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

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

喜欢——就去用！

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

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

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

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

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

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

呵呵 教训不敢啊

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

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

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

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

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