in reply to Total Perl Domination
My job is in Computational Biology. Some of the work requires gluing together various "bits": data in various formats, lots of fairly simple string work, nice output reports, etc. Perl is close to ideal for that. It's also excellent for running various programs, for automating tasks such as database downloads, for quick&dirty GUI programming, and similar tasks.
It helps if you help Perl help you: when I created a new data format, I gave it a nice C interface (for our C programs). Not wanting to write (and maintain!) 2 parsers, I wrapped the C interface, with SWIG, to be usable from Perl. The Perl interface is object-oriented, of course, so it's actually nicer than the C interface. And recently I removed the need to free the allocated C objects manually, making the Perl interface even nicer.
But I also have to use C. Perl offers excellent performance for "built-in" tasks, such as regexp matching. But if you require high performance with non built-in structures and algorithms, the performance hit is huge. So the core, high performance tasks are done in C (or C++).
Perl's goal never was to replace other languages; it does its best to work with the others (unlike, say, SmallTalk or Prolog, and even most Lisps), and it makes some (maybe even many) types of programming easier and more pleasant. But it's no panacea, nor is it meant to be one.
``Use the right tool for the job''. If that means Perl, use it. If it means something else, use that.