Monday, March 3rd, 2008

Generics in JavaScript 2

Category: JavaScript

Francis Cheng continues on his walk through of ECMAScript Edition 4 features, this time discussing type parameters (read: generics in Java).

We could end up with code like this:


  1. function reprimand(list:List.< +Employee>) { ... }
  2. var writingTeam:List.<techwriter> = new List.</techwriter><techwriter>();
  3. reprimand(writingTeam); // no error if ECMAScript adopts this style of variance annotation

I have to admit to having a few shakes when I see this. I went through the Generics migration in Java land, and if I had a choice I would probably roll it back, or at least get erasure in there.

And the period before the angle brackets instead of just copying Java? Hmm. In general I don’t like the angle brackets as they mess up when you mix with HTML. Now I am rambling.

Where would you like to see this go in a future JavaScript?

Posted by Dion Almaer at 8:22 am

2.3 rating from 53 votes


Comments feed TrackBack URI

I like generics in C# and I think it could do well in JavaScript.

Comment by kim3er — March 3, 2008

This is getting reaaaaaally verbous…
And I’m beginning to get scared.

Comment by philogb — March 3, 2008

Seriously, that looks absolutely horrid. At least come up with a syntax that doesn’t look like it was written by somebody on crack.

Comment by Gavin — March 3, 2008

What would be the value of this in a dynamically typed language?

I fail to see the usefulness of this … is it to limit the “expressiveness” of the language, or to try to enforce bad habits from Javaland / C#world?

Is it to prevent lazy programmers from adding cats to a dogs collection? If you’re worried about other developers breaking stuff, don’t give them direct access to your collections!

Soon we’ll see generics/types abused in Javascript, as we see them in say C#, where even the MS programmers have gone overboard.

I predict over-generalisations galore!

… or maybe I’ve misunderstood the usefulness of Generics for a dynamically typed language?

Comment by Morgan Roderick — March 3, 2008

No thanks, dump that feature please!

Comment by Dougal85 — March 3, 2008

No thanks, I don’t wanna be more verbose. And I refuse to learn another C language.
Keep that crap away, thanks !

Comment by Laurent V. — March 3, 2008

I think that ECMAScript Edition 4 features is very important, because we need to make better Rich Internet applications.

Comment by ultranessy — March 3, 2008

please god no.
someone can tell me they actually want that in the language? eww.

Comment by PaulIrish — March 3, 2008

Yeah I’m skeptical too. Generics have often been considered a failure in Java, and I don’t see how they will be any more appropriate in ECMAScript.

Plus is there any more confusing term than “Generics”? In JS, Arrays are 100% generic, Generics make things more specific.

Comment by K9 — March 3, 2008

It doesn’t matter how mangled JavaScript gets. It just means that the libraries and frameworks will be a little bigger download when we want to use a real API. All of these E4 efforts will ultimately augment the power and influence of the JavaScript libraries.

Comment by Brad — March 3, 2008

I agree with the other commenters. This adds nothing of value and only makes the language more difficult. Java was right to not support C++ templates and wrong to eventually adopt it as generics. To bring it in JavaScript doesn’t make sense as it is a dynamic language that relies more on duck-typing.

If they really want to improve the reliability of JavaScript they need to beef up support for automated testing (unit testing, functional testing) and get consistant API’s for DOM, etc in the browsers.

Comment by Eric Anderson — March 3, 2008

OMG! I was just starting in some way to like AS3 (not as much as original JavaScript) and getting used to is typing. But please this feature (as most of the ECMAScript) is make for dummy developers who just don’t know where they are. I thinks that in JavaScript 2 we just need to clean the language from it’s original bugs, not to flood with useless things witch may kill the language.

Comment by RStankov — March 3, 2008

The other issue is that compatibility with IE would get more difficult since MS is not willing to upgrade its engine. If there is something necessary to be added then I would like the feature of socket development in JS.

Comment by kadnan — March 3, 2008

Javascript != JAVA/C . The more popular “web-apps” become the more JAVA and C folks will migrate into the ranks of those that might influence direction of how the language evolves. If anything the greater the distance ECMA script puts between it and JAVA the better.

Placing something like new List.() in an HTML page creates a tag soup that a normal web developer can’t just take a look at and quickly understand.

Comment by Chris Phillips — March 3, 2008

