[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: .NET CLR? was no subject

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.
In particular:
(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,
    and performance
(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?
----- Original Message -----
Sent: Wednesday, March 06, 2002 11:10 AM
Subject: .NET CLR? was no subject

Sorry for the useless message.  I had trouble frazing my question and it
was late, my brain was frized,...  So, i'll try again.

I've been trying to formulate an opinion about Java vs C#.  I started with

http://www.prism.gatech.edu/~gte855q/CsharpVsJava.html which is fairly
detailed comparison.

The differences seem mostly annoying, though two things seemed interesting:

T1:  Multilanguage support through the Common Language Runtime (CLR).
This paper:
http://research.microsoft.com/~emeijer/Papers/MondrianDDJ.pdf about the
functional language Mondrian shows a nice example where a C# program
invokes an iterator which is really a Mondrian infinite list.  So, i can
imagine using Mondrian to do parsing for a C# program - Cool!

However, http://www.javalobby.org/clr.html suggests that a language, say L,
becomes L#, a hybrid langauge, with C# warts or performance
limitations.  The article even quotes David Simmons about Smallscript.

T2: attributes.

C# code can contain attributes that become metadata that can be used by the
runtime system.  For an aspect oriented example see:

So the questions are:  Is CLR a good thing from a language implementation
point of view, ie, are you better off than implementing a language in Java,
say?  From a programmers point of view, does programming in multiple
languages with a common runtime help?  Would you program in multiple languages?

How good is this metadata idea?


At 04:05 AM 3/6/2002, Vladimir G Ivanovic wrote:
>"KA" == Ken Anderson <kanderson@bbn.com> tests the waters with an empty
>Yes, the list itself is alive, but the members are dormant ;-)
>Last I remember, Matthias was going to post something or other.
>--- Vladimir
>Vladimir G. Ivanovic                        http://leonora.org/~vladimir
>2770 Cowper St.                                         vladimir@acm.org
>Palo Alto, CA 94306-2447                                 +1 650 678 8014
>"MF" == Matthias Felleisen <matthias@ccs.neu.edu> writes:
>   MF> That's not how I would have explained the difference. Consider this.
>   MF> Here is how you define the-current-continuation:
>   MF>  (define (the-current-continuation) (call/cc (lambda (x) x)))
>   MF> Now implement call/cc. Hint: The solution is in one of my early papers,
>   MF> including calculations. Hint-: It's not in the on-line biblio we just
>   MF> saw. So don't peek :-)
>   MF> More tomorrow -- Matthias