Hacker News Reader

Comment by smt88 | Hacker News Reader

Python is among the least-readable languages for me. The lack of whitespace and brackets around code blocks just make it look like the "wall of text" that everyone hates in emails.

And then there's the fact that Python has significant characters that are literally unreadable because they're invisible (semantic whitespace).

View on HN

I never got the point against meaningful whitespace. It's indentation. You already indent blocks anyway; the only difference is that you don't need braces or begin/end.

I also did not understand your point about "lack of whitespace" around blocks. The only difference between blocks in Python and other languages is that the block start uses a colon instead of an opening brace and you don't have a line for the closing brace. Is that closing line such a big deal for you?

As someone who recently switched to opening curly brackets on new lines and did some Python coding last week I kind of agree - you either put in empty lines everywhere or you have a continuous block of code through all scopes. It's a matter of preference and you can still work with it of course, but I've learned to appreciate reducing code density.

And regarding the syntax, using curly brackets like in C-like languages only takes one more symbol per scope and the difference in readability (where a scope ends etc.) is bigger for me. Also while indentation in Python kind of works as syntax it's not ideal as it can lead to literally invisible syntax errors, and imho the syntax isn't strict enough as Python allows you to have a different indentation width in every single scope.

That said it's still a great language for little experiments. Similar to Bash, despite Bash being not the best designed language to put it mildly.

And yet I notice that you separated the paragraphs in your post using semantic whitespace rather than "BEGIN PARAGRAPH" / "END PARAGRAPH" or something similar, and it seems perfectly readable to me.

> separated the paragraphs in your post using semantic whitespace

That's not what "semantic" means.

In my post, the size of the whitespace was not semantic. I could have used one spaces, two spaces, tabs, or (as I did) a couple of newlines. All that matters is that there was any whitespace at all -- which is what most mainstream languages do.

In Python, the whitespace I chose would change the actual program.

To repeat: I do not want anything that is literally invisible to change my program. It's easy to glance at code and see "=" vs "==", but it's much harder to tell the difference between " " and " ".

> a couple of newlines

