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

20 views
Skip to first unread message

Christoph Otto

unread,
Sep 5, 2011, 5:02:37 PM9/5/11
to parro...@lists.parrot.org, perl6-c...@perl.org
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

Darren Duncan

unread,
Sep 5, 2011, 5:25:49 PM9/5/11
to Christoph Otto, perl6-c...@perl.org, parro...@lists.parrot.org
Speaking not as a current Parrot implementer, but as an intended HLL implementor
over Parrot, I generally agree with what Christoph is saying here. This
includes not being afraid to break things at a quicker pace in order to move
forward. -- Darren Duncan
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

Jimmy Zhuo

unread,
Sep 5, 2011, 10:19:26 PM9/5/11
to parro...@lists.parrot.org
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. :)

_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

Michael Hind

unread,
Sep 5, 2011, 10:35:27 PM9/5/11
to parro...@lists.parrot.org, Christoph Otto
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 forward.

We need to make sure that we have a good liaison with HLL;s, particularly rakudo.

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)

--
Michael H. Hind

Cell: +44 (0) 7877 224 745

Moritz Lenz

unread,
Sep 6, 2011, 1:44:26 AM9/6/11
to parro...@lists.parrot.org
Hi,

On 09/06/2011 04:19 AM, Jimmy Zhuo wrote:
> I agree with cotto, I don't even think parrot needs a deprecation
> policy right now since parrot is not stable enough.

maybe we need one, but it should be much looser than the current one.
Something like "Don't break stuff that HLLs use, unless you provide and
document an alternative".

Or maybe it should read "be nice to HLLs".

Whatever it turns out to be, it should emphasize that parrot does have
users right now, and that parrot developers should care about its users
-- it's just that "care about users" doesn't necessarily mean preserving
APIs as the current deprecation policy requires.

Cheers,
Moritz
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

Jimmy Zhuo

unread,
Sep 6, 2011, 2:14:20 AM9/6/11
to parro...@lists.parrot.org
Mostly, if parrot breaks rakudo, pull a patch request to rakudo/nqp is
good choice. :)

On 9月6日, 下午1时44分, Moritz Lenz <mor...@faui2k3.org> wrote:
> Hi,
>
> On 09/06/2011 04:19 AM, Jimmy Zhuo wrote:
>
> > I agree with cotto, I don't even think parrot needs a deprecation
> > policy right now since parrot is not stable enough.
>
> maybe we need one, but it should be much looser than the current one.
> Something like "Don't break stuff that HLLs use, unless you provide and
> document an alternative".
>
> Or maybe it should read "be nice to HLLs".
>
> Whatever it turns out to be, it should emphasize that parrot does have
> users right now, and that parrot developers should care about its users
> -- it's just that "care about users" doesn't necessarily mean preserving
> APIs as the current deprecation policy requires.
>
> Cheers,
> Moritz

Lucian Branescu

unread,
Sep 6, 2011, 4:16:05 AM9/6/11
to Christoph Otto, perl6-c...@perl.org, parro...@lists.parrot.org
On 5 September 2011 22:02, Christoph Otto <chri...@mksig.org> wrote:
> 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.

Unsurprisingly, I agree. I went into GSoC knowing that Parrot had
issues and no real interop story, but what I found was worse than I
had expected.

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

