[翻译] Anders Hejlsberg访谈录——Geek of the Week

[翻译] Anders Hejlsberg访谈录——Geek of the Week

原文地址：http://www.simple-talk.com/opinion/geek-of-the-week/anders-hejlsberg-geek-of-the-week/

原作者：Richard Morris

译文地址：http://www.cnblogs.com/AndersLiu/archive/2009/03/30/anders-hejlsberg-geek-of-the-week.html

翻译：Anders Liu

摘要：Anders Hejlsberg，C#和.NET框架背后的创造型天才，在12年前加入微软之前，他就以编译器编写者的身份驰名16年了。他的BLS Pascal、Turbo Pascal和Delphi彻底变革了软件开发方式。今天，他依然能够冒出新的想法和激进的倡议。

Anders Hejlsberg, the creative genius behind C#, and much of the .NET framework, had already been famous for sixteen years as a compiler-writer before he joined Microsoft twelve years ago. His BLS Pascal, Turbo Pascal, and Delphi had revolutionized the way that we develop software. Today, he is still bubbling with new ideas and radical initiatives.

Anders Hejlsberg，C#和.NET框架背后的创造型天才，在12年前加入微软之前，他就以编译器编写者的身份驰名16年了。他的BLS Pascal、Turbo Pascal和Delphi彻底变革了软件开发方式。今天，他依然能够冒出新的想法和激进的倡议。

Whether he truly is an international superhero of C# as some claim, Anders Hejlsberg is certainly a visionary. Known as one of the 'big brains' at Microsoft, he was born in Copenhagen in Denmark and studied engineering at the Technical University of Denmark in Lyngby.

不管他是否像人们声称的那样是C#的国际化超级英雄，Anders Hejlsberg绝对是一个幻想家。作为微软“大脑”之一的他，出生在Denmark（丹麦）的Copenhagen（哥本哈根），并在位于Lyngby的Technical University of Denmark学习了工程师。

It was here that Anders began writing programs for the Nascom microcomputer including a Pascal compiler for CP/M and MS-DOS and marketed for the Nascom 2, under the name Blue Label Software Pascal, or BLS Pascal. Later he went to work for Borland and rewrote his compiler to become Turbo Pascal for the IBM PC. This new compiler sold for $49.95, which was far cheaper than any other commercial high-level language. It became hugely popular in the 1980s thanks in part to an aggressive pricing strategy and having one of the first full-screen IDEs. It became popular with hobbyists as a structured replacement for BASIC. This was followed by 'Super Pascal' which had labels, a return statement and expressions as names of types.

在这里Anders开始为Nascom微型计算机编写程序，包括一个针对CP/M和MS-DOS的Pascal编译器，和针对Nascom 2销售的名为Blue Label Software Pascal的编译器，亦称BLS Pascal。之后他去Borland参加工作，并编写了自己的编译器，这款编译器最终变成了针对IBM PC的Turbo Pascal。这款新型编译器售价$49.95，比当时任何其他商用高级语言编译器都要便宜很多。这款编译器在二十世纪80年代非常流行，很大程度上是因为这种盛气凌人的价格策略，以及其具备的首个全屏幕IDE。它深受初学者喜爱，并成为了BASIC的替代品。这之后是Super Pascal，它具备标签、返回语句和类型名字表达式。

Anders' Turbo Pascal version 5.5 finally added object orientation to Pascal, but the Object-oriented culture was in full swing, and so Anders and his team used Apple's draft standard for Object Pascal to create Delphi with a reference-based object model, virtual constructors and destructors, and properties. Delphi is still used to this day to produce high-quality commercial software.

Anders的Turbo Pascal 5.5版最终为Pascal添加了面向对象，但此时面向对象的文化已经全面地铺开了，因此Anders和他的团队使用了Apple关于Object Pascal的标准草案来创建Delphi，包括一个基于引用的对象模型、虚构造器和析构器以及属性。今天人们依然在使用Delphi生产高质量的商业软件。

Anders joined Microsoft in 1996 and was architect for the Visual J++ development system and the Windows Foundation Classes (WFC). The WFC was primarily designed for creating GUIs for Java applications on Windows. J++ was close to Java, but differed in important aspects. A dispute with Sun over this was settled when Microsoft agreed not to advance J++ beyond its mirrored implementation of Java, version 1.1.4. The technology of J++ was eventually recycled, and survived for a while, as part of the Microsoft .NET platform and the J# programming language.

