关于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个人，那就是着相了。

目前想到的就是这些。

评论

17 楼 冉翔 2006-09-18  

引用

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

我很想知道一开始Java的风格是怎样的。

我从03年到现在接触Java到现在，基本上风格就那样，随便找段代码都跟《Core Java》《Thinking in Java》书里的教学代码的风格很相似。而C++现在的风格还是各种各样什么都有。

so，很想听高人讲下Java 1995～2003年之间风格是怎么转变演化的。

16 楼 levinfox 2006-09-18  

cookoo 写道

借uncutstone的例子，比如说一个人是个教师，教师这个职能mixin进人这个类，如果用interface约束那他是人的时候就不能是教师，是教师的时候就不能是人！而用mixin生成的是一个既是教师也同时是人的新接口

这个问题实际上有两个方面.
1. 接口的设计. 接口的设计并不是并行的，而是与抽象方式程度相一致的有向无环层次结构
2. Java中的显式接口，表达能力强于动态语言的duck typing方式

在这个例子中，从抽象/类型的角度来说，教师应当只是人的子接口，而不应当被设计为与人并行的独立接口，这里符合is-a的关系。所以这个例子并不好
从接口表达的角度来说，如果确实需要教师和人的相互独立，比如说动物或者录音机/录像机也能够称为教师，那么，在java中本身也可以从人/动物/物体和教师两个接口派生出一个人教师/动物教师/物体教师的子接口，接口是支持多重继承的. 这样一来，对于使用者而言，如果需要是知道自己在调用的是哪一类教师，那么就传入这些个子接口类型，如果不需要，那就直接传入教师接口类型. 这是非常明确的依赖处理方式

15 楼 buaawhl 2006-09-18  

这不是对DHH的要求，是对媒体宣传工具的要求。DHH是一个伟大的程序员。媒体宣传工具把他塑造为教主，反复传播rails的理念，仿佛rails的理念就是ruby的理念。
现在的情况是，很多不需要做web的程序员，要入门学ruby，都首选rails作为入门例子练练手。
这当然没有错，也没有妨碍我去看其他的Ruby Project。

自私一点讲，我想讨论学习ruby，但是目前不打算学习rails，那就是一个工具而已。据说rails做的那么好，拿着本书就可以用了。需要的时候，就拿来用好了。
所以，我就发表一下看法，处于自私的目的，就是希望看到更多的除了rails之外的关于Ruby的讨论和信息而已。like symbol, dsl, and much more, soa, container, distributed, mobile code, etc.
这只不过是表明一个立场，以便相同立场的Ruby爱好者可以扎堆讨论。

14 楼 cookoo 2006-09-18  

buaawhl 写道

这个思路很简单啊。
大多数ruby都是rails用户，如果都满足于rails，rails说不做的事情，大家都不做。这语言怎么发展？
rails是ruby top killer，众望所归，DHH的理念几乎就是所有rails用户的理念。
你看，这么多人抱怨rails的问题，很少有考虑自己从头去解决的，都是打算怎么绕开，或者等待rails的下一步发展。以至于现在Ruby MVC领域一支独秀。
signal37是一个伟大的公司，一个伟大的商业传奇，但是，rails还不足以是一个伟大的技术。
ruby可以称得上是伟大的语言。

有killer当然好。只是如果这个killer的基础很脆弱的话，语言本身的基础也很脆弱。那么更多领域地发掘killers,不是更好？
我确实觉得web2.0很脆弱，我只是一个凡人，看不出来隐藏的巨大商业变革。如果看出来了，我早就飞黄腾达了。

你的误解很深啊，DHH说不做，不代表你就不能做，毕竟是开源软件嘛（er这么说好像有欠说服力...）。

不满足于DHH人多着呢，比如DHH不喜欢复合主键，有人自己搞插件也一样；有人不喜欢DHH的默认rhtml搞了模版liquid；有人不喜欢DHH感觉完美的AR搞了rBatis；DHH说不喜欢内置国际化有人照样搞出plugin；DHH不喜欢重量级组件还不是有人搞了mvc三包的engine。你看有这么多前辈做榜样，你不喜欢什么也可以自己搞嘛。Rails也不是唯一的Ruby web框架，不过plugin改东西太easy了，很大程度减少了另起炉灶的可能。

