如果你想掌握Ruby，这本书是最好的起点。如果你想运用Ruby，这本书也是案头必备。所以，如果你已经决定要走入Ruby的世界，那么这本书是必经之路，而本不需要一篇“推荐序”。
问题在于，我们为什么还要学习一种新的语言？特别是当Ruby整体上仍然是一个没有完全成熟的“小语种”的时候，为什么要把宝贵的精力投入到Ruby中？这才是我想讨论的问题。
跟很多人一样，我学习程序设计是从Basic语言开始的。然而在初步了解了程序设计的基本概念之后，我便迅速地转向了C语言，并且在上面下了一番苦功夫。是C语言帮助我逐步理解了计算机系统以及算法、数据结构等基础知识，从而迈入程序设计的大门之中的。C语言出色地实现了真实计算机系统的抽象，从而表现出极佳的适应性和强大的系统操控能力。直到今天，我仍认为认真理解和实践C语言是深入理解计算机系统的捷径。然而，当我尝试着用C语言来干点实事的时候，立刻发现一些问题：C的抽象机制过于简单，容易犯错，开发效率低下，质量难以稳定。这时，有一位老师向我介绍了VisualBasic，他盛赞VB是“最高级的开发语言”，代表未来的发展方向。正好当时有一个学校的项目摆在我面前，我几乎没有学习，凭着自己那点QuickBasic的底子，借助在线帮助，迅速地将项目完成，并且获得了好评。
通过这些初级的实践，我体会到VB在开发应用程序方面所具有的惊人的高效率，进而意识到，C与VB是两类设计目标完全不同的语言。以C语言为代表的系统编程语言的优势在于能够充分发挥机器的性能，而像VB这样的语言的优势则是充分提高人的效率。事实上，执行性能与开发效率是软件开发中的一对矛盾，所有的程序设计语言都必须面对这个矛盾，作出自己的选择。
在当时，大多数新语言的选择是上下通吃。它们一方面提供了丰富多彩的高级抽象，另一方面又提供了强有力的底层操作能力，希望由此实现高性能与高效率的统一。C++、Java、C#和Delphi都是走的这条路线，甚至VB从5.0开始也强化了底层操作机制，并提供了编译模型，不落人后。
我当时选择了C++。对于熟悉C语言的我来说，这是一个自然而然的选择。深入学习C++是一个漫长而艰苦的过程，不但要理解伴随面向对象和泛型而来的大量概念，牢记各种奇怪的语法规则，还要了解实践应用中大量存在的陷阱，掌握一系列“模式”、“惯用法”和“条例”。在克服这种种困难的过程中，我对程序设计的认识确实得到了强有力的提升，但是C++真的实现了执行性能和开发效率的双丰收了吗？很遗憾，答案是“否”。我自己的体会是，使用C++要花费大量精力来进行试探性设计，还可能要投入巨大精力来消除代码缺陷，因此开发效率不高。一些权威的调查显示，在新项目的执行中，C++的开发效率甚至低于C，这不得不发人深思。C++提供了大量的语言机制，又存在一些陷阱，想要实现良好的运行性能，就必须遵守一系列清规戒律，这就带来了思想上的不自由，其结果往往是效率的低下。
随后流行的Java和C#等语言，有效地消除了C++中存在的一些陷阱和缺陷，并且提供了很好的基础设施和开发环境，大大提高了开发效率。但是它们都设定了严整的结构和规则，进行严格的编译期检查，强调规范、纪律和计划。这些语言的拥护者们骨子里都认为，构造大规模软件是一个严肃的工程，必须施加强有力的约束和规范，时时刻刻预防和纠正开发者可能犯下的错误。当然，这样必然会导致对开发者思维的束缚和思考效率的限制，从而导致宏观上的低效。但他们认为，这是构造大型高质量软件所必须付出的代价。
然而，世界上另外有一些人的想法完全不同。他们认为，一种“可上九天揽月，可下五洋捉鳖”的终极语言即使能够实现，也注定是低效的。既然这个世界本身就是丰富多彩的，为什么不保留编程语言的多样性，各取所需，各得其所，彼此协同合作，不亦乐乎？既然C语言在充分发挥机器性能方面已经登峰造极，那么就应该尽力创造能够充分发挥人脑效能的程序设计语言。当人的效率充分提高的时候，所有的问题都会迎刃而解，或者至少大为简化。
1998年，我读到一本薄薄的小书，叫做《Perl入门》。这本书介绍了一种完全陌生的语言，不但看上去稀奇古怪，而且骨子里透露出来一股与C++、Java等完全不同的气质：狂放、不羁、乖张、散漫，无法无天。对于当时的我来说，这一切令人诧异，难以接受。而Perl的拥护者似乎也懒得挑战“主流意识形态”，他们自嘲地说，Perl就是骆驼，样子不好看，气味也不好闻，但就是能干活。随后进入视野的Python外表温文尔雅，简朴工整，但其实质与Perl一样，也是崇尚自由灵活，追求简单直接。伴随着Web走来的JavaScript和PHP，虽然外表上差别很大，但是总体上看，与Perl、Python一样，都是把自由放在结构之上，把人放在机器之上的语言。人们称它们为“动态语言”或者“脚本语言”。这些语言的出现和流行，强有力地挑战了过去20年来人们深信不疑的传统观念。传统认为编译阶段的类型检查至关重要，可是动态语言却把这类检查推迟到执行阶段的最后一刻才进行；传统认为严整的结构和严肃的开发过程是必不可少的，可是动态语言却能够用一种看上去随意自由的风格去“堆砌”系统；传统把精致的模型和多层次的设计视为最佳实践，而动态语言却往往是蛮不讲理地直来直去；传统把频繁的变化和修改视为不良过程的标志，而动态语言却将此视为自然而然的工作方式；传统认为必须在机器性能与人的效率之间取得折中，动态语言却偏执地强调人的效率，而把机器性能这档子事情抛到九霄云外。动态语言离经叛道，却又大获成功，不由分说地把人们好不容易搭建起来的那个严谨的、精致的圣殿冲击得摇摇欲坠。人们怀着复杂的心情观察着动态语言的发展，猜度着它的方向和影响。
这时候我发现了Ruby。
很多转向Ruby的人，在谈论这种语言的时候，都提到“乐趣”这个字眼，我也不例外。使用Ruby编程，你会体验到一种难以名状的趣味，这种感觉，就好像是突然掌握了十倍于从前的力量，同时又挣脱了长久以来一直束缚在身上的枷锁一般。“白日放歌须纵酒，青春作伴好还乡”，当年临摹“HelloWorld”时的淳朴热情仿佛又回到了身上。Ruby实现了最纯粹意义上的面向对象，让Smalltalk、Perl和Lisp的灵魂在新的躯壳里高歌。相比于Python，Ruby的思想更加清晰一致，形式更加灵活；相比于Perl，Ruby更简单质朴，绝少光怪陆离之举；相比于Smalltalk和Lisp，Ruby更富有现代感和实干气质；相比于庙堂之上的“工业语言”，Ruby自由挥洒、轻快锐利；而相比于JavaScript和PHP，Ruby从Smalltalk继承而来的深厚底蕴又大占优势。面对执行性能与开发效率的谜题，Ruby毫不犹豫地选择了开发效率，选择了对人脑的友好。Ruby的基本思想非常简单淳朴，对于基本原则的坚持非常彻底，毫不打折扣，而在具体应用中又集各家所长，实现了巧妙的平衡。从我自己的体验来讲，使用Ruby写程序，与使用C++等主流语言感觉完全不同，没有战战兢兢的规划和设计，没有紧绷的神经，没有一大堆清规戒律，有的是一种闲庭信步的悠然，有的是时不时灵光一闪的洋洋自得，有的是抓住问题要害之后猛冲猛打的快感。我的水平还不高，还不能够设计更精妙的框架和DSL（领域语言），但我相信我已经初步体会到了Ruby的乐趣。
自从这本书的第1版出版以来，Ruby的发展越来越快。最初人们用Ruby来完成一些临时的任务，然后就迅速被它迷住了，越来越多有用和有趣的东西被开发出来，越来越多有才华的人加入了Ruby的阵营，从而形成了一股潜流。这潜流在2003年以后就已经出现了，只是还没有引起外部世界的注意。然而自2005年以后，潜流变成了潮流，越来越多的人被卷进来。整个社群围绕着Ruby的质朴与自由，创造了大量的珍宝（gems）。有人用200行Ruby代码写了一个飞快的全文搜索引擎，有人把(X)HTML的解析变成了CSSSelector的有趣复用，有人用13行Ruby代码完成了一个P2P文件共享程序，有人把Google引以为豪的MapReduce算法轻巧地实现在一个小小的Ruby程序库中。当然，最为人津津乐道的还是Ruby onRails在Web开发领域掀起的风暴。所有这一切，都令人对Ruby报以越来越热烈的掌声。
今天，Ruby已经成为世界上发展最快的程序设计语言之一，一个充满热情和创造力的社群围绕着它，开展着种种激动人心的工作。在这里没有什么豪言壮语，但是所有的工作都在扎扎实实地推进，人们被自己内心的力量驱动着，而这种力量来自于Ruby质朴和自由的乐趣，它是近于纯粹的。
我深深地知道，Ruby今天还不是“主流”，其前景究竟如何，也不是没有争论。在今天这个时代，选择技术路线是一件关乎生计和名利的事情，是不纯粹也不能纯粹的事情。在各种场合，年轻的或是年长的程序员们头头是道地分析着IT大局，掰着指头计算着技术的“钱”途，这些都无可厚非，甚至非常必要。但是，作为一个把程序设计当成自己的事业，或者至少是职业的人，总应该在自己的内心中留下那么一小片空间，在那里抛开一切功利，回归质朴，追求纯粹的编程的乐趣。如果你跟我一样，希望体会这样一种内心的乐趣，我热情地邀请你翻开这本书，加入Ruby社群。也请你相信，当越来越多的人为着自己的乐趣而共同努力的时候，我们就能创造历史。
孟 岩
《程序员》杂志技术主编
2006年12月于北京