Reporter: I've heard C# was created in a room with a group of designers.
记者：听说C#是你的设计小组在一个 房间里设计出来的。
Hejlsberg: Yes. It was the same room for four years. We’re still in that room every Monday, Wednesday, and Friday.
海尔斯伯格：是的。我们在同一个房间 里待了 4年。现在每周一、三、五，我 们还在那儿举行例会。
Reporter: I’m curious about the design process for C#. I've been involved in several different language designs, either directly or peripherally. In the Python process, for example, Guido van Rossum is humorously referred to as the benevolent dictator.
记者：我对C#的设计过程很好奇。这 几年，我直接或间接地参与了几种编程 语言的设计。例如在开发Python (直译 式计算机程序设计语言）的过程中，罗 森被大家幽默地称为仁慈的独裁者。
Hejlsberg: That’s sort of my same position.
海尔斯伯格：我跟他扮演同样的角色。
Reporter: You are the benevolent dictator for C#?
记者：你也是C#设计过程中仁慈的独裁者？
Hejlsberg: I‘m the tie breaker. Once we’ve gone around an issue enough, and it is time to just make a decision one way or the other, I make it. But in most cases the decision is obvious.
海尔斯伯格：我是打破僵局的人。一旦我们在一个问题上停留很久并且到了该作 某种决定的时候我就会作出最后的决定。 但是多数时候，这些决定都是很明显的。
Reporter: Is that similar to how Turbo Pascal and Delphi were designed?
记者：满轮帕斯卡（Turbo Pascal)和 Delphi (Windows平台下著名的快速应用 程序开发工具)也是这样设计出来的吗？
Hejlsberg: Those were less formal. I designed Turbo Pascal mostly by myself. I designed Delphi with Chuck Jazdzewski and Gary Whizin，but the group was small enough that we didn’t really need a formal process. For C#，on the other hand, it has worked really well to formalize: every Monday， Wednesday, and Friday from 1:00 to 3:00，we have a regularly scheduled meeting. We have a living agenda. Issues bubble to the top, and we knock them off. We have a wiki now on the internal web with the issues list，resolutions for them, and so on.
海尔斯伯格：它们没这么正式。涡轮帕斯 卡的设计基本由我一个人完成。查 克扎斯载沃斯基、加里威姿恩 和我一起设计了 Delphi。由于设计 团体很小，我们不需要正式的流 程。另一方面，C#的工作是很正 式的。我们在每周一、三、五的 下午13点举行例会。我们还有一 个日程表，问题像冒泡一样跑到日 程表的最上面，然后我们快速地解 决。在公司内部，我们有一个自己 的维基百科，上面列出了一些问题 和问题的解决方案等。
Reporter: How do issues bubble to the top?
记者：那些问题是怎样浮到表面的？
Hejlsberg: Well, they just sort of do. We have many ways customers can give inputsoftware design reviews, news groups—all sorts of ways we get feedback on the language. The feedback brings up issues, bugs, inconsistencies, irregularities. So there are things we know we want to do. They end up on the list，and then we keep iterating. We’ll look at one and ask, “Do we have any new thoughts on this? No new thoughts? Well, this thing has really rotted here for several weeks, let’s try to attack it for thirty minutes and see if we can get somewhere this time.”
海尔斯伯格：嗯，只是排序而已。客户 可以通过多种途径向我们反馈，比如软 件设计评审会议、新闻组等，通过各种 方法我们得到这个语言的反馈。这些反 馈把问题、漏洞、不一致的设计和不规 则的设计等反映给我们。然后我们就知 道自己接下来的工作了。列表上排满了 这些东西，然后我们用迭代的方式修正 它们。我们看到一个问题就会问：“对 这个问题，大家有没有什么新看法？没 想法吗？嗯，这个事情已经在这儿待了 几周了，我们来用30分钟解决一下， 看看这次是不是能想出办法。”
Reporter: So when something smells bad enough...
记者：也就是说，当事情到了比较糟糕 的地步……
Hejlsberg: Or when something smells good enough that you want to do something with it in the next release, you work on it. But I think this process is just a way to make sure nothing falls through the cracks. You put everything on that list.Something can sit on that list for a long time, and then maybe you decide you’re not going to do it. But at least it gets captured， and there’s a way to revisit it. It will either happen or not happen, but it won’t get lost.
海尔斯伯格：或者如果事情进展 很好，以至于我们想把它放在下 一个版本里面发布的时候，我们 就会投入很多。但是我认为，这 个流程只是保证我们不遗漏事情 而已。所有的事情都列在曰程表 上面。也许一些事情已经拖了很 久，你就会放弃它们。但是，至 少它们没有被漏掉，并且你也可 以再回过头去看这些事情。事情 有可能继续，也可能中止，但是 不会被忽略掉。
Reporter: Who was on the C# design team and what roles did they play?
记者：C#设计小组的成员有哪些？他 们各自的任务如何？
Hejlsberg: The original C# design team was Scott Wiltamuth, Peter Golde, Peter Sollich, Eric Gunnerson, and myself. The C# 2.0 design team is Peter Hallam， Shon Katzenberger, Todd Proebsting, and myself. Most of the credit for generics goes to Don Syme and Andrew Kennedy from Microsoft Research.
海尔斯伯格：C#设计小组最初有斯科 特威尔塔姆斯、彼得戈尔德、彼得 索里契、埃里克加纳森和我。C#2.0 的设计小组有彼得哈勒姆、肖恩卡 曾伯格、托德博尔伯斯汀和我。大部 分泛型的成功都要归功于微软研究部门 的唐塞姆和安德鲁肯尼迪。
Reporter: How much of the design of C# was based on usability research, how much on marketing choices, and how much on aesthetics?
记者：C#的设计分别有多大一部分是基 于可用性研究、市场抉择和编程美学？
Hejlsberg: Ultimately, good language design boils down to assembling a team of people who have good taste. It boils down to programming aesthetics, as you are saying. Good taste is extremely subjective and hard to define， but you can sort of recognize it when you see it. And I don’t think any number of usability studies can give you what taste gives you, because usability studies tend to be very vertical. A study might ask，“What do you think of this particular feature?” But it’s not easy to ask, “What do you think of this language?” Where would you begin? How can you possibly attack that in a two-hour usability study? It’s just impossible.
海尔斯伯格：归根结底，良好的语言设 计需要一个有品位的团队。就像你提到 的，要归功于编程美学。好的品位很难 定义，因为它是非常主观的。但是当你 看到某种东西的时候就会想起它。我认 为无论多少可用性研究都不如品味带给 你的那么多，因为可用性研究是垂直 的。一项调查可能会问：“您认为此特 性如何？”但是不会问：“您认为此语言 如何？”从何开始呢？你能通过两个小 时的可用性研究解决可用性问题吗？不 可能。
Reporter: Somebody has to have depth of understanding.
记者：一些人需要有很深的理解。
Hejlsberg: Working with a programming language is a much more immersive process. People don’t really come to appreciate a programming language until they’ve worked with it for months. And then they may gradually realize, “Wow, this is really comfortable.” You just can’t do that very quickly. That being said, we did a bunch of usability studies, but they were more vertically targeted on particular features.
海尔斯伯格：使用一种编程语言是一个 使人沉醉的过程。只有在使用几个月之 后，人们才会慢慢地欣赏一种语言。他 们会渐渐意识到，“啊，使用这种语言 真舒服。”你不可能很快就得到这种印 象。其实，我们也做了很多可用性研 究，但都垂直集中在某些特性上。
Reporter: For example?
记者：比如说？
Hejlsberg: Most of it was actually usability studies of IDE features. We might ask, “Can people understand that they right click to do this or that?” We did some usability studies for the pure language syntax itself —I think we did some with properties and events, for example—but it was not necessary really. I don’t think that you get as high a yield from usability studies for language features as for IDE features. IDEs are very interactive. You can watch users right click menu items and get good feedback. For programming languages, the question is more, “Is it conceptually understandable?”That’s done very well by having a customer advisory councils, sounding boards. You want places where you can say, “Here’s what we’re thinking about doing for this particular new feature. What do you all think?” And you actually urge them to shoot as many holes in it as possible, because you’d much rather know before you put in the feature than after. So unless a language feature is a complete slam dunk, we tend to make use of those kinds of sounding boards.
海尔斯伯格：实际上，大部分可用性研 究都集中在集成开发环境的特性上。我 们有可能会问：“使用者会知道通过点 击右键来做这个或那个吗？”我们也对 纯粹的语法做了可用性研究，比如属性 和事件，但实际上没有必要。我认为对 语言做可用性研究的收益比对集成开发 环境的特性做相关研究的相同。集成开 发环境有很强的互动性。 你可以看到用户右键菜 单里的条目，并且可以 得到良好的反馈。对于 编程语言，有更多的问 题，比如：“这个东西 在概念上可以理解吗？ ” 客户建议委员会通过 “传声板”能很好地解决 这种问题。我们希望可 以有一个地方向客户提问，比如：“这 是我们对某个新特性的理解，你们感觉 怎样？”同时，我们会要求客户尽量找 出其中的漏洞，因为我们喜欢在实现特 性之前了解问题，而不是实现之后。因 此，除非一个语言特性是完全清晰的， 否则我们都会使用诸如“发声板”之类 的办法向用户了解。
Reporter: C# doesn’t have checked exceptions. How did you decide whether or not to put checked exceptions into C#?
记者：C#没有受控异常。你如何决定 C#是否引入受控异常？
Hejlsberg: I see two big issues with checked exceptions: scalability and versionability. I know you’ve written some about checked exceptions too, and you tend to agree with our line of thinking.
海尔斯伯格：我发现受控异常有两个大 问题：扩展性和版本控制。我知道你也 写了一些关于受控异常的资料，你应该 会同意我的看法。
Reporter: I used to think that checked exceptions were really great.
记者：我过去真的认为受控异常是很好 的想法。
Hejlsberg: Exactly. Frankly, they look really great up front, and there’s nothing wrong with the idea. I completely agree that checked exceptions are a wonderful feature. It’s just that particular implementations can be problematic. By implementing checked exceptions the way it’s done in Java, for example, I think you just take one set of problems and trade them for another set of problems. In the end it’s not clear to me that you actually make life any easier. You just make it different.
海尔斯伯格：确实。坦率地说，最开始 的时候，它们确实看上去很不错，而且 这种想法也没什么问题。我完全认同受 控异常是很好的特性。只是某些特性的 实现会有问题。比如说，按照Java的方 式，你只是把一堆问题转换成另外一堆 问题。最终，我并不认为你实际上已经 把问题简化了，你只是把这些问题换了 个样子而已。
Reporter: Was there a lot of disagreement in the C# design team about checked exceptions?
记者：C#设计团队对受控异常有分歧 吗？
Hejlsberg: No, I think there was fairly broad agreement in our design group. C# is basically silent on the checked exceptions issue. Once a better solution is known—and trust me we continue to think about it—we can go back and actually put something in place. I’m a strong believer that if you don’t have anything right to say, or anything that moves the art forward，then you'd better just be completely silent and neutral, as opposed to trying to lay out a framework. If you ask beginning programmers to write a calendar control, they often think to themselves, “Oh，I，m going to write the world’s best calendar control! It’s going to be polymorphic with respect to the kind of calendar. It will have displayers, and mungers, and this, that, and the other.” They need to ship a calendar application in two months. They put all this infrastructure into place in the control, and then spend two days writing a crappy calendar application on top of it. They’ll think, “In the next version of the application, I’m going to do so much more.” Once they start thinking about how they’re actually going to implement all of these other concretizations of their abstract design, however, it turns out that their design is completely wrong. And now they’ve painted themselves into a comer, and they have to throw the whole thing out. I have seen that over and over. I’m a strong believer in being minimalistic. Unless you actually are going to solve the general problem, don’t try and put in place a framework for solving a specific one, because you don’t know what that framework should look like.
海尔斯伯格：没有，我们整个团队达成 了广泛共识。基本上，我们把受控异 常的问题暂时放置。一旦找到更好的 解决方案——相信我，我们会继续考虑 它，我们会回过头做实事。我坚信，如 果没有什么好说的，没有更好的解决方 案或路径，那么你最好完全保持沉默和 中立，而不是去设计框架。如果你要求 一个入门级的程序员写一个日历控件， 他们通常会对自己说：“啊，我要写一 个世界上最好的日历控件，它将会是多 形态的日历，它会有显示器，芒格，还 有这个，还有那个，等等。”他们需要 在两个月内完成这个控件。他们把所有 的基础框架都放到了控件里面，然后花 两天时间在上面写了一个蹩脚的日历程序。他们会想，“下个版本，我会做更 多事情。” 一旦他们开始思考如何把自 己的抽象设计具体化的时候，他们就会 发现自己的设计完全错误。现在他们把 自己逼上了绝路，不得不放弃所有的东 西。我经常看见这样的事。我是一个坚 定的“最小化主义者”。除非你真的是 要解决一般性问题，否则就不要尝试用 一个框架来 解决具体问 题，因为你 根本就不知 道那个框架 应该是什么 样子。
Reporter: The Extreme Programmers say, “Do the simplest thing that could possibly work.”
记者：极限 编程人员 说，“做最 简单的事才能有效。”
Hejlsberg: Yeah, well, Einstein said that, “Do the simplest thing possible, but no simpler.” The concern I have about checked exceptions is the handcuffs they put on programmers. You see programmers picking up new APIs that have all these throws clauses, and then you see how convoluted their code gets, and you realize the checked exceptions aren’t helping them any. It is sort of these dictatorial API designers telling you how to do your exception handling. They should not be doing that.
海尔斯伯格：是的。爱因斯坦说过， “要尽可能地最简单，而不是比较简 单。”我担心受控异常会成为程序员的 手铐。当你看见程序员拿到如此有着复 杂拋出语句的新应用程序界面的时候， 你会发现他们的代码是如此的回绕，你 会意识到受控异常对他们没什么帮助。 这好像是专制的应用程序界面设计者告 诉你必须怎样进行异常处理。他们不应 该那样做。