Re^2: What's the perl5's future?

[xiaoyafeng]

Thanks for your reply. And I totally agree your opinion.

perl5 is too old, and obviously, it won't be added too many new, modern features in following version. So, you have to heavily rely on some 3rd modules on cpan. AnyEvent is a case, we all know its author is a unpleasant guy, but what if DateTime's author become bad?(sorry just a joke ;)) That's why I think perl6 would be a better choice although it's still on the way yet.

[stevieb]

"perl5 is too old, and obviously, it won't be added too many new, modern features in following version."

New features in: v5.8, v5.10, v5.12, v5.14, v5.16, v5.18, v5.20 and the most recent public release v5.22.

That covers 12+ years of perl development. New features are added during each release cycle.

To further, the p5 maintainers have implemented a newer 'experimental' feature, which allows you to import and/or enable/disable warnings for new features that are currently in 'testing' phase. This allows Perl end-user coders to test new features at will, and provides a life-cycle to test whether anything existing breaks (regression). This is an extremely sane way to introduce new features while allowing interactive community feedback. They also have a very strict deprecation regimen, so that you have at least two full release cycles to swap out code if something is deemed to be removed from core (an accepted experimental feature or a past piece of syntax that breaks new features. Both are uncommon though; usually it's the removal of a CPAN module that has been included in core, but it is being taken back out).

All that adds to the basic fundamental that backward compatibility matters, and these people are really listening to the community, and not disregarding backward compatibility. It's us end users who realistically dictate the future of perl, but only if we speak up using proper channels and sociable conduct. dave_the_m stated above that the maintainers test each build against numerous existing CPAN modules internally, and even reach out to module owners if they spot problems before we do. I think I'll be happy sticking with this setup forever, if possible.

PS. The C programming language is MUCH older than perl is, but it is still widely used...

Update: This is probably a good time to point out that writing unit tests to cover as much of your code base is always a good idea, regardless of how simplistic or minute you think your prod code is. This should be done for all code, but I have a new appreciation for CPAN modules after hearing what dave_the_m said. (Personally, I often write my unit tests as example usage code even before I write the actual code the example will test against).

[AppleFritter]

Age in and on itself isn't an indicator of quality. It's true that development in old projects can slow down[1], but this is by no means necessarily true, and young projects in turn can be lacking, e.g. in maturity, code quality, features and so on. I'd advise against judging projects by their age.

Perl 5, for what it's worth is undergoing active and exciting development; just check the perldeltas for the latest versions.

I also feel I should take up the cudgels for CPAN. You talk about CPAN as if it's a bad thing, but the opposite is true; CPAN is an extremely valuable part of the Perl ecosystem. CPAN allows you to (fairly) easily share the fruits of your labor, and benefit from others' in turn; as such CPAN is a large part of what has made Perl a community, rather than just a language.

Sometimes there's several competing modules on CPAN, but that too is a good thing. After all, isn't TIMTOWTDI (There Is More Than One Way To Do It) one of Perl's mottos? Competition is good, and the best solution will eventually win out. In fact universally-useful, well-maintained CPAN modules can be bundled into the Perl code, and are.

And if no module wins out, and if different people keep on using different modules, then those modules obviously fill different niches. There's room for more than one module for any given task on CPAN anyway, and people being able to scratch their particular itches and getting their jobs done with a minimum of fuss is what I'd call a success.

1. Whether that is a sign of stagnation, or simply conversion on the "Golden Code", is another question as well. TeX (i.e. core TeX itself, not the surrounding ecosystem) is perhaps the best example of the latter, a project that's not seeing much development anymore because it's approaching perfection.