in reply to Should I upload it on CPAN?

The trick with publishing non-modular software to CPAN, is to pull out as much code as possible into modules, and narrow the "script" part of it down to a few lines.

As an example... I developed a script called reprove as a result of a discussion in this monastery. I got the script itself down to just two lines of code. The bulk of the code is in Module::Reprove, while App::Reprove handles command-line processing, output to the terminal, etc.

Replies are listed 'Best First'.
Re^2: Should I upload it on CPAN?
by BrowserUk (Patriarch) on Feb 23, 2012 at 00:05 UTC
    I got the script itself down to just two lines of code. The bulk of the code is in Module::Reprove, while App::Reprove handles command-line processing, output to the terminal, etc.

    Are either of those two modules useful for anything standalone?

    If, as I suspect, the answer is no, then what the &%&^%&^ is the point of making them separate modules?

    And what is the point of a 3 line script?

    It's like saying you've built a personal flying machine that only weights 20 kgs. You just put it on and board any jet that going where you want to go.

    It's this kind of pseud-OO bullshit that makes CPAN a pain to use.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

    The start of some sanity?
[reply]
      And what is the point of a 3 line script?

      I used to think that too, but I've moved more and more of my programs into modules and used wrapper scripts to invoke them with the most common arguments already defined. It's improved the testability and usability of a lot of my code. Otherwise I ended up with a lot of shell aliases to invoke modules—and there's not much documentation there.

[reply]

        Let's see.

        2 modules; 2 namespaces; and two hundred and eighty eight support modules:

        <Reveal this spoiler or all in this thread<!--
        Read more... (10 kB)

        To create a 3 line script that downloads 2 files, constructs a single object and calls a single method upon it -- Ie. Calls one function passing some parameters.

        And when it goes wrong, no one knows how to fix it. If that's modern Perl, you can keep it.

        Isn't it amazing how technology is giving us ever more powerful ways of creating unbelievable (and unintelligible) complexity from simplicity.

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

        The start of some sanity?
[reply]
[d/l]

      Module::Reprove certainly is. App::Reprove probably less so. But a good reason to modularise code is to make it extendable using the well-understood mechanism of inheritance.

[reply]

In Section Seekers of Perl Wisdom