3 ms·

I'd disagree with the "end" keyword. You could add more whitespace, which our brains naturally deal with very well, or you add more "cruft" which we have to act

by ricw 13y ago

I'd disagree with the "end" keyword. You could add more whitespace, which our brains naturally deal with very well, or you add more "cruft" which we have to actively think about. In typography white space is what makes good layout work. And here we're going back to replacing white space with a word. So from those perspectives I think the "end" keyword is a regression. Having said that, it's the first language that I prefer from a typographical perspective to python. So very well done on everything else.

skrishnamurthi 13y ago
We tried very hard to do without an ending delimiter. But it boils down to a simple matter: either make whitespace significant or make the grammar hugely (and perhaps irredeemably) ambiguous. Our position on whitespace is: - it's very important for readability - it should not be semantic - it should be possible for a program to reindent your code That is, if I copy-and-paste code from email or a Web page, my environment should be able to "move it into place". Significant whitespace means that that's no longer possible. Therefore, we want whitespace to be a context-sensitive check that is layered atop the language. You could even see turning this off for code that is machine-generated, sent over a wire, etc. We are looking at actual usage patterns before we decide on the precise rules of indentation. To this end, we needed some way of indicating that a block had ended. Ergo "end" and its alias, preferred for one-liners, ";". Let me add one more argument in favor of an ending keyword: quality error messages. The more complex the grammar and hence the parsing job, the much more likely parse errors will be very complex. What we've learned over a few years of doing user-study research into error messages is that ultimately there is a complex algorithm running underneath and the more we can minimize surprise the better, because the user (especially the beginning programmer) simply has no mental model for what that algorithm is doing.

by ricw 13y ago

skrishnamurthi 13y ago

We tried very hard to do without an ending delimiter. But it boils down to a simple matter: either make whitespace significant or make the grammar hugely (and perhaps irredeemably) ambiguous. Our position on whitespace is: - it's very important for readability - it should not be semantic - it should be possible for a program to reindent your code That is, if I copy-and-paste code from email or a Web page, my environment should be able to "move it into place". Significant whitespace means that that's no longer possible. Therefore, we want whitespace to be a context-sensitive check that is layered atop the language. You could even see turning this off for code that is machine-generated, sent over a wire, etc. We are looking at actual usage patterns before we decide on the precise rules of indentation. To this end, we needed some way of indicating that a block had ended. Ergo "end" and its alias, preferred for one-liners, ";". Let me add one more argument in favor of an ending keyword: quality error messages. The more complex the grammar and hence the parsing job, the much more likely parse errors will be very complex. What we've learned over a few years of doing user-study research into error messages is that ultimately there is a complex algorithm running underneath and the more we can minimize surprise the better, because the user (especially the beginning programmer) simply has no mental model for what that algorithm is doing.