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.
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?
(though obviously no one likes pointless repetition or obnoxious syntax.)
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. :)
if (expression)
statement;
statement;
statement;
if (expression)
statement;
if (expression)
statement;
else
statement;
if (expression); {
statement;
statement;
}
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 :)
Something like this for VIM:
https://github.com/nathanaelkane/vim-indent-guides
Screenshots at the bottom of the page.
However, it is (at least for me) much easier for your eyes to line up two delimiters then a keyword/function call/literal/whatever and the end of the block it introduced when that block's termination is implicit from indentation. With the delimiters, I have two similar things to line up visually. With indentation-significant, I have to line up a delimiter with blank space, which is difficult.
And in the most common code style, delimiters don't line up anyway, because the opening delimiter is at the end of the line.
*Assuming you're using a reasonable editor.
http://en.wikipedia.org/wiki/Whitespace_(programming_languag...
This is, of course, significantly more ridiculous than an IDE helping you out with your CoffeeScript, so don't take my teasing too seriously ;)
No, but the problem there isn't the whitespace per se, but the 32 spaces. To quote Linus on the Linux Coding Style guide:
If you need more than 3 levels of indentation, you're screwed anyway,
and should fix your program.
Flat is better than nested.
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
int a = 1;
inta=1;
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
DO 30 I = 10, 100
Ruby has long struggled with how it interpreted its whitespace, for a long time
sin (x) + y
sin(x + y)
syn(x) + y
DO30I=10,100
DO 30 I = 10, 100
DO 30 I = 10. 100
DO30I = 10.1You know that's what is being discussed.
Note that:
int a = 0;
int a=0;
int a = 0;