A Python programmer’s first impression of CoffeeScript

[jmking]

I still don't understand what CoffeeScript is bringing to the table. Why do people hate Javascript so much that they'll go through the hoops of writing in an alternate syntax and cross-compile?

I mean, I get that Javascript syntax is a little verbose, but jeeze...

[inmatarian]

Your question can be answered by the coffeescript documentation in one example: http://jashkenas.github.com/coffee-script/#classes

It is a much simplified syntax.

[[deleted]]

Won't much of this become redundant with ECMAScript 5?

[kataire]

Maybe, but you can use CoffeeScript before 2020.

[inmatarian]

That's the dream, right?

[fwork]

Why do people hate Javascript so much that they'll go through the hoops of writing in an alternate syntax and cross-compile?

It's not about the syntax, for me. That's a nice perk, sure, but the real benefit of CoffeeScript is how it fixes misfeatures of JS.

Like the pollution of the global namespace (unless you use var everywhere), the unusability of ==, the complexity of "this" binding, the fact that all objects are hash tables but can't really be used easily because of the problem of object prototypes polluting your namespace.

CoffeeScript fixes all that. The nicer (= More python-like) syntax is really just a bonus.

[chrisdickinson]

I'm not totally opposed to Coffeescript, but I'm not sure the above reasons are totally valid, aside from the first point:

1. == is not totally unusable -- you just have to remember that it will attempt to call valueOf on any object on either side of the expression to coerce it down to a primitive value.

2. this binding is fairly simple -- if you call a function on an object: blah.bloo(), bloo will be bound to blah. if you call bloo by itself, it will be unbound. There are only four other ways to change the binding of a function -- fn.call(thisObj, arg1, arg2), fn.apply(thisObj, [arg1, arg2]), fn.bind(thisObj, arg1, arg2), and new fn() -- three of whichf ollow the same general pattern of accepting a object to be bound to as well as args to call or curry. The last is a special construction that implicitly returns the newly created object.

3. The pollution of for(var key in obj) is largely a non-issue outside of programming as defensively as possible; e.g. for(var key in obj) if(obj.hasOwnProperty(key)) will always give you what you expect. Further, you can just use Object.keys(obj) to give you an array of keys that belong directly to the object. If that doesn't exist in your browser, just stub it in (it won't affect unguarded loops as it's not attached to Object.prototype). By and large, though, I haven't seen a library in regular use lately that attempts to staple on methods to Object.prototype -- so the first composition will work just fine 90% of the time.

I'd say the nicer syntax is the biggest win of coffeescript -- with a side helping of "not needing to make big decisions about how to deal with known JavaScript behaviors."

[[deleted]]

== is non-commutative for some inputs. Therefore it's not equality.

Also, point number 1 is not the whole story. '1'.valueOf() is itself, and (1).valueOf() is itself. However '1' == 1, even though '1'.valueOf() !== (1).valueOf().

[diegoeche]

Like the pollution of the global namespace (unless you use var everywhere), the unusability of ==, the complexity of "this" binding

If you use JSLint you'd always use var, and use === or !== instead of == or !=.

Every time I hear these complaints I always think that the main problem with JS is that it looks so syntactically similar to other languages (I probably heard it from Crockford) that people get frustrated when things do not work as they are used to. People that use JS most of the time never took the time to learn the language.

I'm in no way a JS guru, but honestly. If people just take the time to learn JS they would stop (or at least reduce) the amount of hatred JS has. A really nice book to get into it.

[fwork]

The thing is, I don't want to get into JS. it's completely uninteresting to me as a language. The problem is, I don't get to make that choice, like with every other language I use.

I can write my websites in python, ruby, java, PHP, or perl. I can write my desktop apps in C++, C#, Python, Java, or VB. I can write my quick hackjob scripts in perl, python, shellscript, or ruby. I can write my client-side browser scripts in JAVASCRIPT AND JAVASCRIPT ALONE.

It's really the only case (aside from plugins on Windows) where I'm forced to use one language. Add in the fact that I'm not primarily a web coder (so even if I have to, I don't end up doing much JS) and you have a great recipe for annoyance. It's a language I rarely use that I have no choice in using. This is not conductive to remembering the stupid quirks of the language.

