Re^2: How does one choose among modules?

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.

Comment on Re^2: How does one choose among modules?

Replies are listed 'Best First'.
Re^3: How does one choose among modules? by clinton (Priest) on Oct 09, 2007 at 15:13 UTC
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` [download] 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	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: How does one choose among modules?
by clinton (Priest) on Oct 09, 2007 at 15:13 UTC

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.


    Date/Time 
     |_ understand time zones
     |_ converts from RTF 1234 format
[download]

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

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

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

Clint

[reply]
[d/l]
[select]