[ruby-talk:04323] Re: Phython and Microsoft's IL -- C# & .Net

Hi,

Conrad Schneiker wrote:
> "Dave Thomas" wrote:
>
> > In case anyone missed in over on comp.lang.python, ActiveState are
> > producing a version of Python that compiles down to Microsoft's new
> > Intermediate Language (IL), the common intermediate code for their
> > .NET stuff.
> >
> > I'm not sure _what_ I feel about this. Part of me says that the
> > integration will be great, and that Windows users will love having the
> > flexibility. On the other hand, will they move away from the existing
> > Microsoft scripting languages?

I have some further follow-up comments.

An article I skimmed in a (the most?) recent issue of Microsoft Developers
Journal (or something like that) mentions that MS intends C# and the .NET
common runtime stuff to be cross-platform, despite the initial press
releases describing in terms of existing MS stuff. Of course that's no
guarantee that it will actually happen, but if MS or GNU or whoever follows
through, that could be a wonderful development. Hopefully MS will not pull a
Sun flip-flop with respect to independent language standardization, but
we'll have to wait an see.

Although I think it is a good idea to stack the deck in favor of open
platforms and so on, it is important to keep the primary support focus on
present and perspective Ruby users, some large fraction of which are going
to be on MS platforms in any case. Moreover, with the major exceptions of
Linux and minor exceptions such as open BSD and such, the bulk of the UNIX
world is still made up of proprietary flavors, and it was GNU and allied
open source stuff that ran on proprietary UNIX systems that helped make
Linux a viable alternative and led to things such as Cygwin on Windows.

What follows below are some interesting excerpts from "Deep Inside C#: An
Interview with Microsoft Chief Architect Anders Hejlsberg"
(http://windows.oreilly.com/news/hejlsberg_0800.html). As usual, you should
take all such things with a grain of salt or two, but I think it's
nevertheless important to give such things a fair hearing. [My comments are
in square brackets, like this.]

=======================

Also in attendance at the interview were Tony Goodhew, Microsoft C# product
manager, and O'Reilly Windows editor Ron Petrusha. [See the URL for who said
what.]

One of the wonderful things the .NET framework has done for scripting
languages is to make them compiled.

Developers are building software components these days. They're not building
monolithic applications or monolithic class libraries.

I think C# contains some pretty interesting innovations that make component
development easier....

One of the interesting things that came out of our developer tracking study
is that over 60 percent of all developers in the professional developer
market use two or more languages to build their applications.

And so our approach with C# has simply been to offer an alternative to C++
programmers who find that language too complicated and to Java programmers
who miss certain features of C and C++ that were lost in the translation. We
looked for ways to simplify C++ and then put the result on a multilingual
platform that provides greater interoperability, and that gives you all of
these component concepts, and so forth.

The .NET framework allows scripting languages to be used as full-featured
languages because they now have access to a true programming framework and
to the same base-class APIs.

I think one of the key differences between our IL design and Java byte code
specifically, is that we made the decision up-front to not have
interpreters. Our code will always run native. So, even when you produce IL,
you are never running an interpreter. We even have different styles of JITs.
... When you make the decision up-front to favor execution of native code
over interpretation, you are making a decision that strongly influences
design of the IL.  ... So you end up with some different design decisions,
which in turn makes it easier to translate IL into native code. ... Our IL
format is actually truly type neutral. And, by keeping it type neutral, we
can add generics later and not get ourselves into trouble, at least not as
much trouble. That's one of the reasons our IL looks different from Java
byte code.

It's certainly our objective to present C# to the industry as a possible
standard, which is why we've submitted it to ECMA. We certainly hope to gain
support in ECMA for a process that will lead to a commonly designed language
which has a common language infrastructure. And what I mean by a common
infrastructure is the core set of class libraries this specification
entails, such that if other companies using other platforms implement it,
they could reasonably expect to find those classes available to their
programs. ... I might point out that we're taking a true open standards
approach with ECMA. When and if ECMA actually arrives at a standard for C#
and a common language infrastructure, the result will be available under
ECMA's copyright and licensing policies, which are truly open. Any customer,
and any person, will be able to license the ECMA C# standard, subset it,
superset it, and they won't have to pay royalties. ... That is something
fundamentally different from our competitors who wandered around the
standards bodies, looking for someone to rubber-stamp their proprietary
languages. ... One of the benefits of going to a standards organization and
working with people like IBM, with whom we worked on the SOAP specification,
is that we ensure we don't make any such references that tie us or lock us
into something like the COM framework in future versions of the
specification.

There's a great interview with James Gosling on IBM's developer works
site... Here's the inventor of the language saying that neither purity nor
portability exists. [Tony Goodhew was recently slammed on slashdot.org about
this statement for grossly misrepresenting what Gosling actually said in
connection with limits of Java portability under non-typical circumstances.]

When we first sat down to design the .NET framework we took a step back and
looked at what's actually happening on the Web. It's becoming this loosely
connected, very distributed world, and we tried to understand what that does
to your underlying programming model. And so we designed from the ground up
with the assumption in place that distributed apps are built in a loosely
connected, stateless fashion that gives you great scalability. You just
scale out. You roll in more racks and plug them in. And once you make that
fundamental assumption, it changes everything. It changes how you design
your basic services, how you design all your messaging, and it even changes
how you design your UI. It's a new programming model. We have chosen to use
XML and SOAP as the means to make this model work. They are deeply
integrated into .Net and this integration is so core to every decision we
have made in designing the .NET framework that it's not something you could
just walk in and sprinkle on later.

===============

Conrad