RoR 与 Ruby DSL

最近几天来一直都在思考Ruby的成功，以及其对J2EE的借鉴意义。今天终于想明白一些事情了，所以到这里说两句。首先我看到的现象是RoR和Ruby DSL都利用一切可能手段（method missing，closure……）来提升语法的表达力，让它看起来更像声明性的语句，而不是深入细节的如何去做的具体描述。而且我看到为了达到这个目的，背后的实现是会很复杂的。而且某些技巧是等价于或者就是元编程的。对于元编程，我是一直比较反对的。因为总觉得这样的东西超出了人类大脑的掌控能力，至少超出了我的掌控能力。但是在看过一些RoR的代码之后，我改变了这个想法。复杂的实现带来的简单语法是有价值的。它可以让你更轻松地完成每天的工作，让框架用户的代码变得更干净整洁。这些都非常有价值。而且。。。也是非常经济的。RoR的一个团队，完成了所有的脏活累活，他们为了把一个语法变得很好看，可能要花费比简单实现多上十倍的时间，但是只要节约了每个用户哪怕1%的时间，按照1:100的比例来算，那也是值得的了。RoR用户越多，带来的经济价值就越大。但是。。。这是因为RoR是框架。框架意味着大部分使用者是不用关心其事先的，不用维护其实现的，而且只要按照文档教程上说的那样写，就错不了。因为用户和框架作者是通过“契约”来沟通的。这种契约是API，是“语法”。只要有人来保证这些契约，我作为一个用户来说，压根不用去管背后的琐事。而且有一个社区帮助我来学习这个契约的具体含义，帮助我确认哪些是我用错了，哪些是框架本身的bug，并且有人升级修复框架本身。这样的话，我当然希望这个契约越简单越好，越有表达力越好。我不管你是用OO实现的，还是用代码生成实现的，咋弄都行。
但是要是把RoR的相同做法（各种各样的语言技巧）搬到你的项目中来，那就是另外一回事了。你写的代码不再是在开源的框架代码了。当你不是开源的代码时，你的团队和继任者必须负责在项目整个生命周期中维护它。当你不是框架代码时，你的用户就只是你自己，没有1:100这样的加成经济效益。这个时候，再去用复杂的实现来换取字面上的表达力是否值得就是一个问题了。我认为，大部分情况下是不值得的。原因很简单，不够经济。投入和产出效益不成正比。Ruby DSL如果应用在企业内部项目上，就是这么一个样子。你得在背后把简单的事情做复杂，才能把语法整得很好看。但是最终并没有带来什么价值。你可能会说，做业务的人更好理解代码了。问题是，做业务的会来读代码甚至写代码。当然还有很多其他的论点可以支持有价值的理论。但是，我至少个人对把Ruby在RoR的表达力复制倒企业内部的终端应用程序上来持怀疑态度。但是，对应用RoR，利用RoR的良好表达力是举双手赞成的。
那么关于Ruby这种动态语言来说。我是不是能说它是框架作者的最爱。因为它给了DHH闹腾的余地。不然让DHH到Java中来，只怕不会比Rod Johnson高明多少。但是，在终端应用中使用Ruby，必须制定一些纪律来保证团队成员没有把简单事情搞复杂了。不然必然会导致投入多，产出少，难维护的局面。
结论是，写框架和写应用思路是不同的，对于价值的衡量也不同。框架作者想的是怎么让用户尽可能简单。应用的开发人员想的不仅是怎么让自己的日常工作尽可能的简单，还要考虑项目整个生命周期的维护成本。所以，RoR作为一个框架来说，非常优秀。相同技巧用来开发程序自己使用的DSL来说，未必经济。除非你能证明，复杂性带来的表达力正是你和你的Stake Holder所需要的。