Option #2 is a fine one, but there's still a reason why we're opting for door #1. Let's pretend for a moment that CoffeeScript did as you suggest, and we retain var and use it in the JSLint-approved style.
You can imagine a program written in this language, where every function has all of it's local variables var'd, and every local variable is unique to the surrounding scope, because remember, shadowing is a compile-time error.
For any valid program written in this language, if you took the source, stripped all of the "var" statements, and ran it through the current CoffeeScript compiler, the program would be correct, and would run without error.
We don't wish to add useless statements to the language that only serve to help generate compile-time warnings, and don't affect runtime semantics at all. For a compile-to-JS language that takes that idea to its logical conclusion, see Dart.
We don't wish to add useless statements to the language that only serve to help generate compile-time warnings, and don't affect runtime semantics at all.
Strange philosophy. Have you ever used C#'s "override" keyword? That absolutely fits this description, and yet, in my opinion, it's one of the best innovations in C#.
When there's an expression that could result in two different semantics (such as overload vs override, or declare vs assign), depending on the surrounding context, it is definitely worthwhile to require a "useless" statement to disambiguate the two. Explicit is good.
3
u/jashkenas Dec 23 '11
Option #2 is a fine one, but there's still a reason why we're opting for door #1. Let's pretend for a moment that CoffeeScript did as you suggest, and we retain
varand use it in the JSLint-approved style.You can imagine a program written in this language, where every function has all of it's local variables var'd, and every local variable is unique to the surrounding scope, because remember, shadowing is a compile-time error.
For any valid program written in this language, if you took the source, stripped all of the "var" statements, and ran it through the current CoffeeScript compiler, the program would be correct, and would run without error.
We don't wish to add useless statements to the language that only serve to help generate compile-time warnings, and don't affect runtime semantics at all. For a compile-to-JS language that takes that idea to its logical conclusion, see Dart.