Hacker News Reader

Comment by jherdman | Hacker News Reader

I can't shake the feeling that people that like CoffeeScript are those that don't "get" JavaScript (e.g. CoffeeScript's notion of a class, whereas JavaScript has none -- let go an embrace the prototypal object model). Further, most (if not all) of the examples of the problems with JavaScript are null and void. A language that combines paradigms? Most do. Sure, the name sucks, but that's hardly an issue.

I understand that syntax may be more convenient for some, but this is indirection, and is a source of complexity that may impede collaboration from other devs more familiar with JavaScript.

View on HN

I think the opposite: people you get CoffeeScript are more likely those who really get JavaScript. It's turning JavaScript into the language it was supposed to before before the marketers got their hands on it and "javafied it".

In fact, Brendan Eich has taken a bunch of it's features and they will be included in the next version of JS (woot!): http://brendaneich.com/2011/01/harmony-of-my-dreams/

http://www.aminutewithbrendan.com/pages/20110131

Perhaps this isn't the best forum for such a philosophical debate, but the notion that because you have prototypes in JavaScript you don't have classes is just plain wrong.

Every single time you see JavaScript prototypes used effectively, you'll find that they follow a classical pattern: A constructor function serves as the class object from which new objects are instantiated. Syntax like instanceof ("object instanceof class") gives this away. So do all of the built-in JavaScript classes: String, Function, RegExp, Number...

If it's an abstract object that defines common properties for instances, it's a class object, regardless of what you choose to call it. JS prototypes just expose the implementation mechanism, and CoffeeScript just provides you with a convenient way to manipulate the prototype chain.

I prefer coffeescript for the reduced line noise, particularly around lambdas, loops/comprehensions, and object literals. I find the shorter lines and reduced line count* allows me to notice api flaws more easily, so I tend to do my api design in cs. I generally don't use the class construct unless the library I'm working with uses the same pattern (e.g. yui3). It's pretty much just syntactic sugar that simplifies the code at the expense of complicating the toolchain. I think it's worth it but I've met plenty of people who don't.

* In js->cs rewrites I usually wind up cutting the line count in half, but most of that is eliminating all the stray closing brackets on their own lines and collapsing if statements into single lines.

CoffeeScript is javascript so prototypal objects still work as expected. They just went ahead and threw in classes if you want them, since there are already many javascript libraries that provide them for people who either are used to / want classes or to make it easier to port existing code.

coffescript !== javascript, and it never will === javascript.

Please elaborate. It's easy to match generated Javascript to it's corresponding CoffeeScript source. There's a lot of syntactical sugar, but there isn't much that isn't just a handy shortcut. I used something kinda like CS's class system in JS before I even discovered CS.

I have to say that by using cs I learned a lot more about js. Maybe for old js cats it doesnt matter, but I only used js occasionally before, and now it became one of my favorite languages (I use with node, and I write all my node stuff in cs).

One particular example that changed everything for me was the natural and simple way I could build the typical callback constructs with -> and => , so they almost look like blocks in ruby, and feel way more natural as a control construct, and I didnt have to stack lots of })}); and so on.

If you're rather new to something, the ease of use and the simplicity and readability speeden up the learning process extremely.

That being said, there are also a couple of things in cs that are kind of silly.. like using 'for i in my_array', but 'for k of my_dict', and stuff like that, that are really hard to debug.

Although, in terms of debugging, the fact that it gets compiled and possible errors are early detected and a canonical js is generated also saved me lot of time, in particular with IE ;-)

To explain the reason for the "in/of" distinction...

"for item in list" vs "for key, value of object" is an unfortunate necessary evil. It would be great to use the same keyword, "in", for both types of loop, but I'm afraid there's no way for us to know at compile time if "list" or "object" is really an array, or really an object.

I'm curious, why do you need to make a distinction? Is there some other feature of CS that depends on it? Certainly 'for key, value of array' could be implemented with numerical keys. If using just 'for value of dict' is allowed that would also work fine.

