5 ms·
> I only really got involved from 2012 onward, so I have no first hand knowledge about that period, except maybe a few weeks I'm in roughly the same boat. I to
by raiph 5y ago
> I only really got involved from 2012 onward, so I have no first hand knowledge about that period, except maybe a few weeks
I'm in roughly the same boat. I too dipped in and out starting in 2000, and had been reading contemporary discussions on and off from around 2009.
I want to draw your attention to some things I know due to publicly available records, things I think shed light on what really happened.
The first thing is that Rakudo began technically shifting to a multiple backend architecture in mid 2009:
* Following Jesse Vincent's summer 2009 discussion with Patrick Michaud about Perl 6 running on JVM and .NET, NQP was rewritten in the fall of 2009 to support multiple backends.[0]
* jnthn edited his website to say his first interest in working on Perl 6 going forward was "Transforming Rakudo from a single backend compiler to one capable of targeting multiple backends".[1]
> I just know second-hand that something broke the trust between the Perl 6 and Parrot developers around the first Rakudo Star release. And that strengthened the notion that another backend for Perl 6 was needed.
As explained above, Patrick had already focused his and jnthn's efforts on a multiple backend Rakudo in mid 2009, a year before Rakudo Star.
And, as chromatic has said, and the record shows, commits to Parrot "fell off a cliff" in early 2011, about 6 months after Rakudo Star, and a year before the dates of the first commit timestamps in MoarVM's git history, in Q1 2012.
----
[0] https://www.youtube.com/watch?v=XgPh5Li3k4g#t=2m https://www.youtube.com/watch?v=XgPh5Li3k4g#t=2m
[1] http://web.archive.org/web/20091218092004/http://jnthn.net/perl6/ http://web.archive.org/web/20091218092004/http://jnthn.net/p...
- chromatic 5y agoThe first thing is that Rakudo began technically shifting to a multiple backend architecture in mid 2009 Weird how almost nothing Patrick talked about in that talk panned out -- no JVM backend, no CLR backend (the one that Jonathan talked about in that blog post too), no JavaScript backend, no Tcl, no Perl, no Ruby, no Python frontends. In fact, it's amazing how that fourth rewrite of NQP ended up not working at all for any of the backends Patrick showed on his slide. Or at least not working yet. the record shows, commits to Parrot "fell off a cliff" in early 2011, about 6 months after Rakudo Star How strange that that happened just after the developer summit where I said that the NQP strategy was going to leave Parrot developers in a dead end. Imagine that -- people don't want to stick around on a project that's continually undercut by bad technical decisions. Thanks for finally confirming what I've been saying for years.
- lizmat 5y ago> that the NQP strategy was going to leave Parrot developers in a dead end If Parrot had provided all that Perl 6 needed at that time, I don't think the multiple backend strategy would have been selected. Why would one? > where I said that the NQP strategy was going to leave Parrot developers in a dead end To me that feels like a self-fulfilling prophecy. Also, had Parrot been able to attract other languages to a significant extent, the abandoning of Parrot by Perl 6 would not have been an issue. Personally, I think Parrot was not able to attract other languages because: 1. it didn't provide enough benefits to account for the extra effort needed by language developers. It definitely did not for Perl 6 at the time. 2. it didn't have a core team welcoming enough to keep anybody vaguely interested in Parrot In the end, it is always about being able to create a community in open source. Without it, a project is indeed on a dead end.
- chromatic 5y agoIf Parrot had provided all that Perl 6 needed at that time, I don't think the multiple backend strategy would have been selected. Why would one? Given that the multiple backend strategy only succeeded in replacing an existing backend with another backend several years later without achieving any of the interoperability goals of the JVM or CLR, I'm not even sure how to speculate on the reasoning behind that decision. Also, had Parrot been able to attract other languages to a significant extent, the abandoning of Parrot by Perl 6 would not have been an issue. You haven't addressed my point that NQP yanking the rug out from most other languages running on Parrot harmed Parrot. That seems like a material concern. it didn't have a core team welcoming enough to keep anybody vaguely interested in Parrot You haven't addressed my point that I personally spent multiple months offering to make Parrot better fit NQP/PCT for P6 and was repeatedly rebuffed.
- lizmat 5y agoGiven that the multiple backend strategy only succeeded in replacing an existing backend with another backend several years later without achieving any of the interoperability goals of the JVM or CLR, I'm not even sure how to speculate on the reasoning behind that decision. I'd say, it turned out to be more difficult than expected? You haven't addressed my point that NQP yanking the rug out from most other languages running on Parrot harmed Parrot. That seems like a material concern. I guess I don't understand how NQP would be yanking the rug out from other languages, technically speaking? That it could be seen as a vote of no-confidence: well such is life in the open source world. You haven't addressed my point that I personally spent multiple months offering to make Parrot better fit NQP/PCT for P6 and was repeatedly rebuffed. Not having been around at that time, I don't think it is up to me to address that point. If you were rebuffed, I can only surmise that interpersonal and technical relationships had already soured enough not to trust the validity of your offer. Note: I'm not saying that the intent of your offer was questioned.
- raiph 5y ago> Weird how almost nothing Patrick talked about in that talk panned out -- no JVM backend ... no JavaScript backend At the time of writing this comment: js Use new nqp::time instead of nqp::time_(i|n) 20 days ago jvm [JVM] Add op 'nativecallinvoke' 15 days ago moar Disallow explicity specifying op write registers 8 days ago From https://github.com/Raku/nqp/tree/master/src/vm https://github.com/Raku/nqp/tree/master/src/vm