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

您所在的位置:网站首页 p4编程语言的发展趋势 编程语言的发展趋势及未来方向

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

2024-07-05 15:22| 来源: 网络整理| 查看: 265

声明:转载自:http://www.csdn.net/article/2010-08-31/278848

感谢作者的整理,可以让语言使用者对语言的特性有更进一步的了解。

程序设计离不开编程语言,但是编程语言在国内的大环境中似乎一直是个二等公民。国内的计算机教育和工程培训,似乎一直在宣传“语言不重要,重要的是思想”,“语言一通百通”等观点,甚至在许多人眼中“语言的讨论”完全是不入流的,但其实“编程语言”与“工具”、“框架”或是“开发方法”等事物一样,都对生产力有着重要的影响。事实上,语言的发展历史比其他方面更为悠久,并且在过去十几年,甚至最近几年中都依然在不断的碰撞,演变。期间一些新的语言诞生了,而另一些在当时看来阳春白雪的语言和编程范式也重新获得了人们的重视。

Anders Hejlsberg是微软的Technical Fellow,担任C#编程语言的首席架构师,也参与了.NET Framework,以及VB.NET和F#等语言的设计与开发。几个月前,Anders在比利时的TechDays 2010及荷兰DevDays 2010分别进行了一场演讲,阐述了他眼中对于编程语言的发展趋势及未来方向,本文便对他的观点进行了总结。

大约25到30年前,Anders开发了著名的Turbo Pascal,这是一套集语言、编译器及开发工具于一体的产品,这也是Anders进入编程语言这一领域的起点。Anders谈到,如今的计算机和当年他开发的Turbo Pascal所用的Z-80已经不可同日而语。从那时算起,如今的机器已经有大约10万倍的外部存储容量,1万倍的内存大小,CPU速度也有大约1000倍的提高。但是,如果我们比较如今的Java代码及当年Pascal代码,会发现它们的差别其实并不大。Anders认为编程语言的发展非常缓慢,期间当然出现了一些东西,例如面向对象等等,但是远没有好上1000倍。事实上,近几十年来的努力主要体现在框架及工具等方面(如下图)。例如.NET Framework里有超过一万个类及十万个方法,与Turbo Pascal相比的确有了超过1000倍的增长。同样类似,现在的IDE包含了无数强大的功能,例如语法提示,重构,调试器等等。与此相比,编程语言的改进的确很不明显。

在过去5、60年的编程历史中,编程语言的抽象级别不断提高,人们都在努力让编程语言更有表现力,这样我们可以用更少的代码完成更多的工作。我们一开始使用汇编,然后使用面向过程的语言(如Pascal和C),然后是面向对象语言(如C++),随后便进入了托管时代,语言运行于受托管的执行环境上(如C#,Java),它们的主要特性有自动的垃圾收集,类型安全等等。Anders认为这样的趋势还会继续保持下去,我们还会看到抽象级别越来越高的语言,而语言的设计者则必须理解并预测下一个抽象级别是什么样子的。另一方面,如.NET,Java等框架的重要性提高了许多,编程语言往往都倾向于构建于现有的工具上,而不会从头写起。现在出现的编程语言,例如F#,以及Java领域的Scala,Clojure等等,它们都是基于现有框架构建的,每次从头开始的代价实在太高。

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

声明式编程与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的产品,并对所属种类进行分组,并降序地列出每组的分类名称及产品数量。如果是用命令式的编程方式,则可能是这样的:

Dictionary groups = new Dictionary();  foreach (Product p in products)  {      if (p.UnitPrice >= 20)      {          if (!groups.ContainsKey(p.CategoryName))          {              Grouping r = new Grouping();              r.CategoryName = p.CategoryName;              r.ProductCount = 0;              groups[p.CategoryName] = r;          }          groups[p.CategoryName].ProductCount++;      }  }   List result = new List(groups.Values);  result.Sort(delegate(Grouping x, Grouping y)  {      return         x.ProductCount > y.ProductCount ? -1 :          x.ProductCount  p.UnitPrice >= 20)      .GroupBy(p => p.CategoryName)      .OrderByDescending(g => g.Count())      .Select(g => new { CategoryName = g.Key, ProductCount = g.Count() }); 

这段代码更加关注的是“What”而不是“How”,它不会明确地给出过滤的“操作方式”,也没有涉及到创建字典这样的细节。这段代码还可以利用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 { CategoryName = g.Key, ProductCount = 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来做到这一点。此时,使用函数式编程语言时的思维观念便会有所不同了。

F#是微软随VS 2010推出的一门函数式编程语言,它基于OCaml的核心部分,因此是一门强类型编程语言,并支持一些如模式匹配,类型推断等现代函数式编程语言的特性。在此之上,F#又增加了异步工作流,度量单位等较为前沿的语言功能。在F#中如果要计算一个列表所有元素之和,也可以使用命令式的风格来编写代码:

let sumSquaresI l =       let mutable acc = 0     for x in l do         acc  0     | head :: tail -> sqr head + sumSquaresF tail 

在数学里我们经常使用递归,把一个公式分解成几个变化的形式,以此进行递归的定义。纯函数式的代码其“数学性”较强,如果您分析上面这段代码,会发现它几乎就是标准的数学定义。在编程时我们也使用递归的做法,编译器会设法帮我们转化成尾调用或是循环语句。

动态语言与元编程

动态语言不会严格区分“编译时”和“运行时”。对于一些静态编程语言(如C#),往往是先进行编译,此时可能会得到一些编译期错误,而对于动态语言来说这两个阶段便混合在一起了。常见的动态语言有JavaScript,Python,Ruby,LISP等等。动态语言和静态语言各有一些优势,这也是两个阵营争论多年的内容。不过Anders认为它们各自都有十分重要的优点,而未来不属于其中任何一方。他表示,从编程语言发展过程中可以观察到两种特点正在合并的趋势,未来应该属于两者的杂交产物。

许多人认定动态语言执行起来很慢,也没有类型安全等等。例如有这样一段代码:

var a = 0, n = 10;  for (var i = 0; i 


【本文地址】


今日新闻


推荐新闻


CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3