We need to make a distinction because we want to have arrays be iterated over with:

    for (var i = 0, l = list.length; i < l; i++) { ... }

And objects iterated over with:

    for (var key in object) { ... }

Using a "for-in" loop over a JS array isn't acceptable, for performance and semantics reasons, and neither is sniffing at runtime to determine whether the object passed is an array, or an object.

Ideally, JavaScript would have supported a single iteration protocol for both arrays and objects from the get-go, but alas...

The fact that cs is doing this 'the right way', meaning safe for all environments, as you have explained below, is one of the reasons I like it.

I'm new to programming and learned a little bit of javascript lately. I'm going to do a mini project on Node just to give myself an excuse to learn more programming.

If you dont mind my asking, how would i go about using CoffeeScript with Node?

If you build those simple 1-file-testservers with node, simply write them in coffee and then start them like "coffee myserver.coffee".

If it's more elaborated, you might want to set up some kind of build process and then use the generated js files. You could use a simple Makefile and compile your coffee files with coffee -c -b.

I'll try that. Thanks!

Oh, i forgot: You can add the --watch switch and get your scripts compiled on save.

I'm personally of the opinion that prototype-based systems are superior to class-based systems in exactly the same way that gotos are superior to for loops.

Add to this the fact that JavaScript's prototype system isn't actually very flexible, and you're almost always better off to roll a class-based system on top of it.

I don't think many use CoffeeScript because they don't "get" JavaScript. I think they use CoffeeScript because it gives them a much better JavaScript and makes them more productive and "happy".

I don't agree with your opinion at all. Your claim that coffeescript is somehow 'better' than javascript is just false. You prefer one syntax, fine, but don't assume that it is somehow 'better'. I prefer Javascript. I do not prefer Coffeescript at all, and I get javascript, and have gotten it for 14 years.

When targeting Node, one runtime and ES5, vanilla JS isn't so bad. Writing JS for browsers is painful, and CS addresses a lot of those pains.

A function that does nothing useful but illustrates some pain points:

  function frob(obj) {
    var rest = [].slice.call(arguments, 1)
      , results = []
    for (var k in obj) if (obj.hasOwnProperty(k)) {
      v = obj[k]
      if (blurgh(v, rest)) {
        results.push(v)
      }
    }
    return results
  }

This is roughly the same function in CS:

  frob = (obj, rest...) -> [v for v of obj if blurgh(v, rest)]

That's at least 5x more expressive. And it works in browsers, node, and pretty much every other JS environment. I don't write CS but you have to be blind to deny its benefits.

edited: Fixed the CS to iterate over keys of obj using 'of' based on other comments here

Couple of small issues. You probably want "when" instead of "if". The if applies to the whole loop, not to each element. Also, the braces around the comprehension is a pythonism I guess? It means it puts the result into an array, so you get [[<stuff>]] instead of just [<stuff>]. I've made that same mistake a bunch of times.

Nitpicking aside, I totally agree about the expressiveness. I find myself writing about half the number of lines in CS as compared to JS, and the syntax fits my brain better.

Thanks, I was hoping someone would point out the mistakes. Since I can't edit my previous comment:

  frob = (obj, rest...) -> v for v of obj when blurgh(v, rest)

edit: parens dropped for noise reduction

A minor style point, but you can drop the parentheses here. They're only needed when you're assigning the result of the comprehension since = has a higher precedence. I go back and forth on whether it's better to remember this or to just put parens all the time.

The parentheses thing is the one thing that bugs me a bit about the CS syntax, but mostly when dealing with calling functions. I wouldn't mind omitting the parentheses around function arguments if I could be consistent about it. Seems like there are some cases where parentheses are necessary to make sure args go with the right function.

I'm wondering why I find this so annoying though. It's not like I complain about having to put parentheses in math to make sure stuff is evaluated with the precedence I want.

