4 ms·

So, to take this to its natural conclusion, either you (1) don't think we should bother writing indentation, or you (2) think we should write indentation (presu

So, to take this to its natural conclusion, either you (1) don't think we should bother writing indentation, or you (2) think we should write indentation (presumably for our own benefit, since the language is indentation-ignorant) and then write some extra delimiter for the compiler. In option (1), you're going against possibly the strongest majority opinion programmers hold. Feel free to make this case. In option (2), you want us to write the same information in 2 different ways - one for the reader, one for the compiler/interpreter. If you want to make a case against DRY principles, I would love to hear that as well. Is there a third option I'm missing?

mayoff 15y ago
Option (3): require both braces and indentation, with a syntax error when they don't match.
- thedufer 15y ago
  I don't see this as different from option 2. Failures will just happen at compilation-time rather than run-time. This has the slight advantage of making those errors easier to track down, but still violates DRY.
  - fennecfoxen 15y ago
    Is DRY as important in syntax? I thought the main point of DRY is to avoid writing the same code over and over (code duplication is bug duplication, etc). Are you sure those reasons still apply here, or are we being overly dogmatic in our application of this principle? (though obviously no one likes pointless repetition or obnoxious syntax.)
    - thedufer 15y ago
      Yes, it is important in syntax. You're still entering the same information twice (this time in two different ways, rather than two different places), which allows the possibility that the two conflict (the main problem that DRY prevents), resulting in something bad.
      - fennecfoxen 15y ago
        Some people would say that when a compiler blows up telling you "ur doin it rong", that's a good thing. This is surely why there's so much type information floating around a programming language like Java. (Of course, Java is a little extreme. It's obnoxious to be forced to catch/declare-that-I-throw 50 different exceptions when I do any file I/O, and doesn't bring much to my typical use case. I don't use Java much. :)
        artsrc 15y ago
        These should all be compiler errors because the indentation and the delimiters don't match. if (expression) statement; statement; statement; or: if (expression) statement; if (expression) statement; else statement; or if (expression); { statement; statement; } So curly brace languages should have a defined formatting standard and anything else should be a syntax error.
fennecfoxen 15y ago
I'll make a case against DRY principles. A programming language isn't just about the code. It's about the programmer. What the programmer reads and what the programmer writes are an essential part of programming, and we should look at it not just from a coder point of view (DRY principles) but from a user-experience point of view, where redundancy is frequently helpful! Consider: Displaying whitespace (indentation whitespace, that is) to the user is surely essential for basic code readability; our human brains like this stuff. But the quality of our perception of is limited. It's easy to tell when something is a few spaces further in, but can you tell at an instant's glance whether something's indented by 8 or 12 spaces when it's preceded by a paragraph indented by 32 spaces? Because that tells you which flow control construct you just closed. (For bonus points, the start of that construct is off the top of your screen.) Does counting invisible spaces and lining things up with a ruler sound like a great way to figure out the flow of a block of code? I say Meh. Whitespace is a poor medium for communicating something precise like the flow control of a program. The end to code blocks is something important enough that the marker should be something visible, not invisible. And if that means repeating myself, so be it. But this is a repetition that can be trivially automated. Instead of making whitespace into syntax, go the other way around and turn your syntax into whitespace with your IDE or a code prettifier. -- Now, from all I hear, the ever-popular Python programming language already does plenty with whitespace, so clearly it's certainly not impossible to work with. But I don't like it :)
- extension 15y ago
  Is counting delimiters any easier than measuring indentation? Not really. You will just fall back on the indentation in the end anyway. The delimiters never make anything clearer, they just help push the opening line off the top of the screen.
  - ansible 15y ago
    What we need are better editor setups that can slightly shade the backgrounds of nested blocks to clearly indicate indent levels and easily enable the programmer to see what matches to what. Something like this for VIM: https://github.com/nathanaelkane/vim-indent-guides https://github.com/nathanaelkane/vim-indent-guides Screenshots at the bottom of the page.

mayoff 15y ago

Option (3): require both braces and indentation, with a syntax error when they don't match.

thedufer 15y ago
I don't see this as different from option 2. Failures will just happen at compilation-time rather than run-time. This has the slight advantage of making those errors easier to track down, but still violates DRY.
- fennecfoxen 15y ago
  Is DRY as important in syntax? I thought the main point of DRY is to avoid writing the same code over and over (code duplication is bug duplication, etc). Are you sure those reasons still apply here, or are we being overly dogmatic in our application of this principle? (though obviously no one likes pointless repetition or obnoxious syntax.)
  - thedufer 15y ago
    Yes, it is important in syntax. You're still entering the same information twice (this time in two different ways, rather than two different places), which allows the possibility that the two conflict (the main problem that DRY prevents), resulting in something bad.
    - fennecfoxen 15y ago
      Some people would say that when a compiler blows up telling you "ur doin it rong", that's a good thing. This is surely why there's so much type information floating around a programming language like Java. (Of course, Java is a little extreme. It's obnoxious to be forced to catch/declare-that-I-throw 50 different exceptions when I do any file I/O, and doesn't bring much to my typical use case. I don't use Java much. :)
      - artsrc 15y ago
        These should all be compiler errors because the indentation and the delimiters don't match. if (expression) statement; statement; statement; or: if (expression) statement; if (expression) statement; else statement; or if (expression); { statement; statement; } So curly brace languages should have a defined formatting standard and anything else should be a syntax error.

fennecfoxen 15y ago

I'll make a case against DRY principles. A programming language isn't just about the code. It's about the programmer. What the programmer reads and what the programmer writes are an essential part of programming, and we should look at it not just from a coder point of view (DRY principles) but from a user-experience point of view, where redundancy is frequently helpful! Consider: Displaying whitespace (indentation whitespace, that is) to the user is surely essential for basic code readability; our human brains like this stuff. But the quality of our perception of is limited. It's easy to tell when something is a few spaces further in, but can you tell at an instant's glance whether something's indented by 8 or 12 spaces when it's preceded by a paragraph indented by 32 spaces? Because that tells you which flow control construct you just closed. (For bonus points, the start of that construct is off the top of your screen.) Does counting invisible spaces and lining things up with a ruler sound like a great way to figure out the flow of a block of code? I say Meh. Whitespace is a poor medium for communicating something precise like the flow control of a program. The end to code blocks is something important enough that the marker should be something visible, not invisible. And if that means repeating myself, so be it. But this is a repetition that can be trivially automated. Instead of making whitespace into syntax, go the other way around and turn your syntax into whitespace with your IDE or a code prettifier. -- Now, from all I hear, the ever-popular Python programming language already does plenty with whitespace, so clearly it's certainly not impossible to work with. But I don't like it :)

extension 15y ago
Is counting delimiters any easier than measuring indentation? Not really. You will just fall back on the indentation in the end anyway. The delimiters never make anything clearer, they just help push the opening line off the top of the screen.
- ansible 15y ago
  What we need are better editor setups that can slightly shade the backgrounds of nested blocks to clearly indicate indent levels and easily enable the programmer to see what matches to what. Something like this for VIM: https://github.com/nathanaelkane/vim-indent-guides https://github.com/nathanaelkane/vim-indent-guides Screenshots at the bottom of the page.