"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.

Search This Blog

Thursday, December 09, 2004

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.


Anonymous said...

Hi Patrick. I read both your and Tim Bray's posts on the work that is being done to bring better support for dynamic languages to the CLR and JVM and I started wondering: what exactly is the benefit of being able to run a variety of dynamic languages on either of those platforms? It seems to me that moving forward the most meaningful common runtime environment, for any application written in any programming language, is the network and its associated protocols (TCP/IP, HTTP, etc.).

Dodge This said...

yes I agree that as long as the code spit out the same bytes over the network, any language can be used to achieve that. However I think folks here consider it is better to use dynamic language such Jython, Groovy to acheive that since it is proven to be much more productive for developers. Now they are working on details in terms JVM support. Guess what? Microsoft hired Jim H a few ago to work on .Net CLR too.

Blog Archive

About Me

Portland, Oregon, United States
I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.