Re^2: CPAN - wheat from the chaff

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?

Comment on Re^2: CPAN - wheat from the chaff

Replies are listed 'Best First'.
Re^3: CPAN - wheat from the chaff by jfrm (Monk) on Aug 21, 2006 at 23:04 UTC
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.	[reply]
Re^4: CPAN - wheat from the chaff by Anonymous Monk on Aug 22, 2006 at 12:29 UTC
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 `use`d in the source and not downloaded as often as the superceding module Submodules Submodules are `use`d by their parents and start with the name of the parent	[reply] [d/l] [select]
Re^5: CPAN - wheat from the chaff by jfrm (Monk) on Aug 23, 2006 at 16:10 UTC
Yes, these are good tests. I'm not sure if you're meaning that we should try to automate them or I should just spend time doing them manually. If it's the latter, while what you say is true, it misses my point which is that it would be a lot more efficient to just have a list of the "good" (sorry to be contentious again, let me call them "key") modules. For example: I want to do object database work. Here is my vision: I spend 10 mins looking through the list of "good" modules/libraries (whatever you want to call them) and see that either Rose or DBIx are the currently recommended starting places. Here is the status quo: I spend a couple of hours searching the Internet and perl monks and CPAN and find that there's a well-used module called Class::DBI. I spend half a day reading the documenation and tinkering with it and realise it's OK. I then post a couple of questions re implementation. Another half a day later, someone points out to me that Rose and DBIx would be a better bet. I spend another 2 or 3 hours trying to ascertain the truth of this, reading their documentation to see if it's good and nothing is deprecated and reading comparison reviews before finally realising that indeed I should switch to Rose or DBIx. I prefer my 10 minute vision to the "days of wasted time" scenario. The only part about this is that isn't true is the fact that the "days of wasted time" scenario isn't an example - it's the reality that happened to me last week. It's also about the third time that I have been through a similar frustrating process when after different modules. Probably some readers at this point are thinking "what a dork - he should have done this or realised that" Well, I realise that I am not an expert developer but I'm not especially stupid either. CPAN is all about not wasting people's time - resuable software is about not wasting time. So, my question is this - why does the CPAN index waste so much of my time?!	[reply]
Re^6: CPAN - wheat from the chaff by ww (Archbishop) on Aug 23, 2006 at 16:18 UTC


Your skill will accomplish what the force of many cannot
	PerlMonks