5 ms·

Why does it make sense to have this particular syntactic redundancy and not one of the many others that has been proposed? You could make a similar argument tha

Why does it make sense to have this particular syntactic redundancy and not one of the many others that has been proposed? You could make a similar argument that Algol-style 'if' / 'fi' pairs help eliminate brace errors where you accidentally close the wrong construct, but clearly they have not been popular in recent years.

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.
- 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.
NEDM64 11y ago
Because Swift was designed to be easy to pick up by most programmers. And those are used to curly braces, from JavaScript, to languages that they teach in college, like Java, PHP, C, etc...
- roflchoppa 11y ago
  Which actually beings up the point, when will higher education make the switch over??
  - accatyyc 11y ago
    Why should they switch over?
  - kuschku 11y ago
    Actually, higher education is now switching over... from Scheme, ASM and C, Haskell and Co to Java, Java and Java. Oh, and Java.
    - kpil 11y ago
      I think java is a rather good learning language. 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?
      - kuschku 11y ago
        Well, what my uni used to have until 2015 was this: 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.
interpol_p 11y ago
Can {} (or any symbolic scoping) be considered a syntactic redundancy if it allows auto-formatting and auto-indentation of your code? It may be a redundancy to the compiler, but to the code editor it is useful information. 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.
- Nullabillity 11y ago
  You can just use tabs or indent by single spaces, and have the autoformatter fix it afterwards. Alternately, use a proper editor.
  - emn13 11y ago
    There are editors that do such things. However, I've never seen one that does it well. It tends to break down if you're editing code and have a temporary intermediate stage that's syntactically invalid. It's also not great in the face of copy-pasting, especially if you're rearranging code in ways that breaks blocks. You're easily left with code that's been "autocorrected" resulting in everything after a certain point being indented one level too much or too little. In a brace-using language that would correspond to an extra closing brace (or a missing closing brace), and it's easy to fix. In an indent language, fixing it is more of a hassle. 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).

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.
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.

NEDM64 11y ago

Because Swift was designed to be easy to pick up by most programmers. And those are used to curly braces, from JavaScript, to languages that they teach in college, like Java, PHP, C, etc...

roflchoppa 11y ago
Which actually beings up the point, when will higher education make the switch over??
- accatyyc 11y ago
  Why should they switch over?
- kuschku 11y ago
  Actually, higher education is now switching over... from Scheme, ASM and C, Haskell and Co to Java, Java and Java. Oh, and Java.
  - kpil 11y ago
    I think java is a rather good learning language. 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?
    - kuschku 11y ago
      Well, what my uni used to have until 2015 was this: 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.

interpol_p 11y ago

Can {} (or any symbolic scoping) be considered a syntactic redundancy if it allows auto-formatting and auto-indentation of your code? It may be a redundancy to the compiler, but to the code editor it is useful information. 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.

Nullabillity 11y ago
You can just use tabs or indent by single spaces, and have the autoformatter fix it afterwards. Alternately, use a proper editor.
- emn13 11y ago
  There are editors that do such things. However, I've never seen one that does it well. It tends to break down if you're editing code and have a temporary intermediate stage that's syntactically invalid. It's also not great in the face of copy-pasting, especially if you're rearranging code in ways that breaks blocks. You're easily left with code that's been "autocorrected" resulting in everything after a certain point being indented one level too much or too little. In a brace-using language that would correspond to an extra closing brace (or a missing closing brace), and it's easy to fix. In an indent language, fixing it is more of a hassle. 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).