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

Tue Sep 6 02:19:26 UTC 2011

I agree with cotto, I don't even think parrot needs a deprecation
policy right now since parrot is not stable enough. And I don't think
parrot should keep lua/partcl working on parrot any new release. Why?
Almost nobody is developing them, almost nobody is keeping use these
project, even as a play toy. So why parrot is so afraid to break them?
and then what parrot's goal? In my opinion, I think it should be
making rakudo better on parrot, keeping winxed working, and then
making parrot better for other languages. If parrot can't, rakudo will
be ported to other VMs eventually, and parrot will have no users, and
can't attract new developers participating in project. And some
developers still keeps paying close attention to parrot, but never
join in. Parrot loves improvement, but it's too conservative, and it's
not at right point to keep some conservativeness. What worst is, if
parrot can't support rakudo well enough, which is the core user of
parrot, how can parrot well support other languages too? I'm sorry if
the wording is discourteous. :)

On 9月6日, 上午5时02分, "Christoph Otto" <christ... 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