The Parrot is dead. Long live the Parrot?

Allison Randal allison at parrot.org
Sat Feb 9 23:13:23 UTC 2013


On 02/09/2013 11:37 AM, Gerhard R. wrote:
> Assuming there's still sufficient interest, I propose the following
> steps as a way forward:
> 
>   1. Fork off a Parrot-light with the sole purpose of supporting Rakudo
> 
>   2. Start design of Parrot2

If there's a group of at least 3 (preferably 5 or more) developers
inspired by your vision, and willing and able to devote the time
required to complete it, they certainly have my blessing to use the
Parrot name (to whatever extent I have a blessing to give, as one of
Parrot's many contributors). I'd be thrilled to see it. I've considered
something similar at several points over the past few years, but always
set it aside as I realize I really don't have time.

I do have some reservations, however. Maybe you have easy answers to
them, I don't. Please don't take this as discouragement, it's an
encouragement to really see the full challenge and step up to it.

- Restarting a project from the ground up a dozen years in, with no
"production" releases and no "production" users, is a risky business.
Not impossible, certainly. But, it has all the baggage of project
legacy, reputation, and relations with other projects, without the
advantages of existing code. This might be alleviated by doing the work
under the "Rakudo" banner rather than "Parrot", or declaring them as one
and the same. (This would mean that the "existing codebase" you keep is
Rakudo, and the work is a matter of replacing the bits of Rakudo
provided by the current Parrot with new bits more tailored to its needs.)

- Parrot's problem isn't "architecture" in the sense of design, it's the
fact that none of the series of designs for it have ever been fully
implemented. Yet another grand plan for the architecture is no better
than what we have, if it isn't executed. This isn't an academic
exercise, we don't get points for thinking about cool things. The only
measure of success that matters is real use in the real world, and
Parrot (and Rakudo, and Perl 6) have so far utterly failed by that
standard (token use by a handful of people who participate in the
projects anyway doesn't count). Again, it's not impossible, but it is
very difficult.

- Your quick notes on
https://gist.github.com/gerdr/48890726c026588535fa, sound like the exact
same things we were saying in Parrot 6 years ago. That's not necessarily
a bad thing, but chances are that different results will only be
achieved by setting different goals and meeting them with different
strategies.

- This plan requires substantial buy-in from Rakudo, which they've been
hesitant to give. Maybe they've just been burned in the past, and would
gain enthusiasm as their needs were met. That's a big "Maybe" with a lot
riding on it.


To end on a high note, I do firmly believe that "lighter and faster" is
the only way Parrot can succeed, and this plan has that going for it. I
agree with Brian's comment that focusing on just "Parrot-light" has a
better chance of success than trying to do both that and a re-design on
the "big VM".

Allison


More information about the parrot-dev mailing list