编程语言的发展及未来.docx

编程语言的发展及未来.docx

《编程语言的发展及未来.docx》由会员分享，可在线阅读，更多相关《编程语言的发展及未来.docx（24页珍藏版）》请在冰豆网上搜索。

编程语言的发展及未来

编程语言的发展趋势及未来方向

大家好，我是AndersHejlsberg，现在是微软的TechnicalFellow，担任C#编程语言的首席架构师，也参与并领导.NETFramework以及各种语言的开发。

我现在打算谈一下……实际上是我脑海中一些影响未来5到10年编程语言设计的内容。

比如C#或VB该怎么走，F#该怎么办，这次演讲主要就是讨论这些影响我们的东西。

虽然主要内容是谈论未来的，但是我还是想先回顾一下历史。

你们有些人可能对这个产品有印象，这是我大约27年前的工作内容，TurboPascal，这也是我进入这个领域的起点。

我先在拿出这个东西是想展示当年写程序的情况，然后可以讨论目前究竟的发展到哪儿了。

事实上，我现在的机器里正好有TURBO.COM文件，大约39K，嘿，现在还可以运行。

我们现在来试着写一点程序。

先来创建的程序叫做Hello.pas……（开始写代码）……一个Pascal小程序写好了，我们来运行一下……（出现编译错误）啊噢，有地方我写错了……这个特性在当年是个创新，它会自动打开编辑器，直接把我们带去出错的地方。

嗯，我们现在来纠正语法错误，把双引号改成单引号。

再运行一下，现在成功了，（观众掌声）呵呵，谢谢，谢谢。

事实上，在27年后这个程序还能在这台机器上运行还真是挺神奇的。

现在，我们来看一下，从那时算起硬件已经发展了……嗯，我那时写Pascal的机器是Z-80，拥有48K内存。

从那时算起，我现在这台机器已经有大约10万倍的外部存储容量，1万倍的内存大小，CPU速度也有大约1000倍的提高。

但是如果你关注一下目前的软件……过去27年里编程语言到底进步了多少？

呵呵，有趣的是如果你仔细观察这些代码，会发现C#还比TurboPascal的版本多一行。

这也给我们带来了一些值得关注的东西。

首先，编程语言的发展非常缓慢。

期间当然出现了一些东西，例如面向对象等等，但是远没有好上1000倍。

另一方面，你可能会想，那么这些努力都到哪里去了呢？

事实上这些努力没有体现在编程语言上，而是出现在框架及工具等方面了。

如果你关注如今我们使用的框架，它们的体积的确有1000倍的增长。

例如当年TurboPascal所带的框架大约有，比如说100个功能，而现在的.NETFramework里则有一万个类，十万个方法，的确有1000倍的增长。

与此类似，如果你观察现在的IDE，我们现在已经有了无数强大的功能，例如语法提示，重构，调试器，探测器等等，这方面的新东西有很多。

与此相比，编程语言的改进的确很不明显。

另一方面，如.NET，Java等框架的重要性提高了许多。

而编程语言往往都倾向于构建于现有的工具上，而不会从头写起。

现在出现的编程语言，例如F#，如果你关注Java领域那么还有Scala，Clojure等等，它们都是基于现有框架构建的。

现在已经有太多东西可以直接利用了，每次从头开始的代价实在太高。

还有件事，便是在过去5、60年的编程历史中，我们都不断地提高抽象级别，我们都在不断地让编程语言更有表现力，让我们可以用更少的代码完成更多的工作。

我们一开始先使用汇编，然后使用面向过程的语言，例如Pascal和C，然后便是面向对象语言，如C++，随后就进入了托管时代──受托管的执行环境，例如.NET，Java，它们的主要特性有自动的垃圾收集，类型安全等等。

我目前还没有看出这样的趋势有停止的迹象，因此我们还会看到抽象级别越来越高的语言，而语言的设计者则必须理解并预测下一个抽象级别是什么样子的。

我认为，现在影响力较大的趋势主要有3种。

首先，我们会越来越多地使用声明式的编程风格。

这里我主要会提到例如DSL（DomainSpecificLanguage，领域特定语言）以及函数式编程。

然后在过去的五年里，我发现对于动态语言的研究变得非常火热，其中对我们产生重大影响的无疑是动态语言所拥有的良好的元编程能力，还有一些非常有趣的东西，例如JavaScript引擎的发展。

