Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re^2: 2021 is the year to drop support for Perl < 5.12?

by tobyink (Canon)
on Dec 11, 2020 at 13:48 UTC ( #11125000=note: print w/replies, xml ) Need Help??


in reply to Re: 2021 is the year to drop support for Perl < 5.12?
in thread 2021 is the year to drop support for Perl < 5.12?

So you are suggesting I drop support for Perl versions older than Perl 7, which hasn't even been released yet?

  • Comment on Re^2: 2021 is the year to drop support for Perl < 5.12?

Replies are listed 'Best First'.
Re^3: 2021 is the year to drop support for Perl < 5.12?
by Leitz (Scribe) on Dec 11, 2020 at 17:03 UTC

    Code clean up and support is an exhausting task, so the more "bang for your programming buck" you can get, the better off you'll be. I think a lot of good things might happen with a working Perl 7 release. Since Perl 7 is supposed to be compatible with Perl 5.32, then you can focus development branches on 5.32 and easily migrate to Perl 7 when it works. Communicate to your user base about the 5.32 development branch, and give everyone plenty of time to update or migrate.

    What's the best way to delight yourself and your user base? Choose that.

Re^3: 2021 is the year to drop support for Perl < 5.12?
by Leitz (Scribe) on Dec 22, 2020 at 12:08 UTC

    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.

      Addendum I was messing around with MariaDB 10.5.8, the mostly latest, and the "server" rpm includes several Perl files, one originally written in 1998.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11125000]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (5)
As of 2021-10-27 17:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My first memorable Perl project was:







    Results (94 votes). Check out past polls.

    Notices?