我喜欢Ruby的原因

呵呵，为了“吵架”俺还在办公室呢。也是很上瘾。
耐不住性子是因为，玩ruby的很多人隐着，不玩ruby的，甚至有些人很早就听说了ruby/rails，一年多的时间都不去学习、了解，－－这不是问题，每个人都有自己的兴趣和事情－－问题是，却发一些负面的断定性的言论。这对他个人也只能说不负责任，或不考究，但对于读者是种严重的误导。
以我们目前的情况，“Rails不适合大项目”，“Rails相比j2ee没有显著优势”，“Rails的动态特性不可控”等等论调都不成立。

我近6年的工作过程中，头一次体验了产品提前完成，并且在每个sprint里都有足够的时间TDD，review，文档化，重构，交流，学习，研究。代码的质量很靠谱。

不是功能太少，而是很多。并不是太简单，而是很复杂。

以往的经历，哪个team都有做tdd、review、重构...的梦，最大的问题是时间总是不够，要做的事情总是很多。甚至系统还没做完就接近没人敢动的遗留系统了。

说起来，dreamhead最近每天和我一起做Rails应用，你不妨问问他的感受

从更大的角度说，ruby/rails对于软件开发中的 人、流程、产品及开发 各意味着什么？
展开讨论会更有意思。

我去年讲过一个presentation关于这个话题，不知道你有没有听过
Rails是很好的一步，然则一个成熟的Rails团队还需要很多周边的支援

没有，很长一段时间周末有太多私事了。能共享下不？

To 自言200801：
从上面你写的这段内容来看，你对Ruby的执行过程本身理解还存在一些问题。

解析是运行Ruby的代码的第一阶段，通常这个阶段所做的工作就是将我们看到的文本解释成一个中间形式，比如语法树。对于Ruby来说，有了这棵语法树之后，就可以进入到第二阶段，执行阶段。

你所说的各种表现形式，各种语法糖，准确来说，都是在第一阶段进行处理的，通常来说，解析只是一次性执行的过程，所以，语法的优劣从整体上来说，对性能影响不大。

真正影响Ruby性能的是它解释执行的方式。关于编译和解释，我曾写过一篇blog专门讨论，有兴趣的话，可以参考一下。《编译与解释》。

另外，有人提到Ruby这么多年一直很慢。其实，我觉得技术并不是决定性因素。因为之前很多年，Ruby只是在很窄的范围内应用，所以，速度并不是关键性因素。随着Rails让Ruby得到更广泛的认识，Ruby的性能问题才逐渐暴露出来，这时候，人们开始有了改进它的想法。所以，之后Ruby在性能问题上才有了很大的进步，也就是Ruby 1.9。Ruby 1.9已经通过编译成虚拟机字节码的方式，大幅度的提高了性能。只是说，因为1.9同时改进了太多的内容（包括虚拟机、语法和库），所以，很难一步到位的得到大家的认可。

待讨论。



我们UI team有15人+，rails开发者超过10人。另外，我们QA team在之前没有ruby经验的情况下，都能够很快用ruby编写watir脚本了。看你的php项目和开发者数量，初步估计php比较费代码，估计开发过程中复制粘贴的情况较多，同时也是后期维护费力的一个原因。推导一下：复制粘贴是产生重复代码的主要根源，重复代码是坏味道的主要表现，去除坏味道是重构的主要目标，重构是增强易维护性的主要手段。很多情况复制粘贴并不是开发者内心想做的，而是由于语言、库、框架的限制，或者评估成本收益后最终选择复制粘贴（是什么因素造成权衡过后还要这样做呢？大可想想前面贴的使用java的JGL，为什么不是每个人都会选择用它呢？甚至大多数人不用它或不知道），或者根本无法做到通过封装等手段消除重复。这不是开发者素质的问题，而是既有底层工具的支持问题。

鼓励“个人英雄主义”的说法，一是因为用更少的人就能做成事情，二是做这种论断的人可能对将rails应用于大工程没有信心或体验。


你是与Rails做对比，而你连一个Demo都没跑过，我不客气的说，你没有资格下任何论断。


