> But since you're probably going to get this answer from pretty much
> everyone here, what does CPAN have that Rubygems lacks?
There's no doubt that CPAN is a great resource. These are a few of its
highlights:
1. A single, cohesive website that categorizes all modules (http://
search.cpan.org/) for easy browsing.
True, this would be nice. The gems system should allow this -- after all,
there's a single, cohesive website for all local gems (gem server).
2. A module namespace convention that helps one know what the module
does, rather than 'cute' names (Test::MockClass vs. Mocha,
PDF::ReportWriter vs. prawn, etc)
I'm ambivalent about this. I like CPAN namespaces, but I also like the fact
that competing implementations are distinctively named -- for instance,
Hpricot vs Nokogiri. Once a library is known, of course, the namespaces are
usually coherent -- for instance, Nokogiri-related stuff is in the Nokogiri
namespace.
3. A search engine that returns not only description, but also last
update, and reviews. (e.g. Search for "xml\" - metacpan.org)
Not that it's a replacement (as it isn't integrated into Gems), but Github
does expose last update, and makes it quick to find forks, etc.
But yes, this would be useful.
4. Page for each distribution with links to the classes and files,
dependencies, test results, etc. (Example:
http://search.cpan.org/dist/XML-Twig-3.32/\) Much better interface than
Rubyforge.
This seems to be provided by the rdoc, somewhat -- again, in gem server -- but
again, that's not as useful when looking at new modules.
5. Automated tests run by a cadre of volunteers. New releases of
modules are tested upon release on a variety of Perl versions and
operating systems. See the test reports and Perl/Platform Version
Matrix links on the distribution page.
Ideally, these would be run on release candidates, too, right?
6. Ratings. When there are many options for a particular task, seeing
the star ratings can help you whittle down the options to the best.
The overall highest rated modules tend to be the best-practice ones
you should be using.
This would be helpful. It's easy to see how it might be abused, but the
paradox of choice can be irritating.
7. The 'cpan' command comes with Perl. 
The 'gem' command comes with Ruby 1.9.
9. CPAN has a very rich set of mirrors (http://mirrors.cpan.org/\) and
you can configure your local cpan command to use a subset, say a
primary and a backup (good for environments requiring firewall rules
to be in place for external access).
I'm not sure Gems is to the point where this is necessary, in terms of sheer
popularity.
It seems that this could be simplified as:
1. search.cpan.org
2. better docs, on average
3. community (volunteer) services
1 and 3 should be easy to solve. 2 will take time.
Overall, neither is enough to make me ditch Ruby for Perl, and I doubt I'd end
up using a Perl library over an equivalent Ruby one. But that is compelling.
Thanks.
···
On Monday 13 April 2009 09:40:03 Mark Thomas wrote:
On Apr 12, 3:07 pm, David Masover <ni...@slaphack.com> wrote: