一

1、C#设计过程

?

Bruce Eckel：我听说C#是一个工程师小组在一个屋子里设计出来的？

Anders Hejlsberg：是的。4年来，我们一直呆在这个屋子里。现在，每周一、三、五，我们仍然在这里会面。

Bruce Eckel：我很想了解一些关于C#设计过程的情况。我直接或间接参与过几种语言的设计工作，如Python。在Python设计过程中，Guido van Rossum被我们戏称为“仁慈的独裁者”。

Anders Hejlsberg：哦，Guido van Rossum就相当于我的位置。

Bruce Eckel：那么你是C#小组“仁慈的独裁者”么？

Anders Hejlsberg：我一般扮演最后拍板者的角色。比如，我们被一个问题困扰多时，到了非解决不可、只能作不二选择的时候，是由我来作最后决定的。当然大多数这样的情况下，正确的选择是显而易见的。

Bruce Eckel：C#的设计过程是不是和Turbo Pascal、Delphi十分相似？

Anders Hejlsberg：后面两者的设计过程不是那么规范的。因为Turbo Pascal主要由我一个人设计，而Delphi也是我和Chuck Jazdzewski、Gary Whizin等几个为数不多的人来完成，所以没有必要引入非常规范的设计过程。相反的，C#的设计过程则十分规范，每周一、三、五从1：00到3：00, 我们都会召开一个正式会议，会议议程也相当灵活，所有的问题都会拿到桌面上公开讨论、仔细推敲。我们还在互联网上建立了一个Wiki，这些问题及其解决方案，以及其他一些相关的东西都被发布在上面。

Bruce Eckel：那你们是如何发现这些的问题呢？

Anders Hejlsberg：呵呵，我们有一套行之有效的方法。我们可以通过很多途径来得到用户对语言设计的反馈意见——如软件设计咨询会、网络新闻组。这些反馈意见包括：疑问、软件Bugs、不一致、不规范问题等。这样我们就能有的放矢了。最后我们将这些问题整理成表，并一一重现它们。对于每个问题，我们都会认真对待，询问自己：“我们对这个问题有新的想法吗？真的没有吗？这个问题已经搁置好几个星期了，我们立即花30分钟集中精力研究一下，看这次是否能有所斩获。”

Bruce Eckel：那可能一个问题长期没有解决，都臭不可闻了……

Anders Hejlsberg：也许有些臭问题只有放到下一个版本才能解决了。但是我认为这样一个过程可以保证不会遗漏任何问题，因为它们都被登记在册。有时候，你面对这些问题呆坐了很长时间，可能也没什么结果。但问题毕竟是被我们逮住了，总有一天会再去“拜访”它的。也可能不会再去“拜访”了，但问题终归是不会被弄丢的。

Bill Venners：C#设计小组包含哪些成员，他们都担当什么角色？

Anders Hejlsberg：参与最初的C#设计的有Scott Wiltamuth、Peter Golde、Peter Sollich、Eric Gunnerson和我。C#2.0设计小组包括：Peter Hallam、Shon Katzenberger、Todd Proebsting，以及我自己。微软研究院的Don Syme和Andrew Kennedy承担了大部分一般性研究工作。

?

?

2、语言可用性研究和语言美学

?

Bill Venners：在C#的设计中，可用性研究、市场策略和语言美学的侧重是如何权衡的？

Anders Hejlsberg：一般而言，好的语言设计过程体现了对设计小组成员的美学品味取向的综合，也就是你刚才所说的语言美学观。美学品味带有极大的主观性，很难定论，只有产品出来后，你才能仔细体味它。我认为任何程度的可用性研究都不能取代语言美学的价值，因为可用性研究是极有针对性、非常具体的。可能有人问你：“你认为这部分功能如何？”这个问题很难回答。“你对这个语言有什么看法？”你从何谈起呢？你怎么可能花两个小时就解决掉所有可用性问题？绝无可能。

Bruce Eckel：人们必须深入理解这个问题。

Anders Hejlsberg：使用一种编程语言会经历一个感觉微妙变化的过程。只有使用几个月之后用户才能真正喜欢上它。他们会逐渐发现：“哦，它给人的感觉很舒服嘛。”你不能急于求成。