如果侧重于表现层的生成，OO的那些东西确实用处有限。可对于后台逻辑复杂的情况呢？java最初在web领域的成功，不就因为asp在这方面的不足吗？而ruby的OO特性是java一时半会赶不上的。


是的，rails也可以做到，只要不是开发plugin（没事谁写这东西啊）。写不写ruby/rails的单元测试，完全是可选的。我前面也发过贴了，不写测试代码的时候rails程序也跑得很稳定，代码质量也不低，写了之后就又上升一个档次 - 一个基于其它语言框架很难达到的质量水平。你这个论断有点离谱。


好吧，你大概指php是"write-only"型的，开发快，维护难。但rails不是。你没有任何rails经验，只因他们同是动态语言，就认为这是一种共性。你重点是做底层研究，在应用层上需要多比较比较，别想当然了。如同评论java时，我去类比c（同是静态语言），然后断定java管理文件引用的关系是多么的麻烦。
至于具体的rails工程中的代码风格，如命名方式，都有普遍的惯用法，并不需再制订一套专有的，只要在团队中简单的分发达成共识即可。


Rails2.0加强了很多特性，我是怕你看完后指摘它需要改进的地方。并不表示它的兼容性不好，它的deprecated特性有明确的列表，而且还发布过兼容的版本，运行时输出用到deprecated特性的地方，以便于迁移。javaeye最近就迁移到2.0上了，可以请robbin有空分享下经验。

你这个论断同样不负责任。


web系统是否必须跑在多线程下？是否跑在多线程下性能才高？安全性才强？伸缩性才强？
我们team有布署方面的专家，这方面我不在行，就说说我所了解的吧，请各位指正。
j2ee程序是以多线程的方式跑在jvm中的，在最早的应用中，因为线程的创建和销毁比进程更少耗资源（性能因素），因此被推崇。
而后来发现有很多问题，比如稳定性从理论上不如多进程，伸缩性相对SNA架构的多进程方案又差很多，而多进程方案随着lighttpd等技术和一些理论上的支撑（进程重用等），并随多核技术的到来，线程带来的好处已经极大的弱化，而多进程的模式已经有翻身之势。在互联网应用中，使用多进程方案进行布署，很可能一直以来就是主流（不确定，需要各位大牛指正）。Rails不支持多线程，我觉得根本就不是问题。PHP是什么布署模式？我不了解，有怀疑是。。。（就不说怀疑什么了，呵）

一觉醒来，发现大家都很踊跃发言....回到闭包的问题（不好意思，我一直对闭包很推崇，因为它是ruby吸引我的一个很重要原因），前面有大侠用以下java代码演示：



我想大概是想表达ruby类似的代码：

array1 = ["cat", "monkey", "goat"]
array1.each do |a|
  puts "PRINT" + a
end

且不说4行代码和14行代码的比较....我前面说过，ruby的闭包不仅仅是“传函数指针”，闭包创建的时候自动binding一个环境，因此在闭包内部可以访问绑定时环境的对象，说起来拗口，还是用代码说话：

s = "hello"
array1 = ["cat", "monkey", "goat"]
array1.each do |a|
  puts "#{s} " + a
end

在这里，闭包里面可以访问外部的s，不知java如何实现？

我记得在其它地方有看到有人曾经质疑过闭包里面访问绑定是环境对象的行为是否有必要，我觉得十分必要，特别是在编写GUI程序时，特别有用，能使代码高度“内聚”。

然而这本来就是一个工程问题
我前面不是说了吗，对于一个web应用来说，最大的开销在两端的IO，这两个的时间是毫秒级的
（实际上还有一个大开销的东西就是HTML的渲染，通常也是毫秒级的）
既然我明知道每次请求都涉及两个几十毫秒的操作，用编程语言来做的计算到底是几十微秒还是几百微秒，有意义吗？
再考虑到一台性能颇不错的服务器只要两万块人民币，拜托，我干嘛要花这个工夫去考虑它的语法糖背后到底藏了什么？

是否可以举个例子，说明哪些语法糖需要是无法在parse阶段完成，需要借助执行部分的力量。


1.8之前的Ruby（包括1.8）中，压根就没有虚拟机，它的执行过程就是eval一棵语法树，所以，它很慢，所以，才会有后来的YARV。