in reply to requiremens for CPAN scripts?

Although scripts might potentially be useful to people as-is, it is far more likely that a generic version of the key algorithm(s) you are offering in the form of a module will help other people.

For example, a script that takes two arrays of numbers as I/O input and returns the correlation co-efficient is not as useful as a (callable) module to do the same. This is because, unlike a script, such a module can be reused hundreds of times in sequence or parallel without resorting to a relatively slow I/O interface nor the repeated spawning of a pair of shell and perl processes.

Furthermore, the use of an object-oriented interface permits the use of inheritance so that people can customise outside the box, without having to edit your script. In this way your contribution, if "sexy" enough, would grow in its influence.

One world, one people

Replies are listed 'Best First'.
Re^2: requiremens for CPAN scripts?
by perl-diddler (Chaplain) on Apr 07, 2011 at 19:05 UTC
    I'm not sure how one would make a 'generic' module out of a program like 'top' or 'xosview', (for example).

    They are designed to be run and left running for some time, enabling you to monitor what's going on.

    How would you make that into a module useable by other programs?

      I couldn't find a CPAN script called top - but hypothetically if one exists and does broadly what unix top does: I would say: a script that produces data on top-consuming processes is not as valuable in the longer run as a module that can be inherited and locally augmented to monitor additional information about the processes or to filter the processes on different criteria, e.g. I/O instead of CPU, than what top does - a script has a limited application, a module has no limit.

      One world, one people