Thanks for your answer.

Trick is to leave things out without leaving out so much that developers pay too high a price, or just can’t be productive and go elsewhere. There are choices: C# in Silverlight, AS3 in Flex/Flash… JS is not competing by imitiation with those languages, but it is in the same “field of force”, subject to Darwinian competition.

In my view JS certainly needs to evolve, and we’ve done that already with Firefox (JS1.8 in Firefox 3, for example). Some of what we have added benefits library authors more than developers who can consume libraries and focus on app design, but the lines are not clearly drawn.

One thing I love about Ajax development is how front- and back-end folks mix it up, how many disciplines are thrown together. If we can keep JS usable by many segments of the programming market, and keep it from growing too big, but not stagnating it, everyone wins.

/be

Brendan I 100% agree with you and like many developers I also favor implementation of open standards rather seperate approach like IE guys.

My main concern is that future releases of JS engines should not get so complicated that designers become 100% dependent on us, the developers and we developers become dependent on library developers.

/be

function reprimand(list) { ... }
var writingTeam = new List;
reprimand(writingTeam);

Type params are useful for static typing. For people that are forced to use ArrayList, Map etc in Java without Java generics knows how painful it is to have static typing without type params.

I think this is way over the heads of most Ajaxian readers, but there is something to say about it. C# is a static language adding “local type inference” and var. JS is a dynamic language adding optional runtime types and (if the implementation supports it) an optional static type (plus lint) checker. Steve Yegge has blogged about how the dynamic with optional types approach wins, and I agree.

/be

/be

Really, are generics truly that horrible? They permit simple optimizations and catch stupid mistakes. (Although, to be honest, I’d have preferred a type inference-based system where only functions, their arguments, and probably global variables needed annotations. Hindley-Milner is really pretty cool, except that nobody really uses any languages that really [C# does use it a tad from what I hear, but only a tad] take advantage of it.) I don’t understand the people who’d argue for their never being added to Java (although I’d definitely not have used type erasure if I were doing it).

You’ll still be able to write “old style” javascript code. All of this new stuff (strict typing, generics, new OO syntax, …) merely adds to the language, it doesn’t replace it.

Adnan: ES4 is a compatible superset. There’s no reason for two engines and it’s an explicit goal not to require one for ES3 and one for ES4. Opera, Adobe, and Mozilla at least can’t tolerate that footprint and complexity hit and it’s not going to happen.

/be

What I see that new developments are actually targeting library developers rather every TOM,DICK nd Harry and this is bad thing.

Don’t make users dependant on 3rd party libraries even for small tasks!!

I’m not up for extending javascript again into another hellish incompatibility scenario in general – but if you’re going to do it, generics has my blessing.

One mandatory requirement i have is that you exclude any notion of erasures. I can’t imagine using generics unless the runtime supported it natively.

/be

Type paramaters come up in ES4 with Map, Vector, and iterator types. Having a Vector.<double> that can be optimized into fast memory and accessing code layouts for canvas and SVG scripting will save significant runtime and memory consumed by using a plain old Array, as people scale up to do more graphics in JS2. Plus there’s the type checking benefits, in strict and standard modes.

A lot of complaints here reject the premise of optional types being worthwhile, never mind type parameters. Skeptics will have to try out the forthcoming implementations to be persuaded, or not — I am not going to over-sell in advance. I’ll just note that without type params, collection types become less pleasant to use and less usefully typed — contained values are all of type * and you have to do more runtime type testing.

Unlike Java, at least you don’t have to add casts to go from * to a narrower type. And unlike Java, generics in ES4 are much, much simpler — no variance annotations or erasure, for example.

/be