Waiting for a Product, not a Compilerby chromatic (Archbishop)
|on Nov 27, 2011 at 22:18 UTC||Need Help??|
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.