Fallacy Of The Right Tool

Tools go away. Materials stick.

Programming languages are not analogous to 'tools' because we don't have much flexibility to change languages over the lifetime of a project. There are long maintenance cycles and spiral developments. We must understand the choice of language to be 'part of' the software product, not separate from it. This is doubly clear if we allow users to extend or modify the product, e.g. with plug-ins (PluggableArchitecture). Similar statements can be said of frameworks and paradigms.

Choosing between programming languages is more 'Lego or Meccano' than 'Screwdriver or Hammer'...

PickTheRightToolForTheJob is still fine advice, but we should be careful about where we apply it. With respect to languages, you might count a compiler or IntegratedDevelopmentEnvironment or RefactoringBrowsers among the 'tools'.

See: http://schneide.wordpress.com/2009/12/21/the-fallacy-of-the-right-tool/

It's a good principle, but must be weighed against many other principles. Good development is about balancing myriad trade-offs. Also multiple paradigms may have different problems than multiple languages, some which cover mostly the same paradigm. It's generally best to pick multiple complimentary tools and fulfill sufficiently different roles, such as a hammer and a saw, instead of two similar hammers. We also don't want to fill up our tool box with 10 hammers and 10 saws because then we don't have room/resources for others tools such as wrenches and drills. The article above seems to mostly be talking about the 10 hammer situation.

A good mix of development tools may be one database, one heavily-typed/compiled language, and one "scriptish" language to serve as glue and for cases where quick turn-around is the driving factor. We shouldn't have 5 different scriptish languages in the stack.

The article claims that the analogy of languages to tools is incorrect. Languages and frameworks are material. Libraries and modules are prefab units, assemble-on-site. Services and applications are the `tools`. Even a heavily-typed, compiled language like Haskell can be `scriptish` if supported by an interpreter services (e.g. Haskell has GHCi and Hugs), database or pubsub services, and other web services (like Yesod or Snap or Cloud Haskell). Granted, not all languages are equally adapted to supporting `scriptish` composition, and I would not claim Haskell as an ideal example in that role; I only mention it as an example of flexibility. There is no technical reason a single language cannot support both the hard and soft layers.

About-Tools this wiki:

CategorySoftwareTool