Comment by microtherion | Hacker News Reader

Comment by microtherion | Hacker News Reader

Parent Full thread

> Presumably your view of P6-as-a-project is like your view of the language

I'd say I've kept somewhat closer tabs on the project than on the language (partially to figure out whether it was actually time to start paying attention to the latter again).

>> it's too soon to tell whether the "leave" phase will follow or not. > I was tempted to dismiss this as a "when did you stop beating your wife?" point

It's more a case of the 5 times divorcee insisting that the latest marriage is finally built to last; it's not that I doubt the good intentions…

> The current MoarVM devs could all leave today and we'd be in a vastly better place than we would if they hadn't built it. Surely this […] couldn't be classified as a P6ian "leave phase" curse whether we were 2 years or 10 years in to the project?

It would depend on what would happen afterward. The pattern so far has been "Component X is beyond repair. Let's toss it and start over". The curse is not people leaving, it's about preferring rewrites to evolution.

> Whether a hacker leaves a mess behind is about the character of the hacker and the nature of the project's management.

I'm more concerned about the latter, and more concerned about the overall management than the subprojects.

> Pugs development was arguably too anarchic, and Parrot's was arguably too bureaucratic

But what they, to me, had in common was that neither seemed to be focused on making a practical Perl 6 release happen.

Pugs: Setting aside the question of whether the choice of Haskell restricts the pool of available developers, was there ever a realistic prospect that a production level Perl 6 would ship as a tarball with an INSTALL file that said "1. Install a Haskell compiler" ?

Parrot: Deciding 12 years into a project that the underlying VM wasn't a particularly good match for the language (7 years after the original designer more or less said so: http://www.sidhe.org/~dan/blog/archives/000435.html ) strikes me as a massive lack of a coherent vision for the project.

> That said, some devs will inevitably leave. […] Such is life in the FOSS dev world.

Not just in FOSS. But the way to deal with that, IMHO, is to plan in manageable milestones. I just don't see evidence of a true release convergence mentality emerging among Perl 6 developers.

> the 5 times divorcee insisting that the latest marriage is finally built to last

Heh. And here was me thinking Camelia's 20 year old brother was still way too embarrassed to be seen out and about with his 14 year old sister because she was so immature!

But yeah, once bitten twice shy is an understated version of many folks' quite reasonably skeptical attitude toward P6.

> The pattern so far has been "Component X is beyond repair. Let's toss it and start over". The curse is not people leaving, it's about preferring rewrites to evolution.

If a component is indeed beyond repair, it should be tossed and rewritten.

But you are suggesting that components get rewritten that are not beyond repair. I don't agree that that applies to the core P6 projects (Rakudo, NQP, MoarVM, etc.)

> Deciding 12 years into a project that the underlying VM wasn't a particularly good match for the language (7 years after the original designer more or less said so: http://www.sidhe.org/~dan/blog/archives/000435.html ) strikes me as a massive lack of a coherent vision for the project.

You're not giving credit where credit is due -- credit for doing exactly what you recommend too.

First, surely you realize that Rakudo devs read what Dan wrote? And that they directly experienced the poor fit he spoke about? Yet they didn't give up on Rakudo or Parrot. They evolved Rakudo and its fit with Parrot hoping they could avoid having to write another VM. Isn't this all exactly as you (say you) would recommend?

Second, when the Parrot project stalled for a year the Rakudo team started MoarVM. This was also a good thing, not an unnecessary rewrite.

> plan in manageable milestones.

What do you think shipping Rakudo Star with support for MoarVM at the start of May was if not a milestone?

> I just don't see evidence of a true release convergence mentality emerging among Perl 6 developers.

If you mean something akin to "let's ship a production release!" then no, that's not where things are at.

> They evolved Rakudo and its fit with Parrot hoping they could avoid having to write another VM. Isn't this all exactly as you (say you) would recommend?

Yes it is, but from the accounts I've read, during that time, Rakudo and Parrot were always run by different teams that had a limited understanding of each others' perspective. Technically, moving the projects into separate repositories and onto different change schedules seemed to have worked out badly.

>> plan in manageable milestones. > What do you think shipping Rakudo Star with support for MoarVM at the start of May was if not a milestone?

I was thinking in terms of production release milestones. The nearly 4 years or Rakudo Star releases demonstrate, to me, that regular development releases, in themselves, do not help production release convergence all that much.

From the accounts I've read, during that time, Rakudo and Parrot were always run by different teams that had a limited understanding of each others' perspective.

The P6 design team had been having weekly phone calls for years. Patrick (Rakudo pumpking) and Allison (Parrot architect) were both regularly on the calls. As you might expect from any kind of regular meeting, there were occasional disagreements, but the purpose of those conferences was to guide the convergent development of both projects.

I used those calls to figure out what I should work on within Parrot to help Rakudo.

Technically, moving the projects into separate repositories and onto different change schedules seemed to have worked out badly.

From the outside, that probably looks like the point at which the projects really started to diverge, but I think it was a symptom. Near the start of Parrot, a lot of people thought P6 was an ambitious project that'd never amount to anything and they wanted Parrot to succeed with or without P6. At some point, enough people within Rakudo decided that they didn't want to be tied to Parrot forever that they wanted an alternate backend.

> At some point, enough people within Rakudo decided that they didn't want to be tied to Parrot forever that they wanted an alternate backend.

Aiui Patrick read Larry Wall's 2001 Apocalypse #1 (http://www.perl6.org/archive/doc/design/apo/A01.html) and took it into account before he started Rakudo. It includes the following statement:

