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

紧随着个人信息管理项目 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 以改撰马克思的一句话作为总结：“各尽语言所能，按项目需要分配。”

查看英文原文： Scalability: Dynamic and Static Programming Languages