Who came up with this? Let’s put things in context: JavaScript is a dynamic language. It turns out that this characteristics deeply upsets many people, particularly those who prefer to rely on a compiler to check their code for them before running it. It turns out that these guys also have a hard time imagining their objects in memory, what do they look like, what they do, and so on, and for them ECMAScript 4 will bring types, that is, variables declared both with the var keyword and a special type declaration after the variable name. There is an illusion built around statically typed languages. I know it: I’ve already advocated them as the silver bullet that never existed. But I was wrong, and I admit it. Personally I think that dynamic languages are the future.
The problem with statically typed languages is that “collections” or “containers” of things should also be typed, because otherwise you spend a good deal of CPU time boxing and casting instances, because otherwise you might as well “put a cat in a dog collection” as one commenter put in the Ajaxian page above.
I am sorry but, in the case of JavaScript, the evolution of the current draft is becoming ridiculous, even after you throw in all your arguments about performance, IDE support and who knows what else:
ActionScript 3 developers can already enjoy this “syntax sugar”. Ugh!
Working with a dynamic language requires a bit of mind juggling. Which is, after all, part of the pleasure of programming. Does Objective-C need templates or generics? No, because it’s a dynamic language, that is, method references are resolved at runtime rather than at compile time, and as such, you can put a cat in a collection of dogs if you like, but you might as well hear it meow before doing it.
Stating typing brings warm feelings to many people, simply because those cheap / sloppy developers using a static language are (apparently) less prone to mistakes than using a dynamic one. But you know what? Static languages force you to write more code, and more code means more maintenance costs. And in the long term, maintenance costs can kill you. And actually sloppy developers always type sloppy code, whatever the language they choose. Cheaper in the short term means more expensive in the long term.
Do people think that a “more static” language will prevent buggy websites, sloppy coders or that it will open the whole web development thing up to the crowd? Well, I’m sorry to disappoint you but it won’t. A “more static” JavaScript will just make life more difficult for the rest of us, already in love with the most popular functional and object-oriented language on Earth. In my opinion, instead of making ECMAScript 4 look like Java, the committee in charge of it should:
- Add support for Erlang-like lightweight processes for concurrency using the “Actor” design;
- Take a look at Prototype or jQuery and add the APIs and extensions brought by these libraries into the core language.
Now these two features would make web programming a really interesting thing in the long term. I’ve already blogged about my fears regarding the next generation JavaScript; now I hope that the community will react to this horrendous landscape ahead of us.
12 Comments
#1. James H. 03.04.2008
I’ve swung in the opposite direction. I was happy with dynamic languages because they’re easy to learn and fast to work with, but when projects get big, a haze of uncertainty can develop over what kinds of data are passing through your routines, and in the worst cases it may lead to not just a runtime error but a functionality error. Spelling out what types are and aren’t allowed is a fine way to reduce that uncertainty, but I agree that the way it is done in C, Java, et al. is poor. They are static but relatively weak type systems and they impose unnecessary overhead.
I’ve realized that what I like is a type system that is mostly strong and static, with implictness and just a tiny amount of dynamism. haXe fits this bill exactly. It’s ECMA-derived, you can still use it in a “totally dynamic” mode, or you can make use of the static features, which are ML-like and can resolve the majority of the boilerplate based on context. It does enforce a little more overhead and structure at the outset, but this is a downer mostly for the tiny <100-line scripts.
#2. adrian 03.04.2008
Hi James! Thanks for your comments. I’ve found out that for big projects using dynamic languages, unit tests are a must; a good suite of tests run right after every deploy brings confidence that previous code, plus new features, plus bug fixes, current and old, are all running as required.
This, coupled with assertions here and there, help keep your code strong. I’m right in the middle of a rather big Django project, and just by using unit tests I could double my delivery speed: I can catch regressions and broken interfaces right before commits, and this is a huge time saver.
#3. blackdog 03.04.2008
+1 haXe
everything that ES4 wants to be
#4. Ricky Clarkson 03.04.2008
“Static languages force you to write more code, and more code means more maintenance costs.”
This is false. Read about type inference. See Haskell’s QuickCheck for its benefits.
#5. adrian 03.04.2008
Hi Ricky, thanks for your comments! In my previous life (as a .NET developer) we could use type inference and reflection, but (at least up to version 2 of the .NET framework) there were huge performance penalties to do so, and this usually limited their applicability, particularly for demanding web apps. I will take a look at Haskell soon!
#6. Ricky Clarkson 03.04.2008
I possibly submitted multiple copies of that comment - your site appeared to respond to reads better than writes. :)
Type inference has no performance penalties. If you think it does, you probably don’t know what it is. It’s a compile-time mechanism only. (I checked with some .NET people and they gave me blank looks, as far as is possible over the Internet)
QuickCheck is particularly interesting because it’s very very useful, and if you port it to dynamic languages the code to use it is longer, because you then have to be explicit about types.
#7. adrian 03.04.2008
Hi again Ricky! Indeed my server is working randomly today :) Sorry for that.
Regarding type inference, you can then get my puzzled look as well :)) I will check that, definitely. What I was talking about in the .NET world is reflection, that is, the mechanism to get type info at runtime, which involves (or at least involved) heavy method calls inside the CLR (.NET’s runtime). Actually that’s now part of a complete plan of learning Haskell at some time! Do you have any good resource to point me at? Thanks!
#8. Daily Bits - March 4, 2008 | Alvin Ashcraft's Daily Geek Bits 03.04.2008
[...] Now This Is Ridiculous (Generics in JavaScript) (Adrian Kosmaczewski) [...]
#9. Jim LoVerde 03.04.2008
Why must everything be absolute? Dynamic typing is useful for some situations. Static typing is useful for some situations. Having a language that supports both idioms is a good thing.
#10. Ricky Clarkson 03.04.2008
I am not a great Haskell user, I use it as a posh calculator, but I have learned a lot about it and from it. I suggest Yet Another Haskell Tutorial, which is also available as a wikibook, though general advice says to ignore what it says about monads, because it’s a bit misleading there. Simon Peyton-Jones’ The Awkward Squad is an excellent read explaining how Haskell’s monads come into play in ‘real’ software, though it might take a few attempts to read it thoroughly, depending on your background.
QuickCheck itself is reasonably easy to understand, and to port to other languages, at least for its basic functionality.
#11. Ricky Clarkson 03.04.2008
Jim, I agree completely, but I think it will work better the other way around, where static languages gain dynamic features. This is because static typing is actually a more involved topic than dynamic typing*, so it’s easier for a static language’s designers to get dynamic features right than the other way around.
* See Philip Wadler’s talk on Faith, Evolution and Programming Languages ( http://video.google.com/videoplay?docid=-4167170843018186532 and the slides: http://homepages.inf.ed.ac.uk/wadler/topics/gj.html#oopsla )
#12. Jim Loverde 03.05.2008
You make a good point Ricky. However, the problem is that Javascript has already seen “pseudo-static” typing shoehorned into it by frameworks like Prototype and Dojo. And the problem is that because these frameworks use different metamodels to represent their types, it makes it difficult for them to work together. And that’s why Javascript needs to add support for a consistent static class metamodel.
That being said, generics support and some of the other things in the ECMAScript 4 proposal might be overboard. But I’d rather have one dramatic change than a series of incremental changes.
Personally, I think that the meta level hooks in ES4 will be the single most powerful feature that ES4 brings to bear on the language. But I’ve had trouble finding any detailed documentation on how they will work, so it’s possible they won’t be as useful as they could be.
Commenting