There's been a lot of stuff lately about how the .NET VM isn't good for dynamic languages. Via LtU, John Udell wrote an article for InfoWorld about the issue:
The Java virtual machine wasn't designed for dynamically typed languages. Neither was the .Net virtual machine, although at first it seemed so. When Microsoft began talking about the CLR (Common Language Runtime), Perl and Python were often mentioned. The .Net Framework would be available to scripting languages as well as to the core .Net languages. This was a great idea...
All this presumes, of course, that we can get robust support for dynamic languages in the Java and .Net run times. So far, the results are not encouraging. Jython, as we've seen, succeeds by the extraordinary measure of rewriting the Python interpreter in Java. In the .Net world, early efforts to make Perl and Python into first-class .Net languages ran aground. Both projects have now retreated to a dual-run-time strategy. Scripts can produce and consume .Net interfaces but rely on their own virtual machines, not the CLR.
Is there a better solution for these environments? The designers of Parrot, the Perl 6 virtual machine, think not and have struck out on their own. "Why not compile to JVM/.Net?" the Parrot FAQ asks itself. And it answers: "Those VMs are designed for statically typed languages." That's true, sadly. It's a question of priorities, and support for dynamic languages isn't high on the list for Java or .Net.
On his weblog, John writes the following:
... the Parrot VM is not intended to support Perl only, but any dynamic language. ... It would be best, in my view, if the JVM and CLR could serve this purpose. My gut tells me the obstacles are cultural, not technical.
and
I'm no VM guru. Maybe there really is no way for the JVM and CLR virtual machines to properly support dynamic languages. But somehow, I doubt that.
Well, yesterday on Erik's weblog I noticed a link to this great post by Dan Sugalski (he actually wrote that part of the Parrot FAQ), who responds to Udell's article and explains that the reasons clearly are technical, and not cultural.
... both the JVM and .NET are perfectly capable of being target machines. They're fully turing complete, so it's not an issue of capability. But, like the Infocom Z machine, which is also turing complete, the issue is one of speed.
To do closures means capturing and maintaining persistent lexical state. Neither .NET nor the JVM have support for this.... To handle lexicals the way perl needs them means we'd have to basically ignore the system variable allocation system and do it ourselves.
The same goes for the polymorphic ... scalar that perl has. ... To do that with .NET or the JVM would require a custom type capable of doing what perl needs.
So, to make perl work means completely rewriting the system allocation scheme, and using our own custom polymorphic object type. In JVM/.NET bytecode. Doable? Sure. Fast? No way in hell.
To do continuations is non-trivial, and I don't think it's possible to do in the JVM or .NET without treating them as glorified CPUs and use none of their control and stack features. We'd essentially write all the functionality of the interpreter and target the JVM the way we do now with C and hardware CPUs, including complete stack management, completely ignoring any features at all of the VMs. I don't want to think about how slow that would go. It's bad enough doing it all in twisted, insane C targeting real hardware. Another layer of indirection would kill us dead.
He goes on to say that even if the .NET CLR and the JVM could change to support the needs of Perl and other dynamic languages that Parrot targets, "they'd be stupid to do so", because:
All features have costs associated with them, and nothing is free. You design your feature set, then the software to run it, and it's all a huge mass of tradeoffs. This feature lets you do something, but has that cost. Wanting something to be fast means something else is very slow, or effectively impossible, and sometimes two features are mostly incompatible. You make your list, make your choices, and do what you can.
So there you have it. Thanks Dan.
The .NET and Java VMs are simply not meant to support dynamic languages, and that's ok. However, all of this shows why I'm not so hot and bothered about the multi-language features of .NET. The class libraries are very cool (even if I don't like their naming conventions...), and it seems to be good technology. But the multi-language-ness of .NET just doesn't turn me on. Most development in .NET will be done in C# anyway.
Update: Check out the second part to Dan's article: The reason for Parrot, part 2. Man, if he explains continuations as clearly as he did closures, I'll finally be able to understand how they work!
Thursday, March 27, 2003
Permalink
I should point out that sidhe is part of my domain name--my last name is actually Sugalski. (Not that sidhe isn't necessarily inappropriate for other reasons, just not correct