perlmeditation
deprecated
I've been gone for a while because I have been so busy with work. I have finally gotten into the 'groove' here at this new client of mine, where one of my responsibilities is a "code audit". That is, I am going over an existing site, finding problems, and coming up with methodologies for diagnosing and fixing these problems. In addition to that, I am writing new applications which will hopefully last this organization longer than their current set did, about 2 years. I find that this organization has been de-inventing the wheel for that whole period. Intentionally not using upgraded software, and not using available modules.
<readmore>
<p>
We have many machines, all running SunOS 2.6-5.8 (except my lonely little [http://www.openbsd.org/|OpenBSD] machine), and all running perl 5.003-5.0053. I see continual snippets that look like this:
<code>
$mailprog = '/usr/lib/sendmail';
sub send_mail {
open (MAIL, "|$mailprog -t -oi");
print MAIL "To: $toemail\n";
print MAIL "From: $fromemail\n";
print MAIL "Subject: $thistitle\n";
# ...
close MAIL;
}
</code>
This really is a rather tame example. There are things more like this deployed:
<code>
open FILE, "$string_from_insecure_webpage";
</code>
But I digress. What irks me is that there is a definite opposition to "upgrading" and installing modules. I think it was Nat Torkington who said that CPAN was perl's "killer app." He (or whomever) was right. I have a case here where a lot of this client's code could be simplified, modularized, and securified. However, nobody wants to install modules, and nobody wants to upgrade to a new version of, say, CGI.pm, for fear that some of the older scripts will be broken.
<p>
[tilly] continually gets into it with me over my use of <code>our</code> versus <code>use vars</code>. We've discussed other things like this. I have heard from many people that my wanting to upgrade to perl 5.6 from 5.003 is unreasonable.
<p>
<strong>I'm tired of hearing that!!!</strong> Code should be flexible. If you write code that isnt written exactly as the API suggests you write, youre being a <i>bad programmer</i>. If you want to say:
<code>
use CGI :standard;
# instead of...
use CGI qw{ :standard };
</code>
I hope your script DOES break, and I hope you pay me to fix it. If I cant write fluid, reasonable code using tools available to me because your code is hanging together by deprecated pieces of syntactic bubblegum and duct tape, you are hurting both of us. I cant write the responsible code I want to write, and your script breaks when you look at it cross-eyed.
<p>
The reason this is on my mind is I have written a program that uses [cpan://CGI|CGI.pm]'s cool sub <code>Vars</code>, which must be imported via <code>:cgi-lib</code>. The older copy of CGI doesnt have it. Looking at the readme from the newer CGI, I see this warning:
<code>
Versions 2.44-2.46 introduce two API changes that will affect
users of previous versions:
1) The accept() function has been renamed Accept() to avoid conflicting with
Perl's built-in function of the same name.
2) The sub() function has been renamed Sub() for similar reasons.
My apologies for these changes, but they were necessary in order for
CGI to pass the perl5.005 regression tests!
</code>
Because the site is composed of roughly 200 individual scripts, all using #!/usr/local/bin/perl rather than #!/usr/local/bin/perlX.XXX, I am positive I am going to break at least one or two of them upgrading. Having to install a whole new copy of perl for one piddly module (albeit CGI) is a real waste of resources and time.
<p>
I'd really like it if some of the "dont upgrade" people could explain their reasoning, and tell me why I am wrong to want them to write reasonable, fluid, and upgradeable code.
<p>
What are you people going to do when perl 6 comes out? Huh?
<p>
what is the sound of one [deprecated|dep] fuming?
<p>--
<br>Laziness, Impatience, Hubris, and <i>Generosity</i>.