[loewenskind]

>Though it's really no fair comparison as CPAN contains what.. 89033 modules?

Why do people keep trotting out this stupid pointless number. How much of that is duplication? How much of it is crap? How much of it is literally toys (e.g. ACME stuff)? In any case, Java has vastly, vastly more so any language that runs on the JVM automatically beats perl here.

99% of programmers will never notice any functionality missing in Ruby or Python that CPAN has.

[chromatic]

Why do people keep trotting out this stupid pointless number.

Metcalfe's Law. The value of the CPAN increases dramatically with every addition, especially because of the maturity of the entire CPAN infrastructure: CPAN testers, CPANTS, annotations, reviews, dependency tracking, BackPAN tracking, gitpan, linked documentation, et cetera.

[loewenskind]

>CPAN increases dramatically with every addition

Demonstrably nonsense. Let me add a new module called ACME::DoNothing. What have I increased besides disk space and a meaningless module count?

[chromatic]

You've tested the entire CPAN ecosystem, as well as the ability of the ecosystem to identify and remove harmful contributions, if said contribution is in fact harmful.

[loewenskind]

I'll concede that that is very good. And I'll also concede that I can't think of any other systems that do this as well as CPAN (if at all). But my point remains that for 99% of developers we want a library that provides functionality (e.g. an ORM for a common database) and in that respect CPAN will only have an advantage for very obscure requirements. And even then it still loses to Java.

The testing stuff is good and it's the direction everyone should be going but not having it obviously isn't too much of a problem because so few systems currently have it (CPAN was successful long before it had it as well).

[Mithaldu]

> not having it obviously isn't too much of a problem because so few systems currently have it

You can't really draw that conclusion. Other systems do not have it because it is not an easily solved problem, not because they do not think they need it.

Also, needing and benefiting from something are two entirely different things. Yes, no language actually NEEDS this kind of thing. But a language that has it is literally self-healing, since any kind of problem, be it breakages from dependencies, cross-platform issues or core language changes are communicated very rapidly to the developers without them even needing to make an effort.

[chromatic]

The testing stuff is good and it's the direction everyone should be going but not having it obviously isn't too much of a problem because so few systems currently have it....

The Perl 5 Porters mailing list has automated mailings which test CPAN against bleadperl to discover which, if any, commits break existing CPAN distributions. This helps p5p revert genuine mistakes and CPAN authors to patch their bugs.

I know that several minor revisions of other languages have broken several popular extension libraries.

[kentnl]

Without a testing infrastructure, you pretty much rely on programmers having code doing what they say it does, instead of having proof it does what they say it does.

Given human penchant to slip up and not realise problems until after they are encountered, having tests makes pretty much the difference between "science" and "hypothesis"

[perigrin]

Not entirely true. Languages with strong static type systems like Haskell and OCaml go a long way towards being provably correct without test suites. Dynamic languages like Perl however have no such guarantees.

The fact that the cross product of several generations of interpreter, several platforms, and tens of thousands of distributions is generated automatically by a handful of volunteers is a strong argument for CPAN/Perl being unique amongst the dynamic languages in it's testing and compatibility.

Additionally, people who aren't in the right circles probably never know how much grepping through CPAN happens when new features and syntax is suggested for the core Perl5 language. All done by the porters to be sure that new syntax won't break existing code without some fore-knowledge. This is on top of the automated testing.