3 ms·

That's mostly a function of age*avg.popularity.per.year. Java, python, ruby, etc. have been around long enough that available libraries are equivalent if not be

That's mostly a function of age*avg.popularity.per.year. Java, python, ruby, etc. have been around long enough that available libraries are equivalent if not better. A lot of CPAN's libs are likely cruft from the language being so old, the size of it says nothing. What's more interesting is how often libraries are updated with new code, and how often people use them.

peterwwillis 13y ago
Oh, right, old code. CPAN is funny in that they have a central location to test multiple versions of code on multiple platforms and comment/patch them over time. I don't know of anything similar for any other language, probably because there isn't a CPAN equivalent for any other language (edit: there is JSAN and CCAN, but not quite the same). http://stats.cpantesters.org/ http://stats.cpantesters.org/ Want to see how old code stacks up in testing? Let's pick a module and see all its dependencies and their test results. XML::Feed as a random example: http://deps.cpantesters.org/?module=XML%3A%3AFeed&perl=latest&os=any+OS http://deps.cpantesters.org/?module=XML%3A%3AFeed&perl=lates... Hmm, says no results for some of them. Let's drill down and select HTTP::Negotiate to see its test results. http://www.cpantesters.org/distro/H/HTTP-Negotiate.html http://www.cpantesters.org/distro/H/HTTP-Negotiate.html Looks like the latest version has been tested on lots of platforms, and it's good! Let's pick a different piece of code, something older, say from 2005? https://metacpan.org/release/DOMIZIO/CGI-Builder-CgiAppAPI-1.27 https://metacpan.org/release/DOMIZIO/CGI-Builder-CgiAppAPI-1... http://www.cpantesters.org/distro/C/CGI-Builder-CgiAppAPI.html http://www.cpantesters.org/distro/C/CGI-Builder-CgiAppAPI.ht... Ah! So we see the last version it worked with and on which platforms, but on the latest perl it's failed its tests. We can drill down and see why the tests failed: http://www.cpantesters.org/cpan/report/c91a8b7c-4983-11e1-94c9-6af50df65b4f http://www.cpantesters.org/cpan/report/c91a8b7c-4983-11e1-94... Hmm, unprefixed autoloaded parameter. That's probably not too difficult to fix. I guess even though there's old crufty code that isn't always maintained across versions, we have pretty good visibility into when something failed, and with good tests we know why and how to fix it. There's a lot more resources to take advantage of through CPAN, like bug trackers, review sites, development wikis, etc. http://en.wikipedia.org/wiki/CPAN http://en.wikipedia.org/wiki/CPAN
- Zuider 13y ago
  >Hmm, says no results for some of them. A bad sign. This is usually the result of a single test hanging indefinitely, leading to the necessity of killing the entire automated testing process. As a consequence the test results don't get sent to cpantesters.org, putting the onus on the user to file a bug report.
mapgrep 13y ago
This is admittedly anecdotal but: I made the jump from Perl to Ruby, and I can tell you I miss the quality of CPAN. Yes you're right that CPAN has older stuff in it compared to say rubygems.org. It also has, as a gross generalization, older programmers with IMHO more mature and thorough approach to how they package reusable code. This is a language adopted first by graybeard Unix sysadmins in the late 80s and early 90s, then by the first generation of "CGI" web programmers, then by what we'd call today "web developers." So the fact that CPAN contains old code has tons of upsides because the CULTURE of CPAN was set by more seasoned programmers. The documentation, for example, is of generally much higher quality than in Ruby gems, typically involving a nice Synopsis with lots of pertinent examples, documentation of methods/functions that thoroughly lists params and expected output (imagine that!), and that actually discusses edge cases from time to time. There are usually tests that actually run; by default a CPAN install runs a test suite which must pass before proceeding. Rubygems are great but unlike CPAN which began as a manual system where adding a module involved dealing with judgmental humans it's all automated, making an account takes a few seconds and there are no real standards. The culture is just different. This has benefits, like lower barrier to entry, but downsides too. I am continually appalled at the level of documentation in common gems. I guess people expect you to just look at the code, as "view source" options abound in online docs, but then you end up chasing a code path through many methods and classes just to figure out the basics. And there are often real issues with the code, too; while Ruby has plenty of users, they are disproportionately Rails devs who stay in that little ecosystem, so a general purpose Ruby module tends to have fewer eyes on it. Don't get me wrong there is lots of high quality amazing stuff in Rubygems and I'm grateful for it, but you can't spend much time on Rubygems and NOT end up seeing a general difference in standards vs CPAN. Anyway my point is older != cruft and older != bad. Older often means "used by many people for many years, with many bugs removed and many useful features added." Here's one small example. Let's say you want to pull a query param out of an HTTP request. You don't know in advance if it is a GET or POST. In Perl the (c 1994) CGI module solves this trivially without you having to drill down into how the requ was made. In ruby there is no method-neutral way to do this, you have to reinvent the wheel, inspecting the req, sniffing method, and (if you're using any of the code suggestions on Stackoverflow) MANUALLY splitting out the params by decoding the query string and splitting on ampersand. No one has solved this problem with a Ruby module (probably because if you're using Rails, as everyone is, there's a helper for this task). People call Perl a "read only language" but CPAN's "old" culture makes code re-use more easy than even in a more elegant language like Ruby.

