糾正對“用正確的工具幹活兒”這句話的誤解

　　讓我以一個免責宣告來開始這篇文章：我絕對的認可懂得多種程式語言的價值，也認為“用正確的工具幹活兒”是個好思想。但在程式設計工作中，人們對這個概念有個誤解，我認為需要在這裡指出一下。但請記住，對這個誤解的詮釋並不是來否定這個思想的。

　　多語言電影

　　讓我從一個古怪的類比開始：假設這有一個電影，是關於一個政治陰謀，涉及到一系列複雜的國際冒險，衝突波及到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。工具需要可替換，甚至是一次性的。

　　總結

　　“用正確的工具幹活兒”這話並不能簡單的應用到程式語言上，因為它們不是工具，而是材料。這就是為什麼在一個專案中大量使用多語言是危險的。它很容易讓專案變成一個混亂的“複合板“專案。

　　英文原文：The fallacy of “the right tool”