This "waiting for Perl 6" confuses me.

People don't wait for new programming languages the same way they wait for a bus. If you wait 30 minutes for a bus that you would expected to come after five minutes, you are angry that you lost 25 minutes, and decide to take the 10 minutes walk to the next subway station, or take a taxi.

That's not how people wait for Perl 6. They use other programming languages (often Perl 5) in the same time, and don't lose any time anticipating a Perl 6 release that will be useable in their production environment. So the 12 years of waiting aren't 12 wasted years for anybody (except if somebody really was that foolish not to use any other programming language in the mean time).

And thus those 12 years aren't really a problem for most of us. When somebody tells you about a cool programming she just started using, does it really matter if that language has been 2 or 12 years in the making?

To stretch the analogy a bit further, it's a bit more like waiting for electrically powered cars. When a company starts selling powerful and affordable electric cars, I'll buy one, and won't make ridiculous claims like "The world has moved on", just because they were long in the making.

Perl 5 has fundamental flaws that aren't being addressed by any future plans for Perl 5 development that I've seen so far, just as gas powered cars have a fundamental flaw in the long run (limited fuel availability). Gradual improvements (like more efficient fuel usage) help for a certain time, but they can't replace a fix for the fundamental problems.

That's not how people wait for Perl 6.

I wrote my first serious Perl 6 code in 2005, because Pugs was mature enough to run it. (Admittedly I had to hack on Pugs with copious help from Audrey to make it run, but I did it.) Then Pugs hit a wall and I couldn't run it productively any more. (It took eight hours to run the full test suite with Pugs. I think this was around February 2006.)

Around the time Rakudo became Rakudo and not languages/perl6 in Parrot, I could run that code again. Then came the Rakudo rewrites. I was hopeful that the Rakudo Star release targeted at April 2010 (which slipped to the end of July) would mark the point at which I could have that code running and keep it running with minimal work. I don't mind making minor syntax changes to meet specification changes now and then (it was pretty standard and straightforward OO code with a little bit of multiple dispatch, after all), but the point of usability I wanted was the point at which I didn't have to pay the upgrade tax with every new compiler release just to keep working code working. (The program was effectively finished; it didn't need further development.)

Then came the Rakudo rewrites. I can't even describe this history effectively; I know Rakudo's gone through PGE and NQP and NQP-rx and NQP-ng and now nom, and I know I have them in the wrong order and I don't remember which of those occurred before Rakudo Star 2010.07. In a way, that doesn't matter.

I started to worry last December, and I stopped trying to maintain that program altogether in January when it was clear that the nom rewrite would take far longer and produce far more disruption than anyone else wanted to believe. The choice was between sticking with unmaintained code of Rakudo releases on an abandoned branch or switching to a rewrite in progress.

I knew that I could be wrong—things could have gone smoothly—so I decided to wait and see what happened. Now that nom has officially replaced master, it does have some improvements, but it still has substantial regressions. There's also still no new Rakudo Star release.

I'm not interested in telling other volunteers what to do or what to care about, but I cannot in good conscience say that "Perl 6 is just around the corner" when I (who started working on Parrot in August or September 2001 and on Perl 6 in February 2003) have to pay the upgrade tax every month to keep a relatively simple and finished program running.

I can overlook a lack of documentation (documentation is difficult) and occasional bugs and missing features. I can put up with specification changes (they've largely been for the better). I can choose whether to work around the lack of useful libraries (someone has to write them). I accept that people will work on what they want to work on, especially when most of them aren't getting paid to produce a useful product.

Yet with all of those disclaimers, trying to keep that simple program running across all of the changes in Rakudo became very much a waste of my time. The Perl 5 replacement isn't as nice in a compulinguistic sense, but it has the advantage of working and continuing to work without me having to modify it every few weeks (to get performance improvements or bug fixes). Six years was long enough for my experiment to show that Perl 6 really isn't just around the corner unless something changes dramatically.

(No, I'm not going to share that program, because the spectests cover every part of it. They have for years.)

---

Improve your skills with Modern Perl: the free book.

So let me get this straight: you say that Perl 6 isn't usable now because Perl 6 compilers have frequently broken your program(s) in the past. Is that correct?

Perl 6 - second systems done right

Hallo chromatic,

First want to say that hearing such things which just can't be seen as *try to move things in better direction* is sad especially from such well-deserved perler... You are right on many points and everybody know how look Parrot/Rakudo state. But yelling just *did not help*, for both sides of discussion.

Second, your current detailed obiections about Rakudo Star are not well placed becouse it, in my opinion, practically landed ! Fact: I was using latest Star (2011.07) and probably week ago tried nom branch and was surprised that *everything* just worked ! So, practicaly, next Star is available now and oficially is planned on December. Do you know how big improvements are in ?

Now about Perl6 state... Problem no. 1 is Parrot. IMO again. It was planned as reimplementation Perl5 low level functionalities eg. IO buffering to be base for ALL possible scripting languages. Few things work, other not eg. threads... And Rakudo rewrites happens becouse of lack of adequate functionality in Parrot, eg. MMD... Maybe problem is that Parrot developers and compilers developers are too separate communities ? Or maybe in some point there was lack of coordination. Rakudo devs ended implementing things around Parrot or on NQP level. I cannot say how bad or good that is but few things should happen in other way.

So that NQP-xx stages are not (only ?) Rakudo devs fault. And yeling that new Star is not available when it is just landing is for what purpose ?

And, personally, you have personal rights to be nervous in any way you like. But, to the point of other persons private rights. For example, maybe you will feel better when some nasty post make pressure to release Star month or two earlier. But, that core developer have serious family problems means something to you ?? Especially in project which is developed by volunteers. Aggresive lead is realy good but in war situation. Assertive anytime.

So what you want to achive by depreciating Perl6 work done so far ? Want a product ? Everyone want the same ! Tell us something good, show what we doing wrong and not see. But some workable advices...

And remember, that core developers set is just few ppls divided by 2 actively developed compilers. And probably Niecza is done seriously just by Sorear... Not looks realy like "community" rewrite. We need more ppls. And it is need to learn Perl6 before start active development, takes time too. Maybe few Parrot folks can move to Perl6 ? Probably pmichaud++ and jnthn++ comes from Parrot.

Best regards