Fortran 是一个应该得到恰当的荣誉并下葬安息的亡灵。只是，今日之学界中，这个亡灵喜欢跳出来诈诈尸，口中念叨着些咒语，大致是些“祖宗之法不可破”、“前人智慧的结晶”、“语法严谨、简单易学、运行如风”之类，听着让人心里发毛。就不多说这僵尸还诞下了一个名叫 IDL 的怪胎的事儿了，省得过分地得罪同行。
这里并不全是说 Fortran 本身的不好：C/C++ 中的未定义行为、泛滥的宏定义，也会坑得人生活不能自理。
更多的，是 Fortran 所代表的编程范式的问题，因为一门语言包含了它的编程范式。 Fortran 有编程范式么？若说有，那大概可以用这几个词来形容：粗暴、混乱、不计后果。这时，Fortran 的“语法严谨”便显得有些可笑：这反倒使得程序员不再小心谨慎，结果把自己陷入更多的坑中。
一旦一份代码用上了 Fortran，则往往意味着，这份代码背上了沉重的历史负担——你可以说它融汇了前人的智慧，但你更应该看到前人的局限，以及，由涓滴之流般的偷懒汇成的江河般泛滥的愚蠢和短视。所以，以下几个问题中，至少出现一个的几率，将变得非常大： 1. 更换平台编译时、编译旧代码时，动辄出错，且难以排查——很多时候是因为 gfortran 的 F77 兼容模式不能完全兼容某些写法，剩下则多是 ifort 和 gfortran （以及它们各自的用户）间的恩♂恩♂怨♂怨，少数时候是代码中调用的某些库的 API 做了个不痛不痒的改名；
2. 代码中有 goto；
3. 你会看到一个上千行甚至几千行的 subroutine/function； 4. 你会看到一个有一百多个参数的 subroutine/function； 5. 各种不知所云的变量名，以及完全无用的注释；
6. “if a > 0”？恭喜，编译错误，因为，“你那个 0 是个短整形，而 a 是个长整/浮点”； 7, 你得经常跑到一个函数的开头去看一个变量的定义；
8. write 的某个数字超宽了？恭喜你，你得到了一堆星号，谁关心你辛辛苦苦跑出来的数字去哪儿了啊——我当然知道这么做有它固有的原因，不过，这真是“时代的局限”五个字的最好样本之一；
9. 各种没有料到的惊喜，酸爽无比，把 least surprise 原则破坏殆尽。
最重要的，一份用上 Fortran 的代码，很可能有着根本没写过代码、速成培训后大干快上大炼钢铁的半吊子程序猿/程序媛——哪怕，他们可能是非常优秀的科研人员，他们的智商可能是我的两倍左右甚至三倍多，但是微信公众平台认证流程不会写程序就是不会写程序。
请看官不要说数组下标越界检查之类（在足够复杂的代码中几乎从未正确发挥过作用的）算不上优势的优势了，也不要抱着“Fortran 就是比 C/C++ 快、容易优化”、“Fortran 的数值计算库丰富、容易使用、高度优化”的迷思不放了。知乎上已有够多的人详细论证这个问题了，英文网站上相关的论述更是一挖一麻袋。
以及，最重要的，我一直认为，作为一份科研用途的代码，可维护性的提升比运行速度的提升，重要得太多太多太多太多了。平庸的运行速度，至多消耗了更多的机时——这在至今仍然日新月异地发展着的计算机那儿常常不是个事儿；低劣的可维护性，吞噬的则是科研中两样最重要的东西：一曰可重现性，二曰（有经验的）科研人员的生命。我承认，用 C/C++/Julia 仍然有一定概率写出难以维护的代码，但至少，客观上看，Fortran 带来的沉重历史负担，基本摧毁了”存在可维护性“的可能性；同时，Fortran 的低门槛，客观上使得太多人养成了大炼钢铁式的编程习惯，让很多原本可圈可点的代码落到最后臭不可闻。