漫談開發語言的選擇
在軟件這個行業里，怕是沒有任何一個其話題域像開發語言這樣引起爭議了。對開發語言是非的爭論，不單曠日持久，且深度亦是與時俱進。
實現要強調下的是，在這里我們要專注的是開發語言的選擇而非開發語言的優劣。
從不同的視角對開發語言進行選擇，其結論可能大相徑庭。
從項目的角度看，語言自身特性的多少，強弱往往并不成為一個關鍵選擇因素。好比說某語言支持多重繼承，而某語言不支持多重繼承，但對大多項目而言多重繼承這一語言特性并不成為選擇的決定性因素。從項目角度看，某些通常被考慮(或不得不考慮)的因素有：
歷史的原因。維護升級類項目這類沒有選擇的選擇自不必提，這里說的歷史的原因是指這樣一類情形：完成某個項目需要某一圖形算法庫，而公司中只有這類庫的C++靜態庫。這個時候也許可以再做一層封裝，但從省力的角度看，很多人可能更愿意選C++。
現實的具體的原因，也就是說非這種語言不可的情形。做C51程序的話，恐怕大多數人都會直接想到用C。或者面對需要指針直接對內存進行操作的情形，很多人也自然的會想到C/C++。
既有類庫(組件等)的豐富程度。比如Windows下，.net中提供的類庫要比非管態的C++中多很多。同等情形下，很多人出于生產率的考慮，恐怕會選C#，而不是非管態的C++。
配套工具。IDE的豐富程度，單元測試工具，靜態測試工具等等。
其他還有現有人員的技能，目標性能等因素。極端情形下，團隊成員水平較差，那同等條件下就要避免復雜的語言。
總而言之，在做項目的時候，開發語言的選擇往往并不是由語言自身特性的多寡而確定的。通常也并不需要做語言特性的完整比較，而后再做選擇。
其中一個根本原因在于：就通用編程語言而言，大多的最常用的語言特性是即被這種語言支持，也被那種語言支持的，否則的話這種語言也就不能成為一種通用編程語言。
如果單純從學習的角度看，那需要考慮的因素與上述不同。
在學習階段，當我們編制某個程序的時候，與程序結果相比，更應該關注的是過程，也就是究竟學到的是什么。
就編程而言，不論編制任何程序，在學習的階段，其根本目的更應該是加深我們對編程所面臨的本質問題的體會。這也就可以推導出學習階段編程語言選擇的一些基本約束：
遠離RAD。在這里RAD包括，但不限于可視化編程，應用框架等等。RAD相關聯的東西可以幫助我們快速達到結果，但會減少我們對程序本質進行思索的機會。因此和RAD關聯過于緊密的語言，不適合作為學習的語言
選一種支持多范式的，支持大多現代語言特征的編程語言。強調多范式的一個根本原因是很多時候我們要知道我們究竟有多少選擇。就一般論而言，偏于一極通常是不對的，所以強調一切皆是對象的語言必然因此導入其他限制。至少我們應該知道世上還有結構化分析和設計方法。強調現代語言特征是因為，我們很難在不支持類的語言中學習面向對象，在不支持模板的語言中學習泛型
選一門可以貫通軟硬件的語言。在今時今日開發網頁的時候可能完全不需要對計算機體系結構，對操作系統有所了解。但從發展的角度看，一旦我們需要對某些較大規模的產品整體負責的時候（比如：系統集成等等）了解這些基礎知識的必要性就會凸顯出來。從結局來看，肯定不可能每個士兵都成為元帥，但在起點上就決定了一個人必須一直當士兵的安排，多少是有點不恰當的。
讀完上面的原則，很多人會發現，最終可能還是C++這類非管態的語言更適合于打基礎。
這確實是我的觀點。從學習的角度看，***語言應該是C++。在很多場合C++自身的寬泛性和復雜性會成為其自身的弱點，但從學習的角度看，這卻成為它的強項。C++的C語言子集可以幫我讀懂類似《深入理解計算機系統》這樣的書，C++的抽象數據類型，面向對象特征和泛型特征可以讓我們對程序的本質問題有多個視角的考察。甚至這門語言也可以幫助我們認識面向對象這樣一種方法的缺陷。
原文鏈接：http://www.cnblogs.com/daoshi/archive/2012/06/11/2544473.html
【編輯推薦】