然后便是并发编程，无论我们愿不愿意，多核的产生都在迫使我们不得不重视并发编程。

有一点值得一提，那便是随着语言的发展，原本的编程语言分类方式也要有所改变了。

以前我们经常说面向对象语言，动态语言或是函数式语言。

但是我们现在发现，这些边界变得越来越模糊，经常会互相学习各自的范式。

静态语言中出现了动态类型，动态语言里也出现了静态能力，而如今所有主要的编程语言都受到函数式语言的影响。

因此，一个越来越明显的趋势是“多范式程序设计语言”。

这里先从声明式（Declarative）编程谈起。

目前我们在编写软件时大量使用的是命令式（Imperative）编程语言，例如C#，Java或是C++等等。

这些语言的特征在于，写出的代码除了表现出“什么（What）”是你想做的事情之外，更多的代码则表现出实现的细节，也就是“如何（How）”完成工作。

这部分代码有时候多到掩盖了我们原来问题的解决方案。

比如，你会在代码里写for循环，if语句，a等于b，i加一等等，这体现出机器是如何处理数据。

首先，这种做法让代码变得冗余，而且它也很难让执行代码的基础设施更聪明地判断该如何去执行代码。

当你写出这样的命令是代码，然后把编译后的中间语言交给虚拟机去执行，此时虚拟机并没有多少空间可以影响代码的执行方式，它只能根据指令一条一条老老实实地去执行。

例如，我们现在想要并行地执行程序就很困难了，因为更高层次的一些信息已经丢失了。

这样，我们只能在代码里给出“How”，而不能体现出“What”的信息。

有多种方式可以将“What”转化为更为“声明式”的编程风格，我们只要能够在代码中体现出更多“What”，而不是“How”的信息，这样执行环境便可以更加聪明地去适应当前的执行要求。

例如，它可以决定投入多少CPU进行计算，你的当前硬件是什么样的，等等。

我之前提到过，现在有两种比较重要的成果，一是DSL（DomainSpecificLanguage，领域特定语言），另一个则是函数式编程。

其实DSL不是什么新鲜的玩意儿，我们平时一直在用类似的东西，比如，SQL，CSS，正则表达式，有的可能更加专注于一个方面，例如Mathematica，LOGO等等。

这些语言的目标都是特定的领域，与之相对的则是GPPL（GeneralPurposeProgrammingLanguage，通用目的编程语言）。

对于DSL而言其实并没有一个明确的定义，在这里我也不打算为它下个定义，例如UML甚至根本没有特定的语法。

不过我这里会谈一些我觉得比较重要的东西。

MartinFowler提出DSL应该分为外部DSL及内部DSL两种，我认为这种划分方式还是比较有意义的。

外部DSL是自我包含的语言，它们有自己特定语法、解析器和词法分析器等等，它往往是一种小型的编程语言，甚至不会像GPPL那样需要源文件。

与之相对的则是内部DSL。

内部DSL其实更像是种别称，它代表一类特别API及使用模式。

这里我会给你们看一些示例。

这些是我们平时会遇到的一些外部DSL，如这张幻灯片上表现的XSLT，SQL或是Unix脚本。

外部DSL的特点是，你在构建这种DSL时，其实扮演的是编程语言设计者的角色，这个工作并不会交给普通人去做。

外部DSL一般会直接针对特定的领域设计，而不考虑其他东西。

JamesGosling曾经说过这样的话，每个配置文件最终都会变成一门编程语言。

你一开始可能只会用它表示一点点东西，然后慢慢你便会想要一些规则，而这些规则则变成了表达式，可能你还会定义变量，进行条件判断等等。

而最终它就变成了一种奇怪的编程语言，这样的情况屡见不鲜。

事实上，现在有一些公司也在关注DSL的开发。

例如以前在微软工作的CharlesSimonyi提出了IntentionalProgramming的概念，还有一个叫做JetBrains的公司提供一个叫做MPS（MetaProgrammingSystem）的产品。

最近微软也提出了自己的Oslo项目，而在Eclipse世界里也有个叫做Xtext的东西，所以其实在这方面现在也有不少人在尝试。

我在观察外部DSL时，往往会关注它的语法到底提供了多少空间，例如一种XML的方言，利用XML方言的好处在于有不少现成的工具可用，这样可以更快地定义自己的语法。

而内部DSL，正像我之前说的那样，它其实只是一系列特别的API及使用模式的别称。

