关于RoR无法成为企业应用开发的主流的讨论

1、Java的风格不是一开始就是这样的，也经历了一个探索、演化、成熟、形成模式，广泛传播的过程。这是java之所以能够大面积推广、工业级强度应用的原因，也可以说是java大面积推广、工业级强度应用后的结果。

2、Web2.0，固然都是从小应用开始，能快速上手的，但是，这并不意味着，Web2.0只能都是简单的，或者说，都会始终是简单的。JavaEye 2.0目前固然还很简单，但是将来如果想加入多种扩展功能，比如Blog的模版支持，更加完善的Forum，会员的管理，数据的统计，以及将来的招聘，开源项目支持等等，一定会越来越复杂的，难道你那时候就不用ruby了？

3、ruby，相比java最大的优势，不是他用法多种多样，开发速度快，而是更加容易快速的修改，而这正式未来企业级开发，所必须的品质。这一点，buaawhl已经说得很透彻了。

4、除了语言之外，设计模式、框架、开发约定、习惯等等，都是减少开发中交流难题的办法。目前能够用到的工具，还有自动化的TestCase，这个TestCase不但可以辅助重构，我以为也可以作为多个模块之间的协作约定的“无歧义表述”。

5、Ruby过于灵活，Rails其实是过于死板了。这两者的特性不该混为一谈。

6、任何时候，小团队的交流效率，都比大团队的更高，并非Ruby语言、Rails框架的特有问题。如果Robbin认为，采用RoR开发，团队人数就不能超过3个人，那就是着相了。

目前想到的就是这些。

Ruby用户量剧增14倍，基本是Rails的功劳。
现在使用Ruby的用户大部分都是使用Rails。
目前，Rails可以说是冰山的大部分山体。

potian曾经说过一句理想主义的话，Rails只是整个Ruby社区的冰山一角。
我想，Ruby只有发展到了那时候，才是Ruby发扬光大之日。
Rails只是一个催化剂，敲门砖，不应该一直成为Ruby社区的主要代表。
换句话说，Rails的未来，不代表Ruby的未来。

ruby如何如何主要看用这种语言所形成的思维。
这种思维导致语言和语言之间的本质不同。
现在ruby能够给人一种什么思维？现在这种思维除了语言本身带来的因素还有没有其他因素（rail）？
这种思维又能反过来给ruby什么作用力？

很多的语言发展就是这样，语言本身的语法和库以及其它周边重要事物决定思维方式，又反过来作用于语言。

对于第二点，就算后来加了Blog的模版支持，招聘，开源项目支持等等，JavaEye仍然只是一个简单的信息管理系统。业务逻辑仍然是简单的数据增删改。只是页面逻辑会复杂化。对于企业应用，主要还是业务逻辑复杂。

对于第三点，并不是开发快速的语言修改就快速。比如一个月以前写的perl脚本，我发现一个月以后要读懂都很困难。要修改容易主要还是代码的标准性和可读性。我现在经常要维护一些几年前的java代码，修改非常容易。先浏览代码找到要改的地方。然后做修改类名或方法名的重构，其实是预览一下，不是真的要重构。看看修改会牵涉到那些方面，是否有副作用，是否和自己预想的功能一致。然后就可以放心修改了。所以ruby代码的可维护性，没有几年时间的实践，谁也不能断定它到底怎么样？

现在的Ruby高级玩家一般都在整DSL-like API，乐此不疲。
Martin Folwer，Potian都推崇这个。
玩到后来，这个DSL就可能从语言内的API玩到语言外的Message Protocal，Shell Script（Like Rake）。
在SOA，EAI方面可能有所应用。比如，以后的RPC Text Protocal不再使用SOAP, XML-RPC这些了，直接使用简单易懂的DSL。

基础设施方面，也可能长足进步。
动态语言很适合容器和分布式这些松耦合领域，因为没有静态类型检查的限制。

MapReduce for Ruby: Ridiculously Easy Distributed Programming
http://tech.rufy.com/2006/08/mapreduce-for-ruby-ridiculously-easy.html

RingServer
http://segment7.net/projects/ruby/drb/rinda/ringserver.html

Ruby Corba
http://sourceforge.net/projects/rinn/

Distributed Ruby
http://www.rubycentral.com/articles/drb.html

Perl的自由度，比Ruby要高很多。
而Perl的模块化管理方面，比Ruby要差很多。

