5 ms·

> the fighting mostly moved over to the Raku side after that I think the fight was mostly between people who wanted the Perl 6 project dropped, and the ones wo

by lizmat 6y ago

> the fighting mostly moved over to the Raku side after that I think the fight was mostly between people who wanted the Perl 6 project dropped, and the ones working on the Perl 6 project. In any case, since the rename to Raku, we have seen some disagreements in the community, but these have been solved (although in one case banning from the core has been necessary, unfortunately).

microtherion 6y ago
I distinctly recall some rather bitter disputes WITHIN the Raku community, where debates often revealed that the maintainers of the Perl 6 VM were not talking much with the maintainers of the Perl 6 frontend (which, absent ironclad and stable specs, was not a recipe for success), and sometimes the VM maintainers were not even interested in Perl 6!
- chromatic 6y ago
  I recall things differently! The leaders of the Parrot VM and the leaders of the P6 implementation and the P6 language designers were on the phone directly every week talking through things. Up until we weren't, but that was basically the point where the P6 language designers said they wanted to write their own VM anyway.
  - microtherion 6y ago
    Well, you were there and I was not; all my impressions are secondhand. But, looking back at my grandparent comment, I worded this really poorly. It was not whether the people were talking, but whether the components grew in convergent directions. My impression was that for extended periods they did not. Am I wrong?
    - lizmat 6y ago
      My take: 1. Parrot was initially intended to be the backend for Perl 6. 2. Perl 6 didn't materialize fast enough, so Parrot started focussing on hosting other scripting languages. 3. Parrot decided to become the backend for all scripting languages. 4. Parrot became less and less targeted towards Perl 6. 5. Parrot never really became a backend for any other scripting language. 6. Parrot became decicedly a poor fit for Perl 6. 7. Jonathan decided that maybe the JVM could also be a backend, and started porting 8. Building on that experience, Jonathan decided that they could write a dedicated backend for Perl 6, which became MoarVM 9. Parrot development dwindled to effectively 0. 10. During the Great List Refactor of 2015 (about 6 months before the first release) it became clear that porting the Parrot backend would be a lot of additional work, with no apparent upside 11. Parrot support was dropped before the first official release
    - chromatic 6y ago
      Parrot was always intended to support multiple languages, from Simon's original April Fools joke to Larry's dual desire to run both P6 and Perl in the same process on the same VM as well as to make CPAN available to all dynamic languages in the same process on the same VM. That's why Dan and Guido had a bet that Parrot would run Python faster than CPython, and that's why Parrot attracted contributors like Sam Ruby. It's definitely true that, as P6 dragged on and burned out a lot of contributors (including multiple project managers), many Parrot contributors thought that coupling Parrot's success to P6 was a mistake, but I can't see that as a change in focus because the multi-language focus was a goal from the start. Granted, Parrot did wander in the wilderness for a while waiting for the P6 design process to proceed, and Parrot did evolve in some unfortunate directions because of that. The rest of this comment covers 2007 onwards though. Your question about components is particularly interesting, because of what really happened. A couple of P6 developers wrote PCT, a set of tools and libraries to make developing compilers and languages on Parrot easier. This was a good thing, and Parrot users and developers started migrating their language implementations to that toolkit. The PCT developers refactored and revised this a couple of times, and to make that easier, eventually they took the code out of the Parrot tree and started syncing PCT into the Parrot tree on a semi-regular basis. I was working with them weekly to fix Parrot bugs, improve Parrot performance, and add Parrot features to reduce the amount of code necessary in PCT. Thus it's difficult for me to believe that the Parrot developers were designing and implementing Parrot away from P6. Toward the end of 2010, the P6/PCT developers said they were going to rewrite PCT to support multiple VM backends. I argued this would create a lot of churn in the language implementations actively using PCT (ironic, because the PCT developers spent a lot of time before and after this complaining bitterly that they couldn't keep up with Parrot churn) and would provide very little value for Parrot (PCT was out of tree already, and syncing in code designed explicitly to undercut Parrot seemed like a stupid idea). These discussions all took place in the public Parrot IRC planning sessions, which were logged. I also had concerns about yet another rewrite undercutting P6, especially coming six months after the underwhelming Rakudo Star release, but it was clear which direction the winds were blowing, and that's when I stopped working on both P6 and Parrot. Five years later, P6 had its first official release and Parrot was well buried. I know this contradicts the official Raku hagiography, but I've gone back and read the primary sources a few times over the years as people have asked about it, and I'm confident the record backs up what I've said.
  - b2gills 5y ago
    The thing that P6 really needed was a new object system. There were two options. 1. Create a new object system for Parrot. 2. Create a new object system and a VM around it. Considering the object system needed is almost nothing like the one that was in Parrot, creating a new VM was probably considerably less work. Then there is also the problem that some of the major contributors to Parrot didn't care about P6. They have said so publically. I don't think they would have taken too kindly to a completely new object system dumped on their doorsteps. (That's how they might feel about it anyway.) --- Honestly thinking about it now, I think that if option 1 had been taken there would have been a fork of Parrot. I can almost guarantee it. And I'm not just talking about a fork of the codebase. There would have been a fork of the people behind it as well. It wouldn't have been a peaceful fork either. I see all of the anger that you have towards what happened. I can only see it as being significantly worse and bigger if they had created a new object system for Parrot instead. Creating a new object system, and a new VM to support it, was the correct move. Especially considering that a number of the fundamental design decisions of Parrot which were completely unnecessary or plainly wrong. I can only imagine the hell it would be to remove or replace any of the features. --- You seem to be the only one still angry, still here, and still talking about it. Most of the other people who would have been angry regardless of which of those two decisions were made have either gone, or are quiet. If the Parrot object system was replaced instead, a number of those people would still be angry, and still be here, and be loud. They would just be angry for different reasons. Instead what happened is they got angry, but mostly drifted away with Parrot. Come to think about it; things seemed to have gotten quieter after that event. Even though progress started going faster. --- I would have preferred if they (you) didn't get angry about it. I would have very much preferred if there wasn't a reason to get angry. The thing is that there would be some number of people would have gotten angry regardless. It's only a matter of who, and for what. In the reality where Parrot got the new object system instead, I strongly suspect that one of the people who got angry would include jnthn. Since he is responsible for a lot of the progress in recent years, I think I prefer this reality. I mean I miss the people from back then, but I think problems were piling up, and it was coming to a head at some point.

by lizmat 6y ago

microtherion 6y ago

I distinctly recall some rather bitter disputes WITHIN the Raku community, where debates often revealed that the maintainers of the Perl 6 VM were not talking much with the maintainers of the Perl 6 frontend (which, absent ironclad and stable specs, was not a recipe for success), and sometimes the VM maintainers were not even interested in Perl 6!

chromatic 6y ago
I recall things differently! The leaders of the Parrot VM and the leaders of the P6 implementation and the P6 language designers were on the phone directly every week talking through things. Up until we weren't, but that was basically the point where the P6 language designers said they wanted to write their own VM anyway.
- microtherion 6y ago
  Well, you were there and I was not; all my impressions are secondhand. But, looking back at my grandparent comment, I worded this really poorly. It was not whether the people were talking, but whether the components grew in convergent directions. My impression was that for extended periods they did not. Am I wrong?
  - lizmat 6y ago
    My take: 1. Parrot was initially intended to be the backend for Perl 6. 2. Perl 6 didn't materialize fast enough, so Parrot started focussing on hosting other scripting languages. 3. Parrot decided to become the backend for all scripting languages. 4. Parrot became less and less targeted towards Perl 6. 5. Parrot never really became a backend for any other scripting language. 6. Parrot became decicedly a poor fit for Perl 6. 7. Jonathan decided that maybe the JVM could also be a backend, and started porting 8. Building on that experience, Jonathan decided that they could write a dedicated backend for Perl 6, which became MoarVM 9. Parrot development dwindled to effectively 0. 10. During the Great List Refactor of 2015 (about 6 months before the first release) it became clear that porting the Parrot backend would be a lot of additional work, with no apparent upside 11. Parrot support was dropped before the first official release
  - chromatic 6y ago
    Parrot was always intended to support multiple languages, from Simon's original April Fools joke to Larry's dual desire to run both P6 and Perl in the same process on the same VM as well as to make CPAN available to all dynamic languages in the same process on the same VM. That's why Dan and Guido had a bet that Parrot would run Python faster than CPython, and that's why Parrot attracted contributors like Sam Ruby. It's definitely true that, as P6 dragged on and burned out a lot of contributors (including multiple project managers), many Parrot contributors thought that coupling Parrot's success to P6 was a mistake, but I can't see that as a change in focus because the multi-language focus was a goal from the start. Granted, Parrot did wander in the wilderness for a while waiting for the P6 design process to proceed, and Parrot did evolve in some unfortunate directions because of that. The rest of this comment covers 2007 onwards though. Your question about components is particularly interesting, because of what really happened. A couple of P6 developers wrote PCT, a set of tools and libraries to make developing compilers and languages on Parrot easier. This was a good thing, and Parrot users and developers started migrating their language implementations to that toolkit. The PCT developers refactored and revised this a couple of times, and to make that easier, eventually they took the code out of the Parrot tree and started syncing PCT into the Parrot tree on a semi-regular basis. I was working with them weekly to fix Parrot bugs, improve Parrot performance, and add Parrot features to reduce the amount of code necessary in PCT. Thus it's difficult for me to believe that the Parrot developers were designing and implementing Parrot away from P6. Toward the end of 2010, the P6/PCT developers said they were going to rewrite PCT to support multiple VM backends. I argued this would create a lot of churn in the language implementations actively using PCT (ironic, because the PCT developers spent a lot of time before and after this complaining bitterly that they couldn't keep up with Parrot churn) and would provide very little value for Parrot (PCT was out of tree already, and syncing in code designed explicitly to undercut Parrot seemed like a stupid idea). These discussions all took place in the public Parrot IRC planning sessions, which were logged. I also had concerns about yet another rewrite undercutting P6, especially coming six months after the underwhelming Rakudo Star release, but it was clear which direction the winds were blowing, and that's when I stopped working on both P6 and Parrot. Five years later, P6 had its first official release and Parrot was well buried. I know this contradicts the official Raku hagiography, but I've gone back and read the primary sources a few times over the years as people have asked about it, and I'm confident the record backs up what I've said.
- b2gills 5y ago
  The thing that P6 really needed was a new object system. There were two options. 1. Create a new object system for Parrot. 2. Create a new object system and a VM around it. Considering the object system needed is almost nothing like the one that was in Parrot, creating a new VM was probably considerably less work. Then there is also the problem that some of the major contributors to Parrot didn't care about P6. They have said so publically. I don't think they would have taken too kindly to a completely new object system dumped on their doorsteps. (That's how they might feel about it anyway.) --- Honestly thinking about it now, I think that if option 1 had been taken there would have been a fork of Parrot. I can almost guarantee it. And I'm not just talking about a fork of the codebase. There would have been a fork of the people behind it as well. It wouldn't have been a peaceful fork either. I see all of the anger that you have towards what happened. I can only see it as being significantly worse and bigger if they had created a new object system for Parrot instead. Creating a new object system, and a new VM to support it, was the correct move. Especially considering that a number of the fundamental design decisions of Parrot which were completely unnecessary or plainly wrong. I can only imagine the hell it would be to remove or replace any of the features. --- You seem to be the only one still angry, still here, and still talking about it. Most of the other people who would have been angry regardless of which of those two decisions were made have either gone, or are quiet. If the Parrot object system was replaced instead, a number of those people would still be angry, and still be here, and be loud. They would just be angry for different reasons. Instead what happened is they got angry, but mostly drifted away with Parrot. Come to think about it; things seemed to have gotten quieter after that event. Even though progress started going faster. --- I would have preferred if they (you) didn't get angry about it. I would have very much preferred if there wasn't a reason to get angry. The thing is that there would be some number of people would have gotten angry regardless. It's only a matter of who, and for what. In the reality where Parrot got the new object system instead, I strongly suspect that one of the people who got angry would include jnthn. Since he is responsible for a lot of the progress in recent years, I think I prefer this reality. I mean I miss the people from back then, but I think problems were piling up, and it was coming to a head at some point.