預測C#與.NET發展趨勢
在軟件領域，我們有兩個極端：1是什么事情都動手解決，從邏輯角度，“C#什么都能做”，可以把“c#”換成c,c++,vb，甚至匯編，基本上都是對的，但這本身沒有多大意義。其實我們更關心，這門語言，有沒有從語言特性上對這種開發提供支持。比如用bool類型，比c中用0,1表示false，true要“安全”得多。2是“等一等看一看靠一看”的“等看靠”思想。例如，以前c#1.1的時候，我們等著微軟出泛型；c#2的時候，等微軟出linq，silverlight；C#3的時候，等微軟出動態。因為我們沒法直接與MS高層交流，所以我們除了“等呀等，盼呀判”，還能做什么呢？
我們有很多的理想和抱負，個人不能實現，而微軟能實現我們那些夢想的部分，是一種非常美好的事情。
對C#和.net的發展，其實我們也可以反思，批判，提出建議，做出預測。
C#和.NET發展趨勢，最終的目的，是提高開發效率，更加智能。具體的，包括重用，可維護性等等。
那么怎么才能提高開發效率呢？
我們知道，從語言基礎平臺來看，程序開發主要分為算法和API（在.net中表現為類和類庫）。提升效率，應該從這兩方面下功夫。
算法邏輯就三種，順序，判斷（分支），循環。對于循環，C#和Java基本上都沒有努力。雖然LINQ部分地輔助了集合的開發，但離面向集合（數組，矩陣，向量，序列等等，怎么叫都可以）的通用集合開發，還差的很遠很遠。VB簡單地引入了數組字面常量，使得數組的開發，變得簡潔一點。像matlab,r,sas,apl(arrayprocesslanguage)語言，是多么的簡潔，取得的成功是多么驚人，看看科學家和工程師使用的科學計算語言，就明白了。科學工程是多么的需要這種循環黑盒子。
實際上程序的主要工作，都在循環上，而且規律性極強。例如，我們要計算所有員工的月底工資獎金，我們先算一個人工資獎金，然后再用循環處理。
因為循環有自身的規律性，所以不應該由程序員來寫代碼，在更高級（高階）的環境中，循環應該是一個黑箱。
所以為了把循環當作黑箱處理，輔助集合數據（數組，矩陣，向量，序列等等，怎么叫多可以）的表示和應用是基礎，而算法的自動生成是關鍵。
只有把集合當作基本數據類型，循環作為單個操作，并自動優化循環算法（例如并行計算，延遲計算），這門開發語言，才從面向過程，面向算法，上升為面向問題的智能語言，“脫離低級趣味”。
在大學學測量平差的時候，我用FoxPro來實現線性代數的各種基礎運算。
大三學數值分析時候，自己用C語言寫了一些算法，同時也給同學做作業，補考之類助人為樂的事情。
其中學數據結構，書上的每一個算法，都自己先寫算法，再對照書，然后改進，這些算法，都寫了三遍，形成了多個版本和多種實現算法，用過的白紙，對起來有半尺。
2002年，畢業設計做“GPS似大地水準面的二次曲面擬合”，用的是自寫的C++的矩陣實現。這個C++矩陣類，成了我博客的第一篇博文。
工作時，用C++寫了道路橋梁曲線坐標放樣程序，是一個比較實用的功能，可以求出任意公里樁，任意寬度的，任意曲線類型的半徑。
在研究生階段，再學數值分析的時候，使用的是MatLab版本，把書上的所有的算法，自己完全實現，并與書上對比，又進行了改進，寫得非常認真工整。現在這本數值分析的MatLab算法，還在我的桌子上，舍不得丟棄。那些稍微復雜的算法，用c/c++,基本上都要幾百行，甚至幾千行代碼，而用matlab，幾句話，大部分也就20來句，就做的非常漂亮。
再后面廣義測量平差，GPS坐標計算，計算量太大，用c/c++，憑個人精力，基本上是不可能去實現的。matlab成了不二選擇。
其后學生物統計，接觸了R語言，APL語言，對基于集合的編程，深有體會。
為了簡化判斷（分支），C#和java都引入了bool型。但很多判斷，是事先并不確定的。代數計算器的編寫，就是一個簡單而又典型的例子。在C#里，有多種方式，來實現簡單計算器。在大話設計模式里甚至用工廠模式來討論（個人有些反感這種模式，更反感接口的使用，大部分是過度設計）。其他如語法詞法樹，微軟的msscript.ocx,利用動態語言(如python，javascipt)等方式，也是用得比較多的，簡單的計算，可以利用DataTable的Evaluate來進行某些有限的計算。
動態語言中，一句話就能解決的問題，對C#和.net程序員，卻傷透了腦筋。
只有引入動態特性，動一點，再動一點，我要搖擺，在我的地盤我自由地跳。“能靜則靜，想動就動”，“靜如處子，動如脫兔”，“上得廳堂，下得廚房，進得閨房”，是每個程序員的夢中情人。FoxPro，JavaScript，Python，Basic等經典的動態特性，是多么引人入勝，遐想聯翩呀！
至于API（或者類庫），一些是通用的，一些是面向領域的，還有考慮輕重緩急之分。從2002面世，C#和.net走過了7個年頭，應該歲數不小了。但類庫還是相當的缺乏(相比vb,delphi，c等傳統語言）。CodePlex的項目雖然也不少，但成氣候的真沒幾個。
數學類庫是一切邏輯思維的基礎和最大工具。.net應該大量加入數學（代數、幾何、離散數學、線性代數，概率和數理統計）類庫。而現在的.net類庫中，只有簡單的離散數學（數據結構和算法是一部分離散數學的表現和實現）。GIS空間數據庫，可以看成是球面幾何的應用。融入了大量的數學類庫，C#和.net就將會在包括電信，醫療、經濟、衛星、測繪、生物、規劃，CAD，設計等科學工程領域迅速擴大市場。
其實C#和.NET發展趨勢還有很多需要發展的地方：主要包括
1.基于泛型的數據集，（DataTable<T>,DataColumn<T>）
2.基于泛型的控件:TTextBox<T>,而本質上，TextBox只能輸入字符串，在TextBox中怎么確定輸入的字符串合法，并得到正確的對象值，而不是字符串呢？即TTextBox<T>.Value。其實泛型控件的實現也很簡單，答案是構造函數。利用構造函數或類型轉換函數實現，如果沒有重載構造函數，或者重載轉換函數，輸入值失敗。同樣，TComboBox<T>.Item[intindex]也是我們需要的。我剛才在使用ComboBox.Items[intindex]的時候，卻需要使用強制類型轉換，還要考慮()轉換，還是as轉換，因為值類型（如struct）是不能用as轉換的，要多使用兩個闊話，很是丑陋.
3.泛型間數據類型的轉換。為了安全和簡單，C#現在禁止泛型間數據類型轉換。但實際上，泛型間的數據類型轉換，是安全有效的。只要編譯器檢測所應用的類型，有沒有重載對應類型的構造函數和轉換函數即可。
4.SilverLight，compactframework，macroframework和普通的.netframework之間的兼容和互操作，也是一個必須改進的方面。子集和超集（父集），必須完全兼容和互操作。Vista，因為這個問題，而應用受限。
5.silverlight和C#與html的集成，以及silverlight與數據庫、服務器的交互，嚴重阻礙了.net在網絡上的應用。C#應該像js操作html那樣操作DOM。
6..net的可選安裝。飛信用.net開發了那么久，都不敢安裝.net。我們開發的應用程序，應該可以讓用戶只安裝必須的類庫，做到justintimeinstall(JII)
7.基于組合的winform開發框架，而不是目前的傳統的基于繼承的開發框架，能方便界面的快速有效開發。例如，我們把treeivew作為一項，直接放入combobox，把DateTimePicker直接放入ToolStrip中，基于組合的框架，支持直接Items.Add(),而不用寫個自定義的繼承的類。
8.基于集合的控件和基于組合的控件開發框架，對程序自動生成，能大大提高效率。所有的控件，都有過數組版本。這可以通過加入對應控件的集合版本，如RadioButtonList,，TextBoxList,，或者提供泛型控件集合。
9.類似于VBA的二次開發，把.net帶入工業批處理時代。VSA（visualstudioforapplication）已淘汰,VSTA(visualstdiotoolsforapplication)不成熟。傳統的CAD,GIS，OFFICE軟件，在規劃，設計，辦公，計算領域，多用VBA進行二次開發，進行工業自動化，創造的價值，遠遠大于軟件本身的售價
10.NET發展趨勢
等著你補充…
憑微軟孤軍奮戰，路還很長…，夢還很遠…
PS:Linq2Spatial，或者類似的地理計算，也是一個非常重要的方面，微軟的virtualearth,google的maps，earth的在線地圖服務，創造了無以計數的應用。在前段時間的日全食觀測中，我就是利用googlemaps來給全國各地的朋友提供信息。數字地球是整合資源信息的框架，esri最先看到了，Oracle領頭了(oraclespatial)，google最時髦的沖到了前鋒(googlemaps,googleearth)，微軟緊跟其后（msspatial,msvirtualearth)，中科院遙感所、地理所、國家測繪局，武漢大學也死死的跟著，但力不從心。雖然我覺得過于庸俗，但這里還是引用這樣一句大家耳熟能詳的話：“信息的80%都與地理位置有關”。其實這個數字是保守的。我們考慮自然界和生命體的層次：基本粒子（原子核，質子，中子，電子），原子，分子，細胞，組織，器官，個體，物種，種群，群落，生態系統，區域，全球，太陽系，銀河系，宇宙這個人類生存的系統，就會發現，從器官以下的層次，基本屬于物理，化學、生物，電子等領域，與地理信息無關，而從個體，物種，直到銀河系，宇宙，我們都需要獲取時態的空間地理信息。但沒有多少人明白，這其中的基礎，坐標系是怎么建立的（球心坐標，投影坐標，各種投影坐標的轉換和應用），前房交會，后房交會，側方交會，球面幾何的計算。“我在哪里？從哪里來？到哪里去？怎么走?"，這是地理信息系統需要解決的問題，也希望我們能夠在日常計算方便集成面向對象的地理計算。
【編輯推薦】
