8 ms·

> The problem is that these "early adopter" distributions of Perl 6 have been released regularly since mid-2010. I agree. It's taken 4 years to get to this lat

by raiph 12y ago

> The problem is that these "early adopter" distributions of Perl 6 have been released regularly since mid-2010. I agree. It's taken 4 years to get to this latest Star, on top of P6 being 10 years old when the first Star came out. It's all way slower than most (all?) folk expected. This has impacted early adopters, perception/marketing of P6, perception/marketing of P5, and attracting contribution to P6. > Generations of Perl 6 hackers have joined the project, re-written a key piece of the infrastructure, broken a bunch of APIs, and left again. There's definitely been a lot of churn. However, if you focus on the P6 projects that still matter today (eg Rakudo, NQP, the test infrastructure, MoarVM, p6doc, the modules infrastructure) then you find activity that doesn't -- and never did -- match your arrive-rewrite-break-leave pattern. > If it hasn't happened already, we will soon see the CHILDREN of Perl 6 hackers born during Perl 6 development start doing half-baked infrastructure rewrites. The projects that still matter today don't allow new devs to be unduly disruptive. (Getting a commit bit to the most important bit, Rakudo, requires evidence of competence followed by signing and submitting a formal application.) > Early adopt it all you want, but don't claim it's "further ahead than one might think". It sure still isn't ready for most use cases. But have you given a recent release (especially the latest Rakudo Star) a serious look? --- (Edit: Removed the opening sentence "No. " before "The projects that still matter today don't allow new devs to be unduly disruptive." because you can't stop volunteers doing whatever they want.)

microtherion 12y ago
> if you focus on the P6 projects that still matter today (eg Rakudo, NQP, the test infrastructure, MoarVM, p6doc, the modules infrastructure) then you find activity that doesn't -- and never did -- match your arrive-rewrite-break-leave pattern. Correct me if I'm wrong, but isn't MoarVM less than two years old? That would still put it squarely into the rewrite-break phase of the cycle, so it's too soon to tell whether the "leave" phase will follow or not. > Getting a commit bit to the most important bit, Rakudo, requires evidence of competence 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. > have you given a recent release (especially the latest Rakudo Star) a serious look? Not really, I'm afraid. The code examples I've seen don't really look appealing, I have not seen anything that truly made me want to try the language (though I keep hearing good things about the supposedly amazing parsing support), and the lack of a plan to ever move to a product quality release is a major turnoff.
- 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.

by raiph 12y ago

microtherion 12y ago

> if you focus on the P6 projects that still matter today (eg Rakudo, NQP, the test infrastructure, MoarVM, p6doc, the modules infrastructure) then you find activity that doesn't -- and never did -- match your arrive-rewrite-break-leave pattern. Correct me if I'm wrong, but isn't MoarVM less than two years old? That would still put it squarely into the rewrite-break phase of the cycle, so it's too soon to tell whether the "leave" phase will follow or not. > Getting a commit bit to the most important bit, Rakudo, requires evidence of competence 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. > have you given a recent release (especially the latest Rakudo Star) a serious look? Not really, I'm afraid. The code examples I've seen don't really look appealing, I have not seen anything that truly made me want to try the language (though I keep hearing good things about the supposedly amazing parsing support), and the lack of a plan to ever move to a product quality release is a major turnoff.

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.