With IronPython 1.0 out, I was thinking of some of the issues of supporting multiple languages in a runtime environment.

I'm not sure what the right strategy is. I'm not very drawn to IronPython, though maybe in time that will change. Out of laziness alone I'm not inclined to figure out the installation and version issues of running IronPython with Mono, and since I don't use Windows that's the only way I'd use IronPython.

But I'm also not that enchanted with multi-language runtimes. It's nice, but complex, and I seldom find myself wishing that I could use more complex systems. IronPython opens up a whole new world of complex (.NET) systems to me as a Python programmer. Which isn't what I was looking for. Now maybe a .NET user will now be able to use a simpler Python environment, but that isn't me.

But what about Parrot or HLVM? These are (or rather want to be) cross-language environments for dynamic languages, and could introduce an environment that is more interesting to me than .NET (or the similarly uninteresting JVM). Python people are always saying that they wish they could have CPAN. I should qualify that I am not always saying that I wish I had CPAN, but maybe those other people have some point.

But seriously? I'm just going to go to CPAN and pick out a nice module and start using it, just pretending it is a normal Python module? Is it just me, or does that sound absurd? I'm sure there's good things in CPAN, but I really am not looking for more complexity in my life, and that's all I see down that path.

It occurs to me that there's a different method of interoperation, but one that isn't being pursued. I've had a passing interest in Erlang, and came upon this article recently, which describes the Erlang concurrency model in a fairly simple way (and using only Java-ish code, no mention of functional programming or any of that).

Erlang processes generally communicate with other Erlang processes in a homogeneous environment (note: Erlang processes are not OS-level processes). But each process doesn't know a lot about other processes. There's no reason they all have to be written in the same language.

You avoid a lot of hard issues this way. You don't share data. Are strings mutable or immutable in your language? It doesn't really matter -- since you never share strings (or anything else). What does the object model or inheritance look like between languages? It doesn't really matter, since you don't really share objects. Private, public, protected? Doesn't matter. Things actually become less complex, not more complex.

You could do this now with OS processes and sockets, but most language runtimes aren't set up to deal with this kind of process model very well. Processes should be really light, lighter than any OS process or thread. It would be really helpful to have shared memory with copy-on-write, so that you don't actually have to duplicate all the data sent in messages. And there needs to be a common message format, plus library support in each language.

I'm not sure what all the implications of such a system would be. But I'm pretty sure it's a system that would actually be attractive to me -- not in a theoretical isn't-it-nice-that-exists sense (which is the only attraction I have to IronPython), but in a I-want-to-use-that sense. I don't want more options and more features; more is tiresome, I'm really just interested in better.