"The right tool for the job."

[perrin]

Recently, there have been some flamewars on Slashdot.org, TheServerSide.com, and elsewhere about the possibility of LAMP development eating into Java's marketshare. These inevitably include a dozen or so people saying something about choosing "the right tool for the job."

I find this very disingenuous.

True, there are a few cases where something is clearly a terrible fit. A language that is much too low-level (or high-level) for the job should be pretty obvious to nearly anyone familiar with the basics of computer languages. But that's hardly ever what we're talking about.

Usually, "the right tool" argument is followed by a preposterous example of a project where something other than the current speaker's favorite language might be appropriate. (Amusingly, Perl people often cite banks as a place where one might use Java, yet banks use a lot of Perl.)

In reality, people don't have the luxury of switching to an entirely different development environment for each project. If some project comes along where it looks like two-phase commit might be useful, do you expect an expert PHP programmer to drop what he's doing and switch to J2EE? No way. And if a small web project comes along, do you expect a seasoned J2EE programmer to toss out Eclipse and fire up Mason? (Yes, I know, EPIC, but that's entirely beside the point.)

Becoming productive in a new language and toolset takes time, and the cost of switching is high. You can't really do it well on a deadline. More than that, the only people who really have the luxury of choosing without the result being practically a foregone conclusion are people who don't know much about any development environment, like CTOs or Vice Presidents who have some drinks with the IBM sales guys and send you off to WebSphere school a week later.

I don't really have a point here after all this. This is purely for entertainment purposes. But I do suggest that the next time you see a language flamewar you consider playing the Right Tool Drinking Game -- you have to drink (Brooklyn Lager, a fruity Sancerre, a Scotch that only David Adler knows about, espresso, herbal tea... the right drink for the job) whenever you see the phrase show up in the thread. Better keep that cup full.

[cLive ;-)]

Our rule is that we really don't care what you code in - just as long there's at least one (preferably two :) people on the team that can review/fix in that language.

The rule finally came about after an all night hack session to deflect an intense DOS attack on our servers. One of the sysadmins wrote a beautiful script in python, except it didn't always work - he went to bed after 18hrs and I was left staring at some lovely incomprehensible (to me) code. So I had to grab the gist of it and rewrite in Perl (fume). Fortunately it was only a hundred lines or so.

We also now have a (relatively) new guy who loves Java, but that seems to have fizzled out.

I think you're totally on the ball Perrin. There's always a bunch of crap with flame wars. But what does happen is slow osmosis. I've just started loving awk. No way I'll ever write anything big in it, but I've been convinced of its usefulness and have incorporated it into my daily regime. I think that's what's happening with Java (to a degree). People find a great solution to something in Perl that would take 5 times as many lines in Java, and they squirrel it away. Slowly, they start to use more Perl and then get sucked in.

This is turning into a rant without a point and with too much beer, so I'll cut my losses and quit right now.

cLive ;-)

[rinceWind]

(Amusingly, Perl people often cite banks as a place where one might use Java, yet banks use a lot of Perl.)

It may be true that some banks are using more Perl than Java, but have you asked the question "what for?" In my experience, Perl is not used for full blown applications, but as glue, or as admin and DBA tools.

I think that banks are using more C++ than Java or Perl, and this is through reluctance to change or jump on the perceived Java bandwagon. My present client has a nasty taste in its mouth from a J2EE project that went horrendously over budget and had to be canned.

I'm actually being principally hired as a C++ programmer, though I have managed to get Perl used for application monitoring and suchlike. The RT4TJ argument has actually been quite useful to me for Perl advocacy.

[DrHyde]

The Right Tool For The Job is, in most cases, the one that your developers and maintenance programmers are most comfortable with. Whether they are most comfortable with Java, Python, Perl or C++ is not particualrly relevant.

[Tanktalus]

I'm not so sure. Our department, one of many working on a largish product, uses: Perl, Java, Shell, C++, Visual BASIC (although I'd like to replace that with Perl), batch files (again, trying to replace that with Perl - it's just a matter of time). And, of course, makefiles. Of this, the Java, Shell, and C++ code is shipped - Java and C++ are only shipped as binaries ... although even the Shell, we don't ship the source code. Our shell scripts are done in a template format first (based on Text::ScriptTemplate), and then "compiled" to be platform-specific, allowing us to target platforms a bit easier with a bit more flexibility (e.g., shell code needed on AIX may not even be parseable on Linux). We ship the results of the template processing.

It's all about the right tool for the job. Java is used for GUI. Shell is used for filesystem manipulation (on machines that may not have perl installed - our end-users). C++ is used for all the heavy lifting. Perl is used in our build environment for filesystem manipulation and string manipulation, including generating C++, Java, and Shell code. VB/batch files should be done via perl, but this is where your point comes in - there's only so many perl people on the team, so when someone needs something windows-specific, they don't ask us, they just go do it the way they know how. My counter-point? They do things inefficiently and in a way that is not extendable. It works because they hardcode so much stuff in there - and then when the requirements change, they need to make drastic changes to unreadable code. While on the perl side, I modify some data files (string manipulation, anyone?), and I don't even touch the code. In case you're wondering, even the Java guys can update the data files. There's no perl-isms in there. At least, they're not obviously perl-isms - you don't need perl experience to understand them. If we were using Perl where we're currently using VB/Batch files, it would be more work up-front, but changing requirements would be met way easier.

Short version of this node: I respectfully disagree. ;-)

