11 comments

[ 4.4 ms ] story [ 33.2 ms ] thread
I wish someone would write a CoffeeScript for C++.
I spent a nontrivial amount of time thinking about writing a CoffeeScript-like syntactic sugar layer over C, and I ended up abandoning the project for several reasons, not the least of which being that too many things make nice (or even different) syntax hard. What to do about macros, for example, bothered me for a long time.
C++ is a beast of a language that has semantics which are pretty much too big to keep in your head - I think the best potential for this is some of the new languages targeting some of the same ends (Rust is closer to the capabilities of C++, but Go is more mature and has better tooling).
Alas, "Go" was forced to look sorta like C, even though it really acts more like Modula with closures and garbage collection. (ignoring that C & Modula are both just redressed Algol)

Go is more of a C-like counter example of the things the author is talking about, with its authoritarian use of K&R curly brace formatting, and not making statements into expressions.

Right on. I would definitely constrain such a thing to a small subset of C++.
Does "return unless x is 5" really do what I read?

return unless x is 5

"reads" like

if( x !== 5 ) return;

but I guess it's more like

return (x !== 5);

The way it reads is the way it works, which is why it is a nice syntax. Although,it is actually: if (!(x==5)) return;
> CoffeeScript makes parentheses optional in many cases (as does Ruby)

This is one thing that really annoys me with Coffeescript. I personally find the lack of parentheses makes the code harder to read (since it's sometimes ambiguous where the parentheses should be) but faster to write.

> An important consequence of this is implicit returns: because every construct must return a value, all functions must return a value, whether return is called explicitly or not.

Same concern here. When working with someone else's code, it is sometimes unclear if the author intended the last expression to be the return value or it just happened to be the last line of code and it is safe to return something else.

The lack of parentheses and implicit returns also makes it hard to maintain a consistent code style guide as there are too many ways of writing the same thing.

I'm really not a fan of these optional syntactic elements -- I don't find that they aid comprehension. It's like optional braces in C; I get the idea -- reduce conceptual overhead, make the intent of the code clear -- but in practice, it's just nasty.

I wonder if this is why I like scheme, or if scheme is why I like simple syntax.

    > I personally find the lack of parentheses makes the code 
    > harder to read [...] but faster to write.
Then simply use parentheses. They're still there for you to rely on as much as you'd like to. One main reason why they're optional is so that things flow together nicely with the significant whitespace, like so:

    filter list, (item) ->
      if item.flag is 'priority'
        item.visible
      else
        false
... writing the above with all parentheses present wouldn't be quite as nice -- and I don't think any clearer to read.