语言是如何影响框架设计的？

是 Ruby 语言使得 Rails 这样高生产力的框架如此容易使用吗？是 Java 语言的特性阻碍了高生产力框架的创建吗？Frank Sommers 写道，框架是开发人员生产力背后的核心驱动力，而且他对是不是某些语言的土壤可以生长出优秀的框架而有些语言却不能这个问题进行了一番研究。他的帖子引起了大规模争论，其中有针对闭包是否会引出更好的Java 框架的相关讨论。

Sommers 参考了 Cay Horstmann 将 Java 的样板式语法和它缺少“合适的Web 框架”视为遗憾的帖子。Sommers 拿Java 和Ruby 进行对比后说到，Ruby 的代码很优雅整洁，容易学习，写一个典型的Rails 应用也用不着像Java 需要那么多的代码。Rails 利用了Ruby 的元对象协议和模块系统来把开发人员隔离于众多复杂性之外。

Sommers 还拿 Flex 和 ActionScript 与 Rails 和 Ruby 进行了对比：

在 Flex 身后的是 ActionScript 3 语言。它是逐渐成型的 EcmaScript 4 规范的一个版本，它合并了 Java 语法中最丑陋的部分和 JavaScript 最离奇孤僻的一些特性。ActionScript 3 试图在一锅汤里面同时加入动态型别和静态型别这两味主菜，此外还有函数式编程和面向对象编程。这锅汤已经没法喝了，看一眼都会让人眼花缭乱、头晕目眩。

但是 Flex 的设计者把这些复杂性都隐藏起来了——就像 Rails 一样——Flex 应用只是由一些简短的 ActionScript 代码片段、小段函数，与一个基于 XML 的 UI 布局语言混合而成。学习 Flex 比学习 ActionScript 3 高级特性的难度低多了，不过要掌握 Flex 框架如何实现某些关键性功能也绝非易事。

Flex 和 Rails 都选择了它们所尊崇的语言中相对容易掌握的某些方面，而且在它们的设计意图中也在强烈建议开发者使用这些特性。这正是每一个框架都应该做的。

Sommers 随后讨论了可扩展性语言的设计思想。Java 的可扩展性很强，但是处理小问题却不是那么得心应手。Ruby 的可扩展性也许不是那么好，但 Rails 为 Ruby 完成了这一切。Sommers 认为 Scala 具有优秀的伸缩性，或许可以在它的基础上创建出简单的框架。

在这场讨论之外，Bruce Tate曾经撰文介绍过Seaside ——一个拥有可与Rails 的生产力相媲美的基于Smalltalk 的Web 应用框架：

我并不是说在未来 10 年里我们都将使用 Smalltalk 编程。那列靠站的火车已经锈痕斑斑。不过我认为如果有足够吸引人的经济利益驱动的话，语言的问题就会消失得无影无踪。给我一个用凌乱无序荆棘丛生的语言编写的应用，要是它能比流行语言所写的应用快上 5 倍，还容易维护，我每天所消耗的时间精力也能减少 2/3，我才不去管你用的是哪门子语言呢。

Appcelerator 这个 Web 框架走了一条不一样的路。它是与语言无关的，为 Java、Ruby、PHP、.NET 和 Python 都提供了 SDK。

也许 Tim Berners-Lee 的最小能力原则（Rule of Least Power）是人们应该记住的：“在适合用来表示万维网中的信息、约束或是程序的语言中，请使用功能最少的那一个”。