程序设计离不开编程语言，但是编程语言在国内的大环境中似乎一直是个二等公民，许多人也认为，语言的讨论完全是不入流的，但其实编程语言与工具、框架或开发方法等一样，都对生产力有着重要的影响。

　　事实上，语言的发展历史比其他方面更为悠久，并且在过去十几年，甚至最近几年中都依然在不断的碰撞和演变。期间一些新的语言诞生了，而另一些在当时看来阳春白雪的语言和编程范式也重新获得了重视。

　　anders hejlsberg是微软的technical fellow，担任c#编程语言的首席架构师，也参与了.net framework、vb.net和f#等语言的设计与开发，《delphi与c#之父：技术理想架构开发传奇》一文详细介绍了anders hejlsberg在微软的编程传奇之路。

　　几个月前，anders在比利时techdays 2010及荷兰devdays 2010分别作了一场演讲，阐述了他眼中的编程语言的发展趋势及未来方向，本文便对他的观点进行了总结。

　　大约25~30年前，anders开发了著名的turbo pascal，这是一套集语言、编译器及开发工具于一体的产品，也是anders进入编程语言领域的起点。anders谈到，当年turbo pascal所用的z-80和如今的计算机已经不可同日而语。与那时相比，如今的机器已经有大约10万倍的外部存储容量，1万倍的内存大小，cpu速度也有大约1000倍的提高。但是，如果我们比较如今的java代码及当年的pascal代码，会发现它们的差别其实并不大。

　　anders认为编程语言的发展非常缓慢，期间当然出现了一些东西，例如面向对象等，但是远没有好上1000倍。事实上，近几十年来的努力主要体现在框架及工具等方面(如图1)。例如.net framework里有超过一万个类和十万个方法，与turbo pascal相比的确有了超过1000倍的增长。类似的，现在的ide包含了无数强大的功能，例如语法提示、重构、调试器等。与此相比，编程语言的改进的确很不明显。

