delphi之父 Anders Hejlsberg 的演讲(经典)

b>主持: 女士们，先生们，请欢迎最卓越的工程师：Anders Hejlsberg
(掌声)
Anders Hejlsberg:
谢谢。在开始今天的题目之前，我想先带大家回顾一下历史，从早期的计算到现在我们到了何种状态。我相信如果我们回头看一下计算机与分布式应用，你将看到每十年左右都会有变化。回到70年代，你知道，几乎所有的计算都运行在一台服务器上，她被放在后面的房间里，然后前台有傻瓜中断以合适的协议与它相连。
到了80年代，你会发现，应用的重心开始转移到客户端，文件服务器只是提供文件的分类存储。很多计算不是在服务器上实现的，而是在客户端实现的。
现在到了90年代，互联网的时代，应用的重心由转到了服务器端。互联网就好像是一个旧的IBM的3270终端，只是你会联结多个网站而不是一个放在房间后面的服务器。当然，HTML是一个更丰富的协议。
现在，人们开始谈论也许现在该转向另一个时代，趋向于客户端，在这一个点到点的计算时代。但事实上，我们相信现在是一个最终走向平衡的时代。我们将同时计算放在服务器端，也会放在客户端。我们将依然会做很多是在服务器端，先我们现在一样，同时我们也会利用技术的革命，比如手写体识别技术与语音识别技术，将应用放在客户端。
换句话讲，我们将拥有两种最佳的计算世界。这也是一个理由，我们相信会有一种更丰富的协议，一个构架，允许我们拥有两端智能的应用，那就是XML与 Web 服务。
关于XML
Web服务的一件事，当然，是一个自然的转移，让我们来看.NET：是一个在何时何地都可以访问的信息。但不管你问谁，它都是一组分布式的计算，一个分布式的应用，一组连接的应用。并且我们相信，XML与web服务将成为这些分布式应用的连接架构。当然，随着这自然变化，将带来一组工具的变化。
让我们来看，我们现在在哪里。是一些有历史意义的一些工具，从几十年前的文本模式的应用，到图形界面的应用，到现在领导互联网的一些工具。还有今天我们要谈到的有创新意义的一组工具.NET
框架与Visual studio.NET.
当我们发布Visual studio
6.0，那已经是三年半，四年以前，我们知道我们创建了一组极好的工具，可以使客户创建很好的应用，但我们知道我们可以在开发工具方面可以做得更好。
例如，我们意识到创建分布式的应用于连接这是应用非常复杂。如果让我们来看那些创建分布式应用与连接分布式应用的技术，而且我们至今还再用者的技术：DCOM,
Corba, IIOP, RMI. 我们知道那是一组字符串，但非常难开发与维护。我们知道我们可以做得更好。
我们也知道我们有很多很难的编程模型，与很多很难的编程语言难以集成。你知道，我们有Visual Basic与C++,ASP等等。我们知道我们的面向对象系统，COM,
在许多方面不够丰富来创建今天人们想创建的应用。COM不能够支持一些关键的面向对象的的概念，例如继承与多态，同时我们知道，COM太复杂了。COM是一个非常低层的二进制标准。你不得不自己做很多整理工作，例如担心结果，与增加refs,
release, GUIDs等等。
同时，我们与W3C联盟一起在XML的标准之上的工作中，看到一些互联网上跳跃式的发展，并知道将有一组新的应用将在此基础上建立。
但看看所有眼前的事实，我们不可能只是通过修改一下COM，DNA就能有革命性的创新。我们知道，我们需要创建一个新的平台。
这个平台就是.NET 框架。她是一个内置支持XML
web服务，统一我们所有编程模型，并能大大简化开发，提供了一个强大的，持久的，安全的执行环境，支持多种编程语言，并最终允许我们将原有投入精力写的代码得以集成。
现在，在我结识如何构建这一框架，以及详细介绍之前，来让我给你们看一下这个框架的示意图。
她开始于底层的操作系统，在操作系统之上，我们叫他“通用运行时”(common language runtime)
.这是一组组件，在平常的工作中看不到。她提供了所有核心的服务比如类库加载，编辑，意外处理，垃圾收集，安全性，等等，等等。所以它是一个黑盒子，让你可以在.NET世界里执行代码。
在通用运行时上面是一组类库，开始于基类库，它提供一组最通用的功能比如：文件输入输出，串处理，例如访问TCPIP等等。
在这之上，我们有ADO.NET，这是下一代的支持XML web 服务的ADO版本，我们的XML堆(stack)开始于一个低端的XML parser,
通过一个与W3C DOM兼容的XML 文件模型工作，并且也支持X-PATH于一组其它的XML标准。
在类库上面有两个框架。我们有服务器端的框架和客户端的框架。在服务器端，我们有ASP.NET, 我们的应用服务器，Web forms, 那是一个在ASP.NET里写表单的编程模型。她支持Web服务与移动互联网工具集，并且允许你为移动设备创建UI.
在客户端，我们有Windows Forms, 你可以把它当作把Visual Basic 表单与MFC放在一起的一种革新。你可以在Windows表单世界里，将最优化的两种特征兼顾。
再往上，我们可以看到叫做通用语言规范，它是一个标准，是所有的语言必须支持一个最小的功能集合，以便于所有语言可以运行在.NET通用运行时上。
并且我们提供了支持这种通用语言规范的四种语言：Visual Basic, C++, C# 与 J#.
但实业界的合作伙伴正在创建，你知道，到目前，我们已经有超过20种的语言支持通用运行时。

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

