[lizmat]

Well, you are definitely more informed about the pre-2012 period. I only really got involved from 2012 onward, so I have no first hand knowledge about that period, except maybe a few weeks in 2000 (when I was dragged in by Johan Vromans) and 2005 (when I was dragged in by Audrey).

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.

> I know this contradicts the official Raku hagiography

OOC, which official hagiography are you referring to?

Also, I find the use of "hagiography" in relation to Raku a bit strange: if anything, with the rename, the last saint has basically left the building?

[raiph]

> 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

[1] http://web.archive.org/web/20091218092004/http://jnthn.net/p...

[raiph]

> 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

[chromatic]

The 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]

> 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]

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?

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.

[b2gills]

> 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.

Umm. It runs on MoarVM, JVM, and JavaScript. How is that not multiple backends?

If I remember correctly, the JVM port predates the existence of MoarVM.

Granted the JVM port has only ever been a second tier backend. Partially because it only supports Java's level of Unicode support.

---

> 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.

Yeah, because that really wasn't the main problem.

The main problem with Parrot was that the intermediate NQP/PCT code supporting it needed a complete rewrite.

The intermediate code for supporting MoarVM, JVM, and JS are all very similar. They are also significantly different to how Parrot was handled.

There is relatively little backend specific code in Rakudo itself for the three current ones. There was a lot of backend specific code in Rakudo for Parrot. Instead the vagaries of the different backends is mainly handled by NQP.

That means that if you made Parrot work better the way Rakudo-on-NQP-on-Parrot was at the time, it would have been a wasted effort.

---

Imagine the effort you were talking about doing was like tunnelling through a mountain.

The problem is that Rakudo-on-NQP-on-Parrot was going around the mountain instead.

Sure you would have reduced the total length. The problem is that you would have to create a new tunnel in a different direction once Rakudo-on-NQP-on-Parrot instead started tunnelling straight through the mountain to meet you.

Pretty sure that's why they told you to not do that.

[chromatic]

That means that if you made Parrot work better the way Rakudo-on-NQP-on-Parrot was at the time, it would have been a wasted effort.

Two thoughts.

First, that wasn't my plan. We were actively working on the Lorito plan to reduce the total amount of C in Parrot and eliminate the need to write C to extend Parrot, just as you suggested needed to happen in another reply.

Second, it would have been nice to sit down and come up with a plan, rather than Jonathan and Patrick deciding all of this on their own, not telling Parrot developers, and then spending years complaining that Parrot developers weren't responsive to their needs even after their antics had chased away pretty much all Parrot developers.

Granted the JVM port has only ever been a second tier backend.

Ah, so frittering away a bunch of developer time and developers helped them halfway reach a goal years later.

As predicted.

[lizmat]

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.

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.

[chromatic]

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.

If I recall correctly, that's about the time Jonathan started complaining that the Parrot object model didn't work very well for P6 and wrote his own for PCT, which is still weird to me because he was the primary implementer of the Parrot object model in Parrot. (I don't remember the dates, but he also wrote an object model in C# and another in Java, which you mentioned in another comment.)

I tried for a long time to migrate the PCT object model back into Parrot, but both Jonathan and Patrick told me repeatedly it wasn't a priority, so I stopped offering.

I'm not the only person who had this experience; I remember someone else having a similar experience with Unicode support.

OOC, which official hagiography are you referring to?

The one that says "Parrot dumped P6, so the P6 developers had no choice but to write their own VM".

I was there. That's not true at all.

[microtherion]

As a further clarification of my earlier remarks, when I was talking about Parrot developers not being interested in Perl 6 at all, I was not referring to your era, but to considerably earlier times: https://www.sidhe.org/oldblog/archives/000435.html

Different eras with different dysfunctions, and different people involved, but for some reason, always personality clashes.

[chromatic]

That was my era too, but it's definitely true that Dan lost interest in P6 well before he stepped down, and Leo never seemed to have a specific interest in P6.

[lizmat]

> The one that says "Parrot dumped P6, so the P6 developers had no choice but to write their own VM".

I don't think that I ever implied that. To me, in one sentence, it's more like "Parrot and Perl 6 diverged, so that Parrot was no longer a good fit for Perl 6, so the Perl 6 developers had no choice but to write their own VM"

[chromatic]

Parrot and Perl 6 diverged

To me this reads like the "mistakes were made" phrasing used when someone wants to be technically accurate but not say anything meaningful.

Regardless of whatever Raku developers and advocates say, I, as a lead developer of Parrot, went out of my way to make it work better for P6. Patrick asked me not to do certain things and so I didn't do those things.

Maybe that was my mistake.

But it's categorically untrue that Parrot wanted to get rid of P6 or considered P6 an afterthought or wasn't willing and able to be receptive to P6's needs, and I'm disappointed that that untruth continues to persist.

[lizmat]

Regardless of whatever Raku developers and advocates say, I, as a lead developer of Parrot, went out of my way to make it work better for P6.

May I point out that basically nobody of the then Perl 6 team (except Jonathan) is currently involved in the development of Raku? So please don't transfer your mistrust to these people: they have no beef in this.

But it's categorically untrue that Parrot wanted to get rid of P6 or considered P6 an afterthought or wasn't willing and able to be receptive to P6's needs, and I'm disappointed that that untruth continues to persist.

Well, maybe I don't have anything meaningful to say about this, as I have no firsthand experience in the matter. So the only thing I can do in this case, is trying to be technically correct.

I believe you had the best intentions towards Parrot and towards Perl 6 (which for some reason you keep mentioning as P6 in your replies). But, for whatever reason, it did not work out. We can keep discussing the past in that respect, but I'd rather work on the future instead.

If you really want to get the history straight, I'd suggest to write a book about it, similar to http://friendlyorangeglow.com which taught me a lot about the people developing the system I grew up with. Good and bad.