[chromatic]

I believe some of the "historical baggage" lumped on Parrot and, by extension, its developers came from deliberate design and project decisions of the Rakudo developers. I'm happy to lay out what I believe the Parrot team did wrong (and have done so in detail elsewhere), but I've long grown tired of the historical rewriting that goes on in the P6 world.

[pwr22]

Could you link to your elsewhere. I'm keen to learn more of the P6 history, good and bad

[chromatic]

I wrote my experiences with Parrot in specific:

http://www.modernperlbooks.com/mt/2013/02/goodnight-parrot.h...

I did not write but agree with this view of the Parrot Foundation:

http://whiteknight.github.io/2015/01/14/parrotfoundation.htm...

Similarly, this retrospective from another ex-Parrot developer has similar feelings about the P6 language:

http://whiteknight.github.io/2015/01/14/parrotfoundation.htm...

I personally wrote several parts of "Theme, Pragmatics, and Purpose in Programming Language Implementation":

http://outspeaking.com/words-of-technology/theme-pragmatics-...

... and I had several discussions which led to the writing of "Why Perl Didn't Win" and did some minor editing to it recently:

http://outspeaking.com/words-of-technology/why-perl-didnt-wi...

[kbenson]

I assume your second whiteknight link was meant to be this[1]. It's interesting comparing his view of Parrot with yours. He may share some feeling with you about Perl 6, but it appears his conclusion about why Parrot didn't work out is quite different. It appears he goes out of his way to explain that Perl 6 did what it had to to get past Parrot's failings:

The P6 folks were developing their own bindings which used the (much nicer) 6model and the (much nicer) P6 native bindings instead. After a while I had to ask myself why I was fighting in the weeds so much, when the P6 people were rising above the problems of Parrot and doing things better? If my writing these things wasn’t helping anybody, why bother with it?

Notice that the P6 folks were having their biggest successes when they bypassed Parrot, which isn’t exactly a roadmap for synergy and mutual success.

He goes on to say he doesn't really like Perl 6, and doesn't believe in it's direction or that it can achieve it's goals. That's fine. Nobody has to like everything.

I have to say I agree with his assessment that Parrot's goals have largely been met by multiple other projects at this point. This post has convinced me even more that not relying on Parrot was the right choice, which is sad because I was a big fan for many years. Parrot was a train wreck. Some people think Perl 6 was or still is a train wreck. But that wreck has been making progress, and may actually arrive at the station. Can the same be said of Parrot? Can you really lay all that blame, or even a majority of it on Perl 6? If people wanted to work on Parrot, they would.

1: http://whiteknight.github.io/2015/01/15/parrottheend.html

[chromatic]

Yes, that's the link I mispasted. Thank you.

