CoffeeScript is not a language worth learning

https://github.com/raganwald/homoiconic/blob/master/2011/12/jargon.md#readme

by llambda • 15 years ago

218 124 15 years ago

Jd2• 15 years ago

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.

nohat• 15 years ago

Yes, I appreciate a title that conveys the author's actual point.

raganwald11• 15 years ago

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.

Jd2• 15 years ago

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.

munificent3• 15 years ago

For what it's worth, I saw the title on HN, then saw that it was a link to your githublogthing and guessed "aw, he's going to be cheeky and turn it around in the post by interpreting it literally." So I thought the title was clever.

benatkin• 15 years ago

I like the title. It's based on a quote. I think it will get people to read it, sure, but it will also get people to remember it, as well as the Perlis quote. It's also fun to guess what the contents of the article will be. Partly because I knew raganwald liked CoffeeScript all right, I solved that riddle before reading it.

gkoberger• 15 years ago

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• 15 years ago

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.

bergie2• 15 years ago

Agreed, I usually .gitignore the generated JavaScript. Though sometimes it is useful to also provide JS in the repository, so people checking out the repo can immediately have running examples.

That is what we do for example in Hallo Editor: https://github.com/bergie/hallo

thackerhacker• 15 years ago

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?

raganwald11• 15 years ago

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• 15 years ago

Do you think C is a dialect of Assembly?

robbrown451• 15 years ago

I'm curious if your opinion on this would change if they made it so the browser could run Coffescript natively. Personally, I think the fact that it compiles to an intermediate language to be irrelevant to whether Coffeescript should be considered a language.

I consider it a different language if for no other reason than, if a programmer familiar only with Javascript looked at code written in Coffeescript, they would not understand it at all. And it can't be converted to Javascript without either considerable hand work, or via an automated tool.

podperson3• 15 years ago

Surely it's much more like a grammar than a jargon, since the content essentially stays the same (symbol names, values, etc.) but the arrangements change.

In general, langages don't tend to have multiple grammars (although spoke languages tend to be looser than written), and perhaps the unnaturalness of having a second grammar might undermine your position.

gcp3• 15 years ago

The intrinsic quirks and behavior of CoffeeScript and JavaScript are the same. You cannot think of CoffeeScript as a kind of Python. It's a better (but with caveats) syntax for JavaScript.

There's a 1-1 mapping of CoffeeScript syntax to JavaScript syntax. This is really useful when you are debugging. But it cannot introduce much useful new behavior.

That's why I'd agree its more appropriate to see CoffeeScript as a new syntax for JavaScript, than as a new programming language.

chrismealy• 15 years ago

tl;dr: coffeescript is ok

ryanflorence2• 15 years ago

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

raganwald11• 15 years ago

Updated. I hope this reflects your feelings properly. If not, I’m willing to remove your name and link, I don’t want to misrepresent your concerns.

MatthewPhillips7• 15 years ago

> Good CoffeeScript is better than good JavaScript.

Bold statement, explanation?

tjholowaychuk4• 15 years ago

major fail

ryanflorence2• 15 years ago

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.

FranklinChen2• 15 years ago

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

wwweston2• 15 years ago

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.

FranklinChen2• 15 years ago

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

MatthewPhillips7• 15 years ago

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

jacobolus3• 15 years ago

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.

MatthewPhillips7• 15 years ago

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.

fab13n2• 15 years ago

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.

gerggerg2• 15 years ago

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

fab13n2• 15 years ago

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

obtu• 15 years ago

The technical term for what CoffeeScript is doing — a compiler that doesn't need a global view of the program and does local source transformations — is a transpiler.

rbxbx• 15 years ago

>> it's an accretion of rewriting tricks

I think you'll find this point of contention won't work against raganwald: https://github.com/raganwald/rewrite_rails

jashkenas7• 15 years ago

For the curious, check out fab13n's initial work towards one such refactoring / implementation, here:

https://github.com/fab13n/parsec-coffee-script

davesims• 15 years ago

"There ought to be one obviously best way to do each thing, for the sake of maintenance and readability."

In what way does a constriction of convention relate to readability or maintainability? The languages I'm most productive in have many ways to write readable code that accomplishes basically or exactly the same thing. I've always considered it a mark of a language's elegance and power that there would emerge multiple ways of expressing the same problem. But maybe we're thinking about different scopes here. Can you give an example?

Fluxx• 15 years ago

> Now, if we consider CS as a presentation layer for JS, then its proper place is in an IDE, not as a compiler

I disagree. Forcing programmers to use a certain IDE to accomplish productivity gains is a bad road to go down. It discourages innovation, stifles competition and makes it hard to integrate the "compilation" in to other parts of your development cycle.

radagaisus2• 15 years ago

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• 15 years ago

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?

DanHulton• 15 years ago

JavaScript, easily.

I'm a huge, huge fan of CoffeeScript, but JS will be far more useful to you right away, and your knowledge of JS will help you understand CS more when you learn it later.

quanticle• 15 years ago

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.

dpritchett• 15 years ago

JS first, and be sure to use this excellent guide: http://eloquentjavascript.net

It really covers the how and why of JS in a way that will make your understanding sharper.

debaserab2• 15 years ago

Interesting that you point out Twitter Bootstrap -- which to me is becoming the great equalizer for new product/startup websites and a hallmark of lack of creativity or any sign of thoughtful design. Sure, the UI is great, much like the design patterns that Coffee script creates -- but what it signifies is a "dumbing down" of design much like Coffee script does to it's programmers.

In Java, good design patterns are defined and publicized, but it's up to the programmer to implement the design pattern, not the compiler. It's that sort of freedom that I feel is necessary for anything truly creative and innovative to be created.

