.NET: some remarks

PB schizophonic@tiscali.it
Tue May 7 04:26:01 2002


Unfortunately I am lazy. This means that of the many
things I would like to do it happens I do just a little
slice. For instance, last 25 march I was in Cambridge
to attend the second Microsoft .NET crash course,
and I forgot to send a mail to tunicians and say that
if someone was around there we could meet and
have a beer. More, when I came back I decided to
write about my impressions of the crash course, but
actually I didn't. As I can do nothing now for the first
point (of course, I would be glad to share a drink
and a good chat with anyone coming here in Milan)
I will make something for the second. I will spend a
word or two, but almost surely more, on the personal
impressions I had of CLR, .NET and all that, hoping
that they will be in some way useful to someone.

So, it is clear that Microsoft is betting a lot on
.NET and all the related stuff. Among the many things
we saw, more or less interesting, I will focus on
C#, the language of preference for programming
the .NET platform, and on the CLR, i.e. the
core platform (Common Language Runtime).
The idea is somehow dual to that of Java: Instead of
having one programming language and a platform,
the JVM, runnable anywhere, Microsoft put the
slaint on the fact that the CLR is a platform for many
different languages, also for Your Own Lovely
Crafted Language. In facts, compilers for languages
different from Java have also been retargeted to emit
Java bytecode (Ada for instance), but more as an
effort of organizations not related, and AFAIK not
even supported, by Sun. Here we have the direct support
of Microsoft to research institutes and companies, not
to speak about direct efforts of Microsoft Research,
to interface with CLR languages like C++, Scheme, Haskell,
ML, Oberon and many others.
This thing left me a little dizzy. My impression is this: CLR
is a piece of foreing semantics, and they invite, for sake
of multilanguage integration, to put it in Your Own Lovely
Crafted Language, a sort of implant whose effects may
not be so pleasant, especially if your language's semantics
is *very* distant to that of CLR. How do CLR objects,
for instance, interact with C++ objects? How do two very
different object models - garbage collected the former,
not the latter, with multiple inheritance the latter, not the
former, possibly with genericity the latter, not the former -
live together? I am convinced that what makes the true
difference between programming languages, more than
syntactic sugar, is their semantics: Forcibly including a
Java-inspired, object-based semantics, this
is my impression, is like conforming to a common
bottom line, thus flattening differences between languages
and breaking, once more, ortogonality and internal
coherence. The most interesting examples of .NET integration
come from languages whose semantics is very distant from
the model proposed by CLR, namely ML and Active Oberon/
Zonnon. In both cases, tradeoffs had to be established between
"embracing" (creating wrappers for foreign features) and
extending the language.
The payback, on the other side, is that if
you implant this piece of semantics in your language,
magically you gain access to all the features of
the .NET-aware Microsoft products. As a example,
they showed an ASP page whose server-side code
was written in Cobol. I think that many researchers will include
.NET support in their languages just to transform them
from niche products to potentially industrial ones - of course possible
only if you commit yourself to Microsoft world.
(BTW: CLR has support for tail call, but no support for runtime
first class functions, closures and parametric polymorphism.
Some of these features may be included in next versions,
especially the latter - at least, so I read).

What is the role of C#? It will be the main language supporting
the platform, and thus - AFAIK - the testbed of all the features.
Not much to say, it is a Java cleaned by some idiosincracies
(like package management, replaced by C++-like namespaces),
with some idiosincracies of its own (variables redeclaration is not
allowed in blocks, with the exception of loop variables... why?),
some more or less questionable (all the exceptions are unchecked)
and some nifty feature like delegates (method types and variables),
which make the threading APIs nice, and full monitor support.
Anyways, not too much to justify yet another programming
language IMHO.

Finally a word should be said about reflection APIs,
particularly the code emit API which supports runtime bytecode
generation, a good added value with respect to Java where only
querying metadata is available. It is no suprise that many
experiments with it, notably Antonio
Cisternino presented his work on a higher-level API built on
Reflection.Emit, very interesting but still not available online.
When it will be I will send you a link. Anyways, it seemed to
me that almost everyone agreed on the fact that APIs for runtime
code analysis and generation are a powerful and desirable tool.
Is reflection becoming trendy?

Finally: Microsoft also published a version of the CLR with
source code. They invented a license, which allows modification
and redistribution of their code but not for commercial purposes,
and called it the "shared source" initiative. I am not Stallman, so
I am not able to comment the license. However the link to
the shared source CLI (codename "rotor") is below; It has been
ported to Windows, needless to say, and to FreeBSD, and
the code seemed to me readable. Peter Drayton gave a
good lecture where he step-by-step debugged CLR on
some programs to give an idea on how it works.
Both CLR and C# are ECMA standards.

Final remark: Microsoft is trying soooo hard to replace Java as
a platform for researchers to experiment their stuff on, and this
justifies the resources galore here at Politecnico di Milano are
experimenting. Of course all the opinions expressed in this
message are strictly personal, and in no way reflect an official
position of the institutions I happen to be in. Ditto.

Pietro

Links:
http://msdn.microsoft.com/net/ecma/ - on .NET ECMA standards
http://www.oberon.ethz.ch/active/ - Active Objects
http://www.oberon.ethz.ch/lightning/ - Active Oberon for .NET
http://msdn.microsoft.com/net/sscli - Shared source CLI (aka "rotor")
http://www.clrinternals.com/ - Peter Drayton's page on CLR
http://recoder.sourceforge.net/ - Recoder is a metaprogramming tool for Java
(not related with C#, but a nice link anyways)