编程语言的发展趋势及未来方向（4）：动态语言

我下面继续要讲的是动态语言，这也是我之前提到的三种趋势之一。



我还是尝试着去找到动态语言的定义，但是你也知道……一般地说，动态语言是一些不对编译时和运行时进行严格区分的语言。这不像一些静态编程语言，比如C#，你先进行编译，然后会得到一些编译期错误，稍后再执行，而对于动态语言来说这两个阶段便混合在一起了。我们都熟悉一些动态语言，比如JavaScript，Python，Ruby，LISP等等。

动态语言有一些优势，而静态语言也有着另一些优势，这也是两个阵营争论多年的内容。老实讲，我认为结果不是两者中的任意一个，它们都有各自十分重要的优点，而长期来看，我认为结果应该是两者的杂交产物，我认为在语言发展中也可以看到这样的趋势，这两部分内容正在合并。



许多人认定动态语言执行起来很慢，也没有类型安全等等。我想在这里观察并比较一下，究竟是什么原因会让静态语言和动态语言在这方面有不同的性质。这里有一段有趣的代码，它的语法在JavaScript和C#里都是正确的，这样我们便能比较两种语言是如何处理这段代码的。



首先我们把它看作是一段C#代码，它只是用for循环把一堆整数相加，你肯定不会这么做，这只是一个示例。在C#中，当我们使用var关键字时，它表示“请为我推断这里的类型”，所以在这里a和i的类型都是int。



这断代码在执行的时候，这两个值都是32位整数，而for循环只是简单的使用ADD指令即可，执行起来自然效率很高。



但如果从JavaScript或是动态语言的角度来看……或者说对于动态类型的语言来说，var只代表了“一个值”，它可以是任意类型，我们不知道它究竟是什么。所以当我们使用var a或var i时，我们只是定义了两个值，其中包含了一个“类型”标记，表明在运行时它是个什么类型。在这里它是一个int，因此包含了存储int值的空间。但有些时候，例如要存储一个double值，那么可能便需要更多的空间，还可能是一个字符串，于是便包含一个引用。

所以两者的区别之一便是，表示同样的值在动态语言中会有一些额外的开销，代价较高。而在如今的CPU中，“空间”便等于“速度”，所以较大的值便需要较长时间进行处理，这里便损失了一部分效率。



在JavaScript中，我们如果要处理a加i，那么便不仅仅是一个ADD指令。首先它必须查看两个变量中的类型标记，然后根据类型选择合适的相加操作。于是再去加载两个值，然后再进行加法操作。这里还需要进行越界检查，因为在JavaScript中一旦越界了便要使用double，等等。很明显在这里也有许多开销。一般来说，动态语言是使用解释器来执行的，因此还有一些解释器需要的二进制码。你把这些开销全部加起来以后，便会发现执行代码时需要10倍到100倍的开销。



不过由于近几年来出现的一些动态虚拟机或引擎，目前这些情况改善了许多。比方说，这是传统的情况（上图左），如在IE 6或IE 7里使用的非常缓慢的解释器。目前的情况是，大部分的JavaScript引擎使用了JIT编译器（上图中），于是便省下了解释器的开销，这样性能损失便会减小至3到10倍。而在过去的两三年间，JIT编译器也变得越来越高效，浏览器中新一代的适应性JIT编译器（上图右），如TraceMonkey，V8，还有如今微软在IE 9中使用的Chakra引擎。这种适应性的JIT编译器使用了一部分有趣的技术，如Inline Caching、Type Specialization、Hidden Classes、Tracing等等，它们可以将开销降低至2到3倍的范围内，这种效率的提升可谓十分神奇。

在我看来，JavaScript引擎可能已经接近了性能优化的极限，我们在效率上可以提升的空间已经不多。不过我同样认为，如今JavaScript语言的性能已经足够快了，完全有能力统治Web客户端。

有人认为，JavaScript从来不是一种适合进行大规模编程的语言。如今也有一些有趣的工具，如Google Web Tookit，在微软Nikhil Kothari也创建了Script#，让你可以编写C#或Java代码，然后将代码编译成JavaScript，这就像是将JavaScript当作是一种中间语言。Google Wave的所有代码都用GWT写成，它的团队坚持认为用JavaScript不可能完成这样的工作，因为复杂度实在太高了。如今在这方面还有一些有趣的开发成果，我不清楚什么时候会结束。不过我认为，这些都不算是大规模的JavaScript开发方案，而编写C#或Java代码再生成JavaScript的方式也不能算是完全正确的做法。我们可以关注这方面的走向。



在.NET 4.0的运行时进行动态编程时，我们引入了一个新功能：动态语言运行时。可以这样理解，CLR的目的是为静态类型的编程语言提供一个统一的框架或编程模型，而DLR便是在.NET平台上为动态语言提供了统一的编程模型。CLR本身已经有一些支持动态编程能力，如反射，Emit等等。不过在.NET上实现动态语言的时候，总会一遍又一遍地去实现某些功能，还有如动态语言如何与静态语言进行交互，这些都由DLR来提供。DLR的特性包含了，如表达式树、动态分发、Call Site缓存，这可以提高动态代码的执行效率。

在.NET 4.0中我们使用了DLR，不仅仅是IronPython和IronRuby，还有C# 4和VB.NET 10，它们使用DLR实现动态分发功能。因此我们共享了语言的动态能力实现方式，于是这些语言之间可以轻松地进行交互。同样我们可以与其他多样性的技术进行交互，例如使用JavaScript操作Silverlight的DOM，或是与Ruby、Python代码沟通，甚至用来控制Office等自动化服务。

原文链接：http://blog.zhaojie.me/2010/05/trends-and-future-directions-in-programming-languages-by-anders-4-dynamic-languages.html
.NET社区新闻，深度好文，微信中搜索dotNET跨平台或扫描二维码关注