洞察动态语言与静态语言之争

Steve Yegge 一直以来致力于提倡和推广动态语言。他在斯坦福大学的一个发言对动态语言进行了深入的阐述，最近他将此发言的文稿贴在了博客上，不料此话题在博客圈子里引起了不小的反响。他认为静态语言已经发展到了极限，而动态语言相对来说却能给开发者提供更大的空间。虽然承认目前动态语言在性能、可维护性和开发工具上都存在一些问题，但他认为这些问题都不是无法解决的，动态语言推广的主要障碍是业界对尝试新语言的态度不是很积极。

Cedric Beust 就此问题写了博客回应，他对 Steve 的许多看法持否定意见，特别是“构建动态语言开发工具是跟构建静态语言有些不同，但绝不会比它要难”这个结论：

这两者不仅不一样，而且构建动态语言开发工具显然要难得多（在某些情况下甚至是不可能完成的）。你提到静态重构不能覆盖所有的用例，这个观点虽然是对的，但是其覆盖的用例已经快接近 100%，这些不是动态工具能企及的。

[…]

动态类型语言难以大规模替代静态类型语言的结论是基于这样一个事实：源文件中包括大量无类型的代码，这使得自动重构变得无法实现，更别说应用了，程序员自然也就会对重构产生排斥心理。

然而 Cedric 和 Steve 都认为在产业界的大规模开发项目中推广使用新的语言是比较困难。在这一点上他们虽然措词不同，观点还是基本一致的。Ted Neward 对 Steve 和 Cedric 的帖子进行了回应，他持有相反的观点。他认为“发明一种新的语言的门槛从来就没有象今天这么低过”。虽然非常了解“在 IT 中应用新平台的开销”，但他坚信“在新平台应用到下一个大项目之前，还是有可能进行一些准备工作，还是有足够的时间进行实验和经验积累的”。这些实验日前已经变得相对容易了，因为在老的平台上运行新语言已经变成可能：

运行在业已存在的环境（特别是 JVM 和 CLR）上的强大之处就在于此——实际的部署平台并没有变化，因此 IT 人员对部署场景多多少少有似曾相识的感觉。这就是 JRuby、IronPython、 Jython 和 IronRuby 相对于相应的本地解析语言的优势所在。

Ted Newward 总结道“一天过后，你会发现’静态 vs 动态’可能并不是问题关键所在。”选择语言的标准应该是：

1. 拥有表达人脑中概念的能力

2. 拥有随着人脑中概念的演进而演进的能力

在谈到多语言编程时，Ola Bini 也发表了类似的观点。他认为每种语言——强静态、弱静态和动态——都有各自的优势和缺点，生拉硬扯的比较是没有意义的。我们应该选择最适合目标应用的语言：

不同的语言分别适合不同的应用。好的程序员会用其积累来得出许多有价值的结论，这其中就包括选择最好的语言。如果在同一项功能实现上 Ruby 比 Java 快五倍，你怎么看待这一问题？在另一方面，Java 的许多 IDE 在维护代码方面会比较容易，但如果用 Ruby 的话，你维护的代码只有 Java 的五分之一，这两点怎样进行折衷？这都不能一概而论，不过在很多情况下，混合方案往往是最好的。

根据 Greg Young 的观点，静态 vs 动态语言的讨论也应该考虑契约式设计 (Design by contract, Dbc) 和“并非只对类型进行静态验证这一概念”。他解释了应用 Dbc 的附加价值，并且认为静态语言更适合它：

[… …] 总体上说，应用动态语言和静态语言是相当简单的，DLR 的存在很好的证明了这个观点。然而在理论层面和动态语言实际应用之间还是存在一些差距的。动态语言在概念上属于运行时的范畴，静态验证在概念上属于编译的范畴，动态语言代码在编译时的静态验证是无法实现的。试图在编译阶段验证动态代码会使你陷入停机问题的漩涡。

静态验证和契约式设计理论大部分属于确定性理论的范畴。然而在发言中，Steve Yegge 认为验证也可以充分利用“运行时知晓一切”的优势，从而变成非启发式的。他以自然语言处理和语法检查为例说明了概率方法可能更合适于验证工作，并且在计算花销上也更小。

[… ]Microsoft Word 的语法检查器用的是 Chomsky 语法。[… ] 实际上你在试图分析出句子结构时候已经做了跟编译器类似的事情。[… ]

这些都不是很管用，计算上的花销太高了，加上语言也是在不断变化之中的。Google 在这方面就用到了概率理论。

[…] 十年的潜心研究后，你得到的结论是“嗯，我们只是在做概率上的即兴表演”——[…] 他们搜集到巨量的各种语言翻译文档，利用这些文档进行机器学习，得出一个概率模型。在今后的句子翻译中基于得出的模型选出概率最高的组合即可。

查看英文原文： Debate and more Insights on Dynamic vs. Static Languages?