6 ms·

>> have you given a recent release (especially the latest Rakudo Star) a serious look? > I have not seen anything that truly made me want to try the language

by raiph 12y ago

>> have you given a recent release (especially the latest Rakudo Star) a serious look? > I have not seen anything that truly made me want to try the language Ah. That might explain what's going on here. Presumably your view of P6-as-a-project is like your view of the language -- ie you haven't explored it in detail and are instead trusting some combination of what you've heard and what seems reasonable to you. > isn't MoarVM less than two years old? Coding on MoarVM began just over 2 years ago. > 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, but let's see if we can't just drown the witch anyway. :) First, it must be a mistake to think that project age is a way to determine whether or not this purported P6ian "leave phase" applies to a project. Rakudo is about a decade old. 7 of the top 8 all time Rakudo contributors still participate almost daily. (I explain Patrick's absence below.) None of the other 100+ contributors left a mess (and many still periodically hack on it). So Rakudo clearly has not yet suffered from this damaging "leave phase". But, and here's the reason why I'm saying this stuff: do you therefore think Rakudo will never be subject to the "leave phase"? Imo what matters regarding contribution patterns is more like how complete a project is, whether a given contributor leaves it in good shape so others can understand and hack on it, and whether they are likely to. The project's age is immaterial. Second, devs will leave projects no matter what. I fully supported Audrey choosing to radically dial back her Pugs efforts when doctors told her it could kill her; Patrick, the P6 project manager, choosing to focus on his wife and then children before and after his family's loss; Larry periodically backing off to focus on defeating a serious health problem (most recently cancer). This sort of thing can happen to any project. (Probably in proportion to the length of time the project runs.) Now to some MoarVM specifics. MoarVM is already a radically cleaner/leaner/meaner VM for the NQP compiler toolchain than Parrot. (This was the justification for starting it.) 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 (extremely unlikely event) couldn't be classified as a P6ian "leave phase" curse whether we were 2 years or 10 years in to the project? > The few Perl 6 contributors I know were highly competent. The problem was IMHO not lack of competence, but almost the opposite: A highly skilled and productive contributor would come in, implement most of their bold new vision, but run out of steam before the new component had fully stabilized. That doesn't generally apply to the core projects that are relevant today, the ones I highlighted. To briefly mention MoarVM again: jnthn, the lead MoarVM dev, has been a lead P6 hacker for just short of a decade. One could argue Nicholas Clark has been on the case even longer. Whether a hacker leaves a mess behind is about the character of the hacker and the nature of the project's management. While I'd agree that Pugs development was arguably too anarchic, and Parrot's was arguably too bureaucratic, the projects I've highlighted are well managed and producing results upon which others can continue to build. That said, some devs will inevitably leave. I am very disappointed that diakopter is distracted by startup fever because it means he won't have time to build the libperl based P5 interop that's a critical part of Perl's future. I guess someone else will have to do it. Such is life in the FOSS dev world.

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

by raiph 12y ago

microtherion 12y ago

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