8 ms·

I don't think whitespace should EVER be significant, it seems like a very bad setup that's more prone to issues. I also have an unnatural hatred of all things

by PLejeck 15y ago

I don't think whitespace should EVER be significant, it seems like a very bad setup that's more prone to issues. I also have an unnatural hatred of all things Compile-to-JS.

thedufer 15y ago
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.
tomp 15y ago
Which programming language do you prefer then? Don't say C, because in C, whitespace obviously is significant: int a = 1; vs. inta=1; other languages, like CoffeeScript and Python, simply take it to the next level.
- agscala 15y ago
  I think your example is a little too much. Whitespace isn't significant in C. When talking about programming languages, I don't think whitespace refers to spaces between tokens. It's mostly a reference to indentation.
  - masklinn 15y ago
    > Whitespace isn't significant in C. As demonstrated, it is. > When talking about programming languages, I don't think whitespace refers to spaces between tokens. But that makes no sense, it is whitespace, and it has semantic significance (hence being significant). Whitespace was not significant in older versions of Fortran, and that allowed you to write DO30I=10,100 which was interpreted as DO 30 I = 10, 100 that is non-significant whitespace. Ruby has long struggled with how it interpreted its whitespace, for a long time sin (x) + y would be interpreted as sin(x + y) for instance, rather than syn(x) + y how is that not significant whitespace?
    - tordek 15y ago
      But that makes no sense, it is whitespace, and it has semantic significance (hence being significant). Whitespace was not significant in older versions of Fortran, and that allowed you to write DO30I=10,100 which was interpreted as DO 30 I = 10, 100 An amusing bug I saw in Expert C Programming mentioned how somebody once typed e dot instead of a comma, and DO 30 I = 10. 100 ended up interpreted as a simple real assignment: DO30I = 10.1
  - rayiner 15y ago
    He has a point. Whitespace is definitely significant to C's lexer, if not it's parser. When people say "significant whitespace" they're implicitly talking about "implicitly significant to the parser as well as the lexer."
mikeklaas 15y ago
How is it "more prone to issues"? Have you have significant experience in an indentation-significant language like python? As someone who has written 100k's of lines of code in python, I'm surprised how rarely issues arise in practice. The thing is, indentation needs to be correct in "brace" languages for them to be understood correctly, anyway. The famous "dangling if" problem for instance: if (condition) x = 1 y = 2 The better objection to indentation significance, in my opinion, is that it makes it very difficult to find an acceptable syntax for anonymous blocks (which is the main reason python doesn't have them, I reckon).

by PLejeck 15y ago

I don't think whitespace should EVER be significant, it seems like a very bad setup that's more prone to issues. I also have an unnatural hatred of all things Compile-to-JS.

thedufer 15y ago

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.

tomp 15y ago

Which programming language do you prefer then? Don't say C, because in C, whitespace obviously is significant: int a = 1; vs. inta=1; other languages, like CoffeeScript and Python, simply take it to the next level.

agscala 15y ago
I think your example is a little too much. Whitespace isn't significant in C. When talking about programming languages, I don't think whitespace refers to spaces between tokens. It's mostly a reference to indentation.
- masklinn 15y ago
  > Whitespace isn't significant in C. As demonstrated, it is. > When talking about programming languages, I don't think whitespace refers to spaces between tokens. But that makes no sense, it is whitespace, and it has semantic significance (hence being significant). Whitespace was not significant in older versions of Fortran, and that allowed you to write DO30I=10,100 which was interpreted as DO 30 I = 10, 100 that is non-significant whitespace. Ruby has long struggled with how it interpreted its whitespace, for a long time sin (x) + y would be interpreted as sin(x + y) for instance, rather than syn(x) + y how is that not significant whitespace?
  - tordek 15y ago
    But that makes no sense, it is whitespace, and it has semantic significance (hence being significant). Whitespace was not significant in older versions of Fortran, and that allowed you to write DO30I=10,100 which was interpreted as DO 30 I = 10, 100 An amusing bug I saw in Expert C Programming mentioned how somebody once typed e dot instead of a comma, and DO 30 I = 10. 100 ended up interpreted as a simple real assignment: DO30I = 10.1
- rayiner 15y ago
  He has a point. Whitespace is definitely significant to C's lexer, if not it's parser. When people say "significant whitespace" they're implicitly talking about "implicitly significant to the parser as well as the lexer."

mikeklaas 15y ago

How is it "more prone to issues"? Have you have significant experience in an indentation-significant language like python? As someone who has written 100k's of lines of code in python, I'm surprised how rarely issues arise in practice. The thing is, indentation needs to be correct in "brace" languages for them to be understood correctly, anyway. The famous "dangling if" problem for instance: if (condition) x = 1 y = 2 The better objection to indentation significance, in my opinion, is that it makes it very difficult to find an acceptable syntax for anonymous blocks (which is the main reason python doesn't have them, I reckon).