RE: .NET CLR? was no subject

["Brent Fulgham" <address@hidden>]

> Eric Kidd mentioned the case of Eiffel.  My understanding is that even
> though the Eiffel people managed to create a .NET version of Eiffel
> with MI and DBC, they had to go through some pretty major hoops to
> do so.  It appears that the "common type system" really means "common 
> type system for a language sufficiently similar to C#".

ActiveState wrote a whitepaper on the challenges of attempting to port
Python to the CLR (Sorry it's in MS Word format):
http://www.activestate.com/Initiatives/NET/Python_whitepaper.doc

Basically, it sort-of worked, but did not support MI and was basically
a C#-ish Python.  The performance was also extremely bad:

"The speed of the current system is so low as to render the current
implementation useless for anything beyond demonstration purposes. This
speed problem applies to both the compiler itself, and the code generated
by the compiler."

Also, you don't even get to reuse your old code:

"The existing Python for .NET system does not allow any leverage of
existing Python code. Although much of the standard library can be
ported to .NET, it would not be reasonable to attempt to cover every
Python module available."

Some of the subscribers to this list may have strong disagreement with
David McCusker (http://treedragon.com/ged/map/ti/newFeb02.htm#27feb02).
However, I found his comments discussing the CLR with respect to Smalltalk
interesting:

<Osvaldo Doederlein quoting David Simmons>:
"The .NET VM is designed for statically typed and compiled languages.
SmallScript LLC has developed technologies to efficiently support
execution of dynamic typed and bound languages [scripting languages
included]. The "interactive" aspect of languages such as Smalltalk
is too difficult a problem, in current .NET architecture, to
address/provide with the "classic" Smalltalk IDE experience. 

> Can we expect to be able to do things like add classes while
> debugging on the .NET platform? 

No. Microsoft design decisions and their development time schedule
constraints in this version resulted in cutting any real mechanisms
for edit-and-continue style behavior. 

It can be done, but what one has to do under the hood is very painful
and grossly unneccessary/complicated. Which is to say that it won't
be done by us for this version of .NET unless the commercial rewards
justify it."
<End Quote>

He also makes this relatively strong statement:

<Quoting David McCusker again>:
"I want to emphasize that .NET is not language neutral as billed. 
That's a lie promoted by Microsoft's marketing. It's a dumb lie. 
But stupid lies work so darn well! Repetition is cheap and easy. 
It's only sorta neutral. Kinda sorta. But not completely neutral. 
It does matter what language you use. That's the lie involved. 

The non-compatible languages are only so in very technical ways. 
Laymen and less expert programmers don't see the runtime issues. 
So when languages like Smalltalk get shorted, it's hard to see. 
Only the cranks like me complain about what's really getting lost. 
The explanation of why it matters is hairy and anecdote heavy. 
"
<End Quote>

> Jesse Liberty, in his "Programming C#" book, states that he'd
> rather have his teeth drilled than program in managed C++ (I think
> that's a quote).  That's presumably because managed C++ removes a
> lot of the features of C++ like MI.
>

> > 
> > 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?
> > 
> 
> I would absolutely program in multiple languages if it was feasible,
> sufficiently transparent and efficient.  I think that .NET is a first
> tentative step in the right direction, but it hasn't solved 
> the problem by any stretch of the imagination.

I agree with Mike here.  However, current industry practice would
probably make this unlikely.  The typical middle-management response
to this kind of idea is that it's too hard to find people with the
right skills to maintain your Mondrian# component, when all the rest
are VB.NET people.

> When I can write low-level code that needs to be maximally efficient
> in C++, routine infrastructure code in a java or ML dialect, and
> script the system in python or scheme, and all without paying a
> huge runtime cost, I'll be one happy programmer.  I don't see this
> happening for some time yet.
> 

At the risk of being tarred and feathered by the academics here, it
just might be that Parrot is a step in this direction...  *ducks*

Regards,

-Brent