It's not always a matter of being afraid to upgrade Perl. For example, Solaris 8 came with Perl 5.6 or 5.005. Perl wasn't used on that machine for a big program but for convenient small utility programs that created human readable diffs. Having modules needlessly require higher versions of Perl would have lessened the utility of Perl on that platform by much.

I am not against using features when they are useful. I almost always use three-arg open() and qr// whenever they are needed. But especially our is a useless feature that introduces a 5.6 dependency which is completely unneeded - use vars qw() achieves (almost) the same, except that you have to refer to a global variable by its global name from outside the package, which I consider more correct.

For example, one of my modules, parent works with Perl down to 5.004, and Maddingue helped me weed out the compatibility problems that only existed in the test suite. Often, little fixes restore backwards compatibility and if you want your code to be used, thinking of backwards compatibility makes it easier for your users to actually use your code in their environment.

this is an excellent point however:

What do you mean by needlessly?

You can write (almost) everything on Perl 5.000. Hey you could even do that in Perl 4 syntax using require... So why do we expect (and let our users expect) that modules will always work on old version of Perl? This creates needless (here it comes :-) extra work to the module developers.

I cannot speak for that hypothetical "we", but I as a module developer support my users because I want my code to be useful and used. This means that I don't want to place an undue version burden on my users, especially when I am one of my module users. I cannot easily upgrade the Perl versions I have available, and hence want my code to be both, conveniently maintainable on one side and conveniently working on the other side.

For me, this means that I use whatever features I see fit - for example I often use the three-argument open, but I never use our, because the benefit of our is not existent. It's not "big extra work" for me because I mostly know what breaks between the major versions of Perl, and that "little extra work" usually pays off when I encounter a machine with only 5.005 on it.

Remember that the benefit of older perls is larger than you think. The big win is that they are fast. Essentially, if you don't have to deal with Unicode, you don't pay for a lot of overhead. In the C code there is lots of if (unicode) {do_this} else {do_that}. Signal handling has also been made safer since then, at a slight cost in performance.

In fact there have been lots of things added that impose small performance decreases here and there. But the cumulative effect is profound. Consider 6 hypothetical patches to the core. One imposes a 2% decrease, two more impose a 3% decrease, two, a 4% decrease and a final patch makes things run slower by 5%. Doesn't sound too bad? When you add up the effects (0.98 * 0.97 * 0.97 * 0.96 * 0.96 * 0.95)... you discover you've lost 20% performance.

(I'm just playing devil's advocate here... my home machine is running perl 5.10.0).

Of course, if you are doing Unicode you have no choice, but in other circumstances you do.

When a newcomer to Perl looks at a central module or even at a module in core, they see that we are not using the "advanced" features. What message does that give?

This is a false debate. Some of the most scrofulous C code I ever read was source of the standard C library of a compiler (Zortech C, for memory). Not because the programmers were slouches, but because they were held to an imperative of working around bugs in CPUs, operating systems and even their own C compiler. Lots of comments like "can't do foo() here because of...".

So it's hardly surprising that some of the core module code is messy. That's so you don't have to worry, as a client. Systems code is held to a different standard, and looked at through a different lens. I know lots of people don't agree with this, starting with chromatic, but I still believe you can enjoy writing code that forgoes certain language constructs. Poets call this constrained writing.

If people don't wish to support 4.0, 5.004, 5.005, 5.6 or any other version then perhaps there should be a move to End of Life them.

Until then I'll continue to support 5.005 if possible.

--
John.

Update: I probably should have linked to Software End of Life instead of Product End of Life.

Quoting that link from wikipedia:

End-of-life is a term used with respect to a retailed product, indicating that a vendor will no longer be marketing, selling, or promoting a particular product and may also be ending or limiting support for said product.

We cannot stop marketing and selling perl 5.004 as we never did that. Recently I have not seen many people promoting that version of perl either. Does 5.004 or anything below 5.6.0 really still have support?
Is 5.6.0 supported?
What about 5.8.x< 5.8.8 ?
We are not a corporation that needs to End of life a a version of Perl.

It is nice that you make the effort to support old versions of Perl but I think we as a community should not have this as an expectation.

To many of its users, Perl is not a product, it's a tool. You use whatever version of Perl is available at the moment. Needing to upgrade the version of Perl means that you could likely easier accomplish the task at hand using a pipe system made out of sed, awk and ksh. This is why it's important to me not to place unnecessary restrictions on modules.

