I could never understand why people care this much about significant whitespace of all things. This seems like such a non-issue, it should be a minor annoyance at worst. Then again my favorite language is Lisp, so maybe I'm just too much beyond caring about syntax. The only annoying thing about significant whitespace is having to escape a new line sometimes.
But significant whitespace has always made sense to me. You are going to indent your code anyway, so you might as well give the indentation some meaning. I write Python, JavaScript and Lua most of the time, and I never waste any thought on whitespace VS braces VS keyword delimiters.
> You are going to indent your code anyway, so you might as well give the indentation some meaning.
Autoformatters came and fixed that problem. Nobody (except python, haskell and nim coders probably) wastes time indenting code anymore, you save and your code is indented. Nowadays, code that relies on whitespace and has no ending delimiters (like nim and python) gets awkward because the formatters have less information to go on. If your rust or typescript code formats to bad indent or none at all, you have an error.
I can count multiple reasons why someone might dislike significant whitespace. The most evident is that whitespace is... not evident at all! By definition, it's a transparent character: it's extremely difficult to directly count spaces; they can be indirectly counted by comparison with text in the surrounding area. The same principle why we add commas or apostrophes or spaces every 3 digits in big numbers.
As of the "you're going to indent your code anyway" claim, this seems to completely ignore one-liners, either embedded in other documents (onClick=...) or fed to the shell as a quick way to get some work done without spawning new tools.
I turned on indentation guides on my basic editor twenty years ago and never looked back. Show whitespace in a pinch once a year? Or shift arrow select. Not a significant problem.
They can also be shown always in a very muted color if having frequent problems, for some reason.
The biggest advantage if you can avoid significant whitespace is that it's usually a lot easier to manipulate text if you don't have to worry about the whitespace being correct. For example, when I'm copying and pasting Javascript code from somewhere else into a file, I don't need to worry about getting the indentation right, I just paste it into the right location, press format, and it does what I want. This is often nontrivial in Python, where both the source and the destination may have existing (invisible) whitespace. Worse, leading whitespace characters are often trimmed on copy or select, which often makes the resulting paste even more chaotic.
This is a minor inconvenience, and I still use Python regularly when it makes sense, but from a language design perspective, I think it's one of those decisions that makes your users' lives that slight bit harder with no real upside.
Select-lines-(shift)-tab when needed is quite easy.
Often that’s not needed either because moving from one function to another is the same level.
The benefit is not having to constantly read/write delimiters. Imagine a shell where all arguments had to be delimited by , or | chars instead of whitespace.
It's harder when the source or the destination isn't all indented in quite the same way, which happens often if you start a block, press enter and end up on an indented line, and then paste the code.
I don't really get the readability argument - like the lisper I was replying to said, it's all much of a muchness. A shell where arguments are delimited by commas is a function call in most programming languages, and people don't struggle with readability there. If anything, I find having an explicit "close block" symbol a useful visual marker on the page, but I write Python fairly regularly and don't really notice much readability differences compared to any of the brace-using languages I work with.
I configure my basic editor to remove trailing whitespace on save, not specifically for that reason but it does mitigate it.
The point was that whitespace was always significant. People like to pretend it isn’t for some reason. Perhaps because it has a minimum though not a maximum.
There’s a reason Python is considered very readable and “executable pseudocode.” Less delimiter and sigil noise is the main reason.
It's harder to tell where code blocks end just by looking
2, I sometimes want to fuck up the indentation on purpose, if I'm just quickly pasting some code to test if it even works or to mark it as "look at it in 5 minutes from now". Also I can mix spaces and tabs
quick edits it notepad/vim/whatever become painful
also converting tabs to spaces or vice-versa is tiring. A language shouldn't force me to a particular code style
> It's harder to tell where code blocks end just by looking
This is always puzzling to me.
I've always felt that the indentation is what told me a code block ended, not a closing brace. It's graphical rather than textual.
Maybe that's why Python feels more natural to me. The indentation tells me a code block ended, and the closing brace used by other languages is just a redundancy. Languages that use things like "endif/endfor/etc" end up looking downright cluttered.
> also converting tabs to spaces or vice-versa is tiring.
Get a better IDE. I've never had this be an issue in PyCharm.
It’s subjective, but this is also why I haven’t tried Nim or Crystal. If you like brackets, I’d say try Swift if you want to stay in the natively compiled + GC space.
I've really never understood where this aesthetic preference comes from.
Back when most of my code was in C or C++ (or Java), I was told all the time, sure you can omit these braces for a single-statement block, but you shouldn't, you'll regret it later. You can leave all the code unindented or irregularly indented, it won't matter to the compiler, but you'll appreciate lining it up in the long run. And all that advice was correct; I was better off in the long run, and I saw others come to regret it all the time. But then, over time, I started to wonder why I had to scan past all these diagonal lines of close braces as I read the code. And I cursed that these languages made it too difficult to pull out the inner parts into separate functions, disentangle setup and teardown from the main loop etc. But I also cursed that after putting in the effort (even if was just "using a proper text editor") to make things line up beautifully and in agreement with the logical structure, I still had to take up vertical space with these redundant markers of the logical structure.
Python was my first language using significant whitespace, and it was a breath of fresh air. That was a bit over 20 years ago, I think. I've learned several other programming languages since then, but I never "looked back" in any meaningful way.
Every time I copy paste something in python I have to check the whitespace. Often there's a problem that needs fixing, like the first line indented differently, or everything is off. Sometimes I'm not paying perfect attention and get hard to catch bugs.
I'm now certain that significant whitespace is simply wrong.
Significant whitespace pushes a tooling problem (correct indentation) into the human domain. It might have made sense before autoformatters that run on save, but I agree with you that in today's languages, it's a net negative.
As far as I'm aware, none of the new languages that have seen success in the last ten years (Go, Rust, Swift, Dart, Kotlin) rely on the author to format code correctly - instead, they do it for you. And that's good! That's one less thing the programmer has to worry about!
> Significant whitespace pushes a tooling problem (correct indentation) into the human domain. It might have made sense before autoformatters that run on save, but I agree with you that in today's languages, it's a net negative.
Sorry, I don't follow. There's nothing preventing a tool from re-indenting code when it's pasted (i.e.: considering indentation within the pasted text relative to its first line, and then applying an indentation offset according to where it's pasted), and many already do. It's the same kind of logic that's used to auto-format code in braced languages; arguably simpler unless it's also validating the existing indentation of the pasted text.
And actually, who even is relying on "autoformatters that run on save"? I want the code to look right as I'm writing it, not after. The tools you describe are, to me, about maintaining project standards when multiple people are involved, but fundamentally each person is still making the code look locally, personally right before saving (or committing, since these things are also often done with pre-commit hooks). I can't imagine just typing out whatever slop is syntactically correct and waiting to save the file to fix it. Not when I have a proper text editor that facilitates typing it out the way I want it, taking advantage of awareness of the language syntax.
> none of the new languages that have seen success in the last ten years (Go, Rust, Swift, Dart, Kotlin) rely on the author to format code correctly - instead, they do it for you.
Languages do not and cannot format code. Text editors (including the ones built into IDEs) do. If I type a } and the text changes position, it's not the programming language that did this.
And this is also not better in braced languages. Just as I can input a } on a new line in Vim in a braced language and have it dedent, if I want to write more code in Python that's outside the block, I just press the backspace key and it removes an entire level of indentation. And then I start typing that code, and I don't have to input a newline because I'm already on the line where I want the code to be, because I'm not expected to have a } on a separate line from everything else.
> Sorry, I don't follow. There's nothing preventing a tool from re-indenting code when it's pasted (i.e.: considering indentation within the pasted text relative to its first line, and then applying an indentation offset according to where it's pasted), and many already do. It's the same kind of logic that's used to auto-format code in braced languages; arguably simpler unless it's also validating the existing indentation of the pasted text.
I have not had this work reliably for me - my relatively stock VSCode does not indent the pasted code correctly - but I will freely admit that it could, and that this is a point in favour of good tooling.
> And actually, who even is relying on "autoformatters that run on save"? I want the code to look right as I'm writing it, not after. The tools you describe are, to me, about maintaining project standards when multiple people are involved, but fundamentally each person is still making the code look locally, personally right before saving (or committing, since these things are also often done with pre-commit hooks). I can't imagine just typing out whatever slop is syntactically correct and waiting to save the file to fix it. Not when I have a proper text editor that facilitates typing it out the way I want it, taking advantage of awareness of the language syntax.
Most people who write code in these languages rely on them! Format-on-save is one of the first things one sets up in an ecosystem with high-quality formatters. You can write code that is sloppily formatted but conveys your intent, then save and have it auto-format. It completely reformats formatting as a concern. As they say in Go land: "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."
> Languages do not and cannot format code. Text editors (including the ones built into IDEs) do. If I type a } and the text changes position, it's not the programming language that did this.
These languages ship with first-class robust and performant formatters that encode the language's preferred style; much effort has gone into developing these formatters [0]. For all intents and purposes, they are part of the language, and users of these languages will be expected to use them.
> And this is also not better in braced languages. Just as I can input a } on a new line in Vim in a braced language and have it dedent, if I want to write more code in Python that's outside the block, I just press the backspace key and it removes an entire level of indentation. And then I start typing that code, and I don't have to input a newline because I'm already on the line where I want the code to be, because I'm not expected to have a } on a separate line from everything else.
I just don't think about it. I write my code in whatever way is easiest to type - including letting the editor auto-insert closing braces - and then hit save to format.
In general, you are freed from formatting as a matter of concern. It's just not something you have to think about, and that's liberating in its own way; it makes bashing some code out, or pasting some code in, trivial.
> Most people who write code in these languages rely on them!
I find that a little hard to believe. There is a universe of programmers out there who are basically invisible to you.
> I just don't think about it. I write my code in whatever way is easiest to type - including letting the editor auto-insert closing braces - and then hit save to format.
Don't you want to see neatly formatted code while you're writing it?
For Go, they have a statistic from a few years back that suggests about 98% of a cross section of real-world Go projects are formatted according to gofmt. (https://jmoiron.net/blog/fmty-dmpty) I can believe Rustfmt and other tools not having quite the same reach, but I would guess that the proportion is still pretty high.
These tools are very standard and very widely used.
> Don't you want to see neatly formatted code while you're writing it?
Every time I pause, I press ctrl-S or an equivalent. So I really am seeing neatly formatted code while I'm writing it. I would guess that 90% of the time, if my code is syntactically valid, it's also neatly formatted. And even if it's not valid code, it's probably very close to being neatly formatted.
Yes, optimize for the thing you do once in a great while over having to read/type redundant braces constantly. Wouldn’t want to have to pay attention and use the tab key! ;-)
I've been certain that copy & pasting code is simply wrong for a long time, but if the ease of doing this is your yardstick for language design quality, then you are simply right.
Hello fellow programmer from the middle ages; we discovered long ago that significant whitespace is a dead end, the fact that it's popular with the wannabes changes nothing.
