I used CoffeeScript full-time for a year, both client-side and server-side (node.js). I completely agree with everything here -- it's a <i>great</i> summary, and it describes exactly while I never, ever want to use it again.<p>In CoffeeScript, ambiguous code is the rule, not the exception. On top of that, things like variable capture and everything-returns-a-value introduce new kinds of bugs. The author says "realistically, the issues I have raised with CoffeeScript don’t come up every day," but in my experience they pretty much did.<p>But the real kicker on top of it all is that none of the stuff is documented. When you're trying to guess if you should use parentheses or a comma or an indent or a newline or a backslash or <i>what</i>, there are no reference documents to help you. The CoffeeScript home page just has a bunch of tutorial examples which give you an overall idea, but there's nothing rigorous, and the devil is in the details when you start combining aspects of the syntax.<p>In the end, I'm much more productive programming in JavaScript because I know <i>exactly</i> how the language works, no surprises. JavaScript has its fair share of warts, but you take a day or two to learn them, and then you never need to worry about them again. CoffeeScript, on the other hand, is just endless surprises. And I still felt that way after a whole <i>year</i> of using it at work. It's basically unlearnable -- no matter how much experience you have, you constantly find yourself pasting different versions of a line into the "try" tab of <a href="http://coffeescript.org/" rel="nofollow">http://coffeescript.org/</a> until you get one which, through trial and error, turns into the JavaScript code you want.
This article proves not that CoffeeScript is flawed but that Jeff Walker doesn't understand how to use it. For instance, his first example is:<p><pre><code> # BROKEN
func 5, {
event: (e) ->
if e.something
36
else
45,
val: 10}
</code></pre>
Anyone with more than a day's experience with CoffeeScript knows that it's much better to express this with the simpler:<p><pre><code> # far better
func 5,
event: (e) ->
if e.something
36
else
45
val: 10
</code></pre>
Note how just dropping the excessive notation makes the intention clearer while also making the code cleaner.<p>His example on variable capture neatly illustrates a few of the opinions of CoffeeScript that actually make it far easier to reason about code: don't use global variables, and if a variable has the same name, it should refer to the same thing. It's far more confusing to allow rampant variable shadowing. Code that relies on variable shadowing is simply broken.<p>His last example shows a fundamental misunderstanding of not just CoffeeScript, but JavaScript generally. Granted `this` binding can be sometimes confusing, which is why CoffeeScript has a fat arrow (`=>`) to automatically capture `this`.
It's a tool, that is all.<p><i>Ambiguous code</i> is a poorly thought out contrived example with a simple solution.<p>To me, this:<p><pre><code> eat food for food in foods when food isnt 'chocolate'
</code></pre>
Is kind of beautiful and much more readable than:<p><pre><code> for (var i = 0, var len = foods.length; i < len; i++) {
var food = foods[i];
if (food !== 'chocolate') {
eat(food);
}
}
</code></pre>
How is this even an argument?: <i>"One wouldn’t realize it was conditional until reading the end."</i>
How do you expect to understand any code without reading it?
How do you understand people when they talk without listening? And the whole paragraph is moot with syntax highlighting.<p>Variable clobbering is javascript's problem not coffescript's.<p>ECMAScript 6 introduces a syntactic sugar for classes as well as like every single JS framework.<p>Knowing plain old JS is important, especially for understanding CS. CS is just a tool that some people find useful, I don't really understand the passion or frustration.
Ok, so if CoffeeScript is just JavaScript, add the parenthesis. If you need brackets to make a section of code readable or compile to "certain" JavaScript, then add them. Even the programs I work on we add parenthesis, brackets, etc for readability. Use CoffeeScript to increase productivity. Nowhere does CoffeeScript say you must use white space instead of brackets and such. Keep it simple and easy, classes are also nice; I'll be reading those are articles soon as well to gain less of a bias.
<i>>> Why CoffeeScript Isn't the Answer</i><p>What <i>is</i> the question for which CoffeeScript is a compelling answer?<p><i>"I needed to speak to Germans, so I learned French and spoke through a French-German interpreter. Things were occasionally lost in translation and somteimes I couldn't get my point across, but French is prettier. Can I recreate this experience in code?"</i><p><i>"My team can't learn to write `var` or `===`. Can we just learn a new language instead?"</i><p><i>"Indentation speaks to my aesthetic sensibilities, but braces do NOT! What fits my needs?"</i><p><i>"I don't want to use JavaScript. Fortunately, since I never make coding errors, I'll never need to debug transpiled JavaScript. What's the right language for me?"</i><p>Seriously, though, what is the problem that CoffeeScript solves?
I agree with some the things he writes, but others seem blatant absurdities:<p>> "the + operator is still both numeric addition and string concatenation. That is frequently listed as one of the bad parts of JavaScript. Why no provide separate operators for the two?"<p>The problem isn't operator overloading: the problem is implicit type coercion.<p>Having to use 2 separate operators/functions for separate types when writing code, is useful only if types are actually checked at compile time, and the compiler can do inference on them (see the + and +. operators in F#)<p>If you have a dinamically typed language, you can have sane semantics if you make it so that type conversions are explicit (e.g. Python, Ruby...)<p>See also: <a href="http://james-iry.blogspot.it/2009/03/operator-overloading-ad-absurdum.html" rel="nofollow">http://james-iry.blogspot.it/2009/03/operator-overloading-ad...</a>
This article only proves that when doing it wrong, CoffeeScript causes problems.<p>No parenthesis make nested calls unreadable? Simple add parenthesis for the inner calls. Like in any other language with optional parenthesis (Ruby) too.<p>Too long statements are unreadable? Don't write them. Maintaining an 80 or 100 character line limit is good coding practice anyways.
This is not the first article talking about CoffeeScript's ambiguity and readability issues.<p>It's interesting how CoffeeScript fans almost always decide to blame the programmers for these problems. They said good developers should use common sense and use best practices to make code readable, for example by always using parentheses when calling functions. I hear exactly the same argument in the Perl community.<p>But reality is that if a language allows you to write bad code easily, people will write bad code, and you will have to read bad code. This is very easy to verify: most CS project on GitHub, starting with the CS code itself (<a href="http://github.com/jashkenas/coffee-script" rel="nofollow">http://github.com/jashkenas/coffee-script</a>) contain a lot of bad ambuigous uses of the language. A very similar thing happens with Perl code.<p>Programming language design is not only about making it easy to write good code, but also about making it hard to write bad one.
I do have some frustrations with CoffeeScript as outlined here - I find the unless keyword infuriating because it forces me to read backwards:<p><pre><code> a = 123 unless b == 2
</code></pre>
"OK, so a is set to 123. Oh, unless b is 2. That's annoying"<p>That said, my answer is to just not use the unless keyword. If you don't like CoffeeScript classes, you don't have to use them. IMO you could write CoffeeScript using only the kind of functionality availabie in vanilla JS and it would <i>still</i> be a preferable experience.
Am I the only one astounded that we're still having this conversation? The fact that it's still around shows me it has indeed been "the answer" for some. The fact that it hasn't become ubiquitous is plenty of proof that it also is not a one size fit all solution, as if any solution is.
I wonder what the author thinks of GorillaScript [1].<p>[1]: <a href="http://ckknight.github.io/gorillascript/" rel="nofollow">http://ckknight.github.io/gorillascript/</a>
This seems to share many of the same things of CoffeeScript I've had. I prefer plain old JS. More readable, unless you're looking at twitter bootstrap code... No semicolons? Such messy code IMO.
I find CoffeeScript very readable, and I highly value readability. The extra verbosity of JavaScript doesn't really help me when I am reading code. I read CoffeeScript code faster than I can read JavaScript because CoffeeScript removes so much of the repetitive boiler plate code and lets you focus on the intent of the code.<p>I don't really understand the ambiguity argument. From the code examples in the article, I get the impression that the author doesn't really understand CoffeeScript.<p>I definitely prefer CoffeeScript to good old JavaScript.
I had a lot of niggles with CoffeeScript as well, which is why my compiles-to-JS language of choice is LiveScript[1]. It fixes basically all the annoyances and adds a lot of nice things on top of that. For exmaple, you can write more paren-free code with it and there are more kinds of useful function declarations (hushed functions, curried functions, backcalls).<p>[1] <a href="http://livescript.net/" rel="nofollow">http://livescript.net/</a>
Mm, most of the issues the article discusses are part of the learning curve of Coffeescript IMO. The real problem I've had (and I still love it for some reason) is dealing w/ JS frameworks. Like, try using Coffeescript w/ Angular or something. It's quite difficult.
Disclosure: I have never used CoffeeScript. However, based on the article, the death-knell against CoffeeScript for me was the variable scoping rules.<p>With no variable declaration keyword (a la var, my, local, private), adding a variable assignment anywhere could radically change the variable scoping.<p>I'm done, this isn't suitable for prime-time, time to go somewhere else.<p>I spent too many years in the 80s working with xBase. I've been shafted too many times by calling a (coworker's) routine that forgot to declare its variables "private", which stomped over one of my variables. (private in xBase is similar to local in Perl 4) To have a language which doesn't let you declare the intended scope of a variable - ugh.
Phew. I was beginning to worry that a whole month would go by without a blog post about CoffeeScript's deficiencies. I hate it when I write unidiomatic code in a language and then get punished by said language.<p>Now that I got my sarcasm out of the way, whenever somebody bashes CoffeeScripts variable shadowing they openly show the world that they don't understand how variable scoping <i>should</i> work. CoffeeScript covers up JavaScript's warts. One of those warts is JavaScript's broken implementation of closures. CoffeeScript is trying to help you, don't let your lack of understanding of lexical scope get in its way.
> The declaration of what food is occurs in the middle of the line and doesn’t even look like a variable declaration.<p>And that's what makes the whole line unreadable. And 'unless' would make it even less readable.<p>I can understand why people insist on discussing such personal, subjective matters as "readability" or "expressiveness" - I like that too. What I don't get is why do they confuse their impressions with facts and why do they try to generalise based on them. Is it that hard to admit that what's readable to you may be completely unintelligible to someone else?<p>Comparison of programming languages, outside of some really technical metrics, will always be subjective and preference-based. Discussing metrics as vague as "readability" without even agreeing on what it means is absolutely pointless. Yet so many man-hours go into debates and blog posts, sometimes even books, which cover such issues. It's stupid, straw-man discussion every single time it appears.<p>I really wish people would stop writing lengthy posts with a sole purpose of informing the world about their preferences. It's not that I'm against people having preferences, I'd just like them stated as preferences, not facts, and preferably only when they are not repeated a millionth time this month.<p>Edit: also, this: <a href="http://joelgrus.com/2013/12/24/why-programming-language-x-is-unambiguously-better-than-programming-language-y/" rel="nofollow">http://joelgrus.com/2013/12/24/why-programming-language-x-is...</a>
> eat food for food in foods when food isn't 'chocolate'<p>> from the CoffeeScript tutorial...Furthermore, <i></i><i>until you finish reading the line it isn’t clear which foods will be eaten</i><i></i>.<p>The thing with typing the filter at the end is, that format has its basis in mathematical notation, particularly in set theory. Using an even terser mathematical syntax/notation, you could write the same expression this way:<p><pre><code> { eat(food) : ∀ food ∈ { foods } ^ food ≠ "chocolate" }
</code></pre>
You read that as "the set of eat(food) where for all food in the set of foods, the food isn't chocolate". The notation will be quite familiar to mathematicians, and thus if you have a strong mathematical background, especially in set theory, discrete math, and combinatorics, the CoffeeScript array comprehension feels natural.<p>See the Wikipedia article on Set-nuilder Notation/Set comprehension, <a href="http://en.wikipedia.org/wiki/Set_comprehension" rel="nofollow">http://en.wikipedia.org/wiki/Set_comprehension</a>.<p>Here's another example from the Wikipedia article:<p><pre><code> { x | x ∈ R ^ x = x^2 }
</code></pre>
This reads as "the set of all x, where x is a real number and x = x^2", which evaluates to the set { 0, 1 }.
I believe there will be a day when converting CoffeeScript to just native JavaScript won't be very difficult, but until that time, it's useful as a way to have neat syntax features without having to wait for browsers to support it. Indeed, many of the features CoffeeScript introduced into the JS developer's mindset are or will be present in the upcoming ECMAScript specifications. We can only assume this trend will continue.
<p><pre><code> delayed: () ->
-> this.model # isn't the class
</code></pre>
Well, that isn't really fair now, is it? You could have used the fat arrow (`=>`) for binding `this` to the class.<p>With that in mind, I agree with the author in that CoffeeScript isn't the answer, at least not exactly. With syntax this incredibly similar, how far are we from compiling python (with generators, with statements, imports, ...) to JavaScript?
This is a bit overly critical. The implicit parentheses are optional, so if it's confusing or ambiguous you should just use parentheses.<p><pre><code> func 5, {
event: -> 45,
val: 10}
</code></pre>
Is reasonable but<p><pre><code> func 5, {
event: (e) ->
if e.something
36
else
45,
val: 10}
</code></pre>
Really ought to be split up for readability no matter what programming language you use. And besides, the only issue is the extra comma causes it not to compile.<p>To be fair, the `->` vs `=>` (which `this` is `this`?) for class members is confusing. I'd almost prefer class members didn't give you the option and defaulted to `=>`.<p>The "variable capture" section is overblown, though. You're a lot less likely to run into this issue than the classic JavaScript "I forgot `var` and now my variable is global.<p>My biggest complaint is actually the implicit returns. Sometimes I forget a return statement but it works anyway because of this feature. Then I come back later and modify the function slightly only to spend a bunch of time figuring out why it's returning `undefined`.
The example in "Ambiguous Code" is ridiculous - if you write CoffeeScript like that then you have much bigger problems. Also, the part in "Classes Are an Illusion" totally fails to mention the fat arrow `=>`, which solves the main issue the author raises.<p>However, this part I completely agree with:<p>> Realistically, the issues I have raised with CoffeeScript don’t come up every day. Ultimately though, they are enough to say we need something better. I hope to share some thoughts soon on what such a solution might look like.<p>CoffeeScript isn't perfect and we should always be looking for better solutions. So I'm glad that the author wants to add to the discussion. While CoffeeScript isn't <i>the</i> answer, it's probably the best answer we have so far,
Coffee-script is awesome but suffers from it's roots as a preprocessed layer on top .. and that essentially leads to poor overall tool chain support .. I actually enjoyed writing code in it .. debugging not so much ..
Would love some of the constructs to make into JS
I have a rule of thumb that coffeescript is never appropriate for code that has to be require()'d by any code written by somebody else than me.<p>I'll happily use coffeescript, and enjoy doing so, when that condition is met. It doesn't happen very often though.
While it might not be the answer, it has been a very good answer for me. Recently I worked on an Angular project that had a pretty complex data model, and converting the model to CS made the code much more readable. The rest of the app was still in JS, minus a ./models directory which was CS. The other devs found the code very readable also.<p>I am biased towards Python and Ruby. I think that they are nice looking languages.<p>Different tools for different jobs. Next time I am on a JS project and I want to model data, I will probably use CS again.
The only gripe I share is scoping, and that's fixed in LiveScript. I've started writing LiveScript in a fairly explicit style - for example I use parentheses where they improve readability and I always use curly braces for object literals. Qualitatively I think it's increased the readability of my code way beyond JavaScript. It's nice to have curly braces carry specific meaning instead of being littered all over the place.
My problem with CoffeeScript has always been the syntax vs. semantics issue. CoffeeScript saw a big opportunity to improve JavaScript semantics and help programmers more easily avoid the JavaScript minefield ("var" and "===" for example), but in doing so decided "while we're at it, let's overhaul the general syntax too".<p>Gratuitously changing "function" to "->" for no reason other than removing characters seems to introduce more brand new idiosyncrasies than it's worth. If the goal were to improve JavaScript as a language by smoothing over a few of the gotchas, which of course would require a few syntax updates, then I think it would be immensely valuable. (Think SCSS instead of the original "Sass".) But it seems as if the authors were more troubled that JavaScript didn't write like Ruby, so they made a new language that happens to compile to JavaScript. And now I have two languages to choose from, each with pros and cons and their own gotchas, adding more complexity to my decisions when I was hoping for simplification.
These pitfalls can be easily avoided by following a styleguide [1]<p>[1] <a href="https://github.com/polarmobile/coffeescript-style-guide" rel="nofollow">https://github.com/polarmobile/coffeescript-style-guide</a>
There is still not "answer", and the world is not gonna end tomorrow, in the future maybe will be one but until that day comes i will stick with whatever i find appealing to me at present. For now is CS.
Sometimes I think that most CoffeeScript, ClojureScript, etc. programmers are people who were advanced in other languages before they learned JavaScript. There are quite a few programmers who have no issues with these "bad parts" or "really bad parts" because they cut their teeth on them, and these numbers are growing: Most people now learn JavaScript as their first language. JavaScript already won, and things like CoffeeScript are the last gasp of the old regime.
CoffeeScript seems to be an efficient alternative to plain Javascript. The fact is you can't avoid seeing Javascript completely. Just try debugging in Chrome or any other browsers built-in debugger and you'll know what I mean.