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.

  • Comment on Why the Right Tool for the Job is always ...

Replies are listed 'Best First'.
Re: Why the Right Tool for the Job is always ...
by adrianh (Chancellor) on Nov 24, 2002 at 01:15 UTC

    I totally agree with their being a "right tool for the person/team". Bringing a new language to an existing codebase, especially one where the developers are unfamiliar with it, is hard. It will often be the wrong decision and this does have implications for language advocacy.

    However... :-)

    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.

    I think one of the main reasons for this is the tools. There isn't any support for it in most development environments.

    I worked for several years both coding with, and helping develop, a programming environment called Poplog. It had a single IDE that allowed you to develop in Pop-11 (which you won't have heard of :-), Common LISP, ML and Prolog. All the languages compiled down to the same stack based VM, so it was really easy to write code in multiple languages - and many Poplog users did.

    Because they were all running on the same VM it was trivial for Prolog code to call Lisp code that called Prolog code again, that then called some Pop-11 code, etc.

    The ability to merge languages like this is a very different experience from calling an external library in another language.

    That said, want to use Bob's Prolog expert system shell with your Common Lisp stats package, with a UI developed using Pop-11's PropSheet library - bish bosh done. Darn handy.

    I don't agree that "basically all high-level languages are equivalent". I really do think that some languages are better for some tasks. Text processing is easier in Perl. Multi-platform UIs are easier in Java. Writing code that manipulates code is easier in Scheme... and so on. Some of this is because of the available libraries rather than fundamental language differences - but that doesn't make it any less true.

    I don't want to write 100 lines of perl when I could write 10 lines of Prolog (I still miss Prolog occasionally :-). Equally, I don't want to write 100 lines of Prolog where I could write 10 lines of Perl.

    One of the things I'm finding interesting in the development of Parrot is that you're seeing lots of languages other than Perl being implemented. I can see support for multiple languages being a natural extension of Perl's TMTOWTDI attitude.

    Coding in multiple languages is hard. Finding a development team that is comfortable with developing in multiple languages is hard. Hopefully this will not be true forever and people can start taking advantage of the best points in all languages.

    (I'm about to digress and have a little rant... people interested in the original topic please leave now. :-)

    Personally, I find a lot of language advocacy disturbing. I find a great deal of it consisting of inaccurate abuse rather than reasoned argument.

    I've lost track of the languages I've learned in my career as a programmer. Every one (even BASIC :-) has made me a better developer. Each has brought some new angle or perspective on how I look at problems. Each one has been slightly better at some task or another.

    One of the things I look for when hiring coders is the number of languages they've coded in. In my experience, the more languages the better. Instead of seeing how to solve a problem in Perl (or C++, or whatever) - they look at how to solve the problem.

    Perl's a great language and I love it dearly. I do the majority of my professional development work in Perl. But it isn't the best thing for every task in every situation. Neither is Java. Neither is C++. There is no silver bullet.

    I find a lot of new developers coming out of school or university only knowing language X (where X is usually one of Java or C++). They see everything in terms of that language. Every problem is interpreted through that languages advantages and limitations. I love introducing C++ only coders to CLOS or Eiffle and see the rapid expansion of horizons pop their eardrums :-)

    Anyway... I've started mixing metaphors so I'll should probably stop now... We now return you to your original programming.

[reply]

      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.

      I think one of the main reasons for this is the tools. There isn't any support for it in most development environments.

      This is a really interesting point. It may just be that the current barriers against multi-language integration are so great that they outweight the possible advantages. I think Parrot may potentially offer some hope of overcoming this area. For example, I'd love to be able to use Ruby, but CPAN keeps me sticking with Perl. If I could use all of CPAN with Ruby, that'd be very interesting indeed.

      As to whether learning many languages is good. I certainly won't disagree. Learning more stuff in general is basically a good thing.

      My point was just that while language X may be "the right tool for the job", it may still not be the right tool for the job given the team/person/company/etc. I think this has an interesting impact on advocacy because while Perl may be the right tool for a given project (or piece of a project), advocacy may still be inappopriate because of other factors.

[reply]
Re: Why the Right Tool for the Job is always ...
by gjb (Vicar) on Nov 23, 2002 at 23:28 UTC

    First of all, obviously you are right that each task can be solved in C, C++, Perl, Python, Java et al. Each of these (as well as most other general purpose) languages are Turing-complete, so that should not come as a surprise: all have the same expressive power.

    However, I think the catchy phrase about the right tool does make a lot of sense: read a node I wrote in another thread on this topic.

    As usual, just my 2 cents, -gjb-

    PS: Incidently, I'm active on PerlMonks for about 6 weeks, and the topic has occured about 4 times in that short period of time. Obviously it's on lots of people's mind.

[reply]
Re: Why the Right Tool for the Job is always ...
by revdiablo (Prior) on Nov 23, 2002 at 23:48 UTC

    I think what you're saying here probably applies to about 80% of the things I've worked on. Any competent language (of course, opinions about which languages are comptent will vary) would have been just as good as the one selected. There are obvious exceptions, though. Certain tasks just seem well suited to a certain language, or a certain paradigm which some language is more targeted towards.

    An example I can think of straight off is I often find myself writing intermediate Perl scripts to munge text into a format more palatable to Java (XML works, because the Java XML APIs are quite nice). Personally, I find parsing most text formats with Perl to be much cleaner and easier than in Java. (Yes, I'm aware Java now has official regex support, but the quoting required is just nasty.)

[reply]

      An example I can think of straight off is I often find myself writing intermediate Perl scripts to munge text into a format more palatable to Java (XML works, because the Java XML APIs are quite nice). Personally, I find parsing most text formats with Perl to be much cleaner and easier than in Java. (Yes, I'm aware Java now has official regex support, but the quoting required is just nasty.)

      My point wasn't that all high-level languages are exactly the same. All I was saying is that other considerations besides the strengths of the language will often be more important. Again, if you are in a 100% Java shop and you have to munge some text, writing a Perl script, while easier if you already know Perl, may still not be the optimal solution for your team as a whole.

      But yes, I think there's little question that each high-level language has its own strengths and weaknesses. And while the differences are significant when abstractly comparing languages, they become less significant in the face other factors.

[reply]

        I agree with you that, in most cases, bringing a language into a project established in another language is a bad idea. I do not, however, think that makes every high-level language exactly the same. Furthermore, I do not think that makes the currently selected language *always* "The Right Tool For The Job." Sure, sometimes it is a much better decision to use the "wrong" tool for the job... but that doesn't magically make it a better tool.

        I guess the main difference boils down to how we're interpreting "The Right Tool For The Job." You are taking the more pragmatic approach, which I think is the right thing to do most of the time. I still think there's value in paying attention to the more abstract component, though. And that's what I think this whole Right Tool business is talking about.

        In any case, I think we've flogged this freshly dead horse long enough. I guess I'll agree to accept your wrongful interpretation of this too-often used term. :)

[reply]

Back to Meditations