return void;

Earlier this week, I was hanging out in the #corehackers channel and I decided to voice my opinion on the flood of discussions concerning the problems plaguing Perl 5. David Golden challenged me to respond to his post concerning what I want from Perl 5 moving forward.

First, my suggestion to chromatic was that new features should receive first class citizenship over deprecations. Since I prescribe to the technology-over-politics philosophy, I think deprecated features should be removed after 2 releases. Once removed, they should be provided within a library. I don’t feel those aging applications depending on these features need to be intentionally broken, but at some point, features that have been deprecated for 10+ years need to be removed. Keeping them only makes the deprecation problem harder every release they remain.

So what would I like to see out of Perl 5 in the future? Perl 5. It’s simple, I just want to see Perl 5 continue to thrive until there is a complete Perl 6 interpreter (it’s been 9 years, may very well be another 9). Frequent releases have the effect of convincing people that there is an active developer community. When application developers feel there is an active community, they are more likely to consider the platform viable. Application developers do not seek dead platforms for The Next Big Thing.

There are many things Perl 5 pumpkings and developers can do to achieve this. Frequent releases are a must; it doesn’t matter if 1 or 1000 tickets were closed since the last release, getting it out the door is the most important thing. Worrying about 100% backwards compatibility in every release means releases don’t happen. Just look at 5.10.1. 18 months for a minor version upgrade? How many pumpkings has 5.10 had anyways? It’s time to move on and to stop worrying about breaking all of DarkPAN.

Features that extend the expressiveness and flexibility of Perl 5 need the highest priority. The grammars in Perl 6 mean that Perl 6 can eventually host Perl 7. That feature alone will keep Perl 6 alive years beyond any other language.

In the end, bickering about release schedules, deprecation policies, dependency problems, or any other issue is not going to get Perl out the door. At the end of the day, there are technical and social issues to work through. Social issues are hard; people don’t change their minds easily. Let’s just agree to solve the technical issues, which are significantly easier. Scheduling releases, fixing segfaults, and updating modules are all just technical problems that all have solutions. They may not be pretty or quick to fix but solutions exist, and in most cases, we already know what’s needed but are too afraid to move forward. Sure, breaking 10 year old Perl 5 scripts will be painful but no where near as painful as watching Perl 5 die a slow and miserable death where everyone involved bad-mouths it until it actually is dead.