Significant whitespace is a dealbreaker for me. I never tried Nim for this reason
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.
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
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.
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.
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.
They can also be shown always in a very muted color if having frequent problems, for some reason.
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.
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.
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.
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.
loop do
case message = gets
when Nil
break
when ""
puts "Please enter a message"
else
puts message.upcase
end
end loop do
case message = gets
when Nil
break
when ""
puts "Please enter a message"
else
puts message.upcase
end
end
Maybe we both just got bad first expression with most popular, but unfortunately not a good language? =)
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.
I'm now certain that significant whitespace is simply wrong.
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!
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.
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.
[0]: https://journal.stuffwithstuff.com/2015/09/08/the-hardest-pr...
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?
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.
I use Vim, so that would be really unnatural and disruptive.