Sure, sometimes this is bad for the individual - inexperienced users sometimes make bad decisions and pick something unstable - but it's good for CPAN as a whole. And with time users of CPAN learn to find the right module for a given task, on a given day.

Ask yourself this, would DBI be where it is today if oraperl had been listed on the opening page as the "Best way to Program Oracle with Perl"? Would Text::CSV_XS be so bitchin' if every search for "csv" on search.cpan.org terminated in a recommendation for Text::CSV? Of course you're not suggesting either of these, but I think the motivation is similar, as is the likely result.

I've always thought the CPAN FAQ on a closely related topic had a great response - it simply points to this page:

    http://xxx.lanl.gov/help/faq/statfaq

-sam

Actually CPAN modules are already ranked - by how often they are mentioned on PM for a start. Popular modules are simply, more popular. That doesn't mean that they are best, for some value of best, just that they are more popular.

That is good news for someone looking to solve a problem. Popular choices are often easy to find out about and once found are easy to get information about. It's bad news for new modules that may do a better job than the current popular module for the job but haven't yet reached user critical mass - i.e., become popular.

Having a cohesive section that lists the popular modules and a discussion of each module allows the best of both if the discussion can provide links to up and coming solutions to the same problem the module under discussion solves.

You never know, with such a section Data::Dump::Streamer may even become more popular than Data::Dumper.

---

DWIM is Perl's answer to Gödel

Wow, I had not really thought out the philosophical implications of a ranking system for modules -- thanks for your insight.

While it is certainly true that PerlMonks is the center of the intellectual universe, I can't help but wonder if your concern might be overblown. Listing of a module in a PerlMonks 'Best Modules' list seems more likely to generate competition than to suppress it, if I am correct in my assessment of many of our local monks.

I can imagine CPAN contributors flocking to PerlMonks and shamelessly promoting their modules through RFC posts in search of the fame and fortune that will naturally result from being included on our list. :)


No good deed goes unpunished. -- (attributed to) Oscar Wilde

Read The Zen of Comprehensive Archive Networks sometime.

Makeshifts last the longest.

Don't forget that 3 of the 4 nodes sited by the OP were talking about helping relative beginners. Yes PM is for helping eachother in general, but I think it has a special mission to help those who are beginning to find their way, whether in Perl generally, or in some area that's new for them.

As grandfather points out in his node further down, most modules are best for something. I agree, it could hamstring innovation to pre-choose a list of "best" modules (going well beyond a set of reviews of module). Let's keep the variety for those who can best make use of it, but provide help to those who would be overwhelmed by it. Each area has one or two modules that go a little easy on beginners and occasional users, usually nat the expense of features, performance or flexibility. A Good Beginnings list would be very useful, and a name like "Good Beginnings", or some such, would tell people that this is just where to start, not where to stop.

