Brackets are awesome, don’t use them!

Standard

This is a syntax bike-shedding post, where I will try to explain why I think languages should stop using curly brackets for code blocks. I don’t expect anyone to come away completely blown away by this or anything, but I’m a language nerd and often end up discussing in-development languages with their designers. And since approximately 90% of all language discussion is about syntax, I’ll just write a reusable note on brackets here. J

Why brackets are awesome

Brackets are awesome because you can use them to group things in a way that visually resembles the contents being “grabbed” from both directions. This serves to isolate the contents visually, and allows for nesting. Observe:

((a,b),c)

How awesome is that? It’s immediately clear just visually that ‘a’ and ‘b’ belong together, and that they’re nested inside another pair with ‘c’. There are several kinds of brackets, we could use curly brackets and they work just as awesomely at grouping and nesting things:

{{a,b},c}

The reason this works is because the brackets visually look like they are physically containing any horizontal content between them due to the “grasping” nature of the brackets themselves, and the mirror-symmetry.

When brackets are not so awesome

It’s no coincidence that the previous two examples look visually pleasing, the brackets were designed with that use in mind. Observe what happens if we make a slight adjustment:

}}a,b{,c{

Ugh! Not nearly as nice! It gets worse when we flip it around 90 degrees:

Suffice to say, brackets only really work if you put stuff on a horizontal line with the brackets oriented the right way around.

This brings me how curly brackets are used in programming languages:

{
    Foo;
    Bar;
}

Here we’re really no better off than the previous example. Because the content is laid out vertically, the brackets are not oriented the right way around. The symmetry of the brackets is along the wrong axis, and they do not visually “grasp” the contents.

So is this some kind of horrible atrocity that leads any curly-bracket language to unavoidable doom? Well, no, obviously not. You learn to see the curly brackets as “start” and “end” tokens for code blocks, so the fact that the brackets are no longer awesome at grouping the content isn’t such a huge deal.

So why the fuss? Well because brackets are awesome for so many other things! There’s a ton of things in a programming language that could use a set of brackets to group and nest things (indexing, record literals, tuple literals, function arguments, generics, lifetime annotations, etc. etc.). But if we’re “wasting” one of the bracket types on vertical content then it’s no longer available for uses where it would be more valuable (unless you overload them to mean multiple different things in different context, which IMO makes things look more “samey” and cluttered – see round brackets in Lisp).

Alternatives to curly brackets for code blocks

I propose languages use simple “do”/”end” keywords for code blocks. They can be typed about as quickly as brackets, and IMO reduce the “line-noise” quality of the language. Plus, they lend themselves better to a unified indentation style – avoid the wasted lines of Allman style without spurious arguments about symmetry (since they’re just keywords, people are less likely to object to the “do”/”end” not lining up):

if (x == y) do
    printf("Foo!");
end 

For language constructs that always have a code block “hanging off of them” the “do” keyword could be implicit without introducing any ugly asymmetry. For example, these C-style constructs could all be valid even though for each code block we’ve left off the initial “do” for brevity.

for (int i = 0; i < n; ++n)
    printf("%d\n", i);
end
if (x == y)
    printf("Foo!");
end 
void func(int x)
    printf("%d\n", x);
end 

This of course requires that each of these constructs have a clear syntactic “end point” before the code block. E.g. you could choose to get rid of the round brackets in an if-statement and make the “do” required:

if x == y do
    printf("Foo!");
end
 
Advertisements

6 thoughts on “Brackets are awesome, don’t use them!

  1. It’s a good argument, rarely heard. Braces have better uses than delimiting blocks, visually they are better used on the same line.
    Following that, I wonder what code would look like if we replaced every { by ^ and } by v, or better, by Unicode rotated brackets. It could be done by the IDE without changing the existing code.

    “end” as an alternative to braces has problems. It is a word, so it resembles real code more than a lone closing brace.
    In any case, not having a stand-alone ‘{‘ line matters hugely, and if we go that way, Python wins by not needing ‘}’ either. Haskell, too.

  2. Two choices:

    1- use brackets *correctly*:
    (if (= 1 a)
    (print ‘yay)
    (print ‘nope))

    2- use Modula-2 (or Modula-3 if you want OO).

    ie. DUH! Stop doing C/C++!

  3. The time of visual basic is over 🙂 Leave with it!
    And bringing up examples that are not only counter intuitive (c’mon, where would you see horisontal curly brackets!!!) or taken out of context are simply making you looking a bit less dev and more ignorant 🙂

    • The point of rotating the brackets is that they’re just as “incorrectly” rotated as placing them vertically. The only time they do what they’re supposed to is if they’re rotated the right way around on a single line. You’re just used to placing them vertically so it doesn’t look as wrong, which is why another example is helpful.

  4. Personally I’ve never had a problem with brackets being as they are. I kinda put everything into a row as I read it, as a compiler would, so the brackets align themselves proper. Additionally, a nice thing about { and } is they quite specifically mean the beginning and end of a block. Having them on their own on a line is a clear indicator, but having something like “end”, my mind immediately thinks it’s like “break”. I don’t know why but it throws me for a loop.

    Point being: Symbols are cleaner and easier and shorter imo. :p

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s