the language is perfect the way it is :-(

Comment by Toledo — March 3, 2008

An interesting discussion here:

Comment by TNO — March 3, 2008

I use generics all the time in Java, and they can be quite useful at times. That said, they don’t belong in JavaScript and I see absolutely no reason to have it.

Comment by Matt — March 3, 2008

Guys, what we forget is that JavaScript is used by lots and lots of people with little programming background. I love generics in Eiffel, one of the few who got it right, but in a language where I might have to maintain or fix code by programmers who barely grasp the if statement? They cut and paste examples from websites whose authors barely grasp the for statement.

Generics doesn’t buy you anything unless you add static typing.

All this extra garbage will turn JS into a monstrously complex language that no programmer will totally understand. There are already too many languages that no one completely understands.

Please stop this horror and leave JS alone. If there are issues in JS, we can solve them in libraries.

Comment by Berend de Boer — March 3, 2008

One more comment: if you love Java, why not use GWT? You don’t have to touch JavaScript then. Don’t wreck this language.

Comment by Berend de Boer — March 3, 2008

The angle brackets are way too close to E4X notation, too. (That’s probably the reason for the leading dot.)

Just give me [optional] data typing and better control over code visibility (public, private, protected) and I’ll be happy with Javascript 2.0!

Comment by John Hann — March 3, 2008

Those of you hung up on syntax, there’s benefit to the dot before the less-than: it is unambiguous with respect to the less-than operator. E4X is not ambiguous with type parameters in any case.

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.


Comment by Brendan Eich — March 3, 2008

Another comment: “generics” as the street name for type parameters shows how much Java has poisoned the well here. Fans of ML, Haskell, etc. can see beyond this to what we are trying to do. If you have only Java experience, then all I can say is study the programming languages that we are more influenced by. Java isn’t that relevant.


Comment by Brendan Eich — March 3, 2008

I agree with the comment “the language is perfect the way it is”.

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.

Comment by CVertex — March 3, 2008

I agree with John Hann that there should be alternative in new JS engine like PHP5.x where developers can use old javascript as well. Pls do remember that lots of Web designers also use JS for small tasks like Validation and other stuff.

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!!

Comment by Adnan Siddiqi — March 4, 2008

CVertex: no erasure! That was foolish in Java’s case since AIUI the JVML bytecode format changed anyway, so the reason for erasure (bytecode backward compatibility) no longer applied.

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.


Comment by BrendanEich — March 4, 2008

While the world of programming is starting to simplify itself by turning on high level dynamic-typed languages, the EICMAScript guys takes a step in the opposite direction by sticking with the obsolete!
Java community (does Joshua Bloch and Bruce Eckel sounds familiar?) states that Generics have been a big mistake in the language implementation, so why do not learn form the errors made by others?
Looking at the new EICMAScript 4 specifications i’m starting wonder if i ever use JavaScript again when it will be out…

Comment by agilestyle — March 4, 2008

Guys, don’t overreact.

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.

Comment by Joeri — March 4, 2008

Just say no to generics!

Comment by Michael Mahemoff — March 4, 2008

Ok ok, but why do not increase, say, metaprogramming features, instead of including obsolete paradigms to the language?

Comment by agilestyle — March 4, 2008

the most horrible JS-2 proposal I’ve read about.
its f***ing madness to implement generic engine in scripting language

Comment by shabunc — March 4, 2008

Umm, has anyone actually read the article? Because clearly the Ajaxian formatting system is mangling the example code.

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).

Comment by jwalden — March 4, 2008

agilestyle: first class types are not an obsolete paradigm. And have you looked at the meta and reflect namespaces in ES4 yet?


Comment by Brendan Eich — March 4, 2008

jwalden: C# does not use Hindley-Milner type inference. H-M requires a type system and semantics carefully balanced for the algorithm. In short, not JavaScript’s. You may have heard the jokes about obscure error messages when unification fails in your OCaml or SML program? For the ES4 RI, we over-annotate to be clear and complete, and to avoid painful diagnostics.

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.


Comment by Brendan Eich — March 4, 2008

Dion, I feel that this post is very misleading. You are focusing on something that is not even in ES4. Type params are in the spec but what you incorrectly copy-pasted is something that is not in ES4. If you don’t like type annotations, remember that they are optional so the code sample might as well have been:

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

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.

Comment by ErikArvidsson — March 5, 2008

Thanks Erik — I didn’t read Francis’s blog carefully and see that the excerpted bits Dion picked show a variance annotation idea that is, as you say, not proposed for ES4. Dion, that is a bit misleading :-(.


Comment by BrendanEich — March 5, 2008

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.

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.

Comment by Adnan Siddiqi — March 5, 2008

Adnan: that’s a valid concern, for sure. It’s already the case that libraries are evolving to handle problems that want more specialized language. This is an inevitable process in programming and natural languages.

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.


Comment by BrendanEich — March 5, 2008

it is not clear what is the problem solved in the context of javascript the language by this complication, while i can understand it in statically typed env.
to build more powerfull apps we need speed and standards, not marketing-oriented over-design.

Comment by devsmt — March 5, 2008

Brendan: Valid points raised by you. When we are talking about evolution of JS, the next question comes in mind that whether is it possible to make JS completely independent from back end technologies? Currently JS developer has to talk with some back end script(php,jsp etc) to fetch data from DB(MySQL,Sql server) or even for socket responses? I know that storage factor is being dealt and Google also has come up with Gears to store thing in RDBMS but that doesn’t solve issue of communicating with remote databases. Same goes with sockets. Though I know its pretty scary but scope could be limited so that JS App could talk independently with other systems without involving any back end language. It will also solve issues like hosting since free hosting users will not have to pay to som XYZ hosting just because they needed a server side language to perform a task which could be done within JS as well.

Thanks for your answer.

Comment by kadnan — March 5, 2008

Don’t worry guys, all we need is an implementation of the good old crapless JavaScript in whatever they are going to make of it in next versions. I don’t think it will take more than few hundred lines of code.

Comment by mike08i — April 2, 2008

Leave a comment

You must be logged in to post a comment.