php,rails和java的有趣比较

原文来自：
http://blog.thinkphp.de/archives/170-Keynote-of-Tim-Bray-some-interesting-comparison-between-PHP,-Rails-and-Java.html
觉得很有趣。首先有趣的是作者的身份，Tim Bray是sun公司负责web技术的主管，但是在比较中丝毫看不出作者对Java偏袒；其次是作者的结论，正如在回帖中有人提及的那样，“Java赢在开发工具，却输在开发效率”。这可真有是个绝妙的讽刺！第三点是这个贴子在原出处和TSS上都得到了激烈的讨论。看来随着RoR的出现和逐渐成熟，一次类似当年Java出现时的语言优劣的争执又将无可避免的上演了。
我们自己应该以一个什么样的态度来迎接这次变革呢？其实归根结底，希望用某种编程语言来大幅度的降低软件开发的复杂度是不切实际的。动态语言在灵活性、初期的开发效率（之所以强调初期，因为个人认为动态语言的灵活性在提高开发效率的同时会弱化采用工具或者其他控制手段保证代码质量的可能。）有着先天的优势；但是像Java或者C＃这样强类型的准静态语言（Java和C＃都已经并且将越来越多的加入很多有意义的动态语言的特征，比如Java6对脚本语言的支持）在实现复杂的业务逻辑、开发大型商业系统、以及那些生命周期很长的应用中也有着非常强的优势。
记得七八年前，自己开始从一个C＋＋的熟练使用者向Java语言迁移时，刚开始的确对Java语言的简单（比起C＋＋要命的灵活性）很欣赏，因为在一个大型项目里最重要的是代码的健壮性。但是随着Java的越来越成熟，使得Java越来越复杂，而且和Java相关的很多概念也越来越超越Java语言本身。这无疑大大的增加了学习Java的成本。
再来看RoR，的确非常轻盈和简单。这得益于它对动态语言和OO特性的完美结合。但是个人认为纯粹技术上的优雅不一定会换来商业上的成功。对于软件工业来说，最重要的还是分解业务逻辑的复杂度和不确定性。毕竟，正如我的一个同事所说的那样，“无论用任何语言，初期的开发成本我们还是投入的起的。”呵呵，据他说，他经历的项目在初期的开发上占的成本大概只占到整个项目开发成本的1/6到1/5。
注：初期开发成本，是指一个项目中，最初完成开发人员视角的系统功能时所花费的成本。

很赞同楼主的意见。

初期成本只是大项目的一小部分，但对小项目会更有意义。

因此，每种语言的优劣势，一定要清楚，而且要因地制宜的使用它。

在我开发JavaEye2.0网站之前，我其实是很担心采用ruby on rails的技术风险的。三个资深的Java程序员为什么要放弃这么拿手的Java，偏偏要采用完全没有经验的RoR呢？

知道我是怎么说服我自己和我的团队的吗？

我说我们现在不懂RoR，如果我们现在用RoR开发很可能要付出比Java更长的时间，走更多的弯路，冒更多的风险，但是从长远来看，采用RoR我们会大幅度降低网站以后的维护和升级的成本。所以采用RoR我们就是牺牲短期利益换取长期利益，这个风险我们值得去冒！就这样我们毅然采用了RoR，事实证明，不但网站上线以后的维护和升级成本大幅度降低，连初始开发周期都大大缩短了。

RoR的意义不光在于开发速度快，这只是一方面，更重要的是连维护成本都跟着大幅度降低，这才是最有意义的。

我觉得有些人自己也没有用过RoR，就贸然揣测RoR的缺点，得出某些结论还是挺轻率的。

robbin兄，我经常看《程序员》杂志，所以对你的一些技术观点还是比较了解和认同的。但是也知道你在技术方面走的比较快。这个快字在大多数时候是好现象，但在某些时候并不会带来积极的效果。举个简单的例子，如果JavaEye是由三个刚刚学习Java不久的开发人员来负责，你会建议他们使用RoR吗？或者JavaEye是由三十个水平参差不齐的人来维护，你会建议项目使用RoR吗？
灵活轻盈的东西在高手手里是利器，在普通的开发人员手中会是什么则完全取决于项目指导者所界定的开发手段。
我想JavaEye里面的很多人都接触过PHP的。著名的bugtracker工具Mantis就是用PHP开发的。我因为项目的需要曾经修改过Mantis的源码，深深为Mantis作者的水平所折服。Mantis采用的语法是传统的PHP写法，但是作者却采用很多OO甚至FP的思路将整个代码结构设计的非常出色。RoR从语法上要优于PHP，所以我坚信使用RoR能开发出比Mantis的代码结构更为优秀的系统。可是同时我也看过很多用PHP或者JSP开发（这里是指JSP的代码量远远超出了Java的代码量的项目，即jsp不但负担了显示逻辑，还负担的大多数业务逻辑。）的网站项目，大量充斥其中的支离破碎的代码有时候真让人苦笑不得。也许有人会反问，难道用Java开发就可以避免这种现象吗？对，的确不能。但是Java作为一种强类型语言，在设计层面上可以得到工具的强有力的支持，使得普通的开发人员可以严格按照设计者的意图完成代码的开发工作。
重新回到那个比较本身，我建议大家更多留心一下Tim Bray的观点。毕竟，作为JavaEye的我们，所能接触的领域，比起Tim  Bray来要局限很多。
另外，不知道robbin兄

这句是不是在说我？如果是的话，请有机会时直接指出来。记得以前Jdon有阵子气氛就非常不好，观点不同时常常失去冷静而互相攻击。robbin兄也是经历过的，希望JavaEye的气氛能一直以一种善意的探讨为主。

robbin,你们的维护成本真的降低了吗？记得前段时间还看到你说代码很难分解和同步，最后基本上是一个人在编码

假如你从现在起要自己维护和升级，你觉得你能在短时间胜任吗（如果你们现在还是主要一个人在编码的话）？

关于RoR维护成本，TTS上的讨论也热火朝天。http://www.theserverside.com/news/thread.tss?thread_id=43020
目前国内除了JavaEye还有没有其他比较成熟的RoR应用？如果有的话，robbin兄可以联络大家聚在一起讨论一下目前系统的可维护性究竟如何。

说真的javaeye功能还是比较弱的.有些方面易用性也不太好(举止例子,我搜索列表,点开列表中的一个主题.看完以后,想回到列表.好想不行噢!).并且也有蛮多的bug,其中处理BUG速度也是比较慢.我提了一个BUG.居然那么久还没搞定.

ssuupv的话好像有些离题，呵呵。不建议在这里讨论JavaEye的bug，因为个人觉得JavaEye用这么快的速度完成了升级已经能够说明很多问题。不知道JavaEye是兼职完成的还是有专职人员，如果是兼职，bug响应速度慢一点是完全正常的。

\

呵呵，借用下，不多说了。

还有想问下robbin， 根据楼主所提供图表上的开发效率对比，ruby只是java的两倍，而维护效率只有java的1.3倍左右。之前的讨论中您曾经提出过开发效率5-10倍的观点，特别是代码量是有10倍差距的，在我理解代码量的量级差距至少能够带来维护效率的成倍差距。能否就此问题给出一些解释。

这个是错误回贴，请删除