要是没有Ruby能产生出Rails吗？ (Could Rails have been built without Ruby? )

要是没有Ruby能产生出Rails吗？
原文出处：http://www.billkatz.com/node/42
翻译：Suninny

读了保罗·格雷厄姆（译注：Paul Gramham，著名的Lisp黑客，著有《On Lisp》和《黑客与画家》等书）关于计算机语言的杂文，由他提出的一些有趣观点使我受到启发。这篇博客条目完全可以叫做《保罗如何使我领悟了Ruby on Rails》。

首先，新的语言多半将趋向于Lisp，也许因为Lisp是麦卡锡（McCarthy）的一次理论演练，一个思维实验，与其说它是被真正设计出来硬塞进当时（1958年）的计算局限，而宁可说是被用来探索“设法使计算公理化”（见格雷厄姆的论文《The root of Lisp》，译注：中文版的译文叫《Lisp之根源》）。与之相反，Fortran和C，从硬件中采纳了大量的尾接指令（cues）来提高运行速度。随着时间的流逝，低级语言被用来处理算法简单、计算贫乏的问题，而脚本语言（如Perl、PHP、Python、Ruby）却得到迅速发展，由简单粘合剂的角色渗入到更加复杂的处理任务中。

从我开始Lisp编码到现在已有二十年了，我想知道我喜欢Ruby是否源于它跟我遥远记忆中的语言一样强大，并且比我用过的C、C++、PHP更加优美和灵活。她是一个真正面向对象（基于消息）的语言，拥有强类型、闭包并且看上去万事万物皆动态（类型、开放类）。尽管于Ruby和Rails来说我还只是个新手，但我知道她会是一个让我乐在其中的语言。

格雷厄姆谈到了“自底向上设计”－－通过改变语言去适应问题域。它暗示出为什么相对于其他Web架构，Rails看上去如此棒的一个原因：Rails就像是一个加大了马力的Ruby而不只是一堆类、过程调用和拴在一块的代码的组合。

“在Lisp中，你不仅编写你的程序向下朝向语言，你还建立语言向上朝向你的程序”，格雷厄姆写道：“语言和程序一同进化…到最后这门语言将看起来似乎就是专门为你的程序而设计的。而且当语言和程序默契地配合，你最终得到的是短小、清晰而高效的代码。”这是一个出自1993年关于Rails很好的描述，它指出了Web框架之间相当微妙的一个区别。

正如标准的Ruby让你使用“attr_writer :some_attribute”，Rails提供了一个用于定义数据关系的记法“has_many :data_thing”。这条Ruby之路似乎更深奥，随着Rails的扩充，不知她是否会继续坚持Ruby的风格。

是时候问答这个问题了――“如果没有Ruby能产生出Rails吗？”，我认为不但得着眼于功能性而且要从美学方面作考量－－它不只是简单代码行上的比较，你向上朝着Rails建立了一个解决Web开发共同问题的语言。如格雷厄姆所言，你能用任何图灵机等效的语言来建立Rails。真正的问题在于你得将美学也复制过来，不管你是否会在这过程中做一个Ruby解释器的秘密实现。对于Python用户来说，移植也算特难；而作为C用户，还是构造一个Ruby解释器来得容易。

与Zope 2（一个主力的Python应用和后端服务器架构）相冲突的一个问题是，怎么使非Python化的架构呈现在开发者面前，架构师们选择了重写，Zope X3就是重写后的作品。在早期开发的路标中，他们写道，“我们知道Python是一个伟大的语言，因为它有一个小型的核心，值明确而一致，并且有一个巨大的标准库。Zope将追随这一指针。至少一个Python大虾Xavier Defrang，认为“将不会有[Rails] in Python/PHP/Perl/Java，正是因为语言的关系…一个架构能否最终博得你的好感，在于她简洁和优雅的设计，而不是看上去像一个设计模式库。”

Defrang关于草率运用模式的抱怨很生动。格雷厄姆的这篇杂文是这样结尾的：
…在面向对象的世界里，你经常会与“模式”打交道。这些模式往往不是作为第C种情况――人编译器（human compiler）来运转〔译注：保罗的原文列出了A、B、C情况〕。当在我的程序中看到模式，我认为它是麻烦的征兆。一个程序的形态仅仅能反射它需要解释的问题，这其中任何其它的规律性，于我来说只是我的抽象工作未做到家的征兆，通常我会手工写一些宏来解决这方面的问题。

我认为格雷厄姆将模式视为副本的同义词，这非常不同于Martin Fowler对模式的看法－－怎么会认为模式就是使“怎样”（how）和“何时”（when）形式化呢。

Rails的缔造者－－David Heinemeier Hansson如此热衷于模式，他甚至为Martin Fowler的模式门类建立了漂亮的图表。Rails即是MVC模式的例证。一定数量的其他样式，如Active Records影响了框架的设计，这种无缝结合有时甚至让评论家都不会察觉到他们的存在。Rails的开发者试图尽可能地提取出这种规律性。按Rails的话说，他们称之为DRY（Don't Repeat Yourself）原则；惯例（译注：Rails的另一原则是惯例优于配置）允许我们从数据库从提取模型信息，避免了重复代码；助手（Helpers）减少了我们建立窗体及其他的面向视图的代码的数量。Rails不是第一个进行这种简化尝试的框架，但也许她是最干净的一种，因为这种抽象适合Ruby语言的风格。

一些框架信奉规律性，甚至使其成为一种文化－－可能伴随附加语言－－这样的工具能分析并自动产生一部分代码。当人们阅读代码时，就会明白它是何等的罗嗦。在这样的环境下编程就是使用工具。开发不只意味着用X语言而是Y工具中的X语言。我认为Ruby on Rails与之相反，底层的代码用Ruby构造并使用元编程（如上面的has_many）来尽可能的保持简洁，也许这是因为Rails缺乏一个如Visual Studio般全效的IDE。

有许多Rails专用的关键字，像你所期待的那样建立一门语言用于Web应用，但这些关键字以Ruby方式运作。与此相对的是，有些未混入底层语言的框架不仅需要掌握新的标识符而且还要掌握一门新的方法学。Ruby on Rails拥有代码生成脚本能快速建立脚手架，并且我想知道这种抽象能否做得更出色。

Rails尚未发布1.0版（译注：原文写于05年，目前最近的Rails版本为1.1.2），她是一件进展中的艺术品，将来的Rails版本会有所出入。随着我的Ruby和Rails编程水平的提升，我将致力于抽象级别的优化，哪种模式比较适合以及服务器端代码怎么尽可能与各式各样的胖客户做好接合…格雷厄姆的杂文让我回想并巩固了许多有关编程和Web开发方面的知识点――即便你不同意他的观点。这就是好文章的印记。