CPAN - wheat from the chaff

[jfrm]

Dear venerable brothers,

Although the virtually compulsory usefulness of CPAN is obvious 2 things strike me:

1. There are loads of sub-modules that are only used by their parent modules - these would never be used by themselves.

2. Some modules are critical, well loved and/or development is ongoing. Other modules are old and no longer recommended (e.g. I understand Rose:DB:Object and DBIx have kind of replaced Class::DBI) or used much. Some modules are obviously no longer supported. I suspect that some modules may also be posted by amateurs such as myself and should therefore have a health warning against them.

What this means is that when listing the modules, all the important critical/well loved modules are obscured by all the other sub-modules and modules that I probably don't want to know about.

So, the question is obvious: How do I see a list of only the important and proven modules?

I have no doubt that I'm not using all the modules I should be but then I don't know what's out there. Going through the complete list of modules finding out what they all do would take to much time. I would like to go through a list of the wheat without the chaff. Any suggestions?

thanks for your wise utterings.

[davorg]

You might find the CPAN Ratings site or CPANTS useful. They both address slightly different aspects of the CPAN "quality" issue.

[holli]

Have a look at the Phalanx project.

[petdance]

Phalanx only measures what's downloaded a lot. It does nothing as far as quality.

[ForgotPasswordAgain]

There was a thread on this a couple weeks ago, Section proposal: Best CPAN Modules , where the original poster even used the same "separating the wheat from the chaff" metaphor that you did..

[ptum]

Heh. Except as I amended, the word 'chaff' is too harsh for most CPAN modules. As I am currently on a diet that encourages more complex grains, I suggested that the metaphor might be amended to 'separating the wheat from the quinoa' or perhaps even flax, teff, or brown rice.

I kept meaning to get back to this topic, because I didn't think we ever reached a consensus on what to do (if anything). There was a lot of support for samtregar's Don't hamstring CPAN post which resisted any attempted ranking of modules for fear that such a system might stifle competition.

So, as Inigo Montoya once said, "Let me sum up."

There seemed to be considerable support for the following courses of action:

• Do nothing. CPAN modules are usually 'best' for the specific job for which they were designed ... the 'best' tool for a particular job is the tool that was designed for that job. Few CPAN modules stand out above the rest, and those that do are so commonly used that a ranking system is useless.
• Enhance the existing Module Review section so that modules could be displayed in some sort of ranked order of usefulness for a particular task. I personally liked the idea of categorizing the modules into sections (as in Categorized Questions and Answers and showing a list of 'getting started' modules in each category.
• Grandfather mentioned that one way to judge the popularity of modules would be to determine how many times they were referenced in PerlMonks posts. That might be a good place to start in creating a 'getting started' list of modules for frequently-encountered problems.
• One thing I took away from the earlier discussion was a determination to write at least one good review of a module I used. Sadly, I haven't yet acted on that intention ... but if enough of us did, it might encourage a reorganization of the Module Reviews section here in the monastery.

What do you think we should do?

[jfrm]

Well, I agree that it is an important question as it is just this sort of issue that can put off potential PERL converts before they get involved.

Naturally, I'm not keen on the "nothing" idea or I wouldn't have asked the question. The Module Review sounds like one of those ideas that is fine in theory but unlikely to work in practice as it sounds like it would require a lot of startup and ongoing work.

The popularity of something is not necessarily a good indicator that it's the best thing to use so I'd suggest this is not the right road.

I don't think I quite agree with the comment on chaff. Of course one man's chaff is another's wheat but, if we agree that the word chaff should be replaced with something less contentious - then there are certainly still modules that I (and as I'm a fairly typical semi-competent developer, I expect I speak for many) don't want to see when searching and they are easily categorised into 3 types
1. "inadvisable" modules (poorly written, no support, not cross-platform etc.) 2. modules that have been largely superceded by something else for most general purposes. 3. modules that are to all intents and purposes only used as submodules and are not useful by themselves.

I'm not sure any of the proposed courses of action would give me this TBH. But the categorised Q&A would meet the requirement without too much additional work so may be a good compromise.

[swampyankee]

One of my cruder rating parameters is the documentation. If it's not complete enough to use, i.e., with listings of methods (or subs), reasonable explanations, reasonably well written (no grotesque misspellings, reasonable grammar, etc), I figure that an author who couldn't be bothered with decent documentation couldn't be bothered with decent testing, and the module is in the category of "probably dross".

[johnnywang]

All the above mentioned projects (reviews, etc.) are great, but the require hardwork from many, so might be difficult to be successful(of course, there are counter examples: wikipedia). I'm thinking that just a simple vote-like page might do the trick, say a page in perlmonks so that any logged in user can put in the modules they use (and like to recommend), this will produce a list based on usage. This might work, since we monks all manage to find time for the Voting Booth after all. Of couse, someone needs to do that work also, damn, why isn't any good thing free.

[chrism01]

I'd really like to see a system of some kind that described which modules are up to date/working. Like most people, I don't have time to keep installing/trying modules one at a time to find out.
Ditto the comment about wanting good documentation (above) eg method defs and examples.
1 example is worth a paragraph of explanation.
PS: I really do like CPAN generally though.

[bibliophile]

Just a random thought - what if there were a spot on each monks home node to list the 5 (or 10, or whatever) CPAN modules that they use most frequently?

You'd get a good idea of what are 'good' modules by looking at the more experienced monks' nodes.

It would also be possible (I suspect) for PM gods to pull some kind of weighted report out of all the home nodes...

Participation would, of course, be completely voluntary. :-)

[ff]

How about do like public broadcasting: Every six months, access to Perlmonks is suspended until you fill out a little survey describing your interest/satisfaction with CPAN modules. Input required would be minimal (though allow for maximal), and you could fill out the survey in advance of the "suspension" day in order to avoid such a jolt. :-)

[Anonymous Monk]

(e.g. I understand Rose:DB:Object and DBIx have kind of replaced Class::DBI)

Its a good idea to avoid statements like that.

[doom]

(e.g. I understand Rose:DB:Object and DBIx have kind of replaced Class::DBI)

Its a good idea to avoid statements like that.

Why, because someone might haul you into court?

Class::DBI vs DBIx::Class is a good example of why frequency of mention isn't a good gauge of actual popularity, because these days Class::DBI may be mentioned a lot, but the context is usually "don't use this".

Myself I'm skeptical of the concept of ORM software, and if I thought people were tracking mentions of modules I'd have to start using circumloqutions when citing examples ("the CPAN package whose name I will not mention but is spelled C-l-a-s-s::D-B-I").