My recent entries here hit a nerve in fellow p5per Steffen Müller. In a comment on 's Guide to CPAN Needed, Steffen claims that my arguments are "pie-in-the-sky fantasies" from someone who "has done nothing but finger-pointing".

That's a dangerous line of thought when addressing criticism of a software project.

I can imagine a fair few people wondering when the Perl 5.10 performance regression when assigning a list from @_ , patched in January 2008 will ever be present in a release version of Perl.

(It's doubly amusing, in a very sad way, when one of the excuses for avoiding regular releases of Perl 5 is that "We just can't cause regressions!" and when Red Hat gets pilloried for a somewhat rarer Perl 5 performance regression.)

Is pointing out that a patch for a known performance regression languishing, unreleased, in bleadperl for 17 months a problem? Is that criticism dismissible from everyone who isn't currently a Perl 5 committer or the maintainer of a core module?

Perl 5.10.1 could have come out on 07 January 2008 with only that patch and been an improvement over Perl 5.10. There is no shortage of minor version numbers. There are no API changes. There are no backwards compatibility concerns. (I don't know if the smokes were clean on all target release platforms, but given that the patch is very simple; most of it is moving code a few lines, I believe that's a low risk.)

Yet Perl 5.10.1 still hasn't come out, seventeen months later -- and imagine the furor if a downstream Perl distributor applied the patch and something went wrong. In what universe is it a good thing that a trivially fixable performance regression affects more and more people every day when it could have been fixed three weeks after Perl 5.10's release -- before it had affected anyone besides early adopters.

Imagine applying the same line of reasoning ("Your criticism is wrongheaded and useless") to anyone who said "If the Switch module is dangerous and not recommended, why not remove it from the core?" (Fortunately, it is on the docket for deprecation and eventual removal.)

Imagine applying the same line of reasoning to everyone who says "You know, Perl 5 really could use optional function signatures, or Perl 5 could use a declarative syntax for classes.

That's what bothers me most about Steffan's comment; it elevates "plain old hackers" above people with ideas, questions, concerns, and the desire to improve the efficacy of other plain old hackers.

Yet if it takes a core hacker to make these arguments, permit me a biblical allusion to Philippians 3:5 to answer the silly charges of "Philosophy and project management and advocacy and education and writing documentation are all worthless; you should write code!"

As of last Friday, I owned more of bleadperl than Steffan. (Yes, this is a stupid comparison, because....)

I wrote a huge amount of tests for the core and standard library in the early 2000s when we quadrupled the number of tests between Perl 5.6 and 5.8. (A lot of that work doesn't show up in the silly line-number Internet measuring contest link in the previous item because I wrote those tests for many other people who have taken over maintenance -- this is exactly what you expect when you write tests.)

I wrote the original version of Test::Builder upon which nearly all modern Perl testing exists -- including the testing used to demonstrate the core's stability.

I co-wrote the book on Perl Testing.

As linked earlier, I grew tired of suggesting that someone add the class keyword to Perl 5 and added it myself (though sadly, the patch was rejected).

keyword to Perl 5 and added it myself (though sadly, the patch was rejected). I backported the yadda-yadda-yadda operators from Perl 6 to Perl 5 and implemented DOES .

. I can predict, to the day, the next 25 stable releases of Parrot, including the releases where we will have removed deprecated features and the releases we expect downstream distributions to package and distribute. (I believe -- and I believe most, if not all Parrot committers also believe -- that the policy of stable monthly releases saved the project from almost certain irrelevance.)

I don't mean to disparage anyone else's contributions -- far from that, I believe that everyone who's reported a bug, suggested a change to the wording of the documentation, or posted the results of a test run has just as much right to voice concerns about a project as a core developer.

That doesn't mean my critcisms or concerns are accurate or correct or useful. They could be wrong. I welcome corrections, if so.

Yet there's something deeply wrong with a release process that lets known and fixed problems that almost every Perl 5.10 program will encounter linger for years, especially when fixing them is trivial.

You shouldn't have to be a pumpking to be able to say that.