So you're not talking about what I was talking about, which was dealing with reality.

Were you there?

No way am I going to believe that that is a balanced characterization of what went down.

With all due respect, that's because you have no intent of reading the IRC logs or the mailing list archives of that time period. If you cared to do any research at all, you would have no trouble confirming my characterization of the event. You could start by looking at the commit rate to Parrot and correlating that with the "Rakudo doesn't want Parrot" discussions in December 2010 and January 2011 and then the Parrot commit rate going way down in February and March of 2011.

There is a correlation between those events.

"designed to be portable, with Parrot needing to evolve in to a dedicated NQP backend"

If you had bothered to do your research, you would know why that was never and would never be acceptable to Parrot.

It's sad that you can't be bothered, that you're so invested in propping up a project categorized by overpromising, underdelivering, and failure after failure that you're willing to take the sunshiney optimism of the people who were paid to work on the project over the opinion of dozens of volunteers who've been burned out or forced out of the project because they could no longer buy into the repeated promise that usable and useful software is just another six months away.

If you were truly interested in the truth, you'd ask the other people involved about their characterization of events.

You might start with a pointed question:

When Patrick and Jonathan said that they were going to rewrite NQP again to focus on VM independence because that independence was "important to the long term plans of Rakudo", what was your reaction?

Given that:

• Rakudo Star was less than a year old at that point
• Everyone acknowledged that that rewrite of NQP would mean a huge regression in the featureset of Rakudo on the rewrite branch
• Almost everyone acknowledged that development effort would necessarily be split between supporting the existing, working codebase and the rewrite
• If the rewrite went well, that would mean abandoning the existing development branch (the one on which Rakudo Star was based), which meant abandoning any users who'd tried to build anything with Star releases

... is it so difficult for you to conceive of a world in which volunteers would think that that circus of bungling was anything they'd like to participate in?

You know what's also sad? The fine whine of unrealistic expectations from Rakudo that Parrot could simultaneously provide a stable API (despite Rakudo reaching into the guts of Parrot) and meet every performance and feature goal of Rakudo, instantly updating Rakudo about any breakages, writing patches for Rakudo that they could apply when they saw fit, never actually testing Rakudo code against Parrot (that was Parrot's job, to test all external clients), and support existing abandonware that Rakudo had convinced people to import into the Parrot repository. With volunteer labor. To support a Rakudo project that had no qualms about breaking stuff their users had written or depended on—no qualms about not even testing that Rakudo broke stuff in its library or ecosystem.

So, yeah, when Rakudo said "The long term support plan of running on multiple VM backends is so important that we're going to break everything right now, less than a year after Rakudo Star came out, and spend a year getting us back to the place we are right now instead of passing more spec tests or writing documentation or making stable and useful packages or testing the ecosystem or anything else that actually gets a useful and usable P6 into the hands of real users," I think you'd have to be quite a fool to imagine that that was motivated by anything other than "We don't want to use Parrot anymore." I certainly wouldn't spend two and a half years not delivering working software unless I had a goal I considered more important.

After all, it's not as if most of the Rakudo developers making this choice lacked commit access to Parrot. (If you're in the mood for grim amusement, look at the commit history to see who wrote the long-lamented Parrot object system.)

Patrick's utterly compelling logic

Post hoc ergo propter hoc. Parrot had its problems. Everyone agrees on that—but when the paid developers of Rakudo told the volunteers of Parrot (volunteers who'd worked on Parrot for years because they wanted to help realize a usable and usefl P6) that Parrot had no place in Rakudo, what did you expect to happen?

Don't take my word for it. Ask Dan. Ask Allison. Ask Jesse. Ask Nat. Ask Andrew. Ask Julian. Ask Vasily.

reading the IRC logs or the mailing list archives of that time period.

I've long thought that the "first Parrot Developers Summit for 2011" gets to the heart of the issues. Am I wrong?

{Parrot needing to evolve in to an optimal NQP backend} was never and would never be acceptable to Parrot.

Does me changing the word from "dedicated" to "optimal" (which more accurately reflects what I think Patrick proposed) make any difference?

When Patrick and Jonathan said that they were going to rewrite NQP again to focus on VM independence ... Rakudo Star was less than a year old

Do you mean to focus more on VM independence?

Patrick decided to go for a multibackend VM strategy in the summer of 2009, as described in the talk video I linked earlier in this thread. Coding on the multi backend NQP began in October 2009.

Or was there just mass confusion between the projects (perhaps because Patrick didn't have sufficient time to keep channels properly open due to his RL circumstances)?

I'll let most of the rest of what you wrote pass without further comment, with a couple exceptions:

I think you'd have to be quite a fool to imagine that {the new object model rewrite} was motivated by anything other than "We don't want to use Parrot anymore." ... when the paid developers of Rakudo told the volunteers of Parrot ... that Parrot had no place in Rakudo, what did you expect to happen?

For better or worse, I have indeed drunk the P6 koolaid, including thinking that Patrick is a nice honest guy with integrity. I don't find credible the claim that Patrick said in 2011 that Parrot had no place in Rakudo.

I hear you about asking the Parrot folk you listed. I'm dubious about that being a good thing because it seems to me likely to be unnecessarily painful and divisive no matter what gets said. Which perhaps also applies to this exchange. So I'll leave you to have the last word if you wish to say something else.

Thank you for all the good things you do for Perl and for this exchange. I think I finally understand why you dislike Perl 6, or, rather, Rakudo.

~~ the P6 Spokesweaselfool

I think I finally understand why you dislike Perl 6, or, rather, Rakudo.

No, you really don't.

I've long thought that the "first Parrot Developers Summit for 2011" gets to the heart of the issues.

(I had to unblock that site from my DNS to look at it.) No, that link really doesn't (unless you like the part where one of the Rakudo developers stormed off in a fit rather than continue the discussion). What you're missing is The further NQP diverges from Parrot's semantics ..., the less competitive Parrot can be with regard to NQP., which you can see Patrick agreed with. In my mind, the most disappointing part is the agreement to migrate features from PCT, NQP, and Rakudo back into Parrot, replacing parts of Parrot that never actually materialized.

In other words, that was the assumption I (and it seems like other Parrot developers) operated under. That had long been a big point of contention. Resolving that with a plan made me feel better about the relationship between Parrot and Rakudo.

Except it never happened. Rakudo was back to blaming Parrot for every little perceived fault within weeks as well as delaying and deferring any migration of code in design or implementation. (Ask Andrew about that; I'm sure he remembers plenty of conversations where he was told not to start on 6model.) Perhaps that agreement was made in haste on Rakudo's side. All I know is that Rakudo dug itself further in the hole of a rewrite which, as predicted, took months and months to get back anywhere close to feature parity, and by that time I was done with the project.

Look at the timing of this discussion on IRC and the point at which developers left Parrot: within two months. All of the nice words everyone exchanged and the lovely plan everyone seemed to agree too, and then Rakudo's successfully chased almost everyone off. Nice work.

Coding on the multi backend NQP began in October 2009.

The most polite way I can think of to characterize that assertion is "complete nonsense", unless people were lying about what they were doing in October 2009. (Were you there? I was.)

I don't find credible the claim that Patrick said in 2011 that Parrot had no place in Rakudo.

I never mentioned Patrick and I'd never claim that he said that. You still can't resist putting words in other people's mouths, can you?

As you yourself said elsewhere in this mess of a thread, Patrick hasn't worked much on Rakudo in the past couple of years—so why would I claim he's one of the paid developers?

I hear you about asking the Parrot folk you listed.

Goodness forbid you get some actual perspective on what happened, rather than making up nonsense that you could otherwise easily verify.

No way am I going to believe that that is a balanced characterization of what went down.

Found it.

In the #parrotsketch discussion of September 06, 2011, I brought up the idea of making a list of potential Parrot improvements and another list of Rakudo's top priorities (from Parrot). Patrick said that there'd been lists like that made in the past and then said that I had "offered to work on them and we had deferred him from it."

"We" in that context means "Rakudo developers". "Them" means "Parrot improvements corresponding to Rakudo's top priorities".

That's why I keep saying "I offered to make Parrot improvements for Rakudo, but Rakudo told me not to" and "You can find documentation for this if you bother to look for it." Because that's what happened, no matter how much #perl6 wants to pretend otherwise.