in reply to what are all the things to be considered to write a effective perl script or module?

As the old saying goes "first make it run, then make it right, then make it fast".

So code away, and if it becomes too slow for your application, you start to profile, and identify your bottlenecks.

In many cases the choice of good algorithms and data structures buys you more than any micro optimizations.

If you're still interested in micro optimizations, you'll find plenty of them discussed here at the monastery (for example with this search).

  • Comment on Re: what are all the things to be considered to write a effective perl script or module?

Replies are listed 'Best First'.
Re^2: what are all the things to be considered to write a effective perl script or module?
by dHarry (Abbot) on Feb 06, 2009 at 15:03 UTC
    As the old saying goes "first make it run, then make it right, then make it fast"

    I would prefer some sort of design first, preferably gathering requirements before that. Design of test cases to check that the specs are met. Specs that can be traced back to the requirements. Then write the code and test it, test it and test it. If the code does what it is supposed to do only then it is effective.

Re^2: what are all the things to be considered to write a effective perl script or module?
by Herkum (Parson) on Feb 06, 2009 at 15:03 UTC

    That is interesting, I realize I tend to start from 'make it right, then make it run.' My reasoning for this is that I know how I want my code to look and where I want my values to be so I focus on putting things in the 'right' place. So when I have to go make it run I know where all the problems should be. I not saying that I don't have bugs, gods knows that I ain't true, but at least I should a general idea of where the problem is going to be.

    I see too many programs that were written to run first, and never bother going to the second step. The usual explanation being, if it runs, it must be right! :)

      I think that the "first make it run, then make it right" has two purposes: for one thing you can't check whether it's right if it doesn't run, and the second point is that beginners tend to write large pieces of code which is then hard to make run.
      The best approach depends on your problem. But for many problems a very good approach is to start with a running program that does nothing like what you need and then through many iterations make it into the program you want. And when I say a running program, there are occasions when I've started with:
      #! /usr/bin/perl -w use strict; print "Hello, world\n";
      and then evolved it into an entirely unrelated program. (I usually start with a slightly more complex standard template that does things like find the right library path, processes command-line arguments, and has POD stubs.)

      This approach may seem weird but it can work quite well. Particularly if you mix it with test driven development.