[phaylon]

It is true that you will use the tool that you understand as "fits best." But that does'nt make it the best tool for the job. That you're using Java for GUI, Bash for filesystem, etc. depends IMO on your company, your strategies, your experiences and many, many other factors. It's not because Java is just the right tool for the GUI job but because it's the best tool in your worker's hand.

[sub_chick]

I see what you are saying here and I just so happend to bring up a simular topic here in meditation just a few days ago Perl with other languages and some very good points were made there as well. Yes, having many tools to work with and having the flexibility is good. And I found out that many monks are into other programming languages as well which is nice to hear.

[tinita]

still, companies do things like that - switching an application from perl to java. in 1/2 year or so.

reasons:
"java is more widely used and has working frameworks" - old problem with chicken or egg - if more companies supported perl development there would be more frameworks
"you will get more/better support just because there are more people who know java" - same problem
"why do you complain? a computer scientist is not a language-x-programmer but a programmer who can program in any language" - well, why don't we all program in bash, then? the point is not to *be able* to program in a language but to think that a language is the better tool

perl is often seen as a script-kiddie/unix-admin language, like "if you want to do some real business, you don't play around with perl".

[hardburn]

perrin++

The "right tool" argument is generally used to support whatever your favorite tool is. The flame warrior might then mumble something about hammers and screwdrivers. The problem is that those are both very simply tools, and it's quite clear when you should use one over the other. Programming languages are very complex tools. In almost any sizeable application, it would take a huge study to know what language(s) would be best for the application. This study might take as long as just writing it in whatever language you have on hand.

Further, any given section of an application might be better suited to a language other than the one you're using. Chances are, the gains in writing that section in another language will be sucked up by the process of binding the two languages together. In a complex app, you might get away with two languages. I doubt you'd see a productivity gain with more, even if your entire team was well studied in each language.

Even if I honestly think that a given language is the "best tool", I don't use that argument, because too many people use it to serve their own ends.

[Perl Mouse]

I'm a strong believer in "the right tool for the job". However, the job doesn't stop with what needs to be done, but also by whom - now and in the future. To select a language for a job, a manager or project leader should consider what expertise he has available over the lifetime of the project.

[g0n]

I quite agree that one of the most important factors for choice of language is having the technical resource (now and in the future) to write and maintain in it.

Unfortunately (as I rant quite frequently) a very large proportion of IT managers (at a decision making level at least) have little or no technical understanding. As a rule they are appointed by business managers, following the age old adage of 'appoint someone as much like me as possible' (this approach is well attested in org psychology BTW).

They therefore make the decision of what language(s) to mandate in house, often on an entirely non technical basis, based on: the advice of their employees (which they will rarely listen to), the business tech media (what's todays buzzword folks?) and salespeople (Always trust the advice of someone with a personal interest in your decision < /sarcasm>). The result is usually that the choice of 'the right tool for the job' is constrained by available resource, which is in turn constrained by what has been mandated as the 'house language', often for entirely non technical reasons.

[salva]

ok, now imagine you want to eat some food, fried fish for instance. Obviusly, the right tool for the job depends on what you are used to, if you are from France you would like to use a fork and a knive but if you are from Japan your preferred tool would be a pair of sticks.

Now, you want to eat some soup, what are you going to use, the fork or the sticks?

[phaylon]

I heavily agree with you. The Right Tool depends IMHO and in my experience more on the one who's using it, than what for it's used. Although you can do most things in most languages, you do it /differently/ in most languages. So I'd also say "There is not much difference in which language you use" is false. It matters what tool you use, it matters what this tool is used for, and it matters who is using this tool, how much he's experienced with it.

At the end of the day, most coders are humans too. Humans that do one thing better than the other, that like one thing better than the other.

[lachoy]

I talked about this a while ago but in much harsher terms, you being the consummate gentleman :-)

[perrin]

At this point, when I hear it, I translate it mostly as a stall tactic, or as "I think your tool sucks at everything, but I'm trying to be polite."

[Anonamous Monk]

Sounds like maybe the is two points - 1: management may force you to use the wrong tools; 2: your experience maybe forces you to use tools that are not the best.

[ForgotPasswordAgain]

It's interesting that you started out by putting your explanation in the context of flamewars, a social phenomenon. I think a more general way to frame your objection to the "right tool for the job" argument is that it doesn't take into account the social aspects of developing software; it only looks at what works best technically.

[radiantmatrix]

I think you're generally right: RT4TJ arguments are often baseless, as the "right tool" tends to be what you have available in terms of extant code, dev tech, and people.

However, just because the argument is often misused by people who don't understand it doesn't mean it is without basis. For example, Perl is not the Right Tool when performance is King (say, 3-D model rendering and shading). Neither is Java, for that matter. You'd probably use C or ASM for something like that.

I think the fallacy comes when people start to think that for any given application there is One True Language that is the Right Tool for that job. The Right Tool argument really has more to do with narrowing the field, not the ultimate choice.

Except in those cases, the choice is less about the nature of the problem/solution, and much more about the specific constraints of the specific situation outside the problem (i.e. what resources do you have, and what work can you borrow to make your life easier).