最终，当然，支持所有功能特性的是Visual studio.NET.
那么现在来看一下我们如何创建这一开发工具以及何种动力产生了这一框架。
谈到这里，让我们看一下我们为什么会有这么多的复杂的编程模型，纠其原因，其实都是一个历史过程，让我们来看我们如何编写Windows应用的。让我们回溯到10或甚至15年，写一个Windows应用，实际上只有一种方式来做。你会启动你的C便一起。你可能会：include
Windows. H. 你会翻开书，你会写Win cross与Windows 消息处理器。那些都非常复杂，并且没有工作效率。
然后，随着时间的推移，我们看到一些不同的编程模型。例如，Visual Basic
开创了一种快速开发方式，利用表单来设计程序，用这种方式，你知道，可以从一个工具面版上拖放“控制”放到一个表单中。然后你可以写一些时间处理器，使得代码都放在后台。
但C++就走了另外一条道路，利用MSC与ATL. 这里我们用一些不同的范例，如Sub classing.
当然，这样使你更轻大，并可以更好的表示，但他当然没有Visual Basic使用起来容易。
最近，随着互联网的发展，我们看到一整套新的编程模式的崛起，围绕在服务器端执行的HTML页面，与ASP编程模型。
然后你一定会想象，我们会继续下去，并且将有一种新的编程模型来写Web服务，与一种新的编程模型来写移动UI,
但是有一个不幸的事实。一个是你不经意间选择的编程模型会决定你选择编程语言。
例如，如果你想到MSC, 如果你是一个VB的编程人员，并且有一些MSC或ATL你想使用。她不只是一种简单的可能。反之，VB表单只能从Visual
Basic中得到。如果你想写一些HTML 页后面的代码，你只能用描述语言。
另外一个问题时，每种不同的编程模型，都对通用的问题有着不一样的解决方案。例如，
在不同的编程模型中，对于文件的输入输出，就有不同的处理方式。
现在，.NET 框架所作的事情，就是统一这些编程模型，提供一种一致API，不管你所用的语言，也不管你用了何种编程模型。
现在，我来讲以下.NET框架的另外一个目标是大大简化编程。在这里，.NET框架提供了很多方式，我不能够例数所有的方式，但我放了一些重要的在这张幻灯片中。
首先，我认为.NET框架所作的是提高了抽象层。如果你今天来看COM,
他是一个非常低级的二进制标准。我不知道你们是否作过C++与COM的编程，它是可怕的。你知道，你不得不处理H结果与GUIDs与增加refs与release,
直是到处都有丰富的机会来藏有bugs. 正向我所说的，COM在今天来看，并不足够丰富。她不支持核心的面向对象的概念。
.NET框架是你远离这些麻烦，它只是完全自动的去处理这些事情，让你可以从杂物中解脱出来，并集中思想到运算规则上。
另外一个问题是，.NET框架是如何统一编程系统的。在.NET框架中，每件事都可以看作是一个对象。甚至一个INT也可以看作是一个对象，或一个float.
没有变量；所有都是对象。所以就没有在Visual basic中在变量与对象中的二分法。将会有一个字符串绑定在整个平台，并且所有字符数据都是Uni-Code.
最后，这一平台提供了面向对象的编程或软件组件的编程方式。例如属性，方法，事件都是.NET框架中的第一级的结构。所以他不象如果你用C++来写一个Active X
控件，你不得不用一些宏来定义属性，以及事件等等，这些所有的支持都内置在.NET框架的开发语言中。
另外一点是：组织这些API的方式。过去人们用Win32API, 实际上是一个巨大的扁平的API.
那里根本没有任何组织。我们对这些30000个入口最好的办法就是按照字母排序，但请看在.NET框架中，所有一切都被逻辑化的组织明且命名。所以如果你看到一些关于输入输出的东西，就可以去看System
IO，然后你会找到叫”文件“的类库，所以它可以很容易的带你到你想要的地方。
另外一种方法来看是否我们简化了编程，就看一下我们以前如何写代码，现在又是如何写代码。这里是一些我喜欢的，一些例子，调用Windows
API来生成Windows. 你首先调用Creat.windows.ex然后把它送给至少12个参数。然后你需要更新一下窗口，来显示一下屏幕上的状态。
对比一下你所做的，把它放在.NET框架中。你生成一个表单。你用了Caption,然后你显示出来。
现在，你所做的许多都是一个VB程序员会做的事。“我们已经这样做了好几年. 到底有什么新鲜花样？“
我认为有几个新的地方，对比今天的VB编程方式。首先，今天的VB,为了让你容易得拿到APIs. 一些人不得不事先打包API把它变成COM APIs.
这也是为什么VB有些滞后。通常，当新的API出来，他们首先是由C的编程方式生成，然后VB 工作人员再把它打包成容易使用的API.
第二个问题，当然，一旦这些APIs被打包，你就不能真的与其他人说相同的语言，因为别人在一个低级别的API上并且一些文档不能用，一些东西不能够打包，因此你不得不丢到这些，或者那些，你喜欢的功能。
但我认为也许最重要的事我们-微软将如何编辑这些API.
他不会是一些低级别的官样文章。我们将把抽象层向上移，使新的API容易使用，程序员只需要关注于所要做的事情，也就是说不需要完全懂得所有的API才能够写最简单的应用程序。
我认为另外一个重要的事情就是.NET框架提供了一个功能强大的持久地执行环境。在.NET框架中，所有对象都是自动地执行垃圾收集与内存管理。
现在，事实上，在COM与.NET框架中，内存管理是完全不同的。在COM中也有自动的内存管理。但它是用一个叫做reference
counting的方法来处理，用这种方法来计数代表每个对象的reference的数量。如果没有遇到一个难题，到目前为止他工作的非常好。这是一个循环reference的问题。如果你有两个对象，每个都有一个reference指向对方，
而对于内存管理来讲，这些对象就始终是活的，然而没有其他reference他们并且你生成了一些内存岛，永远不会被收集。
.NET框架使用不同的技术来实现内存管理，叫标记()与清扫（Sweep）, 我不打算将太多细节他是如何工作，但最根本的他完全解决了reference
counting的问题。
另外一个提供强大执行环境的关键是意外处理。你已经熟悉了在VB中的“on error go
to”,它确实是提供了一些少量的结构化的错误处理。但仍然有些错误处理会更复杂，当一个错误出现在.NET
框架中，每个意外处理都会带有一个错误描述信息。你可以获得一个错误信息堆栈，并能精确知道什么出了错，并错在哪里。
在.NET框架中也许最重要的错误处理就是强制性的处理。如果你们看一下，传统的Windows API是如何工作的，所有语言是如何工作的，比如C,
C++等等，错误处理总是一个随意的事情。一个API也许可以返回一个错误代码或一个结果代码来说明这个API是工作还是不工作，但除非你会写一些代码来检测这些错的结果，你知道，否则任何事都不会发生。事实上，你的应用将会处于混沌状态，然后三个或四个API调用会启动，因为一个空指针或者你没有任何想法如何结束。
不只是意外处理。如果一个意外处理发生了，如果你的应用没有处理这个意外，然后你的应用就会关掉。他们会有序的关掉，并提醒你，你有丰富的时间去解开现有的状况等等，但我们最终不会陷入混沌，这样就会减少很多bugs.
类型安全是另外一个带来强大的原因。在.NET框架中不会有不安全的类型表。你不会产生某一个类型的指针指向另外一个类型，执行引擎会简单的拒绝她。不可能有位初始化的变量。你不可能索引，超出他的边界的数列等等。
一个关键的功能就是我们的零冲击安装功能。这时，事实上是我喜欢的功能之一。在.NET框架中，绝对不需要为了运行而注册的说法。你可以生成一个子目录，把应用拖到哪里，运行他，当运行结束，你就可以删除目录，不管你在什么机器上运行，都不会留下痕迹。
（欢呼，鼓掌）
这不是说你的应用不能共享信息。我们也支持另外一个模式，当我们安装进一个global assembly cache, 正如我们所说的，然后应用可以共享类库。
另外一个关键，我认为，在.NET框架中的革新是Side-by
side执行，这允许你可以在相同应用利在你的机器上运行与安装不同的版本代码。你可以有应用版本1.0，应用版本2.0
并且你可以并行运行他们。你甚至可以在相同的进程中运行从这些应用中出来的对象。
这也就意味着，你不再有哪些DLL hell问题，当你安装一个新版本的DLL, 你的应用在从前的时候会因为它而终止。
而代替它的是，在.NET框架中，你的应用将继续会根据版本而运行。所以，正像我所说的，你可以有一些数据库支持的库版本1.0，1.1 与2.0,
各种不同的应用可以继续使用不同的版本，因此默认情况下当你在机器中安装了新的的应用，你的应用也不会中断。
所以.NET框架是一个多语言的平台。从最初我们设计这一平台，我们就知道我们想要在这一平台上支持多种语言。对我们最重要的不是让人们只学一种语言，而是让他们可以利用以前他们已经知道的编程语言经验，并且已经编写的代码。
另外一个关键，.NET框架中所支持的语言都是一流的。我提到过一些早期的事实，API不能用于今天的VB如果他没有第一时间打包成一个COM对象。这在.NET框架张绝对不成问题。任何API发布到.NET框架中，都可以立即被VB或任何在这一平台上实现的编程语言来使用。
事实上，我们的集成能力已经远超过我们现在所看到的。例如，你可以用一种语言写一个类，从另外一个语言中继承，并且从第三种语言例示。这种集成能力可以如此之深。
当然，它也意味着你可以高度整合这些开发工具。你实际上只需要一个集成的开发环境，一个Debugger来使用这些多语言。
现在我们提供了5种语言：VB, C++, C#, J# 与Java Script 或者J script.
但是在业界，学术界，有很多其他语言被开发，以及正在开发，包括一些语言如：Cobo, Fortran 与APL.
现在，我曾经提到.NET框架允许你高度的集成存在的代码。因为你的所有语言都创建在这一公共的基础之上，叫做.NET框架的公共基础之上。你可以看到.NET框架在语言之间的集成能力是比我们以往所见的任何架构都强。
其实在性能上，能力上，在这一平台上写一个Visual Basic或C#或J script 或任何其他这一平台支持的语言都没有太多差别。
但是在现实世界里，只是语言的互操作是不够的。当然，有很多代码不是为.NET框架写的，我们也希望能够完全的利用上，所以.NET框架提供了在DLL之间的互操作性，在DLL中的代码，通过一个叫做
P 调用,
来实现DLL与COM或OLE自动对象的互操作。事实上，任何你在.NET框架中写的代码都可以在框架之外看作是一个COM对象，反之亦然，任何COM对象，可以自动输入到.NET
框架中，被看作是一个类放在哪里。
然后最终，我们通过XML和SOAP，我们提供了可能是最好的，最灵活的方式来在异类的系统中集成。
所以有很多互操作简单的内置在里面，因为我们相信摩尔定律――至少在我的思想中，摩尔定律已经离我们很远。我们会如何以用Gigaherz的CPU与512　megabytes的内存？回溯以前６４K或640k的内存，你也许每次都会感到困难，也许要花六个月来写一个程序来利用所有的机器容量。你已经远离那个时代。但今天，你不会与要这样的问题，我的意思是，客户期望越来越多的容量，好像用不完的容量，我们不得不找到方法来利用以前已经写过的代码。
所以，我转移一下话题，来谈一些web service.　关于web service的革命，我认为我们正在当中，Visual
studio.NET与.NET框架，会将起重要作用。
在我们做演示之前，我想讲几张幻灯片来解释一下我所认为的web
service.　实际上简单得像可以认为它是一个花生壳，如果HTML是使人与机器可以交互沟通的话，XML与SOAP就是关于机器与机器的沟通机制。更精确些，它是一个相同的结构。
现在我来讲一下，传统的分布式计算，是如何利用DCOM, Corba, RMI等等来连接应用。　那什么是web
service来提供的更好的技术来写这些分布式的应用。
我认为有三个关键的因素。首先，XML web service充分利用了Web.
他们有着与创建HTML应用相同的架构。所有在网络上传递的一切都是通过HTTP协议。所有都一样。唯一改变的就是web service 代替了传递HTML,
你在HTTP基础上传递XML.
当然，这样就给我们很好的机会可以利用以前的web 应用，使原来的web 应用变成web service 也许只需要简单的增加几行代码，或一页代码在网站上。
第二件事情是，web
service可以使你真的可以在异构系统集成。任何种类的应用结构都必须支持的异构系统环境的集成。你不需要要求应用的两端都运行在相同的OS上。你甚至于不需要应用的两端都用相同的中间件。有了web
service,　你的应用的一端可能是在.NET框架上，应用的另一端可能是运行在Apache server上，运行着perl
script，但输出XML的数据格式。
最后一件事，我认为web service允许你创建真正的可扩展的应用。再次，让我们看一下传统的分布式应用技术。他们都用了所谓远程调用的技术如：DCOM,
Corba等等，他们真的使得这个世界看起来像是面向对象。她正好是一些对象运行在这台机器上，一些对象运行在另外一台机器上。但是这个架构只有在内部处理通讯，在一台机器上，或在一个本地的内部网络中，它可以执行得很好。但当你开始扩展你的应用时，比如你的客户端在旧金山，而你的服务器在纽约，你就会出问题。因为在这种旧的技术中，它基本上是，试图隐藏一个事实，你的应用不能够足够分布，当分布的距离分布到无限的网络上时，就会出问题。当你提出一个调用，但需要等很久，你不得不持续保持呼叫状态，但这真者的会伤害到可靠性，因为你不可能fail
over.
而且你也不能做一些饶舌的沟通当你在调用一个对象时，对方回话后然后离开。“噢，谢谢”“噢，别客气”等等。当你在一台机器上这所有一切都会很好，，但是当你要对东海岸对话时，你真的需要了解对方的状况时，光速就会出现问题,。
现在，对比XML web
service,　有很好的证据存在着，它可以扩展到任何你以前达不到的地方。因为我们已经今天在HTML上看到了很好的扩展。正如我所说的，我们改变的只是传递的东西，从前是HTML,
现在是XML. 但所有的架构都一样。我们知道如何扩展，我们知道它可以扩展。
所以什么是web
service的基础？当然，它起源于唯一的有互联网提供的通讯，在这一通讯机制上，我们存储通用的由XML提供的数据结构，XML可用来传递任何数据。
现在，在XML之上我们有很多变化了的协议，我们有XSD来描述类型。我们有SOPA来描述交互或web service的调用。我们有WSDL, web
service 描述语言来描述web service. 我们有发现协议。
在这之上，我们有web service的黄页，注册的服务叫做UDDI.
现在，最关键的就是我们有简单的开放的标准，并且有广泛的业界支持。这些都不是微软制定的标准，这些标准是我们与业界合作伙伴以及与标准组织如W3C合作创建的
所以一个web service 是如何工作的？让我来举例，假设我是一个web service的消费者，我想使用web service.
首先，我会找到我想要得web service. 我不得不在web service
世界里去寻找。我可以有几种方法。我或者到UDDI去找，或者到特定的业务区域里去寻找。这些特定的区域支持特定的schema，数据按各种方法排序。但通常，我会的得到一个连接，一个web
service描述语言文件，告诉我关于我所找到的web service.
或者我也可以直接找到我要找的web service的组织，说我已经知道他们的网址，并且获得了disco文档或一个发现文档，它基本上是一个目录，所有的web
service都在这一地址上。
另外一个状况是，我最终找到一个WSDL文件或者一个Web
service描述语言，或者我找到了一个连接，这个连接可以让我找到WSDL文件。通过这个文件，我可以知道如何与Web
service通讯，最后一步就是利用基于XML的SOAP协议来与这个服务对话。
现在，在幻灯片最上面的三个步骤是设计时步骤，如果你愿意，没有任何步骤在运行时发生。只有最后一步是在运行发生。但所有以上三步都完全支持Visual studio.
我可以从Visual studio中找到UDDI的注册处。我可以获得Discovery(发现)文件或者一个WSDL文件，并且Visual