6 ms·

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

by raiph 12y 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 12y 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 12y 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...

by raiph 12y ago

microtherion 12y 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 12y 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...