5 ms·

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

by nly 11y ago

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.

cwzwarich 11y ago
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.
alricb 11y ago
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.
- kuschku 11y ago
  Why are <> so terrible? I mean, they’re more accessible than {}. <> is next to shift on the keyboard, {} is AltGr+7/9.
  - masklinn 11y ago
    > 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.
    - iSnow 11y ago
      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.
      - masklinn 11y ago
        > 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…
        iSnow 11y ago
        Oh OK, but that's a solved problem.
        masklinn 11y ago
        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.
    - fao_ 11y ago
      That can be solved relatively simply with lookahead, can't it?
pekk 11y ago
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.

by nly 11y ago

cwzwarich 11y ago

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.

alricb 11y ago

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.

kuschku 11y ago
Why are <> so terrible? I mean, they’re more accessible than {}. <> is next to shift on the keyboard, {} is AltGr+7/9.
- masklinn 11y ago
  > 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.
  - iSnow 11y ago
    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.
    - masklinn 11y ago
      > 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…
      - iSnow 11y ago
        Oh OK, but that's a solved problem.
        masklinn 11y ago
        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.
  - fao_ 11y ago
    That can be solved relatively simply with lookahead, can't it?

pekk 11y ago

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.