![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
The future of programming language runtimes
There is a saying in linguistics, "A language is a dialect with an army and a navy. I think this applies in a way to computer programming languages too. The most widespread programming languages aren't necessarily the ones that are "perfect" in an Esperanto sort of way, but the ones which have an army and a navy - i.e. large corporations backing them.
Fragmentation
The current fragmentation in the language runtime space is quite disheartening. It's still best described by this 7-year old hub paper by Havoc and Owen. I hope they won't be mind my linking to it. Examples of this fragmentation problem are still prevalent today. The difficulties in using gtkmozemebed from Python due to two garbage collectors and type systems in one process. To use the Linux inotify system from Ruby, you need a random third party binding that may or may not be up to date. If you want to use the Eclipse rich text editor in your next OCaml program, well you're just screwed. The examples are almost endless...most pairs of (API X, runtime Y). Not all of those are sensible combinations, but a lot of them are.
Now, the problem with Hub I think was that it assumed you could still sensibly mesh unmanaged languages like C/C++ as they are today with managed VM-based runtimes like Python and Java. If you've been following the Mozilla project, you know that they are embarking on a huge effort to automatically rewrite their 2+ million lines of code to go from C++ with reference counting to C++ with garbage collection, because the problems with leaks between the two systems are too hard. (By the way, this stuff is really cool and worth watching as I've mentioned before).
In the GNOME community, we largely get by with systems such as PyGTK and Gtk# that do mix runtimes with reference-counted C because we're not running untrusted code from the Internet, like Mozilla has to. If you forget to destroy that widget you removed but that still had signal handlers calling managed code connected to it, it's a bug in your application that is your fault - not the fault of some college student writing his first JavaScript application that was an intern at a website you visited.
The technical future
This prediction has been made plenty of times for years, but I think it's worth repeating. The future of language runtimes is pretty clearly going towards VM-based runtimes. C/C++ are dead ends for pretty much anything except a kernel. More modern AOT-compiled languages such as OCaml and Haskell have a lot to gain by switching to a VM. Concurrent, generational garbage collection isn't trivial, and a modern VM gives you that. Being able to load code dynamically, or programmatically construct new optimized functions at runtime for specific data is very appealing. Debugging is significantly easier.
The political future
So, here we are in 2008. Is the situation much better? In some ways, yes. The Free Software community now includes Java. Popularity of truly open, community-driven languages and runtimes such as Python and Ruby seems to be rising. And finally, there is a project which is attempting to create a .NET base language runtime, Mono.
Mono
The Mono project is the marriage of two major ideas. A runtime designed for multiple languages is a very unifying concept. It would solve almost all of the issues Hub was attempting to address for managed, VM-style languages. It leaves C/C++ out unless they're manually bound, but there's no helping that.
The second idea though of Mono is that it is defined as a .NET clone. This idea has proven very divisive. One company, Microsoft, is the upstream. This is not a good idea for the Free Software community; we don't have control of our technical destiny anymore. If we want to add a bytecode that makes Python run better, we have to wait for decisions to be made in some Microsoft boardroom.
If I was in charge of Mono, what I would do immediately is reach out to 3 communities that are much more clearly part of the Free Software world: Python, Ruby and finally - Mozilla Tamarin. Mono could say to these communities, "Hey, we'll be your JIT, garbage collector, and common library runtime" - but with the freedom to adapt and change to the needs of these communities. Especially having Mozilla on board would be a coup, because it's shipped to so many people. I certainly wouldn't have a problem making my application depend on Firefox being installed on Windows.
The problem with separate projects like Jython and IronPython, JRuby etc., is that they're essentially forks. They have connections with the upstream, but that's not the same as being the upstream. If Mono can unify the truly open Free Software languages around one common runtime, it would greatly circle the wagons around
Java
Sun has finally realized that the idea that every single application would be written in Java and only needs a least-common-denominator API across every platform doesn't work. Even more importantly, the JDK is now Free Software, and though the JCP isn't ideal, it at least exists.
It certainly seems plausible to me to imagine that Sun would be willing to buy into a shared runtime that wasn't .NET, but a true cross-corporation, community effort. They're already trying to add new bytecodes to better support other languages, but instead we could translate IKVM-style from Java 5.0 bytecodes into a new shared runtime.
5 years from now...
I really hope I'll be writing my Python app that
- Gets efficiently JIT-compiled
- Can access various OS components like inotify automatically as they're added to a common shared library
- Can seamlessly blend in a Web-like widget that executes other languages such as JavaScript without pain
- Is able to call into frameworks like Hibernate
Oh, and I want my jetpack.
(Anonymous)
About that jetpack
The perils of uniting around a single common tool (whether Mono or whatever) should be blatantly obvious ... slower development, inability to innovate, and lack of options.
Linux is what it is because it abhors monoculture (ha, I said, mono?)
Anyhow, sqlalchemy and TurboGears satisfy your javascript and database needs, as for the jetpack, well, me too.
Re: About that jetpack
On Mono.
You are correct that today the support for C and C++ requires manual bindings with Mono. But this is not really a limitation of the CLI, but a resource limitation.
In the Microsoft world you can use C and C++ through their compilers which are able to generate either pure CLI code from C and C++ or mixed code (keep the C and C++ code native, while the compiler automatically exposes all the metadata that the runtime needs to talk to it).
There have been over the years a couple of attempts to get GCC to generate CIL code. Most recently ST Microelectronics (in the past two years) lead the work to do just this, and it was only a few months ago that the code finally made it to SVN. Last I hear the code lives in a branch in GCC, and it is not part of trunk yet.
But even if the above code is completed, there is still work that needs to be done for the mixed support. Not impossible to do, but someone has to do the work.
One of the interesting features of the CLI is that it has a strong inter-object story; It is very easy to support other object systems and integrate them into Mono. Although we had no interest in COM ourselves, other folks did and they contributed the work to have Mono use COM.
As it turned out, supporting COM was fantastic, as it allowed us to talk to Mozilla without any wrappers, and we are today communicating with XPCOM and letting Mono manage the lifecycle of those objects, and deal with in/out marshalling of the data.
At one point we considered working on an integrated GObject binding, but we decided against this because the Mono team was too small, and we wanted to start writing Gtk# applications sooner rather than later. It would also have been challenging although not impossible to offer Gtk# to the Windows crowd.
You are correct that today IronPython and Jython can be perceived as forks of CPython in that they do not support everything CPython does (in particular, the C-based extensions and modules). But I like the approach that Guido has taken which is to say that Python is a language, and it can have multiple implementations.
It would be useful for Mozilla to adopt Mono, and they would get a lot out of it in my opinion. But Mozilla is now betting on Tamarin and does not consider using Mono an acceptable solution, not even the ECMA core is OK with them.
In the end, am not sure that we will reach a point where we will have a unified runtime, but am not sure that this is a terrible thing.
Bridges to various technologies will continue to exist, and full control over your dependencies continues to be an important aspect of many software projects, taking an external dependency on third party GCs, JITs or bridges continues to be painful from a project management perspective.
Am sure that if we were starting with a clean slate many decisions would probably be different, but at this point, we should work to make the best that each of us can do, and try to collaborate in the areas that we can.
Miguel.
Re: On Mono.
On Guido and multiple implementations - I think he's wrong. Multiple implementations of something are not workable or sustainable. Trying to turn GCC into Java failed. Jython is far behind Python. IronPython is decent, but the comparison vs CPython 2.4 lists a number of things, and Python 3000 is coming.
Mono has so far implemented a lot of the APIs, though I see few 100%s on the API status page.
But it isn't really about the APIs. It's about the common bytecode (and semantics), and garbage collection. If we can achieve that, the libraries can follow.
Mono has the right licensing to approach Python,Ruby,and Tamarin I think. It's just a question of political acceptance, not being tied to .NET.
(Anonymous)
Re: On Mono.
On C/C++, I believe you missed the second part of my comment. Microsoft compilers support three modes of operation:
* Pure native
* Pure CIL bytecodes
* Mixed CIL/native
The intermediate one (Pure CIL bytecode) is what you are referring to, and I agree, it has its uses and its academically interesting, but has the limitations along the lines that you describe.
The interesting one is the Mixed CIL/native (if we were to have this on Linux): it exposes managed interfaces that managed code can consume, but its implemented with native code. So this is the best of both worlds.
Regarding Guido; I believe you can pick solid examples where that has worked. C, C++, Fortran, Lisp, Scheme, Smalltalk and others have benefited by having more than one implementation, from breaking from being "one product" to become languages.
I do not know the story of GCC and Java, but this does not strike me as a particularly relevant example. GCC/Java was aiming at something that was almost research on this field: to batch-compile code from Java to native code and integrate with a dynamic runtime for dynamic pieces. Not an easy job.
But the open source Java efforts (pre-open sourcing) had a very difficult task ahead of them, the only people that cared enough to work on those projects were the free software advocate hackers, not the people that had an itch to scratch. The itch-scratchers went directly to Sun or IBM's Java, who cares if the source was available, as long as it worked (I have talked about this in detail in some blog entry).
The fact that not every runtime and language is at the same level is not by any means the end of the world. I would hate to see a frozen language, and even things languages like C continue to evolve. Evolution is at the core of what makes programming fascinating.
As for Mono and its APIs: we have not implemented 100% of everything, but the reality is that it does not matter. Many of the calls are pretty obscure and are only used by a handful of apps.
We know this because we have been collecting data from real world applications (about 4,500 on the last count) on which APIs they actually use, and these APIs are a tiny subset of what the framework implements.
Not ideal? Perhaps, but it does not matter. Its like saying that Linux was faulty because it did not implement every possible POSIX spec. Eventually, it got what mattered, and the rest is just junk. The same goes for things like OpenGL. What matters is what people use.
But with all the above said, the political issue will continue to prevent Mono from gaining more acceptance.
Am open to suggestions, but I have reached the point where I have stopped actively promoting it to Linux users, and instead have focused on the Windows crops of developers, where the offer is compelling: we make your apps run on Linux and MacOS (sadly, MacOS seems to be an important driver).
Miguel.
Re: On Mono.
Other things like Common Lisp, Scheme, Smalltalk are pretty much irrelevant...
I agree it does seem like Mono has the APIs which matter.
I can understand why the shift in marketing, though certainly Mono has some mindshare - I use Tomboy and like it.
And yes, it does come back to politics between large corporations, with the Linux/Free Software community caught in the crossfire, which sucks.
I'm just hoping we can find a way forward from the current stalemate.
(Anonymous)
Mono's future.
One last thing: we are not dependent on Microsoft determining what goes *in* or *out* of Mono. We are an open source project, and as such, if you had a good idea, you could implement it, and if its good enough, we could even bring it to ECMA for standardization.
For example: there have been between 4-5 "forks" of our C# compiler that people have used to study new language features. If those features are properly evolved and productized, there is nothing stopping us from using them and submitting to ECMA, or even having our own extensions (very much like GCC did with C).
But for instance, lets consider running Python faster under Mono. As it turns out doing the work on Python *alone* is a lot of work, work that nobody was willing to do in the first place until Jim came along; Microsoft hired Jim and he went on working full time on making IronPython fast. Some of his research lead to improvements in .NET that did increase the speed of IronPython (and we have implemented them now).
Nothing prevent us from doing that, but someone has to do that work. Today it just happens to be the case that Microsoft is doing a lot of the work on running dynamic languages and running them fast on top of .NET, so we are not leading that charge. All of their work on this area is also open source (MS-PL license) so we do not have to work there.
But if you really felt that there was an area where MS dropped the ball we can always take charge.
Most of the ball dropping though happens in the class libraries, rather than in the virtual machine itself, or the language (the evolution of C# is a thing of beauty: well maintained, well groomed, and with incredibly taste, it will become a poster child of how to grow a language correctly).
In the space of class libraries, the community (sometimes proprietary, sometimes open source) has picked up where MS left, very similar to what happened in the Java world where entire ecosystems of libraries were created (Nuint and Junit; Hibernate and NHibernate; Npgsql, the NDesk.* libraries) and we of course have created a few things, maybe not as ambitious as others have, but they have filled in the gaps for what we need (Gtk#, Mono.Posix, Cecil, Mono.Cairo, Npgsql, Cocoa#).
Miguel.
Re: Mono's future.
It would just be nicer I think if conceptually there was a split - the Mono .NET implementation which was on top of the FreeVM project. FreeVM would have the freedom to change the bytecode format, greatly subset the class library, etc. It would have direct participation from other communities besides Mono-the-.NET like Python,Tamarin,and ideally even Java.
The key again is to get buy-in from the actual upstreams; get commitment to modifying the upstream "Python 4000" compiler to emit FreeVM bytecodes, share a class library etc.
I could understand you saying you don't really have the resources to do it - it would be a massive undertaking, and a lot of that would be pure politics, not engineering.
But it does make me sad that the team is apparently going all out on increasing Microsoft's hold on the web via Moonlight, rather than something like this.
(Anonymous)
Re: Mono's future.
On Moonlight, I do disagree, and I have explained my position in a few other places.
Silverlight succeeding or failing will happen with or without Moonlight's help.
I happen to find the technology fascinating myself and I love it, but I also believe that it is crucial that Linux does not become a second class citizen in the web in the case where Silverlight *does* succeed.
Miguel
(Anonymous)
Frameworks
It would be awesome to have VM container services for managed JDBC (connection pools, statement caches, ..), work managers (asynchronous beans for work queues), web services, and so on. Take a look at any commercial better J2EE platform. The amount of goodies they offer really makes the life easy. No, it's not just having a framework or a library for task X. It's about being managed. These containers look after those services rather well, especially when you work with large environments (100+ server clusters etc).
(Anonymous)
tired coder
Large scale (system) programming on Linux today basically boils down to C++, because practically all libraries are in C, if not, it's C++. Language bindings are not always there, are often badly designed (too C-ish) or are simply unmaintained. And there's more, gdb doesn't support C++ all that well either, for example it has zero support for throwing exceptions (yeah, setting breakpoint on cxa_throw does not count).
(Anonymous)
Re: tired coder
I wouldn't write C/C++ anymore and the bindings are considered usually 3rd class citizens by both the C/C++ library developers and the developers of the higher level languages that I would like to use. On top of that the documentation is simply poor and mostly just refers to the C/C++ library's documentation - which you have to apply yourself in C/C++ish way. Which doesn't really fit into the rest.
On top of that the "best of breed" (most commonly used) languages such as Python, Perl and Ruby do not have built-in support for anything really interesting. Especially the lack of GUI toolkit support is lethal to the mass adoption of these languages... You got to usually to make anything worthwhile install a bunch of binding libraries and pray that they work (also in the future). Appalling and painful, say I.
So I'm back to doing other stuff. Time after time. Anything but NOT software for Linux desktop. Web based information systems (Rjango/RoR), Java/Swing applications (usually targeted for Windows users really) and such. Bah.
Some years ago when C#/Mono was new idea there was even talk of "converting all of Gnome into C#". Naturally the general change resistance and lack of vision killed that very fast. Shame, it would have really been the best thing ever to happen for Linux desktop development and Gnome.
(Anonymous)
D programming language?
http://www.digitalmars.com/d/
Re: D programming language?
What we should have is a common bytecode format and runtime VM between languages like Python, Java, Ruby, and C#. Then when say a Linux kernel programmer adds a new API for receiving signals on a file descriptor, or whatever, someone can write the library *once* for the common bytecode format, and every sane language can leverage it.
(Anonymous)
Re: D programming language?
The other problem is that language designers insist on separating the language from the development environment, rendering their languages static and early-bound in some respects of behavior.
VM services such as garbage collection, dynamic compilation, object models etc, would be better provided by the operating system itself. The VM should be the operating system, and vice-versa!
One of the pioneering VM-based languages, Smalltalk (appeared circa 1980 at Xerox Parc), was basically an operating system in itself. Despite its design being nearly 30 yrs old, it is still more powerful and expressive than Java, C#, or Python (yes - no exaggeration). Smalltalk users could do amazing things like editing programs whilst they were executing (now recently re-invented as "hot-swapping"). Then there are other cool things. Monticello, a VCS for Smalltalk, records _semantic_ changes in the program, rather than dumb textual changes like git or bzr. You can only do these things if the language is integrated in all respects with its immediate environment.
So here's my heady vision for a new computing model: A very small operating system kernel such as MINIX [1], providing a few essential services, and nothing else. On top of that, a VM layer [2] providing the usual VM services and development API. This design will most certainly disenfranchise C and keep it where it belongs, in the very low-level OS and VM-bootstrapping arenas.
1. Linux is a non-starter here, it's a re-invention of technology rooted in the 1960's. Even the original designers of UNIX have moved on to better things such as Plan 9.
2. Some great VM research from the original Smalltalk designers: http://vpri.org/html/work/ifnct.htm
(Anonymous)
Parrot
If running Ruby/Python/* on another runtime was that much of an advantage over running it on the upstream ones, the alternative implementations would have beaten the upstream ones handsomely in no time. Curiously enough, they haven't so far, and I don't see a particular sign that they will.
(Anonymous)
We need to raise the boundary a little, so we have single a unified calling and memory model. We can thus avoid marshalling, low-quality language binding generators and crappy local garbage collectors. Probably the easiest way to ensure calling and memory model compatibility is to simply compile to common virtual machine language.
I firmly believe, that the boundary will move up sooner or later, just like it did in the past (asm -> C). What are we going to do about it?
(Anonymous)
But you can't avoid, for example, marshalling between types for different languages, calling conventions, etc., simply because the language specifications differ at fundamental levels.
(Anonymous)
http://en.wikipedia.org/wiki/Marshalling
= copying objects
If we agree on at least basic properties of objects, we don't need to copy them.
One can also go further and just define the basic set of classes. What benefit do you get from writing your own vector, btree, HTTP parser, XML parser...? Even Python and Ruby share some common libraries written in surprise surprise - C!
I say, this is just backwards. I would like to write code and to be reused by someone else. Right now, I am forced to write it in C if I want reach everyone, then write bindings although my code (even though it's C) already contains classes and methods! Of course, I can't rely on garbage collector either, although most of potential users have garbage collectors in their language.
As you said, we already have the tools to make it happen, we just lack the vision.
And you know what? Screw this shit. I am going back to write code for Qt in C++, it is portable, fast, has reasonable support for memory management and classes. And everyone can be happy now with their own runtimes without my code polluting their ivory towers.
I would argue that the first reason is simply because those communities are divided on whether to target .NET or the JVM.
The fact that until very recently, the JVM was not Free greatly hampered adoption. And of course, .NET has politics (well, so does Java).
The fundamental point is that both Python and Ruby *are* running on VMs. They're just crappy ones, albeit optimized for the particular language. That's doesn't seem sustainable long term to me.
The basic thrust of my post though was to imagine what it would be like to try to turn Mono, which has a liberal licensing and has been part of the Free Software community for a long time, into a unifying framework both technically and politically.
I am kind of sad to hear from an OpenJDK developer that the future is multi-runtime! You can't dream? =)
Even if all the free runtime projects for different languages tomorrow said 'let's throw away the years of our own independent work that work so well for our users that we are successful enough that fans of other VMs care about us running on their VMs, and rewrite everything to run on top of the JVM to make the FreeVM dream come true', that would still leave Microsoft not using the same runtime as they do. Is Microsoft going to switch to the JVM? You go ahead and make 'em, I'll cheer you on. ;)
But let's be even more optimistic, and let's assume that instead of the JVM they switch to Mono or DotGNU or some other free software CIL runtime, and that all free software JVMs are rewritten to run on top of CIL runtimes.
Let's for the sake of argument assume that Mono is that silver bullet. Then, given all of its silvery properties, the liberal licensing, technical and political awesomeness, the always superior open source development model, Microsoft will surely switch to Mono. In fact, as all of these silvery properties hold already today and are the reason for the other implementations to switch, surely Microsoft has already switched to the wildly superior Mono runtime.
Ah, wait, they haven't. Funny thing, that.
That's the basic problem with the premise: if not even the C# implementations (Microsoft, DotGNU, etc.) can agree on a single runtime, where the switching cost is as low as possible, then it's very unlikely that all the implementations of other languages, with the orders of magnitude higher switching costs, would agree on a single runtime.
Replace C# with Java to make the same argument about OpenJDK & the JVM.
The economic, social, and political costs of a revolutionary switch to a completely different VM are immense. Perl6 is a great warning example against relying too much on the power of self-fulfilling prophecies.
The alternative is a process of reforms.
If, say, there was a set of libraries for GC, JIT, interpreters, threading, and all the other runtime housekeeping tasks, and they were clearly superior to what's used in all the VMs today, and easy to switch to, and well maintained, and tested, and so on ... then you could, gradually, build up a collection of runtime components everyone uses.
Alas, would it make sense for Mono or OpenJDK or $random_other_existing_runtime to throw away its own JITs, GCs, etc. and switch to inferior solutions now for the sake of convergence? Probably not, or they would have done so already. So your only hope for convergence lies with runtimes that have not been written yet, which, funny enough, adds to the cacophony of existing runtimes. ;)
The other alternative is to see if the alternative language implementations on top of VMs ever manage to make those dreams come true. Empirically, the evidence points to alternative implementations having a hard time displacing reference implementations, from Kaffe vs. JDK, over Mono vs. MS .NET, to all the J* & Iron* implementations vs the upstreams.
I'd disagree that they have failed, fwiw, any more than Linux has failed to displace OS X, or Wine has failed to displace kernel32.dll. Unity through displacement of alternatives is more of a nightmare, than a dream, in my opinion.
Remember though, it's not that important if Microsoft doesn't switch. Because if Mozilla joins forces, then at least personally, I'd have no problem requiring Firefox to be installed on Windows and OS X so that the Free/SharedVM was there. Probably you'd have to ship some extra class libraries with your app, but no big deal.
Your points about no projects switching for technical reasons seem right. But what I think *may* be possible is projects unifying for technical AND political reasons.
Thanks for the thoughtful reply!
Even then, not even DotGNU has switched to Mono, even though as an FSF project implementing .NET, they should be more fond of political reasons, than Microsoft.
If it doesn't even make sense for DotGNU to switch to Mono, I don't see how it would make sense for Firefox to rewrite their code from scratch for some political goal. Alternatively, how about rewriting Mono from scratch in ECMAScript so that it can run inside Firefox? It doesn't make sense to me, but it meets the political goal of one VM to run them all, the ECMAScript VM inside Firefox.
I hate to be the guy smashing dreams here, but maybe the 'common shared runtime' thing is less of an actual technical problem waiting for a solution, and more of a social problem with the world domination plan for Free Software taking a bit longer than everyone hoped, and turning into a bit of head scratching as its banner carriers get into their 30s, a la "Why is this taking so long? Because everyone is not united behind my project/plan/thing! Come on, folks, get on with it already!" ;)
In reality, the future is happening so fast today, in part thanks to Free Software, that people with a great master plan are bound to be overrun by it. And that's a very good thing, in my opinion. The best way for Free Software to 'win', is to have many good futures to pick from.
Remember the "Network Object Model" part of GNOME? ;)
Now on Mono-in-ECMAScript, have you looked closely at Tamarin? http://www.mozilla.org/projects/tam
While presently it is designed for execution of JS, they have plans to translate .NET bytecodes to Tamarin bytecode so they can execute IronPython/IronRuby:
http://arstechnica.com/journals/linux.a
So actually, it's already in Mozilla's plans to be a common VM for multiple languages. Though realistically, they will probably focus mainly on JS.
On DotGNU - I think Mono has won. Look at the DotGNU mailing list archives for the entirety of December:
http://dotgnu.org/pipermail/develop
More tellingly there were NO posts from October or Novemeber.
On "NOM" - for sure, plenty of times we've thought before of some grand unifying idea only to have it flounder. A lot of times, the idea really was bad. Like CORBA.
But not all of these ideas are bad. One problem is that the kinds of people who have Big Grand Ideas are also the kinds of people who tend not to think about Details. Like licensing, or good backwards compatibility with previous systems.
One project that has been fairly successful at its goal of allowing disparate systems to talk in a basic way is DBus - it had practical licensing, and the developer explicitly reached out to KDE to make sure that it would have compatibility with their previous DCOP system.
I agree that multiple futures are useful to have - but I still have the sense that there is an opportunity out there for a practical project to try to help some of our futures collaborate. You are right though that the hurdles are huge.
We'll see...for my part I'll be closely watching the Jython/IronPython progress so I can get Real Threading and a JIT for my shell =)
common shared library idea
i think this simply cannot work nicely.
it's not even a technical problem.
the problem is, that when you have different programming languages, they also have different function-naming-standards, and sometimes even different execution-styles etc.
for example, imagine that you do have this shared library, and you can access it from both python and java. some issues:
(or look at haskell, which is a lazily-evaluated language...)
a programming language is not just the language-core. it's also it's standard library, which imho should be written in the way that it's natural for the given programming language.
Re: common shared library idea
The differences between the languages also make implementing them on top of the a single shared VM is very hard. IronPython and Jython developers spend a lot of time fighting against their respective VM's semantics because those don't quite fit that of Python. For that reason the JIT of those VMs is also not helping Python too much. Those JITs are not at all optimized for the sort of bytecode that Jython and IronPython produce. Python needs a very different sort of JIT than Java (Psyco is completely unlike most other existing JITs).
Re: common shared library idea
You can translate from one to the other transparently (though I think Python is wrong here and should be using camelCase. And I say that as someone who's written many many thousands of lines of Python and likes most of the language).
"java does not have functions, only methods"
No one said the common underlying bytecode had to be exactly Java.
"it's also it's standard library, which imho should be written in the way that it's natural for the given programming language."
Right, and Haskell's very small standard library and 3rd party library availability is one major thing hampering adoption. Realistically, nowadays people expect a *lot* from their language. HTTP server, good XML things like XPath, etc.
(Anonymous)
Re: common shared library idea
Also, I think that adding mutable/dynamic classes is not impossibly hard either - JVM people are doing it right now I believe.
Now if you start including haskell, it can pose a real problem. I'm not even sure, that haskellers themselves know how to implement (in elegant & efficient way) everything that is being written in more traditional languages.
I'm pretty sure, that we can make some workable compromises here and there in order to keep moving forward.