为什么越来越多的科学家使用Python，Ruby而非Fortran

为什么越来越多的科学家使用Python，Ruby而非Fortran

需要强调的一点是， 语言只是工具， 在特定应用场景下满足特定需要的工具，
脱离应用场景来谈不但没有意义而且还会扣友善度。以下经验（吐槽）都是针对大规模科学计算的， 个人电脑写一个下午的代码，然后跑十分钟的代码趁早去用
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