6 ms·

I think at one point, prior to MoarVM being announced, there was still a chance Parrot could have been "saved". The deprecation policy was a point of contentio

I think at one point, prior to MoarVM being announced, there was still a chance Parrot could have been "saved". The deprecation policy was a point of contention, sure. It was poorly implemented in practice--but it was as much to help Rakudo as it was to reduce the amount of churn in Parrot. Rakudo probably would have had less trouble with it if Rakudo had less code which poked into the internals of Parrot. That's half the fault of Parrot, which had poor design of certain pieces, as well as Rakudo, which rejected a lot of offers to pull some or most of that code into Parrot. (That's a theme.) I personally spent most of my time on Parrot doing things to improve it for Rakudo--fixing a lot of unpleasant bugs, both in Parrot and Rakudo, for example as well as improving performance. I and other Parrot developers asked multiple times for a list of issues Rakudo wanted Parrot to address. Occasionally we'd get a list and work on them--but I also volunteered to focus on specific improvements for Rakudo and was told "No" or "Not yet" multiple times. You can see that too, if you look in the IRC logs--and not just for things I wanted to do. Andrew Whitworth, in particular, spent months or years on tenterhooks, volunteering to implement the object system called "sixmodel" in Parrot, but he was always told that it wasn't fully designed yet or it wasn't mature enough. Eventually he left the project too. On one side, I took a lot of criticism from Rakudo developers for not pushing Parrot harder to be what they wanted and on the other side, I took a lot of criticism from Rakudo developers for trying to change Parrot to be what they wanted. In the face of that seeming contradiction, it seemed obvious to me that they'd already decided to write and maintain a new backend VM from scratch. My priority--getting a usable P6 release out and stable for general purposes--was clearly incompatible with that decision. Rakudo Star was supposed to come out as a "useful and usable" distribution for early adopters over four years ago, and to my knowledge, it's still only nominally useful and usable for very few purposes. That is one of my most substantive criticisms of the whole process. Rakudo and P6 have a long history of claiming to be about eighteen months away from general usability, but the project's history is littered with rewrites, questionable technical decisions, and many, many good people leaving in frustration--sometimes quiet and sometimes not. I begrudge no one working on it, but I believe it's on a path to ever less relevance without a dramatic change in project management. I'll reluctantly take the blame for mistakes I made as a member of the P6 design team and as a leader in Parrot, but I object to rewriting history to suggest that Parrot was solely at fault for Rakudo's current state.

kbenson 12y ago
I understand you were in what seems an untenable position between Rakudo and Parrot. I'm not trying to further the "Parrot caused all Rakudo's problems" argument, just my own which is that Parrot and Rakudo were destined to either split farther or merge at some point. It's unfortunate that Parrot started towards what appeared to be a merge at just about the same time Rakudo decided a deeper split was the only way forward. Personally, I've always viewed MoarVM as a spiritual successor to Parrot. Parrot and Rakudo begat NQP, and NQP has survived parrot. It's a shame more parrot devs didn't jump to MoarVM, but they of course had their own motivations for working on Parrot in the first place, which may not align well with being "the Perl 6 VM" (among any number of other reasons), which MoarVM exemplifies more than Parrot had in many years.
- chromatic 12y ago
  It's a shame more parrot devs didn't jump to MoarVM Why would they? Rakudo's position was "Parrot is fundamentally broken and Rakudo is actively moving away from it." You can see how Parrot's development all but stopped within a few weeks of that discussion from the Ohloh link I posted earlier. More than that, Moar's development began in secret around that time, so how would Parrot developers know that they should have been working on that instead? (Rakudo developers often claim that Parrot had no singular focus on Rakudo, but that graph argues differently to me. Then again, Rakudo developers also claim that they decided against using Parrot because Parrot development ceased, but that's an obvious post hoc ergo propter hoc argument to anyone who looks at the chronology.) Personally, I've always viewed MoarVM as a spiritual successor to Parrot. I looked at the code briefly after its announcement. It seems to repeat most of the long-standing architectural flaws of Parrot and it ignored much of the design work that we had been doing to make a Parrot which could compete favorably with fast VMs such as LuaJIT or v8. (My impression then was that, if Rakudo hadn't chased away Parrot developers and Parrot were free to ignore pesky things like backwards compatibility, deprecation, and users who wanted it to continue to work, Moar looked a lot like Parrot would have after the same time period. It was pretty disappointing.)
  - kbenson 12y ago

kbenson 12y ago

I understand you were in what seems an untenable position between Rakudo and Parrot. I'm not trying to further the "Parrot caused all Rakudo's problems" argument, just my own which is that Parrot and Rakudo were destined to either split farther or merge at some point. It's unfortunate that Parrot started towards what appeared to be a merge at just about the same time Rakudo decided a deeper split was the only way forward. Personally, I've always viewed MoarVM as a spiritual successor to Parrot. Parrot and Rakudo begat NQP, and NQP has survived parrot. It's a shame more parrot devs didn't jump to MoarVM, but they of course had their own motivations for working on Parrot in the first place, which may not align well with being "the Perl 6 VM" (among any number of other reasons), which MoarVM exemplifies more than Parrot had in many years.

chromatic 12y ago
It's a shame more parrot devs didn't jump to MoarVM Why would they? Rakudo's position was "Parrot is fundamentally broken and Rakudo is actively moving away from it." You can see how Parrot's development all but stopped within a few weeks of that discussion from the Ohloh link I posted earlier. More than that, Moar's development began in secret around that time, so how would Parrot developers know that they should have been working on that instead? (Rakudo developers often claim that Parrot had no singular focus on Rakudo, but that graph argues differently to me. Then again, Rakudo developers also claim that they decided against using Parrot because Parrot development ceased, but that's an obvious post hoc ergo propter hoc argument to anyone who looks at the chronology.) Personally, I've always viewed MoarVM as a spiritual successor to Parrot. I looked at the code briefly after its announcement. It seems to repeat most of the long-standing architectural flaws of Parrot and it ignored much of the design work that we had been doing to make a Parrot which could compete favorably with fast VMs such as LuaJIT or v8. (My impression then was that, if Rakudo hadn't chased away Parrot developers and Parrot were free to ignore pesky things like backwards compatibility, deprecation, and users who wanted it to continue to work, Moar looked a lot like Parrot would have after the same time period. It was pretty disappointing.)
- kbenson 12y ago