論C#變得越來越臃腫是不可避免的)

C# 2.0發布的時候，我們回頭看Java，總認為這個語言怎麼發展得這麼慢?但當C#發展到3.0的時候，它也開始顯示出臃腫之態了，這是否會也會帶來什麼連鎖效應呢? 　　6年前，我是個Java的擁護者，當時C#還是1.0版，我經常和師傅爭論Java如何比C#好，於是他給我一個回答：“我們的COM比Java早了近5年，所以我們更成熟;我們的.NET比Java晚了5年，所以更先進”。雖然這麼比較有“偷換概念”的感覺，但現在想想其實有另一層意思——“成熟與先進”的矛盾。
　　Lisp、Haskell、Scheme這些語言也都可以被稱之為“偉大”，但為什麼很少有人去學呢?因為需要用太多的東西“充斥”我們的大腦後才可以使用。Java和C#之所以可以快速地被普遍接受，一個很重要的原因就是因為它們的簡單與清爽。但當明年春天C# 3.0發布的時候會怎麼樣呢?雖然你可以將WCF、WF、WCS和WPF視為.NET的外掛，不予理會，但LINQ是個不好迴避的內容，因為它在處理資料訪問(關係型的、非關係型的)方面有比較明顯的優勢，所以即便你個人排斥它，其他還是會有很多人用。最後很可能成為這樣一種局面：參與到一個項目組，自己只能從事一些表層業務開發，因為下層的公用封裝機制都是用LINQ編寫的，況且還有Enterprise Library這個“樣板工程”在後面催著。
　　可以這麼說，C#越來越臃腫是個必然的趨勢，作為.NET語言的“主力”，隨著新的開發架構的出現，C#的複雜性還會增加，同時很可能導致革新特性越出越慢，畢竟牽扯的內容多了，作為“主力”除了要考慮語言特性間的協作外，還要充分考慮處理效率。
　　不過比起“一條道跑到黑”的Java而言，.NET平台有個優勢——CLS(Common Language Specification，Common Language Specification)。相信Java的設計者不太願意，也不敢隨便為了一個“快速走紅”但還沒有2年時間市場考驗的技術趨勢就去修改Java編譯器;.NET不同，“C#紅旗不倒的同時，.NET平台可以彩旗飄飄”，比如Spec#就是個例子，為了避免null對於軟體的影響，.NET家族誕生了Spec#，目的就是通過非null這個前提，提高資料驗證、異常處理、堆棧管理的能力，利於開發人員提供更高品質的軟體;F#也是，雖然C#是強型別的，但動態語言式的開發一樣可以基於這個“小兄弟”開發，加上它和其他.NET語言前輩基於同一個CLR環境，所以功能毫不遜色。
　　綜上所述，C#臃腫是不可避免的，而且很可能會像Visual C++一樣，因為語言的複雜性，導致C#開發人員技術能力的兩極分化。但同時，藉助實驗性.NET語言的支援，即便需要整合新的特性，也不會像某些語言一樣從頭開始。依靠實驗性語言的積累，相信從MSDN中查看C#這些新文法的時候，可以少見一些標著“[Obsolete]”的內容。