Why the Right Tool for the Job is always ...by autarch (Hermit)
|on Nov 23, 2002 at 22:12 UTC||Need Help??|
If you've read any discussions of language advocacy, you've no doubt seen the phrase "the right tool for the job." In other words, if you need to nail something together, you don't whip out the arc welder.
It's a catchy phrase, but it's misleading at best. First of all, programming languages are much more multi-purpose than your average carpentry or welding tool. A hammer is basically designed for hitting things or pulling nails out, that's it. On the other hand, while there are niche languages, most languages in use today were designed for general purpose use. A programming language like Perl, C, or Java is more comparable to a whole toolkit than a single tool.
In fact, I'd say that there is precious little agreement on what the one right tool for a given job is. In my experience, the only thing that programmers as a whole are likely to agree with is the assertion that when speed of execution is absolutely of the essence, then the only viable solution is to use C (or assembly, eek!). But the world of possible applications is vast, and the applications where speed is the most important factor are not that common.
When speed isn't the most important factor, development time, maintainability, and flexibility in adding features will usually take precedence. Again, programmers seem to generally agree that C and assembly do not help in these cases, and so some higher-level language is recommended.
So the question is which language to choose, and "the right tool for the job" starts getting bandied about. The fact is, there is nothing that can be done in one of C++/Java/C#/Perl/Python/PHP/(VB?) that cannot be done in one of the others. Some of these languages are a bit better at certain things than others. Perl is well known for it's text-process power, but C++ can take advantage of libpcre and Java/Python/PHP all have Perl-compatible regexes as well. Yes, Java is a bit more verbose than Perl, but if you are already fluent in Java, the extra typing is a minimal effort next to learning another language, or even the extra effort in using a language with which you are unfamiliar.
Java is known for its various application frameworks, EJB and so on. But is there anything that EJB does that cannot be done in Perl? To the best of my knowledge, no. Perl might take more typing to get the same thing done, but it can do it, and there's certainly plenty of application frameworks to choose from on CPAN.
So my contention is that most of the time, there is no such thing as "the right tool for the job". However, there is the "right tool for the person/team". Since basically all high-level languages are equivalent, the only thing that ends up really mattering is the particular person or group who will be developing the application in question.
I, personally, am quite well-versed in Perl. I can read Java, C++, or Python, and understand what is happening in the code. But when it comes to writing code, Perl is by far my most fluent language. So that means that the "right tool for me" is going to be Perl, regardless of the application. The flip-side of this is that in some cases I will not be the right person for the job, not because I couldn't program application X, but because the employer has an investment in some other language and does not want to deal with the added burden of adding Perl to the mix.
If you're at a company where your existing codebase is in Java, then the "right tool for you" will be Java. Yes, Perl may be better at text-processing in the abstract, but if you and everybody else at your company are most fluent in Java, then Perl's advantages will continue to be abstract.
I can't prove that I'm right about this, but one point in my favor is the relative absence of multi-(high)-language applications. While we often see Java/Perl/Python/VB mixed with C for speed-critical components, applications with equal mixes of Java and Perl, for example, are almost unheard of. Similarly, I haven't seen many projects which equally mix Perl and Python, or VB and Java.
So what's the point of all this? Partly, I'm sick of that stupid phrase! But there's more to it than that. I think this also has implications for language advocacy. I would be thrilled to see Perl used more and more. Hey, that's more work for me! But I think realistically, the places where a language is going to make the greatest inroads are either going to be when a company is making its first technology decisions, or when a company has decided to replace a clearly outdated/broken/unmaintainable/whatever large system, like an older COBOL/mainframe app. If a company already has ten functioning apps in Java, then trying to convince them that app eleven should be in Perl seems like an uphill battle at best.