分享
 
 
 

C#揭密 (和C#首席设计师的对话)

王朝c#·作者佚名  2006-01-08
窄屏简体版  字體: |||超大  

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.

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

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有