范凯的个人观点
来自范凯的个人博客 因为看到一篇讨论PHP，Python和Ruby的编程语言讨论贴，就说说我的PHP，Python和Ruby之路吧：
我2000-2001年用PHP用了两年，那还是第一次互联网泡沫时期，到2001年后期，Servlet/JSP流行，然后我就发现：你说用PHP写的东西，都会被人鄙视。当时我们其实也用Java了，只不过用Java写后端的消息队列。
2001年后期泡沫破灭，我跑去做企业应用，就主要写Java写了很多年，中间2003年开始做JavaEye网站，到2006年用Rails重写JavaEye之前的3年，用的是phpbb搭建的，所以PHP也断断续续一直用到了2006年。
以我2000-2006年总共六年多的使用体验来说，我对PHP真的是深恶痛绝之，但凡做一个稍微大一点的系统，代码就很容易失控。2002年以后，我曾经一度以为PHP这个东西快死掉了，那个时候大家都言必称J2EE和.net了。结果Web2.0之风袭来，大家又发现J2EE太重，PHP又死灰复燃了，我其实很诧异现在PHP居然又变得如此流行。从技术上来讲，PHP是个很烂的东西，但它门槛低，易部署，普及率高，好找人，实在是互联网时代的VB，打不死的小强。
Python我大概是04-05年迷恋了一年左右，研究过Zope，plone，后来还看过wxPython，曾经一度想用Python写JavaEye网站。记得04年Rails出来之后，还很长一段时间被我深深鄙视过。
但后来我去杭州拜访potian，被他的Rails实践经验说服了，之后我和他以及其他人在JavaEye上面有一个很长的讨论贴，讨论Rails的运行机制，最后我又被他说服了。然后我还不死心，研究和比较了Rails和Django，不得不死心了，后来还曾经几次想用Python，每次都死心的很彻底，现在就彻底不考虑Python了。
就算你不用Rails，作为一个程序员，我也强烈建议你学习一下Ruby，仅仅因为可以开拓你的思维就很值得了。因为Ruby的语法很强大很好玩，是现代语言版本的smalltalk，算是很原汁原味的面向对象编程语言，你学习了Ruby以后，你就会发现，原来Java/C++所谓的面向对象就是TMD的山寨版本的面向对象，原来面向对象还可以这样玩阿。
PHP用一句话来总结就是：quick and dirty
Python用一句话来总结就是：quick and clean,but not convenient for web development
Ruby用一句话来总结就是：code for fun and quick for web
补充一下吧：为什么我当初用Rails来写JavaEye网站：
在选择用什么工具开发JavaEye网站的时候，唯一的指导标准就是：用最少的人力，最少的时间开发JavaEye网站，并且后期维护和持续升级，乃至重写的时候，代价最小。
首先排除Java和C#，代码太多太麻烦；
其次排除PHP，项目一大，代码一多，代码的管理很成问题，PHP缺乏一个起码的包管理机制；
当时重点考察Python和Ruby，因为有豆瓣的先例，开始很倾向于Python，而且我那个时候对Python比较熟悉，还曾经痴迷过一段时间的wxPython，对Zope和plone也有一些研究。
但后来比较了Rails和Django之后，就倾向于Rails了，差距实在太大了，而且当时Django很不成熟，在很早期的版本。其实即便现在Django和Rails的差距也没有缩小过。
但让我最终下定决心的是potian在05年就大规模使用Rails的实际工程经验，我曾经去杭州就我比较质疑的问题当面请教过他，和他谈过以后，就决定用Rails了。
应该说，我当初用Rails的决定很英明！ 在四年以前，当我开始鼓吹Hibernate，抨击EJB的时候，遭到的是群起而攻之的场面，但是不到一年之后，Hibernate已然得到了普及和大多数Java开发人员的认可；
在三年以前，当我开始赞誉spring的时候，spring还面临着EJB3的阴影，以及EJB2对其不登大雅之堂的指责，然而不到一年的时间，spring已经成为绝大多数Java开发人员的首选；
在两年以前，我极力希望宣传webwork，唱衰JSF，时至今日，webwork以Struts2.0的身份容登大雅之堂，而JSF还在靠厂商死挺着；
而当一年之前我开始采用RoR开发JavaEye的时候，RoR的置疑之声还甚嚣尘上，但当我在今年初预言07年下半年RoR在国内会被广泛接受的时候，很多人已经笑不出来了；
今年我预言些什么呢？我觉得会是AJAX技术走出PC的时代，证据就是iphone，与此相关联的事情就是REST架构的流行。
但是这篇文章里面我想谈的却不是我预言的水平准不准，而是想谈Java真的会因为RoR的流行而过时吗？目前在web开发主要应用在两个大的领域，互联网和企业应用，我们分别来看一下：
一、互联网领域
互联网领域第一大动态语言是PHP，第二第三分别是ASP和Java。在中小型互联网应用当中，PHP的王者地位不容动摇，但在大型应用当中，Java是目前主流的选择，特别是电子商务类型的应用，例如阿里巴巴就从早期的PHP转变到Java，从前的eachnet也是如此。造成这样局面不是没有原因的：
1．中小型互联网网站强调开发速度，维护成本，以及入门快速和部署成本，PHP是最合适的选择；用Java则显得过于笨拙，开发慢，维护成本高，入门周期长，部署麻烦；RoR开发速度最快，维护成本最低，但是RoR入门速度没有PHP快，部署成本比PHP高。因此中小型互联网网站主流还是PHP，但RoR能够占据一定的份额。
2．大中型互联网站强调稳定性，性能，大规模代码的组织能力，而开发效率则退居次要地位，有些应用如电子商务对事务有很高的要求，显然Java是最合适的选择；PHP的代码组织能力最差，RoR次之。
在互联网领域，Java从来就不是主流，并且Java的适用领域和RoR不太重合。我们甚至可以这样说，RoR现在在互联网领域取代的是那些原本不适合用Java，但是被错误的选择了Java的项目。
二、企业应用领域
目前企业应用领域第一大语言是Java，dotnet其次。企业应用采用的技术和行业有很大关系：例如金融行业，电子政务行业一般只采用Java。dotnet发展了6年尚且没有进入企业高端的应用，RoR在短期之内也很难取代Java的地位。
在企业应用领域，Java是主流，并且Java的适用领域和RoR也不太重合。我们也可以这样说，RoR将来在企业应用领域要取代的是那些原本不适合用Java，但是被错误的选择了Java的项目。
至此，我想Java程序员大可以松一口气，RoR目前有哪些不适合的场合呢：
1．对事务要求非常高的场合
RoR还是很简单的单数据库事务控制，缺乏精细的事务控制功能，当然也不支持跨数据库的分布式事务。因此对于事务要求严格的大型电子商务网站，部署复杂的分布式数据库场景显得力不从心。当然也许有些plugin可以提供这些功能，但是从目前的功能完备性和成熟度来看，还不够。
2．处理大量遗留数据库的场合
ActiveRecord的威力很大程度上来自约定，大量命名糟糕的遗留数据库会对RoR造成比较大的障碍。
3．庞大的项目团队，对开发速度要求低的场合
例如日本外包项目，团队庞大，个体开发速度要求低。但是对于代码规范要求严格的项目。
虽然RoR不会取代Java，但不意味着作为程序员的你可以固步自封。即使在工作当中用不上RoR，多看一点新的技术，对于开阔个人视野也有很大的好处。 挺有意思的现象
记得过去还没有创办JavaEye的时候，在技术社区里面推广Hibernate(也算不上是推广，只是和别人交流Hibernate)，就有一大批人酸酸的跳出来说，你们今天学习这个明天学习那个框架，全都是跟风，这些框架都是浮云，真正JDBC这种基础知识才是实力的，我就用JDBC，我用的一直很好，我完全没有必要去学习Hibernate……
每当看到这种话，我就觉得特别好笑，用一个我发明的说法叫做“牛逼哄哄的露怯”。没有人逼你学习Hibernate，你不乐意关心Hibernate，那就继续用JDBC好了，这个世界从来都不是非黑即白的。
其实这种人的心态很有意思。他一方面眼红人家学习新的技术，另一方面自己又不想花时间和代价去学习，所以恨不得所有的人都不要去学习新技术，这样他心里就感觉很安全了，正因为如此，他就总是要时不时跳出来打击一下别人，表面上很牛逼，其实虚弱的内心挣扎一览无余。
如果想把技术作为终身职业，那么对于技术人员的起码要求就是不能固步自封，要始终以开放的心态接受新技术。
打好基础知识固然重要(重要到根本无需你一遍又一遍的祥林嫂)，但是不接触新技术，新思路，新的理念，很快就会被淘汰掉。
当然学习新技术也不是盲目的什么都学习，什么流行学习什么，而是根据自身的需要，有选择的学习。例如Java Web框架有很多很流行的，Struts，Webwork，Spring MVC，Tapestry，JSF，主流的就有5个，盲目的学习者就是人家说什么他就学什么了。而聪明的学习者应该对这些东西都去接触一下，从中选择一个值得自己投资时间成本去学习的框架。例如对这五个框架我都涉猎过一遍，最终我把时间花在了Webwork上面，事实也证明我当初的投资是正确的。
我学习ruby on rails有很现实的需要，其实即便抛开现实的需要，我也认为如果有空，Java开发人员有必要学习一下，原因是：
1、ruby语言和rails框架的社区力量正在以惊人的速度增长，甚至已经进入爆炸式繁荣的前夜，这不是昙花一现的现象，而是一个时代开始的象征。
2．从我这段时间学习的情况来看，ruby语言有足够的学习深度，我原来以为自己一个很快速的上手，然后就很精通了，但是ruby不像PHP那种方便面，其知识的广度和深度都让我感觉这是一个完整的知识体系。也正因为如此，ruby生命力会很长。
3． ruby和rails是非常非常Unix-like的东西，经常和操作系统提供的功能有深度的依赖，这和Java这种不依赖操作系统，什么基础设施都自己卷起袖子自己创造的理念相比，非常非常的不同。这样做会带来一个很大的好处，很多在Java里面解决方案很复杂的问题，在ruby方案中就很简单可以搞定，相比之下，让Java显得颇为大而无当。
不过ruby和rails也树立起了一堵墙，这堵墙就是Unix操作系统，要学好我，你就先跨越Unix这堵墙吧。呵呵，这也是为什么rails core team清一色的MacOSX的原因了。
不过我觉得这是好事，我本人是Unix fans，乐意见到这种现象，况且凭借我多年深厚的Unix功底，在ruby fans中，我又站在了一个很高的起点上领跑了。
想学好ruby吗？先在你的电脑上面安装MacOSX/ubuntu作为开发环境咯。 孟岩最近写了一篇博客：
Ruby 1.9不会杀死Python
这篇文章很有点标题党的意思，所以在JavaEye论坛很快被水掉了，只好锁贴：
但我个人对于孟岩的观点是不敢苟同的。首先我并不同意所谓魔幻语言和简约语言的分类。其实Martin Flower论述过这个问题，他是用“人性化接口”和“最小接口”来区分编程语言的风格化差异的。
其实不用我多说，Martin论述的挺充分了。强把Ruby和C++归为魔幻一类，其实并不准确，因为Ruby的魔幻语法和C++相比，最大区别在于：
C++的魔幻语法会导致代码的可读性变差，而Ruby的魔幻语法会导致代码的可读性大大提高。
不论是matz本人，还是整个Ruby社区，Rails社区诸多开源项目的作者，抑或整个Ruby和Rails开发者社区，在一个编程哲学问题上是高度统一的，这就是：
强调程序员的快乐编程，追求人性化编程，在代码的可读性上面有偏执的追求，拒绝难以阅读的代码和难用的API。也就是所谓的coding for fun!
所以你看无论是Rails，rake，rspec，甚至移植自lucene的ferret，都鲜明的体现出来这种特点，就是API简单好用，让你写的代码像英文文章，自然流畅，轻松愉快。要是哪个Ruby框架的API复杂晦涩，在Ruby社区简直没法混，大家根本不买他的帐，这也是为什么Ruby应用于DSL领域这么热的根本原因。
对于ruby程序员来说，这种追求编程人性化的哲学理念会潜移默化影响程序员，让他不知不觉把代码的可读性越写越好。对于程序员来说，谁不想coding for fun呢？ 而当你品尝到了coding for fun的乐趣，又怎么会轻易抛弃？
所以Ruby受程序员欢迎的根本原因还是在于它是一种能给你带来编程乐趣的语言。 有人说，robbin你说了那么多RoR的优点，你啥时候说说RoR的缺点阿？你说的缺点肯定比别人说的更客观。没办法，为了表现出来我不是一个RoR粉，只好总结点缺点，以飨RoR黑子们：
Ruby和Rails的一些缺点的总结：
ruby的问题我觉得主要是：
1．ruby本身的性能是比较差的，无法直接做一些计算密集型的任务
比方说大量的分词运算、语料训练什么的，用ruby写是不行的
2．ruby的C扩展很难写
正因为ruby性能差，所以很多情况下要依赖C写的底层库，但是写ruby的扩展C库是很困难的事情。一方面没有特别多的资料介绍，你能参考的只有《Ruby Hacking Guide》，另外一方面Ruby是带有GC的语言，C又是没有GC的，所以如果你对ruby的GC机制没有特别清楚的了解情况下，写C扩展会出现意想不到的问题：比方说你写的程序逻辑没有任何问题，但是和ruby配合起来就会不定期的出现错误，这就是你C程序的某个赋值变量可能会被ruby GC以你意想不到的方式销毁。
3．ruby的C扩展库质量不高，容易出现内存泄漏问题
正因为上面的原因，很多第三方的C扩展库质量不好，很容易出现内存泄漏问题，这是一个很头疼的问题，你很难定位，也很难解决，只能尽量避免使用第三方扩展C库。
Rails的问题我觉得主要是：
1．特别容易出现命名冲突
你自己写的代码里面给类增加的方法，动不动就和Rails给类扩展的方法名称冲突了。这种错误很隐蔽，很难发现。这也是ruby语言动态性带来的一个负面影响
2．Rails每次升级API变动都比较大
Rails升级是不太考虑向下兼容性的，所以每次升级的话，可能你很多代码都要改，更糟糕的是很多Rails插件特别喜欢以hack rails的方式来扩展Rails功能，那么Rails一升级，插件的兼容性几乎肯定是不行的，这个是比较痛苦的事情。
3．Rails的view方面还是比较原始的erb拼接字符串方式，像JSP那样原始，没有一个类似Java的velocity/freemarker那样的页面模版库，所以写helper动不动要用字符串去拼html片断，如果是特别复杂的view需要拼的话，代码就会写的很丑陋。
当然总体来说，RoR还是让我感觉非常满意的，特别适合互联网应用。 从无到有刚开始做一个网站或者一个产品，要非常聚焦，没有旁的多余功能，只有一个做的极其牛X的核心功能，牛X到别人没有办法模仿你，于是网站开始崭露头角；
等核心功能成功以后，网站开始声名鹊起，为了扩展用户规模，产品开始多元化，各种各样时髦功能，各种各样用户要求的功能纷纷上马，于是用户规模开始快速扩张；
等用户规模已经起来之后，开始聚焦商业目标，于是删繁就简，开始砍掉与商业目标不符合的枝节功能，加强和商业目标符合的核心功能，网站进入健康的商业循环；
大部分网站都可以做到第一个阶段，但其中大部分都会倒在第二个阶段，而迈过第二阶段能够做到第三个阶段的就凤毛麟角了。到了第三个阶段，一个产品才真正开始成熟起来，才具有顽强的生命力，在IT垂直领域里面，JavaEye处于第二个阶段，需要向第三个阶段转变。
也曾经盲目的想把JavaEye的规模做到行业最大，于是上了各种各样的产品和功能，很多都没有细化和雕琢，现在想来都有些多余，而符合商业目标的核心功能又用力不足。现在总算想明白一个道理：规模最大又如何？还是不赚钱。所以接下来怎么做就很清楚了。
另外一条思路是做平台，互联网的未来生态系统肯定是由平台和内容提供商构成的，你要么做平台，要么做内容提供商。但在IT垂直领域，用户规模和市场空间过于狭小，平台没有足够的空间生存，所以这条路不通。不要企图做大而全的门户，不要企图做无所不包的平台。
定位好目标，不要做无关的功能，突出符合商业目标的核心功能和产品，足矣！