A couple of newlines to create a new paragraph is semantic whitespace, as one newline or a space would not do so. Markdown (although not HN's Markdownesque syntax) even has significant trailing whitespace, which I would object to in a programming language.

> it's much harder to tell the difference between " " and " ".

Can't think of any scenario where you'd need to.

If you do mix hard tabs with spaces for indentation, which would cause readability issues with other languages anyway, it'll fail to run and point out where.

I can empathize that significant whitespace sounds off-putting at first, but after biting the bullet I think it's definitely a net positive. Indentation indicates my intent yet most languages just ignore it. For example, consider this gotcha across multiple non-significant-whitespace C-like languages:

    for (i = 1; i < 11; ++i)
        printf("%d ", i);
        printf("%d ", i);

Or, alternatively, hunting down one misplaced closing bracket.

Also, with Python appealing to new programmers, there'd probably otherwise be plenty of beginner code with no indentation at all.

> A couple of newlines to create a new paragraph is semantic whitespace, as one newline or a space would not do so. Markdown (although not HN's Markdownesque syntax) even has significant trailing whitespace, which I would object to in a programming language.

A code block is *not* the same as a paragraph. It is the same as a part/chapter/section/subsection/subsubsection. (Think about it.) In formal writing, these are practically always clearly indicated by not just semantic whitespace but also by semantic headers with particular semantic styling as well as semantic numbering. In addition, if you you write these programatically in for example Markdown or LaTeX, you might have semantic whitespace in the markup language but you definitely will have semantic non-whitespace symbols in the markup language.

Next Quote:

    for (i = 1; i < 11; ++i)
        printf("%d ", i);
        printf("%d ", i);

This has nothing to do with the lack of significant white space and everything to do with terrible language design. Here is the *only* valid way to write the above in Rust:

    for i in 1..11 {
        println!("{}", i);
    }
    println!("{}", i);

If you tried:

    for in in 1..11
        println!("{}", i);
        println!("{}", i);

you would get a compiler error because the braces are required around the bodies of all control- and loop structures. Also note that a common class of bugs is avoided in Rust because in Rust the loop condition is not in parenthesis. (Nor are the conditions in `if`s, etc.)

> Also, with Python appealing to new programmers, there'd probably otherwise be plenty of beginner code with no indentation at all.

Which is to say teaching methodology for coding sucks. While you shouldn't overwhelm a beginner with linting errors from a very pedantic linter (to put it mildly), not automatically linting all beginner code for some basic issues like incorrect white space and wEirD_caPS_in_OVERLY_LOOOOOOOONG_idENTIFIERS or `l` `o` `t` `s` `o2` `f` `s2` `h` `o3` `r` `t` `i` `d` `s3` (lots of short identifiers) is, IMHO, a really bad idea.

Furthermore, actually (at least in my experience tutoring C++/Java/C#), bad white space is actually not that common for beginners after the first few lessons. I guess that most humans are used to just automatically write and type semantic white space. Therefore if they see their teacher writing code with white space they'll not only use white space themselves but use it similarly.

On the other hand the identifier issues I've mentioned above are all more common, especially too short and obscure identifiers.

> A code block is not the same as a paragraph. [...]

Right, but for Markdown they're a difference in output despite the input \n\n being just whitespace, and for the final text they have semantic effect despite being just a gap between text. I don't think the argument was whether the particular semantic meaning of paragraphs exactly matches the semantic meaning of code blocks, just that they do have semantic meaning.

> This has nothing to do with the lack of significant white space and everything to do with terrible language design

It's a problem that illustrates how indentation indicates intent, and would be fixed by semantic whitespace. I agree that if a language is going to disregard whitespace, then {...} should be consistently required to partially make up for it.

> I guess that most humans are used to just automatically write and type semantic white space

My experience has been the opposite: looking over huge blocks of completely unindented VBA/MATLAB code written by people with little prior programming knowledge, and being thankful that data science is moving more towards Python. Likely a different crowd than those being actively tutored in C++.

But yeah there are bigger, often harder to automatically fix, issues with beginner code. PyCharm has PEP 8 lints by default for things like variable name conventions, which help but are still commonly ignored.

You can add empty lines before and after blocks. The only thing that matters is the indentation. If you see code without empty lines separating different steps, that's pretty badly written Python.

> If you see code without empty lines separating different steps, that's pretty badly written Python.

You're describing literally all of the Python I've ever seen. Look at Flask, for example[1].

Furthermore, without brackets, adding newlines in a code block forces me to then add more newlines between blocks (which Flask also does!)

I would rather just have easy-to-scan, clear characters that demarcate a code block.

1. https://github.com/pallets/flask/blob/main/src/flask/templat...

fully agree with you. the downvotes must be by Python fanboys seething in their indented whitespaces.

I'm not a Python fan at all but still see much value in clean, DRY syntax.

Significant whitespace is a huge success even in languages that switched to it late! Almost nobody in the F# or Scala¹ community would consider to switch back to that unnecessary line noise which are explicit block markers.

Code should be indented for readability anyway (and almost nobody would dispute that)! So there is just no real value in additional block markers. In fact such block markers make refactorings more difficult than needed.

¹ https://august.nagro.us/scala3-braces.html

___

BTW: Contrary to your opinion stated in your profile "subtracting points" for writing things the majority here disagrees with is not fascist in any way but exactly the mechanism that keeps the quality of the comments here high—which in turn attracts those "smart people hanging out here" (who you're praising) in the first place. ;-)

per se, I don't mind the white spaces--but I don't want to be forced to use them. Like what you see in Julia, or Kotlin. Code is poetry. I should be trusted to organize my code according to how it reflects what it reflects.

I dislike block markers as much as forced white-space, because there is lack of freedom. I understand that this was done so that different people could easily read legacy code but I don't think this helps because despite Python zen, there way too many ways to do the same thing. Why not allow the programmer to get creative so that at least the code is elegant? Elegance is highly readable.

---

BTW: I think a good mechanism would be: "do not reward if it is not worth it" and "reward if it is." But the Fascist aspect here is: "punish if it is not worth it." Who decide what is worth what? Opinions vary. If everybody thinks alike, nobody is really thinking. Answers that earn higher points may be attractive to a majority of people, but you well know that the majority are of average intelligence (IQ is normally distributed). So mediocre quality gets upvoted, anything the mediocrity-loving majority doesn't, gets downvoted. Makes sense? The intelligent people I refer to are those who like me, question, probe, disagree, and dare to say it like it is. :) That does not mean the majority.

> unnecessary line noise

It's not noise, though. It protects me from common whitespace issues like careless copying/pasting, style differences between me and other developers, and IDE/OS settings.

It's also just easier to scan. Imagine if we did the same thing with math:

    a * b / (c - d)

Look at that noise! We can get rid of some of those symbols, right? Let's replace parentheses with whitespace instead.

   a*b/ c - d

So now it's denser and I typed fewer characters, but it's harder to scan because my eyes don't register " " as quickly and easily as they register "{".

I don't see the connection between white space in PLs and parenthesis in math.

On the other hand: Let's consider what the Python-like version of math actually look like:

    f(x) = :
        x, if x > 0
        -x/2, if x < 0 and x is even
        0, otherwise

In stead of:

              __
             /
             | x,  if x > 0
    f(x) =  <  -x/2, if x < 0 and x is even
             | 0, otherwise
             \__

The latter is, of course how math actually looks.

Reply on news.ycombinator.com