6 ms·

Bullshit. Top article there right now is "A useful, usable, “early adopter” distribution of Perl 6". Sounds lovely, doesn't it? The problem is that these "ear

Bullshit. Top article there right now is "A useful, usable, “early adopter” distribution of Perl 6". Sounds lovely, doesn't it? The problem is that these "early adopter" distributions of Perl 6 have been released regularly since mid-2010. The first "early adopter" Perl 6 book was released in 2003. 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. 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. I don't expect the project to ever converge on a stable release. Early adopt it all you want, but don't claim it's "further ahead than one might think".

tadzik_ 13y ago
Thankfully or not, your comment is so full of bullshit, FUD and exaggerations that it's not going to fool anybody. Try being less poetic and more to the point next time.
- microtherion 13y ago
  My comment contains numerous easily verified facts. I note the utter absence of any attempt on your part to provide evidence that contradicts anything I said.
- Pacabel 13y ago
  How do you figure that? That comment that you replied to matches reality very well. Perl 6 is nearly 15 years old now. There have been many attempts to implement it during this time, and none of them have really been usable like Perl 5's implementation is. I can recall hearing about Rakudo Star, Pugs, Niecza, v6.pm, Yapsi, and Sprixel. There are probably others that I've forgotten about. And that's ignoring NPQ, Perlesque, Parrot and all of the other intermediate implementations and runtimes that have been dabbled with. There has been a lot of wheel-spinning when it comes to getting Perl 6 implemented. It's like they've tried everything except the proven approach of just writing a plain interpreter using C, like we've seen work well for earlier versions of Perl, Ruby, Python, and so many other languages.
raiph 13y 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 13y 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.

tadzik_ 13y ago

Thankfully or not, your comment is so full of bullshit, FUD and exaggerations that it's not going to fool anybody. Try being less poetic and more to the point next time.

microtherion 13y ago
My comment contains numerous easily verified facts. I note the utter absence of any attempt on your part to provide evidence that contradicts anything I said.
Pacabel 13y ago
How do you figure that? That comment that you replied to matches reality very well. Perl 6 is nearly 15 years old now. There have been many attempts to implement it during this time, and none of them have really been usable like Perl 5's implementation is. I can recall hearing about Rakudo Star, Pugs, Niecza, v6.pm, Yapsi, and Sprixel. There are probably others that I've forgotten about. And that's ignoring NPQ, Perlesque, Parrot and all of the other intermediate implementations and runtimes that have been dabbled with. There has been a lot of wheel-spinning when it comes to getting Perl 6 implemented. It's like they've tried everything except the proven approach of just writing a plain interpreter using C, like we've seen work well for earlier versions of Perl, Ruby, Python, and so many other languages.

raiph 13y 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 13y 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.