开始说过，我们在可用性研究上也做了大量工作，但主要是针对特定的功能。

Bill Venners：可以举个例子么？

Anders Hejlsberg：我们将可用性研究的重点放在了IDE功能实现上。我们会问自己：“用户是否知道在这里点击右键会有什么结果？”在纯语言功能部分，我们也考虑了一些可用性问题——例如在一些属性和事件上——不过没什么必要，真的。

我想在可用性研究上，语言特性不可能带来和IDE特性一样高的收益。你可以看到用户点击一个菜单项立即得到正确的反馈信息。而对语言来说，问题要复杂一些。例如：“它的概念容易理解么？”我们通过用户咨询会、留言板，比较好的解决了这些问题。用户需要有个说话的地方，“对于这个新特性，我有这样一些想法，你们是如何考虑的呢？”这样的问题提得越多、尖锐越好，因为你肯定是最希望在产品出来以前就能知道用户的想法，而不是产品推出以后。在一个语言特性被完全敲定前，我们通常都会考虑用户的建议和意见的。

?

二

1、对Checked Exceptions特性持保留态度

?

（译者注：在写一段程序时，如果没有用try-catch捕捉异常或者显式的抛出异常，而希望程序自动抛出，一些语言的编译器不会允许编译通过，如Java就是这样。这就是Checked Exceptions最基本的意思。该特性的目的是保证程序的安全性和健壮性。Zee&Snakey(MVP)对此有一段很形象的话，可以参见：

http：//www.blogcn.com/user2/zee/main.asp。Bruce Eckel 也有相关的一篇文章（《Does Java need Checked Exceptions》），参见：

http：//www.mindview.net/Etc/Discussions/CheckedExceptions）

Bruce Eckel：C#没有Checked Exceptions，你是怎么决定是否在C#中放置这种特性的么？

Anders Hejlsberg：我发现Checked Exceptions在两个方面有比较大的问题：扩展性和版本控制。我知道你也写了一些关于Checked Exceptions的东西，并且倾向于我们对这个问题的看法。

Bruce Eckel：我一直认为Checked Exceptions是非常重要的。

Anders Hejlsberg：是的，老实说，它看起来的确相当重要，这个观点并没有错。我也十分赞许Checked Exceptions特性的美妙。但它某些方面的实现会带来一些问题。例如，从Java中Checked Exceptions的实现途径来看，我认为它在解决一系列既有问题的同时，付出了带来一系列新问题的代价。这样一来，我就搞不清楚Checked Exceptions特性是否可以真的让我们的生活变得更美妙一些。对此你或许有不同看法。

Bruce Eckel：C#设计小组对Checked Exceptions特性是否有过大量的争论？

Anders Hejlsberg：不，在这个问题上，我们有着广泛的共识。C#目前在Checked Exceptions上是保持缄默的。一旦有公认的更好的解决方案，我们会重新考虑，并在适当的地方采用的。我有一个人生信条，那就是——如果你对该问题不具有发言权，也没办法推进其解决进程，那么最好保持沉默和中立，而不应该摆出一个非此即彼的架势。

假设你让一个新手去编一个日历控件，他们通常会这样想：“哦，我会写出世界上最好的日历控件！我要让它有各种各样的日历外观。它有显示部分，有这个，有那个……”他们将所有这些构想都放到控件中去，然后花两天时间写了一个很蹩脚的日历程序。他们想：“在程序的下一个版本中，我将实现更多更好的功能。”

但是，一旦他们开始考虑如何将脑海中那么多抽象的念头具体实现出来时，就会发现他们原来的设计是完全错误的。现在，他们正蹲在一个角落里痛苦万状呢，他们发现必须将原来的设计全盘抛弃。这种情况我不是看到一次两次了。我是一个最低纲领主义者。对于影响全局的问题，在没有实际解决方案前，千万不要将它带入到整个框架中去，否则你将不知道这个框架在将来会变成什么样子。

Bruce Eckel：极限编程(The Extreme Programmers)上说：“用最简单的办法来完成工作。”