the perils of others' perl - a cautionary tail...

I'm a consultant. I often talk to people and offer to write scripts for them. It has never yet been an issue. 9 times out of 10, they simply want output parsed and placed into one of the products my company sells or somehow combined with other information to make the output more informative. Week before last, someone asked if I could take the output of something they have and put it into our product. "No problem" quoth I. "What is it you have?" "A perl script," they replied. Of course, I said I'd just re-write it and make it output the way we discussed.

Wow. All I can say was wow. Never before had I seen such a beast as this. To pull apart a file, they have used a `` call to cat with five pipes through grep. They dump this into a plain array. That's just how it starts. I count 35 system pipes through the whole script. I shudder to think how long this must take to run. I had to read through it 7 or 8 times just to understand it. Basically, it appears to be written by somene reasonably proficcient in Unix, but either just learning or not knowing perl.

All I can say is always ask to see the script you think you can re-write in seconds before you offer - else be stuck like me spending Sunday picking it apart with forceps just to see where all the parts are...

Comment on the perils of others' perl - a cautionary tail...

Replies are listed 'Best First'.
Re: the perils of others' perl - a cautionary tail... by perrin (Chancellor) on Mar 10, 2002 at 18:53 UTC
As a quick and dirty rule for evaluation of how nasty someone else's code is, I think it's safe to assume that any script which doesn't use strict and warnings and have at least some attempt at reasonable legibility (i.e. indentation) is going to take a lot more work. It's not even because strict will prevent you from doing terrible things, but rather because people who know enough to use strict generally know enough to avoid the worst problems.	[reply]
Re: the perils of others' perl - a cautionary tail... by particle (Vicar) on Mar 10, 2002 at 16:08 UTC
ick. i'm in a similar position to you, and make similar offers to clients. i hope i never see a script like the one you've come across. also, i hope you are able to successfully suggest to your clients interested in perl that they make use of the resources available to them, like CPAN, c.l.p.m, and perlmonks. i've had many thank-you's for pointing clients to the resources i regularly use to make my work ~~easier~~ possible. ~Particle ;Þ	[reply]
Re: the perils of others' perl - a cautionary tail... by mojotoad (Monsignor) on Mar 11, 2002 at 01:39 UTC
Based on your description, it sounds like there are significant gains to be made in efficiency and speed by rewriting. I'm interested in a follow-up -- can you give us some simple benchmarks when you are done, such as old size, new size, prior system calls, new system calls, and best of all, performance on a moderate data set? Not only would such a magnanimous post generate cascading blankets of appreciative warmth from your fellow monks, the excercise might give you some impressive "bonus" information to pass along to the client in question, information that might make you stand out when they cast around for future contracts. Uh, that of course assumes that the decision-maker at the client shop is not the original author of the script with a fragile ego to boot. ;-) Matt	[reply]
Re: the perils of others' perl - a cautionary tail... by Trimbach (Curate) on Mar 11, 2002 at 12:49 UTC
Wow that's impressive... 35 system pipes? Ouch. I was once contracted to make some minor modifications to an existing (in production) web auction script. The changes the client wanted were pretty minor (some DBI changes to make the SQL more agnostic, plus some minor output changes) so I said "sure!" Problem was, the script was actually approx. 200 little scripts and config files, all them calling one another in a huge rats nest of global variables (everything was global), remote sub calls (sub A in file A calling sub B in file B, which in turn calls sub C in file C, all brought in using "use" with no scoping), etc. I spent two days trying to wrap my brain around it before I gave up. Insane. Needless to say I am now much more cautious before I commit to modifiying large codebases... even little changes can be a nightmare if the code is bad enough. Gary Blackburn Trained Killer	[reply]
Re: the perils of others' perl - a cautionary tail... by metadoktor (Hermit) on Mar 10, 2002 at 16:20 UTC
Sounds like you need a badperl2goodperl module. ;) metadoktor "The doktor is in."	[reply]
Re: the perils of others' perl - a cautionary tail... by shotgunefx (Parson) on Mar 11, 2002 at 23:19 UTC
Whenever I'm approached about others code, I treat it like a plumber would. I assume that lurking beneath the surface is a "Rube Goldberg". I won't quote anything without a look through (even though you can still get suprised). If it looks that nasty, I can tell them I can rewrite it. If it's that convoluted, it's usually quicker. -Lee "To be civilized is to deny one's nature."	[reply]
Re: the perils of others' perl - a cautionary tail... by claree0 (Hermit) on Mar 11, 2002 at 22:37 UTC
Oh dear - it sounds very much like some of my early code. While I know better now (and a script will finish on the same day I started running it!), I know that there are some of the 'originals' waiting to bite me when I'm least expecting it. The moral - yes, it sucks, but it's even worse when you're having to unravel your own code!	[reply]