动态和静态程序设计语言的可伸缩性

紧随着个人信息管理项目Chandler的消亡，在TSS上展开了一场关于动态语言可伸缩性潜力（scalability potential）的讨论。Ted Neward试图跳出语言之争，就此问题提出一些结构性的见解。

首先，Neward强调一种语言的可伸缩可以按照“项目大小，就像代码行数”或者“处理能力（像‘需要达到每秒处理10万请求’）”来理解。这两者是需要加以界定的，因为即使两者都很重要，但它们并不总是齐头并进的：比如使用汇编语言或者C，有助于性能的伸缩性，而不是（项目）大小的伸缩性。

Neward根据“语言扩展或者增强项目复杂度预算（complexity budget）的能力”来定义大小的伸缩性。他引用了Mike Clark的概念，意指“每个项目都有着自己固定的复杂度预算，你在基础架构（infrastructure）和工具上花费的精力越多，那用在业务逻辑上的精力就越少。”按照Neward的观点，这正是关于静态语言和动态语言可伸缩性能力争论的核心。

静态语言的拥护者辩论道，类型安全检查结果减少了程序员的工作量，“作为一个自动化工具运行一系列不需要程序员手写的测试”。此外，IDE的支持为这些语言提供了强大的重构工具，这“被广泛认为对动态语言平台来说是不可能的。”然而，动态语言支持者拿出了这样的事实——“这些语言的动态性意味着减少在创建和维护代码时的工作量，结果便是相对静态语言少的多的代码行数[……]，因而含蓄地提高动态语言的可伸缩性”。

按照Ted Neward的观点，“使用动态语言的程序员每行代码可以典型地产出比他使用静态语言的同事更多的工作”，但是他极有可能需要对没有编译器的动态语言编写更多的单元测试，在某种程度上，来确保一定数量的系统测试。

就IDE重构方面，Neward引用为Eclipse引入重构支持的Dave Thomas的意思。比如，由于动态语言直到运行时才能确定类型信息，所以其给出的信息是有限的。可是，Thomas强调“简单地搜索和替换整个文件，这是任何一款非凡的编辑器所提供的，其效果与Eclipse或者IntelliJ提供的重构功能有很多相同之处，因为类型不再是个问题。”Neward强调说他期望IDE提供商开发针对动态语言而设计的工具：

[……]相对容易地想到，IDE可以主动地去“运行”正在编写中的代码，这与Eclipse在整个编辑过程中执行常量编译（constant compile）、跟踪类型信息是相似的。

此外，不应该忘记“最初的重构浏览器是为了Smalltalk（世界上最老的动态语言之一）并使用其构建的”，这是在TSS的争论中突显出来的。

至于处理能力的可伸缩性，Ted Neward强调它是重要的，因为“不能在使用高峰期间处理预期用户负荷的项目实际上是失败的，正如从来没有被安装过的项目一样。”

动态语言反对者争论道，动态语言无法在处理能力方面缩放，因为它们是“构建在其自己的运行时（runtime）之上的，这可以说在工程效果上大大逊色于JVM Hotspot或者CLR实现中的垃圾收集装置。”而动态语言支持者回应道“现在有许多web应用和网站在MRV（Matz的Ruby VM？）解释器（与Ruby一同安装，‘开箱即用’）之上具有‘很好的’伸缩性”。

轮到Ted Neward时，他指出“随着JRuby的发布，以及像IronRuby和Ruby.Net这样的项目的运作，完全有理由相信动态语言必会运行在像JVM和CLR这样的现代虚拟机之上的”：

虽然动态语言运行在针对静态类型语言而设计的VM上通常会带来一定的性能和内存的损失，但工作在DLR和MLVM（译注：多语言VM）之上，以及对底层平台的增强将更有利于动态语言场景（scenario），而这将减少性能和内存的损失。

Ted Neward似乎认为这是一个机会，在项目大小和处理能力两个方面通过配合工具并针对其特征优化运行时环境来改善动态语言的可伸缩性。更一般而言，他相当 反对将静态语言和动态语言对立的做法。他强调一个事实，就是一些应用（例如Excel）成功地将两者结合起来，“通过创建一个核心引擎，和围绕它的一个脚 本引擎——非编程人员可以通过有意义的方式运用这个引擎。”

Neward以改撰马克思的一句话作为总结：“各尽语言所能，按项目需要分配。”

Ted Neward是Effective Enterprise Java的作者。