Python is pretty to look at, but I hate working in white space sensitive languages. If I have to have another argument about tabs vs. spaces I am going to toss my monitor out the frickin’ window.
Well, tabs versus spaces is not a Python thing, that will bite you in any language eventually. Blame the VT-100 terminal.
Here is the thing about indentation versus curly-braces-and-semi-colons: It boggles me that people find it acceptable to use one mechanism to communicate block structure to the compiler, and a completely different mechanism to communicate block structure to humans, and have no way to automatically check that they have the same semantics. This is a frequent source of bugs, and is entirely preventable. When it comes to the ergonomics of computer-convenient versus human-convenient, humans should win. Therefore, significant white space is clearly preferable simply from the standpoint of eliminating the source of an entire class of bugs.
But the main thing that makes Rust harder to read is all the punctuation noise and short, cryptic keywords. While one friend once said: "A good programmer can write FORTRAN in any language.", I don't feel compelled to help them.
> It boggles me that people find it acceptable to use one mechanism to communicate block structure to the compiler, and a completely different mechanism to communicate block structure to humans, and have no way to automatically check that they have the same semantics. This is a frequent source of bugs, and is entirely preventable.
Strongly agree. The solution that Rust, Go and other new languages have adopted is shipping a formatting tool to consistently make the semantics of indentation and braces match. I personally can't help but think that this is a worse-is-better solution when compared to significant whitespace, but at least it works. Every Rust CI I am setting up will fail the build if `rustfmt --write-mode=diff` feels like you didn't run rustfmt before committing.
> But the main thing that makes Rust harder to read is all the punctuation noise
Given the decision to favor explicit casts, references and dereferences over implicit ones, this cannot really be helped. In some ways, once you get used to it, it helps readability, because it always communicates what the things being worked on are.
> and short, cryptic keywords.
I agree that this was probably a mistake. Cannot really be helped now, though.
Overall, I think the readability argument against Rust is overstated. Sure, when you are starting out it looks like line noise, especially if compared to python. But it didn't take me more than a week or two before it basically became entirely clear and readable. The radical explicitness of the language helps readability in many ways that make it much better than C++.
Of course, much better than C++ is a low bar to pass.
I think Go shipping a single canonical formatting tool was an inspired decision that eliminates a massive point of contention in software teams. I expect the majority of new languages to ship a canonical format tool in the future.
GCC will now warn about (some cases of) misleading indentation, which is a step forward. And clang format can autoformat based on the brackets, I believe.
I still prefer whitespace to indicate blocks though.
Python is ugly and inconsistent as hell due to lack of methods (no maps or reduce in collections for example), indentation, lack of expressions (nearly everything is a statement) and one statement lambdas.
Though rust is beyond good and evil indeed, I really don't get this obsession with brackets and C-like abominations like &*staff. Ada or SML are doing a much better job.
PEP-8 (more than 15 years old) recommend spaces, so unless you are deliberately looking for a fight, the question is settled.
Autoindent is a solution to a problem that doesn't exist in Python in the first place. Having two independent representations for blocks, one for human readers (indent) and one for compilers (braces), leads to nasty bugs when they get out of sync. Autoindent is a tool to keep them in sync. In Python there is a single representation, so nothing can get out of sync.
But the tooling for editing the code has no support for indenting blocks as trivially as adding braces.
Sure, you just run clang-format or such on the block/file, and get all the visual stuff sorted out.
The difference is that I can add braces in the middle of multiple lines, just need to get my changes to match up, and then I can tell it to reformat the changed section/the whole file.
For block indenting, I have to select each block I want to operate on before issuing the block indent command.
Braces let me skip the selecting, requiring the same cursor movement but allowing batch insertion of selection begin/end markers, in a sense.
> If I have to have another argument about tabs vs. spaces I am going to toss my monitor out the frickin’ window.
Clearly the correct answer is spaces. /s
Seriously though, I like python because not only is it pretty, it's also concise. While it's not perfect, a lot of time has been spent on language features to make them easily comprehendable.
The lesson for me from python is that UX is important, even in programming languages.
Fortran IV came close. You could put spaces in the middle of identifiers, keywords, and numbers, and the compiler ignored them. The language did not require spaces as separators anywhere. Spaces were only significant in Hollerith constants (what we'd call string literals today) and in columns 1-6. Columns 1-6 were reserved for line numbers, comment signifiers, and continuation marks.
Also, it makes autoindent in Emacs worse.