Commentary
source: http://www.andrewluetgers.com/2011/09/07/coffee...
Andrew Luetgers thinks CoffeeScript is an exercise in making a programming language that is as terse as possible, at the expense of readability. I argue that, instead, it is about achieving a closer fit between what you think and the code you actually write down. Cutting down on line noise, not creating it.
Hm, your argument that CoffeeScript divides the community is specious at best. Sure, on a superficial level it means people writing code for the browser are now using two different languages (well, plus ObjectiveJ, ClojureScript and a couple of others) but at the end of the day both crowds can use each other’s libraries and both crowds are knowledgeable about JavaScript. I dunno, maybe there’s something to this line of thinking, but then you really do need to do better than just spreading FUD around.
Secondly, your fear that CoffeeScript leads to line noise and is harder to scan utterly misunderstands the design goals of CoffeeScript. Sure, CS cuts out and shortens syntax here and there, but the ultimate goals are greater consistency and better readability. It’s about things like default arguments, list comprehensions, function binding, destructuring assignment and so on, which are obviously all things that are possible in JavaScript and, you might argue, things you can do in your sleep in plain JavaScript too… but they lead to an incredible amount of line noise, with temporary vars and brackets and parens all over the place.
Helping us express common patterns in as clean a way as possible is not at all about saving keystrokes, it’s about making a language that brings what you mean and what you write as close together as humanly possible, instead of forcing you to think about stupid implementation details and incidental complexity.
This is especially obvious if you’ve ever coded in Python or Ruby. You want to quickly loop through a hash, whip up a quick for ... in loop, and notice that, err, this isn’t working at all. You want to see whether a string starts with a substring, look for something like str.startswith(substr) and realize that you’re going to have to make do with str.indexOf trickery, which is easy, but indexOf isn’t very descriptive now is it? You want to do something as simple as adding a few default arguments to a function or method, and realize that JavaScript has no syntax for such a common pattern. Now, I’m sure you’re thinking “well, but these things are super-easy in JavaScript, you just have to know how to do them” — but at that point you’d actually be arguing the inverse of your original claim, namely that the fact that JavaScript is harder to write and scan because it doesn’t abstract away these patterns doesn’t matter. Well, it does!