[转贴]失去信心？还是再度迷惘
Eric Liu, 2006年3月16日凌晨2点于京城
对于最近沸沸扬扬的讨论，相信大家对于NET expert: Microsoft is losing confidence in .NET 已经有所耳闻，一向支持.NET的技术专家Richard Grimes的突然反戈在本来就不平静的技术社区掀起了轩然大波。有些戏剧性的是战火是在TSS.COM而非TSS.NET挑起的，作为.NET社区开发人员，可以说是一种悲哀，除了可以归结为Java Fans的无聊之作揖外，看来更多的是我们需要去反省自己的思维是否如Java社区般的活跃。
我的朋友孟岩先生也写了名为《.NET面临信任危机，根源在于目标模糊》的个人评论，总体来说他将.NET的遭遇的信任危机归结于微软自身对于.NET战略的定位模糊导致。2004年我曾经写过一个长篇的.NET战略探讨《在蹉跎中一路前行》，个人总体认为.NET经历了一个狂热到迷惘、再到务实，然后一步一步走向成熟的过程。2004年写那个Post的时候期待是2005年中.NET迎来成熟应用的鼎盛时期。
坦白而言，没有我期待中的那样顺利，就如同Longhorn一次又一次的裁减功能，一次又一次的推迟发布日子那样让人急不可耐。Richard老兄看来也是经受不了这样的煎熬，所以在DDJ抛出了那样令人惊世骇俗的论调，一时之间Java vs .NET的争端再起，微软为了挽回一些。。。。。。。。。。。。。，Visual C#的项目经理Dan Fernandez也对此作出了自己的回复，我无意去卷入这场没有结果的纷争，去评论Java or .NET的孰优孰劣唯一能够得到的是加剧凉两派的怒火。对于Java或者说J2EE，我的了解太过有限，所以也不敢轻易下什么结论。对于.NET，对于微软，因为曾经工作的关系，相对有些了解，因此下面的文字仅仅是针对Richard Grames的文章和TSS.COM上面相关的讨论有些自己的理解。不是Microosft的卫道者，也不是抨击者，谨代表个人意见
Everything rewriting in .NET is Stupid？
我似乎想不出任何理由需要微软去.NET去重写所有的代码，尤其是Office这样的产品，已经拥有了那么成熟稳定的版本，假如组织人力使用.NET重新编写，除了可以去宣传微软的大款和愚蠢之外，我似乎找不到更好的词语去送给他们了，好在微软还不是那样的傻瓜。已经拥有一个非常能够给他们带来远远不断财富的“造钱工具”，重新编写仅仅是为了炫耀？
有人说.NET是一个虚拟操作系统，在我理解的范围内绝对不是如此的，相反，微软是希望通过.NET的推广将更多的开发人员绑定在Windows操作系统之上，一些最重要的类库如ASP.NET、GDI+等等都需要调用操作系统特有的API来实现的（相信大家对于win98下面无法运行asp.net有所了解），对于一些平台出现的问题，微软的文档给以的解释是“需要使用到某些底层API”。OK，漂亮而邪恶的解释，你尽管可以抱怨原先的Win32 API怎么不好用，可以抱怨MFC设计的太糟糕，但是莫要忘记了一切都是微软给你提供的编程接口，那么.NET做什么呢？首先是做一个包装，让你可以更加方面的进行应用开发，Richard说的一点都不假，.NET的很多类库都是从VB和MFC(应该更多的是WFC)迁移过去的，如果大家有兴趣去看看System.Web.Mail这个命名空间的类实现，如果利用一些反射工具如Reflector，你就可以意外的看到这个所谓的邮件类仅仅是CDO.Message的包装，假如没有cdont.dll和cdosys.dll，你的MailMessage没有理由能够很好的工作。这样的情况在.NET类库中是很多可以看到的，包括Richard提到的EventLog。
请不要抱怨Microsoft欺骗了你，永远不要去相信商业产品的所谓百分百，基于向下兼容和保护已有类库的应用，微软没有理由要整个.NET类库用C#或者VB.NET这样的语言来编写，我们不要去讨论可以不可以，首要考虑的是必要或者没有必要，答案一目了然，NO。
微软对于后续产品都提供.NET的托管包装是一种临时性的策略问题，从营销的角度考虑，微软需要有一个统一的“.NET Inside”去给以开发人员足够的信心，但是在他的能力范围之内，不太可能对于2000之后发布的产品都“Embed .NET”，所谓.NET的COM+互操作和P/V Invoke技术一半是给开发人员提供的，一半是留给他们自己用的，因为从商业的角度而言，他们需要有一个统一的技术去完成基于COM/COM+应用的系统能够平稳的迁移到他希望的.NET平台。从技术的角度而言呢，微软提供的一些托管包装如Office 2000的互操作类库等更多的是为了给.NET开发人员提供一个访问既有系统的入口。对于宣传的初期，有了这些技术和宣传的概念，对于这个庞大的“.NET战略”而言已经足够，因为大多营销人员花时间去给客户解释“What’s .NET”上面去了。
上面提到了.NET CLR算不上一个真正意义的VM，因为这个VM太多的工作只是完成了对于Win 32的API封装和抽象，一些核心技术还是构建在原有的技术如COM+,MSMQ等等之上，在.NET世界里这些东西仅仅是盖头换面成Enterprise Services,Messaging等等不同Namespace下面的托管类，那么谁都知道真正改变的有多少，至于ASP.NET和ADO.NET还有一些其他技术，那么就另当别论了。那么你会问我CLR干么，对于微软征服世界的基础是将所有的应用全部绑定在Windows操作系统之上，而.NET CLR则让这一些变得更加自然，因为大多开发人员会更加开发windows程序更加简单方便，更加“爽”，爽到后面的结果就是不想用其他技术了J
不同于Java VM设计的初衷就是能够独立于操作系统之上提供服务，.NET从这个角度来看更加是一个寄生的“VM”。很多人抱怨.NET没有一个类似于应用服务器的概念，如果你接受过微软一些工程师的培训或者听过他们的演讲，他们会振振有辞的告诉你，.NET是有应用服务器的，因为Windows本身就是应用服务器，如群集、故障转移、负载平衡、事务、异步消息等等都是在操作系统层面上提供的。从设计的理念来看，.NET和Java是完全方向的，Java实现是首先设计了VM，然后在VM的基础上创建应用服务器，因此所有构建在Java之上的应用都是可以在应用服务器之间进行迁移的，OK,.NET是首先构建了应用服务器，然后.NET CLR提供了对于应用服务器的访问包装，你也可以说这些应用服务都是可以迁移的，对，在应用服务器之间进行迁移没有任何问题，对了，我差点忘记了，.NET的应用服务器是Windows操作系统，那么对不起，只有在Windows OS之间迁移你的应用了。
这就是微软最本质的.NET策略，一个提供了对于Windows良好包装的运行时（不是框架），那么对于成熟的产品非得一定要用.NET重写吗？包装已经完全足够，重写略显多余，可惜在一些包装上微软到目前依旧没有作的很好，Exchange是一个很好的例子。
Rewritting in .Net is stupid?
VB.NET is not VB?
不知道在这点上，有多少人可以赞同我的看法，我不敢去妄下结论VB.NET的推出是因为技术的考虑还是因为市场的考虑。在Windows开发中，VB和VBScript应该属于一个无处不在的语言了，作为一个顶尖的Windows开发人员，你喜欢也好，厌恶也罢，但是有一点你不得不承认，如果一点都不会这种可以不声明变量的语法，注定要接受一些煎熬，假如你需要写一些Windows脚本程序，假如你要操作Office,还有很多假如…..虽然很多人鄙视做VB的开发人员，因为他们认为大多VB程序员都是不入流的，只是会用VB的IDE拖放几个控件，然后双击集中的按钮编写所谓的click事件。
假如你对于VB的理解仅仅停留于此，那么我只能够说你确实不懂这门语言，你看见的仅仅是迷雾，而不是令人仰止的高山。VB(这里说Visual Studio 6的VB)准确的说是一门Component-Base的语言，它从语法的角度不提供继承机制的实现，但是提供了一些有效的多态实现，让开发人员能够随心所欲的开发基于组件的应用，如果不是出于性能的考虑，开发COM组件没有太多使用VC（我不是说标准C++）这样设计的略显晦涩的语言，那些有点蹩脚的宏和事件映射相信让追求美感的程序员不止一次的鄙视。在一些业务应用开发方面，VB6已经登封造极，但是不以为这它没有任何缺点，因为解释执行（虽然5.0以后提供了VB6VM.dll[似乎是这个]，但是本质上来说还是解释执行）的效率低下和一些东西太死，让一些顶尖的VB程序员束手束脚。
没有人能够准确的指出VB的发展应该是怎样的，应该在语言层次上做怎样的扩展，包括微软在内，也不是能够那么一针见血的指出开发人员的真正需要。所以VB.NET推出的时候，大多人是失望的，因为发现除了Dim obj as ObjectType和Begin…End这样语法的接近，VB.NET已经不是他们想象的VB，是的，加入了继承，加入了重载，加入了很多很多关键字，但是我们依旧发现这不是我们要的VB.NET。所以当我因为手误创建了VB.NET的工程时，我一点都不感到失望，依旧很随手的去写一些需要的测试代码，除了语法结构，我已经没有任何需要去考虑这是一个怎样的语言。
但是对于微软而言，意义远远不止是失望两个字。我想Richard的观点是正确的，VB.NET的推出是为了稳定和巩固MS开发人员，2000推出.NET的时候，在市面上从事Windows开发的程序员大多使用VB6和Delphi,当然还有一部分高高在上的VC6,推出C#的原因无非是要创造一个没有历史包袱的语言，使其能够更好的胜任基于.NET的开发，同时提供类似C++的语法，使C++或者Java程序员更快的转到C#开发上来。这几年来因为Borland的不争气，出人意料的吸引了许多原先的Delphi开发人员，而VB开发人员要么固步自封，要么干脆抛弃VB直接转移到C#(国内这样的程序员多一点，在北美市场，VB.NET还是比较多)，因为VB.NET和VB的太不接近，对于大多人而言以其去接受一个有历史包袱和阴影的语言，倒不如放开手脚，去学习Anders打造的全新语言。
那么这个时候VB.NET还是多少的VB？
Mono only is Mono,not .NET never。
当我继续写这个Post的时候，我专门到Mono的站点下载了Mono的运行时和类库的完整源代码。用来两天的时间阅读了一些类库如ASP.NET,XML等等的源代码，必须承认，通过这两天源代码的阅读让我原先的一些想法有稍微的改变。
从微软的战略来看，是希望将用户毫无条件的锁定在Windows操作系统之上，有人的地方就有计算机，有计算机的地方就有Windows。这是微软多年来倾其全力的追逐的梦想。在桌面操作系统上除了Apple的苟延残喘之外，还有一部分反微软斗士使用的基于Linux的桌面系统之外，其他无一不是微软帝国在统治。也许这里有人会攻击我对于Linux的看法，也不止一次的听到有人对我说“你根本不懂Linux”，所以一切的评论都是不够公允的。不曾经怀疑过Linux在服务器市场上的冲击力，也正是在服务器领域的成就让芬兰大学生Linus Torvalds的无心之作在短短的10多年内成为最流行的服务器操作系统，但是在桌面领域呢？你可以告诉我已经有很好的操作系统，包括我们国内那几家扛着“振兴民族软件产业”大旗的企业，从国家拿走大笔大笔的钱，也做出了一个表面看起来像模像样的“为中国人设计”的Linux操作系统，但是有多少人真正在用，明眼人都会看明白的。当然也有人会骂，用着D版的Windows在网上冲浪，然后愤恨不平的陈述微软霸权。
作为微软，总会尽可能的将用户锁定在Windows之上，那么.NET也不会例外，为了确保不允许被“拷贝”到其他操作系统之上，在类库的设计上正如上面提到的会采用“底层API”。尽管微软也提交了CLI，提交了C# Spec，但是遵循了ECMA标准的C#和微软自己的标准有多少区别吗？
有，正因为标准，所以有了Mono这样东西的出现
没有，因为Mono仅仅是Mono，而不是.NET。
你可以质疑我这样自相矛盾的回答，也可以说我不懂Linux，更加可以说我不了解Mono。我的朋友Kaneboy告诉我越来越发现Mono是一个好东西，等我阅读了部分的源代码之后我也认为Mono是一个好东西，但是它是.NET吗？也许你可以从我下面的文字中找到一些答案。
如果你是一个.NET架构师，那么我建议你一定要去阅读Mono的源代码，因为Mono可以告诉你很多你之前不可能知道的东西，你会看到很多你一直想看到却没有机会看到的东西，就比如ASP.NET、ADO.NET。相信在VS.NET或者Web Matrix的帮助下你能够写出很眩的页面，能够写出很漂亮的控件，也会感觉到比之前的ASP更加得心应手，但是你会发现一些东西你始终无法突破，比如很多文档会告诉你ASP.NET Page对象模型，会告诉你页面的在整个HttpApplication管道化过程中的迁移，会告诉你可以启用Session，可以启用片断缓存，但是始终无法明白Web应用中Session的底层是如何设计和考虑的，如何真正有效的提高你的缓存设计策略。一切尽在Mono，相信那些源代码能够解开你一些困挠许久的疑惑。
但是，目前的Mono仅仅是在跟Microsoft在走，如果你去阅读过源代码，然后也用Reflector看过微软自身对于类库的实现，你会发现作为追随者真的很辛苦，对于一些核心的实现，微软仅仅是对于原有的技术做了一个包装，然后通过.NET统一编程接口，而Mono却需要一切从零开始。前文提到了微软会不遗余力的将所有技术锁定在Windows操作系统之上，那么从这个角度来说他绝对不运行有一个同样的产品出现在非自己统计的操作系统平台上，对于Mono,也如同对于Application Server的策略是一致的，因为微软比谁都明白，如果让框架运行时(CLR)和应用服务器独立于操作系统，那么Windows就失去了最后的技术壁垒，不知道大家是否记得当年的Visual J++，为了将Java锁定到Windows，微软开发了WFC，并且允许使用Visual J++开发COM组件，Sun后来告发了微软一把，理由很简单，因为微软的“险恶用心”和破坏了Java世界的“纯洁性”，平心而论，如果忽略微软对于Java的改动，甚至仅仅将Visual J++当着一门新的语言(比如Pre-C#，当然了，这是我在胡扯)，依托于WFC的强大，作为Anders加盟微软之后打造的第一个产品，Visual J++在windows开发上就我个人的感觉来看已经超越Visual Basic。
从文化而言，Mono是一个自由斗士，它打破了.NET只能够在Windows上运行的限制，同样也帮忙微软印证了.NET可以跨平台。但是微软真的系统跨平台的.NET吗？肯定不是的，如果所有的开发商都使用.NET开发，而.NET同样可以运行于任何操作系统，那么Windows就不是唯一的选择，开放源代码、免费（这里提及的可能不是特别准确）的Linux会更加成为主流。如果你是商人，你将如何选择？因此没有任何一个理由让微软的.NET要去跨平台，当然商业上标榜的跨平台是另外一个策略问题了。
鉴于上述，Mono注定是永远的追随者，1.1的框架还没有在Mono下面完全实现，而.NET 2.0又快要推出，如果你稍微那么了解一点点的Whidbey(Visual Studio 2005的开发代号），你知道.NET 2.0相对于1.1已经改变很多很多，那么Mono究竟有多少力量能够在时间上不被微软甩开太远。我这里没有答案，也许谁也没有。如果你是学习，那么有很多理由建议你去看看mono，如果是你研究，那么有更多的理由选择Mono。如果你是一个商人或者架构师，要找出在商业上选择Mono的理由确实很难，真的，很难……
Mono only is mono,not .net never
Mono only is Mono,not .NET never。
当我继续写这个Post的时候，我专门到Mono的站点下载了Mono的运行时和类库的完整源代码。用来两天的时间阅读了一些类库如ASP.NET,XML等等的源代码，必须承认，通过这两天源代码的阅读让我原先的一些想法有稍微的改变。
从微软的战略来看，是希望将用户毫无条件的锁定在Windows操作系统之上，有人的地方就有计算机，有计算机的地方就有Windows。这是微软多年来倾其全力的追逐的梦想。在桌面操作系统上除了Apple的苟延残喘之外，还有一部分反微软斗士使用的基于Linux的桌面系统之外，其他无一不是微软帝国在统治。也许这里有人会攻击我对于Linux的看法，也不止一次的听到有人对我说“你根本不懂Linux”，所以一切的评论都是不够公允的。不曾经怀疑过Linux在服务器市场上的冲击力，也正是在服务器领域的成就让芬兰大学生Linus Torvalds的无心之作在短短的10多年内成为最流行的服务器操作系统，但是在桌面领域呢？你可以告诉我已经有很好的操作系统，包括我们国内那几家扛着“振兴民族软件产业”大旗的企业，从国家拿走大笔大笔的钱，也做出了一个表面看起来像模像样的“为中国人设计”的Linux操作系统，但是有多少人真正在用，明眼人都会看明白的。当然也有人会骂，用着D版的Windows在网上冲浪，然后愤恨不平的陈述微软霸权。
作为微软，总会尽可能的将用户锁定在Windows之上，那么.NET也不会例外，为了确保不允许被“拷贝”到其他操作系统之上，在类库的设计上正如上面提到的会采用“底层API”。尽管微软也提交了CLI，提交了C# Spec，但是遵循了ECMA标准的C#和微软自己的标准有多少区别吗？
有，正因为标准，所以有了Mono这样东西的出现
没有，因为Mono仅仅是Mono，而不是.NET。
你可以质疑我这样自相矛盾的回答，也可以说我不懂Linux，更加可以说我不了解Mono。我的朋友Kaneboy告诉我越来越发现Mono是一个好东西，等我阅读了部分的源代码之后我也认为Mono是一个好东西，但是它是.NET吗？也许你可以从我下面的文字中找到一些答案。
如果你是一个.NET架构师，那么我建议你一定要去阅读Mono的源代码，因为Mono可以告诉你很多你之前不可能知道的东西，你会看到很多你一直想看到却没有机会看到的东西，就比如ASP.NET、ADO.NET。相信在VS.NET或者Web Matrix的帮助下你能够写出很眩的页面，能够写出很漂亮的控件，也会感觉到比之前的ASP更加得心应手，但是你会发现一些东西你始终无法突破，比如很多文档会告诉你ASP.NET Page对象模型，会告诉你页面的在整个HttpApplication管道化过程中的迁移，会告诉你可以启用Session，可以启用片断缓存，但是始终无法明白Web应用中Session的底层是如何设计和考虑的，如何真正有效的提高你的缓存设计策略。一切尽在Mono，相信那些源代码能够解开你一些困挠许久的疑惑。
但是，目前的Mono仅仅是在跟Microsoft在走，如果你去阅读过源代码，然后也用Reflector看过微软自身对于类库的实现，你会发现作为追随者真的很辛苦，对于一些核心的实现，微软仅仅是对于原有的技术做了一个包装，然后通过.NET统一编程接口，而Mono却需要一切从零开始。前文提到了微软会不遗余力的将所有技术锁定在Windows操作系统之上，那么从这个角度来说他绝对不运行有一个同样的产品出现在非自己统计的操作系统平台上，对于Mono,也如同对于Application Server的策略是一致的，因为微软比谁都明白，如果让框架运行时(CLR)和应用服务器独立于操作系统，那么Windows就失去了最后的技术壁垒，不知道大家是否记得当年的Visual J++，为了将Java锁定到Windows，微软开发了WFC，并且允许使用Visual J++开发COM组件，Sun后来告发了微软一把，理由很简单，因为微软的“险恶用心”和破坏了Java世界的“纯洁性”，平心而论，如果忽略微软对于Java的改动，甚至仅仅将Visual J++当着一门新的语言(比如Pre-C#，当然了，这是我在胡扯)，依托于WFC的强大，作为Anders加盟微软之后打造的第一个产品，Visual J++在windows开发上就我个人的感觉来看已经超越Visual Basic。
从文化而言，Mono是一个自由斗士，它打破了.NET只能够在Windows上运行的限制，同样也帮忙微软印证了.NET可以跨平台。但是微软真的系统跨平台的.NET吗？肯定不是的，如果所有的开发商都使用.NET开发，而.NET同样可以运行于任何操作系统，那么Windows就不是唯一的选择，开放源代码、免费（这里提及的可能不是特别准确）的Linux会更加成为主流。如果你是商人，你将如何选择？因此没有任何一个理由让微软的.NET要去跨平台，当然商业上标榜的跨平台是另外一个策略问题了。
鉴于上述，Mono注定是永远的追随者，1.1的框架还没有在Mono下面完全实现，而.NET 2.0又快要推出，如果你稍微那么了解一点点的Whidbey(Visual Studio 2005的开发代号），你知道.NET 2.0相对于1.1已经改变很多很多，那么Mono究竟有多少力量能够在时间上不被微软甩开太远。我这里没有答案，也许谁也没有。如果你是学习，那么有很多理由建议你去看看mono，如果是你研究，那么有更多的理由选择Mono。如果你是一个商人或者架构师，要找出在商业上选择Mono的理由确实很难，真的，很难……
Mono only is mono,not .net never