OK... Here I am, sharing my not-always-popular opinions. First of all, I would like to point out that I HATE using the term script when referring to any programming I write. I will try to always use the term program because no matter what the intent or the size of the project we have, it still involves programming. It also helps to legitimize the use of Perl and other 'scripting' languages to others.

When I first started writing perl programs, I would write a small program to perform a specific task or set of tasks and then forget about it. I guess this is fine if we were only to use it once but this never seems to be the case. I would often find myself, about two or three months later, looking for this now obcure little program that I wrote and hoping that I didn't throw it out because I need it again to perform a similar task. After about a year or so of programming in this way (yes, I'm a slow learner) I decided that I should build a library of these utilities that I can use them whenever I needed to. This made it much easier for me to find them and I also found that I was using them more often because I was able to find them so easily. Every time I would write something new, I would place it in my library and have it ready for the next time I wanted to use it.

This led me to the next step:
I took about two weeks and converted my little utilities into modules, sometime combining several that were related into one package. This was the point where I took a giant leap in my knowledge of Perl and my appreciation for the efforts that others had put into their modules.

I guess the moral of the story here is that there is no such thing as a one-off. You will never write a program that will be used only once. Always write it as though you were going to use it many times and keep it handy so that you can find it and use it.

Does everyone here do this? Did it take me longer than most to realize what was definitely a timesaver?


Replies are listed 'Best First'.
Re: The Illusion of One-Offs
by footpad (Abbot) on Aug 16, 2001 at 20:59 UTC

    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.


      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. :-)

Re: The Illusion of One-Offs
by dga (Hermit) on Aug 16, 2001 at 20:55 UTC

    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.

Re (tilly) 1: The Illusion of One-Offs
by tilly (Archbishop) on Aug 16, 2001 at 20:43 UTC
    My rule of thumb is that if it takes me more than 15 minutes to write, it is no longer a one-off, and if it takes more than 5 then it already probably isn't a one-off.

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

Re: The Illusion of One-Offs
by perrin (Chancellor) on Aug 16, 2001 at 19:55 UTC
    This is well said, mrmick. If you get into the habit of always coding with -w and 'use strict;', it will become second-nature and make things a lot easier when you take on a bigger programming challenge. It is also well worth it to make the jump from a bunch of random .pl files to modules with package names. It's not a difficult jump, and it will pay off big if you ever want to use any of this stuff under mod_perl or in any large project where subroutine names might otherwise conflict.

    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.

Re: The Illusion of One-Offs
by E-Bitch (Pilgrim) on Aug 16, 2001 at 19:23 UTC
    Actually, mrmick, I'm still in your previous stage. I have only known perl for about 3 months or so, and am just beginning to realize what you just mentioned. Do you have any advice from your trials and tribulations? I still have yet to learn packages (who needs to write one when you are only using the program once :) )
    Tempora Mutantur Nos et Mutamur in Illis
    "The Times are Changed Even as We are Changed in Them"
      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.

(jeffa) Re: The Illusion of One-Offs
by jeffa (Bishop) on Aug 17, 2001 at 01:30 UTC
    Actually, i have been enjoying the art of writing programs and then throwing them away - the goal being to practice having to remember 'how to do it' without having to RTFM or ask someone else.

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


        A flute with no holes is not a flute . . .
    a doughnut with no holes is a danish.
                                    - Basho,
                                      famous philosopher
Re: The Illusion of One-Offs
by Hanamaki (Chaplain) on Aug 16, 2001 at 21:04 UTC
    Getting oneself organized is a big hazzle and I have always envied this people who handle Filofaxes, mountains of paper and computer files with ease. I know there are CVS and all that stuff you can use for tasks beyond programming but I still have files like "paper.draft" "paper. new", "", "paper.endversion", "paper.done" etc. pp.
    A Nightmare!!!

    Fortunately, there is one place I am organized: Perl.
    Thanks to Perl I was educated to have a ":lib" and a "site_perl". Exploring the ":lib" and CPAN helped me to get much more organized and to get a feeling for classification.
    I throw away a lot of Programms I wrote for "one-time" use and usually I do not regret it. These little Data Munging programms are faster written than remembered as already (partly) written.
    On the other hand, If I write a function I know I have to use again, or find a nice little function here on perlmonks, in books, newsgroups etc. I will more or less copy and paste it into one of my categorized "Hanamaki::" moduls. Of course some bigger scripts will become modules on their own.

Re: The Illusion of One-Offs
by Ri-Del (Friar) on Aug 17, 2001 at 00:46 UTC
    I have to completely agree concerning the Illusion of One-Offs. In another (shudder) language I was using this summer for an internship, I came to the same conclusion. It became apparent that much of what I was writing could be combined into a simple module/object and reused in whatever section of the program that I was working in. By abstracting the program to be able to handle general situations rather than distinct individual ones, I began to think of Turing and his early computational machines, and how he wanted to develop a general machine that would take any sort of algorithm, and that's when I realized that this is actually a fundamental part of computers that each of us deals with at both high and low levels. Our entire experience is mediated by a constant abstraction. Perl itself is an abstraction that greatly simplifies our tasks. Imagine having to do in machine code what we do with Perl.
    In the end the very language we are communicating with seems to be an abstraction of the actual concepts. When each of us uses a word to describe something we are not in actuality describing it to the fullness of its nature, but rather using a name to identify a concept. It is this fundamental principal that seems to be ever evolving in the languages we use to program (be they scripts or programs =) or the manner in which we program ourselves. That's a cool thought provoking idea you have there mrmick.
Re: The Illusion of One-Offs
by hsmyers (Canon) on Aug 17, 2001 at 01:19 UTC
    For me there is a sort of natural progression in all of this. For instance, I generally can't stand to duplicate a line of code unless I really have to. An obvious rule says that if you have to do the same thing from more than one place, make it a function. If you abstract this to the level of .pl files, then you can't really think of any of your code as throw-away. Same rule here says that if you use it more than once make it a module! O-O if you like, but re-use is your friend here.

    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.

Re: The Illusion of One-Offs
by Anonymous Monk on Aug 17, 2001 at 23:32 UTC
    Doing this is certainly sensible, and whilst I am semi-sensible, a coder should feel no obligation to do likewise. TMTOWTDI.
      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.