[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: .NET CLR? was no subject
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,
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
> (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.