这里则是一些LINQ查询语句，RubyonRails以及jQuery代码。

内部DSL的特点是，它其实只是一系列API，但是你可以“假装”它们一种DSL。

内部DSL往往会利用一些“流畅化”的技巧，例如像这里的LINQ或jQuery那样把一些方法通过“点”连接起来。

有些则利用了元编程的方式，如这里的RubyonRails就涉及到了一些元编程。

这种DSL可以访问语言中的代码或变量，以及利用如代码补全，重构等母语言的所有特性。

现在我会花几分钟时间演示一下我所创建的DSL，也就是LINQ。

我相信你们也已经用过不少LINQ了，不过这里我还是快速的展示一下我所表达的更为“声明式”的编程方式。

publicclassProduct

{

publicintProductID{get;set;}

publicstringProductName{get;set;}

publicstringCategoryName{get;set;}

publicintUnitPrice{get;set;}

publicstaticListGetProducts（）{/*...*/}

}

publicpartialclass_Default:

System.Web.UI.Page

{

protectedvoidPage_Load（objectsender,EventArgse）

{

Listproducts=Product.GetProducts（）;

Listresult=newList（）;

foreach（Productpinproducts）

{

if（p.UnitPrice>20）result.Add（p）;

}

GridView1.DataSource=result;

GridView1.DataBind（）;

}

}这里有许多Product对象，那么现在我要筛选出所有单价大于20的那些，再把他们显示在一个GridView中。

传统的做法就是这样，我先得到所有的Product对象，然后foreach遍历每个对象，再判断每个对象的单价，最终把数据绑定到GridView里。

运行这个程序……（打开页面）这就是就能得到结果。

好，那么现在我要做一些稍微复杂的事情。

可能我不是要展示单价超过20的Product对象，而是要查看每个分类中究竟有多少个单价超过20的对象，然后根据数量进行排序。

如果不用DSL完成这个工作，那么我可能会先定义一个对象来表示结果：

classGrouping

{

publicstringCategoryName{get;set;}

publicintProductCount{get;set;}

}这是个表示分组的对象，用于保存分类的名称和产品数量。

然后我们就会写一些十分丑陋的代码：

Dictionarygroups=newDictionary（）;

foreach（Productpinproducts）

{

if（p.UnitPrice>=20）

{

if（!

groups.ContainsKey（p.CategoryName））

{

Groupingr=newGrouping（）;

r.CategoryName=p.CategoryName;

r.ProductCount=0;

groups[p.CategoryName]=r;

}

groups[p.CategoryName].ProductCount++;

}

}

Listresult=newList（groups.Values）;

result.Sort（delegate（Groupingx,Groupingy）

{

return

x.ProductCount>y.ProductCount?

-1:

x.ProductCount

1:

0;

}）;我先创建一个新的字典，用于保存分类名称到分组的对应关系。

然后我遍历每个Product对象，对于每个单价大于20的对象，如果字典中还没有保存对应的分组则创建一个，然后将数量加一。

然后为了排序，我调用Sort方法，于是我要提供一个委托作为排序方法，然后blablablabla……执行之后……（打开页面）我自然可以得到想要的结果。

但是，首先这些代码写起来需要花费一些时间，很显然。

然后仔细观察，你会发现这写代码几乎都是在表示“How”，而“What”基本已经丢失了。

假设我离开了，现在新来了一个程序员要维护这段代码，他会需要一点时间才能完整理解这段代码，因为他无法直接看清代码的目标。

不过如果这里我们使用DSL，也就是LINQ，就像这样：

varresult=products

.Where（p=>p.UnitPrice>=20）

.GroupBy（p=>p.CategoryName）

.OrderByDescending（g=>g.Count（））

.Select（g=>new{CategoryName=g.Key,ProductCount=g.Count（）}）;products……先调用Where……blablabla……再GroupBy等等。

由于我们这里可以使用DSL来表示高阶的术语，用以体现我们想做的事情。

于是这段代码则更加关注于“What”而不是“How”。

我这里不会明确地指示我想要过滤的方式，我也不会明确地说我要建立字典和分类，这样基础结构就可以聪明地，或者说更加聪明地去确定具体的执行方式。

你可能比较容易想到我们可以并行地执行这段代码，因为我没有显式地指定做事方式，我只是表示出我的意图。

我们打开页面……（打开页面）很显然我们得到了相同的结果。

