C＃揭密 （和C#首席设计师的对话）

C＃揭密 （C#首席设计师的访谈录）

小气的神  2001.08.12

本来想转载一篇Borland CEO Dale L. Fuller的访谈录，不过发现了这一篇文章，也是一个访谈录。比较起来我更喜欢这篇有关C＃的，虽然很长但没有Borland的那篇这么市场了，那么关心以后的市场，自己公司的发展方向，特别时当Microsoft表明不再支持和预装JVM了之后，Borland将如何发展等等占了大量的篇幅。这篇《An Interview with Microsoft Chief Architect Anders Hejlsberg 》我想更有意思一些，也会有人更感兴趣一些。

这篇访谈录的主人公:Anders Hejlsberg 在Microsoft大名鼎鼎，因为目前象他这样的位置的人在MS不会超过10个（盖茨自己还占了一个，而且是首席称号），这之前他设计过Turbo Pascal，而且之后领导参与了Delphi的设计工作。也许我们应当开始关注这个人，并且记住他的名字：Anders Hejlsberg

本来想翻译它的，不过自己向来是宁转不翻，宁抄不写；再想想自己的水平还无法翻译好这样的精品，另外这样的文章中会涉及到许多有关编程语言的比较和论点，对中国开发人员来说会有些敏感；如果你偏爱它翻译时就会不知觉的用一些感情的母语去诠释它，同样对于你不喜欢的就会用另外一些悲观的词语，对于每个阅读的人来说也许可能就不公正了。无意影响你的思考和阅读，也无意引起有关语言优劣的争论。保持它的原汁原味，大家自己去感受吧。不过这篇文章绝对值得翻译，我期待着它的中文版出现。谢谢这位译者先。

访谈录中大约有近30个问题，讲了许多技术热点和看法，我总结了一些我认为有意思的东西，比如：

 C#是否是Java的克隆？C#是否是用来代替Java的？
 C#被定位成：C/C＋＋家族中第一个面向组件的语言。
 Java中没有enums和指针，C＃中都有，那么设计C＃时如何实现和权衡？
 大师级的互操作性的概念
 “unsafe code”的方方面面。
 “language” 和 “runtime”，我知道许多人在谈论Java时混淆了两者。
 用C＃可以用 unsafe code，而VB不行。
 服务器端的VBScript,JavaScript现在不在是运行时边解释边运行的了.
 .NET IL 和 JVM 的区别和不同。
 Java和C＃的“namespaces”有什么不同还是两者是相似的，但实现不同？
 当问到C#,NET framework,Visual Studio .NET 的Release 时间时的回答.
 Microsoft已向ECMA提交了C#和CLI，难道MS无意控制C#,MS出于何种考虑呢？
 对于COM 和 C＃规范化的看法。
 "pure C#"  ,"pure .NET" ,对"pure Java"的看法。
 永远的热点：XML

下面的英文是原文中的节选，你可以Review一下，太多了。另外还有一篇《Microsoft .NET vs. J2EE: How Do They Stack Up? 》的文章也一起附带。
原文URL：http://windows.oreilly.com/news/hejlsberg_0800.html
另一个URL：http://java.oreilly.com/news/farley_0800.html

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

I think one of the key differences between C# and these other languages, particularly Java, is that we tried to stay much closer to C++ in our design

Why are there no enums in Java, for example? I mean, what's the rationale for cutting those? Enums are clearly a meaningful concept in C++. We've preserved enums in C# and made them type-safe as well.

Just because code is marked "unsafe" does not mean that it is unmanaged. Of course, we're not just throwing in unsafe pointers and leaving people vulnerable to downloading unsafe code over the Internet. Unsafe code is deeply tied into the security system.

We can't afford to rewrite all of our software. The industry just can't afford it, especially now when we're moving on Internet time. You've got to leverage what you have, and so I think interoperability is just key. We focused hard on giving programmers all of the right solutions for interoperating with Internet standards, such as HTTP, HTML, XML, and with existing Microsoft technologies, so you don't fall off a cliff the minute you find that something isn't provided by the new .NET environment, or when you realize you want to leverage some existing API or component.

We're going to build a platform that actually allows you to implement multiple programming languages and also have them share a common set of APIs (Application Programming Interfaces). Let's face it, some people like to program in COBOL, some people like to program in Basic, some like C++, and some will like C#, I hope. But we're not trying to tell you to forget everything you ever did. We're not saying, "Now that there's only one language, there shall be no further innovations in this race." We're saying that our industry advances by its flexibility. How did Java come about? It came about because there were programming languages before it and there will be programming languages after it. We want to build a platform where your preference for one language over another doesn't negate the whole value proposition. We want to create a platform where there can be innovation. Who's helping COBOL programmers today? Who's taking them to the Web? Only on the .NET platform can you embed Fujitsu COBOL in an ASP page. I mean it's truly revolutionary.

