|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-05-28
这与ruby/python的动态语言特性有关，目前来说(JDK1.4)java的动态特性发挥到极限也就是反射和动态代理了。java被设计成强类型语言，而要继续提升其动态特性，对此肯定就会有影响了。
我觉得，这不是一个技术问题，而是一个哲学问题了。 p.s:虽然java的动态特性，可以通过其他手段进一步提升，但那就是通过“库”的方式了。 |
| 返回顶楼 | |
|
发表时间：2005-05-28
有点疑问:
一个CRUD需要1行代码,这功能不希奇,我做过,但是只能对付一个表的情况,并且这个表只能有1个无业务逻辑的流水号PK. 当一个CRUD操作涉及到多个表,或者这个表是联合主键、没主键的情况，这个功能还能正常使用吗？ |
| 返回顶楼 | |
|
发表时间：2005-05-28
代koalant发言：
我在我日记上更新了这个文档，提供了一个比较快的下载。 http://www.5dblog.com/vip/mulder/index.asp?id=91925 更新记录：2005-5-28： 9：30 添加了关于"关于Ruby on rails的思考"一节，第一节中增加了描述面向“用户型”和面向“程序员型”框架的区别 更新记录：2005-5-28： 13：25 添加“参考资源”一节，将文章中对 Oreilly.com 上 ROR 教程的使用部分以红字做了说明。 更新记录：2005-5-28： 16：05 添加了关于如何在 ruby 程序中读取和保存 yaml 格式的内容。 你可以帮我贴一下新的下载地址： 下载地址： http://www.koalant.com/rubyonrails.pdf 另外提供一个高速下载: http://211.102.240.142:8080/music/rubyonrails.pdf |
| 返回顶楼 | |
|
发表时间：2005-05-29
对ROR不感冒，它所承诺的十倍的开发效率是不公正的，因为它本身假定了很多的假设和默认规则，而且也不适合以领域模型组织业务逻辑的情况。它的适用性的范围比较狭窄，只适合于让简单的事情变得更简单。但是我们往往希望自己可以解决一些复杂的问题，这时它就帮不了你什么了。虽然它学习起来很简单，但是由于适用性（实用性）比较小，所以学习成本还是很高的！（我觉得不适合一线开发人员学习，倒适合像gigix这样的人玩玩。
 ）
