2006-09-17
关于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个人，那就是着相了。
目前想到的就是这些。
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个人，那就是着相了。
目前想到的就是这些。
评论
johnny2008
2007-03-07
dwangel 写道
花花公子 写道
你可以试试看用ruby和java同时实现一个SOA系统，到底谁更简洁。
37signals就是用互联网的方式解决企业应用。企业应用系统弄这么复杂才能保持它的神秘感。使得人们上网写blog，写wiki很轻松，但是一提到企业应用就皱紧眉头，认为这是一个严肃的话题。
为什么一定要用SOA?
Java的一些特性比较方便地实现了SOA，而且SOA更多的考虑与其他系统地结合。
但ruby现在并没有考虑与其他系统的结合，拿这个比，是不适用的。
关心一些更重要的问题更能节省时间。YAML 和XML相比，YAML更简单些，但是同样能完成很多工作，还不用复杂的解析。
另外，企业应用系统考虑的严密性要求更高。
刚看到一个帖子的观点：强壮性检查，会导致阅读者的注意力分散。
同样地，企业应用的延伸性的要求，往往也会分散开发者的注意力和精力，
同时也会把系统弄复杂。
但是，软件应用本身变化性很强，如果是为了短时间应用，那么开发一套系统，用上很短时间，
然后丢弃，在开发的成本大大降低的条件下，完全有可能。
另外，很早我就认为软件开发是服务性行业了，软件行业的景气与否很大程度上依赖于它所服务的
具体行业。（游戏开发有点特殊，应该归到娱乐业去）
dwangel
2006-09-20
花花公子 写道
你可以试试看用ruby和java同时实现一个SOA系统，到底谁更简洁。
37signals就是用互联网的方式解决企业应用。企业应用系统弄这么复杂才能保持它的神秘感。使得人们上网写blog，写wiki很轻松，但是一提到企业应用就皱紧眉头，认为这是一个严肃的话题。
为什么一定要用SOA?
Java的一些特性比较方便地实现了SOA，而且SOA更多的考虑与其他系统地结合。
但ruby现在并没有考虑与其他系统的结合，拿这个比，是不适用的。
关心一些更重要的问题更能节省时间。YAML 和XML相比，YAML更简单些，但是同样能完成很多工作，还不用复杂的解析。
另外，企业应用系统考虑的严密性要求更高。
刚看到一个帖子的观点：强壮性检查，会导致阅读者的注意力分散。
同样地，企业应用的延伸性的要求，往往也会分散开发者的注意力和精力，
同时也会把系统弄复杂。
但是，软件应用本身变化性很强，如果是为了短时间应用，那么开发一套系统，用上很短时间，
然后丢弃，在开发的成本大大降低的条件下，完全有可能。
另外，很早我就认为软件开发是服务性行业了，软件行业的景气与否很大程度上依赖于它所服务的
具体行业。（游戏开发有点特殊，应该归到娱乐业去）
gigix
2006-09-19
ddd 写道
>>（1）未来的企业需要的IT系统就一定像你所说的那么复杂吗？（2）未来编写软件、使用软件的方式就一定像现在的J2EE这样吗？
引用
这话一下子就让我想起那些叫兽和博士（满嘴的“理念”，也不知道自己理解没有），他们既然是搞研究就本不应该满嘴这些东西，就应该踏实一点。
言归正传，你说“复杂”时候不知道考虑没考虑歧义问题，你说的复杂是指it系统的哪个方面复杂？
还有，你表达东西本来可以很直接很朴素，不知道为什么非得用一种间接方法。比如这两点，完全没必要用反问，你自己人为增加着交流的难度，可能也是故意的吧（恶意推导一下：不能让别人真正了解自己的想法，否则别人思考方式也这样就显示不出自己了）
引用
这话一下子就让我想起那些叫兽和博士（满嘴的“理念”，也不知道自己理解没有），他们既然是搞研究就本不应该满嘴这些东西，就应该踏实一点。
言归正传，你说“复杂”时候不知道考虑没考虑歧义问题，你说的复杂是指it系统的哪个方面复杂？
还有，你表达东西本来可以很直接很朴素，不知道为什么非得用一种间接方法。比如这两点，完全没必要用反问，你自己人为增加着交流的难度，可能也是故意的吧（恶意推导一下：不能让别人真正了解自己的想法，否则别人思考方式也这样就显示不出自己了）
这些问题，我自己没有想清楚，只是有一些模糊的感觉。我也不打算要教导别人，我想做的只是让某些感兴趣的人开始思考——说得不好听，我凭什么要教导你？你交学费给我？
我说过好几次了，这些东西大家都没有想清楚，我只是抓紧时间把我想到的模糊的感觉写出来而已。我说的对你有启发则好，要是没有启发便罢，我不打算说服谁说什么，更看不出在这里装个高深对我有什么好处。
losing_fox
2006-09-19
如果以后中小企业成为整个社会的主流，支助的时候
gigix的说法还是有道理的
大量中小型系统的信息集成，分享，搜索才会是重点
gigix的说法还是有道理的
大量中小型系统的信息集成，分享，搜索才会是重点
levinfox
2006-09-19
花花公子 写道
你可以试试看用ruby和java同时实现一个SOA系统，到底谁更简洁。
37signals就是用互联网的方式解决企业应用。企业应用系统弄这么复杂才能保持它的神秘感。使得人们上网写blog，写wiki很轻松，但是一提到企业应用就皱紧眉头，认为这是一个严肃的话题。
企业应用的复杂性来源，从技术的角度来说是异构系统的集成，包括数据、流程和界面上的集成，需要专门的工具和方法来干这件事情，比如用到DB2 II, MQ和Portal等等，动态语言这块，别的不说，要想干这些脏活，必须有对这些庞杂工具的接口(这些工具绝大部分不是java写的)，现在好像基本上都不具备，也就是开始完善数据库的接口而已。SOA的出现可以缓解这个问题，但不是解决，也许要等到大家都用webservice那一天........
另一个复杂性来源于系统运行的稳定性，这个决定了只能采用成熟技术，关键业务肯定不会构建在目前rails这个状态的项目下。上次rails第一次发布安全升级警告的时候一票企业用户在DHH的blog造反，实际上是不成熟的表现，既然选择了rails这类处于快速成长期的项目，就要有足够的心理准备和应急措施.
其他的，就是业务上本身的复杂性和易变性，基本上一个项目坚持6个月以上，必然会出现业务的不同程度上的变化。这一点，感觉是快速开发的动态语言的用武之地。不过动态语言的代码的可维护性有没有静态的好，现在还是个问号
levinfox
2006-09-19
cookoo 写道
你后面分析的独立情况，我完全同意，这也是正确的教师和人的普遍关系。但是，一开始is-a的继承关系判断明显是错误的：人是种动物，教师不是种动物也不是某个物种，高一层的继承关系检验失败。教师是个职能（teach），一个role，不是人的子类。
从实践的角度来说，将教师抽象为人的子类型的一个前提是所有的教师都是人，就比如工人/农民/程序员都是人那样，如此，则从DRY的角度来说并没有必要独立于人的单独的这类角色类型序列来。接口和抽象是在需要的时候出现和细分的，因为每一层细分都带来新的复杂性.从里氏代换的角度来说，将教师作为人的子类型的时候，所有用人这个实例的地方用上教师实例，并不会产生语义上的矛盾。
另一个则是玄学的角度，人是一种动物是从生物学的角度的划分，但在建模当中，特别是在这个例子的场景下，设计者是不会从生物学角度来定义人这个接口的，而更多的倾向于社会学的角度。不过，这个是玄学问题，缺乏可讨论性。
ddd
2006-09-18
>>（1）未来的企业需要的IT系统就一定像你所说的那么复杂吗？（2）未来编写软件、使用软件的方式就一定像现在的J2EE这样吗？
引用
这话一下子就让我想起那些叫兽和博士（满嘴的“理念”，也不知道自己理解没有），他们既然是搞研究就本不应该满嘴这些东西，就应该踏实一点。
言归正传，你说“复杂”时候不知道考虑没考虑歧义问题，你说的复杂是指it系统的哪个方面复杂？
还有，你表达东西本来可以很直接很朴素，不知道为什么非得用一种间接方法。比如这两点，完全没必要用反问，你自己人为增加着交流的难度，可能也是故意的吧（恶意推导一下：不能让别人真正了解自己的想法，否则别人思考方式也这样就显示不出自己了）
引用
这话一下子就让我想起那些叫兽和博士（满嘴的“理念”，也不知道自己理解没有），他们既然是搞研究就本不应该满嘴这些东西，就应该踏实一点。
言归正传，你说“复杂”时候不知道考虑没考虑歧义问题，你说的复杂是指it系统的哪个方面复杂？
还有，你表达东西本来可以很直接很朴素，不知道为什么非得用一种间接方法。比如这两点，完全没必要用反问，你自己人为增加着交流的难度，可能也是故意的吧（恶意推导一下：不能让别人真正了解自己的想法，否则别人思考方式也这样就显示不出自己了）
cookoo
2006-09-18
levinfox 写道
在这个例子中，从抽象/类型的角度来说，教师应当只是人的子接口，而不应当被设计为与人并行的独立接口，这里符合is-a的关系。所以这个例子并不好
从接口表达的角度来说，如果确实需要教师和人的相互独立，比如说动物或者录音机/录像机也能够称为教师，那么，在java中本身也可以从人/动物/物体和教师两个接口派生出一个人教师/动物教师/物体教师的子接口，接口是支持多重继承的. 这样一来，对于使用者而言，如果需要是知道自己在调用的是哪一类教师，那么就传入这些个子接口类型，如果不需要，那就直接传入教师接口类型. 这是非常明确的依赖处理方式
你后面分析的独立情况，我完全同意，这也是正确的教师和人的普遍关系。但是，一开始is-a的继承关系判断明显是错误的：人是种动物，教师不是种动物也不是某个物种，高一层的继承关系检验失败。教师是个职能（teach），一个role，不是人的子类。
关于duck typing的优劣恐怕很难在短时间内有明确结论，一方面它方便了那些动态特性的实现，一方面也容易被搞得接口分散和不清晰。
dada
2006-09-18
花花公子 写道
你可以试试看用ruby和java同时实现一个SOA系统，到底谁更简洁。
37signals就是用互联网的方式解决企业应用。企业应用系统弄这么复杂才能保持它的神秘感。使得人们上网写blog，写wiki很轻松，但是一提到企业应用就皱紧眉头，认为这是一个严肃的话题。
原来企业应用是故意弄得复杂，让广大兄弟们可以借着他的神秘感混饭吃啊。
gigix
2006-09-18
fyol 写道
gigix 写道
答案很简单，不接受。DHH在RailsCon已经说得很明确了，Rails不打算迁就这些“企业级超复杂”。如果一定有这样的需求，那么就不要用Rails。
我说过很多次，Rails的兴起并不仅仅是一个语言、一个框架那么简单的事，它背后暗含着一种商业模式、企业运营模式、IT专业服务模式的变迁，所以它才受到那么多人的关注，甚至非IT的经济类媒体都来关注它。但似乎很多人仍然没有认真想想这到底是什么意思。譬如说我给你两个问题去思考：（1）未来的企业需要的IT系统就一定像你所说的那么复杂吗？（2）未来编写软件、使用软件的方式就一定像现在的J2EE这样吗？
不接受就无法成为企业应用的主流，所以rails只能用来搞web2.0。
（1）未来的企业需要的IT系统就一定像你所说的那么复杂吗？
只会更复杂。
http://www.csdn.net/subject/SAP%20Netweaver/SAP%20Netweaver_index.html
并且看来会慢慢超脱于产品层面。
虽然web service可以使跨系统开发模糊语言的差别，但java在这块市场里已经获得了更深层次的支持。
另外，是不是接受业务主键更像是哲学问题，不见得所有产品都会兼容两者。
（2）未来编写软件、使用软件的方式就一定像现在的J2EE这样吗？
rails应该是引爆了下一次革命，但在企业开发方面，这一次革命java应该更容易从中受益
第一，Rails!=Ruby。这个Martin Fowler已经说得很清楚了。
真正有趣的是，这调调听着很耳熟。五年前听到的版本是“如果Java采用虚拟机就无法成为高性能应用的主流”，结果呢？
From Ruby to Java里面另一句话很有味道：Productivity is the King。而IT最有趣的一点，就是可以眼看着生产力如何驱动历史。
花花公子
2006-09-18
fyol 写道
gigix 写道
答案很简单，不接受。DHH在RailsCon已经说得很明确了，Rails不打算迁就这些“企业级超复杂”。如果一定有这样的需求，那么就不要用Rails。
我说过很多次，Rails的兴起并不仅仅是一个语言、一个框架那么简单的事，它背后暗含着一种商业模式、企业运营模式、IT专业服务模式的变迁，所以它才受到那么多人的关注，甚至非IT的经济类媒体都来关注它。但似乎很多人仍然没有认真想想这到底是什么意思。譬如说我给你两个问题去思考：（1）未来的企业需要的IT系统就一定像你所说的那么复杂吗？（2）未来编写软件、使用软件的方式就一定像现在的J2EE这样吗？
不接受就无法成为企业应用的主流，所以rails只能用来搞web2.0。
（1）未来的企业需要的IT系统就一定像你所说的那么复杂吗？
只会更复杂。
http://www.csdn.net/subject/SAP%20Netweaver/SAP%20Netweaver_index.html
并且看来会慢慢超脱于产品层面。
虽然web service可以使跨系统开发模糊语言的差别，但java在这块市场里已经获得了更深层次的支持。
另外，是不是接受业务主键更像是哲学问题，不见得所有产品都会兼容两者。
（2）未来编写软件、使用软件的方式就一定像现在的J2EE这样吗？
rails应该是引爆了下一次革命，但在企业开发方面，这一次革命java应该更容易从中受益
你可以试试看用ruby和java同时实现一个SOA系统，到底谁更简洁。
37signals就是用互联网的方式解决企业应用。企业应用系统弄这么复杂才能保持它的神秘感。使得人们上网写blog，写wiki很轻松，但是一提到企业应用就皱紧眉头，认为这是一个严肃的话题。
fyol
2006-09-18
gigix 写道
答案很简单，不接受。DHH在RailsCon已经说得很明确了，Rails不打算迁就这些“企业级超复杂”。如果一定有这样的需求，那么就不要用Rails。
我说过很多次，Rails的兴起并不仅仅是一个语言、一个框架那么简单的事，它背后暗含着一种商业模式、企业运营模式、IT专业服务模式的变迁，所以它才受到那么多人的关注，甚至非IT的经济类媒体都来关注它。但似乎很多人仍然没有认真想想这到底是什么意思。譬如说我给你两个问题去思考：（1）未来的企业需要的IT系统就一定像你所说的那么复杂吗？（2）未来编写软件、使用软件的方式就一定像现在的J2EE这样吗？
不接受就无法成为企业应用的主流，所以rails只能用来搞web2.0。
（1）未来的企业需要的IT系统就一定像你所说的那么复杂吗？
只会更复杂。
http://www.csdn.net/subject/SAP%20Netweaver/SAP%20Netweaver_index.html
并且看来会慢慢超脱于产品层面。
虽然web service可以使跨系统开发模糊语言的差别，但java在这块市场里已经获得了更深层次的支持。
另外，是不是接受业务主键更像是哲学问题，不见得所有产品都会兼容两者。
（2）未来编写软件、使用软件的方式就一定像现在的J2EE这样吗？
rails应该是引爆了下一次革命，但在企业开发方面，这一次革命java应该更容易从中受益
windyboy
2006-09-18
同意楼上的说法
RoR不单单是一种新的语言，也许是一种新的开发的组织架构
J2EE把传统的过程分层，似乎这个层次结构太严格了，为了把软件做好，完全按照分层的做法似乎并不理想，RoR就是借鉴了先进的思想，尽可能简化事情。
设计人员可以把精力从分层的架构中解脱出来，逐渐向更人性化的DSL靠近，给大家带来的新的挑战
RoR不单单是一种新的语言，也许是一种新的开发的组织架构
J2EE把传统的过程分层，似乎这个层次结构太严格了，为了把软件做好，完全按照分层的做法似乎并不理想，RoR就是借鉴了先进的思想，尽可能简化事情。
设计人员可以把精力从分层的架构中解脱出来，逐渐向更人性化的DSL靠近，给大家带来的新的挑战
gigix
2006-09-18
fyol 写道
我觉得没有了rails的ruby没什么价值，就像没有delphi的pascal一样（虽然一个是因为框架兴起，一个是因为IDE而兴起）。
linux上用来写角本倒是不错，我也这样想过，但普及起来有难度
ROR企业应用：
有一个问题就很难解决：跨系统的数据交换
企业开发里面很多内容都与ERP等各种管理软件的WEB扩展有关系，而这些管理系统大部分是业务主键的(如客户编码做客户表主键，员工编码做员工表主键)，ROR如何接受？
linux上用来写角本倒是不错，我也这样想过，但普及起来有难度
ROR企业应用：
有一个问题就很难解决：跨系统的数据交换
企业开发里面很多内容都与ERP等各种管理软件的WEB扩展有关系，而这些管理系统大部分是业务主键的(如客户编码做客户表主键，员工编码做员工表主键)，ROR如何接受？
答案很简单，不接受。DHH在RailsCon已经说得很明确了，Rails不打算迁就这些“企业级超复杂”。如果一定有这样的需求，那么就不要用Rails。
我说过很多次，Rails的兴起并不仅仅是一个语言、一个框架那么简单的事，它背后暗含着一种商业模式、企业运营模式、IT专业服务模式的变迁，所以它才受到那么多人的关注，甚至非IT的经济类媒体都来关注它。但似乎很多人仍然没有认真想想这到底是什么意思。譬如说我给你两个问题去思考：（1）未来的企业需要的IT系统就一定像你所说的那么复杂吗？（2）未来编写软件、使用软件的方式就一定像现在的J2EE这样吗？
引用
linux上用来写角本倒是不错
那曾经是人们使用计算机的最普遍的方式。
fyol
2006-09-18
我觉得没有了rails的ruby没什么价值，就像没有delphi的pascal一样（虽然一个是因为框架兴起，一个是因为IDE而兴起）。
linux上用来写角本倒是不错，我也这样想过，但普及起来有难度
ROR企业应用：
有一个问题就很难解决：跨系统的数据交换
企业开发里面很多内容都与ERP等各种管理软件的WEB扩展有关系，而这些管理系统大部分是业务主键的(如客户编码做客户表主键，员工编码做员工表主键)，ROR如何接受？
linux上用来写角本倒是不错，我也这样想过，但普及起来有难度
ROR企业应用：
有一个问题就很难解决：跨系统的数据交换
企业开发里面很多内容都与ERP等各种管理软件的WEB扩展有关系，而这些管理系统大部分是业务主键的(如客户编码做客户表主键，员工编码做员工表主键)，ROR如何接受？
gigix
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很脆弱，我只是一个凡人，看不出来隐藏的巨大商业变革。如果看出来了，我早就飞黄腾达了。
大多数ruby都是rails用户，如果都满足于rails，rails说不做的事情，大家都不做。这语言怎么发展？
rails是ruby top killer，众望所归，DHH的理念几乎就是所有rails用户的理念。
你看，这么多人抱怨rails的问题，很少有考虑自己从头去解决的，都是打算怎么绕开，或者等待rails的下一步发展。以至于现在Ruby MVC领域一支独秀。
signal37是一个伟大的公司，一个伟大的商业传奇，但是，rails还不足以是一个伟大的技术。
ruby可以称得上是伟大的语言。
有killer当然好。只是如果这个killer的基础很脆弱的话，语言本身的基础也很脆弱。那么更多领域地发掘killers,不是更好？
我确实觉得web2.0很脆弱，我只是一个凡人，看不出来隐藏的巨大商业变革。如果看出来了，我早就飞黄腾达了。
这个，事实并非如此。我现在的情况大概一半一半，一半是写Rails有关的，另一半是Rails无关的。那些更老的linux玩家，用上Ruby以后更少依赖Rails。即便要host web content，我们也不会一上来就用Rails，很多时候都是直接webrick的。
前两周为了一个功能用不用Rails还争执起来，最后我费了很大力气才说服他们用Rails。
冉翔
2006-09-18
引用
1、Java的风格不是一开始就是这样的，也经历了一个探索、演化、成熟、形成模式，广泛传播的过程。这是java之所以能够大面积推广、工业级强度应用的原因，也可以说是java大面积推广、工业级强度应用后的结果。
我很想知道一开始Java的风格是怎样的。
我从03年到现在接触Java到现在，基本上风格就那样，随便找段代码都跟《Core Java》《Thinking in Java》书里的教学代码的风格很相似。而C++现在的风格还是各种各样什么都有。
so，很想听高人讲下Java 1995～2003年之间风格是怎么转变演化的。
levinfox
2006-09-18
cookoo 写道
借uncutstone的例子，比如说一个人是个教师，教师这个职能mixin进人这个类，如果用interface约束那他是人的时候就不能是教师，是教师的时候就不能是人！而用mixin生成的是一个既是教师也同时是人的新接口
这个问题实际上有两个方面.
1. 接口的设计. 接口的设计并不是并行的，而是与抽象方式程度相一致的有向无环层次结构
2. Java中的显式接口，表达能力强于动态语言的duck typing方式
在这个例子中，从抽象/类型的角度来说，教师应当只是人的子接口，而不应当被设计为与人并行的独立接口，这里符合is-a的关系。所以这个例子并不好
从接口表达的角度来说，如果确实需要教师和人的相互独立，比如说动物或者录音机/录像机也能够称为教师，那么，在java中本身也可以从人/动物/物体和教师两个接口派生出一个人教师/动物教师/物体教师的子接口，接口是支持多重继承的. 这样一来，对于使用者而言，如果需要是知道自己在调用的是哪一类教师，那么就传入这些个子接口类型，如果不需要，那就直接传入教师接口类型. 这是非常明确的依赖处理方式
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爱好者可以扎堆讨论。
现在的情况是，很多不需要做web的程序员，要入门学ruby，都首选rails作为入门例子练练手。
这当然没有错，也没有妨碍我去看其他的Ruby Project。
自私一点讲，我想讨论学习ruby，但是目前不打算学习rails，那就是一个工具而已。据说rails做的那么好，拿着本书就可以用了。需要的时候，就拿来用好了。
所以，我就发表一下看法，处于自私的目的，就是希望看到更多的除了rails之外的关于Ruby的讨论和信息而已。like symbol, dsl, and much more, soa, container, distributed, mobile code, etc.
这只不过是表明一个立场，以便相同立场的Ruby爱好者可以扎堆讨论。
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很脆弱，我只是一个凡人，看不出来隐藏的巨大商业变革。如果看出来了，我早就飞黄腾达了。
大多数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, 串台词了）
庄表伟
- 浏览: 678959 次
- 性别:
- 来自: 上海
- 详细资料
搜索本博客
我的相册
共 19 张
最近加入圈子
最新评论
-
《Dreaming in Code》似乎 ...
看了第0章，写的挺有意思的。
-- by weiqingfei -
关注软件开发项目中的人[ ...
呵呵！正在踏入项目管理中，LZ的文章很让我受用，希望以后能常向楼主请教！！
-- by kayzhan -
我成了CSDN的活雷锋！
真实的感觉是 csdn 有点像 广告网站
-- by modun -
我成了CSDN的活雷锋！
至于利益，我想现在这个社会不用像孔孟一样跟梁惠王说“大王何以言利”这样的一句彪炳 ...
-- by seemoon -
我成了CSDN的活雷锋！
为啥总有扒坟的？
-- by youcai
评论排行榜