From: Dan Sugalski <dan@...>
Date: 2002-08-09T10:35:19+09:00
Subject: Re: Rite vs Parrot: rationale?

At 6:48 AM +0900 8/9/02, Mauricio Fern�ndez wrote:
>I'm been looking for the rationale of implementing Ruby's own bytecode
>engine (Rite) instead of using Parrot.
>
>[34594]  (23 Feb): <<_EOF_
>Rite will have some kind of VM.  It would NOT be Parrot, but I hope I
>can prepare backend API that makes Parrot backend possible.
>
>							matz.
>_EOF_
>
>We can feel Rite is beginning to become something, but I have been
>unable to find the rationale for some of the mayor design decisions
>already taken; particularly the reasons behind [34594] (which was
>acknowledged by Dan Sugalski as being correct without any further
>explanation).

While I can't give you Matz's rationale for it, I can tell you why I 
think it's a good idea to not have Parrot be the back end for Ruby 
2.0.

It's not done.

If Parrot were fully functional, it'd be reasonable to talk to Matz 
about having it potentially be the engine for Ruby 2.0, but it's not, 
and it *definitely* wasn't at the time Matz was starting in designing 
and developing Rite. He'd have been foolish to bet that what we were 
building would meet his needs and the needs of Ruby based only on 
some design documentation, a bit of source, and a conversation or two 
with someone he's never met.

Heck, *I* wouldn't be comfortable if Matz was counting on Parrot 
being Ruby 2.0's back end at this point--we aren't done, and the 
thought that something that we screwed up in parrot development would 
impact someone else is rather unpleasant. (I'd hate to think that if 
I got hit by a bus before we were done that ruby'd be in serious 
trouble) I don't mind being an alternate implementation, I just don't 
want to be the primary implementation, certainly not when we aren't 
finished.

Also, while Matz is responsible soley for Ruby, I can't be, and that 
means that I may end up making decisions for the core that aren't 
necessarily in Ruby's best interest. (Nor Python's, nor Perl's, nor 
Scheme's for that matter) With any engineering project of any size 
there are inevitable tradeoffs, and my (self-chosen) problem scope is 
larger than Matz's so the chances that there'll be an unfavorable 
decision for some Ruby feature is greater.

Maybe when we're done things'll be better--I certainly have some 
rather compelling reasons to get a 100% full ruby implementation 
working on Parrot. When we're done then it'll be different since we 
can look at an existing project and judge it on its merits, rather 
than look at some plans and guess how things will turn out, and 
perhaps at that point the decisions may change, but that's not really 
something worth worrying about now.

Finally, don't forget the important question: "Who the heck *is* this 
Dan guy anyway, and why should we trust him to make Ruby work?" :)

Reasonable caution is, I think, in order. That's only prudent.
-- 
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk