笔者认为有以下几个方面：

一、 RoR的推波助澜

笔者认为，Ruby的成功，很大一部分是由于RoR的带动。

几年前，如果你没听过RoR倒是情有可原，但如果今天，RoR对你来说，还是一个陌生词汇的话，那你就有点危险了。:)

什么是RoR呢？

全称，Ruby on Rails，简称，RoR或者Rails。

它是个全栈的（full-stack）web应用框架，它为开发者提供了构建一个web应用所需的完整基础结构，并且严格按照MVC（模型-视图-控制器）架构进行开发。

RoR致力于提高开发者的开发效率，希望通过尽量少的代码，完成尽可能多的功能。基于这样的考虑，RoR有两大设计原则，一是，不要重复自己 （Don''t Repeat Yourself）；二是，惯例优于配置（Convention Over Configuration）。

使用RoR，你甚至可以通过简单的几条命令行、几行代码，就完成一个功能强大的web应用程序，这极大地提高了开发者的开发效率。

2004年7月，RoR一经发布，在短期内，便受到很多开发者的追捧。时至今日，RoR已经被全世界的开发者们所关注，它带给开发者的效率提升，是前所未有的；它带给业界关于软件开发的思考，也是意义深远的。

在RoR如此风行的大背景下，Ruby on Rails，这个需要使用Ruby进行开发的web框架，也自然地带动了Ruby语言的发展。

在下面的“Ruby语言受关注程度趋势图”上，可以清晰地看出，Ruby语言在RoR发布也就是2004年7月后，进入了高速发展期。

Ruby因为有了RoR这样的“杀手级”应用，变得春风得意，那么Python呢？

在《浅谈Python语言》一文中，我们提到了Python具有丰富的API库，在web开发方面，也有Django、Turbogears这样的一些框架，就运行速度而言，

Python比Ruby快；就社区而言，Python也比Ruby成熟，可是为什么Python没有产生一个像RoR这样的“杀手级”应用呢？

Python语言的创始人Guido在接受InfoQ采访时，是这样解释的：

“我不喜欢Killer

Application，因为那会让多数人或者社区将精力集中于一个地方。Python是一个应用广泛的语言，基于Python已经产生了很多好用的

Web框架，比如Django等。但是Python不Killer

Application，至少目前是这样，而且我相信随着Python社区的发展，会有很多Killer

Applications自然出现。我喜欢多样化的应用。”

通过这个观点，我们可以看出Python在其发展道路上，追求的是一种均衡，一种“大而全”。

“会有很多Killer Applications自然出现”，这点，我想我们需要拭目以待。单就“均衡”而言，笔者认为这很危险，作为一门脚本语言，试图做Java之类传统语言做的事情，不太可取。

以Java为例，在web应用上，有太多的框架可供选择，不错，“在不同的场景用不同的框架”，这想法很好。可是，在实际应用中，有多少开发者可以根据项目特点，正确、合理地选择框架？

与其到最后，用户还不知道该如何选择，还不如一开始就替用户做出一个选择。

作为Python的使用者，我更愿看到有个Python的“杀手级”应用出现，进而带动Python更快速地发展。

你可以说RoR成就了Ruby，可是Rails为什么偏偏选择了Ruby？！Ruby优势何在？

二、 Ruby的优势

1. 比Perl更强大，比Python更面向对象

“比Perl更强大，比Python更面向对象”，这是Ruby创始人Matz设计Ruby的初衷。

Python既支持面向过程的编程也支持面向对象的编程，而Ruby则是完全面向对象。

在Ruby中，任何东西都是对象，包括Python中的基本数据类型；每个过程或函数都是方法。

例如，取-3的绝对值，在Python中，是这样的：abs(-3)。

而在Ruby中，则是这样的：-3.abs。这种OO的方式，显得更加直观。

2. 强大的语法功能

单就语法的简单性而言，Ruby不及Python。但解决一些较复杂的问题，Ruby强大的语法功能，有助于降低问题的复杂度。

例如：

Ruby以“块”的方式来实现列表内的条件、循环语句，比Python的更灵活、更具通用性。

Ruby具有类似Lisp的彻底的函数方式的条件、循环语句等。

Ruby的迭代器功能可以将流程控制结构抽象化。

3. 强大的字符串处理、正则表达式功能

Matz认为：Ruby >(Smalltalk + Perl) / 2。

Ruby类库是对Perl语言功能的面向对象方式的重组，因为借鉴了很多Perl的东西，使得字符串处理、正则表达式这块，Ruby同样强大。

4. 不会僵住的“胶水语言”

同样是“胶水语言”，Ruby比Python更灵活。

使用过一段时间的Python，你会发现，Python比较依赖第三方的东西。相比较，Ruby则更依赖自身。例如，Ruby可以使用（UNIX的）绝大部分的系统调用，单独使用Ruby也可以进行系统编程等。

有优势，Ruby就一定可以成功了？Python同样也有很多优势！对，还得看当时所处的环境。

三、 时势造英雄

这点还得回到RoR的崛起。

Ruby，1995年12月正式发布，2000年进入美国；2004年7月，RoR正式发布。

RoR的出现时间，值得玩味。

在下面的“Java语言受关注程度趋势图”上，可以看到，2004年7月前后，Java处于一个相对“衰退期”。

