
CoffeeScript is not a language worth learning - llambda
https://github.com/raganwald/homoiconic/blob/master/2011/12/jargon.md#readme
======
fab13n
TL;DR: Coffeescript should be seen as a way to enforce good Javascript style,
and as such it does a decent job.

That's an interesting and very defensible PoV. However, even considered as
such, it has some serious warts:

* It has no clearly-defined semantics: it's an accretion of rewriting tricks, and as such, it's often very hard to predict how two tricks will interact together, especially when they involve indentation and line-breaks.

* It tries to support too many cute idioms, which leads to too many ways to do things. There ought to be one obviously best way to do each thing, for the sake of maintenance and readability.

Now, if we consider CS as a presentation layer for JS, then its proper place
is in an IDE, not as a compiler. Ideally, files should be stored as JS and
converted back to CS transparently when editing. Mixes of real JS and CS->JS
code should mesh together gracefully. When a piece of CS is highlighted, the
corresponding JS should be shown as a tooltip. And of course, when a backtrace
is produced, it should be translated from JS lines to CS lines transparently.

Today, CS fancies itself as a compiler, i.e. something which produces object
code which should never be dealt with by the programmer. As such, it fails. If
it presented itself as a representation/refactoring abstraction, it would be
much easier to embrace. Of course, the implementation/integration with an IDE
would be an order of magnitude harder than a text->text processor, and would
make the language^Wtool liable to editor wars.

~~~
gerggerg
From the coffeescript website: _CoffeeScript is a little language that
compiles into JavaScript. Underneath all those awkward braces and semicolons,
JavaScript has always had a gorgeous object model at its heart. CoffeeScript
is an attempt to expose the good parts of JavaScript in a simple way._

Coffeescript has never presented itself otherwise. What causes the confusion
is pointless discussions about semantics and people who don't fully understand
the point of coffescript teaching other people about it and writing over
zealous blogposts.

All programming languages are human convenience. The computer cares not about
list comprehensions or splats. It just reads hi/low. Coffeescript is a tool
that enables you to write those hi/lows more conveniently. It doesn't care if
its called a language or a form of mixed martial arts. It's just there to help
you if you want it to.

<https://en.wikipedia.org/wiki/Compiler> _A compiler is a computer program (or
set of programs) that transforms source code written in a programming language
(the source language) into another computer language (the target language
...)_

~~~
fab13n
> Coffeescript has never presented itself otherwise.

My point was not to disparage the author, his intentions, his lucidity, nor
even the resulting language. When people receive something packaged as a
compiler (a file->file traduction tool to invoke from the command line and to
include in building scripts), they naturally understand it as a compiler, and
judge its qualities as a compiler.

And by "compiler", I mean the informal concept that people spontaneously put
behind gcc or javac, not any attempt to formally classify a kind of data
conversion tool. Among associated expectations, there's this idea that the
abstraction provided by the compiler doesn't leak: you generally don't need to
know about ASM/bytecode while using GCC/javac. CS doesn't shield you from the
generated JS, and as such, it falls short of most people's expectations about
a compiler.

Looking at these expectations from a different perspective, as does Raganwald,
is very interesting.

~~~
gerggerg
When talking about compiling computer languages. It would help if we were all
using the standard definition of a compiler.

I'm glad you've got your own definition but using it only serves to confuse
the discussion.

Furthermore, your argument is weak. The only reason you don't need to be more
familiar with the technologies supporting gcc and javac is because they are
robust and much older. If you were there at the beginning of their development
you most certainly would have needed to be more familiar with their underlying
platforms. In fact many would argue you'd be a better programmer if you did
now.

Another reason your argument could be weak: Does a line number mapper between
coffeescript and its generated javascript completely nullify your argument?

At that point I wouldn't need to ever look at the generated source and would
care only about it's execution. That sounds pretty much exactly like a
"compiled" language to me.

------
radagaisus
I taught a new programmer in my department JavaScript and CoffeeScript.
Yesterday he told me he saw Notch coding a 2d version of minecraft in Java at
a hackaton online, and how weird is the difference between CoffeeScript and
Java.

Maybe for us there's nothing new in CoffeeScript. Heck, the patterns of
programming in javascript, callbacks, functional programming, prototypes,
closures, the context of this -- for him it's a lot of stuff to learn and
unlearn. Sure, I came with experience in ruby and python, so learning coffee
script was just one happy afternoon, but for him it is a language worth
learning. keep that in mind.

