In recent years there has been an upsurge of interest in dynamically typed languages, with quite a lot of buzz about JavaScript, Python and Ruby. Could it be that one of these languages will rise to be the champion of the next decade?

I would be a bit surprised. These languages are quite old and carry a lot of baggage. Although they are quite a bit more expressive than the current champions, they also give up a lot and are much more challenging to implement efficiently. Most importantly, I do not think they adequately address the pain points I mentioned in http://blogs.msdn.com/hermanventer/archive/2008/02/28/succeeding-as-a-programming-language.aspx.

Nevertheless, there are good reasons for the current success of dynamic languages and we should try to learn from that. The language I know best is JavaScript, so let me reflect a bit on the differences between JavaScript and Java.

The most obvious difference is the lack of type constraints. JavaScript objects allow you to assign any kind of value to their properties. This may seem like a crazy lack of discipline and an invitation for run-time disaster, but it does enable JavaScript programmers to create highly polymorphic data structures, which makes it easier to write less code. And writing fewer lines of code is a very good thing. Granted, there is now no compile time type checker to point out some of your mistakes to you. But, if you write unit tests and develop incrementally, you find these kinds of errors pretty quickly anyway. And you’ll find many others that a compile time type checker will miss.

Now, in Java you can make your data structures polymorphic by annotating your fields with type “Object” and casting down whenever you need to operate on the value stored in the field. But this is not only verbose and ugly looking; it is also downright hard to do. In effect, the programmer has to implement dynamic typing, instead of the compiler doing it. And doing it efficiently is hard. So, instead, Java and C# have acquired ways to parameterize types. This gets you quite a bit of polymorphism, but often too little. Also, the added expressive power comes at the expense of much more complicated type rules. Not many weeks go by in between episodes where I find myself puzzling over how to make a type error go away, or helping someone else understand the C# type rules.

Another important difference is that the JavaScript type system is structural rather than nominal. That is to say, if you store an object in field foo and then call foo.bar(x, y, z), you really don’t care what the type of the object in foo is, only that it should have a function property called bar that can handle the arguments x, y and z. To achieve this in Java or C#, you’d have to define a separate interface for every method you write, which is very tedious and best left to a compiler. Why is this important? In a nutshell: “version resilience”.

The runtime support needed for dynamic typing can also leveraged for all sorts of metaprogramming, which makes dynamic languages very powerful. For example, in JavaScript one can dynamically update the value of a function property on a prototype object. This makes it easy to instrument code and do all sorts of Aspect Oriented programming like things.

To sum up: I strongly suspect that a future champion programming language will provide a type system that is virtually or completely invisible to programmers, that allows programmers to write code that can deal with highly polymorphic data and that is structural rather than nominal. I also expect that there will be first class support for metaprogramming.