Anders于1996年加入Microsoft，担任Visual J++开发系统和Windows Foundation Classes（WFC）的架构师。WFC主要设计用于使用Java来为Windows应用程序创建GUI。J++很贴近Java，但在关键方面有所不同。为此Microsoft和Sun产生了争执，而最终以Microsoft同意不再发展J++使其超越对应的Java实现——版本1.1.4——而告终。J++的技术最终被回收，并作为Microsoft .NET平台的一部分和J#编程语言的形式得以暂时存在。

Anders was rapidly promoted to Distinguished Engineer in 2000. He is now a Technical Fellow in the Developer Division and chief designer of the C# programming language and a key participant in the development of the Microsoft .NET framework.

很快Anders在2000年被提升为Distinguished Engineer。他现在是Developer Division的Technical Fellow和C#编程语言的首席设计师以及Microsoft .NET Framework开发团队中的关键成员。

Since its initial release in 2000, the C# programming language has been widely adopted and is now standardized by ECMA and ISO.

自从2000年首次发布以来，C#编程语言得到了广泛应用，并已被ECMA和ISO组织纳为标准。

He has co-authored "The C# Programming Language", published by Addison Wesley, and has received numerous software patents. In 2001, he was the recipient of the prestigious Dr. Dobbs Excellence in Programming Award.

他还是《The C# Programming Language》（Addison Wesley出版）一书的合著者，并且获得了多项软件专利。在2001年，他还获得了最有威信的Dr. Dobbs Excellence in Programming Award奖项。

---

译注

本文原作者Richard Morris，以下简称RM；Anders Hejlsberg，简称AH。

RM:

"Anders, why is C# called C#. Wasn't it originally named Cool? There's a rumour going around that it was renamed because of the desire to attract geeks. I jest of course, but why the name change?"

“Anders，为什么C#叫做C#？最初它不是叫Cool么？有传闻说它改名是为了吸引极客（Geek）的注意。当然了，我是在开玩笑，但为什么要改名呢？”

AH:

"Yes, the codename for C# was COOL, which stood for C-style Object Oriented Language. We actually liked that name and even looked at keeping it for the final product, but the trademark lawyers weren't, um, cool with it. So, we had to convene the language naming committee. We wanted to have a reference to the language's C heritage in the name and finally settled on C#. Some other candidates I recall were e-C, Safe C, C-square, C-cube, C-prime, C-star, and Cesium... Looking and those now I'm pretty happy with our choice."

“是的，C#的研发代号就是COOL，表示C-style Object Oriented Language。我们非常喜欢这个名字，并且非常希望能够将其用在最终的产品中，但是商标法不允许，嗯，它太酷了。所以，我们必须召开语言命名委员会会议。我们希望语言的名字能够体现出C的传统，于是最终敲定为C#。其他一些我能回忆起来的候选名字还有e-C、Safe C、C-square、C-cube、C-prime、C-star和Cesium……回忆起这些，我现在还是为我们的选择感到高兴。”

RM:

"What were the fundamental flaws in other languages that you believe drove the development of Common Language Runtime (CLR), and in turn, C#?"

“你认为其他语言中的哪些本质上的缺陷驱动着CLR和C#的开发？”

AH:

"I wouldn’t say we were motivated by fundamental flaws in other languages. It was more that we needed to modernize the Windows developer experience. At the time we had multiple distinct development toolsets, e.g. Visual Basic for Rapid Application Development, C++/MFC for systems-level programming, VBScript and IIS for Web applications, and so on. There was little or no sharing of code and skills between these toolsets and your application model would effectively dictate a particular programming language. Furthermore, application interoperability was done through COM, which is a very low-level mechanism, programmers often had to do explicit memory management, there was no common exception and error handling mechanisms, etc. etc. We wanted to fix all of those issues by creating a unified programming platform that supported multiple programming languages, was object-oriented at the core, and provided a shared API framework with modern services such as garbage collection and exception handling."