What whiteknight didn't say was he'd spent over a year volunteering to port 6model to Parrot and had been repeatedly rebuffed. (He's a much nicer person than I am.) You can find that in the weekly parrotsketch logs too.

Look at the Ohloh logs of contributor activity. You can see them drop right after Rakudo said they were going to abandon the NQP Parrot was using. That's what finally drove people away.

Any post-hoc justification you hear about Rakudo dropping support for Parrot because almost everyone left is silliness. Why work on something when you've been all but told is going to be unused, no matter what you do? Especially when you've been told not to fix the things you wanted to fix.

[kbenson]

All I see from that is more evidence for whitenight's theory that separating Parrot and Perl 6 was a major contributing factor to the problems. Instead of one incredibly ambitious project there were two incredibly ambitious projects (possibly half the work of the prior project, but undeniably ambitious) which relied on each other in myriad obvious and hidden ways, in both a technical and social sense.

Looking back on it, it seems obvious they were both doomed, as long as they were locked in that spiral of needing the other to advance to be able to move forward, and not being able to really drive the other project themselves. Think the only way out was to either come together again, not in tighter integration, but as a single project, or to split apart and fulfill their own needs. I think joining was actually the riskier option, there were many people in Parrot with no interest in Perl 6 beyond it's ability to drive Parrot. whitenight is frank and unapologetic in this, as he well should be.

So what if Perl 6 people stalled on giving the okay for Parrot to migrate some implementation details to Parrot? They were both immature projects, feeling their way through how to proceed. There are countless possible reasons for that, but a big one might be that they were unsure of the continued viability of that implementation, and didn't want to waste weeks of some Parrot dev's time to turn around a week after they finished and say "sorry 'bout that, but 6model really isn't going to work and we're going to scrap it for something else."

Then Perl 6 decides to hedge it's bets on Parrot. Sooner than later, because it was always the idea Perl 6 would run on multiple back-ends. Parrot as it existed could have survived that, if it hadn't already been floundering for a long time. They had recently decided to refocus on Perl 6, after realizing that the whole "VM for everything dynamic" thing wasn't really working, at least not as a main dev goal, and they were desperate for a fix. So what would that have done? Make a situation whose viability could best be described as "ridiculously horrible" all better? The best that could be hoped for there was "still pretty fucking bad."

Whiteknight lays out a pretty compelling case that Parrot was slowly imploding for a very long time. I trust his assessment, as he's one of the few people I recall landing major branches in Parrot, and fairly consistently. I understand that you put a lot of time into Parrot, and also Perl 6. Years. But that doesn't change the fact that many of Parrot's devs decided it wasn't worth continuing. Again, I think whiteknight gives a good explanation; the goals of the project had be mainly met already by outside sources.

Was the situation bad? Undoubtedly, or we wouldn't be having this exchange, but I like to think if you asked people involved from both sides candidly whether or not they thought some blame lied with themselves, they would own up to that.

> Any post-hoc justification you hear about Rakudo dropping support for Parrot because almost everyone left is silliness.

Rakudo hasn't dropped support for Parrot. Nobody has said that it will. Parrot isn't deal

> Why work on something when you've been all but told is going to be unused, no matter what you do? Especially when you've been told not to fix the things you wanted to fix.

Because, as should be obvious to anyone following along, Parrot usually did what it wanted anyway, as evidenced by the planned major shift towards treating Perl 6 as a first class citizen again. You can't shift back to Perl 6 without having shifted away. The stories don't line up. You can't be a controlling prima donna and be sidelined, because being sidelined means a lack of control.

You want to know what this looked like from the outside? Parrot was going downhill for a long time, and when they tried to re-hitch their horse the Perl 6, it was too little too late.

You can reply if you like, and I'll be happy to discuss this with you more here, in this thread, but I think I'm done engaging you on this issue here in the future or elsewhere for the foreseeable future (I imagine you're fine with that). I've spent a lot of time over the years here on this issue with you because you've garnered quite a bit of respect from me due to your prior works, but the way in which you see the people involved in this situation and how you assess their motivations is fundamentally foreign to me. I'm not sure anything I've ever said has actually ever made you think about a single point the issue in a different way than you had before, and if I'm not even having that effect, then I'm not really doing anything worthwhile in these conversations.

[chromatic]

So what if Perl 6 people stalled on giving the okay for Parrot to migrate some implementation details to Parrot?

My problem is that this gets argued both ways. This thread is far too nested anyhow, but here's my complaint.

Yes, Parrot and Rakudo drifted apart. There were poor decisions all around. Patrick and Allison and I in particular talked extensively about how to improve things.

We decided this: I personally volunteered to fix any bug, patch any memory leak, add any feature that Rakudo wanted. I spent a lot of time doing that. Several other people also volunteered to add any feature Rakudo wanted.

Time and time again, we went to the Rakudo developers with proposals and they said "No" or "Not yet". Thus my work was mostly fixing bugs and making minor performance improvements. (The major improvements were in that list. So were major revisions of most parts of Parrot to make it smaller, simpler, and faster.)

Then the NQP rewrite came. Parrot faced using a deprecated NQP for its compiler tools, adopting a deprecated NQP so it would keep working, or rewriting all of its compiler tools.

At that point, I decided that there was no point in working on Parrot and left.

I'll take responsibility for everything I did wrong (or for not doing things I should have done). I don't accept the current party line from Rakudo, however. To wit, "Parrot of course had to be abandoned, because it wasn't meeting Rakudo's needs."

Parrot may or may never have succeeded. Rakudo may or may not have succeeded on Parrot. We'll never know. Yet the claim that Parrot developers weren't interested in making it work with Rakudo is nonsense. In my experience, it was the other way around.

[pwr22]

Thanks for sharing. I never knew you were so involved back then or that people were being treated that way