I've been thinking quite a bit about runtimes recently. It's an interesting topic in general, but I also have a more specific interest: I'm designing Fitz, a next-generation 2D graphics library, and I want this library to be as useful as possible. So I want to avoid gratuitous runtime incompatibility.
Bertrand Meyer's Polyglot Programming is a very insightful discussion of some of the consequences of Microsoft's Common Language Runtime (CLR). Here's a particularly interesting quote:
The language openness of .NET is a welcome relief after the years of incessant Java attempts at language hegemony. For far too long, the Sun camp has preached the One Language doctrine. The field of programming language design has a long, rich history, and there is no credible argument that the alpha and omega of programming, closing off any future evolution, was uttered in Silicon Valley in 1995. Microsoft's .NET breaks this lock.
Absolutely. What the CLR provides instead is a runtime hegemony. It seems to be a fairly high quality attempt, and is well on its way to achieving huge market share. The idea of a runtime hegemony provides almost all the advantages of a language hegemony, with the added advantage of providing a much easier migration path for components written in non-native languages to be assimilated into the runtime. Do note the echoes between Bertrand's discussion of libraries and Paul Graham's in Being Popular.
It remains to be seen, I believe, whether it's worth writing new CLR code in any language other than C#. It's a nice enough language, and you have the advantage of not having to worry about the language-to-runtime mapping Bertrand mentions towards the end of his essay. But other languages might turn out to provide compelling advantages over C# for this environment, and the CLR will, as Bertrand argues, support them.
There is now a flowering of thought, design, and implementation of runtimes on the free software side. This world is resistant to hegemony. Instead of one dominant runtime, we will see lots of different approaches. In the short term, this is a serious disadvantage compared with CLR, because it doesn't provide a good story for people (such as myself) who just want to write software. In the long term, I think, it could lead to much stronger working knowledge about how to knit together systems out of disparate components.
I'll list here a few selected projects I find interesting, with some comments focussed on runtime and integration.
- CPython. The CPython runtime is carefully layered on
of the C
runtime, supporting the highly dynamic Python, while
access to the wealth of C libraries. In fact, CPython + C
can be seen
as an "aggregate language", actually a fairly compelling
Other language implementations, such as Ruby, fall into this
- Pyrex. Pyrex is essentially a hybrid language with
semantics fairly similar to Python, but able to call C
we essentially have a 3-language aggregate, consisting of
Pyrex + C.
- Lisp. Lisp is a mature language, with mature, high
implementations. Most Lisp implementations provide a Foreign
Interface (FFI), which is capable of directly calling C.
details of the FFI tend to differ from implementation to
implementation, so you can't really have a Lisp + C
rather a family of CMUCL + C, AutoLisp + C, etc. See Design
for Foreign Function Interfaces for a much deeper
note Arc, which could well become the most compelling Lisp
- Parrot. See this interview
with Dan Sugalski for much more info on why Parrot is
- Ruby/Python. This project attempts to knit Ruby and
together. I'm including it largely because it illustrates
technical difficulties in integrating runtimes: the last
version integrates Python 1.5 (which uses reference
Ruby (which is fully gc'ed). It's relatively straightforward
integrate N runtimes when only one is gc'ed - it is the
all others are slaves. It's far harder to have more than
Ruby/Python seems not to have grappled with the problem yet.
- JVM (Java) + JNI. This is still a reasonable
implementations are still not very good. They will get there
Note also Jython, which knits the Python language into the
- Swig, an "interface language" for easy integration
scripting languages. One of the most fascinating aspects of
that a single interface can generate wrappers for many
- Corba. Most people these days use Corba to
quality network protocols, layered on top of IIOP. However,
one of the
original goals of Corba was to facilitate integration
between a number
different languages. It is a mature standard, and fairly
implemented even in the free world, but is fairly painful in
- Mono and DotGNU, free clones of Microsoft's CLR.
These projects have widely varying goals and ambitions. Some will no doubt succeed, others fail. I expect our community to learn a lot in the process. And perhaps, some day, programmers can sit down and write code without facing difficult decisions about which runtimes to be compatible with, and which to be incompatible with.
Update: Stacking them up: a Comparison of Virtual Machines by John Gough. A well-written, technical comparison of JVM and CLR.