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

Christoph Otto christoph at
Mon Sep 5 21:02:37 UTC 2011

masak made the offhand remark in #perl6 recently that I used as the
title of this message. Now that I'm done giving State of the Parrot
talks, I'm free to take off my optimist hat and realize that Parrot is
going to die a slow death if we don't do something drastic. I love the
vision that Parrot has, so as architect I want to do what's needed to
make it kick ass.

First of all, Parrot isn't mature and stable enough to justify our
deprecation policy. Mature projects with a stable API and lots of
production users need a deprecation policy like ours. We need to take
out the trash. Parrot has evolved from a heritage where it was
acceptable for our C interface to be a batch of poorly-encapsulated
functions that poked into Parrot's internals in a fairly indiscriminate
way. Until we've moved completely away from the code from that era, we
need to get that mentality out of our tree. We have all kinds of junk
that we're "supporting" because it happened to exist when we adopted our
policy, and us keeping it around isn't doing ourselves any favors. We
need to start thinking of DarkPAN for Parrot as a fairy tale and avoid
invoking its name in policy discussion. We can only help users when we
know they exist. Silent users will have to either make themselves known
or deal with it.

The right solution for Parrot is to break things and fix them as needed
in users' projects. This implies some infrastructure to detect HLL
breakage. Since we can't seem to come up with a proper infrastructure, I
hacked together tools/dev/ It's a barely-maintainable
script to glue HLL build processes together in the most delicate and
brittle way possible which doesn't involve magnets and a slingshot. It's
guaranteed not to work on all platforms, but it will be good enough
point out when tests fail in HLLs. It also tries to provide enough
logging that you don't need to go back and re-run the test suite again
to find out what exactly broke. If it doesn't, see the next paragraph.

Improvements to the script are welcome, especially the addition of every
single HLL and library which can be expected to pass its test suite.
It's my sincere hope that the script is painful enough to use that we'll
be forced to find something better. If not, we can at least require an
all_hll_test run before any non-trivial branches get merged.

Additionally, teams as a requirement are a distraction. We have a
handful of full-timeish developers. git-summary lists 30 developers
who've pushed to parrot.git since 3.6.0 was cut, including duplicates.
The number is 11 for those with 10 or more commits. For a project of
Parrot's size, the team-based structure is a poor fit. The redundancy we
tried to accomplish with teams is a good thing and their dissolution
does leave us open to the possibility that a role will go unfilled. The
solution is to react to our shortcomings as they become problems. We can
create, retire and reassign roles as the need arises. We have a smart
bunch hacking on Parrot; we'll figure it out.

I'm also convinced that we're trying to impose too much structure on
Parrot in the way we implement roadmap goals. We've gone through the
motions of putting together roadmap plans, but we all individually tend
work on what we see as important. Starting with the next PDS, I would
like to dissolve most of the formality involved in roadmap goals.
They'll still need to be mostly well-defined and completable, but
that's it. A brief one-sentence goal like "move imcc out of libparrot"
is perfectly acceptable, if the hacker proposing it is capable.
Anything between a sentence and an essay is fine, if it describes a
completable goal.

The next year or two will be a much more turbulent time for Parrot as we
start tearing down and rebuilding Parrot. It will be harder to predict
what the Parrot of January 2012 will look like and harder to form goals
around it. That said, roadmap goals are useful and there's value in
term planning and execution. Still, few teams meet their roadmap goals
100%. If we don't, Parrot will continue. If an important goal slips,
we'll reschedule. If it ends up being unnecessary, we can drop it.

While I'm cutting down our roadmap goals, I also need to add one. HLL
interoperability is a core feature of Parrot that's been broken/missing
since 2008. We need to get it documented and working again, and it needs
to be a roadmap goal even if doesn't have a champion. HLL interop is a
core differentiator of Parrot, a major selling point, and for HLL
implementers something that no other VM can offer. We need to make this
happen if Parrot is to have a distinguising feature that will attract
users apart from hosting Rakudo. If we can't get Tene++ motivated enough
to get on this, someone else needs to pick up where he left off. HLL
interop is too important to drop.

All of this might seem to put M0 into question. We need a better Parrot
right now in addition to a much better Parrot after M0, Mole and Lorito
land. I'll be continuing to lead the M0 effort, but will be putting more
emphasis on improving Parrot's existing internals and ensuring a
coherent vision as we move forward. M0 isn't magical fairy dust that we
can sprinkle on bad code to turn it into good code. Parrot will need a
number of changes before moving 100% to M0 becomes possible, and those
changes need as much attention as anything.

Finally, this begs the question of what we expect users to build their
code on. We're going to be gutting PIR, but that doesn't mean we don't
want anyone building on Parrot. We will be recommending the use of
languages and libraries like nqp, Winxed and Rosella as the primary
interface for user-level interaction with Parrot. We will test these
level languages extensively and ensure that they continue to work and
provide a stable foundation that people can use to build awesome things.

masak's full send on #perl6 was "well, Parrot is a foundering project on
top of a wonderful vision. meaning, it could still be great if it gets
its act together. M0 could be that, who knows?" I agree with this.
Parrot's goal of being a top-flight VM for self-hosted interoperable
languages is a great vision worth working toward. We as a project need
to get our act together, but we have a talented and motivated group of
hackers. We can build Parrot into what it should be, and I'm excited to
help make it happen.


More information about the parrot-dev mailing list