C#与.net发展趋势和预测
因为我们左右不了c#和.net的发展，所以我们对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(array process language)语言，是多么的简洁，取得的成功是多么惊人，看看科学家和工程师使用的科学计算语言，就明白了。科学工程是多么的需要这种 循环黑盒子。
实际上程序的主要工作，都在循环上，而且规律性极强。例如，我们要计算所有员工的月底工资奖金，我们先算一个人工资奖金，然后再用循环处理。
因为循环有自身的规律性，所以不应该由程序员来写代码，在更高级（高阶）的环境中，循环应该是一个黑箱。
所以为了把循环当作黑箱处理，辅助集合数据（数组，矩阵，向量，序列等等，怎么叫多可以）的表示和应用是基础，而算法的自动生成是关键。
只有把集合当作基本数据类型，循环作为单个操作，并自动优化循环算法（例如并行计算，延迟计算），这门开发语言，才从面向过程，面向算法，上升为面向问题的智能语言，“脱离低级趣味”。
在大学学测量平差的时候，我用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
2. 基于泛型的控件: T TextBox
3. 泛型间数据类型的转换。为了安全和简单，C#现在禁止泛型间数据类型转换。但实际上，泛型间的数据类型转换，是安全有效的。只要编译器检测所应用的类型，有没有重载对应类型的构造函数和转换函数即可。
4. SilverLight，compact framework，macro framework和普通的.net framework之间的兼容和互操作，也是一个必须改进的方面。子集和超集（父集），必须完全兼容和互操作。Vista，因为这个问题，而应用受限。
5. silverlight和C#与html的集成，以及silverlight与数据库、服务器的交互，严重阻碍了.net在网络上的应用。C#应该像js操作html那样操作DOM。
6. .net的可选安装。飞信用.net开发了那么久，都不敢安装.net。我们开发的应用程序，应该可以让用户只安装必须的类库，做到just in time install (JII)
7. 基于组合的winform开发框架，而不是目前的传统的基于继承的开发框架，能方便界面的快速有效开发。例如，我们把treeivew作为一项，直接放入combobox，把DateTimePicker直接放入ToolStrip中，基于组合的框架，支持直接Items.Add(),而不用写个自定义的继承的类。
8. 基于集合的控件和基于组合的控件开发框架，对程序自动生成，能大大提高效率。所有的控件，都有过数组版本。这可以通过加入对应控件的集合版本，如RadioButtonList,，TextBoxList,，或者提供泛型控件集合。
9. 类似于VBA的二次开发，把.net带入工业批处理时代。VSA（visual studio for application）已淘汰, VSTA ( visual stdio tools for application)不成熟。传统的CAD,GIS，OFFICE软件，在规划，设计，办公，计算领域，多用VBA进行二次开发，进行工业自动化，创造的价值，远远大于软件本身的售价。
10.
等着你补充…
凭微软孤军奋战，路还很长…，梦还很远…
PS: Linq2Spatial，或者类似的地理计算，也是一个非常重要的方面，微软的virtual earth, google的maps，earth的在线地图服务，创造了无以计数的应用。在前段时间的日全食观测中，我就是利用google maps来给全国各地的朋友提供信息。数字地球是整合资源信息的框架，esri最先看到了，Oracle领头了(oracle spatial)，google最时髦的冲到了前锋(google maps,google earth)，微软紧跟其后（ms spatial, ms virtual earth)，中科院遥感所、地理所、国家测绘局，武汉大学也死死的跟着，但力不从心。虽然我觉得过于庸俗，但这里还是引用这样一句大家耳熟能详的话：“信息的80%都与地理位置有关”。其实这个数字是保守的。我们考虑自然界和生命体的层次：基本粒子（原子核，质子，中子，电子），原子，分子，细胞，组织，器官，个体，物种，种群，群落，生态系统，区域，全球，太阳系，银河系，宇宙这个人类生存的系统，就会发现，从器官以下的层次，基本属于物理，化学、生物，电子等领域，与地理信息无关，而从个体，物种，直到银河系，宇宙，我们都需要获取时态的空间地理信息。但没有多少人明白，这其中的基础，坐标系是怎么建立的（球心坐标，投影坐标，各种投影坐标的转换和应用），前房交会，后房交会，侧方交会，球面几何的计算。“我在哪里？从哪里来？到哪里去？怎么走?"，这是地理信息系统需要解决的问题，也希望我们能够在日常计算方便集成面向对象的地理计算。