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.
Agreed but keep in mind the Perl community were black sheep for years because the language is so (admittedly) hairy and ugly oh and also not a "real" programming language because it gained adoption when scripting languages still had a stigma. And the community had its own issues; there were sites like "Matt's Script Archive" distributing horridly insecure code (read through http://en.wikipedia.org/wiki/Matt's_Script_Archive). But time has a way of changing both communities and how they are seen. Like I said, old is good. Programming communities age like wine. (Which means they improve and improve -- until they peak at which point all bets are off.)
Seems like a better lesson to learn would be "Don't use software written by people who've never read an RFC and know nothing about security." That way you could avoid awful software written in any language.
Yeah. The condition of rubygems are generally so bad (unfinished and/or abandoned), that I would strongly recommend Python over Ruby for new projects - which is a shame, in the core language Ruby is more elegant and more fun to write, and I know Ruby much better than I know Python. (for a concrete example, compare "NumPy" to the various attempts at good math structures in ruby)
I wish I could recommend perl - CPAN modules generally really are amazingly high quality. But the mental cost of the perl programming model: no named params! arrayref vs array vs list! Contextual::Return! blessing scalars into objects! - that cost is just so friggin high that I can't imagine asking anyone to follow me there anymore.
References do suck. All languages have ugly misfeatures, by nature. (Some language groupie collectives are in denial...)
But you get named parameters (and type checking of them!) for functions/methods through CPAN. And lots of other language extensions.
High flexibility in programming languages -- Perl isn't close to e.g. Lisp macros -- do have costs, of course. You need to use automatic tools, code reviews and coding standards. But you should do that anyway.
I really doubt the extra time/cognitive costs make for a noticeable extra burden, considering that you'll have to learn lots and lots of other stuff anyway.
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.