[翻译]Grimes先生的告别

Grimes先生的告别

Mr. Grimes’ Farewell

原文http://www.ddj.com/documents/s=9211/ddj050201dnn/

2005.2.1

-

Richard正在逐步淡出所有关于.NET评论。在告别致词中，他回顾了.NET开发中的失误，并针对该平台的未来发表了看法

-

从我开始为这个通讯撰写文章至今已经快3年了，但是现在我决定结束了。我想我应该写一篇总结性的文章来阐述一下我对.NET现状的一些看法。

在2000年初，.NET还是技术预览版的时候我就开始使用它了，那个时候它还叫COM+ 2，而且其中的主要语言是一种称作Cool（译者注：C-based Object-Oriented Language，基于C的面向对象语言）的东西。其框架（Framework）最初也只是简单地称为“下一代Windows服务（NGWS，Next Generation Windows Services），直到市场部的那些书呆子们决定为它起一个术语来搞乱Internet搜索引擎：.NET。多少次你被问起“.NET是什么”和“它和.COM、.ORG有什么关系”？当然，Cool这个词还是可以搜到的。于是一些淘气的人决定称他为C#，这也是为了搞乱搜索引擎和用户。搜索引擎不喜欢#字符，用户也不知道该怎么读他（读作C-pound？还是按照大西洋西岸的读法：C-hash？）（译者注：或者按我们中国的读法：C井？）。我在技术预览版的新闻组中发表的第一件作品好像是一个用Cool写的简单的命令行应用程序，并且对它和与它等价的Java程序提出了反问：有什么不同吗？这得到了Visual Studio产品组经理的诸多反馈，但他却没有真正看清我的观点。

不像Visual Studio的其它版本，Visual Studio .NET的第一个beta版是公开的。所有的人都可以下载这个beta版并在其新闻组里报告Bug和问题。说实话，我并不觉得它是个好东西。我只是匿名地在公共的组里面提交了一个可重现的Bug，我不喜欢报告不可重现的Bug或提供改进建议。这样一个开放的、大型的测试会得到大量的Bug报告，我们见过那个项目能从这种情况中获益。我怀疑其目的是不是真正为了找到Bug——其真正目的更可能是开放这个Beta版以使其得到尽可能广泛的接受或认可。

和很多人一样，我首先就被该框架的大小震撼了。这也太多了！在接下来的几年里我得到的结论是这个大小确实是一个障碍。其中的类太多了，尽管我认为很多类的设计很好，但还是有很多类设计得很草率。很多类只不过是对Win32的包装，还有很多类看起来像是从其它框架中移植过来的。在.NET发布之前，Microsoft有它自己的Java框架库，称作WFC；它还有一个托管的库，用作“经典（Classic）”Visual Basic运行时的一部分。很难说有多少类是从WFC和VB中移植到.NET里的。我可以指出这样一个类，它在.NET里工作的何在VB中一样不爽（Badly），这个类就是EventLog。人们都懒得去想在该框架的1.0版中对它的设计是多么的没头脑。这是有案可查的，我从Beta版就开始抱怨这个类，但开发者给我的回复都只是一写漏洞百出的借口。终于，在2.0中“修正”了这个类，但是错误的方法并没有被删除，所以我根本不认为这是对它的修正。

大体上说，我认为这个库发布得太早了，而且我认为它太大了。该框架的再分发包有25MB，这要大过Java再分发包很多倍。在Visual Basic早期的一次培训中曾经提到，是共享软件和免费软件市场铸就了这门语言的流行。尽管现在也有一些用.NET编写的共享软件应用程序，但我经常听到人们抱怨那个巨大的再分发包。在这个专栏中，我也曾提到过大小问题，并且我至今仍然在想，如果Microsoft能够提供一个该框架的删减版本，比如只有mscorlib和System程序集，是很有益的。

尽管我专注于Visual Basic，我也会针对该语言给出我自己的看法。不得不说经典Visual Basic已经疲倦了。这门语言天生就是单线程的，而且在COM中有一些列的问题（在创建COM服务器的时候确实是这样）。实际上，当我写完MTS的书（1999年出版）后，我就开始总结MTS是如何设计的，以让Visual Basic开发者能够编写对象，并从线程和安全中受益，COM+使这又前进了一步。Visual Basic可以调用Win32函数，但必须使用一种恶心的手法（Dirty Hacks）。不过有了COM和COM安全性以后，它确实达到了一个尽可能高的境地，但是在某些代码中仍然不能提供一些C++能够提供的功能。任何解决方案如果C++能够提供简便性而VB不能，则很难让人们去选择VB。然而，这些问题都是由这门语言机器运行时的天性造成的，而这些解决方案要被彻底地改变。这就导致了VB.NET。

