From what I understand from the various reading that I've done on .NET (and I'm not claiming to be an expert, by any means) is that within the actual compiler for your langauge of choice, everything is pretty much open. Since the "byte" code is "complete," it should be able to handle pretty much any langauge. Of course, that's assuming that some sort of mapping by the compiler to the "byte" code exists. For some dynamic languages, they may get neutered in order to fit properly (like dyanamically redefining the class interface, or whatever). That's part one. Can it be translated such that it can be run by the CLR.

The next issue has to do whether it can be accessed externally by other .NET components. This includes features like inheriting from langauge A to language B across assemblies. This is where languages basically get neutered to be seen the same way. There's not a whole lot of difference here between the way COM works (it's a C-like interface). That's not to say that it's not an improvement over COM, because it is (you can't inherit a COM interface, for example). But, it does mean that langauges won't be able to be seen external the same way they are seen internally.

So, from my perspective, the whole multiple language thing is cool, but slightly misleading. First, there's a mapping of your language to run on the CLR (internal view). This removes *some* functionality from most all languages (or, at least, some modifications). This is *not* the same as the difference between managed and unmanaged C++, though (unmanaged C++ is like using JNI in java....it gets compiled to the machine and runs outside of the CLR). Second, there's the external referencing of assemblies (components, etc. get compiled into an assembly, similar to a DLL). There's nothing horribly new here, other than the improvement of that interface (i.e. inheritance). There's still the issue, for example, of case-sensitivity between languages.

Bottom line: it's definitely an improvement over COM/COM+/DCOM/etc., but it's not earth shattering. If I were MS, I'd have done the same thing (assuming I was smart enough to come up with the idea in the first place, which is debatable). On the one hand, it allows them to create a common view of their OS. On the other hand, it allows them to compete against Java on the server side (and other server-side development languages, too, such as PHP, Zope, ColdFusion, etc.).

I consider it a brilliant move on their part (under the circumstances), but it's not as *cool* once you get into the details and discover that, by "partnering" your language with MS's .NET to allow you to run there, you're really not getting what you think. It's that whole partnering with MS thing, again.

Dan Shellman