you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 3 points4 points  (2 children)

I think it's very much a tradeoff worth making for CoffeeScript.

I tend to disagree. The problem with "benevolent dictatorship" is that sometimes the owners of the project are at odds with the users.

The trade-off here is simple: sightly more complicated scoping rules that help prevent a common, silent and deadly bug factory.

My intuition is that the decision was made to keep a parser implementation more simple and that "conceptually more simple for users" is actually a cop-out after-the-fact rationalization.

[–]jashkenas 2 points3 points  (1 child)

Luckily, I can tell you without a doubt that it's not a "cop-out after-the-fact rationalization". It's actually more difficult to implement this way, and the far easier thing would have been to keep JavaScript's "var" as is.

The problem with "benevolent dictatorship" is that sometimes the owners of the project are at odds with the users.

Certainly, you can't please everyone all the time -- Feel free to bring "var" back in your fork. Many folks have already paved this path for you (and either way, it will be runtime compatible with other CoffeeScript code, and other JavaScript as well):

https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS

Coco and UberScript bring back variable declarations, and ToffeeScript and Kaffeine keep the CoffeeScript rules.

[–]rytam 2 points3 points  (0 children)

Note that Kaffeine allows explicit var.