Parrot is a foundering project on top of a wonderful vision.
Patrick R. Michaud
pmichaud at pobox.com
Thu Sep 8 00:07:02 UTC 2011
On Wed, Sep 07, 2011 at 12:46:37PM -0700, Jonathan "Duke" Leto wrote:
> As an aside, it would be awesome if somebody built Is Rakudo Fast Yet.
> 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.
This would seem to be very much at odds with what chromatic++ wrote in
"The right solution is to invent a time machine and not kick Rakudo
out of the nest. (The rightest solution is to invent a time machine
and start implementing Perl 6 on Parrot from the first day as a
first-class citizen [...])."
I will willingly accept whatever focus Parrot chooses to have in this
regard. However, if distancing Parrot from Perl 6 in 2009 was a mistake,
we might not want to repeat or reinforce it further in 2011.
> 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.
This phrase of "Rakudo telling Parrot 'Don't Do That'" keeps being repeated,
and I really want it to stop. I've been unable to recall an actual instance
of me telling Parrot "don't make this change" for something that isn't
part of a published API. (I'd be very happy to be proven wrong here, so
that I can admit the mistake and we can move on. But I can't prove a
If the "don't do thats" were coming from other Rakudo developers or users,
then I don't know that they represented Rakudo's official position unless
they were also echoed by me. I admit it may have been difficult to make
that distinction in the past. Also, remember that "Perl 6" != "Rakudo",
and particularly #perl6 is not #rakudo. Just because someone on #perl6
or using Perl 6 has said something about Parrot doesn't at all mean it's
Rakudo's official position on the topic.
For the complaints that I have made, I believe I've tended to complain
not about the fact of the change itself, but rather about the lack of a
path to a viable alternative that we can use. If the change to Rakudo is
simple to make, we make it and move on (and often don't say anything about
it). If it's not, then we need Parrot's help to find a path, and sometimes
Parrot has not been helpful.
However, regardless of the past, let me try to make my (and Rakudo's)
official position abundantly clear now and for the future:
1. Neither I nor Rakudo claim or desire veto power over any changes that
Parrot desires to make, for whatever reasons the Parrot developers may
choose to make those changes.
2. If some change does cause things in Rakudo to break, we'd like some
help from Parrot developers in resolving the issue that goes beyond
"your fault, deal with it." The new relationship manager role should
help here but this has not been tested since the role was established.
If the breakage is in a published API, we may complain, if the breakage
is from Rakudo using unpublished internals, we will meekly accept
responsibility for our transgression and not complain (but we may
still want help to find a resolution).
3. When a change to Parrot is proposed (or made) that we feel is a
mistake, we feel some obligation as Parrot users to provide feedback
and say "that's the wrong path, please don't do it like that." We
fully recognize and accept that Parrot has the right to choose whatever
path it wants, even over our objections. Don't expect us to be
completely happy with the result, though, and we may grumble about
the choice from time to time afterwards if we feel it's a continuing
mistake (as we have for the deprecation policy).
4. Moritz and I continue to be the Parrot relationship managers,
and official statements of Rakudo positions come only from us.
Others can of course remark as they wish (as with any open source
project), but please weight such comments appropriately.
5. If at any time or on any issue the Parrot leaders want us to stop
providing feedback or to treat some issues as being "decided and not
open for further debate", simply identify them and we will stop.
The above holds equally true for NQP as well as Rakudo. If any of the above
seems ambiguous or unclear, let me know and I will try to clarify.
More information about the parrot-dev