|
| 返回顶楼 | |
|
发表时间：2005-05-29
http://forum.iteye.com/viewtopic.php?t=13133
buaawhl 写道 femto 写道 第一，那个咚咚是rails, rubyonrails 第二，他只号称快10倍，没有好称快20倍 第三,SET,GET属性那是java的说法,ruby属性不用javabean概念的 至于自动生成find ,delete ，ruby是不写代码的，有点像hibernate那样， 算是运行时反射，不过又不完全像，总之是不用写代码就是了。 gigix 写道 然则ruby on rails的最大特点不是代码生成，而是它生成的代码量只有同等规模Java程序的1/10。原因两方面，第一是Ruby本身比Java简洁得多，第二是convention over configuration。这两点才是ROR的特点，不是代码生成。就算不用代码生成，ROR的开发效率照样高过Java很多，因为需要写的代码少很多。 这两段和我的理解比较接近，我就引用在这里，借此展开讨论。 1. 解释语言 是比 编译语言更高级的语言，正如编译语言 是比 汇编更高级的语言。开发速度自然要快。ROR, Zope 的开发效率都要快。语法、用法上要高级很多，简洁很多。（对于业务简单的网站，PHP的开发效率都要比Java快很多） 编译语言为了支持一点运行期的动态性，不得不引入反射机制，bytecode generation机制。解释语言根本不需要，本身就是运行期间解释的。 2. ROR, Zope 等 Server 的稳定性、负载量、并发数如何？ Java APP Server 已经发展了很多年，有很多重量级的产品。 3. 当代码量增大、文件增多（假设500个文件以上）的时候，解释语言的代码的维护难度如何？ 编译语言有个编译过程，起着语法检查的作用。语法限制更严格。 解释语言不需要编译，应该也不需要语法检查。语法限制很松。 两者的这个 灵活度、严格度 的 “度”怎么把握？ 怎样的“度”恰好，既能保证 生产力、也能提高 易组织性，可维护性？ ---- 一点提醒。 比较语言的特性，本来是一件很有意义的事情。 但是，也许是因为饭碗的关系，“干一行，爱一行”，很容易盲目冲动地热爱拥护某一门编程语言，以至于产生情绪化的口水战，产生不了任何积极意义的内容。 Java vs C# 话题，就是这么被禁掉的。 希望不会发生在 java framework vs ROR 的身上。当然，这个可能性也不大。因为目前靠 ROR 为生的人数不象用 .net的人那么多，产生不了足够的对抗力和冲动。 |
| 返回顶楼 | |
|
发表时间：2005-05-29
我倒是支持Rail这种系统，毕竟在软件世界里开发效率是非常重要的一个方面，性能在一定情况下可以靠硬件等方法提高。
这使我想起我一个做对日外包的好朋友，他说日本人和中国人最大的区别是，日本人认为硬件不值钱，要加内存就加个G好了，而软件真正值钱。中国人正好反过来！ 这点我也有体会，我们给日本实施了个项目，日本那边的UAT服务器用了4G内存2X3点几个G的Xeon，跑DotNET根本连1G都没花掉。夸张阿！！！ |
| 返回顶楼 | |
|
发表时间：2005-05-31
关于硬件和软件的问题，其实是因为外国人力成本高，这并不能说明太多问题。
问题的实质在于类型绑定，象java这样的强类型语言，要求所有操作数的类型均能在编译或运行时确定，目的在于消除因为类型误用产生的错误。在编译期，当我们声明一个变量时，会将这个变量的“名字”与一个具体的“类型”绑定；在程序载入内存时，会为这个“类型”分配相应的存储空间；而到了运行时，这个“名字”将和存储空间绑定并赋值。 而使用动态类型绑定的语言，如脚本语言，类型是在运行时通过赋值语句绑定的，这样便获得了更大的自由度，代价自然是较弱的发现错误能力，及运行代价（因为必须在运行时做类型检测，java为了获得变量所绑定的空间能存储不同类型的值，也会做运行时类型检测，但它天生的单根继承体系，有个Class类，维护着正确的类型描述）。 这只是从语言本身的角度分析，通过一些其他技术，强类型语言，甚至C++这样的静态语言也能获得的很强的动态特性（STL真是太强了），只是就变得比较复杂了。 脚本语言最适合用做“胶水”，把可靠的粒度较小的组件组合起来。 |
| 返回顶楼 | |
|
发表时间：2006-10-18
都是设计模式惹的祸，过多的考虑优雅，考虑无依赖
却把简单的问题弄得越来越复杂 Java社区的人都有个习惯，即使很简单的应用，设计的时候也要费尽脑筋如何优雅，如何无依赖，为了无依赖整出一大堆的配置文件 可是第三方的配置文件的维护就是一个负担，我现在开发能用约定就用约定，尽量减少配置文件 |
| 返回顶楼 | |
|
发表时间：2006-10-19
ROR的所有特点不仅是优点,在某些场合下也同时是缺点.但ROR中适应了潮流的某些特点是值得我们注意和学习的.
我看最关键的一点就是元编程.最大程度降低代码和逻辑的冗余,这个是所有语言,模式,方法都追求的.问题是,这会带来性能上的损失,仔细测量和权衡,明智的放弃部分性能,对我而言,是值得学习的. 第二点是,为某个较大范围的业务做一个深入的解决,而不是为超大范围做一个普通的解决.跟GIGIX说的为20%的人提供100%的满意度类似.ROR就是面向web上的MIS类应用.保持通用部分的简单性和和特殊部分的可扩展性。 所以，问题不是用不用ROR，而是ROR究竟有什么东西是值得我们学习的。你可以用ROR，也可以继续用你手头的任何语言。语言只是工具，关键是思想。 |
| 返回顶楼 | |
