CoffeeScript and Progress(peterlyons.com)
peterlyons.com
CoffeeScript and Progress
http://peterlyons.com/problog/2012/03/coffeescript-and-progress
8 comments
Anecdotally, Airbnb's mobile website (http://m.airbnb.com) was written entirely in CoffeeScript.
We had never used CoffeeScript before the project and we finished what you see today in about 6 weeks with a team of 3.
The project codebase looks like it was written with consistent style all the way through, which can be harder to do with JavaScript when it's 3am and all you want to do is make it work (when you start to get lazy). It was nice knowing that the for loops I was writing would compile to the same for loops that the other guys were writing.
CoffeeScript currently makes up just over 1% of Airbnb's codebase. I expect that number to grow quite a bit over the next year. Here's the breakdown according to github: http://cl.ly/2A241Z2d2I2m2R211Q1t
We had never used CoffeeScript before the project and we finished what you see today in about 6 weeks with a team of 3.
The project codebase looks like it was written with consistent style all the way through, which can be harder to do with JavaScript when it's 3am and all you want to do is make it work (when you start to get lazy). It was nice knowing that the for loops I was writing would compile to the same for loops that the other guys were writing.
CoffeeScript currently makes up just over 1% of Airbnb's codebase. I expect that number to grow quite a bit over the next year. Here's the breakdown according to github: http://cl.ly/2A241Z2d2I2m2R211Q1t
also, the comparison of number of lines for coffeescript and javascript is usually misleading, because same logic/implementation in cs is usually(or, always) smaller than the js version.
How much functionality, if you can make a guess, would you say is there in the codebase in cs?
How much functionality, if you can make a guess, would you say is there in the codebase in cs?
All of the http://m.airbnb.com functionality is in CoffeeScript.
I think programmer productivity is also linked to happiness given one's own tools. My experience thus far is I'm happier when working with CoffeeScript. Not "OMG P0nies" happier, but significantly happier. I think the amount of boilerplate CS removes is significant, but indeed whether it is worthwhile depends on many factors in any given situation.
Given how CS maps to JS, I'm not too worried about leaky abstractions.
Given how CS maps to JS, I'm not too worried about leaky abstractions.
> programmer productivity is also linked to happiness given one's own tools
so i certainly agree with this, but in my experience, as the problems get harder, my happiness isn't determined by syntax.
the things that make me mad are "i have to fix this defect but this code is a fragile mess which i'm afraid to touch, so i bandaid on more hacks to have the minimum possible area of impact so i know for certain that i can give this to the client and it won't make things worse". that makes me fucking furious, man, the artist in me dies a little bit every time I do it. We have this issue in our large javascript codebase. CoffeeScript would probably help a little bit, but a speculative 2x improvement in "fucking furious" is still furious.
This opinion is probably along the lines of those who think CoffeeScript is a toy. List comprehensions don't fix our problem; we (my team) just don't care. investing in education, growing the teams ability to craft well factored code and stable code, that will have exponential payoff.
Now you can get meta here and say a language like ClojureScript which brings Clojure's strong opinions about managing complexity and crafting good abstractions - you get better just by using it, its sort of self-educating. ClojureScript has my attention.
so i certainly agree with this, but in my experience, as the problems get harder, my happiness isn't determined by syntax.
the things that make me mad are "i have to fix this defect but this code is a fragile mess which i'm afraid to touch, so i bandaid on more hacks to have the minimum possible area of impact so i know for certain that i can give this to the client and it won't make things worse". that makes me fucking furious, man, the artist in me dies a little bit every time I do it. We have this issue in our large javascript codebase. CoffeeScript would probably help a little bit, but a speculative 2x improvement in "fucking furious" is still furious.
This opinion is probably along the lines of those who think CoffeeScript is a toy. List comprehensions don't fix our problem; we (my team) just don't care. investing in education, growing the teams ability to craft well factored code and stable code, that will have exponential payoff.
Now you can get meta here and say a language like ClojureScript which brings Clojure's strong opinions about managing complexity and crafting good abstractions - you get better just by using it, its sort of self-educating. ClojureScript has my attention.
I would also argue that even if the abstraction overhead of CoffeeScript proves problematic in the long run, it would still be an excellent tool for writing out a functioning sketch of your project. The individual components can then, if needed, be rewritten in JS. And because of CoffeeScript's golden rule, that's a wonderfully simple process.
> people aren't saying that "CoffeeScript is a priori somehow wrong or inferior or a bad choice".
It may not be the best anti-CoffeeScript argument out there, but it is a pervasive one. The most common objection I've seen to using CoffeeScript is not any actual criticism of the language or of the various overhead created by another layer of abstraction, but simple horse laughs along the lines of "CoffeeScript is a toy. Use a real language."
While the stronger arguments should be addressed, like the one against against adding an additional abstraction, I don't think addressing the weaker arguments is "missing the point".
It may not be the best anti-CoffeeScript argument out there, but it is a pervasive one. The most common objection I've seen to using CoffeeScript is not any actual criticism of the language or of the various overhead created by another layer of abstraction, but simple horse laughs along the lines of "CoffeeScript is a toy. Use a real language."
While the stronger arguments should be addressed, like the one against against adding an additional abstraction, I don't think addressing the weaker arguments is "missing the point".
There is no point, it is a description of how some people respond to language innovation. I've seen people reject CoffeeScript for valid reasons (even if I don't share them), but I have definitely also seen people show a knee-jerk aversion to CoffeeScript without even really knowing what it is, thinking it is somehow "wrong" on a fundamental level.
If you're considering trying Coffeescript, here are a few thoughts for you. Remember that the Vim plugin for Coffeescript compiles your Coffeescript to a js automatically every time you save, and it even shows you immediately if there are any errors. I've had difficulty setting up other Vim plugins, but this one was blessedly simple to get going.
An awesome tool for helping you to learn Coffeescript is the "Try Coffeescript" tab on http://coffeescript.org/. This lets you type a little bit of stuff, and see how it translates into Javascript, in realtime, while you type. I still use this today when I'm trying to verify I'm on the right track with a bit of punctuation (meaning, leaving punctuation out, usually).
An awesome tool for helping you to learn Coffeescript is the "Try Coffeescript" tab on http://coffeescript.org/. This lets you type a little bit of stuff, and see how it translates into Javascript, in realtime, while you type. I still use this today when I'm trying to verify I'm on the right track with a bit of punctuation (meaning, leaving punctuation out, usually).
Also, a bunch of shortcuts[0] and Syntastic (which Just Works) makes it absolutely blissful.
Note that although :CoffeeCompile operates on the whole file by default, it also works on buffer regions, so vai,c shows me the current block as JS (i is from indent-object plugin)
[0] http://esa-matti.suuronen.org/blog/2011/11/28/how-to-write-c...
Note that although :CoffeeCompile operates on the whole file by default, it also works on buffer regions, so vai,c shows me the current block as JS (i is from indent-object plugin)
[0] http://esa-matti.suuronen.org/blog/2011/11/28/how-to-write-c...
Http://js2coffee.org is also very useful
Ouch, my eyes! All those closing punctuation groups!
This seems to come up often, the purported ugliness of JavaScript. To rebut, I'll use one of his own arguments:
I don't really know why people bring this up so often. It's just a non-problem for me.
This seems to come up often, the purported ugliness of JavaScript. To rebut, I'll use one of his own arguments:
I don't really know why people bring this up so often. It's just a non-problem for me.
> The few who responded seemed to dislike it, not for any particular technical objection to the language or its features, but simply to its existence at all, which surprised me.
It seems that the author is surprised by rational human behavior. A new language introduces a tradeoff between having a new tool that may better solve your problems, and introducing fragmentation where the developer must invest time learning a new language and tooling or the developer faces a smaller body of code that he can work on.
I like and use CS, but the author's philosophy that more languages in use always better for everyone, is fundamentally flawed.
It seems that the author is surprised by rational human behavior. A new language introduces a tradeoff between having a new tool that may better solve your problems, and introducing fragmentation where the developer must invest time learning a new language and tooling or the developer faces a smaller body of code that he can work on.
I like and use CS, but the author's philosophy that more languages in use always better for everyone, is fundamentally flawed.
So let me clarify that my general take on the state of programming languages today is that they are all pretty terrible and we don't have a good track record of fixing known flaws with them. With tend to just live with them. Given that, most new languages offer a shining chance at progress toward something better. They indicate someone is thinking about the problem and trying to help. Thus by default I like new programming languages per say. But yes, each does add to the total body of stuff out there, which has a cost.
This is Rob Pike's take on FUD toward new programming languages:
http://commandcenter.blogspot.com/2011/12/esmereldas-imagina...
http://commandcenter.blogspot.com/2011/12/esmereldas-imagina...
If
f g h x boils down to f(g(h(x)))
and
[1 2 3] boils down to [1, 2, 3]
Then what is the meaning of [f 1] ?
EDIT: I've tried on http://coffeescript.org/ and it seems a = [1 2 3] doesn't work? EDIT2: newlines instead of spaces works, my bad
Then what is the meaning of [f 1] ?
EDIT: I've tried on http://coffeescript.org/ and it seems a = [1 2 3] doesn't work? EDIT2: newlines instead of spaces works, my bad
Right, array elements separated by new lines works, but CS requires commas between elements in 1-line arrays. I would like to see CS remove commas between array elements but most folks like commas there, it seems. And yes, I guess there's a syntax ambiguity with function arguments that is not easily resolved. I love omitting parens for calling a single function, but doing it more than once per line should be avoided I think.
Semi-related anecdote: Ruby enforces commas in arrays but the problem still exists for [f 1, 2]. Is it [(f 1), 2] or [f(1, 2)]?
Apparently as a consequence of this ambiguity, even [f 1] has become illegal in Ruby 1.9. One of those god-awful undocumented changes that broke my apps. :(
Apparently as a consequence of this ambiguity, even [f 1] has become illegal in Ruby 1.9. One of those god-awful undocumented changes that broke my apps. :(
I agree with pretty much all of his points. But the argument that code will 'never align' with line numbers seems like a dismissal that debugging exactly what you wrote is very valuable when tracking down subtle bugs.
Fair enough. I don't need line numbers specifically when I have a full-on in-browser graphical debugger so I can debug exactly what is being interpreted. There's work underway to handle mapping back to source files, and when that arrives, it will be "nice". However, listening to NodeUp podcasts, people think that line numbers not lining up is an absolute deal-breaker, which I just don't find to be the case at all in my personal experience.
I also think that lack of line-number mappings is a fair criticism of coffeescript. If the article is rejecting FUD, then it should target statements like "debugging is a nightmare." I agree with the author's overall point that you can usually track down problems without a lot of fuss.
Or not-so-subtle ones, debugging Cocoa is a pain even for simple stuff (such as the wrong format spec to NSLog) when Xcode drops you into a debugger full of assembly 9 times out of 10 instead of saying "Look here, this NSLog call makes no sense" and dropping you in obj-c code.
I don't have an opinion pro or con on this.
However, I'm old enough to remember when JavaScript was first introduced as LiveScript and it was mostly seen as a toy for simple stuff while Java was the Real Deal. (I started my first company largely on this premise.) The big competition back then was ActiveX. Remember that? Amazing how things have evolved.
However, I'm old enough to remember when JavaScript was first introduced as LiveScript and it was mostly seen as a toy for simple stuff while Java was the Real Deal. (I started my first company largely on this premise.) The big competition back then was ActiveX. Remember that? Amazing how things have evolved.
as your project gets big, does coffeescript help us write more maintainable code, better abstract our solutions so we can keep less things in our head at once, resulting in higher agility and fewer bugs? When you look at the deep reasons why a large codebase went sour, you're not blaming it on things like list comprehensions, you're blaming it on things like "Java strong-arms us towards building abstractions with only OOP, which over the course of a few years builds into indecipherable layers of implementation inheritance, causing high defect rates and much decreased agility".
The difference between CoffeeScript and Javascript, in terms of what a team can accomplish, hasn't been proven in production-scale projects. they may be, or maybe only for some teams, or maybe they aren't, but you can't debate something without being able to articulate the opponent's position.
update: interestingly, ClojureScript may be a language where the productivity delta from javascript is much larger, and is better worth it. clojurescript introduces new ideas and idioms to the js community, where coffeescript is an incremental update to javascript with no new ideas.