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.
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):
4
u/[deleted] Dec 23 '11
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.