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

Andrew Whitworth wknight8111 at gmail.com
Sat Sep 10 21:33:31 UTC 2011


I have formulated my thoughts, after talking with several people over
the past few days, in a (lengthy) blog post:

http://whiteknight.github.com/2011/09/10/dust_settles.html

The short version is this: JavaScript and Python as dukeleto suggests
are great goals, and demonstrating working compilers for each and
interoperability between them is an important milestone. However,
these are not and cannot be our current, primary goal. Our current
goal should be improving Rakudo, and doing what we can to make Rakudo
better, and to make Parrot better for Rakudo. JavaScript and Python
compilers serve as a refinement to narrow that focus and help to keep
us from losing sight of some bigger goals over time. Right now we need
to focus on Rakudo because Rakudo is our user base. We should make
design decisions with an eye towards the impact they will have on
JavaScript and Python, but we need to focus primarily on Rakudo.

I think any other course of action, modulo a few small tweaks, will
bring negative consequences to both projects.

--Andrew Whitworth



On Wed, Sep 7, 2011 at 3:46 PM, Jonathan "Duke" Leto <jonathan at leto.net> wrote:
> Howdy,
>
> 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
> deprecations
> 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
> design.
>
> 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.
>
> Duke
>
>
> [0] http://irclog.perlgeek.de/parrot/2011-09-06#i_4379752
> [1] http://isparrotfastyet.com/
> [2] https://github.com/whiteknight/jaesop
> [3] https://github.com/lucian1900/puffin
> [4] https://github.com/parrot/parrot/blob/master/api.yaml
>
> On Mon, Sep 5, 2011 at 2:02 PM, Christoph Otto <christoph at mksig.org> 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/all_hll_test.pl. 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
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>
>
>
>
> --
> Jonathan "Duke" Leto <jonathan at leto.net>
> Leto Labs LLC
> 209.691.DUKE // http://labs.leto.net
> NOTE: Personal email is only checked twice a day at 10am/2pm PST,
> please call/text for time-sensitive matters.
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>


More information about the parrot-dev mailing list