Ruby现在的模块管理还是有很大改进余地。很多人觉得够了。我还是倾向于Java, Python的那种多级package。

动态语言重构更容易，但是风险更大。

但是现在ruby代码的情况，也不容乐观。
修改的容易程度至少取决于两点：1. 一个方法/一个类是否容易的被其他人较为容易的读懂，象ruby这类基本无约束的动态语言，虽然比perl要好，但也只是好在内在的OO上，因为更强大，其自由度实际上是在perl之上的. python在语法上约束多一些，但是如果不是整个社区逐渐形成的保守风格(GVR比Matz强势多了)，也好不到哪里去
2.对象间的依赖关系能不能被轻易的识别出来，这一点缺乏接口/契约或者类似东西的语言都很难做到,duck typing只是一个聊以自慰的说道，并不能体现出接口作为一种系统演化过程中的抽象和解偶手段这一层含义来。一个类承担了过多的职责，不是大不了的事情，可怕的是调用者明明只用到了其中的一类职责，却产生了整体性的依赖，写代码的人可能知道，看代码的人并不能很快搞清楚这个类直接或者间接使用了被调用类的哪些个职责。依赖关系的隐式性是无类型声明型语言所编写的程序在可理解性上的(我觉得有必要区分可理解性和可读性)死穴。
动态语言的另一个死穴，是一旦使用了过强的语言特性，如open class或类似的东西，很多错误只能在集成测试或者更高层面的测试上发现。而不同阶段发现bug,其搞定的代价是按指数上升的。我最近就碰到过几个类似的问题，都是测试本身(而不是被测试的代码)引入的，一次是写了改了一个测试的某个部位，边上的其他几个测试挂了一半...还有一次更绝，因为早先写的一个测试用例的问题，导致虽然这个测试能够通过，但是后来编写的测试怎么着都看起来正确跑起来错，而且总是某名奇妙不得要领的错误,折腾半天...........
另，动态语言的强悍性，使得仅仅为了可测试性而引入IOC，Factory这类模式一点必要都没有。可以在测试过程中替换类所依赖的所有东西，不是一般的爽

Ruby的module/namespace当然可以分多级，比如CGI::Session::FileStore，不过不强制文件夹也要体现这个结构。

动态语言既然是Bind By Name，那么就应该遵守Name Convention。
相对于Java Method Signature来说，只是少了一个参数类型。
契约中剩下的部分，method name, paramter number，还是有效的。
同样可以design by contract。只是契约更加弱了。

open partial class, mixin 这些都是在同一个class中做文章。
我期望的一种做法是大量采用pojo + reflection。

Ruby CodeGen vs Reflection
http://www.iteye.com/post/130226

因为Ruby的reflection效率很高，才有20%左右的overhead.

对于active record来说，
person.save(),
person.delete()，

我们可以这么写。
persister.save(person);
persister.delete(person);

如果觉得长，经过一番内部处理，可以简化为
save(person);
delete(person);

这样就免除了domain object对active record的依赖。

act as 之类 plugin 也都可以同理处理。

这样的效果看起来是把service的注入点向上提。
这个domain object确实不依赖persistence layer了，但是DAO layer 或者 action layer 却依赖于persistence layer。
总是要把这个persistence service注入到某一层。
这个注入的手段可能是mixin, inheritance。

越上层的类，重用的可能性越小。我们就没有太在意它的POJO特性了。所以，注入上层，总比注入下层类要好。

下层类（比如domain object）成为了POJO，免除了mixin，那么，类定义是什么样，契约就是什么样。代码分析工具进行静态分析的可能性就增大，就有可能根据source来分析这些下层类之间的关系。

to cookoo,
Yes, I know Ruby module can work as multi level namespace.
而且, ruby module 可以是 instance，可以作为参数和返回值，不仅仅是静态的namespace。

我说的package主要是说文件目录。ruby对于文件的引入，我只知道一个 require, load.

说死穴夸张了点，罪不致死吧。。。duck typing本身默认假定依赖于类的所有公共接口。你说的只依赖一部分那是类设计问题，不是duck typing的错。但是不可否认open class, mixin,和各种eval让公共接口变得难以辨识。这些强力特性当然极大提高个人开发效率，但是也在团队里制造了潜在沟通障碍。我觉得需要更智能的工具去帮助消除理解障碍，因为削弱或约束这些强力特性已经不实际了。