【導讀】程序員在著手一個項目時，需要做的關鍵決定之一就是選擇一種語言，或是一組語言，用于實施該系統(tǒng)。這一決定不僅會影響系統(tǒng)的實現(xiàn)，也會影響設計。既然這個決定會導致深刻而長遠的結果，那么是不是在做這個抉擇時應該更加務實？很多時候，我們會盲目地偏頗于我們選擇的語言。
例如，我們應該使用面向對象的語言還是過程語言？選擇什么語言對項目以及作為項目一部分的程序的生命周期有著深遠的影響，很多次，我們基于一些非常善變的因素，沒有思考太多 就去選語言：這語言是我慣常用來實現(xiàn)這類系統(tǒng)的；這語言我了解得最透徹；這是我最喜歡的語言，我很享受于用這種語言編程；等等。
既然這個決定會導致深刻而長遠的結果，那么我們是不是在做這個抉擇時應該更加務實？很多時候，我們會盲目地偏頗于我們選擇的語言。而且，有時候我們之所以不喜歡選擇這種語言的原因可能正是為什么我們要選擇那種語言的原因。
如果我們能夠放開胸懷，坦誠地對待自己持有的偏見，那么我們就可以減輕一些類似在裝修時硬要將方釘釘進圓形孔的痛苦。雖然我們沒有什么秘訣來為項目選擇完美語言，但還是可以遵循一些原則，幫助我們做出一個更好，更合適的語言選擇。
沒有完美的語言
這一點對任何人，甚至是新手而言，都是在意料之中的，并且我們很多人都愿意承認，“當然，這種語言并不是完美的語言，”但與此同時，我們很多人還是 會說，“這語言是最好的編程語言”。說一種語言是項目的最好語言的關鍵是項目的背景，也就是說，最好的語言只存在于一定的范圍內。這就是我們的第一條原則：
沒有完美的語言：每一種語言都有它的優(yōu)點和缺點。
例如，許多通常使用運行時語言，如Java或Python的開發(fā)人員，聲稱C或C ++令人透不過氣來，會因為關注例如內存管理這類低層次的細節(jié)，或關心編譯時類型檢查的嚴格粒度，而扼殺分置于開發(fā)人員的職責。這是事實，只要我們正在開發(fā)的項目不關注看似瑣碎的任務，如內存管理或發(fā)生在單一循環(huán)中的copy-assignment的數(shù)量。
相反，如果我們工作在一個項目，或項目的一部分，那么對于代碼應該如何高效以及程序的關鍵性安全的偏見需求是自然而然的，這些看似繁瑣的細節(jié)可能正是我們正在尋找的粒度水平。在這種新的背景下，Java或Python的運行時性質似乎過于漠不關心或過于心不在焉。相反，我們希望當內存分配和釋放的時 候，能夠嚴格控制有多少move-assignment和copy-assignment被執(zhí)行，并在編譯時捕捉盡可能多的錯誤，而不是讓錯誤滲入運行時 （表現(xiàn)為運行時異常）。
雖然在理論上“沒有完美的語言”這一點聽起來是顯而易見的，但是我們作為開發(fā)人員的行為通常會背離這個概念：我們說我們知道我們最喜歡的語言是不完美的，但我們還是繼續(xù)對我們開發(fā)的項目使用這種語言，不管它是否適合。此外，當其他的開發(fā)人員質疑我們選擇的語言時，我們會堅決捍衛(wèi)我們的選擇，而不愿意從他或她的反駁中看見事實的真相。請記住：每一種語言都有它的優(yōu)點和缺點。了解你掌握的語言的優(yōu)點和缺點，然后根據(jù)實際情況做出選擇。
你不喜歡一種語言的原因可能就是你應該使用它的原因
這似乎違反直覺，但有的時候，我們之所以不喜歡一門語言可能正是使用某種語言的原因。還是上面的例子，在我作為一個C ++開發(fā)人員的經(jīng)驗中，很多時候因為有那么多不同的概念要跟蹤（內存管理和對象壽命時間，C ++編程三原則等），以致于完成項目的一個簡單功能都會變得繁瑣不堪。在用C ++開發(fā)幾周之后，使用Python，Java或另一種“更高級”的語言，簡直就像上天的恩賜：但真的是這樣的嗎？
有時候，可能我們不喜歡一門語言的原因正是我們要使用該語言的原因。如果我正在開發(fā)一個驅動程序或一些關鍵性安全，實時的系統(tǒng)，上面表述的繁瑣不堪的原因可能正是這個語言的最大優(yōu)勢。例如，C ++提供了一種機制用于表達當對象被復制時被執(zhí)行的邏輯，這在效率和嚴謹性井然有序的時候是非常寶貴的。
這可能看上去都很好都很棒，因此我們很難確切指出在某個背景下，某種你看不順眼的語言可能反而更有幫助。那么，我們該怎么知道哪些你不喜歡的語言是有幫助的呢？這就引出了我們的第二條原則：
對自己要誠實：知道自己為什么不喜歡一門語言，不要教條化自己的憎惡。
例如，在上面那個C ++的例子中，我之所以不喜歡長時間地用C ++編程，是因為這語言要求思想嚴謹，否則很容易犯錯，就像是被困于叢林中（過多地關注樹木，而不是樹林這個整體）。這種嚴謹會妨礙開發(fā)人員去質疑，如“我要在堆棧上或堆上創(chuàng)建對象嗎，或者部分在堆棧上，另一部分在堆上？”或“要讓這個類可擴展，應該通過模板參數(shù)還是通過繼承？”等決定。在其他語言中， 開發(fā)人員只需分別創(chuàng)建一個對象以及使用面向對象的繼承就可以完成這些任務，然后進入到下一個功能，因為語言（或者，更準確地說，編譯器或解釋器）關注這些細節(jié)。
但是，如果我對自己誠實的話，我會承認，我之所以不喜歡C ++的這些功能，是因為它將表達這些細節(jié)的責任歸咎于我。在其他語言中，我不僅不需要負責這些細節(jié)，而且我也沒有責任表達這些細節(jié)：它們被抽象遠離開發(fā)人員。在一個這些細節(jié)是必不可少的上下文中，我不喜歡C ++的原因正是我應該使用這種語言的原因。
這是否意味著，我們應該愁眉苦臉地使用這些會讓我們對這語言惱怒的功能？也沒有必要。或許你可以換個角度：不要將這些功能當作缺點，也許我們應該擁抱它們，將它們當作完成任務的必需品。我們不應該說“這真是一個悲劇，”而應該說，“謝天謝地，我居然能用這種語言做到這一點。”請記?。涸谀承┍尘跋?，這些功能將是上天的恩賜，而在其他情況下，它們才是累贅。至于為什么不喜歡某一門語言的功能，請誠實地告訴自己。
越熟悉其他語言，越好
對于這一點，就是我們要說的第三個原則：
如果你擁有的唯一工具是一個錘子，那么你看每一個問題都像是釘子。
這條規(guī)則并不適用于軟件工程，但它尖銳地表現(xiàn)了許多軟件開發(fā)的情況。很多時候，我們選擇一種語言，或一種語言支持的工具（如Java的JMS，Python的ASYNCIO，Rails的Ruby等），是因為我們知道它們存在。如果我們唯一熟悉的語言是Java，那么我們會將我們碰到的 所有問題都適應到Java的上下文中。例如，“我需要為一個通信應用創(chuàng)建一個路由框架。在Java中我該怎么做呢？”這就限制了可供我們使用的工具，并人為地限制我們?yōu)橥瓿晒ぷ鬟x擇合適工具的余地。
解決這個問題的方法是擴大你的視野，了解其他語言的的功能和錯綜復雜之處。正如Andrew Hunt和David Thomas在《The Pragmatic Programmer》中給出的建議，一個好的做法就是，每年學習一門新的語言。這可不沒有聽上去那么容易，學習一門語言對不同的人將意味著不同的事情。 還有一個衍生問題是，我們對正在進行中的項目往往只會使用這一種語言，從而使得學習的另一種語言顯得毫無用處。例如，假設我是一個Android開發(fā)人 員，基本上每天只用Java，那么學習C?？赡芫蜁@得不合時宜地浪費時間。
不要被假象所蒙蔽。學習其他語言的優(yōu)勢體現(xiàn)在我們能從不同的角度去看問題，并且使用最適合該問題的工具。為了做到這一點，我們必須學習其他語言的相關警告，以及開發(fā)人員使用這些語言解決問題的方式。例如，如果一個開發(fā)人員想用C ++執(zhí)行元編程，那么他或她可以使用C ++中的Template Metaprogrammming（TMP），但他或她也可以使用Java中的反射。理解其他語言是如何解決類似問題的，可以減少我們認為它毫無用處的風 險。
再說一個例子，如果我們需要能夠改變一個類的運行時特征，那么一個深入熟悉C ++錯綜復雜性的C ++開發(fā)人員，可能會試圖編造一個延伸這個編譯時語言的界限的解決方案。而另一個C ++開發(fā)人員，由于對Java也有一定的了解，就能夠說，“我喜歡C ++，但Java的運行時反射更適合解決這個問題。”
因為有如此之多的編程語言任開發(fā)人員擇選，因此，優(yōu)先安排學習什么語言很重要。不妨從當今最流行的語言入手（可參考《most popular languages on Github》，《Language Trends on Github》，《The 9 most popular computer languages》，《according to the Facebook for programmers》等）。
語言是手段而不是目的
這是第四條，也是最后一條原則，聽上去可能最哲學，但也可以說是最重要的：
編程語言是一種手段，而不是目的。
除非你是一個語言標準的作者或是一個編譯器的作者，否則你就應該將編程語言當作是一種手段而不是目的，目的是完成項目：最終的目標是要完成項目，而不是使用特定的語言。這并不意味著每個開發(fā)人員就無權要求他或她喜歡或不喜歡的語言（實際上，如果我們對自己誠實的話，這些好惡反而能夠讓我們受惠；參見 上面的第二條原則），但我們不應該自欺欺人作出這樣的決定，如，“這對我來說是使用該語言這一功能的一個很好的機會”，除非該語言的功能真正適合項目的需求。
重要的是要記住，語言只是表達如何解決手頭問題的一種方法：請確保你選擇了最能表達解決問題域的語言。
其他需要考慮的地方
下面是一些我們在選擇語言的時候，需要補充考慮的地方：
考慮語言如何與其他語言的交互。例如，如果你認定Python是完成大部分項目的最好語言，但在你的項目中有一個定義良好的組件，需要極高水平的粒度或效率（更適合用C或C++ ），這并不意味著你不能在這個項目上使用Python。相反，考慮使用Python，特定組件用C或C ++寫，然后使用Python C API接口此組件。請注意，要制定這樣的解決方案，我們需要知道Python有一個C API；因此，了解最流行語言的這些功能是很有幫助的。
中間件可以允許使用多種語言。例如，如果有兩個必須進行通信的應用程序，如移動設備和一個服務器應用程序，但這并不意味著它們必須使用相同的語言（當然也可以相同，如果你判斷認為這是最好決定的話）。如果這個移動設備是一款Android手機，而服務器應用程序非 常適合作為一個Python應用程序的話，那么使用一個消息代理，如RabbitMQ，可以讓你在通信的同時使用這兩種語言：Android應用程序可以 使用Java RabbitMQ API，而服務器應用程序可以使用Python RabbitMQ API。
擁抱其他語言的古怪之處。如果你是一個Java開發(fā)人員，那么你會使用包來分隔源代碼的邏輯單元；如果你是一個 Python開發(fā)人員，那么你會使用Python的包結構做相同的事情；如果你是一個C ++開發(fā)人員，那么你會使用命名空間或前綴的類名（即“DZone_MyClassName”）。了解你正在使用的語言的特別之處，并擁抱它們：在羅馬， 就入鄉(xiāng)隨俗。否則的話就像是因為你更喜歡單詞用意大利語發(fā)音，而用意大利口音說德語，這樣就顯得不倫不類了。當然也有可能一種語言的一個功能長期存在，但 是這樣的話，其中必有其原因：確保自己明白其中的道理。
推薦閱讀：
殘酷的現(xiàn)實：主流筆記本電池的續(xù)航和壽命都糟糕
