My non-CS background is making it difficult to grok the .Net CLR.
I can understand the "multi-language support" provided by your favorite
hardware's instruction set (Sparc, Pentium, etc.).
But what's the "cross-language support" promised for a CLR.
(a) what is the "killer app" for a CLR?
(b) why does said "killer app" require a CLR?
(c) how one can expect a single CLR efficiently to support
the particular idiom(s) of divers languages?
For the jvm I would answer thusly:
(a) application portability (smartcards to mainframes)
(b) new hardware abstraction supporting safety, concurrency,
(c) jvm appears in two distinct versions: client and server, since
even for the same language different usage patterns demand different
engineering tradeoffs. I would expect that different languages
have usage patterns that differ even more -- creating severe
tradeoffs for any CLR implementation.
Also crucial from an enterprise-application standpoint is the question
of maintainability. The "language promiscuity (tm)" promised by the .Net CLR seems
at variance with maintainability; who's got the skillset to debug that vb#
control multiply-inherited so easily from an eiffel# class and a managed C++ class?
I think the javalobby.org soundbite about the .Net CLR as a platform for
"skinnable languages" was clever.
"Apple" <=> "Pomme" <=> "Apfel" ... sure; but have you ever read those
on-the-fly babelfish translations of webpages written in French or German?
[How will the oeuvres of our functional-language code poets fare in .Net CLR translation?]
Given engineering tradeoffs, the .Net CLR will be optimized for C#; do we then believe
that C# is the "center of balance" of all interesting and desirable language features?
So who can elucidate the (a)-(b)-(c)s of the .Net CLR?