Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re^5: MoarVM update

by raiph (Hermit)
on Sep 13, 2013 at 03:22 UTC ( #1053828=note: print w/ replies, xml ) Need Help??


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

Rakudo Perl 6 on Parrot is too many years away from being sufficiently ready.

Are you suggesting some folk should work on Parrot to make it acceptable for 6.0.0? Who? How?

jnthn decided Perl 6 on JVM was the quickest way to get Perl 6 on to a mature VM so they could drive the Perl 6 specification toward 6.0.0.

Do you think he was wrong?

Perl 6 on JVM might be a decent choice for driving the Perl 6 specification toward 6.0.0, and might even be workable for some JVM fans, but it's obviously inappropriate as the only serious VM option. So now what?


Comment on Re^5: MoarVM update
Re^6: MoarVM update
by curiousmonk (Sexton) on Sep 13, 2013 at 07:30 UTC
    Rakudo Perl 6 on Parrot is too many years away from being sufficiently ready.

    This is the most disappointing thing I've read all day today

    jnthn decided Perl 6 on JVM was the quickest way to get Perl 6

    How quick?

    Seriously speaking I don't care if Perl 6 runs on a dozen VM's in its first 6.0.0 release. In fact I prefer it rather doesn't. There are plenty of other important things like the standard library, CPAN compatibility and documentation to be sorted out and standardized before we branch out to other platforms. Perl 5 doesn't run on any VMs apart from its own and we are perfectly fine with it and its perfectly usable. There is no reason for any one to expect anything other wise for the first cut production release. And not just Perl, most new languages that come today run only on one VM, and users are perfectly fine with that.

    Perl 6 on JVM might be a decent choice for driving the Perl 6 specification to 6.0.0, and might even be workable for some JVM fans, but it's obviously inappropriate as the only serious VM option. So now what?

    Far more important than a few percentage of users who can't use JVM or Parrot or whatever are the vast majority of users who would prefer a working product on anything. And by this definition and strategy whom would you please? There are always going to be users, who can't deploy a compiler on a particular VM. So will we keep starting new projects and never finish them.

    You can release 6.0.0 product on any VM, then you have all the time in the world to release it on other VM's when you want. Other wise no matter how great the progress is in the sub projects, there is hardly any reason for anybody to care.

      jnthn decided Perl 6 on JVM was the quickest way to get Perl 6
      How quick?

      First, how quick it would be isn't really important. If there's already one acceptable VM, and the project is late, then no matter how quick a port would be, it's almost certainly the wrong thing to do. Conversely, if there is NOT already one acceptable VM, and the project is late, then the right thing to do is almost certainly to get an acceptable VM done as fast as possible, no matter how long that takes.

      Second, it's only of historical interest how quick the JVM port was. It's done. That's why, in the last few weeks, as just one example of the impact of freeing Rakudo Perl 6 from Parrot, the critically important concurrency and async parts of 6.0.0 that have been delayed by years have started landing. (To acclaim by at least some of the P5ers that have seen it.)

      There are plenty of other important things like the standard library, CPAN compatibility and documentation to be sorted out and standardized before we branch out to other platforms.

      It's pointless having doc, standard libs, and CPAN compatibility if it doesn't run acceptably on ANY platform. To be clear, this is by no means just about concurrency, async, and parallelism, or even speed. Simple buffered IO in Rakudo Perl 6 has fallen victim to a series of basic bugs in the last 12 months, bugs that have taken months to resolve, partly because Parrot contribution has been drying up since 2010.

      Perl 6 has to run acceptably on ONE platform. Perl 5 has an acceptable platform. Perl 6 did not. (You might think that Parrot is/was acceptable, but have you actually checked that assumption out?)

      I too think that the JVM might well be fine as the one platform for rolling out 6.0.0. It was partly chosen because it was about the shortest route to a VM that would let the team drive Perl 6 and the Rakudo compiler toward 6.0.0, but it was also chosen because it's a production worthy VM. It might work out as the sole VM for an initial official 6.0.0 roll out.

      That said, the NQP/JVM backend currently has a few fundamental weaknesses as a Perl 6 platform (eg it takes several seconds to start). While the JVM solves immediate problems Rakudo had, allowing Perl 6 and Rakudo to move toward 6.0.0, there's still a chance it will turn out not to be acceptable to many as a mainstream production VM.

      Some devs who did not do significant work on Rakudo, and who would not write doc or Perl 6 library code, wanted to work on a VM. Are you suggesting they should have been told to go away, maybe to work on, say, a Python VM instead? Regardless, they were not told to go away, and they're now building out a VM that generally uses one quarter of the RAM that the JVM does (so half the RAM Parrot does), starts thousands of times faster, implements 6model and NFG natively to great effect, and so on.

        Telling people to go-away is a long tradition in Perl-6. Telling people to go-away and then whinging that they aren't fixing bugs is a peculiar nonsense. You are not that clever are you?
Re^6: MoarVM update
by chromatic (Archbishop) on Sep 13, 2013 at 15:42 UTC
    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.

      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.

        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://1053828]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (7)
As of 2014-11-27 21:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (188 votes), past polls