Well, I wouldn't call this unpopular; I'd call it the natural evolution of a programmer learning to be pragmatic. The Three Virtues can be applied to any programming language, discipline, or environment. (They can even be applied to other forms of creative problem-solving.) After all, you just described Laziness in action.

I do disagree with the use of script, though probably for the same reasons you avoid it. After all, would you call Javascript rollovers a program? They certainly require the same sort of research, discipline, and testing that "programs" do, but I think you'd run into a certain amount of resistance from others (generally non-IT people) if you insisted on calling them programs. (Indeed, I think the general response might be "What-ever.") Similarly, certain folks insist on calling .CGI files "scripts" no matter how involved.

Now, that's not to say you can't think of them and treat them as programs. That's just discipline. My point being that you should think of them as whatever you want, but use terminology appropriate for your audience. There are few things more annoying (to me, at any rate) than folks who insist you adopt their mental model about something.

I realize you didn't do that and I'm not saying you do or did. I'm just pointing out that no matter what you personally think about something, you need to communicate with others that have different opinions and experiences. All too often, many holding strong ideas and opinions are not receptive to other points of view. I believe it's far wiser to hold your ideas and to allow others to hold theirs. (Who knows? They just might be onto something.) Thus, it seems wise to allow others to develop their own opinions and to adapt to those opinions as needed. Educate as needed; ignore as necessary. But never give up hope that others will learn from your successes and approaches. Similarly, you shouldn't be afraid to grow from someone else's ideas.

Speaking of learning from your successes, have you given thought to uploading selected bits from your library? Not only would you get feedback, but it's likely that others would find them useful, educational, and interesting. Perhaps not, but it shouldn't hurt.

And, finally, I do agree that there are far fewer "one-off's" than most people realize. Heck, I've even take code used to learn the behavior of a given feature and plopped it straight into a production app. You should always give a certain amount of thought toward the possibility of reuse. Don't carry it too far, but at least consider it.

--f

footpad says:
Speaking of learning from your successes, have you given thought to uploading selected bits from your library?

I would really like to but they are mostly a collection of mandane little tasks that I'm simply too lazy to do over and over again. :-)

Also, there are things in many of them that I would not be permitted to share with anyone outside the corporation. Therefore, I really don't own them. Non-disclosure agreements are definitely binding. :-)

Mick

I believe you are reaching for one of the three primary Perl virtues, laziness. This would be to never rewrite something you already wrote once before. I seek one day to be at one with all of the virtues but still have attained none of them to any great degree.

May your path to enlightenment be fulfilling.

Your fellow traveller on the path to Perlvana.

OTOH if I have created the right libraries for myself, then I can get a lot done in 5 minutes. :-)

This is one of the nicest things about learning Perl: it's easy to take it one step at a time.

Thanks perrin,
All of my modules here are with package names and most are OO Modules, thanks to Damian Conway's book, Object Oriented Perl.
Mick

At first, when I realized that my programs were going into 'outer space', I moved everything named *.pl into a single directory so I would know where everything was. After this, when I needed the program again, I would modify it so thqt it could be called from other Perl programs and do what I needed it to do. After a while, it became evident that I needed to document what was there so I creted a little text document to tell me which program did a particular function for me. This was before I learned POD. :-)

There are better ways to organize what you have... just find the one that works for you.

Mick

This, of course, is not at all practical - but i find it does improve my 'improvisation' skills. :)

jeffa

    A flute with no holes is not a flute . . .
a doughnut with no holes is a danish.
                                - Basho,
                                  famous philosopher

There is another idea that comes to mind. From the point of view of craftsmanship, your code should be the best you can make it. It would be better to think of it staying around forever (given the number of 'prototypes' that ship, this is all to real) rather than heading for the bit bucket--even if true. If coding is done with the idea of one-of, it is all to easy to let that slip into 'knock off' or worse.

I beg to differ with what is implied by many of my estemed seniors.

The conventional wisdom is that you should code anticpating future requirements. It is assumed that extra work now will save future work. It is thought to be cheaper to add features during design than it is during testing or maintenance

The extreme programming people disagree. They argue that anticipating features is a waste of time because you will guess wrong most of the time.

If you assume that planning ahead pays off, you are inclined to remember all the times that planning paid. You are less inclined to remember the times the up front costs were not recovered.

The XP way is to code only as much complexity as you need right now. If you can get by with csv files now, don't install Oracle.

This is not to say that you shouldn't save your simple good-enough-for-now programs. When (if) the time comes to put them to new purposes, spend the energy to make them more complex (general)

The XP religion doesn't require the faithful to pile spaghetti on top of spaghetti. "Good enough for now." alone probably won't work well. There are other XP principles (build the test code first, program in pairs, talk to the customers, revise and improve whenever possible, etc) that keep things in balance.