You can have similar editor support for indentation syntax, where the editor shows scope markers, code folding, scope coloring, etc. in a particular style chosen by the programmer. The editor could even show you the matching beginning construct after you deindent. The important difference is that redundancy in the user interface can be separated from redundancy in the language's grammar, and personal preference can be used to determine the former. The "mash closing braces" scenario you refer to is generally eliminated with indentation syntax; a single deindent can be the equivalent to multiple braces.
<> is next to shift on the keyboard, {} is AltGr+7/9.
The problem is parsing complexity, they have to be disambiguated from the corresponding operators (also the right shift `>>`), so either the syntax has to be such that they can't appear in the same context and can be trivially differentiated, or you got yourself an exponentially harder to parse language.
With the same right one could argue that {} can't be used for generics etc. since most people also have to write JS from time to time and it will confound the hell out of their language parser when switching languages.
Er… mate I'm talking about actual parsers here, as in the stuff that follows the tokenizer…
foo<bar<1> could be interpreted as "foo<(bar < 1)>" or "foo < bar<1>"
It's undecidable without symbol lookup.
It's not like experienced Python programmers are constantly getting confused by their IDEs and wondering what scope a line is in.
While I tend to write code to match whatever style guide I am following, I know a few programmers who write extremely messy, poorly indented code and then just hit the magic Clang-auto-format hotkey every now and then to clean up their file. In a whitespace significant language it is not possible to infer the correct indentation if not explicitly provided.
Also if you have unmatched braces, that's generally a trivial parse error - the compiler (or linter) will check that and find that every time. But with indents, if the outcome of some code refactoring accidentally broke the indent and everything after some point is over-indented, that tends to superficially work (I've actually made that mistake several times in coffeescript).
Additionally, diffing tools I know of can be set to ignore whitespace, which makes common code changes much easier to understand. If, on the other hand, you do that with an indent-sensitive language you're going to miss indent-changes entirely. That's just a practical tooling problem - you could write a diff that works just as well for indent-based languages - but it's a practical problem nonetheless.
All in all, I think it's a much better idea to have braces. If you think they're ugly, use your syntax highlighter to deemphasize them. A smart code editor could even omit the braces entirely in normal, syntactically valid code (which I'm not suggesting is necessarily a good idea, but it's possible).
There is almost no magic, which is good when learning new stuff. The actual computer is sort of still there. The IDEs are free and good. The environment and APIs are really stable so 10 year old code compiles and runs, and the syntax is traditional. It's not a toy language so it's useful too.
The major drawbacks is that there are a lot of crappy "enterprisy" code out there.
I really liked learning Scheme though (in 1994 or so). I think every php- and javascript-damaged kid really needs a big dose of Scheme, just as we needed it to heal some of the damage that came from Basic and C. (COBOL seems to be very hard to cure)
Clojure does not strike me as anywhere near as "clean" as Scheme, but maybe it's an alternative.
Perhaps a good first year should include courses that uses Java, Scheme and Prolog?
First semester you have 3 courses going into programming from 3 different angles:
- Racket – functional programming, algorithms, etc
- DLX processor design and logical circuits (ended with ARM assembler) – the technical side
- Math – obviously, the pure mathematical side of it
Then, second semester, we did Java, C, complex algorithms and data structures, low-level programming, etc.
I’d say this is a nice way to go at it, because after the first year you have a rough overview how everything, from electron level to malloc, from simple algorithms to a webserver, works.