Perl 5.6.0 came out in March 2000. Perl 5.8.0 came out in July 2002. Those releases are seven and five years old, respectively.

I haven't received a nickel for any patch I've contributed to Perl, whether documentation, tests, or functional code. I haven't received a penny for any module I've ever written or maintained. I'm not complaining; I've never asked for anything nor have I expected anything. I wrote the code because I wanted to and I released it because I hoped it would be useful.

I've fixed bugs in Perl and in various pieces of code because I wanted to fix them. I added features and documentation and tests because I wanted to use those features, to see other people use them, and to have confidence that they work. I didn't write them because I wanted or expected money, or appreciation. I wrote them to get used.

It is not worth one second of my time even to think about supporting ancient versions of Perl, versions which are missing useful features and which contain known and unfixed bugs. I didn't add features to code or fix bugs in the hope that maybe five or seven years later I might be able to rely on that feature being present or a bug being absent without someone complaining that for all that I've never requested or expected money, praise, or even appreciation, my code doesn't run on ancient software. I helped the build great software because I want to use it.

It is ridiculous to expect volunteers to support code that is seven years old, code eleven stable releases old.

That's my opinion and my choice of how to spend my free time and how I donate my experience and code and effort. Again, I don't get paid for this. I've never asked for payment. I've never expected payment or appreciation. I just put out the best code I can for anyone to use as they see fit under a license that allows them to do many useful things.

If someone else chooses to spend his or her free time bending over backwards to provide shiny new software for people who've demonstrated that they don't care about upgrading because they can't be bothered to upgrade to a version of Perl released this millennium, that's his or her own choice and I won't stand in the way. I think it's ridiculous, but I'm not going to tell anyone how to spend his or her free time, just like I'm not going to put up with anyone telling me that I should spend one moment of my time caring that one of my modules doesn't run on Perl 5.004 (originally released in May 1997 and most recently updated in April 1999).

Update: reversed "five and seven", per talexb's suggestion.

When people like Tim Bunce accept patches to make their code work on 5.6.2, that is the difference, in some companies, between "of course perl can work with databases" and "perl is a useless piece of hacker shit that can't even talk to a database, let's use Java".

I'm not saying that you *must* make your code backward compatible - as you quite rightly point out, I ain't paying you so have no say in how you spend your time. But it would be nice if you did.

And as for how old perl 5.6 is - hands up who's using the even more ancient C and SQL standards. Mature languages don't normally go adding new and pointless features - like 'our' and three-arg open - willy-nilly, and in my opinion mature programmers won't go using them without giving serious thought to the ramifications.

When people like Tim Bunce accept patches to make their code work on 5.6.2, that is the difference, in some companies...

5.6.2 I can almost accept. It's nearly four years old, but I can almost accept this, because it shows that at least they upgraded to something somewhat modern.

I'm sure there are companies using Perl 4.x, which is fourteen and a half years old. I don't see why anyone should care about them.

And as for how old perl 5.6 is - hands up who's using the even more ancient C and SQL standards....

Hands up everyone who's using gcc 2.x, Visual Studio 1.x, and msql.

Mature languages don't normally go adding new and pointless features - like 'our' and three-arg open - willy-nilly, and in my opinion mature programmers won't go using them without giving serious thought to the ramifications.

Objection: strawman. I didn't mention any features in specific, and I did mention bugfixes. I'm sort of a fan of being able to use Unicode properly, and I'm definitely glad for performance improvements in regular expressions and all of the memory leaks fixed in closures and CVs coming in 5.10. It's a bit silly to call those pointless features added willy-nilly.

I used to use "our" and 3-arg open() until I started working in a shop that supports all kinds of ancient machines (Redhat 6.2, with Perl 5.005_03) because that's what a particular customer bought way back when and they don't want to upgrade.

