|Problems? Is your data what you think it is?|
Re^4: How a script becomes a moduleby dragonchild (Archbishop)
|on Oct 11, 2004 at 03:02 UTC||Need Help??|
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.
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.
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?
Being right, does not endow the right to be rude; politeness costs nothing.