Language is a funny thing: It's a matter of taste. Language is almost a religious thing, and it's a lifestyle choice for programmers.

In the evolution of languages and frameworks, we always seemed to end up marrying a programming language to a particular API and a particular form of programming. VB was about rapid application development and forms, MFC (Microsoft Foundation Classes) was about sub-classing, and ASP was about putting stuff in web pages. In each case, your choice of programming model always dictated your choice of programming language and your choice of available APIs. It added to your workload the burden of learning new languages and APIs every time you switched frameworks. We have really tried to unify all of that. We provide one API, one supporting visual design tool, and we give you the flexibility to choose whichever language works for you.

One of the wonderful things the .NET framework has done for scripting languages is to make them compiled. Look at ASP+. Now, you're actually running real compiled code in your pages; it's not late-bound, dispatch look-ups where you don't see a runtime error until the user hits the page. ASP+ developers can use the full power of Visual Basic .NET instead of VBScript. And for the first time, they have the ability to use Perl, Python, and other popular languages if they so choose.

I think the approach we've taken with the IL is interesting in that we give you options to control when compilation -- or translation, if you will -- of the IL to native code occurs. With managed C++, you can actually generate native code directly from source. Managed C++ can also generate IL, as can C# and VB. And when you install your code we give you the option to compile it at that point; to compile the IL to native at that point, so that when you run it there's no just-in-time compiler overhead. We also give you the option of running and compiling code dynamically, just-in-time compilation. And, of course, having an IL gives you many advantages, such as the ability to move to different CPU architectures and to introduce verifiability in type safety and then build the security system on top of that.

I think one of the key differences between our IL design and Java byte code specifically, is that we made the decision up-front to not have interpreters. Our code will always run native. So, even when you produce IL, you are never running an interpreter. We even have different styles of JITs. For the compact framework, we have the EconoJIT, as we call it, which is a very simple JIT [Editor's Note: .NET Compact is a subset of the .NET framework designed to be ported to other devices and platforms.]. For the desktop version we have a more full-fledged JIT, and we even have JITs that use the same back end as our C++ compiler. However, those take longer so you would only use them at install time.

Osborn:
How many people were involved in the development of C#?
Hejlsberg:
The language design team consisted of four people. The compiler team had another five developers.

In terms of the entire Visual Studio and .NET platform group, we are about a thousand-person division. That includes program management, developers, testers, all the build functions, the frameworks, the runtimes, the ASP programming models, and then all of the people like myself, the management overhead.

Osborn:
What are the planned release dates for C#, the .NET framework, and the next version of Visual Studio?
Goodhew:
Well, we've brought the technology preview to the 6,500 attendees here at PDC. We expect to go to beta sometime in the fall (2000), and then we'll release when ready. One of the really exciting things we've done is take a good solid look at how the Windows 2000 launch release went and the way we involved key customers in the joint development and the joint deployment process. In the case of .NET framework and Visual Studio .NET, we will again work with customers to determine when the final product is ready to release. We're going to let them tell us when the product is ready. And, because we've got real customers involved in the process, we should get a much better product in terms of quality. The downside of that is the process then becomes a little indeterminate. This is a fundamental change. We are looking to hit a quality bar for the release of the product rather than just pick an arbitrary date and say we'll ship.

COM is not a must for standardization of C# and a common language infrastructure. Not at all. C# has a class model that is completely rich, whereas COM is just another view of how applications can interoperate. But there's nothing in C# or the core common runtime that says there must be COM, GUIDS, HRESULTS, AddRefs, or Releases. There's none of that. The .NET common language runtime completely eliminates that. But it gives you great interoperability with COM, which I will continue forever to think is super important for the reason I gave earlier. But it's not a prerequisite at all.

As Anders said, COM interop and COM support is critically important to us and to existing Microsoft customers. I think we've done a great job supporting COM on the .NET platform. But people in the industry have been reading too much into our use of the words COM and DLL. They conclude that the .NET platform is for Windows platforms only, and that's absolutely incorrect.
And I think that just as COM interop is important to Microsoft and to customers who are building solutions on Microsoft platforms, a standardization of C# and the common language infrastructure should allow for other implementations to add meaningful interop with any platform on which they choose to implement the language.

特别：以上文字涉及其他人的隐私和个人权利，如非被授权或经本人同意，任何网站或期刊请不要刊登、转载、转贴或已其他形式进行传播。以上所有文字只用于内部交流，不作任何新闻发表和商业用途。特此声明。