No matter how productive it makes you, a programming language won’t save you any time if you can’t take advantage of a body of code written by other people. A community works faster than any one person, and it’s usually easier to install and learn a library than to write and debug the same code yourself.
That is, if you can find the library in the first place. And if you’re not sucked into an mess of dependencies that grow and grow, making you want to write the code yourself just so you can be doing some real programming.
The success of Perl’s CPAN archive has made the Ruby community work on our own centralized code repository and packaging system. Whatever you think of Perl, you must admit that a Perl programmer can find just about any library they need in CPAN. If you write your own Perl library, you know where to send it: CPAN. This is not really a technical aspect of Perl, but it’s a powerful component of that language’s popularity.
The problem of packaging is more a logistical problem than a
technical one. It’s a matter of coordination: getting everyone to agree on
a single mechanism for installing packages, and a single place to go to
find those packages. For Ruby, the installation mechanism is Ruby gems (or
rubygems or just “gems”), and
rubyforge.org is the place to go to find gems (packaged libraries and
In many recipes in this book, we tell you to use a gem for some task: the alternative is often to show you pages and ...