Ruby和Rails：朴实而深远的朋友-InfoQ

许多人都说，Ruby 和 Rails 的入门门槛很低——而且大家都是不约而同地表达了同样的观点。“Ruby 语言帮你解决了很多事情，”这些年我听到的都是这样的话语，“因此你可以专注于实现你的目标。”而你也常常会听见人们用相似的好评褒扬 Rails。

对于这两种情况的说法，我恰好都表示赞同。

当然，这并不是说，写出能正常工作的代码或者让一个 Rails 应用程序启动并正常运转这样的事情，是你从街边随便揪出来的一个人就可以做的。门槛低只是相对的说法；你得先对习惯于程序开发的过程，才能体会到透明编程技术所带来的好处。你得先入道，才能借助 Ruby 或者 Rails 在原有的“道”上取得突破。

对于用户来说，易用性同样也是相对的。数十年来，从 Usenet 和其它在线评论中，我们可以发现，人们对于编程工具一直没有一致认可的选择。所有这些希望说服对方改变自己所用的工具集合的高谈阔论都是在浪费时间——没错，浪费时间，这些话里面的每一个字都在浪费时间——想想都让人觉得对不起自己的胃。（我从 1990 年就开始关注 Usenet 和其它在线论坛了，但从没看见有谁成功说服另外一个人转投某个语言或者工具。）因此，费尽心机宣称某个语言或者框架比起另一个更透明或者组织得更为良好，或者更容易使用，根本没有意义。

不过，要是你听见哪些技术被人们以同样的语气不停赞扬着的话，那么你至少得好好留意并且讨论一下这些技术了。

至少，在理论上像 Ruby 和 Rails 这样的编程语言和系统都是为了帮助你解决某方面具体问题的，也就是说，像乐器一样，它们是让你达到结果和完成目标的工具，而它们本身并不是目的。不过，音乐家把自己乐器的历史、文化和技术特性视为一个整体，而程序员们正如他们一样，对于自己所用的语言和系统也存在同样的认同感。没错，你用算法就可以描述出一个编程任务，然后可以任选几百种编程语言中的一种来把任务实现出来——这和你可以使用数百种乐器中的任意一种演奏出一个特定的曲调是一个道理。不过使用了哪种乐器并不是最终的结局。

将音乐家和程序员做类比的例子简直是不胜枚举，而其中有一些类比，与手头的问题还有易于入门的问题是有关系的。

小提琴大师 Itzhak Perlman（伊扎克·帕尔曼）就恰如其分地点评了小提琴和钢琴的区别——从长远角度看，两者没有哪个更难也没有哪个更简单，但具体说起来，和小提琴还是不一样，钢琴上手还是更容易一些。Perlman 如是说：

和钢琴演奏者相比，小提琴演奏者要度过一段更为艰苦的历程才能演奏出真正的音乐，因为钢琴演奏者 [……] 一上手就得照着乐谱练曲子，依葫芦画瓢。他们 [钢琴演奏者] 不用处理颤音（vibrato），不用操心换把（shifting），不用对付滑音（sliding），也无须顾虑弓速（bow-speed）[……] 你只要 [在钢琴上] 摁下一个键就能听到声音 [……] 你一开始就得把音乐弹出来。

正因如此，钢琴就成了乐器王国中的 Ruby 或者 Rails 一样脱颖而出。

Perlman 把低入门门槛描述成一种责任：钢琴演奏者没办法拖延自己演奏动人音乐的责任，因为他们无法以钢琴在器械操作上有难度为借口。（我们当然不是说你轻而易举就可以把钢琴弹得行云流水，而只是说在你面前扔一本乐谱你就能弹出一点什么，而初用小提琴你是做不到这样的。）

于是，自我夸耀——当然不是说 Perlman 在自夸，不过他开玩笑地把这个未决的问题抛给了更多的人——就成了演奏高难度乐器的音乐家专属的权利了，这些人能用“奇技淫巧”演奏出悠扬的乐章。但是，在计算机世界中，显摆的权利则属于使用能让自己效率更高的工具的人们，而 Ruby 和 Rails 则成为人们“吹牛显摆”所用的扩音大喇叭。

