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

[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).