Alex headshot

AlBlue’s Blog

Macs, Modularity and More



Microsoft’s interesting post regarding support for dynamic (or other) languages in the CLR is really noteworthy. Microsoft have long been active in doing other work on the CLR – after all, it already supports C# and VB.Net, not to mention hooking in existing managed C/C++ code. But the focus on supporting other languages – the Pythons and Rubys of the world – shows how much they’re looking into making the CLR the platform of choice. It doesn’t hurt that there’s already an open-source implementation available (though, of course, Microsoft can/will argue that theirs is the best), which means that people need not be scared about using it.

In the JVM camp, we’ve really got no people at all doing interesting language support for bytecode. There’s also some fundamental issues in some languages; for example, tail-recursion isn’t supported (whereas it is in the CLR, with the special tail IL instruction).

Instead, we’ve got arguments about the best way of introducing anonymous functions/lambda expressions into the Java language itself (and still calling them closures, even when they’re not) as a way of evolving the Java language. Surely we can have a nice, new language (or set of languages) that compile down to Java bytecode and that can let people write their own code in their language of choice?

I see three possible futures from this:

  • Java will (slowly) adopt features at the rate of one per year
  • C# will become the default language, even on Linux systems
  • Someone will write a language that compiles down to either CLR or JVM and doesn’t care which

Frankly, my money is on the last one. A lot of current/existing languages are non-optimal; Python and Ruby (the two main contenders) have a lot going for them, but neither uses Unicode by default (unless you count the JXxxx implementations which are woefully behind). And other features like Erlang’s message passing aren’t used heavily, nor is functional programming generally (exceptions being things like Scala). On the other hand, .Net has a wide variety of different languages – C#, Spec#, F#, VB.Net … and all of them are interoperable with each other. Now it seems that dynamic languages such as IronPython and NetRuby will be following in that fold as well.

If Sun separated out the JVM from the Java libraries, then the JVM might be in with a chance of survival. But tying it down to the Java libraries unnecessarily (and forcing everyone to download them even if they’re not using that language) is essentially the decision that’s killed off any other language support on the JVM. Sadly, I don’t think that either Harmony or releasing the VM under open source is going to change that now.