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

程序员文章站 2022-03-30 12:49:19

...

回复内容：

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

科学计算领域需要大量矩阵运算，Fortran具有天然优势。曾将c++改写为fortran，那感觉真是酸爽，那一片片循环，全变成一行，可读性不要太好。你有class，我有module，科学计算并不需要多么高深的面向对象技术，除非你的目标是像OpenFOAM一样写个计算库。
多看看fortran最新语法，goto，do while之类的早就过时了。熟悉C系编程语言就难以接受 Fortran 的语法习惯，比如函数形参类型声明，和早期的C语言一样复杂，有点反人类

Fortran硬要说和哪门语言语法最像，那就是(Visual)Basic了，然而作为对VB有些好感的人，本人还是认为Fortran蛋疼，学完function就搁置了。

另外说明一点，我没有看不起Fortran，没有任何这个意思，不能否定它在科学计算上的伟大，而且按本人青睐长关键字的尿性(比如VB)，用Fortran替代C搞计算也是个长远打算，只不过是来吐槽下这个过程中遇到的困难吧

用Fortran，天在看，IMPLICIT留隐患。一句GOTO亲友散，非结构化天下乱。诚心诚念JAVA好，C和C+平安保。众生皆为Pylab来，Fortran险恶忘前缘。Python弟子道真相，卸掉Fortran莫拒绝。

上网搜九评Fortran有真相这是个伪命题。现有的底层工具已经比较全了，blas，lapack这些高性能数值计算库有了不需要重新写。尽管如此，开源的blas，lapack还都是fortran写的，每年也都在更新。
每个人处理数据的代码需要自己写，python这类脚本语言容易开发，还能通过numpy scipy调用blas库性能能接受。有多少组是专职更新blas和lapack，或者开发相应计算套件需要写fortran的？
但用python做前后文本处理的人多，不代表python的写个矩阵乘法就能超过blas。
最后，在模拟计算领域，要成大拿最后都得搞搞新算法新模型，并且集成到现有包里去。要这么搞就绕不开fortran以及他的历史遗留库。 Python就算了，在科学计算上Ruby真的没多少人用作为一个用过 Fortran 的 pgplot 库作死画图的人类表示；

让 Fortran 这么难用简直是超乎想象的系统工程，比如 mod 编译坑，变量声明坑，依赖链坑其实，学术圈也是一个市场，用的人少了自然是有个更好的产品。
最大的问题：Fortran不好维护，可读性差
- 代码风格千奇百怪
- 面向过程语言
- goto

且不说现在性能越来越不是问题了，就算于追求性能，C++一点不比Fotran差。
为啥还在用Fortran？
- 数值计算很多成熟的Fortran库，大家懒得换
- 课题组遗留代码懒得重写
- 商业软件二次开发大多数只有fortran接口一般的计算物理博士生，花三周学习fortran语言，三个月开发程序，三年进行科学计算。计算效率与开发难度孰轻孰重需要比较吗？
我想楼主说的越来越多的科学家使用Python、Ruby而非Fortran，可能只是楼主的个人体会而已。fortran在高性能计算领域的地位目前还是无可替代的。
更何况很多答主提出的fortran缺点有些片面：
1、代码风格与维护：implici规则，goto，common变量等语法早就不建议使用了，只是为了兼容性还支持而已。总有人喜欢拿以前的语法来说事。这就好比在今天拿出一部iphone1，然后批判说这手机一点也不好用，屏幕小速度又慢，怎么还有人说苹果手机好用。事实上，用fortran90以上的标准书写的代码还是比较好维护的的。
2、开发与计算效率：这一点无疑是fortran的优势,fortran学习难度比C低了一个档次，并且语法严格，对数组运算的支持十分强大，写数值计算程序非常爽。有人说C，matlab的效率也不低。我认为那只针对经过反复优化的代码，在用C和matlab时，稍微不小心效率就降下去了，而fortran代码的效率基本上取决于你的算法，完全针对代码写法的优化很少。
3、不支持面向对象：fortran目前支持部分面向对象功能，说不支持的多般半是fortran用的不多的。另外，面向对象这个功能在科学计算领域用的真心不多，一般把同一对象的信息封装起来就足够了，用不着多少高深的语法。看科学家对编程的需求了。数据科学的兴起让人们对数据挖掘和可视化功能要求越来越高，python好用，lib多，但就其内核而言根本没法控制memory，更深入的不是特别了解。
对于数值模拟，比较重视计算效率和可行性，对memory 的allocation甚至acccess都要严格的控制，相对更加底层。Fortran主要是之前有大量数值模拟code遗留下来，但是好多功能确实不太uptodate，function call对argument的数量都没有控制。感觉现在模拟方面c++是主力，strongly typed 有助于计算的严谨规范，美国劳伦斯伯克利国家实验室LBNL计算组的code是C++。只想说一点，基本数值库(blas, lapack等)的性能跟fortran没关系……fortran只是它们的接口语言而已。所有性能说得过去的实现应该都是汇编写的。

更何况C也是它们的接口语言，然后因为C是，所以所有正常的语言都能通过调用C接口获得性能的好处。

既然大家性能都好，为什么要去吃fortran的屎呢？

声明：本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系admin@php.cn核实处理。