C#首席架构师Anders Hejlsberg访谈 (转贴2)

win32c 2003-01-12 04:19:27
Osborn:
我们已经讨论关于Java、C++和脚本语言。在PDC上,我听到很多人争论.NET IL(IL是微软中间语言,所有编译器都必须产生它以运行在.NET框架上)和运行于Java虚拟机中的Java字节码没什么两样。从你的谈话中,显然你并不同意这一点。你介意进一步评论它们之间的区别吗?
Hejlsberg: 我当然不同意这种说法。首先,ILs的思想是一种非常老的思想了。你可以追溯这个概念到UCSD Pascal p-machine(一个早期的个人计算机Pascal实现)或者Smalltalk。P-code曾被Basic和Visual Basic使用,Word的一个组成部件,内部使用p-code引擎,因为它更精简。所以,p-code根本就不是什么新玩意。

我认为,我认为我们使用的IL的方式对此感兴趣:我们给你一个选择—如果你愿意—你可以控制将IL编译或翻译为本地代码的时机。实际上,使用managed C++,你可以直接从源程序生成本地代码。Managed C++还可以生成IL,就象C#和VB那样。当你安装你的代码时,我们给你一个编译选项,可以把IL编译成本地代码。因此,当你运行它们时,就不会有即时编译负担。我们还给你提供了一个动态运行和编译代码的选项:即时编译。有了IL,就给你带来了很多便利,比如它提供了这些能力:移植到不同的CPU架构,引入真正的类型安全,并在此之上构建安全系统。

我认为我们的IL设计和Java字节码关键区别在于,我们做出了超前的决定—不用解释器。我们的代码永远本地运行。因此,即使产生IL,你也从来都不会运行解释器。我们甚至还提供了不同风格的JITs。对于精简框架(compact framework),我们有EconnoJIT,就象我们称呼它的一样,它是一个非常简单的JIT(编注:.NET Compact是.NET framework的一个子集,是为移植到其它设备和平台而设计的)。对于桌面版,我们有完备功能的JIT。我们甚至有可和我们的C++编译器共用一个后端的JIT。不过,这都会比较耗时,因此你只应该在安装时使用它们。

一旦你做出偏向于执行本地代码而不是解释代码的决策,它就会强烈地影响IL的设计。它改变了应该包括那些指令,应该包括哪些类型信息,以及它应该如何表达。如果你仔细看看两种IL(译注:即.NET IL和Java字节码),你就会注意到它们很不一样。从某种意义上讲,我们的IL是类型中立的。指令里没有指定引数类型的信息。进一步来说,它是靠已经压栈的东西推断出来的。这种方式使IL更为精简。无论如何,一个JIT编译器需要知道那些信息,因此没有理由在指令里携带它们。所以,我们最终做出了不一样的设计决策,而这使得容易把IL翻译成本地代码。

Osborn:

解释方式和你描述的方式有何不同?

Hejlsberg:

解释器的核心是一个循环—从p-code流取得一些字节,然后进入一个大大的switch声明,“哦,这是ADD指令,因此它到这儿来,但这不是…”等等。

解释器模拟CPU。我们反其道而行之,我们只走一条道,我们一直都走一条道,我们把指令翻译为机器码。现在,在EconoJIT的情况下,机器码实际上非常简单,它只创建一个调用和压栈指令的列表,并且调用运行时辅助器,然后运行时辅助器引发这个列表。当然,这个代码比解释的代码执行得快。

Osborn:

让我用一句话来总结一下:你们完全编译代码。因此当你编译完时,bits已经完全准备好运行了,尽管从IL翻译成机器码的时机可能不一样。

Hejlsberg:

是的。但是,如果是在一个内存受限的小设备的环境里,运行完就可将代码丢弃掉。

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发行版是微软历史中最高质量的发行版本之一。

...全文
61 4 打赏 收藏 转发到动态 举报
写回复
用AI写文章
4 条回复
切换为时间正序
请发表友善的回复…
发表回复
wincore 2003-02-22
  • 打赏
  • 举报
回复
up
mgspeed 2003-01-16
  • 打赏
  • 举报
回复
up
benbencatrabbit 2003-01-12
  • 打赏
  • 举报
回复
up
mouseanAnya 2003-01-12
  • 打赏
  • 举报
回复
MARK!

7,763

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 非技术区
社区管理员
  • 非技术区社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