3 ms·

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 fr

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
Why would they? I wasn't trying to imply any sort of wrong decision on the part of Parrot developers for not working on MoarVM. I tried to make sure that was obvious. Perhaps I failed. More than that, Moar's development began in secret around that time I'm aware, which is one of the things I was alluding to when I mentioned "among other reasons" for not working on MoarVM. Beyond not knowing it existed, when they did there was probably a feeling of betrayal. I'm not trying to ignore that. The shame is that some of these people would most likely have enjoyed working on MoarVM if things had played out differently. 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. That actually sounds like praise to me (barring some of the architectural missteps you allude to earlier in your statement). That MoarVM was able to mostly get to where you think Parrot could have been if it had been able to ignore a lot of extremely hoary and cumbersome problems seems like a good thing. Did you find it disappointing because of MoarVM specifically, or because of the realized loss of potential from Parrot? In the end, if the Parrot split solved some P6 roadblocks, and spurred more rapid P6 development, which I believe it did, I have to count the action as a wide choice. I found Parrot interesting in it's goals, but it's target of being a VM for scripting languages was starting to get competition from the JVM, which I'm not sure it could compete with. P6, on the other hand, still hasn't seem a competitor feature-wise IMHO to make me think it's future is in doubt from an outside source (whether it will ever be successful, however you define it, is a different question). Of course your level of investment and interest in each of the two projects may cause you to weigh the situation entirely differently.
- chromatic 12y ago
  Did you find it disappointing because of MoarVM specifically, or because of the realized loss of potential from Parrot? Several reasons, in no particular order. One, because of the deliberate driving off of Parrot developers and their knowledge about what works and what doesn't work for building a VM for a Perl. (Sure, you can believe that I feel a little personal betrayal there, but there's also a concern that the Rakudo developers were taking on yet another project for which the bus number is, as usual, abysmally low.) Two, because the resulting design (when I looked at it) was adequate, at best. I believe it won't compete with fast VMs without a serious change in its architecture, and no amount of magical thinking about how a GSoC student will build a JIT in 10 weeks will fix that. Three, because it represents yet another example of NIH thinking and throwing out working code in favor of spending even more time building something new from scratch. Four, because it set back the P6 release date by at least 18 months, if not years. Five, because all it represented when I looked at it was the kind of code shuffling that Parrot could easily have done in the past three years, without doing anything much else (such as make the architecture improvements we'd begun to design and prototype). One fact often forgotten in all of the nonsense about how "Parrot lost its focus and thus its purpose" is that Parrot was, from the start, intended to run at least both Perl and P6 simultaneously in the same process without embedding libperl.so.
raiph 12y ago
> Moar's development began in secret around that time MoarVM's first commit was in April 2012, a year after Parrot commits fell of a cliff. https://github.com/MoarVM/MoarVM/commit/51481efadbf5bbebfc20767c07056bd2dfc2fabc https://github.com/MoarVM/MoarVM/commit/51481efadbf5bbebfc20... > 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. Maybe look at the chronology again? > {MoarVM} seems to repeat most of the long-standing architectural flaws of Parrot Such as? > (Moar looked a lot like Parrot would have after the same time period. It was pretty disappointing.) As you now hopefully realize, the time period was 14 months, not 29.
- chromatic 12y ago
  MoarVM's first commit You mean the first commit committed to a repository which survived long enough to be made public, eventually. Even so, if you look at the timestamps on those first commits, you realize that either the design of the VM leaped from someone's head fully-formed like a virtual Athena, or (as was widely known at the time) that someone had been designing and playing with ideas for much longer. Maybe look at the chronology again? The one where Rakudo developers told Parrot hackers not to implement sixmodel to replace Parrot's default object system (the one which one of those Rakudo developers had, in fact, actually implemented) during the period where it was obvious that those Rakudo developers were in fact designing their own VM? Who am I to believe, you or my own lying eyes?
  - kbenson 12y ago
    The one where Rakudo developers told Parrot hackers not to implement sixmodel to replace Parrot's default object system (the one which one of those Rakudo developers had, in fact, actually implemented) during the period where it was obvious that those Rakudo developers were in fact designing their own VM? Hmm, I read that as Rakudo devs trying to keep Parrot devs from starting a project that they may not want to continue in the future (given your statement it was obvious they were looking into developing their own VM). If the decision has been made, trying to reduce fallout seems wise to me, given also that they weren't public on the new direction, which I don't know the details of why.

