in reply to The Limitations of the CPAN
Now here's my "ace in the hole" argument: Our Perl is not what you think. Sure, it's easy for me to sit here and say Perl's CPAN isn't the end all and be all when we use it so frequently. However, most (not all) things that we use from the CPAN are either readily available in other languages are are easily cobbled together. The heavy lifting -- those things that are the core value in our code -- has all been built in-house for our needs.
I believe this has already been mentioned but this has been true everywhere I've worked. There is no ready-made software for your enterprise. Anything you buy or download has to be tailored or wrapped in some way to fit the reality of your workplace.
Other than that I've found the opposite regarding CPAN. Our use of Perl grew from small to big mostly because the other in-house languages didn't have readily available, free solutions to problems that needed to be quickly solved. CPAN did. We're currently using over 300 CPAN modules. I have no illusions that those would be easy to "cobble together" or would come ready-made as part of another language, particularly for free.
That being said, different languages and systems have their place. There is no one answer. The way we're using Perl now (on a large scale) is a good fit for the problem set. I would not even suggest it for some of the other problems we solve. I would guess you've been employed as a programmer for somewhere between 5 and 10 years. I only say that because I found myself and other very good programmers going through a phase during that time period where we knew enough to see all the flaws and desperately thought many things should be done and redone differently in "better" ways. Somewhere after year 10 all of us seemed to become practical. The fact is, most of what we write is relatively short-lived anyway. Systems come and go. Ways to program come and go. Methodologies come and go. There will always be something out there that looks like it solves the problem better.It is a good learning experience to go through a few large scale rewrites to see just how little that promise delivers.
For something new, I agree that you should evaluate and pick the best tool for the job. But there's a practical side to that too: you need to sell it to management and you need to be able to hire people as things grow. I think Ruby would be a hard sell in that regard (at least for me).