Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: CPAN modules on old versions of perl? (Perl::Critic::Ancient anyone?)

by grinder (Bishop)
on Nov 28, 2006 at 18:01 UTC ( #586541=note: print w/replies, xml ) Need Help??


in reply to CPAN modules on old versions of perl?

Asking authors to determine the minimum version of the perl interpreter required to run their program sounds like a lot of work, and therefore doomed to failure. You might coax a few authors into doing so by making it a measure of Kwalitee, but I can think of a better way.

Given all the Perl::Critic modules around, it might be a fun project for someone to write a Perl::Critic::Ancient, which warns about constructs that exists are available only in 5.8 or better, or only in 5.6 or better and so on. For instance, if you encounter our, the module would complain that it won't work on 5.005.

Another example: the constant module changed quite a bit over the years in what it would or would not allow, such as constant hash refs.

It might be nice to criticise code that doesn't work across a single maint version. For instance, there might be stuff that works in 5.8.8, but doesn't work prior to 5.8.4. (I have no idea if this is true, offhand).

The beauty of this approach is that, as a module, people would have a venue for reporting bugs, noting that such and such works in 5.8.7 but not in 5.8.6. Some people might even offer patches!

This also puts the burden on someone who needs to install, say, Plagger on 5.003_11 to go to the trouble of auditing themself what modules are required, and using this (on a modern installation) to find out what roadblocks stand in the way of success.

It also avoids wasted effort. What's the point of expending a non-trivial amount of effort to ensure that all my CPAN releases work on 5.002, when there's a fair chance that no-one will ever need it? I do not have the time.

On the other hand, if I received a cry for help from a lonely programmer who was battling to install one of my modules on 5.004, and gave me a report of what the offending lines were in the code, there's a better than middling chance that I just might go ahead and do it, because I would be happy to help this person out.

• another intruder with the mooring in the heart of the Perl

  • Comment on Re: CPAN modules on old versions of perl? (Perl::Critic::Ancient anyone?)

Replies are listed 'Best First'.
Re^2: CPAN modules on old versions of perl? (Perl::Critic::Ancient anyone?)
by jhourcle (Prior) on Nov 28, 2006 at 22:54 UTC
    It also avoids wasted effort. What's the point of expending a non-trivial amount of effort to ensure that all my CPAN releases work on 5.002, when there's a fair chance that no-one will ever need it? I do not have the time.
    On the other hand, if I received a cry for help from a lonely programmer who was battling to install one of my modules on 5.004, and gave me a report of what the offending lines were in the code, there's a better than middling chance that I just might go ahead and do it, because I would be happy to help this person out.

    Although I could see the desire to have your code be used the world-over, sometimes the cost of making things backwards compatable makes them more obfuscated and harder to maintain, or result in other tradeoffs; yes, it is possible to write things in Perl 4, but many of us enjoy the added features of Perl 5.8 and would love to see the new features of Perl 6.

    I'm going to have to go against the grain on this one, and say that rather than trying to make all of the modules used behave like older versions of Perl, it'd be better (although I'm guessing vastly more complicated) to make a source filter that allows a given file to be parsed as the older version. Of course, the problem is that this would likely cause slower execution time and additional overhead.

    I don't think it's a good idea to try to tie our hands and insist backwards compatability by changing the modules is the best way to go. We have newer tools, and we should use them. Decisions were made to maintain older versions of perl, and this is one of the tradeoffs. Yes, it sucks, but it's their decision on upgrading perl, and this is just one of many factors that might influence it.

    * Note -- I don't have modules published through CPAN currently, but I have had to deal with management who wouldn't allow me to upgrade code that needed it -- I just went and installed multiple versions of perl, and made sure that the libraries I wrote worked in both versions. The only problems I remember having was some quirk with Net::LDAP, and I just went and got an older version, so the two matched, as management didn't give me enough time to analyze what had gone wrong

      yes, it is possible to write things in Perl 4

      Maybe so, but modules don't exist in Perl 4, so the issue is moot.

      The point I was trying to make is that I hold the code I publish on CPAN to a to a higher standard than the code I write from day to day. The former should be able to run on a wider range of perl interpreters, the latter could quite easily be tied to a single release.

      The Perl syntax understood by perl 5.8 is not radically different to the syntax understood by perl 5.000. Yes, there have been lots of nice little tweaks and fine-tuning over the past 12 years, but nothing that has fundamentally changed the language. (ok, $coderef->() is really nice, and the alternative is awful).

      It's not particularly difficult to write code that avoids 5.8-isms. I don't recommend this as a regular technique, but in code for CPAN, it means the code works for a wider audience.

      I think chromatic under-estimates the longetivity of business installations. At my previous place of work, they're probably still using 5.003. Currently at work, some of my mission-critical systems rely on 5.6. They will probably continue to do so until they are retired. Life is too short to upgrade perl continually, just to ensure that I'm running on a perl released less than two years ago. It just ain't gonna happen.

      Again, I don't recommend that people write in a 5.003-compatible syntax. Write in 5.10 syntax, and use defined-or, state variables and the underscore prototype if you want. Write in what you feel comfortable with.

      But it would be really nice to have a Perl::Critic module that examines your code, and points out what parts won't be recognised by a 5.8.x interpreter, what parts won't by a 5.6.x interpreter and so on. It would be a fun project I think, for someone with more tuits than I, and it's certainly something the Perl community could be proud of. Something we could hold up and say "See? Java, PHP, Python, Ruby... they have nothing like this! You can audit code and find out what the minimum perl interpreter is needed to run it."

      And it would be Good.

      • another intruder with the mooring in the heart of the Perl

      I agree. I don't go through the effort of submitting patches to p5p so that I can use those new features and rely on those bugfixes someday. I have little interest in offering free support to someone who won't run a stable Perl released sometime in the past two years.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (4)
As of 2023-01-28 10:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?