Counting mentions is okay, I guess, but there can be cases where something is just "famously bad", so that basing a decision on statistics alone would be unfortunate.

For the programmer facing the need to solve a problem, I don't think there's much we can expect in terms of avoiding an ad-hoc approach, but when it comes to breaking into a territory where numerous CPAN modules have already gone before, there is a progression of steps that should lead (more or less directly) to a good choice:

  1. Compare documentation for readability: if a module's description of usage is hard to understand, you'll probably have trouble using it; if the explanations are clear and well organized with suitable attention to detail, there's a good chance the code was written the same way. **

  2. Compare documentation for relevance to your task: among the modules whose descriptions you find readable, you'll see different ideas about how to approach the underlying problems, different ways of organizing resources, even different assumptions about the goals and constraints of the caller's application. Sometimes you'll pick a module because it fits well with what you're doing, and sometimes you'll rethink what you're doing to fit a module that looks good to you.

  3. Compare documentation for ... (what can we call it?) "dedication" or "gravitas" or "grown-upness" or ... : check for things like depth of revision history, references to published standards or RFC's, and maybe just some subjective "gestalt" sense about whether the module author really "gets it".

  4. Once you have a ranked list based on reading the docs, the next hurdle is ease of installation. Usually this isn't really a discriminator -- the majority of modules install easily -- but if your first choice turns out to depend on half a dozen other modules that you didn't think would be relevant (and that you haven't thought to review yet), and especially if one or more of those modules happen to fail "make test", you might consider moving on to the next candidate.

But let's face it -- a lot of us would just rather go to PerlMonks and post a SoPW node or mention a question in the CB, and there's nothing wrong with that, except maybe that we still end up (as often as not) with a lot of alternatives to choose from, and we're back to step 1.

** update: My apologies about that first point... it may have come across as being "Anglocentric" or prejudicial against excellent programmers who have better things to do than beat their heads against English grammar. I want to be clear that I'm talking about how specifications are outlined and how sample code is shown -- not about correct spelling, verb tenses, plurals or even sentence word order. If the docs are hard to follow because of limited English skills, it's worth looking at the code to see whether it's just a problem with English, and not a problem with logic.

For better or worse, Perl is a language dominated by English, but putting aside its function names and reserved words, its flexible syntax should seem fairly "familiar" to speakers of any human language, given an adequate amount of formal education.

In reply to Re: How does one choose among modules? by graff
in thread How does one choose among modules? by mr_mischief

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.