　　在过去50~60年的编程历史中，编程语言的抽象级别不断提高，人们都在努力让编程语言更有表现力，这样就可以用更少的代码完成更多的工作。我们一开始使用汇编，然后使用面向过程的语言(如pascal和c)，然后是面向对象语言(如c++)，随后便进入了托管时代，语言运行于受托管的执行环境上(如c#和java)，它们的主要特性有自动垃圾收集、类型安全等。anders认为这样的趋势还会继续下去，还会有抽象级别越来越高的语言。另一方面，编程语言往往都倾向于构建于现有的工具上，而不会从头写起。现在出现的编程语言，例如f#、scala和clojure等，都是基于现有框架构建的，每次从头开始的代价实在太高。

　　在anders眼中，如今影响力较大的趋势主要有三个(如图2)，分别是声明式的编程风格(包括领域特定语言、函数式编程)、动态语言(最重要的方面是元编程能力)以及多核环境下的并发编程。此外随着语言的发展，原本常用的面向对象语言、动态语言或是函数式等边界也变得越来越模糊，例如各种主要的编程语言都受到函数式语言的影响。因此，多范式程序设计语言也是一个愈发明显的趋势。

　　声明式编程与dsl

　　目前常见的编程语言大都是命令式(imperative)的，例如c#、java或c++等。这些语言的特征在于，代码里不仅表现了“做什么(what)”，而更多表现出“如何(how)完成工作”这样的实现细节，例如for循环、i += 1等，甚至这部分细节会掩盖我们的最终目标。

　　在anders看来，命令式编程通常会让代码变得十分冗余，更重要的是由于它提供了过于具体的指令，这样执行代码的基础设施(如clr或jvm)没有太多发挥空间，只能老老实实地根据指令一步步地向目标前进。例如，并行执行程序会变得十分困难，因为像“执行目的”这样更高层次的信息已经丢失了。因此，编程语言的趋势之一，便是能让代码包含更多的“what”，而不是“how”，这样执行环境便可以更加聪明地去适应当前的执行要求。

　　关于声明式的编程风格，anders主要提出了两个方面，第一个方面是dsl(domain specific language，领域特定语言)。dsl不是什么新鲜的玩意儿，我们平时经常接触的sql、css、正则表达式等都属于dsl。有的dsl可能更加专注于一个方面，例如mathematica、logo等。这些语言的目标都是特定的领域，与之相对的则是gppl(general purpose programming language，通用目的编程语言)。

　　martin fowler将dsl分为外部dsl和内部dsl两种。外部dsl有自己的特定语法、解析器和词法分析器等，它们往往是一种小型的编程语言，甚至不会像gppl那样需要源文件。与之相对的则是内部dsl。内部dsl其实更像是种别称，它代表一类特别api及使用模式。

　　xslt、sql等都可以算作是外部dsl。外部dsl一般会直接针对特定的领域设计，而不考虑其他方面。james gosling曾经说过：每个配置文件最终都会变成一门编程语言。一开始你可能只会用它表示一点点东西，慢慢地你便会想要一些规则，而这些规则则变成了表达式，后来你可能还会定义变量，进行条件判断等，而最终它就变成了一种奇怪的编程语言。这样的情况屡见不鲜。现在有一些公司也在关注dsl的开发。

　　例如以前在微软工作的charles simonyi提出了intentional programming的概念，还有jetbrains公司提供了叫做mps(meta programming system)的产品。最近微软也提出了自己的oslo项目，而在eclipse世界里也有xtext，所以如今在这方面已经有不少尝试。由于外部dsl的独立性，在某些情况下也会出现特定的工具，辅助领域专家或是开发人员编写dsl代码。还有一些dsl会以xml方言的形式提出，利用xml方言的好处在于有不少现成的工具可用，这样可以更快地定义自己的语法。

　　内部dsl往往只代表一系列特别的api及使用模式，例如linq查询语句及ruby on rails中的active record声明代码等。内部dsl可以使用一系列api来“伪装”成一种dsl，利用一些流畅化的技巧，例如像jquery那样把一些方法通过“点”连接起来，而另一些也会利用元编程的方式。内部dsl还有一些优势，例如可以访问语言中的代码或变量，以及利用代码补全、重构等母语言的所有特性。

　　dsl的可读性往往很高。例如，要筛选出单价大于20的产品，并对所属种类进行分组，降序列出每组的分类名称及产品数量。如果是用命令式的编程方式，可能是这样的：

　　var groups = new dictionary(); foreach (product p in products) { if (p.unitprice >= 20) { if (!groups.containskey(p.categoryname)) { grouping g = new grouping(); g.name = p.categoryname; g.count = 0; groups[p.categoryname] = g; } groups[p.categoryname].productcount++; } } var result = new list(groups.values); result.sort(delegate(grouping x, grouping y) { return x.count > y.count ? -1 : x.count < y.count ? 1 : 0; });

　　显然这些代码编写起来需要一点时间，且很难直接看出它的真实目的，换言之，“what”几乎完全被“how”所代替了。这样，一个新的程序员必须花费一定时间才能理解这段代码的目的。但如果使用linq，代码便可以改写成：

　　var result = products where(p => p.unitprice >= 20) groupby(p => p.categoryname) orderbydescending(g => g.count()) select(g => new { name = g.key, count = g.count() });

　　这段代码更加关注的是“how”而不是“what”，它不会明确地给出过滤的操作方式，也没有涉及到创建字典这样的细节。这段代码还可以利用c# 3.0中内置的dsl，即linq查询语句来改写：

　　var result = from p in products where p.unitprice >= 20 group p by p.categoryname into g orderby g.count() descending select new { name = g.key, count = g.count() };

　　编译器会简单地将linq差距语句转化为前一种形式。这段代码只是表现出最终的目的，而不是明确指定做事的方式，这样便可以很容易地并行执行这段代码，如使用pinq则几乎不需要做出任何修改。

　　函数式编程

　　anders提出的另一个重要的声明式编程方式便是函数式编程。函数式编程历史悠久，如当年的lisp便是函数式编程语言。除了lisp以外还有其他许多函数式编程语言，如apl、haskell、ml等。函数式编程在学术界已经有过许多研究，大约在5~10年前许多人开始吸收和整理这些研究内容，想要把它们融入更为通用的编程语言。现在的编程语言，如c#、python、ruby、scala等，都受到了函数式编程语言的影响。

　　使用命令式编程语言写程序时，我们经常会编写如x = x + 1这样的语句，此时我们大量依赖的是可变状态，或者说是变量，它们的值可以随程序运行而改变，可变状态非常强大，但随之而来的便是“副作用”问题，例如一个无需参数的void方法，它会根据调用次数或是在哪个线程上进行调用对程序产生影响，它会改变程序内部的状态，从而影响之后的运行效果。而在函数式编程中则不会出现这个情况，因为所有的状态都是不可变的。事实上对函数式编程的讨论更像是数学、公式，而不是程序语句，如x = x + 1对于数学家来说，似乎只是个永不为真的表达式而已。

　　函数式编程十分容易并行，因为它在运行时不会修改任何状态，因此无论多少线程在运行时都可以观察到正确的结果。假如两个函数完全无关，那么它们是并行还是顺序执行便没有什么区别。

　　当然，现实中的程序一定是有副作用的，例如向屏幕输出内容，向socket传输数据等，因此真实世界中的函数式编程往往都会考虑如何将有副作用的代码分离出来。函数式编程默认是不可变的，开发人员必须做些额外的事情才能使用可变状态或是危险的副作用，与之相反，c#或java必须使用readonly或final来做到这一点。此时，使用函数式编程语言时的思维观念便会有所不同。