My Perception of CoffeeScript

http://leongersing.tumblr.com/post/11561298378/my-perception-of-coffeescript

by activestylus • 14 years ago

82 55 14 years ago

leongersing.tumblr.com

tinutinu• 14 years ago

'I agree with this' is not same as 'objective and balanced'.

True that - I actually disagree with his final conclusion, because you can still program functionally in CS. I embraced JS prototypes a long time ago and have no need for the OO magic offered by CS. That said I still prefer it for a good chunk of my development.

Coffee vs JS rants typically degenerate into emotional outbursts, I was impressed by the author's overall restraint and advocacy for both approaches

to3m• 14 years ago

I assumed this was some kind of dry humour. Language comparisons are rarely objective and balanced.

blrblr• 14 years ago

It makes more sense for CoffeeScript to exists as an independent language, rather than as a JavaScript generator.

The syntax is beautiful, it had potential; why be a difficult-to-debug JavaScript 'compiler' instead?

daveid• 14 years ago

Sorry, but wouldn't that defy the purpose? You can only use JavaScript client-side, and I assume it would take a lot of time, effort, and "why" to make browsers ship parsers for other languages.

boothead• 14 years ago

I'd hardly characterise coffeescript generated js as difficult to debug (even the OO flavoured bits). My experience and that of most others I've seen online is that the mapping from the js that you debug back to the coffeescript that generated is trivially done in your head.

MrUnknown• 14 years ago

As someone who barely knows any JavaScript, but want to learn CoffeeScript (I know ruby, and they are similar), even I can do this.

rimantas• 14 years ago

I'd say this "difficult-to-debug" attitude comes from those who did not actually tried to work with CoffeeScript and just think that would be the case. We have a lot of code in it already and debugging was never an issue.

base6982• 14 years ago

+1 here too.

gmac• 14 years ago

The author has 3 main gripes: backticks to drop back to JS, the 'class' keyword, and the fat ('this'-preserving) arrow.

But these are all features you can blithely ignore: don't use backticks, and stick to native JS prototypes and the thin arrow.

At which point you're left with, from where I'm sitting, a less noisy, more concise, more enjoyable way to program the web browser than plain JS.

activestylus4• 14 years ago

Well stated, and I agree 100% it is a sort of blindspot for this article. That said I agree with him on a level that CS does encourage a sort of OO band-aid approach towards functional programming and will definitely impede newcomers from embracing the power that comes with the built-in paradigm. I feel that it should not be in core, but am happy as you are to simply use what works and ignore what doesnt

oscilloscope• 14 years ago

Synapse creates a non-trivial Class:

https://github.com/bruth/synapse/blob/master/src/synapse.cof...

Here's the documentation, to get some context:

http://bruth.github.com/synapse/docs/#learn

Do you feel that this code would be significantly improved by using JavaScript's bare prototype pattern instead?

raganwald3• 14 years ago

these are all features you can blithely ignore: don't use backticks, and stick to native JS prototypes and the thin arrow.

Without taking a personal stance on these features, I suggest that “You can ignore Language Feature X” is often a weak argument. If you feel X is harmful, not only must you ignore it, but you must consider all of the other developers, maintainers, and so forth who interact with your code.

You personally may not use X, but what about your team mates?

Your team (of 1+) may not use X, but do you ever have to debug modules or plugins written with X?

If you really think X is a terrible idea, it’s in your best interests to discourage its existence, not just ignore it :-)

stcredzero4• 14 years ago

There are tools that can cover this.

You personally may not use X, but what about your team mates?

Team leads should tell team members to use automated tools for coding standards. This takes care of most of this.

Your team (of 1+) may not use X, but do you ever have to debug modules or plugins written with X?

The Node.js community has a way of dealing with non evented-friendly code. Programming as a whole would probably benefit from more things like this.

dxbydt4• 14 years ago

Frankly his main gripe is that JS = FP, CoffeeScript = OO.

The 3 gripes you point out are mostly a consequence of Coffee choosing to do OO instead of FP & then needing hooks into JS's world to achieve this end. From the article - "CoffeeScript sees the world through OO’s eyes. When I see JavaScript, I find beauty in it’s ability to be a dynamically typed Functional programming language."

His example is known by various other names, most commonly http://www.google.com/search?q=lots+of+little+objects

He wants just 2 "objects" ( he more specifically wants unstructured objects, or plain structs ) - sammy the python & tommy the horse. Functional JS gives him just those 2. But OO CoffeeScript gives you 5, or even 6 if you count hasProp.( var Animal, Horse, Snake, sam, tom, __hasProp. )

The more dramatic way to document this behavior is to have say 100 cats & 500 rats, whoe identity is captured in an int. With FP you'll be able to happily get away with just 2 "objects" - 1 cat and 1 rat ! The int indexing will happen via a function call. With OO you will have 600 little objects plus a bunch more for the classes and the hasProp !!