“我们并不以其他语言中的本质缺陷为动机。我们更多是为了给Windows开发人员提供更加现代化的体验。那个时候我们拥有很多不同的开发工具集，如用于快速应用程序开发的Visual Basic、用于系统级编程的C++/MFC、用于Web应用程序的VBScript和IIS等等。在这些工具集之间，很少甚至没有代码和经验能够共享，而且你的应用程序模型往往是受特定的编程语言支配的。另外，应用程序的互操作是通过COM进行的，这是一种非常底层的机制，程序员通常必须进行显式的内存管理，也没有通用的异常和错误处理机制，等等等等。我们希望创建一个统一的编程平台来解决这些问题，这样一个平台应该能够支持多种编程语言、以面向对象为核心，并能提供一个共享的API框架以及流行的服务，如垃圾收集和异常处理。”

RM:

"There's no real concept of inner classes in C#--you can declare a class inside another class, but it's not really the same as an inner class in Java, unless you're talking about those declared static. Did you consider introducing them when you were designing the language? if so why did you reject them?"

“在C#中没有真正的内部类的概念——你可以在另一个类中声明一个类，但这并不是像Java中那样的真正的内部类，除非你将它声明为静态的。在你设计这个语言的时候，你考虑过加入这个概念吗？如果考虑过，你为什么又放弃了呢？”

AH:

"Correct, C#'s nested classes do not implicitly carry a reference to an instance of the enclosing class, so in Java terms they are like static inner classes. C#'s view is that nesting of classes is just a way to control lexical scoping. If you need to, it takes but a line or two of code to store a reference to an outer class instance in a nested class, so you can pretty easily emulate Java's inner classes.

“是的，C#的嵌套类并不隐式地携带一个指向包装类实例的引用，所以从Java的角度看，这更像是静态的内部类。C#认为类的嵌套只是一种控制词法作用域的途径。如果你需要的话，可以通过一两行代码在包装类示例中存放一个嵌套类的实例，因此你可以非常简单地模拟出Java的内部类。

I think a much bigger difference is C#'s support of lambda expressions and closures, both cornerstones of functional programming. These are still missing from Java, although there have been multiple proposals to add them. In terms of expressiveness I think these are far more important than inner classes."

我想还有一个巨大的区别在于C#对lambda表达式和闭包的支持，这都是函数式编程的基石。但Java依然没有加入这些特性，即便有很多提议要求添加。从表现力的角度来说，我认为这些远比内部类更重要。”

RM:

"I've noticed that the event registration/un-registration thread is unsafe? Why is that?"

“我注意到事件的注册/取消注册不是线程安全的，这是为什么？”

AH:

"No, that's not the case. If you declare an event without explicitly implementing the add and remove accessors (the C# language specification uses the term "field-like event" for this), the C# compiler automatically generates thread-safe accessors for you.

“不，并不是这样的。如果你在声明一个事件时没有显式实现其add和remove访问器（C#语言规范使用‘类似于字段的事件’这种语法），C#编译器会自动为你生成线程安全的访问器。

Perhaps what you are referring to is that you must take extra care when writing thread safe code that raises events. For example, say you have a class that declares and raises an EngineFlameout event:

你所提到的问题，可能是在编写线程安全的用于触发事件的代码时需要格外主义的问题。例如，假设你有一个类，声明并触发了一个EngineFlameout事件：

public class RetroRocket
{
    public event EventHandler EngineFlameout;

    protected virtual void OnEngineFlameout(EventArgs e) {
        if (EngineFlameout != null) EngineFlameout(this, e);
    } 
}

This code looks innocent enough, but it isn't thread safe. Specifically, a race condition arises when another thread unsubscribes to the EngineFlameout in the short period of time between the null check and the invocation of the event handler—the event might then become null and an exception would occur. The code can be made thread safe by first copying the event delegate into a local variable, i.e.

这段代码看上去有够简单，但它并不是线程安全的。尤其是，当在null检查和调用事件处理器之间的这一小段时间里，如果其他线程取消注册EngineFlameout事件，就会产生竞态条件——此时事件可能是null，并且会抛出一个异常。只要首先将事件委托复制到一个局部变量中，就能让这段代码变成线程安全的，例如：

protected virtual void OnEngineFlameout(EventArgs e){
    var handler = EngineFlameout; 
    if (handler != null) handler(this, e); 
}

This is really no different from code that tests whether an object reference is null before calling a method on the object, it just so happens that we're dealing with events here. As with literally any piece of code written in an imperative programming language, extra work is required to ensure thread safety."

