Polyglot Programming

It seems that Microsoft's .NET platform has made it much easier to mix and match programming languages. I guess this is old news to some, but I still think it's pretty interesting.

Meyer begins:
Let's start with the impolite question: Should one really care about multilanguage support? When this feature was announced at .NET's July 2000 debut, Microsoft's competitors sneered that it wasn't anything anyone needed. I've heard multilanguage development dismissed, or at least questioned, on the argument that most projects simply choose one language and stay with it. But that argument doesn't really address the issue. For one thing, it sounds too much like asserting, from personal observation, that people in Singapore don't like skiing. Lack of opportunity doesn't imply lack of desire or need. Before .NET, the effort required to interface modules from multiple languages was enough to make many people stick to just one; but, with an easy way to combine languages seamlessly and effortlessly, they may—as early experience with .NET suggests—start to appreciate their newfound freedom to mix and match languages.

This has the potential to help a lot of obscure languages that have been hindered by poor library and runtime support. As Meyer writes:

...The practical advance of new language designs has been hindered by the library issue: Though you may have conceived the best language in the world, implemented an optimal compiler and provided brilliant tools, you still might not get the users you deserve because you can't match the wealth of reusable components that other languages are able to provide, merely because they've been around longer. Building bridges to these languages helps, but it's an endless effort if you have to do it separately for each one.

It's worth noting that every language that has been successful in the last few years has had very good library support. Perl in particular has lots of libraries available through CPAN, the hacker's friend. Java has a huge anstandard library available from Sun.

Basically, .NET allows an astonishing amount of code reuse between different languages. Specifically:

• A routine written in a language L1 may call another routine written in a different language L2.
• A module in L1 may declare a variable whose type is a class declared in L2, and then call the corresponding L2 routines on that variable.
• If both languages are object oriented, a class in L1 can inherit from a class in L2.
• Exceptions triggered by a routine written in L1 and not handled on the L1 side will be passed to the caller, which—if written in L2—will process it using L2's own exception-handling mechanism.
• During a debugging session, you may move freely and seamlessly across modules written in L1 and L2.

This is an amazing amount of inter-operability, similar to being able to use Honda parts on your Ford engine. In particular, objects in one language can inherit from objects in another languge. I suppose, theoretically, you could have an object where the parent class was in c#, the derived class was in Eiffel, and another derived class was in F#.

You have to make some compromises to get this kind of interoperability. Specifically:

• Eiffel and C++ allow multiple inheritance; the .NET object model (as well as Java, C# and Visual Basic .NET) permits a class to inherit from only one class, although it may inherit from several interfaces.
• Eiffel and C++ each support a form of genericity (type parameterization): You can declare an Eiffel class as LIST [G] to describe lists of objects of an arbitrary type G without saying what G is; then you can use the class to define types LIST [INTEGER], LIST [EMPLOYEE], or even LIST [LIST [INTEGER]]. C++'s templates pursue a similar goal. This notion is unknown to the .NET object model, although planned as a future addition; currently, you have to write a LIST class that will manipulate values of the most general type, Object, and then cast them back and forth to the types you really want.
• The .NET object model permits in-class overloading: Within a class, a single feature name may denote two or more features. Several languages disallow this possibility as incompatible with the aims of quality object-oriented development.

So multiple inheritance and genericity are out.

Microsoft has always tried to control the infrastructure of the computer business. Back when that meant writing implementations of BASIC for primitive 8-bit CPUs, that's what they did. Later, they graduated to DOS and Windows. And they have always tried to control compilers and other development tools. The .NET platform can be viewed as just another example of this tendency.

It used to be development was simple: you had a CPU, and some assembly language code. Now, you can write your code for any one of a set of overlapping layers of abstraction: the operating system, the web browser, or the virtual machine (.NET or the JVM). And Microsoft now controls all of these things, to a greater or a lesser degree. Where do you want to go today?

Oh well. Hopefully, languages like OCaml and Smalltalk will get a second chance through .NET.