5 ms·

> 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 (partial

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

raiph 13y ago
> 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 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.
- microtherion 13y ago
  > 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.
  - chromatic 13y ago
    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.
    - raiph 12y ago
      > 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 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=PLRuESFRW2Fa77XObvk7-BYVFwobZHdXdK&index=18 https://www.youtube.com/watch?v=XgPh5Li3k4g&list=PLRuESFRW2F...

raiph 13y ago

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

microtherion 13y ago
> 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.
- chromatic 13y ago
  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.
  - raiph 12y ago
    > 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 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=PLRuESFRW2Fa77XObvk7-BYVFwobZHdXdK&index=18 https://www.youtube.com/watch?v=XgPh5Li3k4g&list=PLRuESFRW2F...