但是，我们应该分开讨论 Ruby 和 Rails，它们入手的难易度可不能直接就划上等号——这也是和我们文章主基调像对应的说法。这个说法也代表人们常会表达的疑虑：到底 Rails 开发人员该不该花时间掌握 Ruby 呢？

从某个角度讲，这个问题是可以理解的。Rails 和 Ruby“门槛低”的美名并不意味着它们对于同一群人来说都很容易，或者说不意味着它们容易的方式是相同的。S 系统并不因为使用 L 语言写的，就一定和 L 语言具备相同的难度。比如说，Ruby 是使用 C 语言写的，不管人们对 C 语言如何褒扬贬抑，要说得上 C 语言入门通常是没那么简单的。

对熟练掌握 Ruby 语言的反驳，我见过两种情况，分别基于不同的立场：

Rails 很简单，但 Ruby 就高深得多了（从难度的意义上说，级别太高）。
Rails 是一个系统；而 Ruby 则是原材料（不从简单的意义上讲，级别过低）。

对于这两种立场，就未来的 Ruby 框架或者还没有问世的类库来说，任意一种都可以说是正确的——而且也可能确实是正确的，但不管哪一个都没能正确描述 Ruby 和 Rails 之间的关系。

这里的关键点在于 Rails 设计的方式。Rails 让开发人员用到 Ruby 语言中的许多资源。是的，在许多方面，Rails 都是自成一套系统的。然而在许许多多其它的方面，Rails 暴露、探索并且发掘了它和 Ruby 的联系，而不是将这些联系隐藏或者掩盖起来。

举一个例子：helper 文件。在你每生成一个控制器（controller）的时候，helper 文件也会相应为你创建出来。Helper 文件里面什么也没有：你可以在里面放入自己写的 Ruby 方法，并可以从视图模板中调用这些方法。

这里并没有什么和 Ruby 无关的抽象，也没有将 Ruby 封装成一个单独的领域特定语言，更没有“只能通过向导生成（Wizard Only）”的标志。有的只是空位，由 Rails 提供的空位，可以让你放入定制的 Ruby 代码，也就是提供给你让你可以为应用程序加入 Ruby 代码的空位。

Rails 鼓励你使用 Ruby，鼓励你去了解 Ruby。Ruby 既不会过于难以使用，也不会过于底层，而使得你无法给 Rails 项目带来直接迅速的帮助。

Ruby 和 Rails 是不是两个平级的搭档，二者之间只是一个平行的关系？答案是否定的，要更加复杂一些。Ruby 是一项先行的基础技术；而在某些层面上，Rails 则为你提供一个经过量体裁衣的、以目的驱动的 Ruby 环境。

尽管如此，在你编写 Rails 应用的时候，Ruby 看起来确实像一个辅助技术。试想一下 XML 和 XHTML（或者任何其它的 XML 应用）之间的关系吧。一个是系统，另外一个则是使用第一个系统写出来的系统。尽管二者都被称为“标记语言（markup languages）”，但是它们的命名方案将其中的一个间接层（indirection）给隐藏起来了。

对于 Ruby 和 Rails 来说，事情有点儿倒过来了。名字是不一样，但是技术上的关系倒是比较平级（egalitarian）。

可能“平级”这个词用得并不是很准确，可能根本不存在描述 Ruby 和 Rails 之间比值的正确用词。可能这就是 duck typing 的一个例子，duck typing 所代表的原则是，无论对象属于什么类或者模块，关系都不大，关键在于它做些什么。当你开发一个 Rails 程序，并且你决定要写一个 Ruby 方法来帮你解决问题的时候，你是否能给语言和框架的关系下个定义其实并不重要。你要的只是能给出结果的东西：Rails 的配备、Ruby 的核心类、插件、Ruby 类库、你自己写的方法，等等。

这也正和“百川汇于海”是一个道理。

关于作者

David A. Black（ dblack@wobblini.net ）是 Manning 出版社《Ruby for Rails》一书的作者，同时是 Ruby Central, Inc. 的共同主管。Ruby Central, Inc. 是 RubyConf 和 RailsConf 这两个国际 Ruby 及 Rails 年度大会的主办公司。David 通过 Ruby Power and Light, LLC 提供 Ruby 和 Rails 的咨询和培训（ http://www.rubypowerandlight.com ）。