Language Specific Design
The proliferation of language runtimes (virtual machines) both fascinates and frustrates me. Here on my Windows machine I use the .NET Common Language Runtime, the Java VM, the Flash player, and one VM per dynamic language (e.g., Python, JavaScript). Over on my Mac, subtract .NET but don't (yet) add Mono. On servers, add the PHP and Ruby VMs.
When people "port" applications and frameworks from one language to another, what they're really doing, in many cases, is transferring capability from one VM to another. Case in point: TrimPath Junction, a "clone or port of the terrific Ruby on Rails web MVC framework into JavaScript." Language preference wasn't the reason to emulate Rails in JavaScript. Rather, the motivation was to bring Rails-like capability to the only VM available in the browser, and thus to enable single-page applications.
That frustration is why I like to say that design is language specific - unless you want to do a ton of work to take a language capability and port it. Multi-language VM's are a pretty hard thing, too - the VM's that exist were very much designed with their main language in mind - Java on the JVM, C# on the CLR. Sure, there's a port of Python to both - and in the case of the CLR, it sounds like the author is, for all intents and purposes, creating a new VM on top of the CLR - i.e., treating it as another hardware platform.
We looked seriously at using the CLR as a place to run Cincom Smalltalk, but found that it was utterly unsuitable - we would have had to treat the CLR as a new platform, and write a new VM on top of it. The CLR simply doesn't have suitable support for a language like Smalltalk. Don't even ask about the JVM - it's been frozen for years, and any Smalltalk running on it is going to be slow. Really slow.
Neither Microsoft nor Sun are acting truly motivated to support dynamic languages - at least, not if you look at what they actually do.
Comments
Regarding the JVM
[Charles Miller] February 27, 2006 18:06:32.591
Gilad Bracha blogged recently about a proposal to add an 'invokedynamic' bytecode to the JVM to make it easier to run dynamic languages on top of it. So the JVM may be thawing slightly: http://blogs.sun.com/roller/page/gbracha?entry=invokedynamic
(Come to think of it, I think I originally read about that in your blog, so apologies if that's nothing new :) )Comparison with IronPython
[Charles Cook] February 28, 2006 4:07:36.507
Comparison with IronPython
[Charles Cook] February 28, 2006 4:14:03.401
Akin to what I've been reading about Iron Python
[ James Robertson] February 28, 2006 7:35:33.399
Comment by James Robertson
To get a working Smalltalk - akin to what the Iron Python effort looks like. Then, there would be a secondary issue: VisualStudio tools would all be a downgrade from what you can currently do in a Smalltalk environment.
The effort would be large, and for just one platform.
IronPython vs. VW SMalltalk
[Patrick Logan] February 28, 2006 9:29:24.141
If I recall the numbers correctly, IronPython performs nowhere near the level of the VisualWorks Smalltalk VM.
the JVM - it's been frozen for years
[Isaac Gouy] February 28, 2006 12:17:25.529
James wrote "the JVM - it's been frozen for years, and any Smalltalk running on it is going to be slow. Really slow"
Previously James wrote "If this possible JSR gets implemented, it will be very, very good news for dynamic languages - it will make them possible to implement decently on the JVM"
What is new in Mono 1.1.12
[Isaac Gouy] February 28, 2006 12:38:25.737
"This version of Mono can run IronPython 0.9.6."
Isaac
[ James Robertson] February 28, 2006 13:44:05.644
Comment by James Robertson
Which part of "if" was hard to understand?
If only
[Isaac Gouy] February 28, 2006 16:44:22.087
If you had written If the JVM stays frozen, without invokeDynamic..." there wouldn't be anything hard to understand.
JSR 292
[Isaac Gouy] March 2, 2006 14:32:42.262
JSR 292: Supporting Dynamically Typed Languages on the JavaTM Platform