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所需要的。

评论

14 楼 taowen 2006-12-08  

whisper 写道

泛函那可是优雅的难以置信
ruby中似乎也没对算子这样的东西有什么像样的支持
可是容易终归不是什么坏事
尤其是他确实能完成你的工作时
有时觉得一千行代码比完成同样功能的一百行代码更省事
那是因为我们的头脑还不够优雅

那得建立在为了这100行优雅的代码，你没有引入1000行dirty的代码来让那100行优雅的代码成为可能的前提下。有人帮你写那1000行dirty的代码，何乐而不为呢。要是都得自己维护，我宁愿使用ruby最基本的语言设施，而不去搞tricky的东西。

13 楼 whisper 2006-12-08  

泛函那可是优雅的难以置信
ruby中似乎也没对算子这样的东西有什么像样的支持
可是容易终归不是什么坏事
尤其是他确实能完成你的工作时
有时觉得一千行代码比完成同样功能的一百行代码更省事
那是因为我们的头脑还不够优雅

12 楼 dongbin 2006-12-08  

全是高科技啊，看来我要回家好好学习了！

11 楼 charon 2006-12-07  

taowen 写道

组合数学貌似比近世代数简单。教俺近世代数的老师酷得不行，可惜俺就是没学会。。。

hehe. 俺也没学会。但俺的一个师兄近世代数和泛函都非常好。
学组合数学只要会数数有耐心就可以了，问题都相对具体一点，容易触类旁通。而近世代数需要非常好的抽象能力，一般人受不了，我也就是前半个学期还跟得上，后面的都跑飞了.

10 楼 taowen 2006-12-07  

charon 写道

taowen 写道

Higher Order Function就是复合函数啊，元编程是一个函数接收另外一个函数做参数，根据这个参数产生另外一个函数。这不是泛函中的算子么？泛函理论对比函数的理论，要复杂得多。

应该说也只有在概念上，元编程才和泛函有点关系，计算机系出身的去学泛函本身就不多，基本上也没什么好果子吃，电子工程和自控的多一些吧。相比之下，近世代数(抽象代数)更贴近一些(群环域之类的玩起来还好理解一些，至少还是组合数学的基础)。
不过，这两门课对开启思路还是很有好处的，特别是泛函分析，对学过谓词演算的还是很有启发。

组合数学貌似比近世代数简单。教俺近世代数的老师酷得不行，可惜俺就是没学会。。。
但是至少可以用泛函的复杂来说明操作函数的函数一般比操作值的函数要复杂。所以我推论出了元编程一般比常规编程复杂。

9 楼 charon 2006-12-07  

taowen 写道

Higher Order Function就是复合函数啊，元编程是一个函数接收另外一个函数做参数，根据这个参数产生另外一个函数。这不是泛函中的算子么？泛函理论对比函数的理论，要复杂得多。

应该说也只有在概念上，元编程才和泛函有点关系，计算机系出身的去学泛函本身就不多，基本上也没什么好果子吃，电子工程和自控的多一些吧。相比之下，近世代数(抽象代数)更贴近一些(群环域之类的玩起来还好理解一些，至少还是组合数学的基础)。
不过，这两门课对开启思路还是很有好处的，特别是泛函分析，对学过谓词演算的还是很有启发。

8 楼 taowen 2006-12-07  

pilipala 写道

呵呵 教训不敢啊

我也是最近开始学的，只是看到帖子随便说了几句，是不是用词太激烈了，那就不好意思喽

个人觉得元编程的难度要比范函小多了吧，
也不知道： “泛函分析是元编程的数学基础，”
倒是愿闻其详

我倒觉得，如果是学习一门语言，编译原理的基础似乎是更有帮助些。

