Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: