Hacker News new | past | comments | ask | show | jobs | submit login

Syntax highlighting and code folding in editors/IDEs kind of killed the argument for if/fi or Pascalesque begin/end... even in C++, to terminate heavily parened expressions, I can just thrash ) until my editor tells me I'm done, then run it through clang-format to clean it up.



There's definitely something to that. I think a related reason why syntactic redundancy (e.g. semicolons, which thankfully Swift and Go have made optional) has been reduced in newer languages is that compilation is no longer an actual batch job, and thus error recovery during compiler parsing isn't as big of a concern as it once was. If your program is damaged in a way that the compiler can't parse it, the turnaround time is seconds rather than hours.

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.


IDE features also kill the argument against Python-style indentation.

It's not like experienced Python programmers are constantly getting confused by their IDEs and wondering what scope a line is in.


One advantage of not using {} for blocks is that they are available for other purposes, like generics or templates, instead of the terrible <>, combinations like (::) or unicode characters.


Why are <> so terrible? I mean, they’re more accessible than {}.

<> is next to shift on the keyboard, {} is AltGr+7/9.


> Why are <> so terrible? I mean, they’re more accessible than {}.

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.


That can be solved relatively simply with lookahead, can't it?


Nope, because you can have arbitrary constant expressions within template instantiations.

foo<bar<1> could be interpreted as "foo<(bar < 1)>" or "foo < bar<1>"

It's undecidable without symbol lookup.


Seriously? Some people either have a really weak mental model of a language or want to see problems where there are none.

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.


> Seriously? Some people either have a really weak mental model of a language or want to see problems where there are none.

Er… mate I'm talking about actual parsers here, as in the stuff that follows the tokenizer…


Oh OK, but that's a solved problem.


It would be solved if languages using these forms didn't require more complex parser than languages not using these forms. That is not the case, and it is thus not solved in any meaningful sense of the term.


I'm not sure what you mean here, {} looks just as accessible on the keyboard as <> to me.


Not everyone is on US keyboard ;)


I use a French desktop keyboard and I've remapped left ctrl / left cmd / right cmd / right ctrl (it's a Mac) to { [ ] }. When used as modifiers they of course still perform their original function. Works like a charm, no AltGr necessary.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: