8 ms·

Unless the Singularity has occurred and no one told me, everyone has emotions. I prefer, however, to discuss facts backed up by primary sources, such as the com

Unless the Singularity has occurred and no one told me, everyone has emotions. I prefer, however, to discuss facts backed up by primary sources, such as the commit stats linked earlier or mailing lists or IRC logs. Do you have an opinion about the situation based on those?

kbenson 12y ago
Of course. I'm not making some pie-in-the-sky assertion that arguments should be devoid of emotion, just that I had noticed what appeared enough emotion to overrule civil discourse in the past. That said, after re-reading your original comment, I don't see much to disagree on (except for one thing, which I'll cover later), and it doesn't seem to exhibit many of the problems I was alluding to, so you have my apologies. It was inappropriate of me to bring that up in this context. What I should have commented on was that Parrot was all but dead long before MoarVM put the last nail in the coffin. I doubt the announcement did much beyond cement what most developers already knew - Parot was not well suited for it's original purpose, whether you view that as a VM for P6 or a general purpose VM, specifically because for too long it had tried to follow both paths to the detriment of all. My impression of Parrot, as an outsider who consumed quite a bit of the public information available about parrot development, ended up being that Parrot was too experimental of a VM, and never moved beyond the stage of being a fun sandbox for developers to come experiment in. When P6 was still coalescing around how to implement what was in the spec (and revising the spec in light of that), this didn't matter much. As P6 increasingly moved towards an actual implementation, Parrot's misalignment with what P6 needed along with Parrot's deprecation policy caused many problems between the projects. I think at one point, prior to MoarVM being announced, there was still a chance Parrot could have been "saved". But by saved, I mean continue on as a sandbox for developers to experiment in, possibly without ever culminating in a VM that was useful as primary target for a language. If enough developers would have been willing to continue with this truth exposed (and I'm not sure enough would), then if Parrot and made the choice to continue as a "general purpose VM" instead of primarily a P6 target, it may have survived as a sandbox. I'm interested in your opinion on this interpretation - not because I think any of it is news to you, I'm sure it's not - but the opposite, in fact. This view is in no small part informed by your own writings on the subject over the years. P.S. I was completely serious before when I said I missed your more frequent posting on modernperlbooks.com. I hope that no matter what the future holds for you, that it also includes you writing about technical issues in blog or book form (and enjoying doing so!). I know you've helped solidify my thinking on a great many things over the years, to my great benefit.
- chromatic 12y ago
  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

Of course. I'm not making some pie-in-the-sky assertion that arguments should be devoid of emotion, just that I had noticed what appeared enough emotion to overrule civil discourse in the past. That said, after re-reading your original comment, I don't see much to disagree on (except for one thing, which I'll cover later), and it doesn't seem to exhibit many of the problems I was alluding to, so you have my apologies. It was inappropriate of me to bring that up in this context. What I should have commented on was that Parrot was all but dead long before MoarVM put the last nail in the coffin. I doubt the announcement did much beyond cement what most developers already knew - Parot was not well suited for it's original purpose, whether you view that as a VM for P6 or a general purpose VM, specifically because for too long it had tried to follow both paths to the detriment of all. My impression of Parrot, as an outsider who consumed quite a bit of the public information available about parrot development, ended up being that Parrot was too experimental of a VM, and never moved beyond the stage of being a fun sandbox for developers to come experiment in. When P6 was still coalescing around how to implement what was in the spec (and revising the spec in light of that), this didn't matter much. As P6 increasingly moved towards an actual implementation, Parrot's misalignment with what P6 needed along with Parrot's deprecation policy caused many problems between the projects. I think at one point, prior to MoarVM being announced, there was still a chance Parrot could have been "saved". But by saved, I mean continue on as a sandbox for developers to experiment in, possibly without ever culminating in a VM that was useful as primary target for a language. If enough developers would have been willing to continue with this truth exposed (and I'm not sure enough would), then if Parrot and made the choice to continue as a "general purpose VM" instead of primarily a P6 target, it may have survived as a sandbox. I'm interested in your opinion on this interpretation - not because I think any of it is news to you, I'm sure it's not - but the opposite, in fact. This view is in no small part informed by your own writings on the subject over the years. P.S. I was completely serious before when I said I missed your more frequent posting on modernperlbooks.com. I hope that no matter what the future holds for you, that it also includes you writing about technical issues in blog or book form (and enjoying doing so!). I know you've helped solidify my thinking on a great many things over the years, to my great benefit.

chromatic 12y ago
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.