不过，随便搜索一下Internet就能看到VB.NET的发布所引起的公愤。最好的例子就是Karl E. Peterson的站点（http://www.mvps.org/vb/rants/vfred.htm）。VB.NET根本不是VB：据Karl的站点显示，VB和VB.NET语言之间有很多不兼容的地方。此外，VB是单线程的，没有异常，而且通常用于写非OOP代码。VB.NET提供了一个“移植（Porting）”工具，但是我所认识的很多人（包括我）在使用了这个工具之后发现它只是简单地注释掉了大量的不可移植代码。我最初的建议就是VB开发者不可能移植他们的代码，只能将他们的代码转换为VB类，并通过COM互操作（Interop）来在.NET代码中进行调用。而VB代码依然只能在最初设计它们的环境中运行。当然，Microsoft希望“VB.NET就是VB”的神话能够永存，并且承诺提供移植工具。

一些人觉得VB.NET是神奇的。但我真的不认为这是语言的原因。几乎没有哪些特性是其它语言所不具备的（过滤器和接口方法重命名是两个例外），但这并不构成设计一门新语言的原因。也有论据表明VB.NET会让VB开发者感到舒适，但正如我所说的，VB.NET不是VB，，而且由于开发者必须去学习OOP和.NET的一些规则，如线程、异常和委托，这和要求开发者们学习一门新语言有什么区别？C#语言天生适用于.NET，但对于VB.NET来说没有这个必要。分号和花括号并不是很难用！我们的确要让这门语言成为.NET语言，但没必要这么彻底。就我看来，公共语言基础架构（CLS，Common Language Specification）只是简单地要求VB.NET代码能够按照它的方式构建代码，却不是真的使所有的语言能够协同工作。我知道带符号整数很有用，但无符号整数同样有用！我不理解为什么VB.NET没有把无符号整数作为语言的一部分。还有一种迟钝的设计我认为是幼稚的，我们没有任何理由去使用Option Strict Off（“迟绑定（Late Binding）”是“难以发现运行时Bug”的同义词），而且如果你不显示地声明你的变量，你将无法在调试过程中跟踪它们。VB.NET的一些新特性根本无法抵消这一系列的缺陷。

我撰写了一个VB.NET专栏并且经常在VB.NET大会上发表演讲，因此我非常清楚这门语言。然而，这并不是一门能够让我感到舒服的语言。我发现不论什么时候我要使用这门语言，我都要保证很多事情。而它根本不会按我所期望的方式工作，而且我不是唯一一个这样的人。这是我从那些从经典VB转到VB.NET的人们那里听来的最多的抱怨，而且Karl E. Peterson的陈述也支持这一观点：VB.NET的确不是VB。那为什么Microsoft还要开发VB.NET呢？答案是这样的，在2000年，VB开发者的数量超过使用其它Microsoft开发语言如C++的开发者的数量至少在10倍以上（这是我在Microsoft内部会议上看到的数字）。Microsoft花了很大力气宣传C#是“出自C++家族的”另外一门语言，但市场人员认为他们并不能令所有VB程序员转向这门类C++的语言。但是他们认为如果Microsoft开发一种类VB的语言，则大量的VB程序员将会转移到.NET。换句话说，VB.NET产生的原因是市场原因而不是技术原因。

指出.NET大体上和经典VB有些类似是值得的。和VB类似，.NET中可以使用接口，但是更好的方式是使用类。接口是优雅的，但.NET的基于类的首选解决方案却标志着接口的死亡。看看.NET Remoting：这种机制允许在一个上下文环境中创建一个对象，而在另外的上下文环境中去访问它。这意味着该对象的状态被保存在本地，而它的行为却是远程的。因此，Remoting应该是一个基于接口的工具。你可以用接口来调用Remoting，但是通读整个文档和Web上的所有“how-to”，你却找不到这样的实现。相反，Microsoft建议人们使用基于类的方法，这经常会出现一些莫名其妙的状况，如人们将他们的服务器程序集部署到客户端以使得客户端拥有服务对象的元数据、或一个肥皂泡（Soapsuds）程序集的时候。这些基于类的Remoting所带来的各种问题根本就是迂腐（hack）。