对于任何首先检查对象是否为null，再在对象上调用方法的代码而言都是这样，处理事件时也不例外。事实上，任何使用命令式编程语言编写的代码，都需要做额外的工作才能确保线程安全。”

RM:

"It's probably more of a CLR issue, but why doesn't the "throw" statement work as advertised? It always resets the stack trace even if used without an argument "

“这个可能是CLR的一个大问题，为什么‘throw’语句不像宣称的那样工作？它总是重置堆栈跟踪，即便在使用的时候没有携带参数。”

AH:

"If you "throw" without an argument (known as a rethrow), the StackTrace property of the exception is not reset. That is one of the main differences between the implicit and explicit forms of the "throw" statement. That said, the CPU stack is always unwound upon entry to a catch block, even if that catch block rethrows the exception or throws another exception. This might be the issue you are referring to. It is a natural effect of the CLR's exception handling being built on top of Windows Structured Exception Handling (SEH). A team mate of mine, Mike Stall, has a good blog post on this topic:

“如果你在‘throw’的时候没有携带参数（称作rethrow），异常的StackTrace属性是不会重置的。这是隐式和显式形成‘throw’语句之间的主要差别之一。这就是说，在进入一个catch块的时刻，CPU堆栈永远都是未展开的，即便catch块rethrow了该异常或throw了另一个异常。这可能就是你所提到的问题。这是CLR异常处理的本质特征，因为它是构建在Windows结构化异常处理（SEH）之上的。我的一个团队成员Mike Stall写了一篇有关这个主题的不错的blog：

http://blogs.msdn.com/jmstall/archive/2007/02/07/catch-rethrow.aspx”

RM:

"When you want to hack up an experiment quickly, do you use C#? if not, what do you use?"

“当你需要做一个快速实验时，你会使用C#吗？如果不使用C#，你会用什么？”

AH:

"Well, I pretty much do all my experimentation in C#. Dogfooding is important!"

“嗯，我的几乎所有试验都是用C#做的。狗食是很重要的！”

RM:

"How do you think the introduction of the new "dynamic" type in C# 4.0 will affect application performance and reliability?"

“你如何看待C# 4.0中新引入的‘dynamic’类型？它会对应用程序的性能和可靠性带来哪些影响？”

AH:

"The "dynamic" type in C# 4.0 makes it much, much easier to interface with anything for which you do not have a static .NET type—for example, COM and OLE Automation libraries, the JavaScript and HTML object models, objects from dynamic languages such as Python and Ruby, or REST based Web Services. Where you would previously have to go through reflection-like APIs, such as Type.InvokeMember and ScriptObject.Invoke, you can now just write regular methods calls that are resolved dynamically at run-time.

“C# 4.0中的‘dynamic’类型极大地简化了与其他不具备静态.NET类型的系统之间的接口——如COM和OLE Automation库、JavaScript和HTML对象模型、来自动态语言如Python和Ruby的对象或基于REST的Web Services。之前你必须使用反射风格的API，如Type.InvokeMember和ScriptObject.Invoke，而现在你只需要编写常规的方法调用，而在运行时对其进行动态解析。

C# 4.0 really is a happy marriage of static and dynamic programming—instead of picking one or the other, you get to do both in the same programming language.

C# 4.0真的是静态和动态编程之间完美的联姻——不用破坏其中的任何一方，两者都能用同一种编程语言来实现。

I expect performance and reliability to both benefit. Similar to IronPython and IronRuby, C# 4.0 uses the Dynamic Language Runtime (DLR) for all dynamic dispatch, and the DLR has been extensively tuned to provide great performance."

我认为这对性能和可靠性方面都有益处。和IronPython和IronRuby类似，C# 4.0使用动态语言运行时（DLR）进行所有的动态分派，而DLR经过了大量的微调，可以提供卓越的性能。”

RM:

"By the time .NET came on the scene, Java had already been around for a number of years as a successful managed platform, and whilst there are obvious similarities between C# and Java, there are also some differences. When designing the C# programming language, what did you learn from the Java experience, and were there any shortcomings in that language that you tried to avoid?"

“在.NET走上历史舞台的时候，Java作为一款成功的托管平台已经风光了好几年了。而C#和Java之间有很多明显类似的地方，也有很多不同。在设计C#编程语言时，你从Java中借鉴了哪些经验，又有哪些不足是你需要努力避免的？”

AH:

