Parrot is a foundering project on top of a wonderful vision.
mike.hind at gmail.com
Tue Sep 6 02:35:27 UTC 2011
I couldn't agree more.
I have always fe;t that we went into a deprecation policy far too early and
this is holding parrot development back.
I would recommend that we scrap the deprecation policy and try and move
We need to make sure that we have a good liaison with HLL;s, particularly
Fix things as needed and make sure that they are good for our monthly
releases, which I think we should continue with, avoiding emphasizing other
releases at the moment until we have something much more stable.
Cheers, Michael (mikehh)
(For some reason I seem to have sent this to Darren, rather than to the list
- correcting now)
On 5 September 2011 22:02, 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
> 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.
Michael H. Hind
Cell: +44 (0) 7877 224 745
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the parrot-dev