For me, the web is a wild beast we are training. Rails, Coffee Script, and
even more importantly - Twitter's Bootstrap are tools we use to express our
products in a higher domain language. Bootstrap gives us a common UI for the
web that is both beautiful and usable. The fact that I could strap in a day a
snappy ajax file upload with plupload into my coffee script view means I have
more time to focus on my product instead of my code. That it is less painful
to change stuff. Do you ever look at your PHP code from the old days and you
admire it? I admire it. I wrote crazy stuff back then. I wrote wrappers and
classes and 10,000 lines of utilities just so I can put up a website half the
quality of today's websites in double the time.

1\. Coffee Script is a DSL for writing damn good websites. 2\. (and imho)
Coffee Script is a great language.

~~~
malnourish
So I'm going to learn either JavaScript or CoffeeScript over January. I have
some experience in VisualBasic (took a high school programming class about
four years ago). Which one should I learn?

~~~
quanticle
Learn Javascript. Coffeescript is defined in terms of Javascript. If you don't
know Javascript, learning Coffeescript will be unnecessarily difficult,
because you'll have to go back and learn Javascript in bits and pieces as you
learn Coffeescript. If you learn Javascript first, learning Coffeescript will
be easier, because Coffeescript will build upon your Javascript knowledge.

~~~
stickfigure
To re-emphasize this point, there is no "choice" involved. You cannot
understand Coffeescript without understanding Javascript... it almost looks
like you can at first, but at soon as you start debugging you're back in "what
is this prototype thing?"

On the other hand, after you work with Javascript for a little while you
quickly start wishing for something like Coffeescript. It's a very natural
transition, but you can't short-circuit the process.

------
chc
I feel bad saying this, because I respect raganwald greatly and I usually
enjoy his writing, but this post is somewhere on the border between facile and
false. For example:

> _CoffeeScript has lots of more subtle transformations up its sleeve, like
> comprehensions, destructuring assignment, splats, or the "fat arrow" some
> rail against. Here's the secret to understand: None of these things are
> "language features" that compile from a language that has
> them—CoffeeScript—into a language that doesn't have them—JavaScript_

Well, CoffeeScript does have these features, and JavaScript really doesn't
have them. Would you describe JavaScript as a language that has them?
Destructuring assignment doesn't exist in most implementations of JavaScript.
It _will_ have that feature later on, but it doesn't now. It also doesn't have
comprehensions or splats. That's why the JavaScript that CoffeeScript
generates doesn't just use JavaScript's syntax for these features — they
aren't there. Instead, you have to do something else that gets the same
effect.

This is also ignoring bigger changes, such as the fact that everything is an
expression. That isn't true in JavaScript at all, and can't be mimicked with
anything that even vaguely resembles it. You have to do what CoffeeScript does
in the generated JS — constantly be storing intermediate values at the place
where they're produced and assigning them afterward if you want to get a value
out of most constructs (such as an if).

The two languages do correspond pretty closely, and that's intentional. But
the same is true for C and machine language. If you think that C is just a
shorthand for machine language, I guess you're welcome to your opinion, but
you're pretty lonely with that one.

Any source language can be said to be a simple transformation of its target
language, since that's what a compiler does. That doesn't mean they're the
same.

~~~
raganwald
_Any source language can be said to be a simple transformation of its target
language_

Not always. There are a number of language features that have non-local
implications, such as pattern matching, lazy evaluation, continuations, or
exceptions. If you implement such a feature on top of a language that doesn’t
have it, you will have decidedly complex transformations.

I agree that it’s overly simplistic to suggest that it isn’t a full language
if it only involves local/simple transformations, but the question of local
vs. non-local transformations at least hints at the idea that a new paradigm
or way of thinking about programming is involved.

~~~
jerf
Nit: I think pattern matching would be local the way you are using the term;
pattern matching is(/would be) implemented right at the site you use it with
some form of if/else clauses that would be verbose, but obviously related to
the original code. Your other three examples definitely involve large-scale
"non-local" source transformation all over the place to implement them.

I say this because it took me a moment to figure out how those four things
went together.

~~~
chc
Clojure's core.match is implemented as a macro with almost exactly the
technique you mention. It spits out a decision tree built out of conds.

------
ryanflorence
> Ryan Florence argues that if people use CoffeeScript to write JavaScript
> programs, maintenance will be a nightmare:

I posted that article a little prematurely and more as a rant for my co-
workers. It was a bit misunderstood (and it blew up online before I even knew
it so I didn't bother editing).

My point in that quote was that bad CoffeeScript is worse than bad JavaScript.

Good CoffeeScript is better than good JavaScript.

~~~
MatthewPhillips
> Good CoffeeScript is better than good JavaScript.

Bold statement, explanation?

~~~
ryanflorence
I find really well-written CoffeeScript easier to comprehend and scan, even
though the community at large believes I hate the stuff entirely (I don't).

I'm just not sure if it's enough to make up for a less-than-optimal debugging
experience, especially considering that most of us don't write really
excellent code all the time.

~~~
podperson
So now we need Coffeescript, The Good Parts.

~~~
yxhuvud
No, we need Coffeescript, the mature toolchain.

------
6ren
Link-bait title. It argues CoffeeScript is not a "language".

The obvious rejoinder is that new languages often evolve from design patterns:
a pattern or technique is recognized and subsumed into a language: structured
programming; object oriented etc. This is explicit in lisp DSLs, and even C++
at one stage was a bunch of C macros.

\- True, the design patterns that CoffeeScript encapsulates aren't
revolutionary - but few mainstream languages are.

\- And also, the design patterns are local (unlike, say, garbage collection) -
but so is structured programming.

There is a question of leakiness of abstraction. Ideally in a high-level
language, you are insulated from lower-level details: C is (mostly)
independent of the assembly language; VMs provide even more insulation for
Java, C#, Ruby, Python; SQL is independent of physical storage. A problem with
implementing a language with code-generation is that errors are stated in
terms of the target language instead of the source language, making them
confusing and hard to debug. But this is an implementation issue, not a
language issue. For example, errors can be stated in terms of the source
language, by including line numbers (this is also necessary for VMs).

I think the complaint is that because CoffeeScript is explicitly a JavaScript
generator that is meant to be human-readable, it doesn't make sense to clutter
it with line-numbers. It is trying to target two human user-interfaces; and it
_can't_ be a clean abstraction for both. This is a problem with the goal of
the present project, not with the language itself.

The CoffeeScript project includes a language, with syntax and semantics (which
happen to be defined in terms of JavaScript); it also includes a mapping to
JavaScript. One might therefore say "The CoffeeScript _project_ is not a
language". But the CoffeeScript language is a language.

------
Jd
Not sure why it needs the sensationalist title if the author's underlying
point is simply that Coffeescript is a pretty good tool for writing nicely
patterned Javascript and not a language in and of itself. I guess it is a
marketing ploy. I expect it will work.

~~~
raganwald
I usually write these sort of titles because they amuse me rather than in the
extreme hope of linkbaiting. I accept that writing for my own amusement has
about as much value for others as laughing at my own jokes.

~~~
Jd
It is a bit of a bait and switch, you don't let people know that you think it
is a "damn good tool" until towards the end. I'm ultimately neutral on this.
It sort of works to keep your audience engaged with your writing, but is a bit
of a cheap trick to not put all your cards on the table until the end of the
article.

Oh, and when you are writing you are almost always writing for an audience --
esp. when you tweet the result right afterwards and show up on Hacker News to
discuss it.

~~~
raganwald
I see that in addition to choosing a title that displeased you, in responding
to you I failed to make it obvious that I agreed with you somewhat. I didn’t
say I don’t write for an audience, I said that I selected the title for my own
amusement, and that it would be better in some ways to refrain from enjoying
my own little joke.

Nothing you have said is wrong.

------
derdesign
<http://core-js.org>

MVC Web Framework for NodeJS written in CoffeeScript.

This is an open source project that has just been released, and from my
experience developing it, here are my conclusions:

I believe some people are comfortable coding one way, and others are
comfortable coding another. Anyways, everybody uses what works. At the end,
the productivity you've got and the time you save is all that matters.

Regarding the issue with the stack traces and CoffeeScript, you're right, line
numbers are not accurate, but if you know where the problem is and you'll know
how to debug it, on the spot.

I was not attracted to CoffeeScript myself when I first saw it, but after
having a closer look, I finally realized it is a great tool to use when
applicable. Then I decided to migrate the whole code to CS.

From my experience, it's all about your coding workflow. Knowing CoffeeScript
syntax and how it translates to JavaScript. I use CoffeeScript's simplicity to
implement complicated concepts that would require some ellaboration when it
comes to syntax.

------
jarin
Hmm they say the same thing about haml, however haml makes my life so much
easier when writing views.

I will say that just like you should know HTML before using haml, you should
know JavaScript before using CoffeeScript.

~~~
nyrb
Ditto. They will say the same thing, you should know X before using Y.
Example:

Objective-C -> MacRuby; Slim/HAML/Jade -> HTML; SASS/LESS -> CSS and so on...

~~~
podperson
I think you meant all the examples after the first around the other way.

------
latchkey
I'm starting to feel like anyone who has a negative opinion of CoffeeScript
should prefix their statements with "I've spent the last M months writing code
in CoffeeScript for H hours a day and these are my specific issues with it."

Otherwise, these endless discussions of JavaScript vs. CoffeeScript really
aren't productive. If you haven't spent time with actual coding in it, then
you probably don't have as well formed opinion on it, compared with people who
are spending a lot of time with it.

So, I'll start with my own opinion...

I've spent the last 5 months writing code in CoffeeScript for 8-14 hours a day
for my new startup. I can't imagine being as productive with JavaScript as I
am with CoffeeScript. I write a fraction of the amount of code with CS than I
would with JS and I get to take advantage of all sorts of great features, that
would be much harder to replicate, like class hierarchy with constructors. I
really love not having to type 'function() {}' all the time and the fat arrow
really helps me with binding scope.

~~~
tjholowaychuk
you actually type function(){} ? not utilize those editors hey :p

~~~
latchkey
I type => or ->

Once you get used to not reading the auto typed 'function() {}', it really
makes your code look a lot cleaner.

------
rayiner
> None of these things are "language features" that compile from a language
> that has them—CoffeeScript—into a language that doesn't have
> them—JavaScript.

This is inane. Haskell used to compile to C. Were they not "language
features"?

~~~
raganwald
Clearly my writing is obtuse. Haskell has a language features—lazy evaluation
for example—with no equivalent in C. Nothing about lazy evaluation compiles
more-or-less 1:1 into C code, it’s a program-wide transformation.

CoffeeScript’s features are all JavaScript features, it’s a simple translation
from some shorthand into some other shorthand. CoffeeScript is like the LET
macro in ur-Scheme. Powerful, handy, but not a new paradigm, more like some
syntactic meta-programming on top of JavaScript’s existing model of programs.

~~~
jashkenas

        > CoffeeScript’s features are all JavaScript features, 
        > it’s a simple translation from some shorthand into 
        > some other shorthand.
    

This isn't entirely accurate -- in the sense that current CoffeeScript
semantics can't be implemented as a series of "find-and-replace" operations
into JavaScript. Some of the areas in which the AST transformations become
more involved are:

* Converting arbitrary statements into expressions.

* Destructuring assignment, when mixed with splats and soaks.

* Chains of soaked invocations, like:
    
    
          value = one?().two?().three?()
    

* Class bodies as blocks of executable code.

~~~
Tyr42
So there are more advanced macros that are being used. It's not doing much a
lisp couldn't do. I mean, look at scribble. It's still racket, even though it
has not an s-exp in sight.

Chains of soaked invocations are just a Maybe Monad anyways. It's nothing too
out there. You could write them in normal javascript fine.

------
ketralnis
Why does CoffeeScript have so much "debate" around it? Why don't I see
articles saying "Hey guys, stop writing in Erlang! I don't like it! Stop it!"
Why does this guy, or anybody that takes the time to write such an article,
care what I write in?

~~~
jashkenas
Although I don't believe that you finished reading the article -- that's not
what "this guy" is saying ... you are raising an extremely good question.

Part of the answer is explained by JavaScript's inherent popularity as the
language of the web -- everyone has something at stake, when JavaScript is
involved. To paraphrase myself from a similar thread last month:

Most esoteric programming languages are non-threatening. As a hypothetical
programmer working on web applications, I can feel safe and comfortable in my
ignorance of Haskell, Erlang, D, Io, Arc, and so on. They're far enough
outside of the realm of possibility of adoption for my company that I can
shrug them off with an "oh, that sounds interesting", and little more. Wanting
to adopt one of them would require a whole new development and deployment
stack, a new or ported codebase, and new integration costs with the rest of
our system. You wouldn't expect to see an article talking about how people
using Erlang are creating a "knowledge gap" for Java programmers.

CoffeeScript feels threatening precisely because it _is_ so close to
JavaScript, because the code can run with identical performance as hand-
optimized JS anywhere that JavaScript can run, because any CoffeeScript
library can interoperate seamlessly with any JavaScript library, and vice
versa. It forces you, as a reasonable JavaScript programmer, to answer the
harder question: Why should you be limited to a language that hasn't changed
(IE6/IE7) since 2001?

------
extension
Syntax matters in every way. If you think @foo is prettier than this.foo, and
you get to write the former every day instead of the latter, you will write
better code, be more productive, and love life a little bit more. Programmers
hate to admit that they like nice things, but my experience confirms it.

------
FranklinChen
I still believe that people love or hate CoffeeScript mainly because of the
differences in syntax: [http://franklinchen.com/blog/2011/11/06/the-real-
reason-for-...](http://franklinchen.com/blog/2011/11/06/the-real-reason-for-
the-coffeescript-slash-javascript-flame-war/)

~~~
wwweston
Of course they do; it's the same semantics under the hood. CS is mostly
different tokens plus some sugary shortcuts.

That doesn't mean that it's not OK to prefer it over JavaScript (or vice
versa) if you find those differences make you happier about coding in it.

~~~
FranklinChen
Exactly what I was saying in my blog post: that it's all OK, and everyone
should just get along already.

------
gkoberger
I'm not particularly sold on CoffeeScript, however this article seems to imply
we'll someday have to maintain the generated files? As long as you keep the
source near the generated files (which should be easy with version control --
you shouldn't even be checking in the generated source, in my opinion), I
don't see the problem.

~~~
nas
I'm somewhat unsure of the long term cost to benefit ratio of using
Coffeescript. You are basically getting some syntactic sugar in exchange for
the cost of learning new syntax and complicating your build and debug
procedures.

I'm trying coffee on a relatively small project with only a few developers. So
far I'm happy with the tradeoff. I keep my Coffeescript simple so the
Javascript is almost exactly what I would write by hand.

------
thackerhacker
Quite honestly the premise is rubbish.

"CoffeeScript isn't a language worth learning because it isn't a language. It
doesn't make you think about programming in a new way"

How is that a definition of a language? It compiles down to another language
sure - but what doesn't?

~~~
raganwald
In spoken languages, there is a difference between a language, a dialect, and
a specialized vocabulary. My premise is that CoffeeScript is a jargon of
JavaScript. Maybe you could say it’s a dialect of JavaScript. But my premise
is that notation alone does not make it a distinct language.

~~~
swaits
Do you think C is a dialect of Assembly?

~~~
raganwald
I can’t speak to whatever C looks like today, but when I first learned it,
absolutely positively C was a kind of portable dialect of assembly for an
idealized CPU architecture.

For example, the (in)famous equivalence between 10[p] and p[10] point to C
being a kind of translator rather than an entirely new way to think about
programs.

------
nivertech
This looks to me like a perfect definition of compiler:

 _"CoffeeScript is a program that takes some text you write using a special
set of rules and transforms it into some other text, which happens to be a
JavaScript program"_

------
jyurek
Even accepting the basic premise of the article, that CS doesn't strictly give
you anything you can't get with JS, I still don't see any of the reason
explain why I shouldn't write CS instead.

Even if there are no language features CS gives me over JS (and there are --
list comprehensions to name one), I get cleanliness. The Sapir-Whorf
hypothesis is just as relevant in programming languages as in human languages.
Equivalent JS being "possible" is not a reason to not write easier to
understand and more maintainable code with a language that lets me expend less
effort to arrive at the same place.

------
neilk
Raganwald: as much as I enjoy your writing, this condenses to a sentence. The
Apple Summarizer actually did a good job:

"And if you value making JavaScript easier to read by virtue of getting
everyone to solve the same problems the same way with the same Design
Patterns, CoffeeScript is a good tool for getting everyone else to write good
JavaScript."

Does this really deserve a full article and a bait-and-switchy headline?

~~~
raganwald
_I consistently write long essays and I lack the patience to edit them to
manageable length. More importantly, I lack the moral fibre to discard
perfectly good points. Any fool can chop filler out of an essay. It takes an
author of sterling character to discard perfectly good ideas in the interest
of making what remains an even better essay. And I lack that character. Having
written words about an idea I like, I find it very difficult to let go of
them, and my writing suffers for it._

[http://raganwald.posterous.com/why-i-downvote-tldr-
comments-...](http://raganwald.posterous.com/why-i-downvote-tldr-comments-on-
hacker-news)

~~~
neilk
Ah, I was not saying TL;DR. I don't mind long. I don't even mind Steve Yegge
long.

What bugged me about this article was the deliberate misdirection, which
seemed to me not to have any function in the article. For me it felt like it
was just to arrive at a simple point in a more complex way (and thus pad the
length out).

But there's a huge scope for misunderstanding in these things, so I apologize
for assuming too mcuh here. Maybe you thought it would be amusing to come at
it from a different angle. Maybe I read it too quickly to appreciate that.

------
manojlds
Summary: CoffeeScript is not a LANGUAGE worth learning.

~~~
mcantor
Or perhaps:

CoffeeScript is [ _not a language_ ] worth learning.

------
winteriscomming
There is a increasing trend: many people do not want to code in JavaScript.
This is happening because more and more engineers with experience in other
languages are forced to deal with JS now days and they are trying to come up
with alternate approaches.

I for one hope something succeeds, but would prefer more of a bytecode in
browser solution than transpiling to JS. One can dream.

------
krupan
He says that Coffeescript formalizes design patterns for Javascript. If you
agree with those that say design patterns highlight language deficiencies
([http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatu...](http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures)),
then the existence of Coffeescript is a significant indicator.

------
jaequery
what's wrong w/ javascript? fill me in, because i for one totally love js the
way it is.

~~~
winteriscomming
No real classes. No type systen (optional at least would be good). No
packages. No modules. No generics. No annotations, mix-ins, actors. No
properties. No interfaces. No abstract classes. Horrible to maintain on large
projects. Horrible tooling. Bad performance compared to VM or Native code. So
much more.

~~~
munificent
I'm not sure if you're a fan of Dart or not, but it has nine of those now
(classes, types, modules, generics, actors, properties, interfaces, abstract
classes, and tooling) and more on the way.

Might be worth giving it a try.

~~~
winteriscomming
Yes I like the direction dart is going in (except would prefer the type system
had more actual meaning than just annotations for tooling, but still).

My pipe dream: \- Google implements a VM for dart or equivalent.

\- Dart, Java, C#, ActionScript, Python, Ruby, whatever, can compile to this
VM.

\- VM/bytecode is initially just in chrome, which is fine as far as I am
concerned (no problem saying our app works in chrome only). You can transpile
to JS if you want to target other browsers.

\- Because of native VM implementation in chrome, the best web applications
are in chrome. Chrome increases in popularity.

\- Other vendors are forced to implement this VM.

\- We get to something like a client VM (lets call it CVM) standard for all
browsers.

\- Developer productivity improves and browser based apps start not sucking so
bad in comparison to their native brothers.

------
frankPants
I mean really, all abstraction is just taking a step further away from the
real problems and optimisations right! Let's all just write Assembler specific
to the given chip architecture we're running on. What's with all this high
level language abstraction about anyway, I think it's a fad...

------
shasta
I've always found the Perlis quote to be false. It seems to assume that
existing languages align well with how I think. A good quip only needs a grain
of truth I suppose, but for that reason I wouldn't give such a quip a
prominent place in a logical argument.

------
jbrains
I would have enjoyed the article more without the needless judgment of "not
worth learning".

------
MatthewPhillips
> You don't "Think in CoffeeScript," you "Think in JavaScript." Only you think
> in well-crafted JavaScript.

Not true, if only because CoffeeScript includes classes as a language feature.
In JavaScript it is a hack. This might change with EmcaScript.next, but for
now that creates a significantly different way to design your code.

Try writing a Batman.js app in JavaScript and you'll see what I mean. With
await/defer possibly being merged into CS, we're going to see the languages
diverge further in the future.

~~~
jacobolus
You missed the rest of the essay, wherein Raganwald described how CoffeeScript
“features” are a shorthand for common JavaScript design patterns, forcing
everyone to use the same patterns in the same way. [In other words, he
answered your specific comment at great length, rendering your criticism of
one out-of-context quotation a bit weak, eh?]

Specifically, most major JavaScript projects have some kind of class
implementation which makes inheritance, creating new classes, &c. easier. Some
of these are quite elegant, but they end up being annoying anyway, because
each system is slightly different. CoffeeScript takes one particular pattern
(which is thankfully compatible with the expectations of Google's Closure
compiler) and gives it a shorthand, so that everyone writing CS code will be
on the same page.

~~~
MatthewPhillips
Class inheritance is not a common JavaScript design pattern. It's a hack, used
by a minority of JavaScript developers, in a minority of projects.

The crux of the argument is that when you write CoffeeScript you think in
JavaScript. But I absolutely never think about overriding a parent function in
JavaScript. In CoffeeScript this is actively encouraged.

Like I said, as other ideas like await/defer become more mature (and are
merged into mainline), we're going to see the design patterns diverge futher.

~~~
jashkenas

        > But I absolutely never think about overriding a parent function 
        > in JavaScript. In CoffeeScript this is actively encouraged.
    

Unfortunately, if you never think about overriding a parent's implementation
of a function in JavaScript -- all that means is that you willfully don't use
prototypes. The famous "prototype chain", by which object-orientation in
JavaScript is accomplished, is all about overriding versions of parent
properties.

    
    
        > Class inheritance is not a common JavaScript design pattern. 
        > It's a hack, used by a minority of JavaScript developers, 
        > in a minority of projects.
    

Nope, it's deeply ingrained in all object-oriented JavaScript that uses
prototypes. What are the built-in String, Function, RegExp, Number, Array, and
Object, if not classes?

~~~
MatthewPhillips
There are a half a dozen different implementations of class inheritance in
JavaScript. However no one writing a JS library is going to ask the consumer
to extend one of their objects. This is what inheritance is all about. In Java
you extend everything. Backbone.js is the only popular JS library I can think
of which has their users use this pattern. It doesn't make since most of the
time because:

1) The use of the pattern is not common in the js community. 2) If someone
_does_ use the pattern, they might be using a different implementation.

That you can override an Object's toString is not what we're talking about
here jashkenas. We're talking about creating an Animal class and extending it
with Horse.

~~~
jashkenas

        > 1) The use of the pattern is not common in the js community. 
    