So now I just avoid all the new-fangled constructs (which don't really add much anyway) and try to avoid modules that don't work on 5.005. Sometimes I have to go download an older version of a module, such is life.

In some cases I find that it makes sense to minimize the dependency on external modules and do as much as possible with Perl core. It's pretty powerful as it is... For instance, why use Switch.pm when the Perl Cookbook has a perfectly good, portable example of a switch statement that's made up entirely of built-ins and works even on ancient versions of Perl? (Switch.pm wasn't a standard module back then either).

For most modules, I would agree that it's not worth the effort. With Test::Harness, it's worth it if we can do it with minimum pain. The main problem is the concerns that we can get performance benefits from pre-compiled regular expressions with qr//. Performance is one of our biggest issues (we're pretty damned close, though), and if a 5.004 patch is supplied which is minimal impact and doesn't hurt performance, we'd strongly consider it. (Hell, I'd consider a factory class instantiating "version" subclasses on demand if that's what it took, but there are other problems with that which are beyond the scope of this reply).

What was the result? That my module, which worked perfectly well with the newer perls (5.6.1+), even after the changes for compatibility, somehow caused the old perls to segfault. That's one of those errors that's "not supposed to happen" when you are writing pure Perl! So, from that moment on, I don't give a damn about supporting ancient perl versions such as 5.004. I'm willing to work around the lack of recent features and syntactic sugar, but I'm not willing to work around the bugs.

There are many very good reasons why different organizations may need to use older versions of Perl, and yet still need newer modules. This fact in no way makes module authors responsible for supporting older versions, although I would hope that it's enough to make us accept nonintrusive patches to provide such support.

The way I look at it is that if you're putting a module out there, you are doing it to help people. Maybe that's not your primary concern; that might be the ego gratification or whatever, but you don't get any of the other benefits without actually helping people. So the question of maintaining backwards compatibility is strongly influenced by your estimate of the number of people such support would help. For example, a module in a ton of other modules' dependency trees has much more motivation to provide backwards compatibility than a leaf module.

My personal approach is to try to maintain backwards compatibility, up to the point where using a new feature would make the coding appreciably easier or better. When that happens, I discard support for older versions lacking that feature without a backward glance. Thus, I could say that I only break backwards compatibility when there's a decent reason for it, but in truth, the reason doesn't have to be that good. If more people used one of my modules, though, I would worry a lot more.

I'd also like to point out Python as a counterexample. I tend to work with somewhat but not excessively old Linux distributions, and I've lost track of the number of times I've run into "application A needs python 2.2 but also library L which I have for 2.2 but I also need for application B, which requires a newer version of library L that requires and installs into python 2.3's tree". For whatever reason, I am constantly fighting version dependency battles with Python, and rarely am with Perl. Some of that is because Perl makes it relatively easy to support older versions -- even when a major release is technically not API compatible, Perl tends to minimize the API changes to the extent that very little code actually breaks.

I suspect that people's opinions on this debate are highly correlated with whether or not they have worked in an environment where they were forced to use an older version of Perl (or other similar package).

This is a simple, yet tremendously profound comment. For many organizations, upgrading language tools is a hairy business -- hence the reason I have to support compilers for the thirty-year-old F77 standard. Today, I have systems in production that run perl 5.005, 5.6.0, and (several variants of) 5.8.x. I'm hopefully eliminating the two older of these versions, real soon now (TM) -- but I expect the 5.8 tree will be around for some time. This is primarily because 5.8 is "current" for the OS versions I am using, and getting approval from the software police requires approval from God, Congress, and Griffin (the mythical creature, not that guy in finance :)).

I am primarily a module user, and all the modules I write are for internal use only -- but I know the pain of trying to code for a perl rev that doesn't support 3-arg open() or function prototypes. Occasionally, that situation forces me to defer code reuse and roll my own because I can't find a compatible version of the .pm I want.

Based on this experience, I can completely understand why module writers don't want to be burdened by trying to get their code working under older Perl revs. I am also extremely grateful to those of you who do.

My personal stance has usually been something like "I'll support two major versions most of the time, and three for a little while after a new release".

I do reserve the right to not support particularly old point releases of those major versions, however. In particular, Perl 5.6.0 had so many critical bugs that working around them was just impossible. I test with Perl 5.6.2, and I'd take patches for 5.6.1, but if you're still on 5.6.0 too bad for you.

Similarly, if you're using a particularly ancient 5.8 (say 5.8.0 or 5.8.1) and one of my modules triggers a known Unicode bug in those versions, too bad, since one of the main reason to upgrade to a more modern 5.8 is for Unicode bug fixes.

I expect to stop supporting 5.6 for my modules a year or two after 5.10 comes out, though I won't intentionally break them, I'll probably just stop testing with 5.6 at all.

Overall, I think that's a reasonable balance between using modern features and backwards compatibility. In my personal projects which aren't intended for release, I do tend to use the latest and greatest, even if that code might end up freely available (like the source for VegGuide.Org).

The extreme case perhaps can be seen between 4.x and 5.x upgrades, or big features in 5.x series such as unicode support. If the customer needs unicode support then choice is clear. For me, it's hard not to move to Perl object oriented and leave 4.x behind.