Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re: How does one choose among modules?

by clinton (Priest)
on Oct 09, 2007 at 13:16 UTC ( [id://643682]=note: print w/replies, xml ) Need Help??


in reply to How does one choose among modules?

This is a problem that has irked me for a long time, and I have (somewhere in the back of my head) a plan to do something about it... when I get the time ;)

I'm thinking about a meta-CPAN website, with modules classified by functionality, and with all of the data available about each module aggregated into one place (eg CPAN ratings, release frequency, kwalitee, DrHyde's dependency trees)

So maybe the ability to compare a number of modules based on their lists of stated functionality

The classic example is the myriad date/time modules - while the DateTime collection is considered the gold standard, there are a number of other modules that are more light-weight and suited for particular purposes. Or the XML modules. Different modules for different purposes.

Maybe also an interface of "If I want to do X, which modules should I use, and why?"

The problem (other than getting the site built in the first place), is that, in order for it to be useful, it needs a lot of user input. CPAN ratings are useful (if a bit non-specific), but there just aren't that many of them.

Does anybody have any thoughts about this? Something you like? Dislike? What would you like to see?

I may even get around to writing it sometime.

Clint

Replies are listed 'Best First'.
Re^2: How does one choose among modules?
by Mutant (Priest) on Oct 09, 2007 at 14:51 UTC

    I've thought about this sort of thing too. The problem is the only definitive information about a module is it's POD (and code). Unless you try it, or you're very good at reading code, the only way to select a module is by what it's POD claims to do. Those claims may be incorrect, poorly communicated, or mis-understood. Additionally, it may be hard to find a group of comparable modules.

    Various people have tried to solve this problem, with the likes of CPAN Ratings, AnnoCPAN, reviews like those on this site, etc. The problem is, it's easy for someone to completely miss all those. They may just do a quick search in the CPAN shell, browse some PODs, and install one or two that look reasonable. Maybe they don't install properly on their system, maybe they don't work as advertised, maybe they don't quite meet the current needs. All these things can waste a lot of time - our most valuable development resource.

    I think ratings, reviews, categories, etc. are definitely moving in the right direction. But I think they need to be centralised in some way. The obvious answer is to build these things into CPAN. Then they're available no matter how you access it

    OK, that may be a lot of work, and maybe even impractical, but to me, that's the "ideal" solution to this problem.

      Agreed - it should all be in CPAN. The only reasons I suggest building a new site are:
      • to test out the idea without bringing CPAN down
      • easier to write new code with full access rather than having limited access to the code running CPAN (and I have no idea what state that is in)
      • can experiment with ideas without annoying CPAN users with a changing interface

      If the site proved it's worth, I would expect it to be integrated into CPAN, or at least for CPAN to provide a link to the module's page on this site.

      The problem is the only definitive information about a module is it's POD (and code). Unless you try it, or you're very good at reading code, the only way to select a module is by what it's POD claims to do. Those claims may be incorrect, poorly communicated, or mis-understood.
      I wouldn't even attempt to extract this information manually. I'm thinking more of wiki-style access (though maybe less free-form). I'm brain-dumping here, but how about a tree of "features", eg:
      Date/Time |_ understand time zones |_ converts from RTF 1234 format
      So the process would be:
      • User finds module, wants to add Feature X
      • Clicks : Edit feature list
      • available features contains Feature X
        • Y: select Feature X
        • N: Add new feature
      • Adds a rating 1-5 for that feature
      Another user can:
      • Select 5 modules to compare
      • Site displays a table listing the union of all mentioned features of all the compared modules
      • Modules missing a ranking for a feature displays [unknown] instead
      • User has the ability to rank the [unknown]s
      A feature-finder could be implemented from the same data, so you can add required or optional features from the feature tree, and the returned module list would be filtered (and ranked) to show those that support said features.

      As I said, just a brain dump, but may have value. Any more ideas?

      Clint

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://643682]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others studying the Monastery: (4)
As of 2024-04-23 23:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found