|There's more than one way to do things|
Re^7: MoarVM updateby raiph (Chaplain)
|on Sep 14, 2013 at 04:23 UTC||Need Help??|
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).