这里比较有趣的是，内部DSL是如何设计进C#语法中的，为此我们为C#3.0添加了一系列的特性，例如Lambda表达式，扩展方法，类型推断等等。

这些特性统一起来之后，我们就可以设计出更为丰富的API，组合之后便成为一种内部DSL，就像这里的LINQ查询语言。

除了使用API的形式之外，我们还可以这样做：

varresult=

frompinproducts

wherep.UnitPrice>=20

grouppbyp.CategoryNameintog

orderbyg.Count（）descending

selectnew{CategoryName=g.Key,ProductCount=g.Count（）};编译器会简单地将这种形式转化为前一种形式。

不过，这里我认为有意思的地方在于，你完全可以创建一门和领域编程语言完全无关的语法，然后等这种语法和API变得流行且丰富起来之后，再来创一种新的表现形式，就如这里的LINQ查询语法。

我颇为中意这种语言设计的交流方式。

关于声明式编程的还有一部分重要的内容，那便是函数式编程。

函数式编程已经有很长时间的历史了，当年LISP便是个函数式编程语言。

除了LISP以外我们还有其他许多函数式编程语言，如APL、Haskell、Scheme、ML等等。

关于函数式编程在学术界已经有过许多研究了，在大约5到10年前许多人开始吸收和整理这些研究内容，想要把它们融入更为通用的编程语言。

现在的编程语言，如C#、Python、Ruby、Scala等等，它们都受到了函数式编程语言的影响。

我想在这里先花几分钟时间简单介绍一下我眼中的函数式编程语言。

我发现很多人听说过函数式编程语言，但还不十分清楚它们和普通的命令式编程语言究竟有什么区别。

如今我们在使用命令式编程语言写程序时，我们经常会写这样的语句，嗨，x等于x加一，此时我们大量依赖的是状态，可变的状态，或者说变量，它们的值可以随程序运行而改变。

可变状态非常强大，但随之而来的便是叫做“副作用”的问题。

在使用可变状态时，你的程序则会包含副作用，比如你会写一个无需参数的void方法，然后它会根据你的调用次数或是在哪个线程上进行调用对程序产生影响，因为void方法会改变程序内部的状态，从而影响之后的运行效果。

而在函数式编程中则不会出现这个情况，因为所有的状态都是不可变的。

你可以声明一个状态，但是不能改变这个状态。

而且由于你无法改变它，所以在函数式编程中不需要变量。

事实上对函数式编程的讨论更像是数学、公式，而不像是程序语句。

如果你把x=x+1这句话交给一个程序员看，他会说“啊，你在增加x的值”，而如果你把它交给一个数学家看，他会说“嗯，我知道这不是true”。

然而，如果你给他看这条语言，他会说“啊，y等于x加一，就是把x+1的计算结果交给y，你是为这个计算指定了一个名字”。

这时候在思考时就是另一种方式了，这里y不是一个变量，它只是x+1的名称，它不会改变，永远代表了x+1。

所以在函数式编程语言中，当你写了一个函数，接受一些参数，那么当你调用这个函数时，影响函数调用的只是你传进去的参数，而你得到的也只是计算结果。

在一个纯函数式编程语言中，函数在计算时不会对进行一些神奇的改变，它只会使用你给它的参数，然后返回结果。

在函数式编程语言中，一个void方法是没有意义的，它唯一的作用只是让你的CPU发热，而不能给你任何东西，也不会有副作用。

当然现在你可能会说，这个CPU发多少热也是一个副作用，好吧，不过我们现在先不讨论这个问题。

这里的关键在于，你解决问题的方法和以前大不一样了。

我这里还是用代码来说明问题。

使用函数式语言写没有副作用的代码，就好比在Java或C#中使用final或是readonly的成员。

例如这里，我们有一个Point类，构造函数接受x和y，还有一个MoveBy方法，可以把一个点移动一些位置。

在传统的命令式编程中，我们会改变Point实例的状态，这么做在平时可能不会有什么问题。

但是，如果我把一个Point对象同时交给3个API使用，然后我修改了Point，那么如何才能告诉它们状态改变了呢？

可能我们可以使用事件，blablabla，如果我们没有事件，那么就会出现那些不愉快的副作用了。

那么使用函数式编程的形式写代码，你的Point类还是可以包含状态，例如x和y，不过它们是readonly的，一旦初始化以后就不能改变了。

