Parrot is a foundering project on top of a wonderful vision.

Andrew Whitworth wknight8111 at
Wed Sep 7 20:11:12 UTC 2011

On Wed, Sep 7, 2011 at 3:46 PM, Jonathan "Duke" Leto <jonathan at> wrote:
> Even though we are more careful about doing big merges before stable releases,
> they really aren't much more stable than dev releases. We are lying to our
> users. We should stop that. I propose that stable releases be put on hiatus,
> until there comes a time when we want to reinstate stable releases.

I think I agree with this as well. The problem with stable releases is
that they have been mostly arbitrary. As you mention, we didn't really
do anything different or special leading up to a stable release, and
the results are no different from any other release. The biggest
result of them was that in the days immediately following stable
releases things tended to break because of the deprecation boundary.
If we don't have a rigid deprecation timeline, those breakages will be
spread out more thinly.

It would be one thing if we had some kind of process for making a
stable release be more "stable" than any other release. But every
three months we cut it from master like everything else. Also, we
haven't exactly been getting regular "support requests" for patches to
be made to stable releases. It is one thing if we needed to maintain a
long-term support branch for making patches. It's another thing if
it's just another static tag in the repo.

What we do need is some kind of way to differentiate the releases that
are intended for packaging. Setting aside certain releases each year
that are suitable for that would be a good thing. Whether we want it
to be numerical (X.0, X.6, etc) or be selected some other way is
another question.

> Parrot needs to distance itself from Perl 6 if we are ever going to interest
> the large majority of people that are interested in what Parrot has to offer.
> Most people in the sphere of VMs do not care about Perl 6.

I don't think we need to distance ourselves from it. I think we would
do well if we presented a compelling platform for perl6 development.
That said, we clearly aren't the most compelling platform right now.
All else being equal, a perl6 project started tomorrow wouldn't choose
Parrot. Our biggest draw right now, if we can call it that, is sheer
momentum. It would be costly for Rakudo to move to another VM
wholesale, although much of that cost has been mitigated by the
NQP/6model abstraction layer.

I don't want to distance ourselves from Rakudo. That's not a good
idea. Most things we can do to make Parrot a better host for Rakudo
are going to make us a better host for other languages as well. If the
projects grow further apart over time, that's one thing. But so long
as Rakudo is a user of Parrot, we need to do everything we can to make
Parrot good for Rakudo.

> Which languages should these be? I propose Python and Javascript, since that
> casts a very wide net in the dynamic language arena. It also encompasses a
> language that is mostly server side and a language that is mostly client-side
> (although server-side javascript is all the rage these days, it is still
> predominantly a client-side language).

I actually was having this exact same conversation with chromatic
today. Considering that Python and JavaScript are two of the most
popular languages today, and the fact that they can't really be made
to interoperate on any other platform (yet) is something of a niche
that is worth pursing. Ruby is another great target, although cardinal
might be beyond resurrection at this point. Other languages certainly
should not be excluded or ignored (Lua, Partcl, etc), and so long as
they work or are in development that's a good thing for us.

> To be more specific, I think we need to prioritize the development of
> Jaesop [2],
> whiteknight++'s new JS on Parrot implementation, and decide whether we want
> to use Puffin [3] (lucian++'s Python on Parrot) or start from scratch
> with a different
> design.

The new Jaesop stage 0 is very promising, and I'm happy to both talk
to people about it and hand out commit bits to interested
participants. I don't know the status of Puffin right now, but I
remember looking in on it during the summer and being suitably
impressed. These are as good of starting points as any. Both of these
are going to benefit significantly from object model refactors,
improvements to lexicals, improvements to Sub/NameSpace, improvements
to PCC, and other big changes we already have planned.

> This new vision of Parrot with give focus to the huge wave of refactors that
> are imminent in Parrot. It also gives us a good reason to "push back" when
> Rakudo says "Don't Do That", even though we know we need to do something, for
> the good of Parrot. I am surely not recommending being hostile to Rakudo or
> breaking stuff on purpose, but we just can't let the needs of Rakudo trump the
> needs of Parrot.

Again, let's not treat Rakudo as some kind of foreign party. They are
still big users of Parrot and we need to do what we reasonably can to
make their experience better. We need to put priority on refactors and
improvements that benefit Rakudo *and* other languages as well. Many
things, especially various performance improvements, will have
universal benefits.

I know emotions are running high right now because of all the emails
and charged IRC conversations. Let's all not lose site of the fact
that we have serious improvements to make, that we have existing users
who need to be kept happy and we want to attract future users as well.
Having a vision and concrete goals are good things, but make sure our
goals include all the things we want to be doing, not just focusing on
the new shiny.

--Andrew Whitworth

More information about the parrot-dev mailing list