peterwwillis 13y ago

Oh, right, old code. CPAN is funny in that they have a central location to test multiple versions of code on multiple platforms and comment/patch them over time. I don't know of anything similar for any other language, probably because there isn't a CPAN equivalent for any other language (edit: there is JSAN and CCAN, but not quite the same). http://stats.cpantesters.org/ http://stats.cpantesters.org/ Want to see how old code stacks up in testing? Let's pick a module and see all its dependencies and their test results. XML::Feed as a random example: http://deps.cpantesters.org/?module=XML%3A%3AFeed&perl=latest&os=any+OS http://deps.cpantesters.org/?module=XML%3A%3AFeed&perl=lates... Hmm, says no results for some of them. Let's drill down and select HTTP::Negotiate to see its test results. http://www.cpantesters.org/distro/H/HTTP-Negotiate.html http://www.cpantesters.org/distro/H/HTTP-Negotiate.html Looks like the latest version has been tested on lots of platforms, and it's good! Let's pick a different piece of code, something older, say from 2005? https://metacpan.org/release/DOMIZIO/CGI-Builder-CgiAppAPI-1.27 https://metacpan.org/release/DOMIZIO/CGI-Builder-CgiAppAPI-1... http://www.cpantesters.org/distro/C/CGI-Builder-CgiAppAPI.html http://www.cpantesters.org/distro/C/CGI-Builder-CgiAppAPI.ht... Ah! So we see the last version it worked with and on which platforms, but on the latest perl it's failed its tests. We can drill down and see why the tests failed: http://www.cpantesters.org/cpan/report/c91a8b7c-4983-11e1-94c9-6af50df65b4f http://www.cpantesters.org/cpan/report/c91a8b7c-4983-11e1-94... Hmm, unprefixed autoloaded parameter. That's probably not too difficult to fix. I guess even though there's old crufty code that isn't always maintained across versions, we have pretty good visibility into when something failed, and with good tests we know why and how to fix it. There's a lot more resources to take advantage of through CPAN, like bug trackers, review sites, development wikis, etc. http://en.wikipedia.org/wiki/CPAN http://en.wikipedia.org/wiki/CPAN

Zuider 13y ago
>Hmm, says no results for some of them. A bad sign. This is usually the result of a single test hanging indefinitely, leading to the necessity of killing the entire automated testing process. As a consequence the test results don't get sent to cpantesters.org, putting the onus on the user to file a bug report.

mapgrep 13y ago

This is admittedly anecdotal but: I made the jump from Perl to Ruby, and I can tell you I miss the quality of CPAN. Yes you're right that CPAN has older stuff in it compared to say rubygems.org. It also has, as a gross generalization, older programmers with IMHO more mature and thorough approach to how they package reusable code. This is a language adopted first by graybeard Unix sysadmins in the late 80s and early 90s, then by the first generation of "CGI" web programmers, then by what we'd call today "web developers." So the fact that CPAN contains old code has tons of upsides because the CULTURE of CPAN was set by more seasoned programmers. The documentation, for example, is of generally much higher quality than in Ruby gems, typically involving a nice Synopsis with lots of pertinent examples, documentation of methods/functions that thoroughly lists params and expected output (imagine that!), and that actually discusses edge cases from time to time. There are usually tests that actually run; by default a CPAN install runs a test suite which must pass before proceeding. Rubygems are great but unlike CPAN which began as a manual system where adding a module involved dealing with judgmental humans it's all automated, making an account takes a few seconds and there are no real standards. The culture is just different. This has benefits, like lower barrier to entry, but downsides too. I am continually appalled at the level of documentation in common gems. I guess people expect you to just look at the code, as "view source" options abound in online docs, but then you end up chasing a code path through many methods and classes just to figure out the basics. And there are often real issues with the code, too; while Ruby has plenty of users, they are disproportionately Rails devs who stay in that little ecosystem, so a general purpose Ruby module tends to have fewer eyes on it. Don't get me wrong there is lots of high quality amazing stuff in Rubygems and I'm grateful for it, but you can't spend much time on Rubygems and NOT end up seeing a general difference in standards vs CPAN. Anyway my point is older != cruft and older != bad. Older often means "used by many people for many years, with many bugs removed and many useful features added." Here's one small example. Let's say you want to pull a query param out of an HTTP request. You don't know in advance if it is a GET or POST. In Perl the (c 1994) CGI module solves this trivially without you having to drill down into how the requ was made. In ruby there is no method-neutral way to do this, you have to reinvent the wheel, inspecting the req, sniffing method, and (if you're using any of the code suggestions on Stackoverflow) MANUALLY splitting out the params by decoding the query string and splitting on ampersand. No one has solved this problem with a Ruby module (probably because if you're using Rails, as everyone is, there's a helper for this task). People call Perl a "read only language" but CPAN's "old" culture makes code re-use more easy than even in a more elegant language like Ruby.