On Thu, 2002-02-14 at 10:04, Stephan J. Schmidt wrote:
> > Ya, that's why a Ruby interpreter could never be developed in a language
> > like C, right?  ^,^
> 
> I said "very good". Have you read the CLR article ?

I've read up quite a bit on .NET, yes.  I am *really* looking forward to
a usable Linux version.

> 
> > Not necessarily.  So long as Ruby compiles and runs in .NET, it serves
> > the major purpose.  Attributes would only be needed to deal with .NET
> > extension libraries.
> 
> Whats the purpose of compiling Ruby to .NET and then not use .NET
> libraries ? I can't see one. 

Speed.  (JIT)  Plus, you *can* use .NET libraries.  It'll just take some
more work.  I'm not saying, "port to .NET, then don't worry about
libraries"

Of course the real advantage is using the .NET libraries - interfacing
with all the .NET components.

Something that would make more sense perhaps than porting Ruby to .NET
would be making a Mono interface for Ruby, so that Ruby can communicate
with .NET using its native interpreter.

> 
> > 
> > Well, Ruby in .NET Framework would still be faster than normal Ruby,
> > because it will be run thru a JIT... granted, the methods necessary to
> > make Ruby work with .NET would make it still slower than straight C, I'd
> > imagine it'd be a lot faster than just the Ruby interpreter as it stands
> > now.
> > 
> 
> We will see that. My opinion, and the opinion of the CLR article writer
> is that a Ruby JIT (not the Ruby interpreter) would be faster than the
> CLR.

That is likely, too.  I wonder how easy it would be to write a Ruby
native JIT?  That would be pretty nice.  ^,^

> 
> > 
> > Ya, a Parrot backend would be great for Ruby.  But that's no reason to
> > not even bother with .NET.
> 
> Yeah. If you have enougth time for both, go for both. But 50% ports of
> Ruby to Parrot and .NET are not as good as a 100% port to Parrot imho.

I wouldn't think one person will be doing all the porting.  Some people
will work on .NET, some on Parrot.  Whichever the people decide they
want to work on.

> 
> bye
> -stephan
>