每次開始一個新項目，無論是一個獨立的程序還是現有計劃的一個組件，都會面臨著一個應該選擇什么樣的編程語言的問題。只考慮之前用過的編程語言或者現在最流行的語言的話，你很可能會得到一個糟糕的結果。所以你應該實時評估自己的選擇，并不斷尋找更好的替代方法。

?

評估一種語言的同時，你還需要考慮項目的整體架構，并不是項目的所有部分都適合用同一種語言來寫。選擇編程語言 的過程，實際上也是你項目初步設計中的一個重要組成部分。如何分解和連接組件也非常受語言選擇的結果影響。有些項目很容易就能看出最合適的語言，相信你能 夠自己得出結論。當然語言也會隨時間而改變，所以兩年前的最佳選擇也許現在已經不再適用，而當初首先被排除的語言反而變成了最佳選擇。

你的團隊有過什么樣的經驗？

雖然顯而易見，但是不得不說，你也許應該選擇自己最熟悉的那門語言。雖然嘗試新的編程語言是一項偉大的創新，但非研究性項目并不是適合試驗的地方。如果你需要預測出項目的時間表，并且避免大規模的未知變數，相信你不會愿意使用任何不熟悉的語言。

這并不是說團隊里的每個人都必須是這門語言方面的專家。你甚至可以讓團隊的一小部分不熟悉這門語言的人加入開發中來保證其他人能有較高的效率。僅僅因為不熟悉項目所需要的語言就把有經驗或者有才華的程序員排除在開發團隊之外實在是非常愚蠢的行為！好的程序員都有不錯的適應能力。當然，即使優先選擇熟悉的編程語言，肯定也有讓你不得不使用陌生編程語言的時候。

有沒有計算開銷大的操作？

比如視頻處理，圖形渲染，密碼學，統計分析，信號處理這些對原始處理能力有巨大需求的功能。他們要執行多長時間直接影響到計算機芯片的使用效率。

對于這些模塊，你幾乎肯定會需要一個靜態類型和編譯的語言。或者簡單地說，這些地方你需要快速的編程語言。不論這是多么罕見的問題，這肯定是會出現的。通常這些性能密集組件是有限的，而且可以很容易地模塊化并且和其他語言組合。

會涉及到許多子流程和文件管理嗎？

很多軟件都是為了自動處理重復的手工勞動而存在的。過程中一步都已經有了個非常適合的程序，你需要做的就是把他們組合在一起，這就是軟件開發系統管理員的主要關注點所在，當然也包括很多保證系統和高級運行的。

在這里，你需要執行其他程序并且進行文件管理，而腳本語言靈活又簡單，并且與生俱來地實現了這些功能，毫無疑問是你的最佳選擇！

有緊張的資源限制嗎？

雖然在一定程度上，現在硬件已經夠用了，但是在某些情況下或者對于某些應用來說，硬件還是十分受限的！這一點在嵌入式設備中尤其明顯。然而不是所有的編程語言都適合受限的硬件環境下開發，你需要一種編出來的程序能夠在那樣的環境下運行的語言。

有時候運行時的內存限制是主要問題，有時候可能加載過程的問題更大！也許你會遇到這樣的問題：你的應用需要從EEPROM或者網絡中初始化，那么你可能需要靜態鏈表或者未修剪的庫。這并不是排除了使用基于VM的語言的可能，相反，有時你甚至需要一個小型的VM。

是否有明確的需求？

不管是什么語言所寫，好的程序總是能夠快速地重構和調整。一些語言本身就可以建立快速原型。而且很多商務項目完全沒有規范，或者極其粗糙，這種情況下，客戶在看到最初產品前完全不知道它應該是什么樣子。你會需要不斷地修改，直到每個人都滿意。

如果你需要在會議中頻繁修改程序來演示或者是為了作一份它的詳細報告，你會發現快速原型非常重要。動態語言在這里很有優勢，它可以很容易地結合多個不相關的庫。當然，隱藏“細節編程"，比如內存管理，也非常有助于建立快速原型。

產品的生命周期有多長？

不是所有語言都是足夠穩定的，許多年輕的動態語言在升級中會變得不向后兼容或者大量修改它的核心代碼。瞬息萬變的項目，決不會真的有這些變化的一個 問題，事實上，許多項目甚至還會從這些變化中受益。因為時間向后兼容性成為一個問題，壽命短的項目也會因此變成沒有人關心的項目。

如果你的產品壽命長達五年，十年，甚至二十或更多年，無法向后兼容的問題可能會成為你的噩夢。我不認為你會想繼續使用過久的編譯器和和其它古老的工 具，特別當它們還跟老的硬件掛鉤時。項目支持新的版本或者新產品肯定會讓你受益。這個時候你最需要的肯定是一個有標準委員會管理，并以長期支持和向后兼容 為目標定制的穩定的語言。

需要支持什么平臺？

不是所有的語言都適用于所有平臺。如果目標設備不支持你喜歡的語言，那么你肯定是沒法使用它的！當然你也不能信任實驗性的支持。你喜歡使用C語言， 而目標OS上也有C編譯器也并不一定意味著它會很合適。定制化的芯片或者甚至是GPU之類有時只支持部分語言產生出來的二進制文件。

芯片組兼容性問題并不唯一，對于需要同時工作的其它軟件也一樣。比如你需要在用戶的瀏覽器中運行代碼，那就沒有多少語言可供選擇了。某些消費設備供 應商也只允許部分語言在自己的平臺上使用。 服務供應商往往只專注于某些語言和框架，而并不在意別人的因此帶來生的犧牲。如果你打算為Linux編寫設備驅動程序，你會發現它的內核小組只支持一種語 言。你可以宣傳你的想法會帶來怎樣的好處，但如果你想支持某些特定平臺，別無選擇，只能遵守該平臺的意愿。

是否會有大量的位操作？

文件格式和協議相關的工作往往會需要對字節和位操作。您將需要轉換格式到更高級的格式，然后再序列化成一個緊湊的格式。一些算法也會需要對數據進行位操作。最低級的線路協議也會根據你的行為對比特流進行操作。

做這樣的工作，你需要一個能夠很容易地進行位操作并且能夠提供合適數據類型（比如無符號整數類型）的語言。但也并非所有的二進制操作都這么麻煩，某 些二進制結構就很簡單，甚至經過高級包裝的函數都可以對它們進行操作。你需要仔細審查自己的工作對二進制操作的需求，然后選擇一個不太麻煩的編程語言。

是否涉及到某些特定領域？

不是所有問題的最佳語言都是一樣，有很多非常具體的領域存在的專業語言。比如：人工智能、文本解析、數據轉換、專家系統、數學、財務分析等等。領域特定語言往往以節省大量的編碼工作，而不會產生大的缺陷，所以你應該盡可能使用它們。在這里，你不妨選擇專業語言來代替你熟悉的編程語言。

領域特定語言的使用在一定程度上也限制了你可以在項目中使用的其他語言。一些被翻譯成另一種語言，而另一些則可以作為可調用模塊。無論哪種方式，你還需要某種方法來整合。

如果存在一個優秀的庫也適用這一原則。無論它依賴哪種語言，我都建議你去使用它！

結論

要作出一個明智的選擇，你會需要了解足夠多的語言。如果你僅僅關注某一門編程語言，你會被這門語言以及它的思想 牢牢拴住。但相比于語言來說，它們的風格可能更重要。良好地組合靜態和動態語言/函數式和命令式/高級和低級語言，再考慮具體領域環境的特點，你才能評估 出最適合答案。在選擇語言之外，你還需要足夠的經驗來最佳地利用你最后確定的語言。

當然上面也只是給你一個粗略的參考。很不幸的是第一條規則，也就是團隊熟悉什么語言，通常才是實際上左右語言選擇中的最終結果的因素。盡可能地把項目分解開來，然后給每一個組件尋找一個最合適的語言，至少以我多年經驗來看，組合使用多種語言從沒有帶來過什么壞處。

你可能會認為，只考慮上述因素也并不一定能確定下語言。事實上，這樣通常注意是排除不合適的語言而不是增加新的選擇。項目按組件拆分，給每個組件選 擇最合適的語言，最終你選擇語言的標準會越來越嚴格，直至剩下一兩個最佳答案。但如果你不分解項目，你能得到只是一兩個相當糟糕的選擇，通常按模塊分解項 目會是更好的選擇。

原文地址：http://mortoray.com/2012/05/29/how-to-choose-a-programming-language/

轉載于:https://blog.51cto.com/xuqin/890268

總結

以上是生活随笔為你收集整理的为项目选择合适的语言的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。