Re^2: The need and the price of running on old versions of Perl

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.

Comment on Re^2: The need and the price of running on old versions of Perl

Replies are listed 'Best First'.
Re^3: The need and the price of running on old versions of Perl by chromatic (Archbishop) on Sep 19, 2007 at 18:13 UTC
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.	[reply]
Re^4: The need and the price of running on old versions of Perl by perlhaq (Scribe) on Sep 19, 2007 at 22:18 UTC
FWIW, and this is my personal prefered dev environment... $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd4.1/3.3.5/specs Configured with: Thread model: single gcc version 3.3.5 (propolice) It was only a few releases ago (each release is 6 months apart) that OpenBSD was shipping with gcc 2.95 as the system compiler. And they're currently in the initial stages of discussion about replacing gcc because it's getting big, bloated, buggy, and regularly drops support for various architectures that some people still use. Perl isn't at all like that though. If anything, later releases fix bugs (while adding a manageable amount of features/bloat), and that's a good enough incentive to upgrade IMO. But not everyone out there sees it that way, or cares at all. In which case, I say to them "So be it!" or "As you wish!", and write my code so that it functions even on ancient releases. Because to me it's neither difficult, nor a great burden to support 5.005, and I'm content enough to be able to get paid writing Perl code in the first place. Heck, it could be much worse. Apparently the python guys have to keep several versions of the interpreter around just to run older code! Except on Win32, and then I need 5.8 to do anything remotely useful. ;-)	[reply]
Re^3: The need and the price of running on old versions of Perl by perlhaq (Scribe) on Sep 19, 2007 at 17:25 UTC
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).	[reply]