让我以一个免责声明来开始这篇文章：我绝对的认可懂得多种编程语言的价值，也认为“用正确的工具干活儿”是个好思想。但在编程工作中，人们对这个概念有个误解，我认为需要在这里指出一下。但请记住，对这个误解的诠释并不是来否定这个思想的。
多语言电影
让我从一个古怪的类比开始：假设这有一个电影，是关于一个政治阴谋，涉及到一系列复杂的国际冒险，冲突波及到7、8个国家。每个演员都说着他们本地的语言，没有字幕。谁能看懂这个阴谋的情节？恐怕只有少数几个懂得多语言的制片人能欣赏的了这个电影。我们大部分人都不会去看它。
多语言编程
我们的上一个Web应用项目里使用了6、7种的编程语言(Groovy, Java, HTML, CSS, HQL/SQL, Ant)。如果我们感觉需要的话，还可以轻松的再增加更多的语言。再增加Clojure, Scala 或 Ruby/JRuby 并不会觉得不合适。一个懂得多种语言并有能力在多种语言间切换到程序员就被称作“多语言程序员”。
造成多语言项目产生的一个主要理由通常是“使用正确的工具干活儿”的概念。而这个“活儿”通常指的是一个大项目里的一些小任务，比如编译项目，访问数据库，实现永不定型的业务逻辑。对于每个子任务，都有某个语言能够更出色的完成。除了人们对这种多语言的做法造成的隐藏成本存在争议外，还有一个对于“工具”这个词的误解需要注意。
编程语言不是工具
如果我们在一个简单或复杂传统工程中使用一个工具，就比如用锤子把木片钉成橱柜，或用起子拆解计算机，当你完成了这个“活儿”后，工具会被你丢在一旁。你的最终产品(一个新的木橱柜或一堆电路板)并不包括工具。大多时候，当你的活儿干完后，你的产品上不会再有“变更请求”。
如果你的工具碰巧是一种编程语言，那你生产的源代码将和你的工具融合到一起。没有这个工具，你的产品完全不能运行。如果你认为编译后的二进制代码是“产品”，你将没有可能针对它做“需求变更”，这是程序员最初可能会有的一个错误概念。很显然，程序员的生产的产品是“源代码”。编程语言并不是扮演工具的角色，从软件的性质上看，它应该是材料。工具可以扔掉，材料构成主体。
编程语言是产品材料
因为源代码依附于它的编程语言，它们是一个概念上的合体。所以，我建议，当我们在谈论编程语言时，应该改成“使用正确的材料来干活儿”的说法。相比起选择是使用飞利浦的螺丝刀还是三菱的改锥这样的问题，我们修改后的说法会对编程语言的选择起到更深远的意义。材料需要持久的耐用，而工具大部分时间是丢在一边。
但它们也是工具
在上面提到的我们做过的Web应用项目中，我们使用了很多工具。Grails是我们的框架，Jetty是我们的Web容器，Spring Framework提供了强大的服务，我们用IDEA把它们结合到一起。我们可以轻松的用Tomcat替换Jetty，或用Eclipse替换IDEA。工具需要可替换，甚至是一次性的。
总结
“用正确的工具干活儿”这话并不能简单的应用到编程语言上，因为它们不是工具，而是材料。这就是为什么在一个项目中大量使用多语言是危险的。它很容易让项目变成一个混乱的“复合板“项目。