kbenson 12y ago

Why would they? I wasn't trying to imply any sort of wrong decision on the part of Parrot developers for not working on MoarVM. I tried to make sure that was obvious. Perhaps I failed. More than that, Moar's development began in secret around that time I'm aware, which is one of the things I was alluding to when I mentioned "among other reasons" for not working on MoarVM. Beyond not knowing it existed, when they did there was probably a feeling of betrayal. I'm not trying to ignore that. The shame is that some of these people would most likely have enjoyed working on MoarVM if things had played out differently. 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. That actually sounds like praise to me (barring some of the architectural missteps you allude to earlier in your statement). That MoarVM was able to mostly get to where you think Parrot could have been if it had been able to ignore a lot of extremely hoary and cumbersome problems seems like a good thing. Did you find it disappointing because of MoarVM specifically, or because of the realized loss of potential from Parrot? In the end, if the Parrot split solved some P6 roadblocks, and spurred more rapid P6 development, which I believe it did, I have to count the action as a wide choice. I found Parrot interesting in it's goals, but it's target of being a VM for scripting languages was starting to get competition from the JVM, which I'm not sure it could compete with. P6, on the other hand, still hasn't seem a competitor feature-wise IMHO to make me think it's future is in doubt from an outside source (whether it will ever be successful, however you define it, is a different question). Of course your level of investment and interest in each of the two projects may cause you to weigh the situation entirely differently.

chromatic 12y ago
Did you find it disappointing because of MoarVM specifically, or because of the realized loss of potential from Parrot? Several reasons, in no particular order. One, because of the deliberate driving off of Parrot developers and their knowledge about what works and what doesn't work for building a VM for a Perl. (Sure, you can believe that I feel a little personal betrayal there, but there's also a concern that the Rakudo developers were taking on yet another project for which the bus number is, as usual, abysmally low.) Two, because the resulting design (when I looked at it) was adequate, at best. I believe it won't compete with fast VMs without a serious change in its architecture, and no amount of magical thinking about how a GSoC student will build a JIT in 10 weeks will fix that. Three, because it represents yet another example of NIH thinking and throwing out working code in favor of spending even more time building something new from scratch. Four, because it set back the P6 release date by at least 18 months, if not years. Five, because all it represented when I looked at it was the kind of code shuffling that Parrot could easily have done in the past three years, without doing anything much else (such as make the architecture improvements we'd begun to design and prototype). One fact often forgotten in all of the nonsense about how "Parrot lost its focus and thus its purpose" is that Parrot was, from the start, intended to run at least both Perl and P6 simultaneously in the same process without embedding libperl.so.

raiph 12y ago

> Moar's development began in secret around that time MoarVM's first commit was in April 2012, a year after Parrot commits fell of a cliff. https://github.com/MoarVM/MoarVM/commit/51481efadbf5bbebfc20767c07056bd2dfc2fabc https://github.com/MoarVM/MoarVM/commit/51481efadbf5bbebfc20... > 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. Maybe look at the chronology again? > {MoarVM} seems to repeat most of the long-standing architectural flaws of Parrot Such as? > (Moar looked a lot like Parrot would have after the same time period. It was pretty disappointing.) As you now hopefully realize, the time period was 14 months, not 29.

chromatic 12y ago
MoarVM's first commit You mean the first commit committed to a repository which survived long enough to be made public, eventually. Even so, if you look at the timestamps on those first commits, you realize that either the design of the VM leaped from someone's head fully-formed like a virtual Athena, or (as was widely known at the time) that someone had been designing and playing with ideas for much longer. Maybe look at the chronology again? The one where Rakudo developers told Parrot hackers not to implement sixmodel to replace Parrot's default object system (the one which one of those Rakudo developers had, in fact, actually implemented) during the period where it was obvious that those Rakudo developers were in fact designing their own VM? Who am I to believe, you or my own lying eyes?
- kbenson 12y ago
  The one where Rakudo developers told Parrot hackers not to implement sixmodel to replace Parrot's default object system (the one which one of those Rakudo developers had, in fact, actually implemented) during the period where it was obvious that those Rakudo developers were in fact designing their own VM? Hmm, I read that as Rakudo devs trying to keep Parrot devs from starting a project that they may not want to continue in the future (given your statement it was obvious they were looking into developing their own VM). If the decision has been made, trying to reduce fallout seems wise to me, given also that they weren't public on the new direction, which I don't know the details of why.