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
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).
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||