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

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

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

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

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

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

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

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

你的误解很深啊，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, 串台词了）

这不是对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爱好者可以扎堆讨论。

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

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

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

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

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

这个，事实并非如此。我现在的情况大概一半一半，一半是写Rails有关的，另一半是Rails无关的。那些更老的linux玩家，用上Ruby以后更少依赖Rails。即便要host web content，我们也不会一上来就用Rails，很多时候都是直接webrick的。
前两周为了一个功能用不用Rails还争执起来，最后我费了很大力气才说服他们用Rails。

我觉得没有了rails的ruby没什么价值，就像没有delphi的pascal一样（虽然一个是因为框架兴起，一个是因为IDE而兴起）。
linux上用来写角本倒是不错，我也这样想过，但普及起来有难度

ROR企业应用：
有一个问题就很难解决：跨系统的数据交换
企业开发里面很多内容都与ERP等各种管理软件的WEB扩展有关系，而这些管理系统大部分是业务主键的(如客户编码做客户表主键，员工编码做员工表主键)，ROR如何接受？