下面谈另一个问题，为什么37s不做呢？做个有求必应的土地公岂不是皆大欢喜？因为37s是个实业公司，它做Rails只是出于满足自己的业务需求外的额外贡献。37s不是jboss那种为了做框架而做框架的公司，Rails技术支持也不是37s的业务，所以满足所有人不是它的义务，做额外的事也不符合它的利益。你大概会说: Kao, 怎么这么拽啊，老子不用了。OK, 但愿能提供全方位按摩（哦错了，是服务）的jboss能令您满意。

退一万步说Rails就是现在突然死了，伟大的Ruby也不会怎样，不过就是像两年前那样名不见经传罢了。有更多killer当然更好，不过这不是光想就能出来的。Rails是不够伟大，php就更不伟大了, 可叹人心不古，世风日下，好人遭殃，坏人当道（oops, 串台词了）

13 楼 cookoo 2006-09-18  

个人看法：在静态类型语言里通过造型在某一时刻假装成某一个接口以达到类型约束的目的。而mixin，顾名思义就是把一个接口注入到类中然后和类接口融合成一个新接口。

借uncutstone的例子，比如说一个人是个教师，教师这个职能mixin进人这个类，如果用interface约束那他是人的时候就不能是教师，是教师的时候就不能是人！而用mixin生成的是一个既是教师也同时是人的新接口 (布娃娃[感谢友情客串]肯定会跳出来指着偶鼻子说这是在扩大接口啊)。可见两者的设计出发点不同，用mixin的时候设计者就假设使用者会使用全部公开的新接口（也就是全部依赖）而不是像interface那样假设只使用特定的一部分接口， 但两者都应该不会造成类型安全问题。

这样做好不好可能是个哲学问题了，期待OO大师来解惑了。

12 楼 levinfox 2006-09-17  

cookoo 写道

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

当然，说"死穴"是夸张了一点点。
但是对类的部分依赖在Java的世界里并不一定是设计问题。一个类实现多个接口是相对常见的情形，但是使用者通常只会用到/依赖于这些接口中的某一个(同时几个的情况相对较少).这个时候，显式的接口实际上是一种部分解耦的手段。当然，这种部分解耦有多大意义，我并不是很清楚

11 楼 buaawhl 2006-09-17  

这个思路很简单啊。
大多数ruby都是rails用户，如果都满足于rails，rails说不做的事情，大家都不做。这语言怎么发展？
rails是ruby top killer，众望所归，DHH的理念几乎就是所有rails用户的理念。
你看，这么多人抱怨rails的问题，很少有考虑自己从头去解决的，都是打算怎么绕开，或者等待rails的下一步发展。以至于现在Ruby MVC领域一支独秀。
signal37是一个伟大的公司，一个伟大的商业传奇，但是，rails还不足以是一个伟大的技术。
ruby可以称得上是伟大的语言。

有killer当然好。只是如果这个killer的基础很脆弱的话，语言本身的基础也很脆弱。那么更多领域地发掘killers,不是更好？
我确实觉得web2.0很脆弱，我只是一个凡人，看不出来隐藏的巨大商业变革。如果看出来了，我早就飞黄腾达了。

10 楼 cookoo 2006-09-17  

buaawhl 写道

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

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

哈，你这个Ruby without Rails的保皇派（玩笑）
我一直认为一个语言的发展主要看其Killer Application的发展。本身的特性说的天花乱坠也只是一种可能性。Ruby现在只有一个Killer就是Rails，候补是rake和watir。

9 楼 cookoo 2006-09-17  

levinfox 写道

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

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

8 楼 buaawhl 2006-09-17  

动态语言既然是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.

7 楼 cookoo 2006-09-17  

buaawhl 写道

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

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

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

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

6 楼 levinfox 2006-09-17  

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

5 楼 buaawhl 2006-09-17  

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

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

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

4 楼 buaawhl 2006-09-17  

现在的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

3 楼 ylt 2006-09-17  

庄表伟 写道

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

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

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

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

2 楼 ddd 2006-09-17  

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

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

1 楼 buaawhl 2006-09-17  

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

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