[davidw]

They are not just 'tools in a box', though, that's a bad metaphor. Each language is a more or less complete toolbox, although each one has things it's better at. Still, most of us tend to grab the language(s) we know, first, rather than look around for the 'perfect' language for each job, unless it's going to be a very large project.

[jacquesm]

Exactly, it is all about economy. If the price of change is too large we'll stick with what we know already.

If the price of change starts to look like it might be made up for over the course of a project then that's an excellent incentive to switch to something more suitable.

[madd_o]

Let's accept your argument, that each language is a complete toolbox. You'd likely grab a different toolbox to fix different classes of problems.

For large problems it's common to bring several different toolboxes (think of a primarily php site with a their public api scratched out in java).

The points among each language which contrast and define the 'things it's better at' differentiate the tools and or toolboxes (however you prefer to think of each).

Again, +1 for tearing down tearing down programming languages.

[davidw]

> Let's accept your argument, that each language is a complete toolbox.

You can write a web server with Tcl, Ruby, Python, Java, Erlang, C, or whatever.

You can also create GUI's with all those languages.

Any major language is most likely capable (and has some libraries) for doing common things.

> You'd likely grab a different toolbox to fix different classes of problems.

Like jacquesm says below, you would only do so once the cost of learning a new language is less than the perceived gains from using that new language. Since programmers are expensive, and jumping to something new and potentially unknown has some potential pitfalls, this is often not the case. I.e. it's better for the Ruby guy to write a little web server in Ruby rather than Erlang if that's what he needs, even though the Erlang one will kick the stuffing out of it in performance tests, unless of course he knows that performance is absolutely critical (it isn't in many cases), and more important than solving the "business logic" of the problem.