Another argument against "do the right tool for the right job" (I know that you're not so likely to hear arguments against that here... but hear me out) is this: If you have one tool that works reasonably well for every job (maybe not the best tool for each individual job, in a vacuum), then you can invest yourself in really learning that tool inside out and very well. I may do things with perl that would be better done with sed or with a c program or who knows what... but they take less overall time in perl because I do so much else in perl every day. It's practiced and trained, I can rattle it off like nobody's business.

This is also why (if anyone pays attentsion to such things) I talk a lot, in my posts, about the line between perl scripting and shell scripting, perl "one-liners" and so on. Because, by the same token, I am needs-be using shell all the time, and perl one-liners interface incredibly well with shell scripting. I'm getting off topic here, but ever find yourselves doing stuff like:

something | perl -pe ... | sort | perl -pe ... | wc
[download]

or some crazy pipeline that flows in and out of perl one-liners and through other things that perl could do? Hell, perl can sort. Perl can count the number of lines read... why am I using shell for this? It's because if you're alread *thinking* in one language, use that language, even if it is *not* the best tool. The mind-set shift between the tool you're already using and the "best tool" is not worth the advantage that the better tool gives you.

Anyway... what that's all about is the fact that perl, by being so versatile, is a *reasonable* tool for pretty much any job... and that's often more useful than the very best tools for each of ten different jobs.