Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^6: MoarVM update

by chromatic (Archbishop)
on Sep 13, 2013 at 15:42 UTC ( #1053960=note: print w/ replies, xml ) Need Help??


in reply to Re^5: MoarVM update
in thread MoarVM update

Do you think he was wrong?

At the time, yes—but as it turns out, all of the FUD flung at Parrot chased away most of its developers, so his prediction came true. After being told not to improve Parrot (being told not to change Parrot), there was no reason to continue working on it. That's why you can see commits and participation drop off a cliff a couple of months after Rakudo announced yet another NQP rewrite, one designed to remove Parrot from Rakudo's long term plans.

Granted, it's taken a couple of years and Rakudo on the JVM still doesn't pass as many P6 spec tests as Rakudo on Parrot, but I'm confident that they're aiming for feature parity eventually.

So now what?

So now MoarVM doesn't even pass all of the NQP test suite, so let's all stand up and cheer that the Rakudo developers are dividing their attention between three VMs that we know of: one all but dead but still the most feature complete, one proprietary and memory hungry and a black box of sharecropping, and one nascent that needs at least one rewrite and doesn't run any P6 code worth mentioning.

My guess is what next is yet another rewrite of major components, yet another VM announced, and still nothing I can give to customers who expect little things like stability, library support, and documentation.


Comment on Re^6: MoarVM update
Re^7: MoarVM update
by raiph (Friar) on Sep 14, 2013 at 04:23 UTC
    jnthn decided Perl 6 on JVM was the quickest way to get Perl 6 on to a mature VM ... Do you think he was wrong?
    At the time, yes—but as it turns out, all of the FUD flung at Parrot chased away most of its developers, so his prediction came true.

    jnthn started the port to JVM 10 months ago, by which time it looked highly doubtful that the Parrot project would deliver a mature VM, suitable for NQP and Rakudo, in a reasonable timeframe. (Subsequent events suggest that's an understatement.) So you're not talking about what I was talking about, which was dealing with reality.

    It sounds like you are still fuming over Patrick's 2009 decision to make NQP be a multi backend compiler toolkit for VMs (portable between Parrot, JVM, .NET, etc.). (This is nicely explained in the first 12 minutes of this recent talk Perl 6 on the JVM.)

    If a bunch of Parroteers characterized Patrick's utterly compelling logic the way you have ("designed to remove Parrot from Rakudo's long term plans") rather than the more rational "designed to be portable, with Parrot needing to evolve in to a dedicated NQP backend" (the role MoarVM is now set to fulfil), then no wonder things went south.

    After being told not to improve Parrot (being told not to change Parrot)

    No way am I going to believe that that is a balanced characterization of what went down. At the very least the Rakudo team would have wanted fixes to any bugs that affected Rakudo.

    Aiui Patrick told the Parrot project that he wanted it to focus on what NQP and Rakudo needed and avoid making changes that risked breaking them. He was basically asking the Parrot project to adopt the NQP strategy, which was, imo, absolutely appropriate.

    Granted, it's taken a couple of years and Rakudo on the JVM still doesn't pass as many P6 spec tests as Rakudo on Parrot, but I'm confident that they're aiming for feature parity eventually.

    The process of evolving NQP so it would one day work for multiple back ends began with the 2009 decision Patrick discusses in the video linked above. Maybe that's what you're talking about?

    The port of NQP to the JVM began 10 months ago. The port of Rakudo to the JVM began 5 months ago.

    At the time of writing this comment the latest roast results show Rakudo/Parrot passing 27,401 tests and Rakudo/JVM passing 27,165.

    I would be surprised if the Rakudo team is "aiming for feature parity eventually". The Rakudo/JVM port is ahead in a couple areas (concurrency and async features; calling JVM modules), Rakudo/Parrot in a couple others. I'm pretty sure each backend will evolve based on need and contribution (which doesn't bode well for Rakudo on Parrot given dukeleto's decision not to treat Rakudo as a special customer).

      So you're not talking about what I was talking about, which was dealing with reality.

      Were you there?

      No way am I going to believe that that is a balanced characterization of what went down.

      With all due respect, that's because you have no intent of reading the IRC logs or the mailing list archives of that time period. If you cared to do any research at all, you would have no trouble confirming my characterization of the event. You could start by looking at the commit rate to Parrot and correlating that with the "Rakudo doesn't want Parrot" discussions in December 2010 and January 2011 and then the Parrot commit rate going way down in February and March of 2011.

      There is a correlation between those events.

      "designed to be portable, with Parrot needing to evolve in to a dedicated NQP backend"

      If you had bothered to do your research, you would know why that was never and would never be acceptable to Parrot.

      It's sad that you can't be bothered, that you're so invested in propping up a project categorized by overpromising, underdelivering, and failure after failure that you're willing to take the sunshiney optimism of the people who were paid to work on the project over the opinion of dozens of volunteers who've been burned out or forced out of the project because they could no longer buy into the repeated promise that usable and useful software is just another six months away.

      If you were truly interested in the truth, you'd ask the other people involved about their characterization of events.

      You might start with a pointed question:

      When Patrick and Jonathan said that they were going to rewrite NQP again to focus on VM independence because that independence was "important to the long term plans of Rakudo", what was your reaction?

      Given that:

      • Rakudo Star was less than a year old at that point
      • Everyone acknowledged that that rewrite of NQP would mean a huge regression in the featureset of Rakudo on the rewrite branch
      • Almost everyone acknowledged that development effort would necessarily be split between supporting the existing, working codebase and the rewrite
      • If the rewrite went well, that would mean abandoning the existing development branch (the one on which Rakudo Star was based), which meant abandoning any users who'd tried to build anything with Star releases

      ... is it so difficult for you to conceive of a world in which volunteers would think that that circus of bungling was anything they'd like to participate in?

      You know what's also sad? The fine whine of unrealistic expectations from Rakudo that Parrot could simultaneously provide a stable API (despite Rakudo reaching into the guts of Parrot) and meet every performance and feature goal of Rakudo, instantly updating Rakudo about any breakages, writing patches for Rakudo that they could apply when they saw fit, never actually testing Rakudo code against Parrot (that was Parrot's job, to test all external clients), and support existing abandonware that Rakudo had convinced people to import into the Parrot repository. With volunteer labor. To support a Rakudo project that had no qualms about breaking stuff their users had written or depended on—no qualms about not even testing that Rakudo broke stuff in its library or ecosystem.

      So, yeah, when Rakudo said "The long term support plan of running on multiple VM backends is so important that we're going to break everything right now, less than a year after Rakudo Star came out, and spend a year getting us back to the place we are right now instead of passing more spec tests or writing documentation or making stable and useful packages or testing the ecosystem or anything else that actually gets a useful and usable P6 into the hands of real users," I think you'd have to be quite a fool to imagine that that was motivated by anything other than "We don't want to use Parrot anymore." I certainly wouldn't spend two and a half years not delivering working software unless I had a goal I considered more important.

      After all, it's not as if most of the Rakudo developers making this choice lacked commit access to Parrot. (If you're in the mood for grim amusement, look at the commit history to see who wrote the long-lamented Parrot object system.)

      Patrick's utterly compelling logic

      Post hoc ergo propter hoc. Parrot had its problems. Everyone agrees on that—but when the paid developers of Rakudo told the volunteers of Parrot (volunteers who'd worked on Parrot for years because they wanted to help realize a usable and usefl P6) that Parrot had no place in Rakudo, what did you expect to happen?

      Don't take my word for it. Ask Dan. Ask Allison. Ask Jesse. Ask Nat. Ask Andrew. Ask Julian. Ask Vasily.

        reading the IRC logs or the mailing list archives of that time period.

        I've long thought that the "first Parrot Developers Summit for 2011" gets to the heart of the issues. Am I wrong?

        {Parrot needing to evolve in to an optimal NQP backend} was never and would never be acceptable to Parrot.

        Does me changing the word from "dedicated" to "optimal" (which more accurately reflects what I think Patrick proposed) make any difference?

        When Patrick and Jonathan said that they were going to rewrite NQP again to focus on VM independence ... Rakudo Star was less than a year old

        Do you mean to focus more on VM independence?

        Patrick decided to go for a multibackend VM strategy in the summer of 2009, as described in the talk video I linked earlier in this thread. Coding on the multi backend NQP began in October 2009.

        Or was there just mass confusion between the projects (perhaps because Patrick didn't have sufficient time to keep channels properly open due to his RL circumstances)?

        I'll let most of the rest of what you wrote pass without further comment, with a couple exceptions:

        I think you'd have to be quite a fool to imagine that {the new object model rewrite} was motivated by anything other than "We don't want to use Parrot anymore." ... when the paid developers of Rakudo told the volunteers of Parrot ... that Parrot had no place in Rakudo, what did you expect to happen?

        For better or worse, I have indeed drunk the P6 koolaid, including thinking that Patrick is a nice honest guy with integrity. I don't find credible the claim that Patrick said in 2011 that Parrot had no place in Rakudo.

        I hear you about asking the Parrot folk you listed. I'm dubious about that being a good thing because it seems to me likely to be unnecessarily painful and divisive no matter what gets said. Which perhaps also applies to this exchange. So I'll leave you to have the last word if you wish to say something else.

        Thank you for all the good things you do for Perl and for this exchange. I think I finally understand why you dislike Perl 6, or, rather, Rakudo.

        ~~ the P6 Spokesweaselfool

      No way am I going to believe that that is a balanced characterization of what went down.

      Found it.

      In the #parrotsketch discussion of September 06, 2011, I brought up the idea of making a list of potential Parrot improvements and another list of Rakudo's top priorities (from Parrot). Patrick said that there'd been lists like that made in the past and then said that I had "offered to work on them and we had deferred him from it."

      "We" in that context means "Rakudo developers". "Them" means "Parrot improvements corresponding to Rakudo's top priorities".

      That's why I keep saying "I offered to make Parrot improvements for Rakudo, but Rakudo told me not to" and "You can find documentation for this if you bother to look for it." Because that's what happened, no matter how much #perl6 wants to pretend otherwise.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1053960]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (13)
As of 2014-08-20 15:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (116 votes), past polls