After reading Dan Book's Risk-Benefit Analysis and his Recommendation, I'm less hopeful for Perl 7. And in that, I'm not sure the concepts of "modern", and "Perl" blend well.
There is a lot of older Perl code out there. it's easy to find "modern" languages that do this or that, and coders flock to them with great joy. They also flock up the internet with ideas about what a language should look like and what new toys are important at this moment. While good code can be artistic, code isn't art. Its syntactical balance and arrangement are secondary to a pragmatic "does it work?" No matter how pretty (Object Oriented, Functional, whatever the cool paradigm is today) it is, code must work to have any value.
We can produce working code in Perl. Because of the Perl team's herculean efforts at backward compatibility, we can produce very long lived code in Perl. I can write Perl 5.8 compliant code that gets the job done. Perl 5.8 is old enough to vote in the USA! More to the point, if I can get the job done in Perl 5.8 then I don't really need new things from 5.12+. Later Perls add tools that developers like, but if the code works then the end user doesn't really care about the version.
While dropping support for older Perls makes workforce sense, it hurts Perl overall. We will lose users because the code no longer works and CPAN modules won't easily install. However, the support cost to you and others is high. I certainly won't fault you for dropping support for older versions.
Do what is best for you, as each of us should. My code must meet certain requirements, and "work on the customer's old Perl version" is one of them. I had hoped Perl 7, while a ways off, would give us a way to talk customers into moving forward. It seems my idealism might be misplaced.
Addendum I was messing around with MariaDB 10.5.8, the mostly latest, and the "server" rpm includes Perl files, including one originally written in 1998.
| 