Hacker News Reader

Comment by p1necone | Hacker News Reader

Imo the whole whitespace sensitivity thing was a mistake to begin with. It makes code harder to read, harder to write and harder to parse with only the benefit of being a little easier to understand to absolute beginners (and I'm not even sure about that last one).

View on HN

I am very much not a beginner and I don't find whitespace sensitive languages hard to read. I don't find Lisp hard to read either. Or C-style languages for that matter. The sheer passion people have towards whitespace vs brackets vs parenthesis makes me question their sanity.

Congrats: you are an outlier. That's pretty cool, and it means you can read a lot of code quite easily, which I'm sure lets you be more productive than most, but you are not like most other people.

I think this is one of those silent majority situations.

Almost all programmers can read a C-like language because well, that covers like 95% of languages by use. You have C/C++/Java/Go/JS/Kotlin/Rust/zig/C# etc.

BUT second to that in sheer use is probably Python. Almost everyone (that I know) has touched it atleast a bit whether its dev scripts, tooling, scientific work (bio, cv, etc.), robotics, mech engineers, ml/ai space etc.

Why would anyone nitpick to death tools that have so much ubiquity? Well they'd have to have a narrow focus to even consider it. The majority of algebra users never second guess +, *, ^, (), etc.

I'd say lisp is probably the hardest to get used to combine with the least frequent to cross your path. And then there's a long tail of bash/ruby styles, tcl, ocaml, etc etc.

I think this is a dangerous assumptions to make: the last time I looked at C was 30 years ago, you show me real C code with pointers and references and namespaces and I couldn't tell you wtf was going on if my life depended on it.

With a few weeks of study to "re"learn C and/or C++? Sure, they're just programming languages. But right off the bat? No idea what the hell is going on in real, production C code.

This is my point though. People just complain about whatever syntax they aren't used to using but none of them are inherently more difficult to read.

None of them are inherently more difficult to _learn_ but they sure as hell are more difficult to read when everything's peppered with :: and * and &.

That's a matter of opinion and one I disagree with.

The problem of working C code isn't the syntax, it's the semantics.

Casting pointers isn't difficult to read because dereference and multiplication share *, it's difficult to understand because it's not something you do outside of C.

Maybe you don’t.

In my experience, people who struggle with different syntax conventions are the outliers; if you can handle the idea of brackets generally (as we all do regularly), then you can deal with one set of conventions.

Similarly, if you can grasp the concept of a paragraph, or of bullet points, or a bunch of other things in normal text that convey meaning through whitespace, then you can deal with another.

It's only code that (some) people complain about this with. In every other context, we all know that we can work with syntax based either on brackets or spacing. Just in normal communication, all humans deal with a dizzying array of complex conventions without even thinking about it.

The reluctance to use whitespace-sensitive languages (or the other way around) is learned helplessness, rather than a widespread inadequacy.

Are you sure this an outlier opinion amongst regular python users?

Well no, I imagine that that group would somewhat self select for developers who are okay with reading whitespace based syntax. Someone who finds it hard to read is probably not going to become a regular user of the language unless they have to.

Python is lingua franca in data science / ML, i.e. you pretty much do have to to work in the field. In my experience the people who complain about this aspect of python are those just starting out.

Dependency management would be an example of a real Python issue, not a "everyone gets used to it" one IMO.

I use python extensively, and whitespace very much is an actual issue. Not a big one, but it is annoying every once in a while e.g. when copying code. Especially as autoindenting is very much hampered in that case, because the editor can't tell what the indent is supposed to be if multiple options are valid python. Dealing with braces instead is much easier. Not a deal-breaker or major issue, but an annoyance nonetheless.

Why would a python programmer have any understanding of code that's full of pointers and memory addresses? You show someone who started on Python, and still uses it today, real product C code and their eyes glaze over real fast.

I think you replied to the wrong person.

There's some evidence that indentation-based block delimiting is intuitive: People indent their blocks even in whitespace-insensitive languages.

Indentation-based delimiting is good for reading because it provides visual structure. For writing, it's much more effective to rely on braces or parentheses instead and have the indentation be inferred by an autoformatter. For example, with braces, I can just copy-paste a statement or block of statements from somewhere else and it will have the correct semantics regardless of what indentation the source and destination end up having, and the autoformatter will immediately fix it for me.

With indentation-only based delimiting, you don't know whether you're seeing the whole thing:

  def check(situation):
    if situation.under_nuclear_attack:
       situation.set_alert_level(RED)
  -------------- bottom of window -----------------

Is that the whole function? Does it forget to launch the counterstrike? Or is there more? We don't know without scrolling down.

You can change the meaning of code, without changing its whitespace sensitive diff (git diff { -w | -b }).

> with only the benefit of being a little easier to understand to absolute beginners (and I'm not even sure about that last one).

This one is backwards: the benefit is forcing beginners to write well-formatted code. You would not believe the insane things people just learning can come up with, when in a C-style language where indentation doesn't matter.

Technically, it has the benefit that code cannot be incorrectly indented - it can't be formatted to look like the scope is one way when in reality it's another way.

Code can absolutely be incorrectly indented in python and to make matters worse it changes the functionality of the code when it is.

Code can be indented in a way you didn't mean for it to be. But it cannot be incorrectly indented in the sense I just described, because the indentation changes the functionality of the code. The indentation can never mislead you about the structure of the code.

I've seen one case where it has, where the outdent at the end of a nested loop/loop/if was wrong: it was only 3 spaces instead of matching the 4 indent, so it looked right at a glance but wasn't. Needed to use pdb to step through it and see it do the wrong thing before that stuck out.

And harder to copy-paste!

Call python "harder to read" is like call rain "harder to get wet".

I find it odd that this isn’t a configuration option in any/all language compilers. I prefer indents to braces, but understand the hate others have. Turns out AST engines could convert them relatively easily.

A lot of languages do have auto formatters with opinionated defaults for this.

For go, gofmt is so opinionated that you can't even configure it, which is kinda cool because it means all go code that uses it will look the same.

There's also rustfmt for rust and prettier for JS/TS (and I assume similar for lots of other languages I'm not familiar with), both of which are configurable, which I prefer - but I can see the upsides of a one-size-fits-all code formatting tool (especially for a language like go where a reasonably constrained feature set/syntax is an explicit goal of the language).

Python has black, also not configurable.

Black is pretty nice with the defaults, but it certainly is configurable these days.

It can take command line options, or it can be configured in your Poetry pyproject.toml file.

https://black.readthedocs.io/en/stable/usage_and_configurati...

Reply on news.ycombinator.com