標籤

code.google.com

2013年4月10日 星期三

糾正對「用正確的工具幹活兒」這句話的誤解——編程語言不是工具

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

多語言電影

讓我從一個古怪的類比開始:假設這有一個電影,是關於一個政治陰謀,涉及到一系列複雜的國際冒險,衝突波及到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」 ]
原文網站: 外刊IT評論

沒有留言:

張貼留言