MoveBy方法不能改变Point对象，它只能创建一个新的Point对象并返回出来。

这就是一个创建新Point对象的函数，不是吗？

这样就可以让调用者来决定是使用新的还是旧的Point对象，但这里不会有产生副作用的情况出现。

在函数式编程里自然不会只有Point对象，例如我们会有集合，如Dictionary，Map，List等等，它们都是不可变的。

在函数式编程中，当我们向一个List里添加元素时，我们会得到一个新的List，它包含了新增的元素，但之前的List依然存在。

所以这些数据结构的实现方式是有根本性区别的，它们的内部结构会设法让这类操作变的尽可能高效。

在函数式编程中访问状态是十分安全的，因为状态不会改变，我可以把一个Point或List对象交给任意多的地方去访问，完全不用担心副作用。

函数式编程的十分容易并行，因为我在运行时不会修改状态，因此无论多少线程在运行时都可以观察到正确的状态。

两个函数完全无关，因此它们是并行还是顺序地执行便没有什么区别了。

我们还可以有延迟计算，可以进行Memorization，这些都是函数式编程中十分有趣的方面。

你可能会说，那么我们为什么不都用这种方法来写程序呢？

嗯，最终，就像我之前说的那样，我们不能只让CPU发热，我们必须要把计算结果表现出来。

那么我们在屏幕上打印内容时，或者把数据写入文件或是Socket时，其实就产生了副作用。

因此真实世界中的函数式编程，往往都是把纯粹的部分进行隔离，或是进行更细致的控制。

事实上也不会有真正纯粹的函数式编程语言，它们都会带来一定的副作用或是命令式编程的能力。

但是，它们默认是函数式的，例如在函数式编程语言中，所有东西默认都是不可变的，你必须做些额外的事情才能使用可变状态或是产生危险的副作用。

此时你的编程观念便会有所不同了。

我们在自己的环境中开发出了这样一个函数式编程语言，F#，已经包含在VS2010中了。

F#诞生于微软剑桥研究院，由DonSyme提出，他在F#上已经工作了5到10年了。

F#使用了另一个函数式编程语言OCaml的常见核心部分，因此它是一个强类型语言，并支持一些如模式匹配，类型推断等现代函数式编程语言的特性。

在此之上，F#又增加了异步工作流，度量单位等较为前沿的语言功能。

而F#最为重要的一点可能是，在我看来，它是第一个和工业级的框架和工具集，如.NET和VisualStudio，有深入集成的函数式编程语言。

F#允许你使用整个.NET框架，它和C#也有类似的执行期特征，例如强类型，而且都会生成高效的代码等等。

我想，现在应该是展示一些F#代码的时候了。

首先我想先从F#中我最喜欢的特性讲起，这是个F#命令行……（打开命令行窗口以及一个F#源文件）……F#包含了一个交互式的命令行，这允许你直接输入代码并执行。

例如输入5……x等于5……然后x……显示出x的值是5。

然后让sqrx等于x乘以x，于是我这里定义了一个简单的函数，名为sqr。

于是我们就可以计算sqr5等于25，sqr10等于100。

F#的使用方式十分动态，但事实上它是一个强类型的编程语言。

我们再来看看这里。

这里我定义了一个计算平方和的函数sumSquares，它会遍历每个列表中每个元素，平方后再把它们相加。

让我先用命令式的方式编写这个函数，再使用函数式的方式，这样你可以看出其中的区别。

letsumSquaresIl=

letmutableacc=0

forxinldo

acc<-acc+sqrx

acc这里先是命令式的代码，我们先创建一个累加器acc为0，然后遍历列表l，把平方加到acc中，然后最后我返回acc。

有几件事情值得注意，首先为了创建一个可变的状态，我必须显式地使用mutable进行声明，在默认情况下这是不可变的。

还有一点，这段代码里我没有提供任何的类型信息。

当我把鼠标停留在方法上时，就会显示sumSquaresI方法接受一个int序列作为参数并返回一个int。

你可能会想int是哪里来的，嗯，它是由类型推断而来的。

编译器从这里的0发现acc必须是一个int，于是它发现这里的加号表示两个int的相加，于是sqr函数返回的是个int，再接下来blablabla……最终它发现这里到处都是int。

如果我把这里修改为浮点数0.0，鼠标再停留一下，你就会发现这个函数接受和返回的类型都变成float了。

所以这里的类型推断功能十分强大，也十分方便