Re^4: How a script becomes a module

[dragonchild]

Dude, you do realize you're preaching to the one of the 12 Apostles, right? You really need to read up on the history of Perl. And, it's not just history.

I've spoken in the past about Fortune 500 companies using Perl. Most of them don't even realize they're using Perl. Why not?

Well, it has to do with the fact that there are no Perl applications. But, most of all the lines of Perl in this world are in little quick'n'dirty scripts that keep databases running, load / generate datafeeds, and do other general maintenance on over 100 types of systems.

Would it be better if they were all designed as "a simple module with a simple interface"? Of course. Yet, doing that would actually be detrimental ... for a number of reasons.

• If it ain't broke, don't fix it. Every single code change needs to be tested. Code changes on the level you are proposing require complete retesting. That's dangerous.
• Code changes on the level you propose are very expensive. You're talking about man-months. Many man-months. Just to make things "pretty".

Of course, you're assuming that these scripts will ever need changing. Many of these scripts are run exactly once. Most of the rest will be used in exactly one place. Let me give you an example. It's a shell script, but it's meant to do something Perlish.

#!/bin/sh

for file in $*
do
    echo "$file"
    perl -pi -e 's!\t(?=\t|$)!\t\\N!g;s#\\(?!N)#\\\\#g' $file
done

I use it to cleanup files that I export from Oracle so that they're ready for importation into MySQL. The data importation process is a temporary process, meant to exist for less than a year. I'll probably be able to retire it in less than three years. But, I'm not going to use this anywhere else. Ever. If I do, I'll copy it. I still have to create the stub, so why go through all the trappings?