Hacker News Reader

Comment by simonblack | Hacker News Reader

"We're not in Kansas any more, Toto"

Or to paraphrase that "We're not in Python any more, and C is not Python".

You know what sends me insane? Indentation and lack of fixed types in Python. But I don't have problems with C strings. Because I have grown to love and know C's string foibles just like the author will certainly not be driven insane by 'Python's shortcomings according to me'.

The world is full of people who complain that something or other is different from what they know, so that 'other' is wrong. That's just being isolationist. Everything has its own advantages, its own disadvantages. Let's accept that and move on, instead of making mountains out of mole-hills.

View on HN

> Indentation and lack of fixed types in Python.

Whenever I see someone complain about Python's indentation, my brain internally translates it to "I poorly format my code."

If you code is properly formatted, then Python's indentation is never a problem. I praise Python's indentation-as-syntax because it prevents issues like a dangling else or a forgotten brace while also making proper formatting a requirement for your program to run.

Let's be clear about this: python indentation-as-syntax makes one particular style of formatting a requirement. Not everybody likes it. You might say I poorly format my code in other languages, but most of the time for readability you are somewhat stuck with the formatting of that code base which turns out to be a non-problem thanks to modern editors (sarcasm) like vi that can do brace matching and are older than python.

Python's rigidity on formatting should solve that problem, but it really doesn't and over time it relaxed the rules somewhat which made it better.

The biggest issue is python's indentation stuff doesn't work in a function parameter list, so you get stuck with single line lambdas only or defining a temp named function before using then in an unnatural way.

You've missed the GP point by so wide a margin you could have as well shot in the opposite direction. You're basically doing exactly what they asked you not to.

People are different, work in different ways, are productive with different techniques, have their own habits formed over decades that they don't feel the need to change. None of that means they're worse than you, who, of course, always properly formats your code.

It's perfectly possible, and not that rare, to be careful with indentation and not liking significant whitespace (esp. if the rules are not overly consistent, like in Python). It's also possible to feel like the need to manually adjust indents after moving the code around is a distracting chore that braces largely eliminate. It's possible to work exclusively within an IDE that will make "dangling else" problem impossible to happen, therefore it's possible not to see that as a problem. And so on.

Keep an open mind. Try to get accustomed to various style of working with code. Stop your brain from being discriminatory, and don't assume too much about what other people consider "good" or "poor". If in doubt, ask politely.

BTW: I'm using Python since 2.5.2 professionally. Just a quick disclaimer.

> then Python's indentation is never a problem

I'm sure you have some solid 3rd party research to cite to back up that absolutist claim. Or have some explanation that a it with my workmate's fault and not a git merge (which mixed up indenting between the two files) that introduced a bug that took hours to track down. Or why people like me loved the idea of meaningful indentation in python, then grew to not love it any more after experience.

Or the bitch that it can be when you have to generate code and have to do more than just slap braces around it to delimit blocks.

All in all, another one of those pure-opinion HN posts that are becoming too common.

Indentation and lack of fixed types aren't responsible for over 50% of known security issues in software.

C's issue are not just harmless foibles. They cause real harm to the poor people actually using the software.

> Indentation and lack of fixed types aren't responsible for over 50% of known security issues in software.

there is no way of fixing this with a "string type". The errors come from IPC/Internet, and there will always be just a sequence of bytes, and some length, maybe, given by the user. Somewhere some code will have to trust this length, or compute a length.

That’s a fair point, but of the over twenty programming languages I’ve used in my career, only C uses null terminated strings. All the others store the length. There’s good reasons for that. I think C strings are objectively bad and error prone.

You've grown to love the footguns and hundreds of thousands of security holes that null-terminated strings have introduced over the decades?

It's not so much a question of different is bad, it's that having one of the six positions for your car's stick shift be marked 'Self-destruct' is... Sub-optimal. I'm sure you're smart enough to operate that car safely, but the ditches seem to be filled with burnt-out husks.

Tab-based, versus curly-brace indentation, on the other hand, is a question of how you want the car painted. Purely personal taste.

> It's not so much a question of different is bad, it's that having one of the six positions for your car's stick shift be marked 'Self-destruct' is... Sub-optimal. I'm sure you're smart enough to operate that car safely, but the ditches seem to be filled with burnt-out husks.

Good analogy, but I think you're being to forgiving to C. It's more like having all 6 out of the 6 positions of your car's stick shift marked as self-destruct. If you don't want the car to self-destruct while changing gears, you need to tune your FM radio to 99.0 Mhz and quickly set your turn signals to left, right and left again before shifting. And that only works safely when shifting into the 1st, 2nd and 4th gears, unless you modify your car engine sot it can only drive on Microsoft roads.

On a Python car, the car won't even start if you don't have your cosmetics right, and they have to be of a specific color.

I'm pretty sure that my C program either won't compile, or won't do what I want if I treat curly braces and semicolons as you are treating python indentation.

They serve the exact same purpose, and are both necessary, but the choice of braces versus whitespace is purely aesthetical.

There is no practical advantage to null terminated strings though.

It's not that they are "different", it's that they are extremely error prone and have poor performance for certain operations such as getting the length.

>But I don't have problems with C strings

Everyone thinks they are clever enough to use them and other parts of C without problems, and those people are the most dangerous.

Reply on news.ycombinator.com