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

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

摘要: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.


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。


"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?"



"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……回忆起这些,我现在还是为我们的选择感到高兴。”


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



"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框架以及流行的服务,如垃圾收集和异常处理。”


"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?"



"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.


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."



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



"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.


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:


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.


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."



"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 "



"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:



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



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



"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’类型?它会对应用程序的性能和可靠性带来哪些影响?”


"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经过了大量的微调,可以提供卓越的性能。”


"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?"



"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.


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.


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中绝对没有对应的特性。”


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



"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.


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和关系型数据的这种能力,是确实可以通过编译的。”


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



"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."



posted @ 2009-03-30 15:38  Anders Liu  阅读(...)  评论(...编辑  收藏