Fanciful Magic

Pot Meets Kettle Or Thoughts on VMs

Alright, noticed some discussion on James Reobertson's blog about monocultures and the JVM. Read all the gory details here: Pot Meets Kettle. Now, I know the JVM is very unfriendly to dynamic languages. But, the Microsoft's .NET VM might be in the same boat. Now, they have gone to lengths to make it better for dynamic languages, but I'm taken by to the Lightweight Languages Conference in which I had a chance to talk with Dan Sugalski for a little bit. Now, we talked about the Zork VM and a host of other things. But, the discussion on the .NET VM was very intriguing as was his thoughts on Parrot. Now, what we talked about could fill a lot of entries in my blog, but the thing that stuck out in my mind is that he said that a VM couldn't be everything to everyone. He said that the Parrot VM was an effort to have a common VM for Perl, Python, and Ruby, but there were several challenges that were not apparent at first. While all 3 are dynamic scripting languages, they have feature differences and these differences add up. The thing about a VM is that its tailored to run fast for its languages. So, naturally, Parrot is made to be fastest for Perl with Python and Ruby coming in second. Likewise, the .NET VM will probably be tailored to run C# and VB.NET faster than any other language. I think this is the guideline that Sun takes with Java. It's nearly impossible to satisfy everyone because certain features can degrade performance for other languages. It's a give and take. And it comes down to a language design issue. I think this is where the IBM Universal VM failed. It wasn't fast enough for the Java folks and not flexible enough for others. A universal VM can not be at two places at one time if you know what I mean. Plus, the response for the IBM universal VM was also lackluster. Everyone was too busy finding out that the "hottest new language" at the time was not ready for prime time (of course, I'm talking about Java). Now, Java has come a long way, but I think people are seeing it's shortcomings and it never delivered on its promises (remember the hype that is was EASY?). MS is making the same claims with .NET and they too have missed the boat.

All this talk of a universal VM also makes me think, why do we have VMs to begin with? It's to abstract ourselves away from knowing about the computer architecture we are running on. And why do we need to do this? One it makes write once, run everywhere a reality. But, it also makes certain abstractions possible because they are directly available in the machine code instruction set. I think a universal VM complicates things and there's too many design decisions that impact other factors. It seems like an impossible problem to satisfy everyone. But, I do think we could have VMs that are tailored to certain feature sets. Why not let the {} crowd have their .NET and Java VMs?! Let us Smalltalkers and dynamic languages have ours and let the functional language dudes (and dudettes) have theirs! So, then we would only be dealing with a handful of VMs, but the features targeted to perform best for what features you want.

I'm going to have to do more thinking on this, because something is starting to sound like me like why can't we have VMs where can request and plug-in the features we want at run-time? Hmmmm.....Maybe the thoughts on a static instruction set VMs is the wrong answer for a universal VM, but a more pluggable VM. So, if you want static typing and it's benefits, then you use that instruction set...I wonder if this is possible? I'm thinking it is, but we need to change our thinking on VMs....Just a thought!