REPOST: Re: Python and Ruby: a comparison

[Edward Diener]

Alex Martelli wrote:

> Edward Diener wrote:
> 
> 
>>CLR is a lowest common denominator for language ideas which MS supports.
>>What happens when a language has good ideas which are more advanced than
>>what CLR supports. It is left out of CLR, or included into it with those
>>ideas stripped from the language to accomodate CLR. Sometimes the Holy
>>
> 
> Your assertions are seriously counterfactual.
> 
> Check the list at, e.g., 
> http://www.dotnet-fr.org/links.php3?op=viewslink&sid=15.
> 
> Consider, say, the Gasgow Haskell Compiler for .NET.  Obviously, Haskell 98 
> has quite a few "good ideas which are more advanced" than anything in .NET, 
> such as lazy evaluation, typeclasses, immutable data, monads...  So, was 
> Haskell "left out of CLR"?  Not at all, Glasgow Haskell supports CLR.  Were 
> the advanced ideas that are 99% of Haskell "stripped from the language"?  
> 
> Again, not at all, obviously.  Pretty evidently, instead, what happened 
> (and the same can be said for Mercury, Oberon, APL, and so on) is that a 
> distinction is drawn between a language and its "foreign function 
> interface" (traditional lisp/fp terminology for: how a language interfaces 
> to "foreign" pieces of code, those written in other languages; sometimes 
> more generally called a "foreign language interface").
> 
> It's pretty obvious, isn't it?  The CLR dictates a certain MINIMAL set of 
> functionality that a language must support to fully integrate with it.  In 
> no way does it constrain any _extra_ functionality the language may wish to 
> add.  Such extras will not be seamlessly made available via the CLR 
> sanctioned "view" of any component written in the language, of course (eh 
> yes, it IS pretty obvious: if no other language has ever yet invented the 
> sublime concept of superinfermollification that my new Aretinus language 
> will introduce tomorrow, how could my components expose and offer 
> superinfermollification to other components coded in other inferior 
> languages?!).  But that doesn't, by any stretch of the imagination, imply 
> either that the language is "left out of the CLR", nor of course that the 
> language is stripped of its original ideas.  I'll still use (e.g.) Mercury 
> backtracking, Haskell typeclasses, or Oberon active-objects, even if 
> "lesser" languages will obviously not "see" them at the interface!


I stand corrected.

Yes you can use .NET versions of languages and as long as you don't use 
the features of the language in managed code which CLR supports, it is 
possible to use all the features of the language internally. However if 
a .NET language version does not implement key portions of CLR, mainly 
garbage collection, the basic necessary data types, and single 
inheritance OOP, it is a poor candidate to be inetgrated with .NET.

I still feel this leads to language subsets and people who learn a 
computer language and only use, and know, a portion of that language. It 
has already happened before .NET was even created with VC++, where a 
great many programmers who know only MS's subset of C++ and even some of 
its incorrect syntax, assume they are using C++ effectively and 
correctly and often they are not. Managed C++ in .NET is also an 
abortion of C++ which only a computer programming masochist could love. 
I anticipate this happening with most .NET versions of languages and 
that many programmers of these languages will only know and use the .NET 
subset and not the full language.

Eddie