Something Different

Ian Bicking in a comment captures the problem better than I have...

The CLR is trying to do something difficult. It's not just the kernel upon which languages can be built, but an infrastructure so that languages can be intimately combined. I suspect that there are some combinations that are poorly thought out. For instance, I don't think cross-language inheritance is useful or productive -- better to provide good alternatives (e.g., delegation); language implementations can pretend those alternatives are subclassing if they really desire to.

But cross-language data sharing, including the sharing of objects, is quite important. You can't do that without some significant spec. Now, it might be a better, more evolutionary approach to put different languages on the same VM, and let them figure out the interoperability issues later. But even though that's a different process, it just delays the work, it doesn't remove it.

Data sharing is important. But why this way with the VM and another way outside the VM? The essence of running a common runtime was interesting about 15 years ago. See the late Mark Weiser's work at Xerox on the Portable Common Runtime. This approach addressed the *critical* issues of sharing a common runtime. There may be one or two other critical issues, but they don't require a common object model. The CLS object model in practice turns out to have some uncommon and subtle anomalies; it's a hard problem for questionable results.

A third approach to language interoperability is to standardize on a common intermediate form. This is a variation on the privileged language approach, permitting different languages to interoperate as long as they use a common back-end. In spite of several attempts in this direction, the restrictions on language designers and implementors have proven too severe for wide adoption. We hope our more modest approach (agreement on important parts of the runtime environment), by analogy with the success of common operating systems, will prove better in practice...

PCR itself is about 20,000 lines of C and about 200 lines of assembler.

A good bit simpler than the CLR. Someone didn't get the memo.

The problem with the complexity in dotnet's CLR is that it's not addressing the *right* problem. Compare this to Erlang, Indigo, REST, and other simplifying approaches to "postmodern" programming. Agile software demands we keep our options open and avoid premature commitment to unnecessary complexities.

To repeat a quote from Dan Ingalls, below, "You clearly want the kernel to be as small as possible, so that you encounter barriers to change as infrequently as possible."

I agree with everything Ian writes here... and at the same time I don't feel Microsoft should get kudos for tackling the problem itself. They made the wrong choice to address the problem by overcommitting the kernel of the solution to ideas that just don't pay off in practice.

Simplicity, stratified design, regularity, small pieces loosely joined.