Higher Order Function就是复合函数啊，元编程是一个函数接收另外一个函数做参数，根据这个参数产生另外一个函数。这不是泛函中的算子么？泛函理论对比函数的理论，要复杂得多。
编译器做的就是元编程。因为它要把高级语言表达的函数转化为机器码表达的函数。毫无疑问，投入工业使用的编译器的实现都是很复杂的。但是我们会关心编译器是不是把我们的语言编译对了么？会去了解其中怎么做的么？不会吧。正是因为编译器做的是元编程，所以它能够支持其上的语言。在Ruby内部要嵌入DSL，必然需要对应的东西在背后做元编程。Ruby提供了强大的动态元编程的能力，为其嵌入DSL奠定了基础。所以可以把RoR理解为Ruby内部的编译器，编译的是其支持的DSL，给WEB开发人员用的DSL。只要信任RoR的质量，把RoR当作一种DSL的编译器来看，我们就不用去关心其内部实现。但是如果这DSL是你自己发明，要你自己维护的话，那么复杂性的代价就要自己承受了。另外把RoR当作编译器来看，它也要遵守编译器的一些行为准则，包括对于调试的支持，良好的出错信息，统一的语言习惯。正是这些准则没有做到，使得C++的模板元编程只是天才的游乐场。

7 楼 pilipala 2006-12-07  

呵呵 教训不敢啊

我也是最近开始学的，只是看到帖子随便说了几句，是不是用词太激烈了，那就不好意思喽

个人觉得元编程的难度要比范函小多了吧，
也不知道： “泛函分析是元编程的数学基础，”
倒是愿闻其详

我倒觉得，如果是学习一门语言，编译原理的基础似乎是更有帮助些。

6 楼 inosin 2006-12-07  

5 楼 taowen 2006-12-07  

pilipala教训的是。小弟工作半年刚满，对于很多问题还一知半解呢。元编程不曾练习不多，在MASM上做过一个OOP的汇编实现，基础是把MASM的宏抽象成一个汇编期的图灵完全语言，另外也曾目睹了模板元编程那一夏的狂热。元编程的数学基础，泛函分析倒是曾经把我折磨得够呛。
我的观点就是Ruby的“抽象整理”，体现在RoR优美的语法上的那部分，已经超出了OO的范围。对于其使用的这些元编程技巧的具体实现。我仍然觉得是难度颇高的。无论是从设计的角度还是阅读维护的角度来说。我要强调的只有一个问题，那就是成本问题。我考虑问题的角度就是一个，经济的角度。我认为RoR是“好”的，是因为它能够从用户的使用中收回开发人员的投入。我认为在封闭的，内部的，面向具体问题的企业内部应用当中，应用类似RoR的元编程技巧是“不好”的，是因为没有明显的证据表明其经济价值。所以我不是对Ruby DSL开炮，我是对在“特定应用领域”内的Ruby DSL开炮。RoR就是一种值得大力提倡的Ruby DSL。

4 楼 pilipala 2006-12-07  

1

引用

元编程超出了人类大脑的掌控能力

  我想你太低估大脑的潜力了，多练习练习吧，元编程并不复杂

2

引用

他们为了把一个语法变得很好看，可能要花费比简单事先多上十倍的时间

  如果你再多了解ruby一些，你就会明白，他们为了这个根本不需要花费多上十倍的时间。

3

引用

写框架和写应用思路是不同的，对于价值的衡量也不同。框架作者想的是怎么让用户尽可能简单。应用的开发人员想的是怎么让自己的日常工作尽可能的简单。所以，RoR作为一个框架来说，非常优秀。相同技巧用来开发程序自己使用的DSL来说，未必经济。

  写框架和写应用其实没有什么不同， rails也是从DHH写的应用中形成的一套框架。如果你认为自己只是写应用的，那么应该思考为什么自己不能写框架。也许，应用设计者和框架设计者的不同在于，是否可以从自己的工作中，抽象整理出，经常重复，可复用的部分。 而我觉得这个只和个人的能力有关。而ruby做得只是让这种抽象整理工作更简单易行。

结论是：楼主需要考虑的是 如何好好提高一下个人的能力了。

3 楼 lixigua 2006-12-07  

好像上面两位说的跟搂住想表达的不搭界。

2 楼 mafa 2006-12-06  

喜欢——就去用！

1 楼 canonical 2006-12-06  

这种说法是不正确的. 良好的设计是同时降低了构造的成本和使用的成本。一个复杂的系统本身不是一蹴而就的，它也有一个逐步构造的过程。如果只是提供使用上的方便，那只是一种无聊的技巧而已。