The use of prototypes is ubiquitous in the JS community. There's no two ways
about it.

Unfortunately, the avoidance of prototypes is _also_ a common anti-pattern in
the JS community, simply because JavaScript prototypes are so awkward, fragile
and verbose. Doing the wrong thing with JS prototypes is easier than doing the
right thing, which leads many developers to simply throw up their hands, and
write code like this instead:

    
    
        function makeHorse() {
          var horse = {
            walk:   function(){ ... },
            trot:   function(){ ... },
            canter: function(){ ... },
            gallop: function(){ ... }
          };
          return horse;
        };
    

... which is terribly inefficient and wasteful of memory, and accomplishes
nothing that a prototype couldn't do in a small fraction of the space and
time.

~~~
MatthewPhillips
Obviously the use of prototypes are ubiquitous in JavaScript. No one said
otherwise. The use of class inheritance, as is common in other languages, like
Java, C#, Python, and CoffeeScript is not common at all. Isn't that why you
built it into CoffeeScript, because people were doing hacks to get super?

My point is that this is leading (and other features like await/defer will do
this as well) to different design patterns. Such as Batman.js taking use of
your extends keyword for _consumers_ to implement their framework.

~~~
jashkenas
What you're calling "class inheritance" and what other folks call "the
prototype chain" are one and the same thing. It's not built-in to CoffeeScript
... it's fundamentally built-in to JavaScript.

CoffeeScript is just making it three words:

    
    
        A extends B
    

... instead of the usual JavaScript hoop jumping:

    
    
        function ctor(){
          this.constructor = A;
        }
        ctor.prototype = B.prototype;
        A.prototype = new ctor;

~~~
MatthewPhillips
Prototypal inheritance and class inheritance are not one and the same. How do
I call super or base in JavaScript?

You know this, you had to add it to CoffeeScript. Do you not think the ability
to call super functions leads to significantly different design patterns? If
not, why did you add it? And why is EmcaScript.next probably going to have it?

~~~
jashkenas
Buddy, we're going around in circles here ... Yes, JavaScript lacks a way to
easily call "super", but that doesn't mean that the concept doesn't exist.

Calling "super" means calling the immediate parent's version of the same
function. CoffeeScript is just making it one word:

    
    
        super
    

... instead of the usual JavaScript prototype hoop jumping:

    
    
        Parent.prototype.method.apply(this, arguments);

~~~
MatthewPhillips
We're going in circles because I'm talking about design patterns and you're
talking about the ability to add features into JS that weren't in mind when it
was designed; it can be a lisp if that's what you want. I'll gladly defer to
you on what JS is ultimately capable of, it was never the point of my post.
Rather my point is that the different syntax is leading to a divergence
libraries and frameworks; Batman.js is a great example of a framework that,
while you can consume it from JS, you probably wouldn't want to.

