Havoc Pennington has written an article on the future of languages on the open source desktop. Everyone's having their say, so I thought I would too.
I feel it's missing the point or something. He's looking towards deciding what will be the higher-level language to replace C. However, people will always want to write code in a their favourite language (or even... a language appropriate to the task at hand). This isn't just talking about possible future languages for writing parts of the core gnome system, although it may eventually move to that. It's about random external programmers who want to build on the gnome libraries.
So, gnome has a standard for linking things together: standard object files and C linkage conventions. This is fine as long as all the libraries are written in C (or can export a C API), and every language you use to create application has people patient enough to knock up bindings. This is somewhat sub-optimal.
First, these interfaces are often not naturally expressed in C. Many of them are object-based. Yes, C can be mangled to deal with this, but it is a hack. Second, interfaces can get complicated. If you want to pass things across the interface, you've got to match them up somehow. Do you want to pass things by reference? Data structures that you may then wish to traverse? Starts to look like you're opening a whole can of worms. Once you start creating libraries using higher-level languages, it starts to look messier and messier. Do you really want a library that has its own runtime system? Multiple libraries, each with its own runtime?
I think this is where .net starts to look good. It defines a way of linking things together, at a much higher level than C. It provides a way to pass complex data structures around. It provides a runtime environment, so that garbage collection and so on doesn't have to be reinvented all over the place. The unmanaged code aspects make it possible to support C-like code. Stuff like IKVM makes it possible to run Java on .net, something that looks rather more painful the other way round.
.net is obviously no panacea. It is good for Java and C#-style languages, and can cope with C and most of C++. Fundamentally, it's only good at, what, the languages used for 95% of industrial programming. Functional languages, for example, get ugly. But what do you expect? Trying to write libraries with C interfaces in an obscure language, complete with runtime and bits of marshalling could be pretty horrific too. Moreover, it's still more or less possible - people have done it for a variety of weird and wonderful languages. And if everything gets too hairy, non-CLR languages could be bound to CLR interfaces just as C libraries are bound to non-C languages, except we should hopefully have a more expressive interface.
The CLR may not be the solution, but I think it's worth thinking about how you want to be able to link together libraries from a selection of languages. C is a solution, but a fairly weak one. I'm sure there are reasonable approaches involving IDLs, and marshalling, but it can get very complicated. And it's still not going to be as good as having a common linkage format and interfaces that actually say what they mean and use objects.
I fear that people mistrust the CLR as a MS invention. The Open Source community, often quick to deride companies as having Not Invented Here syndrome could be falling into the same trap. MS are heavily betting on .net. It gives them a common compiler back-end, and a single point to concentrate their optimisations on. They need not worry about upcoming platforms. Hello AMD's 64-bit extensions, hello ia64. And if they really want to, goodbye ia32. There are some very cool tricks that using something like .net allows. You can sandbox untrusted code, but have it linked directly to trusted code. Debugging can use a common infrastructure, and the extra type information should make life less painful. You want to write a compiler? No need to worry about optimising code generation. You want to write an interpreter? Emitting CIL should give you a free cross-platform JIT.
Having said all that, real-life .net will probably turn out to be irritating. Things won't work out right. People don't like the idea of using the CLR and playing catch-up to Microsoft. But if no similar system is used, we won't even be playing catch-up. The current compile-link-execute model is 70s technology. It's good 70s technology, but things have moved on. I think the VM stuff is mostly a red-herring, since executables can just be compiled to native code (even if it's described as a JIT 'cache').
We need a way of linking code from different languages together that doesn't suck. A runtime that prevents each high-level language from reinventing the wheel would be useful. In short, this is what the CLR provides, and this is what I think gnome needs. If the CLR isn't adopted, it should be because something technologically better is.