From: David Masover Date: 2009-04-16T10:34:33+09:00 Subject: Re: Can Ruby stay ahead ? On Monday 13 April 2009 09:40:03 Mark Thomas wrote: > On Apr 12, 3:07 pm, David Masover wrote: > > 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. http://search.cpan.org/search?query=xml) 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.