Thanks for the fun back and forth.

~~~
jacobolus
Dude, just admit you’re wrong about what kinds of patterns are natural or
common in JS and about what was “in mind” when it was created.

Here are some popular big JavaScript toolkits/frameworks: Closure Library,
YUI, Dojo, Prototype, MooTools, ExtJS, Base2, JavaScriptMVC, Backbone.

[http://closure-
library.googlecode.com/svn/docs/closure_goog_...](http://closure-
library.googlecode.com/svn/docs/closure_goog_base.js.html)

<http://yuilibrary.com/yui/docs/api/classes/Base.html>

<http://livedocs.dojotoolkit.org/dojo/declare>

<http://api.prototypejs.org/language/Class/>

<http://mootools.net/docs/core/Class/Class>

<http://docs.sencha.com/ext-js/4-0/#!/api/Ext.Base>

[http://base2.googlecode.com/svn/version/1.0.2/doc/base2.html...](http://base2.googlecode.com/svn/version/1.0.2/doc/base2.html#/doc/!base2.Base)

<http://javascriptmvc.com/docs.html#!jQuery.Class>

[http://documentcloud.github.com/backbone/docs/backbone.html#...](http://documentcloud.github.com/backbone/docs/backbone.html#section-135)

* * *

And here are some other helpful resources:

<http://www.aminutewithbrendan.com/pages/20110216>

[http://www.quora.com/How-was-classical-
inheritance-*supposed...](http://www.quora.com/How-was-classical-
inheritance-*supposed*-to-be-done-in-ECMAScript-3)

<http://www.2ality.com/2011/06/prototypes-as-classes.html>

<http://ejohn.org/blog/simple-javascript-inheritance/>

[http://my.safaribooksonline.com/book/programming/javascript/...](http://my.safaribooksonline.com/book/programming/javascript/9781449399115/code-
reuse-patterns/klass)

<http://javascript.crockford.com/prototypal.html>

<http://bolinfest.com/javascript/inheritance.php>

[http://dmitrysoshnikov.com/ecmascript/chapter-7-2-oop-
ecmasc...](http://dmitrysoshnikov.com/ecmascript/chapter-7-2-oop-ecmascript-
implementation/)

------
Void_
I find these <strike>anti</strike>-CoffeeScript articles annoying. I use
CoffeeScript, because it works for me. If it doesn't work for you, whatever,
write plain JavaScript.

This article just argues over what is and what is not a language.

~~~
adeelk
You didn’t read the article. It supports CoffeeScript.

~~~
Void_
Didn't read the whole thing, nope.

But the title says "CoffeeScript is not worth learning".

~~~
icebraining
_But the title says "CoffeeScript is not worth learning"._

No, it says "it's not a _language_ worth learning". The author's point is that
CoffeeScript is not a language, but a tool for JavaScript.

~~~
Void_
I think it's quite obvious the title is deliberately misleading to get more
people to read it.

~~~
icebraining
Sure, but that doesn't excuse people from commenting without reading it.

~~~
evoltix
The title is still misleading. It doesn't become clear that the author is
advocating CoffeeScript until the end of the article.

------
jcromartie
I don't the fact that CoffeeScript can't be debugged until browsers support
it. JavaScript errors are bad enough, but until I can get a CoffeeScript
source line number in an error I simply refuse.

~~~
erwanl
[https://github.com/playframework/Play20/wiki/AssetsCoffeeScr...](https://github.com/playframework/Play20/wiki/AssetsCoffeeScript)

~~~
jcromartie
Those are just compile errors, though. As far as I know, it's up to the
runtime host (WebKit, Firefox, etc.) to implement support for CoffeeScript
dbeugging, and that's still in the works.

------
chrismealy
tl;dr: coffeescript is ok

------
lucian303
If you can't write Javascript, get out of the biz. Coffeescript is an
abomination.

~~~
rimantas
You remind me of those 1337 HTML "hackers" advocating to write HTML in
Notepad. There are two different things knowledge and control of the code you
write and efficiency of the coding itself. I've been writing HTML for 15 years
and I always did it by hand. But never in Notepad — it is the most inefficient
way to do it. A good editor with autocompletion, snippets, syntax highlighting
will make you much more productive. The same applies to JS vs CS: CoffeeScript
does not absolve you from need to know JavaScript, it just gives a way to
write it in more productive (and fun) manner.

