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