|P is for Practical|
Right tool for the job?by chester (Hermit)
|on Sep 24, 2005 at 17:30 UTC||Need Help??|
In an ideal world, I would know 3,000 programming languages. And when faced with any task, I would open my Rolodex o'Languages (with all of which I am quite proficient), and merrily flip through it to find the perfect tool to solve my current problem, mumbling to myself "Ada? no... ALGOL? no... Applescript? no... ASM? no... AWK? no..."
Half an hour later, I would leap from my chair, exclaiming "The right tool for this job is a combination of UNISAP and PACTOLUS, with just a touch of ASDIMPL and XPOP!" And it would be the perfect tool for this job, and I would whip up an elegant, simple bit of code which efficiently solves my problem while being readable and easy to maintain.
In the real world, I'm somewhat limited by the number of languages I know, and I'm limited by the amount of time I have to dedicate to learning new languages.
For this reason I sometimes tend to use Perl in perhaps inappropriate ways. For example, I have never learned bash scripting beyond the very basics, or sed, or awk; when I want to do anything non-basic involving the shell, I pipe it through Perl. I needed to write a quick GTK app one day, so I wrote it in GTK2-Perl. Another day a QT app, again I used Perl bindings. When I need to create an Excel document with a report from MS SQL-Server, I shudder a bit, then use Perl. When I use vim, I avoid vim-style regexes and use perldo. And so on, and so forth.
Often I'm pretty sure there's another language or tool which was made to solve the problem I'm solving. Instead I wield Perl like a Neanderthal and bludgeon the problem to death, because I (unfortunately?) have a tool which can do anything I want, and because Perl is What I Know. And it works, for certain values of "works". If I was writing an OS kernel or a control system for a nuclear reactor, of course I wouldn't use Perl, but short of that, Perl can solve almost every problem I want to solve.
To put it another way, I think there are short-term and long-term costs. In the short term, using Perl all over the place is good because I can solve problems using resources I already have. (Knowledge being the resource in question here.) But if I spent the time to learn Java or Ruby or assembler language (or whatever) really well, it may save me time in the long run, by avoiding Perl problems that arise when Perl isn't the ideal tool.
But I know that if I wanted, I could devote the next decade to learning more and more about Perl, and still never learn everything there is to know. I still learn something new every single time I come to PerlMonks; I don't see that stopping any time soon. And much of what I learn about Perl is applicable to other languages. But much is also not at all applicable to any other language; it's learning Perl, and it's useful if I use Perl, and it's a waste of time if I don't use Perl.My point (there is one, I assure you!) is this: Is there a point where it's time to say "I know Perl 'well enough'; it's time to devote most of my resources to learning something else"? If only for the sake of having more tools available? Do you think it's more important to devote one's time to becoming a jack of all trades or to try to become a master at one thing in particular? Assuming one lacks the time or resources to do both, or assuming that one is looking to decide where to allocate the most effort.
(update: Thank you all for the thoughtful replies.)