
A CoffeeScript Intervention - telemachos
http://www.pragprog.com/magazines/2011-05/a-coffeescript-intervention
======
Seldaek
I don't quite agree with the conclusion of the article ("you’ll come away with
a better understanding of JavaScript"). The fact that CoffeeScript hides
scoping and other stuff from you means you will never have to learn how
JavaScript really works.

You can argue whether this is good or bad, but it's not giving people a better
understanding of anything, it's just making them follow best practices
unknowingly.

~~~
TrevorBurnham
(I'm the author.)

JavaScript can be pretty overwhelming to newcomers. You mention scope, which
is a good example of where CoffeeScript actually clarifies rather than hides
the underlying semantics.

The most important thing to understand about scope in JS is that _only
functions create scope_. This is very different from C and Java, and since
JavaScript looks like C and Java, that difference is surprising (see e.g.
[http://www.adequatelygood.com/2010/2/JavaScript-Scoping-
and-...](http://www.adequatelygood.com/2010/2/JavaScript-Scoping-and-
Hoisting)). When you learn the same rule in CoffeeScript, it feels a lot
simpler. And that understanding can carry over to JS.

Granted, the compiler is generating the `var` keyword for you, but the mapping
is trivial. What's important is that scoped variables have the same behavior
in both languages.

~~~
Seldaek
All I'm thinking is that people should start using JSLint instead of making up
languages on top of JS. That will catch most of the bugs due to common
misunderstandings of the language.

~~~
technomancy
JSLint can't solve the "I forgot to include a frickin' explicit return _again_
" problem, can it?

~~~
Seldaek
That's a first world problem of ruby devs I think. When you're used to it, you
never forget to write return statements.

~~~
rubergly
Agreed. I hardly think that people who haven't used languages like Ruby or
Coffeescript (with implicitly returning the last expression) ever forget
return statements in a way where everything would be okay if they just added a
"return" keyword. When I use Ruby and Coffeescript, I consciously have to
think "no, I _shouldn't_ write _return_ this time"; I find it hard to believe
that, without using a language like this, anyone would just write an
expression and expect it to be returned. I could see an argument that if
you're returning the application of a function, but it has always seemed
extremely natural to me that I think about what I'm returning when I write a
function; I actually always have a little bit of trouble adjusting to writing
Ruby-style return-less code.

~~~
rawsyntax
it depends on how you think of functions... If you think of everything as an
expression, of course it has some kind of value.

That being said I prefer not to have to write "return" but work plenty with
languages outside of ruby and have no issues writing return when necessary.

~~~
technomancy
> it depends on how you think of functions... If you think of everything as an
> expression, of course it has some kind of value.

Sure, and functions by definition return a value. I know programming isn't
math, but the notion of a "void function" is somewhat of an oxymoron.

------
jasonkester
Wow, this article actually had the opposite of its intended effect with me. I
had always expected that CoffeeScript was a better form of JS that I should
probably get around to learning. Now I've just learned that besides having an
unpleasant syntax, it actually redefines some important features of javascript
to behave in novel ways.

As an example, the whole point of setTimeout is to be able to do the sort of
thing shown in Example 4. Defeating it just means you now have to search for
another way to do the things that setTimeout was designed for.

Same with variable scope. If you can't declare a global without actually
standing in the global scope, that makes things harder, not easier.

Beyond that, I glazed over at seeing various little ascii arrows. I'm sure
they're there for a reason, but by then I was already halfway out the door.

~~~
jacobolus
First, use or don’t use what you want. If you don’t like the cleaner CS
syntax, stick to writing raw JS. Your other points aren’t especially valid
though:

1) You can trivially use setTimeout just as you did before. CoffeeScript just
gives you a couple extra tools for simplifying things when you have use cases
like the one presented in the article.

2) As for the global namespace: if you want to attach something to the window
object it’s much more readable to just write "window.foo = bar" or whatever.
In general though, I defy you to come up with an example where you want to
define global variables from some other scope where your code wouldn’t end up
just as clear but more robust with cross-scope variables defined in some high-
level scope. Pretty much everyone agrees that JavaScript’s "pollute the global
namespace by default" feature was a mistake.

The ascii arrows are by far the best part. JavaScript turns out to be a very
nice language (semantically) for writing functional-style code. Unfortunately,
the regular JavaScript syntax makes defining functions so unpleasant that I go
out of my way to avoid extra ones. CoffeeScript makes defining functions so
easy that I go looking for ways to use more, instead.

------
oinksoft
If you can't be bothered to learn the behavior of keywords as fundamental to
JavaScript as "var" and "this," then yes, you'd better be using some wrapper.
Items (3) and (5) seem to be the only valuable features demonstrated here, and
(5) should be present in the ES Harmony (it is already present in JS 1.7).

The article states that

> It’s about more agile code

but I find this claim dubious when the best JS tools are for JS, and not
CoffeeScript. I believe that the features provided by the Closure compiler are
more beneficial for stable JavaScript development (annotations, etc), and
carry a significant performance incentive.

~~~
rubergly
I don't think the point is "you won't need to learn how these work!"; rather,
it's "you don't need to worry about using the normal convoluted ways of
dealing with these". It's never claimed that _= >_ implies (ha, logic humor)
that you don't need to know how _this_ works, just that _= >_ helps you deal
with a common annoyance found with using _this_.

~~~
oinksoft
My main point is that only those who cannot be bothered to learn the
language's finer points (I don't consider these to be amongst them, but as
indicated by this blog post, others do) will reap significant benefits from
using a tool such as CoffeeScript. Anybody else would be sacrificing too many
useful JavaScript-specific tools to justify the benefits of a slightly more
expressive language.

~~~
rdtsc
> the language's finer points

I wouldn't call those "finer" points.

~~~
oinksoft
You don't read parentheses.

------
beseku
This and the recent release of 1.1.0 gave me a push and I spent some time
converting a small library I maintain (<http://flickrshow.com>) to
CoffeesScript as an exercise and and education into the syntax and potential
benefits.

As it was a 1-1 conversion it was fun to see not only how much syntactical
cruft the CS syntax removes but also how a few sloppy lines got tidied up,
(mainly existence checks). In that sense, it adds value. It'll be interesting
to follow this up with how easy it is to churn out new code ...

------
bergie
It looks like the future of JS resembles CoffeeScript quite a bit:
<http://brendaneich.com/2011/05/my-jsconf-us-presentation/>

------
hasenj
Interesting. I didn't know about the 'do' keyword or the repetition bit with
{x,y} returning {x: x, y: y}. Pretty cool!

~~~
tomstuart
The {x,y} rvalue syntax isn't in the CoffeeScript documentation. This is the
first place I've seen it.

~~~
grayrest
It was but it got dropped in the doc update for 0.4 or thereabouts. I was
hoping he'd take it out for a while because it complicates the disambiguation
of braceless object literals but it seems most people like it, so meh.

~~~
tomstuart
It's a bit weird that it breaks alpha equivalence (i.e. you expect your
program's semantics to be invariant under local variable renaming) but I can
see why people like it. It's certainly compact and idiomatic, and there's a
nice (albeit superficial) symmetry with destructuring assignment.

