in reply to Would you stay with Perl if there were no CPAN?
I frankly suspect that CPAN is “what all the fuss is really about.” A language is a language is a language ... but a language plus a powerful and extensive library of (mostly...) known-good software is a tool.
I don’t think it wrong to say that “CPAN will never change, because it should never change.” There are millions of man-hours of effort represented in that code base, and there are well-known, well-understood methods for working with it which are by now deeply embedded in all sorts of mission critical working procedures. The rightful resistance to change is tremendous, no matter how “er” some “improvement” might be.
Sometimes we overlook just how good we do have it. For example, a few years ago at A Prominent Place-of Legendary Expertise, I watched as someone decided to endeavor to replace a very important Perl subsystem with Ruby. Observing that Ruby had “gems” that appeared to be more-or-less equivalent, they (self-)confidently plowed ahead ... into a hedgerow of FIXMEs and TODOs. The depth and maturity of the Ruby packages, at that time, were nowhere close to being “equivalent to” Perl’s, and they neglected to take that properly into account or, I suspect, even to consider it during their initial project planning. They looked at Ruby at its then state of the art, and saw Perl at its then state of the art, and did not prove their guiding assumptions. The outcome was painful to watch. Now, it goes without saying that the Ruby teams are no slouches, and this is n-o-t language-bashing (or team-bashing!), but the maturity and completeness of the CPAN library is also very much “what the fuss is about.”
In every case, “the contributed library” is a fundamental part of every language system, and its raison d’être. In some odd way, a programming language is really just a tool that enables you to apply existing, well-tested solution libraries to your problem de jour. (And, oh yeah, to construct and manipulate data structures.)