Re: .NET CLR? was no subject

[Anton van Straaten <address@hidden>]

Robert Spector wrote:

 > My non-CS background is making it difficult
 > to grok the .Net CLR.

Not sure it's a CS issue, exactly - it may be more of an MBA issue.

 > But what's the /"cross-/language support" promised for a CLR.


To summarize my rather long story below, "cross-language support" is 
needed for a CLR because it is required for any operating system, and 
the CLR is essentially a new operating system.  The question is whether 
the CLR makes sense as an operating system, and why it needs to be an 
operating system.  I've provided a lengthy perspective on this below 
(brevity takes time).

 > (a) what is the "killer app" for a CLR?
 >

 > (b) why does said "killer app" require a CLR?


The killer app for a CLR (or, to some extent, a JVM) is many, many 
existing applications.  Ignore for a moment the more direct answers you 
might get from the MS marketing department, about how .NET enables web 
services, etc. etc.  A much more fundamental and important issue is the 
fact that to be productive, programmers need lots of support from their 
tools.  Traditional operating system APIs are too primitive, and you 
can't fix that properly with a bunch of disconnected framework 
libraries, or in each language individually.

To really understand this trend, you need to think back to the Sun hype 
for Java, which contains a large measure of truth: the JVM provides a 
"platform", just as surely as Unix is a platform or Windows is a 
platform.  You write code to a platform's API, and that code will run 
anywhere the platform is available.  However, platforms like the JVM and 
.NET go much further than operating systems do: they provide automatic 
memory management, high-level transaction and management services, and a 
whole slew of other support which a traditional operating system 
(platform) would have a hard time providing to an application developer.

A big reason traditional OSes can't easily provide such services is 
their object model, or lack thereof: traditional OSes are low level, and 
their APIs are very primitive - they typically expect C data types as 
arguments, at best providing simple record-style structures.  This 
allows anything from C on up to interface with them, and it keeps things 
simple in some ways, but it also means that programming to the OS API is 
a tedious and relatively unproductive business.

Taking this up a notch, by allowing applications and the platforms on 
which they run to communicate at a higher level, requires a fundamental 
change.  One way to do it is by having the platform support a more 
sophisticated kind of object, for example objects that have 
tightly-coupled, encapsulated behavior, polymorphism, inheritance, etc. 
etc.  But if your platform is going to support such objects, it either 
has to use a very agnostic object model interface - like CORBA or 
COM/DCOM/COM+ - or it has to dictate an object model to the applications 
which run on it - like the CLR or JVM.

The CORBA/COM model has already been tried, and although very useful in 
many scenarios, for the purposes I'm describing - providing very high 
level application services to developers - it has essentially failed.  A 
big reason for that failure is exactly the issue which the CLR 
addresses: there's so much disparity between the languages supported by 
systems like CORBA or COM, that accessing objects using those systems 
was almost never natural, and instead of simplifying the developer's 
life, they complicated it.

In the sort of distributed systems for which CORBA was originally 
designed, this was not necessarily a big deal, since a different problem 
was being addressed, that of distribution.  But independently of fully 
distributed systems, the need for a higher-level standard object model 
is great, and the use of COM within Windows, and CORBA within Gnome, 
demonstrates this.

But as I've said, use of these object systems didn't necessarily make 
life easier overall for the application developer.  The pendulum was too 
far over on the side of object representation agnosticism - you could 
implement objects any way you wanted, as long as you provided the 
appropriate interfaces.  But this produced many restrictions, 
limitations, and complexity for the applications which had to implement 
and use those interfaces.

With CLR and (unofficially) the JVM, the pendulum has swung the other 
way: by the draconian imposition of a single object model, as well as 
all the other important runtime structures and services, one achieves a 
kind of unity and transparency in cross-language and cross-application 
communication that's much more difficult to achieve otherwise.  Yes, it 
comes at a cost - perhaps a terrible one, depending on one's 
perspective.  But for many, the benefits may be even greater - the 
ability for developers to rely on a usable and consistent set of 
high-level services that extend across languages and tools.

So the short version of what I'm saying, which is nothing new but often 
seems not really to be believed or understood, is that the CLR and the 
JVM are both new kinds of operating system, or if you like, the 
extension of existing OSes to provide much more sophisticated 
application services.  Microsoft certainly looks at it as an extension 
of the OS.  Thinking a little about the strategic advantage that such a 
ubquitous system is likely to provide, when integrated closely into the 
underlying OS, should warm the hearts of any antitrust lawyers paying 
attention...

 > (c) how one can expect a single CLR efficiently to
 >     support the particular idiom(s) of divers languages ?  


When looking at the limitations of the CLR as it currently stands, it 
should be kept in mind that this is one of the earliest systems of its 
kind.  It'll improve, and it might even get some competition, which 
would help evolve the field (is Sun paying attention to this space?)

Eventually, the "skinnable language" criticism may very well be 
addressed - it's technically very possible to do, just more complex to 
implement than what Microsoft was able to do in this initial version.  A 
similar criticism could be made of a traditional OS: you can interface 
to it in any language you like, as long as you behave sufficiently like 
C.  CLR changes that to say you can interface in any language that 
behaves sufficiently like C#, and oh by the way, if you implement your 
language on the CLR, it *will* behave like C#.

Just to be clear, I'm not attempting to promote the CLR specifically 
here, or defend its particular shortcomings - rather, I'm saying that 
systems of this kind are a fairly natural evolutionary step in the 
provision of system services to applications.  If the CLR fails, it will 
only do so because something else does a better job of addressing the 
same basic set of requirements - that of providing more powerful and 
integrated application services across a diverse range of languages, 
tools, and applications.

Anton