Here's another one I've seen - If you get two programmers to write a paddleball - one in functional JS, and the other using Coffee OO. The Coffee one will lag pretty soon. The Coffee guy will have a Ball object & a Brick object & a Wall object & each gesture will get captured as an object as well. So when the player moves the arrow keys to move the paddle, each move's x,y coordinates will become a gesture object & then gestures are passed to the ball & the wall to determine collisions....soon you'll have 1000s of gestures & the pgm will slow down unpredictably as the gc kicks in. The functional JS guy won't create a single gesture object, he'll simply call some collision detection function directly with the x & y, so you'll see much better performance.

Ofcourse the coffee OO code will look a lot prettier than the FP one littered with curlies & function calls, but like the author says, "JavaScript’s function keyword and curly brackets aren’t ugly to me, they are useful indicators of code smells."

So pick your poison.

oinksoft2• 14 years ago

I am not a fan of CoffeeScript for my own reasons (it doesn't offer enough for me to drop drop JS), but there is nothing stopping the author from writing his CS like so:

  move = (aDistanceOf) ->
    it = @name or "It"
    alert arguments[1] if arguments[1]
    "#{it} moved #{aDistanceOf} meters"
  
  snake =
     name: "Sammy"
  horse =
     name: "Tommy"
  
  move.call snake, 5, "Slitering"
  move.call horse, 45, "Galloping"

But really, this is just JS wearing some new clothes. The string interpolation is nice, but apart from that, you really gain nothing over the JS version.

pfraze• 14 years ago

I'd add also that Javascript proto inheritance is more about composition than type checking, since `instanceof` has its frames problem [1].

As a result, I'm increasingly inclined to do data-structure objects and composable functions, which seems similar to Go's approach.

1 http://perfectionkills.com/instanceof-considered-harmful-or-...

Confusion• 14 years ago

Closures are a poor man's objects.

Objects are a poor man's closures.

Source: http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent. Be sure to click through to the original source thread. It's a fascinating discussion.

lucian1900• 14 years ago

CoffeeScript's classes are the extend functionality in underscore/backbone. Perhaps they're misnamed a little, but they're extremely simple. Just read the generated code.

cmwelsh• 14 years ago

This is my favorite reply, because it's exactly right. No one is stopping you from mixing and matching paradigms either! You can extend CoffeeScript classes with extra mixins.

I think CoffeeScript's class keyword does a great job at what it's trying to do: make all the complexities of prototypical inheritance accessible to the average person who just wants simple object-oriented classes. CoffeeScript is just JavaScript.

smoyer3• 14 years ago

And the next technical book to be published? ... "Coffeescript - The Good Parts"

On a more serious note, I love Coffeescript and am adept at Javascript. But since we have both of them, I get to choose.

wwweston• 14 years ago

Then we can move on to inventing EspressoScript: It's the Good Parts of CoffeeScript, and not the bad!

smoyer3• 14 years ago

Which will of course be forked to LatteScript, CappacinoScript and MachiatoScript. Real non-conformists will insist on TeaScript (or its fork - ChaiScript). After years of infighting, the industry will finally get behind a standard based on the least common denominator - CaffeineScript which will prompty be sued out of existence by the Caffeine JVM (overlay on .NET?).

By then, young developers will be so disillusioned with the whole process that they'll invent something totally different ... and who can blame them ;) Due to the vocal nature of its supporters, RubyRedGrapefruitScript becomes the default scripting language available in modern browsers.

I'm glad I know assembly language ... I can always go back to the beginning ;)

stcredzero4• 14 years ago

It’s not the that Object modeling metaphor used in CoffeeScript is bad, it’s just overly object-oriented and builds on OO style inheritance.

There are lots of people who don't even include inheritance in their definitions of OO.

jashkenas4• 14 years ago

This essay is fairly amazing -- there's so much emotion and so many assertions packed into it, and yet they're all founded on innuendo and hearsay, not on how things actually are. Most of the things Leon writes are factually incorrect, but at the same time, you can see how listening to enough FUD might make you start to think them...

For example:

    > CoffeeScript classes have attributes and properties that 
    > are encouraged to be mutated by reference so a language 
    > contrivance was devised (@) to allow OO style encapsulation 
    > while still trying to provide Functional referential 
    > transparency in anonymous contexts… wrap your head around that.

What? Instances of CoffeeScript classes are just like any other JavaScript object with a prototype -- just like any old string or function or array. The "language contrivance" `@` symbol is simply an alias for `this`. Nothing more and nothing less. `@name` in CoffeeScript is just `this.name` in JavaScript -- I'm not sure how you wind up with "functional referential transparency in anonymous contexts" from there ... but I'll have a little of whatever Leon's smoking ;)

There's many other things in the essay, but the core boils down to this: There are a bunch of folks who are used to ignoring prototypes in JavaScript because they hand-roll objects by manually adding properties or using Crockford's "module pattern". For them, CoffeeScript's `class` keyword feels like it's adding something alien to JavaScript because it makes prototypes accessible. It's not. Using prototypes and objects lies at the core of JavaScript, and it's only the difficult and fragile syntax that leads people to manufacture new instances like this:

    var makeDog = function() {
      return {
        bark: function(){},
        run: function(){},
        ...
      };
    };

Instead of the far more efficient:

    new Dog;

Finally, CoffeeScript isn't encouraging you to do anything in particular. If you truly don't like using prototypes in JS, feel free not to use `class` in CS.

    > Jeremy Ashkenas, whom I do not know but would 
    > LOVE to have a drink with (alcoholic drink or 
    > otherwise) and pick his brain ...

Ping me the next time you're in NYC. Always happy to grab a drink and talk shop.

activestylus4• 14 years ago

Nice to have you chime in here Jeremy. I personally use CoffeeScript a lot. I also code in Ruby and understand its appeal from that perspective. However I am curious what your take is on dxbydt's reply below. He makes a very interesting comment about the overhead of objects vs simple message passing/currying/etc.

jashkenas4• 14 years ago

My take is that it's a classic straw man -- you can write inefficient functional code that constantly manufactures and throws away closures ... just as easily as you can write inefficient object-oriented code that constantly manufactures and throws away objects.

The point of object-orientation is that "simple message passing/currying/etc" rarely stays simple for long. Eventually your system wants to have many different pieces of data that all share common functionality, and objects are a great way to model that. But if you prefer to work procedurally, and have a big data structure and a bunch of little functions that operate on it -- that's fine too. CoffeeScript and JavaScript support both.

danso2• 14 years ago

Did HN's "no editorializing the original title" policy change, or does it go absent on Fridays? How did "My Perception of CoffeeScript" get changed to "Finally, an objective and balanced look at Coffeescript vs Javascript"?

Groxx• 14 years ago

Woo, it has been fixed. I was going to suggest flagging it for that reason :|

_ouxp• 14 years ago

Might be worth noting that this post is 8 months old.

nathansobo• 14 years ago

This post doesn't make much sense to me either. JavaScript encourages an object-oriented style, but with prototype-inheritance and flexible method binding (where `this` in a function is determined by the caller). CoffeeScript's features embrace both of these design choices and make them easier to use. Using the `class` keyword to set up a prototype chain is really nice, and `@` opens up whole new possibilities that would have been too syntactically heavy with the `this` keyword.

JS is object-oriented. If you really want to write functional code in JS, you're going to need persistent data structures, like Clojure (and presumably ClojureScript) provide. Otherwise you'll pay a high cost for constantly copying objects. Without persistent data structures you pretty much need to mutate properties to remain performant. And if you're mutating properties, object-oriented code is a good approach.

I don't understand why the author sees randomly assigning functions to anonymous objects as a superior approach to using prototypes.

rstacruz• 14 years ago

Hey Jeremy! On a totally unrelated note, if I only have 48 hours to spend in New York city, what would you suggest I visit?

lazerwalker• 14 years ago

> If you’re a fan of OO you’re going to love CoffeeScript from day one, guaranteed. If you’ve never tried to see the world through Functional glasses then I assert that you’re going to be missing out on a few beautiful vistas.

I feel like he's not using the same CoffeeScript I am. Yes, it does make OO-style programming easier than vanilla JS, but it also makes functional programming a heck of a lot more accessible. The terser function creation syntax and the 'everything is an expression' mindset might appear at first glance to be minor improvements, but they add up to a language where working in a functional paradigm is a lot more enjoyable than regular JS.

base6982• 14 years ago

Not to mention it's based on underscore and has almost all the Lisp functions baked in. That coupled with less verbose function syntax and it's an FP programmers wet dream :)

nilliams• 14 years ago

Absolutely agree fp looks and feels great in CoffeeScript.

LeonidasXIV• 14 years ago

I have to agree with you here. Since using CS my code got far more functional because I could create functions that create functions really easy and the implicit returns make it feel like a functional language.

danso2• 14 years ago

This may sound pedantic, but I wish that these type of technical screeds were created with the flexibility/power of online publishing in mind.

There needs to be more thought given to the use of non-prose in communicating these things. More tables, a la Ed Tufte's principle of direct comparison and small multiples, is a huge help. At the very least, it helps break up dense text and forces the author to be more aware of how to best not bury important statements and assertions.

But if you aren't going to go all-in and use tables/graphics because it's a bit of work...then at least use headings, bulleted lists, formatted-text...this is the web, after all.

Or, if you don't even want to do that, at least use line breaks like everyone learns about.

And if you plan on including code, please use a wide enough format (and of course, syntax highlighting, though that is additional overhead).

I don't mean to belittle this author's point on the basis of visual cues alone. It's just that I see a lot of great essays that could be so much more influential and effective with just some additional effort put into presentation.

My Perception of CoffeeScript

Related Stories