Re: Ruby on .NET (was Re: A Ruby WishList)

//> //Ow ow ow. The concept of a Microsoft platform providing a
//> //"true level playing field" for anything just made by brain hurt.
//
//> Hey, backoff.
//
//What's the big deal?  It's a fair point substantiated by=20
//several courts of law.

The idea behind the CLI and that behind MS as a commercial company are
two different things. While I could ask you to not dislike the CLI
because MS created it, it simply easier if you read Dave Stutz's books
first chapter that introduces the CLI. Let me post the link again:
http://www.oreilly.com/catalog/sscliess/chapter/ch01.pdf

Secondly the big deal is that not everyone may share the same opinion
about MS as a company and people are free to do that same as you have
yours. What bothered me was that something that was description about
the CLI was equated to MS, in rhetoric that is so typical of open
source. I will stop now.=20


//
//> Yes I figured that Matz's reasons would be those. Which is=20
//good. But I=20
//> would always argue for the Ruby being on the CLI - I might even do=20
//> something about it, had I been a good enough programmer,=20
//but that will=20
//> have to wait. Today the CLI/CLR let you write a class in C++ and=20
//> inherit and extend that in Visual Basic. Being on the CLI=20
//simply makes=20
//> avilable to Ruby everything the .Net community has done and thats=20
//> awesome.
//
//I won't stand behind or attempt to justify these claims, but=20
//I'm told that the CLI doesn't really support multiple=20
//languages; rather the languages have changed to support the=20
//CLI.  It's probably an exaggeration to say that the languages=20
//are now the same but with different keywords, but it's also=20
//an exaggeration that the CLI supports C++ and VB in their=20
//original spirits.  Do you have an opinion on this?

Yes I do, but admittedly it's a hard question. The CLI offers, listen to
me carefully, execution services to code in certain way - it is not a
classical virtual machine so to speak.=20

The CLI does consume byte code of a theoretical processor or machine.
Execution services include verfication of types loaded into the system,
garbage collection, life time management, reflection, IPC (of a sort)
and other things.=20

Not ALL languages fit into the execution model provided by the CLI in
its present state. Essentially what the desifgners of the CLI have tried
to do is to create a notion of _types_ that can exist across language
boundaries. COM used to do do that in limited ways, but in the COM model
one could not garauntee various services that a _type_ would provide. In
that sense the CLI essentially manages types and objects across
languages.=20

That said, C++ is supported under the CLI in mostly the same form,
additions have been made to the language so that it can interoperate
with other CLI types and with the garbage collector - because C++ never
had a GC. VB is a language that has changed a lot - most of the changes
where inevitable in the language whether the CLI was there or not  such
as making it object oriented and providing support for threading.=20

//> But if Matz (or anyone knowledgible enough) were to put out reasons=20
//> for why the CLR is inadequate, the .net community might be able to=20
//> respond and do something about it.
//
//Forgive my ignorance, but what can the community do about it?=20
// Do they have any influence over the spec?

Yes, in terms of where the CLI is going. The MVP program and the
univrsity grant program related to the SSCLI are steps to help
facilitate this.=20

Regards
Rosh