35 ms·

There's a good reason to keep the {} syntax beyond polarization: it enables you to programatically change/fix indentation, because the supposed levels can be re

by _ak 11y ago

There's a good reason to keep the {} syntax beyond polarization: it enables you to programatically change/fix indentation, because the supposed levels can be recognized by the level of {}. That's something you can't so in a Pythonesquely structured code.

masklinn 11y ago
Also makes for easier code generation. Generated Haskell code often uses braces-and-semicolon, whereas almost no hand-written code does.
cwzwarich 11y ago
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.
  - 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).
nailer 11y ago
> it enables you to programatically change/fix indentation, because the supposed levels can be recognized by the level of {}. You only need to fix indentation if it doesn't match the block structure. Which modern languages solve by removing the unnecessary* {} tokens. * If you can remove it, and it still works, it's unnecessary.
- krapp 11y ago
  With significant whitespace, you're not really removing them, you're just replacing them with non-printing equivalents. It's an illusion of elegance created in text editors which don't display tabs and spaces, but still basically the same. Visible syntax versus default-invisible syntax.
  - pekk 11y ago
    Indentation is visible. Conservatively estimated, tens to hundreds of thousands of programmers don't have any real problem with syntax based on indentation.
    - nailer 11y ago
      You could also measure non programmers (they lack bias) and get real numbers on whether adding parenthesis helps.
      - pekk 11y ago
        I don't see how these numbers would be more real than measuring programmers at work, unless you intend to help non-programmers write programs.
- DrJokepu 11y ago
  > If you can remove it, and it still works, it's unnecessary. There are elements in source code whose sole purpose isn't only to express instructions to the computer. Expressing the programmer's intent to future readers of the source is obviously also a frequent goal. Comments. Extra parentheses that are not strictly required due to order-of-operations rules. Various annotations and attributes. I mean, these are not exactly new, revolutionary ideas.
tomp 11y ago
Can you please explain this argument a bit more? I don't understand how copy-pasting a piece of code with specified indents (which are known when you copy the code) is any different from copy-pasting a piece of code with specified {} nesting.
- BinaryIdiot 11y ago
  If you copy and paste this code into a different level of nesting the brackets can help give you automatic and proper indentation plus you know it's in that block now. With indentation only blocks you don't get that. At least I haven't used an editor that gives me that. Just my 2 cents
comex 11y ago
The downside is that if by pasting or typing you end up with too few or too many }s, the entire rest of the file gets messed up, nesting everything under the current function or ending a class early - in the eyes of the compiler, making it produce a torrent of meaningless error messages, and of the editor if you hit the reindent shortcut. This happens to me all the time in C, and significant indentation totally avoids it.
- panic 11y ago
  You could use indentation as a heuristic during error reporting. If there's an indentation change without a brace, that's probably where the error is.

by _ak 11y ago

masklinn 11y ago

Also makes for easier code generation. Generated Haskell code often uses braces-and-semicolon, whereas almost no hand-written code does.

cwzwarich 11y ago

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

nailer 11y ago

> it enables you to programatically change/fix indentation, because the supposed levels can be recognized by the level of {}. You only need to fix indentation if it doesn't match the block structure. Which modern languages solve by removing the unnecessary* {} tokens. * If you can remove it, and it still works, it's unnecessary.

krapp 11y ago
With significant whitespace, you're not really removing them, you're just replacing them with non-printing equivalents. It's an illusion of elegance created in text editors which don't display tabs and spaces, but still basically the same. Visible syntax versus default-invisible syntax.
- pekk 11y ago
  Indentation is visible. Conservatively estimated, tens to hundreds of thousands of programmers don't have any real problem with syntax based on indentation.
  - nailer 11y ago
    You could also measure non programmers (they lack bias) and get real numbers on whether adding parenthesis helps.
    - pekk 11y ago
      I don't see how these numbers would be more real than measuring programmers at work, unless you intend to help non-programmers write programs.
DrJokepu 11y ago
> If you can remove it, and it still works, it's unnecessary. There are elements in source code whose sole purpose isn't only to express instructions to the computer. Expressing the programmer's intent to future readers of the source is obviously also a frequent goal. Comments. Extra parentheses that are not strictly required due to order-of-operations rules. Various annotations and attributes. I mean, these are not exactly new, revolutionary ideas.

tomp 11y ago

Can you please explain this argument a bit more? I don't understand how copy-pasting a piece of code with specified indents (which are known when you copy the code) is any different from copy-pasting a piece of code with specified {} nesting.

BinaryIdiot 11y ago
If you copy and paste this code into a different level of nesting the brackets can help give you automatic and proper indentation plus you know it's in that block now. With indentation only blocks you don't get that. At least I haven't used an editor that gives me that. Just my 2 cents

comex 11y ago

The downside is that if by pasting or typing you end up with too few or too many }s, the entire rest of the file gets messed up, nesting everything under the current function or ending a class early - in the eyes of the compiler, making it produce a torrent of meaningless error messages, and of the editor if you hit the reindent shortcut. This happens to me all the time in C, and significant indentation totally avoids it.

panic 11y ago
You could use indentation as a heuristic during error reporting. If there's an indentation change without a brace, that's probably where the error is.