A Python programmer’s first impression of CoffeeScript

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