Parrot releases are harder to count because of their prolific release cycle.
— Brian Wisti, In Which Brian Whinges About The Perl 5 Release Schedule
This is a trivial nitpick (read the rest of the article! It's very good!), but Parrot releases are very, very easy to count. The same goes for Rakudo releases.
The other day someone asked what Parrot might look like in a hundred years. I laughed and thought, "What would its version number be?" Then I realized that I can predict its version number in 100 years. Parrot 101.6 will be out, with Parrot 101.7 on the way.
For all of the lofty talk about "stability" and "maturity" and "predictability" which results in Perl 5 not getting released, the fact that I can predict the release date and version number of a piece of software one hundred years in the future says something about the stability, maturity, predictability, and reliability of a very different kind of development process.
(Oh, and Alias -- I can crash several so-called stable releases of Perl 5 with a one-liner the same way you crashed Parrot in December 2008 with a short program. If you want to make the argument that the 30 stable monthly releases of Parrot in a row don't actually exist because they had bugs, the two so-called stable releases of Perl 5 from the same time period don't exist either. Ontological debates are easy to lose.)
I just let the program run for a minute and a half until it leaked all memory on the host and was killed off by the kernel...
I look forward to a packaged distribution so that I can replicate the original test and confirm that the problem has been removed.
Re:I didn't crash parrot
chromatic on 2009-07-03T17:02:29
I just let the program run for a minute and a half until it leaked all memory on the host and was killed off by the kernel...
My Perl 5 program does the same. I confirmed it now with bleadperl; Perl 5.10.1 will very likely have the same problem.