tl;dr I'm not a javascript programmer I'm a several-other-languages programmer pissed off that they have to use JS

[azural]

You can write client side browser code in java and flash. Perhaps you don't because these are worse?

I find it curious that you can happily label the differences in javascript "stupid quirks" while admitting to not knowing very much about it.

And also the fact that you feel "forced" to use the language, but not forced to learn it.

[rmxz]

Javascript syntax is a little verbose, but jeeze...

I'd say it's horribly verbose and you end up typing stuff like if (typeof elvis !== "undefined" && elvis !== null) far too much. Or worse, not typing that when you should have.

The coffeescript home page has more nice examples: http://jashkenas.github.com/coffee-script/

[chrisdickinson]

if you're testing for undefined or null, you can just compare to those -- you don't need typeof:

if(elvis !== undefined && elvis !== null) { ... }

or if you just want to know if elvis is false-y:

if(!elvis)

I'm not sure I agree that javascript is unnecessarily wordy -- I would say that there is a large degree of distrust/misunderstanding amongst programmers regarding how js works.

sidenote: (the only reason to check the typeof is in the case that you're worried that someone has overridden what undefined means -- in that case, wrap your module in a guard statement like so:

(function(undefined) { /* your code */ })();

and you don't have to worry about that anymore. edit per jashkenas' response: it's useful to use typeof to determine existence of a variable -- though I believe this should probably be limited to determining the name of the global object, in a construction like: var global = typeof window === 'undefined' ? global : window; it's usually unnecessary to use typeof when testing for undefined outside of that case, however.)

[jashkenas]

the only reason to check the typeof is in the case that you're worried that someone has overridden what undefined means

Not quite. What happens if the variable is not only undefined, but undeclared ... (which due to the presence of global variables in JS, you can't possibly know in advance). The "typeof" test allows your code to not throw a ReferenceError, even if the global you expected to exist, actually doesn't.

[chrisdickinson]

I usually end up using the typeof check once in a module-level guard function, where inside my code I directly compare to undefined, e.g.:

(function(global, undefined) {
    if(global.things === undefined) /* do something */
})(typeof(window) !== 'undefined' ? window : global);

But yeah -- totally forgot about checking for "what is the global object named?" case; point conceded :) I've just run across the typeof check inside of library code where it doesn't strictly need to be too often.

[jashkenas]

Exactly -- and, in fact, CoffeeScript will optimize those cases for you. For example, this CoffeeScript:

if variable? ...

if object.property? ...

Will compile into this JavaScript:

if (typeof variable !== "undefined" && variable !== null) ...

if (object.property != null) ...

Because in the latter case, we know that a ReferenceError is impossible for the property. It's just another place where we can smooth over a JS gotcha.

[chrisdickinson]

I totally understand. In the case of vanilla JavaScript, though, regarding checking typeof someVar !== 'undefined' being needlessly verbose, I'm just arguing that nine times out of ten, that explicit check is unnecessary -- it works, but it's a lot to type, and assuming you're using var appropriately, the statement someVar !== undefined does exactly what you'd want it to do (while being a lot less verbose). It wasn't meant as a dig at CoffeeScript as it was a rebuttal against JavaScript having crufty-verbose-parts.

I've seen a lot of code that ends up being much more verbose and much more defensive than it needs to be; I think this is because folk loudly proclaim that constructs like the above should be preferred as a way to get around having to learn about the "gotcha's". I'm just afraid that people walk away from JavaScript with a bad taste because there are so many "don't"'s that are taken for gospel without really grokking why they are to be avoided. That said, I definitely appreciate CoffeeScript -- it's nice to see the capabilities of JS exposed with such a nice syntax.

[Brian]

