[treesprite82]

> 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.

[dexterlemmer]

> 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.

[treesprite82]

> 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.