Re: CPAN - wheat from the chaff

[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.

[Anonymous Monk]

Possible automatic checks for

Inadvisable

Check for documentation, version and last modification

Superceded

Superceded modules are mentionened in the documentation of the superceding module (as such), not used in the source and not downloaded as often as the superceding module

Submodules

Submodules are used by their parents and start with the name of the parent