> "Multiple backends are a necessity of the world we live in today. Perl 6 must not be limited to running only on platforms that can be programmed in C. It must be able to run in other kinds of virtual machines, such as those supported by Java and C#."

That statement didn't require that any given P6 compiler be multi backend, but I would guess Patrick was thinking something like the following about P6 and Rakudo (first, my guess about his thoughts when he started it; then, about his thoughts a year or so later):

* Parrot would hopefully be a good host for a P6 compiler at the start and remain that way; OR, if not, it would evolve to become a good host (ie the convergence which you mention).

* After Rakudo on Parrot was "done", some P6 compiler, possibly Rakudo, would eventually be ported to JVM, CLR, and other existing VMs, as tuits and priorities allowed.

Later (2005?), as it became clear that Parrot was not a good fit architecturally for P6's / Rakudo's needs, he presumably responded. I'm guessing his thinking was something like this:

* Parrot and P6/Rakudo might sufficiently converge. This would avoid Rakudo having to focus, before an initial implementation was sufficiently "done", on porting. So Patrick should encourage convergence as best he could.

* Parrot and P6/Rakudo might not sufficiently converge. This would be an existential threat to Rakudo. So he should have developed a plan B. It should have been obvious to him that this would take several years and would best be avoided if at all possible, but he should have had a plan B.

Fast forward to 2009:

> "Putting Perl on JVM was always a kind of thought ... but was never really serious until summer of 2009 ..."

This is from the first minute of the video of Patrick's YAPC::NA 2013 talk "Perl on JVM". I found the whole talk interesting but the first 10 minutes are particularly instructive in relation to the things we're discussing:

https://www.youtube.com/watch?v=XgPh5Li3k4g&list=PLRuESFRW2F...

Please stop guessing at things and do the hard research and look through mailing list archives and sixperl call summaries. Alternately, ask people who were there. (I was one of those people.)

You're spreading misinformation, and you've been told this enough times that it seems deliberate.

> Please stop guessing at things

Imo, all is fair if you predeclare ("mere armchair analysis").

> do the hard research

I've spent a colossal amount of time reading P6 and Parrot mailing lists, IRC logs, etc. I'd estimate more than a thousand hours since 2000.

> sixperl call summaries

I've looked for an online transcript or summary of sixperl calls before. I'm failing to find them with search engines now. Would you be willing to share a link or private copy?

> ask the people who were there

I've attempted private exchanges about this stuff with some folk who were there. The general response is a reluctance to talk about it. What little I get beyond that doesn't seem consistent with the picture you paint.

> You're spreading misinformation

If anything I said is wrong, please point out the specific issues. Thanks.

> during that time, Rakudo and Parrot were always run by different teams

Many folk have contributed to both projects. But yes, they were (and remain) separate projects, with Patrick at that time being the point person for Rakudo, not Parrot, and others being point people for Parrot, not Rakudo.

> {the teams running Rakudo and Parrot} had a limited understanding of each others' perspective

Perhaps.

My own understanding (which is admittedly also merely armchair analysis after the fact for most of the period 2006 thru mid 2011) goes something like this.

First, the gap between Rakudo's purpose and Parrot's purpose became (or maybe was from the get go) an irreconcilable conflict.

(Rakudo's purpose is to ship a practical P6 compiler, including a multi backend strategy to address Larry's "must target VMs" requirement. Parrot's purpose is to ship a practical VM for dynamic languages, with P6/Rakudo given no special status.)

Probably the last chance to have gotten things back on track, which I define as Parrot trying to serve P6's and hence Rakudo's needs, even if it did other things, was 2010. Patrick was made a member of the Parrot Foundation's small board in 2009. Rakudo Star was coming. jnthn had designed and implemented 6model and NQP and there was a chance Patrick could have convinced Parroteers to replace the broken stuff in Parrot with these pieces.

But then, just as Patrick needed to be most available to steer Rakudo (and perhaps to steer Parrot too) through the very difficult year 2010 (to produce, ship and support an initial Rakudo Star; to evolve Rakudo in the face of the problems of fit with Parrot; to try keep Parrot viable), he suddenly had to drastically lessen his involvement -- falling to near zero in late 2011 and since.

(NB. Please don't say this was Patrick exhibiting the "leave phase" syndrome you talked about.)

At this point, instead of the previous situation in which the conflicting directions were more implicit than explicit, it now became clear Rakudo and Parrot were going to do their own things. They might both survive and work with each other. They might not.

In early 2011, commits to the master branch of the Parrot repo fell of a cliff.

By 2012 it really looked bad for Parrot, judging by the paucity of commits and #parrot (in)activity.

In spring 2012 jnthn secretly started MoarVM. He reasoned that if by some miracle Parrot got back on track in a way that obviated the need for MoarVM he could mothball it or transfer the best pieces. If not, he'd charge right on ahead and finish MoarVM.

Fast forward to 2014. Reini Urban is about the only person working on Parrot and it is currently falling further behind in supporting Rakudo's current needs. For example, concurrency. In contrast MoarVM now far outperforms Parrot as a backend for NQP and Rakudo and looks set to pull much further ahead this year.

jnthn had designed and implemented 6model and NQP and there was a chance Patrick could have convinced Parroteers to replace the broken stuff in Parrot with these pieces.

Multiple Parrot developers volunteered to do this. Rakudo developers said "No", or in some cases "Not yet." Said developers tired of being called out for not supporting Rakudo on one hand and being told not to improve Parrot on the other hand and stopped working on Parrot altogether. You can easily verify this by looking at mailing list archives from that period.

Reply on news.ycombinator.com