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

[jhourcle]

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

[grinder]

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.

[chromatic]

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.