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

Jonathan "Duke" Leto jonathan at
Wed Sep 7 19:46:37 UTC 2011


As a bit of back-story, I came to Parrot via Perl 6. I love and believe in the
ideals of Perl and Perl 6 in particular. But some painful truths need to be
thrown into the light, and then actions need to be taken. Otherwise, both
Parrot and Rakudo are dead in the water.

The past is gone, and the more time Parrot and Rakudo spend bitterly
complaining about it, the less relevant both projects become. The only thing
bitterly complaining about old wounds accomplishes is turning off new members
of the community that are interested in getting involved. So to people on both
sides: No More Bitter Complaints.

I agree that the deprecation policy was imposed too early. It seemed like a
good idea at the time, and we even modified it by changing stable releases
from 6 months to 3 months, but it is still too much like a straight jacket.

I talked to moritz++ on IRC [0] and he commented that Parrot stable releases
don't really feel like stable releases, because Rakudo has been bit by huge
performance regressions in stable releases. This comes from the fact that
we do not have automated performance testing infrastructure. IPFY [1] is a step
in the right direction, but we obviously need a whole lot more. As an aside,
it would be awesome if somebody built Is Rakudo Fast Yet.

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.

That being said, the way we store structured deprecation data in
api.yaml [4] will
become even more vital. We currently are reasonably good with actually storing
data in api.yaml, but we still have not yet gotten to the point where we have
easy-to-use and automated tools that fully utilize the data. I would like to
see an automated website that looks automates the easy-to-find 80% of
in projects that use Parrot. I don't want to hear the straw man of "deprecation
tools don't work/haven't been effective in the past" argument. We have only had
api.yaml for a short time, and we have a long way to go in using it effectively
and in an automated way. If no one beats me to automating a web-presence for
api.yaml, I will do it. It is actually a very nice and self-contained project
for new-comers wanting to dip their feet (*hint hint*).

Parrot needs to assume that Rakudo will port themselves to another VM or write
their own. They are actively researching this option, and I don't think Parrot
can afford to tie our future to Rakudo always being our biggest and most
influential user. The needs of Parrot have been holding back Rakudo and the
needs of Rakudo have been holding back Parrot.

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.

That being said, I will spell out my vision for the future of Parrot below. The
reason I think we need this vision is because if we embark on a huge set of
refactors without a *focus*, we will get what we have always gotten: Pleasing
nobody because we attempted to please everybody.

The new focus of Parrot will be to get two languages which are not Perl 6 to
interoperate. This will make good on our currently hollow promise of language
interop, as well as showing people that we are serious about languages that
aren't Perl 6.

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).

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

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.

That being said, if Parrot is successful in making Javascript and Python
interoperable on Parrot, and Rakudo chooses to keep a Parrot VM backend, we
will potentially have three awesome languages interoperating on Parrot, which
will truly be an amazing and worthwhile feat.



On Mon, Sep 5, 2011 at 2:02 PM, Christoph Otto <christoph at> wrote:
> 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
> long-
> 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
> mid-
> 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.
> Thanks,
> Christoph
> _______________________________________________

Jonathan "Duke" Leto <jonathan at>
Leto Labs LLC
209.691.DUKE //
NOTE: Personal email is only checked twice a day at 10am/2pm PST,
please call/text for time-sensitive matters.

More information about the parrot-dev mailing list