|
|
Jython is:
1) many of the modules taken as-is from the standard C-Python distribution and used by your average Python-scripter
2) a Python to JVM-bytecode compiler
3) a layer, written in Java, that provides additional "dynamic services" for the bytecodes produced by #2,
One way to view this is that Jython is producing JVM-bytecodes that conform to an extended object model (#3) where that extended object model is implemented in Java.
I like that formulation. My question then becomes: can (and should) a VM generalize that extended object model? Patrick Logan seems to be thinking along the same lines:
The underlying mechanisms for the CLR as well as for the JVM *are* dynamic. The problems for making these systems universal are in the necessity to use nearly the entire language model of C# or Java, respectively, in order to achieve any kind of integration.
A better approach, IMHO, would be to make integration more abstract and more loosely coupled than the "shared object model" of the CLR or JVM.
Components written in various languages should be integrated via a simpler, asynchronous, shared-nothing, message passing model. Then those components could be instantiated in the same OS process, a different OS process, or on a distinctly different host on the network, without having to alter the mechanism for integration.
A virtual machine in this model would offer a reusable implementation of garbage collection, component instantiation, time-sharing, channel discovery, message formatting, optimized "intra-OS-process" message passing, and an instruction set for sequential processing. A universal virtual machine would not require a shared-memory, monitor-based, object model. [ Lambda the Ultimate]
Sounds good, though of course the devil's in the details. Meanwhile, Rich Kilmer referred me to David Simmons' SmallScript. According to Simmons:
SmallScript runs on two different platforms. The first is its native platform, the Agents Object System(tm) [AOS(tm)], the second is Microsoft's .NET platform. The AOS(tm) platform is QKS' universal virtual machine and object model technology. The AOS currently supports the Windows X86 family of operating systems, with planned releases for other systems including Linux and the MacOS [w/COM and ActiveX functionality]. [ comp.lang.smalltalk]Is the AOS an example of the kind of virtual machine Patrick imagines? Before I could get very far with that line of speculation, Dan Sugalski weighed in from the perspective of Parrot, the VM for Perl 6, which he is designing:
The other question is "could .NET or the JVM change to support features perl needs?" In this case mostly closures and continuations, which are the biggies. (weakly, runtime typed variables are less of a problem, though still a problem) The answer is yes, but they'd be stupid to do so. As I said, those features have unavoidable overhead. Running perl faster at the cost of running C# slower is not, at least in my estimation, a good tradeoff.
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.
That's engineering, and there ain't no such thing as a free lunch. Neither is there any such thing as a language-neutral VM. Or real M, for that matter. Anyone who tells you different is either lying, a fool, or ignorant. Real hardware doesn't like closures and continuations -- VMs that don't do closures and continuations running on top of hardware that doesn't like them is not a recipe for speed. [ Squawks of the Parrot]
Hmm. Maybe I really can't have my cake and eat it too. And yet, somehow, I don't think I've heard the last word on this.
Former URL: http://weblog.infoworld.com/udell/2003/03/26.html#a649