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?

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 :)

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?

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.

And the Zen of Python:

    Flat is better than nested.

In conclusion, if telling nested levels apart is a problem, that's a code smell, not a problem of the indentation system.

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.

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

Screenshots at the bottom of the page.

commenting to save for later (sorry)

/Counting/ delimiters isn't necessarily any easier for our brains than measuring indentation.

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.

You're lining up the statement that opened the block with the statement that comes after the block. Should be easy.

And in the most common code style, delimiters don't line up anyway, because the opening delimiter is at the end of the line.

I guess my feeling is, why automate something that doesn't need to happen at all? If you need to see your whitespace, it should be trivial* to make it visible. Thus, I agree with the comment about brackets being no easier to count than spaces.

*Assuming you're using a reasonable editor.

It's true; you could use syntax highlighting or IDE features to make things more obvious. You could also turn on syntax highlighting in Whitespace.

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 ;)

My response was meant in much the same tone as yours; I use vim and, while I have never needed visible whitespace, I don't have any indication that its an easy thing to do.

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

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.

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.)

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.

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. :)

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.

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).

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.

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.

> 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?

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

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."

Whitespace does not control program flow in C. It only is used to separate tokens. It is not used to control program flow(like coffeescript and python).

Note that:

  int a = 0;

and

  int a=0;

and

  int                       a             =       0;

are all equivalent.

When we say whitespace, we usually mean multiple spaces at the start of a line, something known as "indentation" ;)

s/whitespace/indentation/

You know that's what is being discussed.