開發語言的選擇

 

在軟體這個行業裡，怕是沒有任何一個其話題域像開發語言這樣引起爭議了。對開發語言是非的爭論，不單曠日持久，且深度亦是與時俱進。

 

實現要強調下的是，在這裡我們要專註的是開發語言的選擇而非開發語言的優劣。

 

從不同的視角對開發語言進行選擇，其結論可能大相徑庭。

 

從項目的角度看，語言自身特性的多少，強弱往往並不成為一個關鍵選擇因素。好比說某語言支援多重繼承，而某語言不支援多重繼承，但對大多項目而言多重繼承這一語言特性並不成為選擇的決定性因素。從項目角度看，某些通常被考慮(或不得不考慮)的因素有：

 

•  曆史的原因。維護升級類項目這類沒有選擇的選擇自不必提，這裡說的曆史的原因是指這樣一類情形：完成某個項目需要某一圖形演算法庫，而公司中只有這類庫的C++靜態庫。這個時候也許可以再做一層封裝，但從省力的角度看，很多人可能更願意選C++。
• 現實的具體的原因，也就是說非這種語言不可的情形。做C51程式的話，恐怕大多數人都會直接想到用C。或者面對需要指標直接對記憶體進行操作的情形，很多人也自然的會想到C/C++。
• 既有類庫(組件等)的豐富程度。比如Windows下，.net中提供的類庫要比非管態的C++中多很多。同等情形下，很多人出於生產率的考慮，恐怕會選C#，而不是非管態的C++。
• 配套工具。IDE的豐富程度，單元測試工具，靜態測試載入器等等。
• 其他還有現有人員的技能，目標效能等因素。極端情形下，團隊成員水平較差，那同等條件下就要避免複雜的語言。

 

總而言之，在做項目的時候，開發語言的選擇往往並不是由語言自身特性的多寡而確定的。通常也並不需要做語言特性的完整比較，而後再做選擇。

 

其中一個根本原因在於：就通用程式設計語言而言，大多的最常用的語言特性是即被這種語言支援，也被那種語言支援的，否則的話這種語言也就不能成為一種通用程式設計語言。

 

 

如果單純從學習的角度看，那需要考慮的因素與上述不同。

在學習階段，當我們編製某個程式的時候，與程式結果相比，更應該關注的是過程，也就是究竟學到的是什麼。

就編程而言，不論編製任何程式，在學習的階段，其根本目的更應該是加深我們對編程所面臨的本質問題的體會。這也就可以推匯出學習階段程式設計語言選擇的一些基本約束：

 

•  遠離RAD。在這裡RAD包括，但不限於可視化編程，應用程式框架等等。RAD相關聯的東西可以協助我們快速達到結果，但會減少我們對程式本質進行思索的機會。因此和RAD關聯過於緊密的語言，不適合作為學習的語言。
•  選一種支援多範式的，支援大多現代語言特徵的程式設計語言。強調多範式的一個根本原因是很多時候我們要知道我們究竟有多少選擇。就一般論而言，偏於一極通常是不對的，所以強調一切皆是對象的語言必然因此匯入其他限制。至少我們應該知道世上還有結構化分析和設計方法。強調現代語言特徵是因為，我們很難在不支援類的語言中學習物件導向，在不支援模板的語言中學習泛型。
•  選一門可以貫通軟硬體的語言。在今時今日開發網頁的時候可能完全不需要對電腦體繫結構，對作業系統有所瞭解。但從發展的角度看，一旦我們需要對某些較大規模的產品整體負責的時候（比如：系統整合等等）瞭解這些基礎知識的必要性就會凸顯出來。從結局來看，肯定不可能每個士兵都成為元帥，但在起點上就決定了一個人必須一直當士兵的安排，多少是有點不恰當的。

 

 

讀完上面的原則，很多人會發現，最終可能還是C++這類非管態的語言更適合於打基礎。

這確實是我的觀點。從學習的角度看，慣用語言應該是C++。在很多場合C++自身的寬泛性和複雜性會成為其自身的弱點，但從學習的角度看，這卻成為它的強項。C++的C語言子集可以幫我讀懂類似《深入理解電腦系統》這樣的書，C++的抽象資料類型，物件導向特徵和泛型特徵可以讓我們對程式的本質問題有多個視角的考察。甚至這門語言也可以協助我們認識物件導向這樣一種方法的缺陷。

 

這是完全不功利的觀點，一旦結合起來那個有助於賺錢，那就是另一個複雜的話題了，一時半會說不清楚的。