Osborn:
让我们进入语法细节。我在想，C#是否包括对正则表达式的内建支持。我没有在语言参考里看到它，或许它可能在别的什么地方吧。
Hejlsberg:
首先，在基类库里有一个正则表达式类。我们并没有在语言里加入对正则表达式的任何直接支持，但是，实际上我们有些非常类似的特性。并不值得对它们做重大的处理。但是，比如当你需要指定一个时候—我们给你这个能力去写一个逐字字符串而不需要你每次写两个后斜杠。当你写正则表达式时并且当你的正则表达式里的引号还套引号时，它实际上有极大的帮助。虽然这个帮助不足挂齿，但显然其核心在.NET框架里，而这个框架可以被任何编程语言共享。
Osborn:
C#和Java名字空间看起来不同。它们是否概念相同而实现上不同？
Hejlsberg:
概念上是的，但是在实现上非常不同。在Java里，包名也是物理的东西，它指定了你的源代码文件的目录结构。在C#中，物理包和逻辑名称完全独立，无论你如何称呼你的名字空间，它都和你的实际代码的物理包不相关。这就给你更多的弹性—把物理上分布的单元包装在一起，并且不强迫你建很多的目录。在语言自身，有很多很明显的区别。在Java里，包也是你的物理结构，因此，Java源文件必须在正确的路径里，并且只能包含一个公开类型或者一个公开的类。因为C#没有那种物理和逻辑上的绑定，所以你可以任意命名你的源文件。每一个源文件都可以被多个名字空间使用并且可以带有多个公开类。进一步讲，你可以把所有的源码写在一个大文件里，或你可以把它们分散到交叉的小文件中去。概念上讲，C#编译时发生了什么—你给编译器提供了所有构成你的工程的源文件，然后它只管前进并指出该干什么。
Osborn:
我有一个关于泛型编程的问题：你认为它是个重要的概念吗？它应该成为面向对象语言的一部分吗？如果是的话，你们把泛型编程加为C#的一部分的计划如何？
Goodhew:
好的。在第一个版本里包括泛型编程的愿望受到了限制。并不象每一个人以为的那样，微软并没有无限制的资源。在这第一个版本里，我们不得不做一些困难的决定。
Osborn:
有多少人参与开发C#？
Hejlsberg:
语言设计组由4个人构成，编译器组由另外五个开发人员构成。
Petrusha:
框架呢？
Hejlsberg:
那就多了，整个公司都被卷入了。
Goodhew:
就整个Visual Studio和.NET平台组而言，我们的部门大概有千人左右。包括程序管理人员、开发人员、测试人员，包括所有创建例程、框架、运行时、ASP编程模型的人员以及其它所有的人比如我，管理层的。
Hejlsberg:
就你刚才所说的泛型方面，我明确地认为它是个非常有用的概念，并且你当然可以列举出发生在学术界和业界所有的泛型研究。模板是该问题的一个解决方法。在我们内部讨论中，我们决定要在新平台里做这个事情。但我们真正喜欢做的是让底层的运行时理解泛型。这和如何创建泛型原型是不同的。用Java的“擦除”概念系统里没有真正的泛型知识。如果公共语言运行时理解泛型的概念，多种语言就可以共享这个功能。你可以在一个地方用C#写一个泛型类，别的人用别的语言也可以使用。
使泛型成为运行时的一部分还可以使你更有效率的做某些事情。泛型实例化的最理想的时间是在运行时。如果用C++，模板的实例化发生在编译时，你有两个选择：听任你的代码膨胀或试图在链接时去除掉一些膨胀代码。但是，如果你有多个应用，你可能会忘记这一点，你将只能得到膨胀的代码。
如果把泛型的知识纳入公共语言运行时，则运行时可以理解—当一个应用或组件请求一个“Foo”列表时，它首先会问：“我已经有了一个实例化的“Foo”列表了吗？”如果是，就用那一个。实际上，如果Foo是一个引用类型，并且我们设计正确的话，我们可以让所有引用类型共享一个实例。对于值类型，比如整型和浮点型，我们可以为每一个值类型创建一个实例，但这应该在应用请求时才做。为了把泛型加入运行时，我们已经做了大量的设计工作和必要的基础性工作。
你先前提到的关于IL的东西是有意思的，因为加入泛型的决定影响了IL的设计。如果IL指令嵌入类型信息，如果，例如，一个“加”指令不再是个“加”了，而是一个整数“加”或是浮点数“加”或是一个双精度数“加”，你就把类型信息硬加入到了指令流里，并且在这一点上来说IL不是泛型的。我们的IL格式实际上是真正的类型中立的。并且，为了保持类型中立，我们可以迟些时候加入泛型而不会给我们带来麻烦，至少不会太麻烦。这也是我们的IL和Java的字节码看起来不一样的原因之一。我们IL类型中立。“加”指令可以加栈顶的任何两个东西。在泛型世界，当它被初始化时，它可以被翻译成不同的代码。
Osborn:
所有.NET语言都可获得泛型能力吗？
Hejlsberg:
是的。微软剑桥研究院已经创建了一个支持泛型能力的公共语言运行时和C#编译器的版本，我们正在研究如何尽快使其前进。第一个版本是不可能加入泛型了，我们知道的就这么多。但是我们正在工作以确保我们在第一个版本里做了正确的事情从而使泛型可以适用于整个蓝图。
Osborn:
C#和.NET框架以及Visual Studio的下一个版本计划发行日期是？
Goodhew:
唔，我们为来这儿参加PDC的6500名人员带来了技术预览版。我们希望2000年秋季的某个时间发布beta版，然后在准备好以后，我们发布发行版。我们所做的一个真正令人激动的事情是看看Windows2000发行版发布进行的如何，以让关键客户参与到合作开发和合作部署的进程中来。关于.NET框架和Visual Studio.NET，我们将再次和客户一起工作以决定最终产品的发行日期。我们打算让他们告诉我们什么时候产品该就绪了。并且，因为有真正的客户参与到这个进程中来，我们将获得更好的产品质量。这种做法的不利的一面是使产品开发和发布的进程有点不确定。但这是根本性的改变。我们在寻找一个打破质量障碍的产品发行方式，而不仅仅是挑一个武断的日期说我们要发货了。
Osborn:
因此，不是一个代码完成的日期，我们在寻找一个“准备好出发”的日期？
Goodhew:
是的，没错。我认为开发者将会发现Visual Studio.Net发行版是微软历史里最高质量的发行版本之一。
Osborn:
你们已经把C#提交给ECMA[译注：欧洲计算机制造商协会]。标准化真的是一个严肃的目标吗？你希望在其它平台上也可使用C#吗？
Hejlsberg:
的确如此！把C#作为一个可能的标准提供给业界当然是我们的目标，这也是我们把它提交给ECMA的原因之一。在引导这个有着公共语言基础设施的公共设计的语言的进程中，我们当然希望得到ECMA的支持。关于公共基础设施，我的意思是指这个规范所规定的一个核心类库集，如果其它公司使用其它平台实现它，他们有理由期望发现可以在他们的程序里利用这些类。
Goodhew:
我想指出的是我们正在和ECMA做真正的开放标准。当ECMA为C#和公共语言基础设施达成标准后，在ECMA的版权和授权政策下，真正的开放将可实现。任何客户、任何人都可以被授权ECMA C#标准，子集之，超集之，并且不必付版税。他们可以在任何平台和任何设备实现之。我们完全希望人们那么做。这和我们的竞争者根本不同。他们徘徊在标准之外，寻找某某人去为他们私有的语言贴上印花。
John:
我在早餐和午餐时听说：“如果微软没有把COM搞到基础设施中去，平台会多么具有可移植性？”
Hejlsberg:
完全可能。COM并非C#和公共语言基础设施标准化之必须。根本不是。C#有一个完备丰富的类模型，而COM则是从另外一个视角看待应用的互操作性。但是，C#和公共运行时的核心中从未说过必须要有COM、 GUID、 HRESULT、 AddRef 或 Release等等。一个都没有。.NET 公共语言运行时彻底摒弃了COM，但它还是给了你巨大的COM互操作能力。鉴于先前所述，我仍然认为它将非常重要，但绝非不可或缺。
Goodhew:
我认为这些评论起因于我们公开的最初版本的语言规范。微软在某次会议上把它写进了规范。在那次会议上，我们认为按照微软平台来说这是非常重要的。结果，我们在规范里多次引用COM和DLL这样东西。DLL是如何在已给定平台上激活本地代码的更多的一般性问题中的一个特例。对于纳入标准化组织以及和象IBM的人（我们和他们一起制订SOAP规范）一起工作的一个好处是我们可以不做任何这样的提及，以防止在规范的未来版本里，把我们自己绑死或锁定在象COM框架这样的东西上。
就象Anders说的那样，COM互操作能力和COM支持对我们和已有的微软客户来说是极其重要的。我认为为了在.NET支持COM我们做了大量的工作。但是，业界的人们已经阅读了大量的我们对COM和DLL字眼引用的东西，他们由此推论.NET仅仅是为Windows平台设计的，这是完全错误的。
Hejlsberg:
并且，我认为就象COM的互操作能力对于微软和在微软平台上构建解决方案的客户很重要一样，C#和公共语言基础设施的标准化将允许在任何其它平台上选择实现这个语言以加入意义重大的互操作能力。
Osborn:
所以你们将不会坚持应该有个什么“纯C#”和“纯.NET”的实现？
Hejlsberg:
什么叫“纯”？真正有多少“纯”Java应用存在？我冒险猜测一下，非常非常少。那就是我估计的数量。让我们承认这一点，人们希望能利用他们已存在的代码。不可能叫那些公司把什么东西都扔掉。
Goodhew:
你和Roger Sessions交流过吗？[编注：Roger Sessions是ObjectWatch公司的CEO，并且是《COM+ and the Battle for the Middle Tier》的作者] 。
Osborn:
没有。
Goodhew:
Roger谈到了EJB规范的相关章节，那儿讲了卖方[vendor]许可扩展。毫不奇怪，卖方扩展包括诸如事务管理、安全、消息以及其它更多的方面，这在构建企业级系统中是相当重要的。在一篇文章[译注：http://www.objectwatch.com/issue_24.htm]里，Sessions粗略地列举了11个领域的机能，这是可容许的卖方规范实现。因此，如果你选择IBM Websphere作为你的EJB实现，你为你的EJB应用写的代码将不可避免地被锁定在Websphere。Java是100%纯和100%可移植的概念是不正确的。在IBM的开发者工作站点上，有一个伟大的专访[译注：http://www-106.ibm.com/developerworks/features/gosling/index.html]。James Gosling直接指出了这一点。他说，是的，整个“写一次到处运行”、“100%纯的东西”真是个愚蠢的想法，更多的是属于营销上东西。他说，实际上，“我们并不认为我们能够交付这一切，基本上，我们办不到”。这就是这个语言的发明者说的，不存在什么纯粹性和可移植性。
Osborn:
我们有没有遗漏一些没透露的C#的伟大的特性或创新，你愿意补充一下吗？
Hejlsberg:
关于.NET框架，隐含地，也包括C#，我想提的一点是：它是构建分布式应用的手段。并非很久以前，我们创建两阶层的客户/服务应用，然后对象协议如CORBA、 IIOP、 RMI、和DCOM 接踵而至。这种类型的编程是EJB—（CORBA或RMI的底层实现[译注：DCOM除外]）的基础。我们已经会构建这种强连接式的分布式系统，但它们不具备伸缩性。它们在WEB上不能够伸缩因为它们是有状态的，它们在服务端保持状态，你不能够转入另一台机器，把它插入并让相关东西复制自己。
当初，当我们坐下来着手设计.NET框架时，我们回头看了看Web上究竟发生了什么。它正在变成松散连接、非常分布式的世界。我们努力理解它对潜在的编程模型的影响。因此，我们从根本上假定分布式的应用是构建在松散连接、无状态风格的。依此，我们做出的设计可提供巨大的伸缩性。你只管扩展。你转入更多的框架并且把它们插入。一旦做出了这个根本性的假设，一切就随之改变。它改变了怎样设计你的根本服务，怎样设计你的消息，甚至是怎样设计你的用户界面。这是一个新的编程模型。我们已经选择了XML和SOAP作为使这个模型工作的方式。它们被深深地集成到.Net。并且这种集成对于我们在设计.NET框架时做出的每一个决策是如此核心，以至于它不是那种你只是进来蜻蜓点水地逛一逛就可以的东西。
Osborn:
你能指出一些对程序员来说明显特别的地方吗？
Hejlsberg:
一个相当好的例子是XML是如何被集成到C#中的。C#中有特性[译注：即attribute，关于名词译法的说明，上文有描述]的概念，它允许你向类型和成员加入宣称性信息。就象你可以说某个成员是公有的或私有的一样，你可能还想说这个是事务的，或者这个假定是个Web service，或这个假定被以XML方式的序列化支持。因此，我们加入特性以提供一般性机制，但是我们在所有的Web service和XML基础设施中都用到了它。我们还给你用特性修饰类和字段的能力。在你的类中，你可以说“当这个类型变成XML时，它应该变成“this”标签名，并且属于“this”XML名字空间。”你将有能力指定一个字段变成一个元素，而另外一个变成属性[译注：此处指XML中的属性]。你还能够控制XML的模式[译注：即schema]；在你的类声明的地方控制它，这样，所有附加的宣称性信息就都可以获得了。一旦以该方式正确地使用特性修饰你的C#代码，系统就可以简单把它转化成XML中一个指定的类，在线上传输，当它传回时，就可以在另一端重建该对象。这都是在一处定义完成的。它不象传统的定义文件或多种信息和命名模式。它就在那儿。当你在IDE中创建它们时，它就给了你完整的声明。我们还可以提供高级工具，让它帮你做这个事。
我知道我有点离题了，但是我们提供的这些基础设施的确令人兴奋。单单因为我们有这些特性，你就可以请求XML序列化基础设施或Web service基础设施把已给出的类翻译成XML。当你这么做了，我们实际上将为这个类配上XSD模式，并且我们将创建一个特别的解析器，它是从我们一般的XML解析器派生出来的（.NET基类的一部分），并且重载方法并加入逻辑，因此它是专门为那个模式服务的。所以，我们已经初始化好一个解析器，可以本地代码的速度解析XML。如果它不正确，我们将给你一个体面的出错信息，它可以精确地告诉你是什么出了问题。我们可以在代码缓存基础设施中缓存它，它将坐等直到下一次一个具有同样模式的类来临并将发生作用，“嘭！”，我的意思是，难以置信，难以置信的生产能力！
Osborn:
所以，在盖子下的确有很多有趣的引擎。
Hejlsberg:
是的，并且我认为，当在这个领域里达到这个思想时，我们是领先的一代。
Osborn:
精彩之至。谢谢，耽误你时间了。
Hejlsberg:
不客气。
让我们进入语法细节。我在想，C#是否包括对正则表达式的内建支持。我没有在语言参考里看到它，或许它可能在别的什么地方吧。
Hejlsberg:
首先，在基类库里有一个正则表达式类。我们并没有在语言里加入对正则表达式的任何直接支持，但是，实际上我们有些非常类似的特性。并不值得对它们做重大的处理。但是，比如当你需要指定一个时候—我们给你这个能力去写一个逐字字符串而不需要你每次写两个后斜杠。当你写正则表达式时并且当你的正则表达式里的引号还套引号时，它实际上有极大的帮助。虽然这个帮助不足挂齿，但显然其核心在.NET框架里，而这个框架可以被任何编程语言共享。
Osborn:
C#和Java名字空间看起来不同。它们是否概念相同而实现上不同？
Hejlsberg:
概念上是的，但是在实现上非常不同。在Java里，包名也是物理的东西，它指定了你的源代码文件的目录结构。在C#中，物理包和逻辑名称完全独立，无论你如何称呼你的名字空间，它都和你的实际代码的物理包不相关。这就给你更多的弹性—把物理上分布的单元包装在一起，并且不强迫你建很多的目录。在语言自身，有很多很明显的区别。在Java里，包也是你的物理结构，因此，Java源文件必须在正确的路径里，并且只能包含一个公开类型或者一个公开的类。因为C#没有那种物理和逻辑上的绑定，所以你可以任意命名你的源文件。每一个源文件都可以被多个名字空间使用并且可以带有多个公开类。进一步讲，你可以把所有的源码写在一个大文件里，或你可以把它们分散到交叉的小文件中去。概念上讲，C#编译时发生了什么—你给编译器提供了所有构成你的工程的源文件，然后它只管前进并指出该干什么。
Osborn:
我有一个关于泛型编程的问题：你认为它是个重要的概念吗？它应该成为面向对象语言的一部分吗？如果是的话，你们把泛型编程加为C#的一部分的计划如何？
Goodhew:
好的。在第一个版本里包括泛型编程的愿望受到了限制。并不象每一个人以为的那样，微软并没有无限制的资源。在这第一个版本里，我们不得不做一些困难的决定。
Osborn:
有多少人参与开发C#？
Hejlsberg:
语言设计组由4个人构成，编译器组由另外五个开发人员构成。
Petrusha:
框架呢？
Hejlsberg:
那就多了，整个公司都被卷入了。
Goodhew:
就整个Visual Studio和.NET平台组而言，我们的部门大概有千人左右。包括程序管理人员、开发人员、测试人员，包括所有创建例程、框架、运行时、ASP编程模型的人员以及其它所有的人比如我，管理层的。
Hejlsberg:
就你刚才所说的泛型方面，我明确地认为它是个非常有用的概念，并且你当然可以列举出发生在学术界和业界所有的泛型研究。模板是该问题的一个解决方法。在我们内部讨论中，我们决定要在新平台里做这个事情。但我们真正喜欢做的是让底层的运行时理解泛型。这和如何创建泛型原型是不同的。用Java的“擦除”概念系统里没有真正的泛型知识。如果公共语言运行时理解泛型的概念，多种语言就可以共享这个功能。你可以在一个地方用C#写一个泛型类，别的人用别的语言也可以使用。
使泛型成为运行时的一部分还可以使你更有效率的做某些事情。泛型实例化的最理想的时间是在运行时。如果用C++，模板的实例化发生在编译时，你有两个选择：听任你的代码膨胀或试图在链接时去除掉一些膨胀代码。但是，如果你有多个应用，你可能会忘记这一点，你将只能得到膨胀的代码。
如果把泛型的知识纳入公共语言运行时，则运行时可以理解—当一个应用或组件请求一个“Foo”列表时，它首先会问：“我已经有了一个实例化的“Foo”列表了吗？”如果是，就用那一个。实际上，如果Foo是一个引用类型，并且我们设计正确的话，我们可以让所有引用类型共享一个实例。对于值类型，比如整型和浮点型，我们可以为每一个值类型创建一个实例，但这应该在应用请求时才做。为了把泛型加入运行时，我们已经做了大量的设计工作和必要的基础性工作。
你先前提到的关于IL的东西是有意思的，因为加入泛型的决定影响了IL的设计。如果IL指令嵌入类型信息，如果，例如，一个“加”指令不再是个“加”了，而是一个整数“加”或是浮点数“加”或是一个双精度数“加”，你就把类型信息硬加入到了指令流里，并且在这一点上来说IL不是泛型的。我们的IL格式实际上是真正的类型中立的。并且，为了保持类型中立，我们可以迟些时候加入泛型而不会给我们带来麻烦，至少不会太麻烦。这也是我们的IL和Java的字节码看起来不一样的原因之一。我们IL类型中立。“加”指令可以加栈顶的任何两个东西。在泛型世界，当它被初始化时，它可以被翻译成不同的代码。
Osborn:
所有.NET语言都可获得泛型能力吗？
Hejlsberg:
是的。微软剑桥研究院已经创建了一个支持泛型能力的公共语言运行时和C#编译器的版本，我们正在研究如何尽快使其前进。第一个版本是不可能加入泛型了，我们知道的就这么多。但是我们正在工作以确保我们在第一个版本里做了正确的事情从而使泛型可以适用于整个蓝图。
Osborn:
C#和.NET框架以及Visual Studio的下一个版本计划发行日期是？
Goodhew:
唔，我们为来这儿参加PDC的6500名人员带来了技术预览版。我们希望2000年秋季的某个时间发布beta版，然后在准备好以后，我们发布发行版。我们所做的一个真正令人激动的事情是看看Windows2000发行版发布进行的如何，以让关键客户参与到合作开发和合作部署的进程中来。关于.NET框架和Visual Studio.NET，我们将再次和客户一起工作以决定最终产品的发行日期。我们打算让他们告诉我们什么时候产品该就绪了。并且，因为有真正的客户参与到这个进程中来，我们将获得更好的产品质量。这种做法的不利的一面是使产品开发和发布的进程有点不确定。但这是根本性的改变。我们在寻找一个打破质量障碍的产品发行方式，而不仅仅是挑一个武断的日期说我们要发货了。
Osborn:
因此，不是一个代码完成的日期，我们在寻找一个“准备好出发”的日期？
Goodhew:
是的，没错。我认为开发者将会发现Visual Studio.Net发行版是微软历史里最高质量的发行版本之一。
Osborn:
你们已经把C#提交给ECMA[译注：欧洲计算机制造商协会]。标准化真的是一个严肃的目标吗？你希望在其它平台上也可使用C#吗？
Hejlsberg:
的确如此！把C#作为一个可能的标准提供给业界当然是我们的目标，这也是我们把它提交给ECMA的原因之一。在引导这个有着公共语言基础设施的公共设计的语言的进程中，我们当然希望得到ECMA的支持。关于公共基础设施，我的意思是指这个规范所规定的一个核心类库集，如果其它公司使用其它平台实现它，他们有理由期望发现可以在他们的程序里利用这些类。
Goodhew:
我想指出的是我们正在和ECMA做真正的开放标准。当ECMA为C#和公共语言基础设施达成标准后，在ECMA的版权和授权政策下，真正的开放将可实现。任何客户、任何人都可以被授权ECMA C#标准，子集之，超集之，并且不必付版税。他们可以在任何平台和任何设备实现之。我们完全希望人们那么做。这和我们的竞争者根本不同。他们徘徊在标准之外，寻找某某人去为他们私有的语言贴上印花。
John:
我在早餐和午餐时听说：“如果微软没有把COM搞到基础设施中去，平台会多么具有可移植性？”
Hejlsberg:
完全可能。COM并非C#和公共语言基础设施标准化之必须。根本不是。C#有一个完备丰富的类模型，而COM则是从另外一个视角看待应用的互操作性。但是，C#和公共运行时的核心中从未说过必须要有COM、 GUID、 HRESULT、 AddRef 或 Release等等。一个都没有。.NET 公共语言运行时彻底摒弃了COM，但它还是给了你巨大的COM互操作能力。鉴于先前所述，我仍然认为它将非常重要，但绝非不可或缺。
Goodhew:
我认为这些评论起因于我们公开的最初版本的语言规范。微软在某次会议上把它写进了规范。在那次会议上，我们认为按照微软平台来说这是非常重要的。结果，我们在规范里多次引用COM和DLL这样东西。DLL是如何在已给定平台上激活本地代码的更多的一般性问题中的一个特例。对于纳入标准化组织以及和象IBM的人（我们和他们一起制订SOAP规范）一起工作的一个好处是我们可以不做任何这样的提及，以防止在规范的未来版本里，把我们自己绑死或锁定在象COM框架这样的东西上。
就象Anders说的那样，COM互操作能力和COM支持对我们和已有的微软客户来说是极其重要的。我认为为了在.NET支持COM我们做了大量的工作。但是，业界的人们已经阅读了大量的我们对COM和DLL字眼引用的东西，他们由此推论.NET仅仅是为Windows平台设计的，这是完全错误的。
Hejlsberg:
并且，我认为就象COM的互操作能力对于微软和在微软平台上构建解决方案的客户很重要一样，C#和公共语言基础设施的标准化将允许在任何其它平台上选择实现这个语言以加入意义重大的互操作能力。
Osborn:
所以你们将不会坚持应该有个什么“纯C#”和“纯.NET”的实现？
Hejlsberg:
什么叫“纯”？真正有多少“纯”Java应用存在？我冒险猜测一下，非常非常少。那就是我估计的数量。让我们承认这一点，人们希望能利用他们已存在的代码。不可能叫那些公司把什么东西都扔掉。
Goodhew:
你和Roger Sessions交流过吗？[编注：Roger Sessions是ObjectWatch公司的CEO，并且是《COM+ and the Battle for the Middle Tier》的作者] 。
Osborn:
没有。
Goodhew:
Roger谈到了EJB规范的相关章节，那儿讲了卖方[vendor]许可扩展。毫不奇怪，卖方扩展包括诸如事务管理、安全、消息以及其它更多的方面，这在构建企业级系统中是相当重要的。在一篇文章[译注：http://www.objectwatch.com/issue_24.htm]里，Sessions粗略地列举了11个领域的机能，这是可容许的卖方规范实现。因此，如果你选择IBM Websphere作为你的EJB实现，你为你的EJB应用写的代码将不可避免地被锁定在Websphere。Java是100%纯和100%可移植的概念是不正确的。在IBM的开发者工作站点上，有一个伟大的专访[译注：http://www-106.ibm.com/developerworks/features/gosling/index.html]。James Gosling直接指出了这一点。他说，是的，整个“写一次到处运行”、“100%纯的东西”真是个愚蠢的想法，更多的是属于营销上东西。他说，实际上，“我们并不认为我们能够交付这一切，基本上，我们办不到”。这就是这个语言的发明者说的，不存在什么纯粹性和可移植性。
Osborn:
我们有没有遗漏一些没透露的C#的伟大的特性或创新，你愿意补充一下吗？
Hejlsberg:
关于.NET框架，隐含地，也包括C#，我想提的一点是：它是构建分布式应用的手段。并非很久以前，我们创建两阶层的客户/服务应用，然后对象协议如CORBA、 IIOP、 RMI、和DCOM 接踵而至。这种类型的编程是EJB—（CORBA或RMI的底层实现[译注：DCOM除外]）的基础。我们已经会构建这种强连接式的分布式系统，但它们不具备伸缩性。它们在WEB上不能够伸缩因为它们是有状态的，它们在服务端保持状态，你不能够转入另一台机器，把它插入并让相关东西复制自己。
当初，当我们坐下来着手设计.NET框架时，我们回头看了看Web上究竟发生了什么。它正在变成松散连接、非常分布式的世界。我们努力理解它对潜在的编程模型的影响。因此，我们从根本上假定分布式的应用是构建在松散连接、无状态风格的。依此，我们做出的设计可提供巨大的伸缩性。你只管扩展。你转入更多的框架并且把它们插入。一旦做出了这个根本性的假设，一切就随之改变。它改变了怎样设计你的根本服务，怎样设计你的消息，甚至是怎样设计你的用户界面。这是一个新的编程模型。我们已经选择了XML和SOAP作为使这个模型工作的方式。它们被深深地集成到.Net。并且这种集成对于我们在设计.NET框架时做出的每一个决策是如此核心，以至于它不是那种你只是进来蜻蜓点水地逛一逛就可以的东西。
Osborn:
你能指出一些对程序员来说明显特别的地方吗？
Hejlsberg:
一个相当好的例子是XML是如何被集成到C#中的。C#中有特性[译注：即attribute，关于名词译法的说明，上文有描述]的概念，它允许你向类型和成员加入宣称性信息。就象你可以说某个成员是公有的或私有的一样，你可能还想说这个是事务的，或者这个假定是个Web service，或这个假定被以XML方式的序列化支持。因此，我们加入特性以提供一般性机制，但是我们在所有的Web service和XML基础设施中都用到了它。我们还给你用特性修饰类和字段的能力。在你的类中，你可以说“当这个类型变成XML时，它应该变成“this”标签名，并且属于“this”XML名字空间。”你将有能力指定一个字段变成一个元素，而另外一个变成属性[译注：此处指XML中的属性]。你还能够控制XML的模式[译注：即schema]；在你的类声明的地方控制它，这样，所有附加的宣称性信息就都可以获得了。一旦以该方式正确地使用特性修饰你的C#代码，系统就可以简单把它转化成XML中一个指定的类，在线上传输，当它传回时，就可以在另一端重建该对象。这都是在一处定义完成的。它不象传统的定义文件或多种信息和命名模式。它就在那儿。当你在IDE中创建它们时，它就给了你完整的声明。我们还可以提供高级工具，让它帮你做这个事。
我知道我有点离题了，但是我们提供的这些基础设施的确令人兴奋。单单因为我们有这些特性，你就可以请求XML序列化基础设施或Web service基础设施把已给出的类翻译成XML。当你这么做了，我们实际上将为这个类配上XSD模式，并且我们将创建一个特别的解析器，它是从我们一般的XML解析器派生出来的（.NET基类的一部分），并且重载方法并加入逻辑，因此它是专门为那个模式服务的。所以，我们已经初始化好一个解析器，可以本地代码的速度解析XML。如果它不正确，我们将给你一个体面的出错信息，它可以精确地告诉你是什么出了问题。我们可以在代码缓存基础设施中缓存它，它将坐等直到下一次一个具有同样模式的类来临并将发生作用，“嘭！”，我的意思是，难以置信，难以置信的生产能力！
Osborn:
所以，在盖子下的确有很多有趣的引擎。
Hejlsberg:
是的，并且我认为，当在这个领域里达到这个思想时，我们是领先的一代。
Osborn:
精彩之至。谢谢，耽误你时间了。
Hejlsberg:
不客气。
关键字词:
