
CoffeeScript and Progress - focusaurus
http://peterlyons.com/problog/2012/03/coffeescript-and-progress
======
dustingetz
he's missed the point. people aren't saying that "CoffeeScript is a priori
somehow wrong or inferior or a bad choice". Coffeescript is an abstraction,
and abstractions have potential to leak, so some people are questioning
whether the benefits of coffeescript - namely, prettier code - are "worth it"
for production-scale projects.

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.

~~~
focusaurus
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.

~~~
dustingetz
> 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.

------
unoti
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).

~~~
lloeki
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...](http://esa-matti.suuronen.org/blog/2011/11/28/how-to-write-
coffeescript-efficiently/)

------
robterrell
_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._

------
jcampbell1
> 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.

~~~
focusaurus
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.

------
showell30
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-
imagination.html)

------
ajuc
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

~~~
focusaurus
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.

------
btbuilder
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.

~~~
focusaurus
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.

------
drumdance
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.