radagaisus2• 15 years ago

Creativity is awesome. not in the UI. For me it means less time focusing on my product and more on remembering to make button:active look like it's pressed. for my users it means another UI to learn.

Think about trello. After two minutes on the site I was like "hellll no, I ain't gonna learn how to use this!". The UI scared me, it was too different with too little explanations.

manojlds• 15 years ago

Summary: CoffeeScript is not a LANGUAGE worth learning.

mcantor• 15 years ago

Or perhaps:

CoffeeScript is [not a language] worth learning.

jaequery• 15 years ago

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

gcp3• 15 years ago

Do you know and use other languages? Given that this is about CoffeeScript, an obvious criticism about JavaScript would be: it's not a faster Python.

winteriscomming3• 15 years ago

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.

munificent3• 15 years ago

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.

tikhonj• 15 years ago

Both the classes and type system are not inherently obvious: there are plenty of valid arguments for both prototype-based OO and dynamically typed languages. I personally like prototypes more than classes and am ambivalent about static/dynamic typing.

JavaScript does have packages and modules--check out CommonJS, for example. There are some issues with them in the browser, but that's a different story.

Generics and interfaces make no sense in a dynamically typed language. Abstract classes don't really make that much sense with a dynamic type system either, and they make no sense with prototype-based inheritance. Mix-ins don't make really fit into a prototype-based language either.

Properties would be nice. I don't know about tooling--js2 mode on Emacs is infinitely better than any IDE I've ever used (and I've use a bunch). I've never had issues managing JavaScript code--less issues than Java, for example--but I've never worked on anything particularly big.

JavaScript performance is now quite good. Besides, performance is not a function of the language but a function of the implementation. You wouldn't think of Scheme as a particularly fast language, but I remember recently reading about Stalin Scheme which made it as fast or faster than C.

Really, most of your arguments seem to stem from not liking prototypes and dynamic typing--these are just preferences. Complaints about JavaScript's lacking interfaces are like complaining your Tesla doesn't have a gearbox.

Your argument really makes it seem you would like nothing more than Java/C# in the browser; I personally would like little less than that. This is probably at least partly due to the name: JavaScript makes it seem like the language is akin to Java when it really only shares a superficial resemblance.

justncase80• 15 years ago

Here's a visual response: http://d24w6bsrhbeh9d.cloudfront.net/photo/31723_460s.jpg

chc2• 15 years ago

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.

raganwald11• 15 years ago

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• 15 years ago

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.

scott_s2• 15 years ago

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.

Which is an excellent point, and I think the essay would have been better served if you had oriented it that way, and not around the "not a language worth learning" hook.

jarin• 15 years ago

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• 15 years ago

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

podperson3• 15 years ago

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

nivertech• 15 years ago

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"

rayiner• 15 years ago

> 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"?

raganwald11• 15 years ago

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.

jashkenas7• 15 years ago

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

ori_b• 15 years ago

Haskell wasn't simply sugaring the regular C design patterns. The C that the compiler generated was nothing like the C that you would normally write.

A better example would be Objective C compiling to C. And I would agree that early Objective C wasn't really a language that added new paradigms to C. It sugared good coding practices for the most part, and did little else. As a result, I generally recommended a combination of the K&R book and the ObjC language spec to learn it -- buying books for ObjC was a waste of time, since it was such a thin wrapper around C.

Coffeescript is in a similar position.

blasdel• 15 years ago

Coffeescript doesn't even have its own standard library, much less a runtime being cross-compiled with its own garbage collector and stack frame constructs.

jyurek• 15 years ago

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.

derdesign• 15 years ago

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.

winteriscomming3• 15 years ago

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• 15 years ago

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...), then the existence of Coffeescript is a significant indicator.

Void_3• 15 years ago

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• 15 years ago

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

Void_3• 15 years ago

Didn't read the whole thing, nope.

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

extension• 15 years ago

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.

shasta• 15 years ago

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.

neilk2• 15 years ago

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?

raganwald11• 15 years ago

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

neilk2• 15 years ago

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.

6ren• 15 years ago

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.

ketralnis• 15 years ago

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?

raganwald11• 15 years ago

I personally write stuff like this because the act of writing out my thoughts forces me to think them through clearly. In this case, I actually do agree that CoffeeScript is a “little” language, but writing an essay in this form was an exercise in clarifying what is and isn’t a language and what that means.

Other reasons for writing essays to convince people to use or not use a language like CoffeeScript might include a very natural desire to get lots of people using the tools you prefer. If you prefer JS, but everyone else write cool stuff (like Katy!) in CS, you will be annoyed trying to read their code or step through it in your debugger.

Conversely, if you prefer CS, getting momentum behind it ensures its future and increases the probability you will still be able to use it in the future.

I can certainly appreciate why people might want to evangelize either position. For me, it was an exercise in taking an interesting position—that it’s about the JavaScript it generates not the grammar or syntax—and see if I could make a credible argument.

jashkenas7• 15 years ago

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?

lucian303• 15 years ago

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

rimantas2• 15 years ago

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.

latchkey2• 15 years ago

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.

tjholowaychuk4• 15 years ago

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

latchkey2• 15 years ago

I type => or ->

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

wwweston2• 15 years ago

"I've spent the last M months writing code in CoffeeScript for H hours a day and these are my specific issues with it."

Only if we add months spent writing in JavaScript N hours a day too. Bonus for Python and Ruby.

frankPants• 15 years ago

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

jcromartie2• 15 years ago

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• 15 years ago

https://github.com/playframework/Play20/wiki/AssetsCoffeeScr...

jcromartie2• 15 years ago

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.

jbrains• 15 years ago

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

CoffeeScript is not a language worth learning

Related Stories