Lambda the Ultimate

Both the site and the presentation make it clear that object definitions via functions and prototypes is deprecated in favor of classes. While prototype-based type definitions certainly take a bit of getting used to, and have some intrinsic limitations, I cannot help but have reservations about this decision.

In my mind, the current object definition mechanics (inherited from Self I believe) give JavaScript its unique character and capabilities (take a peek at the Beyond code to see what I mean). Going with classes results in JavaScript loosing its distinctiveness. This is sort of similar to the issue I raised about the viability of VB in the .NET world. Why use JavaScript with classes when you can use Python/Ruby instead?

Also, in the context of a previous thread on static typing, note the inclusions of type annotations:

This information is not used for static type-checking, nor for supporting overloading. Instead it is simply used to coerce the argument to the appropriate type.

Making it a more powerful general purpose language is only likely to encourage "misuse".

The ability to ignore features is in itself a powerful feature of JavaScript, that is closer in philosophy to C++ than Java. In Java you have to understand classes even if all you want to do is write a simple function. With JavaScript you can write simple imperative code in the global scope, without knowing about functions. You can write functions without understanding OOP. You can define objects without higher-order functions and closures. And you can write rather high-level functional code.

BTW my feelings about type annotations is that they could have gone a lot farther. At the very least, some sort of overloading mechanism could have been supported.

I am not sure using type hints for coersion is a good thing. Using for providing hints to a compiler may be reasonable. Using it for shorthand to perform type checking at runtime seems more appropriate than coersion. (Silence is not always golden.)

Overloading in a dynamic language is really a notational convenience. The checking still needs to be performed at runtime. It's a way of partioning the code. But it also seems to be on a slippery slope toward CommonLisp's generic functions with dynamic dispatch. Even further away from a simple scripting language.

Mutually recursive references for more fun reading.

Sure a new version of Mozilla could have it, but I'm not sure how many developers would JS 2.0 if IE didn't support it.

And there's Microsoft's "new version" of JavaScript, JScript.NET, which I think is kind of a dead end compared to VB.NET and C#.

JScript.NET and JavaScript 2.0 are actually very similar (class definitions, type declarations). Indeed if you look at the slideshow you will see .NET mentioned specifically as a motivation for adding classes to JavaScript. Therefore, I would not be surprised if both Mozilla and IE support JavaScript 2.0. You can even extend this to say that .NET will support JavaScript 2.0 and also the JVM (via Rhino).

Regardless, I also think that the practicality of JavaScript as a generally purpose programming language is very much in question. JavaScript must bring something unique to the table in order to justify its use. Otherwise, it will continue to be used only as a browser scripting language (generally at < 1.0 level).