"Well, Java certainly demonstrated the value of type safety, exception handling, and garbage collection in a mainstream programming language. Those just do wonders for productivity.

“嗯，Java的确展示出了再主流编程语言中，类型安全、异常处理和垃圾收集的巨大价值。这些都是生产力方面的奇迹。

Many programming languages influenced C#. Java was one of them, but C++ and Delphi also influenced our design. If I had to call out a few of the differences between C# and Java from a programming language point of view, I might mention C#'s unified type system (value types, boxing, and unboxing), first class support for properties and events, delegate types, separation of logical naming and physical packaging, and unsafe code.

C#受到很多编程语言的影响。Java正是其中之一，但C++和Delphi也影响了我们的设计。如果非要从编程语言的角度说出C#和Java之间的区别，我认为这就是C#的统一类型系统（值类型、装箱和拆箱），对类的一流支持，包括属性和事件、委托类型、逻辑名字和物理打包之间的分离、以及不安全代码。

Also, C# and .NET's design for generics doesn't rely on erasure but rather has true representation of type parameters at run-time. I think this brings about many important advantages. And, of course, in C# 3.0 we introduced Language Integrated Query (LINQ) which really has no counterpart in Java."

另外，C#和.NET对泛型的支持并不依赖于擦除，而是对运行时类型参数的真实体现。我想这会带来很多优点。当然，在C# 3.0中我们还引入了语言集成查询（LINQ），这在Java中绝对没有对应的特性。”

RM:

"Do you believe the LINQ query comprehension syntax (is this its official name?) is a successful feature, or more of an interesting experiment?"

“你认为LINQ查询内涵语法（这是官方的名字吗？）是一种成功的特性，还是更多只是一种有趣的实验？”

AH:

"We call them "Query Expressions" in the language reference, and, yes, I absolutely consider them a successful feature. The fact that you can write your queries in a high-level SQL-like syntax is incredibly important to a lot of programmers. It makes the feature much more approachable. Yet, because the compiler simply turns queries into sequences of method calls with lambda expression arguments, we get a great extensibility story.

“在语言参考中我们称之为‘查询表达式’，我绝对认为这是一种成功的特性。实际上可以用高级的类似于SQL的语法来编写查询，对很多程序员来说出乎意料的重要。这使得这种特性更加贴近开发者。而且，因为编译器只是简单地将查询转变为一系列对携带lambda表达式参数的方法调用，所以我们能得到强大的可扩展性。

When I talk to C# or VB.NET programmers now, most of them use LINQ in their day to day coding, be it LINQ to Objects, LINQ to XML, LINQ to SQL, the Entity Framework, or one of the many third party LINQ providers. And if they don't, it is usually more a question of downlevel deployment than usefulness of the feature. The ability to query in-memory objects, XML, and relational data with a single unified syntax is just really compelling."

现在，在我和C#或VB.NET程序员聊天时，发现他们中的大多数都在每天的编程工作中使用LINQ，他们使用LINQ to Objects、LINQ to XML、LINQ to SQL、Entity Framework或者很多第三方LINQ提供程序。如果他们不使用LINQ，在降级部署时就会遇到比使用该特性更多的问题。使用单一统一语法来查询内存中对象、XML和关系型数据的这种能力，是确实可以通过编译的。”

RM:

"Nemerle showed that adding meta-programming support to C# was a serious possibility? Have you ever considered it?"

“Nemerle表明在C#中添加元编程支持是很有可能的？你考虑过这一点吗？”

AH:

"It is one of the directions we are looking at for future versions of C#. Indeed, I see meta-programming as a piece of our bigger "Compiler as a Service" theme that we are working on for a future release. We want to open up our compiler so it becomes an API you can call to compile a piece of code and get back expression trees and/or IL. This enables a whole host of scenarios, such as application programmability, an interactive prompt, user-written refactorings, and domain specific languages that have little islands of C# imbedded in them."

“这是我们所关注的C#未来版本的一个发展方向。确实，我认为元编程是我们‘编译器即服务’这个庞大主题中的一部分，我们正在为他的发布进行着努力。我们希望开放编译器，使其成为一个API，你可以调用这个API来编译代码片段，并得到表达式树和/或IL。这实现了一种完全宿主的场景，如应用程序可编程性、交互式提示符、用户编写的重构和领域特定语言，所有这些都可以提供一小块地方将C#嵌入进去。

（完）