Comment by shazow | Hacker News Reader

Comment by shazow | Hacker News Reader

My biggest complaint about CoffeeScript is lines like these:

  $('.shopping_cart').bind 'click', (event) =>
    @customer.purchase @cart

Perhaps it's just me but it feels like there's no rhyme or pattern to the use of punctuation and spaces. This is how my brain parses it:

  variable(string).variable string, (variable) =>
    @variable.variable @variable

Specifically it doesn't feel obvious that 'click' is a parameter of bind, and event is a parameter of a new anonymous function, and @cart is being called with @customer.purchase. If I stare at it enough, I can figure it out, but it's not obvious.

Compared to normal JavaScript...

  var self = this;
  $('.shopping_card').bind('click', function(event) {
    return self.customer.purchase(self.cart);
  });

If you're using a framework, you can even get rid of the 'self' bit with a wrapper that binds the 'this' context.

In JavaScript, where there are parenthesis, you know that something is being called. In the CoffeScript example, there are 4 calls:

  $('.shopping_card')
  bind 'click'
  , (event) /* (Update: This is part of a function definition, my bad.) */
  @customer.purchase @cart

Two are called with parenthesis, two are called with spaced positional arguments. Why?

If I understand correctly, parenthesis for calls are generally optional, but I would argue this is a bad thing. The inconsistent use prevents me from being able to skim code and get a feel for what it's doing. Also not to mention the optional commas in lists:

  contenders = [
    "Michael Phelps"
    "Liu Xiang"
    "Yao Ming"
  ]

I see more good reasons to keep the commas (improves flow, explicit) than to get rid of them (I suppose readers could still figure it out if they tried and it's one less character).

I am a fan of the space-based blocks and single-line lambdas like square = (x) -> x * x

Instead of Python meets Haskell, it feels closer to a mix between Ruby's ambiguous syntax and YAML's indent/line-based parsing. If anyone else ran into these "issues" and but grew to appreciate them, I'd be interested in hearing about it.

Coffeescript does inherit its parentheses-are-optional attitude from Ruby, and as a Ruby programmer, it makes perfect sense to me. That said, just because they're optional doesn't mean it's required to be omitted; I'll often use parentheses when I feel that adding them improves code clarity.

Having been writing Ruby for a few years, I really dig that parentheses aren't required - you can write code that reads a lot more like English and a lot less like...well, code. It does take some mental re-training though. Once you've grown accustomed to it, it scans really nicely, and while it's very possible to write code that's difficult to visually parse, good programmers will use parentheses when they improve clarity, and omit them when they don't.

It helps a LOT to remember that in Coffeescript, you're more or less never naming functions - you're just passing around a bunch of lambdas. The function syntax tripped me up at first, as well, but once I got a handle on what it was doing, it makes a lot of sense.

I've described Coffeescript as "Javascript in drag as Ruby with a Python under her skirt", and I think it's a fairly apt description. :P

I think this a great attitude towards optional syntax. For example:

   xCoord(points[0]) - xCoord(points[1])

...is clear, but paren-ful, whereas:

   print object

...is also clear, but has no need of parens.

I see where you're coming from, but it seems a lot like "my biggest complaint about languages I don't know is that I don't know them".

To be fair, I think there are varying degrees of intuitiveness, clarity, etc with languages but I don't think your example really demonstrates a schism in that regard between JS and CS:

    $('.shopping_cart').bind 'click', (event) =>
        @customer.purchase @cart

     var self = this;
     $('.shopping_card').bind('click', function(event) {
       return self.customer.purchase(self.cart);
     });

If you look at the two together, you'll see everything is almost in exactly the same place. The only difference is some punctuation and small syntactic changes.

Coffeescript should be pretty intuitive for anyone experienced with Javascript, but it does take time to learn and "train" your eyes and brain to understand the syntax...otherwise it wouldn't have much point (but this is true of any language).

I think it's a great virtue of Coffeescript that the CS version is so close to your JS one, while being more readable (imho), shorter, etc.

>The inconsistent use prevents me from being able to skim code and get a feel for what it's doing.

Again, I can't help but feeling like this is a non-Spanish speaking complaining that Spanish prevents them from reading and understanding a Spanish language Magazine.

The optional syntax in Coffeescript is generally optional for a reason, because it is determined by something else (generally indentation).

I think you're right that this could be abused, and I could see how someone might not like it...but personally I prefer it. I like languages that will just do the obvious thing, and let me spell it out when I want something else.

I think again your example doesn't really bear out your point, as it seems plain as day to me that each item is separate and I can't imagine needing commas to differentiate them (though I can respect you might not feel the same).

In fact, contrary to helping commas, are more likely to introduce errors. One of the most common errors in JS is forgetting a comma in a list like that, or the dreaded "hanging comma" error that will only cause an error in IE.

Not having commas also allow easy yanking and insertion of whole lines to reorder the list, etc.

Don't get me wrong, again I think you have a point, it just seems to be that the crux of it is this style syntax is not your cup of tea (which is fine).

On an unrelated note, I'd advise against using the name "self" for variables in Javascript, as it's already taken: https://developer.mozilla.org/en/DOM/window.self

You go back and forth between saying that "you don't get it because you don't get it" and "this is my preference, but you do have a point."

I am experienced in JavaScript, and I believe you that I could train myself to code in CoffeeScript or even brainfuck, but should I want to? I am a big fan of the native JavaScript syntax with a few exceptions. I believe it can be improved, but I don't believe CoffeeScript fixes more than it breaks.

A more appropriate metaphor is a non-Spanish speaker complaining that you dubbed my English movie with more English spoken by a Spanish man with a really heavy Spanish accent. I can still understand the movie if I try but it certainly doesn't improve the experience. Perhaps it does for Spanish people?

I don't like languages that let you do what you think is obvious, and when I look at 5 different examples of the exact same code they all look completely different because it turns out that there's no agreement between what people think is obvious (big problem with Ruby). That's my personal preference.

Using browser-compatibility examples is unfair. I'm not arguing against precompiling with an improved syntax, I'm arguing against precompiling against this specific syntax. It's not hard to imagine a syntax where hanging commas are automagically fixed (even Google Closure does this for you). Inserting whole lines to reorder the list works perfectly fine if you have hanging commas.

  var foo = [
    1,
    2,
    3,
  ]

Re: self, no harm done if your variables are scoped, as they always should be. For bonus irony, var self = this; in the root scope is eqv to what it would be anyways.

Reply on news.ycombinator.com