The next thing CPAN needs...

I had a recent experience that gave me pause (pun intended!) and inspiration for a helpful CPAN tool: a categorical tabulation of module popularity.

My example: about a year ago (maybe more), I first dabbled into AJAX and went looking for a module that would import/export native Perl objects in JSON format. So a CPAN search pointed me to the JSON module.

Fast forward to yesterday, where I'm pointed to JSON::Syck, which fits my simple needs, but more importantly (and objectively), is faster & more memory efficient.

So I wish there was something where I could search for JSON, CSV, DBI, CGI, etc and then search.cpan.org would recognize that as a category and present objective data that would better direct me (and other developers) to the most popular (and often best) selection.

An initial objection would be flamewars, but if we kept it to pure numbers and tied it to BitCard logins, the numbers would be objective themselves. Of course, people will probably want to make comments and that's where it could get awkward.

Another objection might be something already exists, whether it be the rating system or this wiki page, but they both don't fit this need, IMO, basically because a sense of popularity isn't thrown behind the modules.

Another objection might be upstart modules would find it harder to be adopted, but if we allow people to change their "allegiance", upstart modules' new votes would become more substantial quickly.

Maybe even simpler would be a download tracker in CPAN to tell how many times a CPAN module has been downloaded/installed. Then put those #'s in the search results.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

I think the problem you're trying to solve is an important and useful one. In Perl6 it will not be as big of an issue because we will have Roles, so multiple JSON modules can implement the JSON role using whatever backend then like. Although this isn't perfect since some JSON modules might want a completely different interface so they won't provide that Role per-se.Maybe we should have something tied to Bit-Card accounts where people can say "Hey this other module does the same basic thing better" then. We

In the same frame of mind, there's an idea I've been
toying with for some time... It's not rare to have the
music instruments used by a band listed in a CD booklet.
As programmers aren't that different from rock stars, it'd
be nifty to be able to do the same thing. I mean, if Nick Krachmeister
can say that he's playing exclusively Howling Kitty Stratocasters
then, by Joves,
I should be able to say that I use XML::LibXML to craft my
masterpieces!:-)

That idea has been tossed around for years. The JFDI suggestion was for people to upload personal bundles (ie. you’d stick Bundle::YANICK in your CPAN directory). You don’t need a lot of new machinery to accommodate that. But we’d probably need a web interface or something to make managing that bundle very easy before people will do it in significant numbers – or at the very least it would need to be widely advertised as a social convention among module authors.

Hmmm... yeah. I didn't think about it, but piggy-backing the Bundle:: mechanism isn't a bad idea at all. All that is needed after that is a back-end mechanism that harvests that information, and a snazzy web interface to display the results.

Well, looks like there's one more cool project I have to throw at the top of the Holiday Hacking pile.:-)