Exactly. Parrot has absolutely no interesting features about its
competitors at the moment. Current "dream parrot" only has HLL interop
as a distinguishing feature, it won't beat good VMs on other things.
It's a little sad that the best interop you can get atm. is on the JVM
(much better than parrot's).
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

Andrew Whitworth

unread,
Sep 6, 2011, 9:40:06 AM9/6/11
to Jimmy Zhuo, parro...@lists.parrot.org
I'm very strongly in favor of this new idea and am looking forward to
getting started on some of the necessary work that needs to be done.
There are some things that need to be broken so they can be re-made
better. Just off the top of my head, things like PCC, Exceptions, MMD
and the object model are going to need some disruptive changes in the
coming months, and having the freedom to pursue the correct course of
action without having to wait months at a time for deprecation periods
to elapse is good. Relying on abstraction layers like NQP and Winxed
are going to be extremely important during this time.

On Mon, Sep 5, 2011 at 10:19 PM, Jimmy Zhuo <jimmy...@gmail.com> wrote:
> 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.

Lua has been extremely stable in the past. It works now and has worked
for a long time. It also tends to be very easy to maintain. I don't
think we need to drop Lua support for any reason, and having it around
is a good thing. We may want to start transitioning it away from being
written in so much PIR code, but that's something we can talk about in
the future. Having a working Lua brings us several benefits, including
a new dimension of testability, the ability to test language interop
(you need at least two HLLs to test interop, and we have working Lua
right now), etc.

If the new Partcl is written in NQP, and if we're going to try and
keep NQP stable, partcl should continue to be mostly stable. Mostly. I
don't know its current status but I do know that historically it has
been more fragile than Lua. If we have people who are interested in
working on it, we should continue to support that effort. If not, we
can't.

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

That's a great point. We do need to improve the Rakudo experience.
That needs to be a big focus of our efforts in the coming months.
It's been said before that Parrot development moves too slow for
Rakudo, and that is the very first thing that should change. Parrot
should be moving quickly enough for Rakudo to have necessary changes
added to Parrot core with minimal effort. Obviously we need to find
ways to take the things Rakudo needs and present them in a way that
can be usable by other languages. Our biggest user right now is
Rakudo, and they also happen to be one of the bigger drivers of
improvements at the Parrot level. We need to make it easier for their
changes and their needs to be added to the core Parrot repo.

--Andrew Whitworth
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

Will Coleda

unread,
Sep 6, 2011, 1:36:49 PM9/6/11
to Andrew Whitworth, Jimmy Zhuo, parro...@lists.parrot.org

--
Will "Coke" Coleda

I'll keep partcl (PIR) and partcl-nqp running, though collaborators are very welcome.

>> 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.
>
> That's a great point. We do need to improve the Rakudo experience.
> That needs to be a big focus of our efforts in the coming months.
> It's been said before that Parrot development moves too slow for
> Rakudo, and that is the very first thing that should change. Parrot
> should be moving quickly enough for Rakudo to have necessary changes
> added to Parrot core with minimal effort. Obviously we need to find
> ways to take the things Rakudo needs and present them in a way that
> can be usable by other languages. Our biggest user right now is
> Rakudo, and they also happen to be one of the bigger drivers of
> improvements at the Parrot level. We need to make it easier for their
> changes and their needs to be added to the core Parrot repo.
>
> --Andrew Whitworth
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev

_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

James E Keenan

unread,
Sep 6, 2011, 6:38:49 PM9/6/11
to parro...@lists.parrot.org
On 9/6/11 9:40 AM, Andrew Whitworth wrote:
> I'm very strongly in favor of this new idea and am looking forward to
> getting started on some of the necessary work that needs to be done.
> There are some things that need to be broken so they can be re-made
> better. Just off the top of my head, things like PCC, Exceptions, MMD
> and the object model are going to need some disruptive changes in the
> coming months, ...

At the risk of sounding like I'm trying to resurrect "roadmap goals",
may I ask: Do you have an order of battle for these disruptive changes?

In other words, do you have an idea as to which areas you yourself
expect to be working on, and in what order?

And are there are any areas that can be double-teamed?

> Relying on abstraction layers like NQP and Winxed
> are going to be extremely important during this time.
>

Can you elaborate on that? Some of our developers are probably already
working with those languages as abstraction layers, but for others it
might be virgin territory.

Thank you very much.

kid51

_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

Jonathan "Duke" Leto

unread,
Sep 7, 2011, 3:46:37 PM9/7/11
to Christoph Otto, parrot-dev
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

--
Jonathan "Duke" Leto <jona...@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

Andrew Whitworth

unread,
Sep 7, 2011, 4:11:12 PM9/7/11
to Jonathan Duke Leto, parrot-dev
On Wed, Sep 7, 2011 at 3:46 PM, Jonathan "Duke" Leto <jona...@leto.net> wrote:
> 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.

I think I agree with this as well. The problem with stable releases is
that they have been mostly arbitrary. As you mention, we didn't really
do anything different or special leading up to a stable release, and
the results are no different from any other release. The biggest
result of them was that in the days immediately following stable
releases things tended to break because of the deprecation boundary.
If we don't have a rigid deprecation timeline, those breakages will be
spread out more thinly.

It would be one thing if we had some kind of process for making a
stable release be more "stable" than any other release. But every
three months we cut it from master like everything else. Also, we
haven't exactly been getting regular "support requests" for patches to
be made to stable releases. It is one thing if we needed to maintain a
long-term support branch for making patches. It's another thing if
it's just another static tag in the repo.

What we do need is some kind of way to differentiate the releases that
are intended for packaging. Setting aside certain releases each year
that are suitable for that would be a good thing. Whether we want it
to be numerical (X.0, X.6, etc) or be selected some other way is
another question.

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

I don't think we need to distance ourselves from it. I think we would
do well if we presented a compelling platform for perl6 development.
That said, we clearly aren't the most compelling platform right now.
All else being equal, a perl6 project started tomorrow wouldn't choose
Parrot. Our biggest draw right now, if we can call it that, is sheer
momentum. It would be costly for Rakudo to move to another VM
wholesale, although much of that cost has been mitigated by the
NQP/6model abstraction layer.

I don't want to distance ourselves from Rakudo. That's not a good
idea. Most things we can do to make Parrot a better host for Rakudo
are going to make us a better host for other languages as well. If the
projects grow further apart over time, that's one thing. But so long
as Rakudo is a user of Parrot, we need to do everything we can to make
Parrot good for Rakudo.

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

I actually was having this exact same conversation with chromatic
today. Considering that Python and JavaScript are two of the most
popular languages today, and the fact that they can't really be made
to interoperate on any other platform (yet) is something of a niche
that is worth pursing. Ruby is another great target, although cardinal
might be beyond resurrection at this point. Other languages certainly
should not be excluded or ignored (Lua, Partcl, etc), and so long as
they work or are in development that's a good thing for us.

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

The new Jaesop stage 0 is very promising, and I'm happy to both talk
to people about it and hand out commit bits to interested
participants. I don't know the status of Puffin right now, but I
remember looking in on it during the summer and being suitably
impressed. These are as good of starting points as any. Both of these
are going to benefit significantly from object model refactors,
improvements to lexicals, improvements to Sub/NameSpace, improvements
to PCC, and other big changes we already have planned.


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

Again, let's not treat Rakudo as some kind of foreign party. They are
still big users of Parrot and we need to do what we reasonably can to
make their experience better. We need to put priority on refactors and
improvements that benefit Rakudo *and* other languages as well. Many
things, especially various performance improvements, will have
universal benefits.

I know emotions are running high right now because of all the emails
and charged IRC conversations. Let's all not lose site of the fact
that we have serious improvements to make, that we have existing users
who need to be kept happy and we want to attract future users as well.
Having a vision and concrete goals are good things, but make sure our
goals include all the things we want to be doing, not just focusing on
the new shiny.

Moritz Lenz

unread,
Sep 7, 2011, 4:52:42 PM9/7/11
to parro...@lists.parrot.org
On 09/07/2011 09:46 PM, Jonathan "Duke" Leto wrote:
> 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.

That wasn't quite my reasoning. My argument was more that stable
releases don't feel better in any way, and that performance regression
was just an example.

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

They do serve a purpose though: most distributions don't want to track
monthly releases, so we need to present a recommendation which version
to ship. If we abolish "stable" releases, we should have at least
"recommended" releases, even if there's no real reason to recommend them
over other releases.

> That being said, the way we store structured deprecation data in
> api.yaml [4] will
> become even more vital.

I'm curious, is there a plan how exactly a HLL dev could profit from
that data? (sorry for getting a bit off-topic here)

> Parrot needs to assume that Rakudo will port themselves to another VM or write
> their own.

Just for clarity, Rakudo doesn't want to move away from Parrot, but
cater to multiple backends, Parrot being one of them. (I think most
Parrot developers are well aware of that, but it doesn't hurt to repeat it.)

Patrick R. Michaud

unread,
Sep 7, 2011, 8:07:02 PM9/7/11
to Jonathan "Duke" Leto, parrot-dev
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.

http://github.com/pmichaud/rpbench-results .

> 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
http://www.modernperlbooks.com/mt/2011/08/no-policy-can-save-wrong-code.html:

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

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.

Pm
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

Will Coleda

unread,
Sep 7, 2011, 8:10:13 PM9/7/11
to Moritz Lenz, parro...@lists.parrot.org
On Wed, Sep 7, 2011 at 4:52 PM, Moritz Lenz <mor...@faui2k3.org> wrote:
> On 09/07/2011 09:46 PM, Jonathan "Duke" Leto wrote:
>> 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.
>
> That wasn't quite my reasoning. My argument was more that stable
> releases don't feel better in any way, and that performance regression
> was just an example.
>
>> 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.
>
> They do serve a purpose though: most distributions don't want to track
> monthly releases, so we need to present a recommendation which version
> to ship. If we abolish "stable" releases, we should have at least
> "recommended" releases, even if there's no real reason to recommend them
> over other releases.

We have tried to emphasize "supported" rather than "stable", and I
think the every 3 month schedule there works in light of
distributions.

Even duke called them stable in his email, though, so this distinction
probably needs more marketing.

>> That being said, the way we store structured deprecation data in
>> api.yaml [4] will
>> become even more vital.
>
> I'm curious, is there a plan how exactly a HLL dev could profit from
> that data? (sorry for getting a bit off-topic here)
>
>> Parrot needs to assume that Rakudo will port themselves to another VM or write
>> their own.
>
> Just for clarity, Rakudo doesn't want to move away from Parrot, but
> cater to multiple backends, Parrot being one of them. (I think most
> Parrot developers are well aware of that, but it doesn't hurt to repeat it.)
>
> Cheers,
> Moritz
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>

--
Will "Coke" Coleda
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

Ryan Voots

unread,
Sep 7, 2011, 6:51:53 PM9/7/11
to parro...@lists.parrot.org
On 09/07/2011 04:52 PM, Moritz Lenz wrote:
>> That being said, the way we store structured deprecation data in
>> api.yaml [4] will
>> become even more vital.
> I'm curious, is there a plan how exactly a HLL dev could profit from
> that data? (sorry for getting a bit off-topic here)

Long time lurker, potential HLL developer eventually. I believe the
idea is that giving it in a structured format is that it would allow an
HLL to do some build-time/static analysis on their code base to find out
if they're using any of the deprecated API. It could even be used by
NQP or the like to warn about it when building also.

Ryan Voots
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

Jimmy Zhuo

unread,
Sep 8, 2011, 12:18:13 AM9/8/11
to parro...@lists.parrot.org
On Sep 8, 3:46 am, "Jonathan \"Duke\" Leto" <jonat...@leto.net> wrote:
> 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.
>

I don't think so. It's a ecosystem, some trivial species may be
extinct. But, please be concerned with core species, please don't
exterminate them. I don't think it's a good idea to exterminate a core
specie for keeping some trivial species. Parrot is the foundation of
the ecosystem, what her point of existence is concerned with species,
not to distance herself from the ecosystem, not to distance herself
from the core species, not to stand high above the masses. :)
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

Jonathan "Duke" Leto

unread,
Sep 8, 2011, 2:11:58 AM9/8/11
to Jimmy Zhuo, parro...@lists.parrot.org
Howdy,

>> Parrot needs to distance itself from Perl 6 if we are ever going to interest

> I don't think so. It's a ecosystem, some trivial species may be


> extinct. But, please be concerned with core species, please don't
> exterminate them. I don't think it's a good idea to exterminate a core
> specie for keeping some trivial species. Parrot is the foundation of
> the ecosystem, what her point of existence is concerned with species,
> not to distance herself from the ecosystem, not to distance herself
> from the core species, not to stand high above the masses. :)

The word "distancing" is imprecise. I am refactoring to "disentangling".

I don't believe in trivial species. There are extinct species and there are
"aliving" species. Which living species would you call trivial? I can't think
of any. Also, no one has mentioned extermination.

In short, I think Parrot needs a shiny product that isn't Rakudo Perl 6 if it
wants to continue aliving and stay relevant. This is orthogonal but related to
Rakuo Perl 6 shipping an awesome, fast, spec-conforming implementation
of Perl 6.

Duke

Jimmy Zhuo

unread,
Sep 8, 2011, 7:57:16 AM9/8/11
to parro...@lists.parrot.org

On Sep 8, 2:11 pm, "Jonathan \"Duke\" Leto" <jonat...@leto.net> wrote:
>
> The word "distancing" is imprecise. I am refactoring to "disentangling".
>

I like 'disentangling'. :)

Andrew Whitworth

unread,
Sep 10, 2011, 5:33:31 PM9/10/11
to Jonathan Duke Leto, parrot-dev
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

_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

Jimmy Zhuo

unread,
Sep 11, 2011, 2:09:42 AM9/11/11
to parro...@lists.parrot.org
On Sep 11, 5:33 am, Andrew Whitworth <wknight8...@gmail.com> wrote:
> 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
>

I agree with whiteknight++, +INF. :)
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

Reply all
Reply to author
Forward
0 new messages