6 ms·
Nice title change, much better than the racism from before, but I'm afraid my spacebar, being white, is offended. Additionally, my previous opinion (http://new
by PLejeck 15y ago
Nice title change, much better than the racism from before, but I'm afraid my spacebar, being white, is offended.
Additionally, my previous opinion (http://news.ycombinator.com/item?id=3296010 http://news.ycombinator.com/item?id=3296010) still stands, that whitespace-significance isn't such a good thing, and this whole "YAY TREES" stuff is overrated.
- raganwald 15y agoI regularly use languages where whitespace is not significant. However, in those languages, whitespace is not significant. It isn’t significant some of the time and not significant some of the time. It is a separator all of the time. Coffeescript is a language where whitespace is held out to be significant, so I’m simply saying “Great! Well in that case, let’s make it more significant." I have no argument with the idea that perfectly good programming languages do not consider whitespace significant.
- PLejeck 15y agoI 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 agoSo, 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 agoOption (3): require both braces and indentation, with a syntax error when they don't match.
- thedufer 15y agoI 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 agoIs 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 agoYes, 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 agoSome 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. :)
- tomp 15y agoWhich 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 agoI 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 agoBut 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 agoHe 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 agoHow 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).
- dextorious 15y ago"""Coffeescript is a language where whitespace is held out to be significant, so I’m simply saying “Great! Well in that case, let’s make it more significant."""" Ever heard of the concept: "too much of a good thing"?
- scott_s 15y agoResponding to what you said before: I also believe that representing everything as a tree (why are programmers so obsessed with trees!?) is ridiculous: code is, quite simply, code. Outline structure or not, what matters is the actual meaning of the code, and this is part of your mental model of the program, not the syntax. Compilers represent your code as a tree - a parse tree first, then an abstract syntax tree. That is how code is understood. It's not an arbitrary decision on raganwald's part.