We can have our cake and still make sure that new users have a good supply of solid bread, not just some cake crumbs. (Err... maybe the French Revolution isn't the best metaphore here.)

Anyway, it's good for the health and prosperity of Perl to make it easier for new and talented people to get things done using it.

As I said over there, any satisfactory solution would need to be dynamic and collaborative; and PerlMonks' existing features don't facilitate this too well. Probably the best we can do here is our wiki node type, of which we have several extant examples, such as this one. I'm not sure how good the locking is on these; it might become an issue if lots of people are trying to contribute.

Using threads in sections (such as this one) is bound to fail, due both to the non-collaborative nature and the intrinsic obsolescence of ordinary writeup nodes.

I fully agree ... the primary intent of this thread is to generate interest in a new section. The use of the thread to collect 'popular' modules is simply an effort to (a) show that there are some modules that are universally popular, and (b) get a start on defining the first candidates for the 'best modules list'.

I'm not sure I understand why you think a dynamic ranked list like Saints in our Book would not work ... ?

Heh. Yeah, you're right, although I do quite a bit of work with Oracle as well. But this underscores the fact that a single person can't really come up with a universal 'best' list of modules -- it is the kind of thing that one needs a community (like this one) to achieve.

Given that every user has a personal favourite which might not apply to other users it seems logical that over time "all" modules would have to be included in the list.

Because for any given module $foo there is almost certainly a user or two who believe that is the world's best module!

For that reason above all I think that such a list wouldn't be as useful as you'd imagine:

• 20,000 people will enter DBI.
• 10,001 HTML::Template
• 10,000 Template::Toolkit
• and then 100 people each entering a distinct module!

What I would suggest is twofold:

1. Add a rating to the module review section and use that in preference to a new section.

2. When you say you don't have time to keep up with CPAN that is reasonable (and common!) but I think it is almost mandatory to have a quick look when working with a new area.

Taking you as an example you say you do mostly "databasey" things. I'd not expect you to look at every type of module available every day, but I would imagine that you would have a quick look if you wished to start workgin with say CVS code.

Does that make sense? Having the "best module" cover some modules for working with CVS servers might stick in your mind, but I'm sure that people who know of CPAN and are working on a new area would be liable to search there first, even if they weren't sure of what was available.

Steve
--

The pertinent question is not so much "What are the best CPAN modules", but "What is the best CPAN module to perform some specific task".

The answer to the second question is very often, "All CPAN modules are best for some specific task". After all, the authors of modules spend the time to write and publish their modules because the modules provide a facility or way of solving a specific problem that didn't seem to be available when the modules were conceived.

Sure, there are plenty of unmaintained and even just plain broken modules around, and there are some that are clearly well written and solve their particular problems very well. But a list of the "best" is just barely usefull.

Of much more potential use is to change the focus slightly and look at "The most popular modules". Those are the ones that are used a lot, often because they are the best, but also because the solve problems that are frequently encountered.

So yes, I agree with your intent, but I'd shift the focus to "most popular", which is actually much easier to measure than "best" (see the What is quality? discussion). I'd focus less on problem domain and more on hints for usage of each module. Actually the two don't have to be exclusive, an index by popularity and another by problem domain solves the problem. Note that as soon as you start sorting stuff into slots though, bits drop through the cracks - good indexes are very hard to generate! (The popularity index is easy - but mutable, the purpose index is hard - but fixed.)

An idea to implement this given current monestary facilities (or at least mostly ;) )

Create a new section "Module Reviews". In this section the module name is used as the title and maybe part of the synopsis or just a link to CPAN is the body. Then we use the keywords nodelet to 'tag' these modules with things related to them. Add a simple directory of that category and use the existing rep system so that those modules can be ranked by rep. (You could always alter the owner as is done in Q&A or something so that it isn't a personal rep battle.) Then also add an index that is a sort of tag cloud that would categorize modules. To me this sounds like a nice thing, as sometimes its hard/impossible to find module on CPAN unless you know exactly what to search for, with a nice tag cloud you could hopefully make finding related modules easier as they would have related tags even if there names varied greatly.

Would this requrie some modifications? Yes. But the modifications would all add value and are not 100% necessary for such a section to function. Personaly I also think this is different than a modules review section as reviews are a single persons oppions. These Nodes could server as a home for conversations about the modules in question and maybe reviews could be tacked onto the original node, or linked to in replies to it (maybe thats where the wiki idea someone else mentioned comes in, so that everyone can add links to the main body).

++ To Eric’s idea of a Module Review its a great idea. I have thought for some time that it would be very helpful to have the Brethrens personal choices of Module listed and why they have found them useful and in what way they have used them

Hi,

I think it would be interesting to have a list like this, because:

• People want to solve a problem, not to search for 2 hours / module.
• People still use modules for which there're better replacements/alternatives, because they're used to them.
• People in doubt want to find others opinion or the main stream.

People with no prior working experience in some fields, need a kind of guide, very often it's: use this module, and this.

I do a lot of search.cpan.org looking at modules and also to the source code, to decide which module i'll use, and sometimes it's a tedious task.

AnnotatedCPAN should be a kind of solution for that, but I would add also a rating system based on some criterias, to have something like the "hottest modules" which will vary depending on the module usage, develpment, etc

And I don't think that the best way to produce better things is forking, or reinventing, things could be refactored; there is also CPAN Forum, RT CPAN, to speak about the development of modules, there's also email and so on, there could be more "community contributed modules". People actually do this, but there're a lot of silent consumers were we don't get feedback...

Regards,

The fun I had building some modules that require lots of other modules which may require some library that is a real pig to build.

This may be a better way of scoring a module than a simple score, so if there are 2 modules that do the same job but one is fairly simple, well doc'd and pure perl it may score more than the more complete, faster C module that can only be compiled with IBM's compiler on SCO Unix on a wet Friday afternoon provided the month has an 'M' in it. :)