The way I think of it is "is this function call (including arguments) the last item on the line". If the answer is yes, you can drop the parens otherwise you have to keep them. E.g.

      foo bar baz 2    # is foo(bar(baz(2)))
      foo bar baz(), 2 # is foo(bar(baz(),2))
      foo bar().baz 2  # is foo(bar().baz(2))

In every case, the foo is the last item on the line. In the second there's an argument after the call to baz() so it's not the last thing on the line and needs parens. In the third, baz is being chained off bar so bar is not the last thing on the line and needs parens. In general I'd do all the parens except maybe the ones for foo in the second and third cases simply because it takes a minute to figure out where the calls get split when you re-read the code.

I tend to drop the call parens in situations the following:

    # DSLish things
    task 'foo', depends: ['bar']

    # Callback/lambda taking things
    xhr_get url, ->
         stop_animation()

That actually covers a fairly wide set of use cases for me since I tend to write DSLish/callback code but for things like `add(2,2)` I write in the parens regardless of position.

> I can't shake the feeling that people that like CoffeeScript are those that don't "get" JavaScript

I disagree with this (though I agree with the rest of your post). The people that like CoffeeScript (and StratifiedJS and other projects like ObjectiveJ) are generally people that do get JavaScript really well. They just want to make it better.

The problem with CoffeeScript and the others is that they are not JavaScript. CoffeeScript is pretty straightforward in that it hardly even looks like JS and just compiles down to it, but others pretend to be JS but introduce new structures that make them all completely different languages (and do source transformation using JS in the browser).

If you don't know the transformations and you don't know JS very well, all these languages on top of JS will leave you stranded the second something goes wrong anywhere in the stack.

I'd like to see JS adopt some core structures for concurrency, namespaces and more CommonJS stuff instead of adding let, generators and comprehensions - which are nice, but mostly just fluff because you can do all those using the core language already and they're details nobody really cares about.

Chris Okasaki has some high praise for languages implementing indentation as part of the syntax http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-i...

Personally I think Coffeescript is a big step forward. A pity it will likely never gain enough momentum to see native implementations on the major browsers.

"Native implementations on the major browsers" will only harm coffeescript, since we'll never see rapid development and evolution of the language and maybe have to deal with the implementation incompatibility in different browsers.

> let go an embrace the prototypal object model

JavaScript itself doesn't embrace a prototypal model. When was the last time you cloned an object to create a new one in JS?

JavaScript's model is much closer to classes than prototypes. The only real significant difference is that unlike class systems, JavaScript allows inheriting both "methods" and "state" from its "class". Otherwise, the language works more or less like a class-based one.

    Sure, the name sucks, but that's hardly an issue.

Sure, as long as you already understand Javascript. Think of people who are learning, or middle managers that are hiring. It's a lot more of a thorn than you might think, because you're educated.

Is your only basis for feeling that people that like CoffeeScript don't "get" JavaScript the `class` syntax? If that's the case, it's a minor feature of CoffeeScript. I'd say the rest of the features it offers fall on the dynamic/functional side of things more than the strong+static typed/classical OOP side ( list comprehensions, splats, treating everything as an exression, etc.).

I agree with everything you are saying. Coffeescript really is for people who prefer a ruby/python syntax, and who just don't like javascript's syntax.

BEATUY IS IN THE EYE OF THE BEHOLDER people! Just because you find javascript 'ugly' and coffeescript 'beautiful' doesn't actually mean everyone agrees with you. I think Javascript is beautiful and I've been coding it for 14 years. I have no need to replace the syntax, or complicate my development tools, or make debugging any more complicated that it already is.

Coffeescript evangelists are like born-agains who try to convert every man woman or child to their newfound religion because their god is the true god. It's annoying really.

Who said everyone has to agree? If you don't like coffee script, don't use it.

It's that simple.

Reply on news.ycombinator.com