提到Java，大家应该都会想到J2EE。

J2EE应用程序的广泛实现是从1999、2000年开始的，它的出现带来了诸如事务管理之类的核心中间层概念的标准化，但是因其开发效率、学习难度和实 际性能的问题，在实践中没有获得完全的成功。作为J2EE核心技术的EJB（2.x），更是因其高昂的学习代价、极低的开发效率和极高的资源消耗，备受指 责。

在这样一个大背景下，2003年，Spring框架诞生了。

Spring的设计思想在于“使J2EE开发更加简单”。这个设计思想，在包括Java领域在内的众多软件开发领域引起了广泛关注。软件开发者们开始思考，如何让开发向着一个更简单的方向发展。

RoR在这一时期出现，无疑是顺应了这样一个潮流。

可以这么说，是历史选择了RoR，当然也选择了Ruby。

遇到合适的机遇，还不够，俗话说得好：“众人拾柴火焰高”。

四、 众星捧月

Ruby的出现，受到了两大主流平台Java和.NET的极力追捧。

2006年9月，SUN雇佣了JRuby的主要开发者Charles Nutter和Thomas Enebo；一年不到，2007年6月14号，JRuby 1.0正式发布。SUN在其Java IDE NetBeans 6.0 M10中，更是集成了对Ruby/JRuby的支持。反观Python的Java实现——Jython，则没有这么幸运，发展至今，它并没有得到SUN的 支持。

而Microsoft，也在2007年7月，推出了Ruby的.NET实现——IronRuby的预览版。

相信SUN和Microsoft对Ruby的竞相推崇，必然推动Ruby的进一步发展。

基于以上几点，笔者认为Ruby的成功不是偶然，并且相信这样的成功还会持续下去。对于Python的未来，我们也将拭目以待。

脱离应用场景来谈不但没有意义而且还会扣友善度。以下经验（吐槽）都是针对大规模科学计算的， 个人电脑写一个下午的代码，然后跑十分钟的代码趁早去用

Python/R/Matlab/Ruby， 上手容易， 功能强大， 网上资源丰富， 绝对是您无悔的选择。

大家的难用都是从

fortran77那里感受来的，看过80年代的Fortran77代码，混乱程度简直爆表。再看2000年左右的Fortran95代码，马马虎虎，

算是中规中矩的结构化语言。最近看过2010年左右的Fortran2003 code（Fortran的lua接口）

。抽象类，构造函数满天飞，我擦好多feature都不知道。

所以你们批判的不是Fortran， 而是任性的，非结构化的coding

style。这不过恰巧搞科学的这票人都不太鸟coding standard和coding style，

所以Fortran写出来的代码大都比较乱， 这是使用者自身需要学习一个， 跟语言本身关系不大吧。见过师弟师妹们写的C代码，

比Fortran版本的还魔幻。

而C和C++里面也有goto， 也有extern可以不做函数参数参数检查，倒是没见你们怎么喷。Fortran里面也有interface来声明函数原型， 倒也没见你们怎么用。

比

如elemental， pure， 函数重载， forall， where，

Fortran95新加的功能一大部分是为并行度设计的，其语法也非常偏向高维的大数组操作， 自动并行化（openmp

workshare）用起来简直比C++爽不知道多少倍。在OpenMP+MPI的场合加上千核量级的并行度，还是有优势的。还有一种东西叫CAF，

CoArray Fortran， 专门针对大并行度的超级计算机添加了很多新语法，估计知道的人不多。

更不要说Fortran2003/2008支持面向对象。当然在虚函数方面好像比C++缺了一个功能， 其他都是完整复刻的。

所

以真要批判， 请先看看Fortran95/2003/2008在来批判， 哪怕只看目录或者Feature

List也好。真正值得喷的是Fortran95里面的module的mod file的依赖问题， 写Makefile很麻烦，

还有就是输入输出功能太弱， 必须要靠lua，hdf5，netcdf， json这些第三方工具来支撑。

至少说，只要不用implicit，Fortran编译的时候可以精确地告诉你哪一行有问题。（对，我就是说给C++党的， 最近做习题被虐的不要不要的）

如

果要用心做好一个代码， 并行度在几千CPU核心的量级上， 有核心维护团队， 用户在百人千人量级上的话，正确的姿势是，

Fortran负责运算密集部分， C++/C负责常用逻辑和接口，

python/ruby/lua负责做胶水，负责暴露给不太关心细节的终端用户。这套东西199几年就有人在做，

结果到现在大家还在吵哪一个更好的问题。

-----2016-02-07 补充-------

获悉Fortran2008里面终

于对变量声明坑进行了修补， 在2008之前的版本中， 变量只能在函数的开始部分声明， 实际的声明语句可能距离使用语句较远，

同时可能引发临时变量误修改的情况， Fortran2008内加入了BLOCK结构， 可以当地生成临时变量，

并显式指明生存期，即使在BLOCK内部使用goto强行跳出， 编译器也会释放临时变量，即

module m

implicit none

contains

subroutine test1(a, b)

integer，intent(in) :: a

integer, intent(out) :: b

....（执行语句）

TMP1 : BLOCK

integer :: temp_var

temp_var = a*b

a = temp_var

END BLOCK TMP1

....（执行语句）

end subroutine test1

end module m