|
Environment, scripting, and behavior
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 [6], 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. If I could make one change to both of these environments, that would be it. [Full story at InfoWorld.com]
Mark Dulcey wrote to point out that the Parrot VM is not intended to support Perl only, but any dynamic language. Yes, I should have made that clearer. 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.
Here's the kind of missed-opportunity story I hear all the time:
Many years ago we wrapped the Framemaker API in a Python extension and embedded Python scripting into Frame. It was awesome. However the powers that be weren't interested in anything that wasn't Java-based. Note to any powers that be - Java is a crappy, crappy language for application scripting. Jython, JRuby, Jackle all run on the JVM and are much better for the task. Repeat after me "Java the programming language is different from Java the platform". [Sean McGrath]
OK. "Java the programming language is different from Java the platform."
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.
|
NEWS 