说.NET是类VB的的另外一个方面是Microsoft对于该框架的态度。Microsoft将.NET视为一个有用的工具，用来扩展它的产品，但是时至今日，它也没有表明该框架的信念。它（Microsoft）几乎没有任何.NET产品是完全用.NET写成的，唯一一个这样的产品也就是Microsoft CRM。然而，这也不是它的主要的收入来源。相反，.NET也就是对以前的产品进行了一下翻新和扩展。甚至Visual Studio .NET也不是一个.NET产品。devenv.exe是一个用C++（大概是MFC）编写的非托管进程。VS.NET宿主（Host）了.NET运行时，因此它可以使用.NET对象，如属性网格（Property Grid，一个控件），并且因此可以使用编译为.NET程序集的代码来扩展它。我个人认为这基本上是Microsoft未来将会使用的一种模型。他们不愿意承担重写所有.NET代码的所需的代价，也没有压力使他们提供全新的.NET代码，相反，.NET可以在需要的时候随时进行宿主（Host），尤其在允许使用用户代码来进行扩展的时候。

Microsoft目前的操作系统，XP和Windows 2003，都不依赖.NET，在XP中，.NET甚至只是一个可选的组件。Windows的下一个版本，代号Longhorn，在PDC 2003上曾发布过一个技术预览版，它看起来好像是到处爬满.NET触须的操作系统。然而，这之后一切都变了。接下来的一年中，Microsoft发布了一系列言论表明它只关心2006年这个假想的最后期限，却一点也没有对于新技术的激情了。第一个阵亡的是WinFS。它确确实实使Longhorn变得很慢，而且特别是它会使我们今天用的Outlook Express无法使用。但是Microsoft没有想办法使这项技术能够工作，却选择了移除它。体会一下它的言外之意，我怀疑这项技术是否还能回来。接下来，Microsoft声明Longhorn中的其它两项.NET技术，Indigo和Avalon，将可以用在其它版本的Windows上。Indigo是一项通信技术，让它运行在其它版本的Windows上是有意义的。然而，决定让Avalon运行在其它Windows版本中却说明了Micrsofot正在丧失销售Longhorn的信息。

我个人的看法是，Avalon，或者确切一点，XAML，将宣告ASP的死亡。其原因是Avalon是一项客户端技术，但浏览器是分布式模型中重要的组成部分。XAML是如此的“Rich”，以至于包含在浏览器中的XAML应用程序看起来与基于进程的Avalon应用程序几乎没有什么差别，再加上Web服务和Indigo（作为一种访问远程代码的机制），XAML应用程序将使ASP.NET应用程序变得陈旧和无用。为什么Microsoft要杀掉ASP？正是因为预装了ASP.NET，Microsoft能够才能够卖出Windows 2003一份单独的副本，以及不少套Visual Studio .NET。然而客户端不一定是Windows，因此他们就无法再卖出额外的Windows（无论是产品还是授权）。这可是一笔不小的损失啊，更坏一点，ASP.NET事实上能够很容易地写出能够在IE之外的浏览器上运行的应用程序。然而，有了XAML这样的技术，Microsoft就能够控制客户端了。这样的话，除了服务器和开发工具，客户端也必须拥有Avalon。这使得Microsoft又能获得一大笔收入，但前提是说服用户升级到Longhorn。然而， 我觉得Microsoft声明Avalon可以运行在其它版本的Windows上表示微软在对待升级到Longhorn的问题上不再自信，而且开发者在不确定客户端运行了Avalon的情况下是不会去编写Avalon应用程序的。

因此，根据去年中的这些声明，Microsoft已经预示了Longhorn其实并不是.NET的一个伟大的革新，尽管在PDC 2003上我们还相信这一革新。这使我觉得Microsoft已经失去了对.NET的信心。等我看到Longhorn的Beta版时候（今年晚些时候），我要好好检查一下，看看其中究竟有多少使用.NET实现的。我怀疑只有很少一点。如果Longhorn没有实现Shell，或者不允许用于使用.NET来扩展Shell，则说明Microsoft已经完全失去了信心。如果Longhorn没有在.NET中实现任何服务，则他们会指出（像我一样）.NET不是运行在LOCALSYSTEM帐户权限下的一种正确的技术。

如果你读到了这里，你可能觉得我对于.NET的观点有些愤世嫉俗。这个框架中包含了太多的承诺，但我觉得Microsoft太过雄心勃勃、发布了太多程序集、太过性急了。结果就是设计缩水，然而对于提供向后兼容，Microsoft不应该简单地重新设计所有的库却忽视了现有的。所以我们会坚持使用现有的库。Microsoft总是允许市场优先于技术。他们开发和推广VB.NET只是尝试让大量的Windows开发者转向.NET，却不是因为真的需要这样一门语言。这个框架最终会成为Visual Basic——用户可以用它写程序，但Microsoft不会用它去开发操作系统或其他它赖以生存的、能够产生主要收入的产品。