关于InfoQ的“评论：C#正变得越来越臃肿”的感想

关于InfoQ的“评论：C#正变得越来越臃肿”的感想

有幸在InfoQ的饭局里面认识了王翔，他对.Net和MS技术的确有非常深的造诣。今天看到他的一篇评论： “C#正变得越来越臃肿”
发表了一些感想：

先进与成熟的确是矛盾，但是现在的新技术成熟的都比较快，可能是人接受新事物的速度提高了吧。
Haskell这样的语言是函数式编程的代表，更多的需要从头开始。所以国外学计算机理论首选Haskell，很多老外抱怨过上学的时候这个东西学的头疼，但是后来他们也都表示获益匪浅。我们的计算机教育是本末倒置，所以我们这些程序员觉得他们晦涩难懂。但是看到Erlang这样的语言，在未来多核环境下的前途，我们还是会动摇的。
LINQ的确不错，但是又是M$一言堂。统一数据访问模型是非常好的想法，MS总能后发制人，但是闭门造车很容易被人家超过。现在我们看到LINQ很先进，但是等MS的讲师把它推到实践的第一线的时候，别的开发平台也会有类似的产品出现了。而且，根据标准，查询XML用JQuery，在各种语言里面查询关系数据库也都有众多ORM实现。所以LINQ的想法虽然很好，但是对于其他语言／平台来说却没有非常迫切的需求去实现类似的技术。

关于修改Java JVM的话题不是最紧才有的，下一步会怎样很难说。CLS这个技术不足为奇，其实虚拟机本身就是平台／语言无关的东西，我们已经看到了JRuby、XRuby、Jython和现在的Java Script Engine这样的东西，Java已经在平台化了，这个大家都不会放慢脚步。

关于C#和Java的痼疾，我推荐Bruce Tate的《超越Java》，里面的观点同样适用于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，公共语言规范）。相信Java的设计者不太愿意，也不敢随便为了一个“快速走红”但还没有2年时间市场考验的技术趋势就去修 改Java编译器；.NET不同，“C#红旗不倒的同时，.NET平台可以彩旗飘飘”，比如Spec#就是个例子，为了避免null对于软件的影响，. NET家族诞生了Spec#，目的就是通过非null这个前提，提高数据验证、异常处理、堆栈管理的能力，利于开发者提供更高质量的软件；F#也是，虽然C#是强类型的，但动态语言式的开发一样可以基于这个“小兄弟”开发，加上它和其他.NET语言前辈基于同一个CLR环境，所以功能毫不逊色。

综上所述，C#臃肿是不可避免的，而且很可能会像Visual C++一样，因为语言的复杂性，导致C#开发人员技术能力的两极分化。但同时，借助试验性.NET语言的支持，即便需要集成新的特性，也不会像某些语言一 样从头开始。依靠试验性语言的积累，相信从MSDN中查看C#这些新语法的时候，可以少见一些标着“[Obsolete]”的内容。