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

ruby-talk
1

//|Don’t get me wrong, all I am saying is that the .net is geared to go
//|places and it already is in the enterprise spehere. The merits of
//|platform that provides a true level playing field across
//languages is
//|slowing showing its strenght in the enterprise.
//
//Ow ow ow. The concept of a Microsoft platform providing a
//“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.

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.

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.

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.

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
    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.
Let me repeat myself:
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.

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://www1.elsevier.com/gej-ng/31/29/23/89/27/31/59.1.006.pdf
Design and Implementation of Generics for the .NET Common Language Runtime - Microsoft Research (an old
story, this is part of the CLR now)

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

InterScan_Disclaimer.txt (520 Bytes)

2

//|Don’t get me wrong, all I am saying is that the .net is geared to go
//|places and it already is in the enterprise spehere. The merits of
//|platform that provides a true level playing field across
//languages is
//|slowing showing its strenght in the enterprise.
//
//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 several courts of
law.

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.

I won’t stand behind or attempt to justify these claims, but I’m told that
the CLI doesn’t really support multiple languages; rather the languages
have changed to support the CLI. It’s probably an exaggeration to say
that the languages are now the same but with different keywords, but it’s
also an exaggeration that the CLI supports C++ and VB in their original
spirits. Do you have an opinion on this?

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.

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.

Forgive my ignorance, but what can the community do about it? Do they
have any influence over the spec?

Cheers,
Gavin

3

I think that was a reasonable statement. Given MS’s track record, I can
see why someone would find it difficult to believe that they would be
truly interested in leveling a playing field. They are a corporation,
and most people realize that corporations only serve their own
interests, and the interests of their stockholders. They got in trouble
in trouble already once for un-leveling the playing field between
languages (remember the whole java thing?)

To paraphrase Orson Wells, “The playing field is level; just some areas
are more level than others.”

–Mark

···

On Apr 22, 2004, at 11:57 PM, James, Roshan (Cognizant) wrote:

//|Don’t get me wrong, all I am saying is that the .net is geared to go
//|places and it already is in the enterprise spehere. The merits of
//|platform that provides a true level playing field across
//languages is
//|slowing showing its strenght in the enterprise.
//
//Ow ow ow. The concept of a Microsoft platform providing a
//“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.

4

Hi,

On the other hand…

I read all of that and it is rather frightening. These people
have VM, JIT and almost type inference! Soon enough they will cross
the bridge between statically typed languages and scripting
languages (coming from the static side, using “generics”).

What their acts tell us is:

“we love it when it’s flexible (i.e. when type is “weak”),
but we are never going to acknowledge it however…
'cause we love speed even more (nobody’s perfect).”

Strangely enough, I don’t know of so much work going on in the
other direction: coming from “weak” typing, going to fast code.

One may conclude that people trading flexibility for speed
are unhappy (and try to fix that), whereas people trading
speed for flexibility (read: Ruby users) are happy (not
trying to improve speed so much).

Reality is more subtle. Rite and Parrot are indications that
script languages people want more speed.

From all that I am confident that future is for scripting
languages.

Matz: Don’t care about Rite, you are already doing the right
thing with Ruby: Promoting scripting languages. Some unhappy
C# or Java user will soon provide a VM for Ruby.

Go to the next step directly: Provide a syntax whereby source
code writers can provide “hints” that will help the compiler/VM
to speed things up (you may also want to provide easy access to
the AST AbstractSyntaxTree, to help the unhappy people).

Yours

Jean-Hugues

PS: Please don’t take that mail too seriously, I am not implying
that people that like type safety and speed are unhappy people in
“real” life :wink:

···

At 15:57 23/04/2004 +0900, you wrote:

//|Don’t get me wrong, all I am saying is that the .net is geared to go
//|places and it already is in the enterprise spehere. The merits of
//|platform that provides a true level playing field across
//languages is
//|slowing showing its strenght in the enterprise.
//
//Ow ow ow. The concept of a Microsoft platform providing a
//“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.

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.

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.

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.

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
    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.
Let me repeat myself:
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.

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:
Microsoft Research – Emerging Technology, Computer, and Software Research
http://www1.elsevier.com/gej-ng/31/29/23/89/27/31/59.1.006.pdf
Design and Implementation of Generics for the .NET Common Language Runtime - Microsoft Research (an old
story, this is part of the CLR now)

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

Web: @jhr is virteal, virtually real
Phone: +33 (0) 4 92 27 74 17