From: "James, Roshan (Cognizant)" <JRoshan@...>
Date: 2004-04-23T15:57:05+09:00
Subject: Re: Ruby on .NET (was Re: A Ruby WishList)

------=_NextPartTM-000-e51902df-2ad7-4ed2-83f5-a8e3820f09f4
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

//|Don't get me wrong, all I am saying is that the .net is geared to go=20
//|places and it already is in the enterprise spehere. The merits of=20
//|platform that provides a true level playing field across=20
//languages is=20
//|slowing showing its strenght in the enterprise.
//
//Ow ow ow. The concept of a Microsoft platform providing a=20
//"true level playing field" for anything just made by brain hurt.

Hey, backoff. You probably don't know enough about the CLR architecture,
which is why. If you are really interested in technology, go read
http://www.oreilly.com/catalog/sscliess/chapter/ch01.pdf, you might
understand what I was trying to say.=20

Yes I figured that Matz's reasons would be those. Which is good. But I
would always argue for the Ruby being on the CLI - I might even do
something about it, had I been a good enough programmer, but that will
have to wait. Today the CLI/CLR let you write a class in C++ and inherit
and extend that in Visual Basic. Being on the CLI simply makes avilable
to Ruby everything the .Net community has done and thats awesome.=20

I must say that the CLR is not ready for true dynamic languages, I
cannot imagine how a closure or a continuation would be implemented on
the CLR. The present C# implementation of yield (Whidbey release - VS
2005) is a 'hack', for want for a better word.=20

But if Matz (or anyone knowledgible enough) were to put out reasons for
why the CLR is inadequate, the .net community might be able to respond
and do something about it.=20

Matz:
>   * I want to enjoy writing my own VM.
>   * I don't want to restrict the language design by VM feature.
> The latter is more important.  When I design new feature for Rite, I=20
> don't want to wait other projects (say .NET) to add VM function.

Matz, don't wait - go ahead and do your own thing. I really appreciate
you for that.=20
Let me repeat myself:=20
Branching to the CLR to gives Ruby an oppurtunity to branch from a
lesser known scripting language to a player of equal footing to
soimething like C#. Ruby as a lnaguge is good enough for that. Since the
CLR is inadeqaute in ways to support the functionality that Ruby
requires, document them - that gives others an oppurtunity to work to
fix them.=20


There are some very smart people at MS and outside working towards these
things and it Only Helps Ruby to leverage these things. I don't know how
you guys 9especially those who don't know much about the CLR will relate
to this, but atleast notice that there is work happening:
http://research.microsoft.com/projects/ilx/absil.aspx
http://www1.elsevier.com/gej-ng/31/29/23/89/27/31/59.1.006.pdf
http://research.microsoft.com/projects/clrgen/generics.pdf (an old
story, this is part of the CLR now)


Regards
Roshan James
http://pensieve.thinkingms.com/

------=_NextPartTM-000-e51902df-2ad7-4ed2-83f5-a8e3820f09f4
Content-Type: text/plain;
	name="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="InterScan_Disclaimer.txt"


This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. 
Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly 
prohibited and may be unlawful.

		Visit us at http://www.cognizant.com


------=_NextPartTM-000-e51902df-2ad7-4ed2-83f5-a8e3820f09f4--