If I always wanted to write modules, I'd use Java. Perl is useful because I don't have to write a bunch of code to get something done.

If you don't write a lot of scripts, this might not seem like a big deal to you. I'm not going to spend the extra time on the majority of my one-offs and quick and dirty scripts because I'm not going to use them again. I'm more interested in getting work done then spending quality time with my keyboard.

As for planning one from the start, may we all live in such a perfect world. Unfortunately, not everyone does, and pretending so ignores a great many people who could use a map to better code.

I buy that.

But it's not a far stretch to use very very light-weight classes and use a simple hash for the properties until you need something more. This is an entire class in a small steal-entries-from-http://buzz.bazooka.se/-and-fake-email-posts-to-our-internal-bullshit-list-at-work program I wrote for the fun of it after a coffe break discussion:

package Buzz::Post::Comment;
use HTML::Entities;

sub new { my $pkg = shift;
    bless(my $self = { @_ }, $pkg);

    $self->{text} =~ s{<br />}{\n}gs;
    $self->{text} = decode_entities($self->{text});

    return($self);
}
[download]

It's not really a serious class in that you can't see what properties there are, there is no documentation, no visible interface to new() etc.

But the benefits I get are:

• No hassle, it's almost like just using a hash
• OO thinking, which is the way I work
• A good name. That's always worth a lot
• Somewhere to put my methods instead of in the pile of subs

Basically it's the same laid-back scripting attitude, but with a touch of structure.

/J

Unfortunately, not everyone does, and pretending so ingores a great many people who could use a map to better code.

<Are You>You've just attempted to call me a java-lover???</Talking To Me Voice>

A simple module with a simple interface is reusable elsewhere and is (sometimes) partially self documenting. If you want to write "dirty" scripts, fine, but I don't think dirty has a place -- except in mountain biking. Maybe that's because I ship my software to places, other people use it, or it runs several thousand times -- true -- but for dirty stuff people don't need lofty long-winded meditations on PerlMonks anyway. Even a simple database fixup trick can be reused -- and a module allows it to be reused by code as well as by a system call. Cool. So in those cases, write a simple module, it takes an extra 1 minute TOPS and write a one liner to call it. Big deal.

A little bit of discipline, just a little bit, is a good thing, and I don't think the ability to avoid using strict is a feature, nor do I think the ability to avoid writing packages (I did not say OO objects) is neccessarily a feature. I use Perl because it is powerful, not because it is clean.

Maintaince of even the smallest scripts is important, as is readibility, else you accumulate bugs and allow yourselves to be sloppy. I don't want a hand-holding language like Java, I abhor it, but getting yourself into the practice of writing modules, even for small scripts, is good -- because doing it right the first time is better than having to go back and fix it three times over.

Having to keep fixing an initially broken design is what is wrong with the refactoring concept. Yes, sometimes you have to do things that way, but you should also be aware of how to do it right the first time, or at least get close. Dirty-scripts are not an ideal genesis for anything, so I chose not to create them. Forgive me if I have a different opinion than you, but you are not the only one here.

If I'm derailing people who "could use a map", maybe it's because I'm speaking of a bigger picture. Those folks can read to. I think you underestimate the audience of PerlMonks in their ability to think for themselves. I spoke of my personal technique, if you chose not to use it -- fine -- but I wouldn't go saying my views are wrong or counter productive, or that I'm pretending anything. Mine is not a high horse...

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
[download]

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.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.