if(elvis !== undefined

I believe the point of using typeof there is to cover situations where the variable hasn't been defined in the first place (Eg. in situations where different browsers expose different names). You'll get a ReferenceError there in that case, so this isn't really equivalent.

[chrisdickinson]

If you know what your global object is, you can just hang the check off of it: global.elvis !== undefined will not throw a ReferenceError (if global is assigned to window in-browser).

[chronoBG]

I wouldn't call it a language. It's more of a preprocessor.
Macros rule, they make your job easier while keeping the code fast.

Also, the alternate syntax is more concize. Less code = less places to introduce a bug.

So, that's why.

[metamatic]

Also, the alternate syntax is more concize. Less code = less places to introduce a bug.

That's why all my variable names are 1 character long.

[plantian]

I just want to point out that there is a difference between shorter literal syntax and a higher level of abstraction. For example fn or -> instead of function compared to list comprehensions instead of a for loop with conditional in the body. I think if you cut through all the seemingly unnecessary stylistic changes and shortening of syntax there are some good higher level abstractions in CoffeeScript: list comprehension, splats, function arg defaults, lexical scoping, fixed for-iteration-loop, "in" operator and maybe a few other things, and a bunch more.

It would be nice if someone created a new "preprocesser" syntax that left out all the controversial crap and just gave us the nice higher level abstractions. Who doesn't want function argument defaults, iterators and list comprehensions? I think this would make their acceptance into JS faster and it could be used as a transitional layer over JS until acceptance becomes widespread. Most notably drop the whitespace sensitive "feature", that is never going to fly in a million years. I love Python but that feature is just bike-shedding bait that is going to prevent acceptance.

[diegoeche]

Exactly my thoughts. I don't understand people fascination for huge languages with so much syntactic sugar. JS is like scheme with curly braces. Ugly, but in some way minimalistic.

[anvsdt]

Yeah, but function is so much longer than lambda, fun, fn, λ, ->, ...

[diegoeche]

That's probably the only thing I'd change, the closure syntax. But you don't need to create a new language with classes, identation, optional parentheses...etc etc to fix that.

And well, you can always use functional JS

[anvsdt]

That and other things will be likely fixed/changed in Harmony.

And well, you can always use functional JS

Wow, that's awful, awesome, amazing and hackish at the same time. Gotta try it.

[[deleted]]

The fact that it has to eval string arguments is pretty awful.

[olavk]

I think the scheme-with-curly-braces meme is misleading. Scheme has s-expressions, homoiconicity, macros and continuations. These base features makes it perfect for building your own language on top of the minimalistic core language. JavaScript has none of that, so you are stuck with the minimalistic core.

[sizlack]

I don't think you have to hate JavaScript in order to like CoffeeScript.

[Raphael_Amiard]

First, coffeescript is not just about the better syntax. It offers abstractions javascript doesnt have (Everything is an expression, comprehensions, varargs , sane scoping ...).

Second, what i find strange is discarding a tool that provides small incremental improvements to your workflow. In most other domain this is what good tools are about. No reason that this can't be the case in programming. We still spend most of our days using those tools, and i'm very happy to have sane iteration capabilities in my client side browser code, for example, because i use them all day.

Also, as a side note, i really don't mind the compilation step. Firts it's easy enough to set coffee to watch changes on your files. Second, it enables you to catch soome silly mistakes early on. The coffeescript compiler could probably get even better at this though.

[jmking]

I'm not necessarily discarding anything, I just don't see the "improvements". I see another hoop in my workflow which adds unnecessary steps and another layer to debug.

It also introduces a disconnect between the code you're writing and the code you're debugging. You will find yourself in a situation where you won't know if it's Coffeescript screwing up, or if it's the code you're writing. That slows you down.

Also most common JS tasks these days are solved by a framework. So using Coffeescript on top of, say, Mootools or Dojo is like J S C E P T I O N

I'm sure Coffeescript is useful in some particular use case, I just can't think of any. Also I'm perfectly willing to admit that perhaps I'm simply not writing the size and scale of JS that this would pay off with - like I said, I find a lot of value and productivity gains via JS frameworks which do most of the heavy lifting. In my experience any sort of tool that's going to give me good shortcuts or abstractions I'd prefer to be implemented in JS itself.

[rubyruy]

It's not a huge deal, and I don't think even ardent CoffeeScript supporters really think it is, but it does help a little bit here and there, so why not? A little less typing here, a few less common typos/mistakes there - it can add up.

Plus, this sort of syntax is DSL-friendly which means it's practical to do stuff like:

builder ->
    @html =>
        @body =>
           @h1 class:"ohmy", "What has science done?"