我认为fortran的使用在慢慢变少，在科学计算领域的新软件中已经成为从属语言。现有的新的fortran代码的产生完全是历史原因。如果我现在要开发一个新的数值计算项目，可以自由选取语言，我会在c++，python和matlab中选一个。如果开发效率重要，我会选python/matlab。如果计算效率重要，允许慢慢开发，我会选c++。如果计算效率很重要而开发时间短，我会考虑用python/matlab起框架，然后profiling，把耗时的计算步骤用c++封装。想要理解这个问题，我们就要理解人们为什么会选择其他的语言。
我使用过basic, fortran, c, matlab/octave, c++, 以上按照接触到的历史顺序。了解R和Java，最近在努力学习python。从大一学fortran到现在已经十几年了。fortran写过大概4万行，用c++在openfoam上写过5万行并且开发过新的库(library)，matlab写过大约一万多行。这三种语言都很熟。OOP(面向对象编程)也大量使用，所以我相信我有资格做一个比较。我就介绍一下我以前碰到的情况，以及我对语言的选择。有些是成功的例子，更多的是各种坑。从这里你可以间接的看到fortran语言的优劣，以及现在市场份额变换的原因。
我的经验是，没有一个语言能够在所有的应用领域中占有优势，没有一个语言能够在所有的比较指标中占有绝对地位。所以作为开发者有必要了解尽可能多的语言，当有自由选择条件的时候，选择最适合项目的语言。(注意前提是有自由选择条件，另外计算快的语言并不一定是适合项目的语言)
一个数值计算项目的开发可能涉及到三个抽象层面。最底层是一个特定数值算法的开发。表现在开发后的交付物(deliverable)是一个函数(结构化编程或者过程式编程)或者是一个类(面向对象编程)。中间的抽象层面是库的开发，表现在交付物是一堆紧密关联的函数或者类，用户使用的时候会先编译成lib文件(后缀a so dll 之类)。最高层面是求解器或者叫应用，表现在调用库文件，交付物是可以编译成可执行文件的代码。影响我选择语言的原因有以下几个：
(1)数值性能不是选择语言的唯一标准。在这三个层面的开发中，即使是针对数值计算，在数值上的性能都不是唯一的影响因素。IO，字符串的处理能力对于新的科学计算软件开发都很重要。
(2)越向更高的抽象层次发展，对计算性能的要求就越低，对编程语言处理抽象问题的能力要求就越高。只有问题被抽象化，才能提高可维护性。这也是为什么c++现在越来越流行。
(3)即使是数值性能是最重要的参考标准，人为编程的影响都远大于程序语言的影响。再牛的编程语言都无法阻碍程序员写垃圾程序。我看到的做数值的很多是半路出家学编程。大家对于编程的态度跟计算机方向的程序员是有本质不同的。就像理工科学微积分，而数学系学数分一样。关注点不同而已。有几个学习fortran编程的人在写第一个多重循环的时候会关心多维数组的内存排序这种情况下fortran的计算性能通常不会最大限度的发挥。
(4)在新的模型或者算法的开发中，快速prototyping是至关重要的。这个时候，首先关注的是有效性，其次才是效率。这也是为什么python和matlab可以占有重要的地位。这两种语言作为解释性语言，最大的特点就是开发快。而且测试算法的复杂度跟语言无关。
(5)可以使用的已有代码。这个才是导致fortran至今还占有一席之地的最大原因。大量已有的库或者计算软件是fortran写的。这个情况在改变。
讲一个自己的例子，2011年的时候我们的模型在应用到一个新领域的时候出了问题，模型是用fortran写的大大小小几千行。我自己大概能猜是哪个地方出了问题，但是不能确定。于是我假设那里出的问题，想了一个不错的idea，但是不知道能不能成功。我当时把出问题的数据从fortran写到硬盘上，再读到matlab里，用matlab实现了我的idea，编程耗时1个小时，matlab计算耗时1个小时。经测试发现我的新方案竟然解决了问题。于是老板同意在fortran上改，编程耗时1周，计算耗时5秒。提问：如果我一上来就耗时1周改fortran代码，结果发现没有解决问题，老板心中会想让多少只草泥马从我身上踩过/p>
2012年的时候给一个古董级的40万行的fortran计算流体软件做项目。软件开始于1970年代，这个软件至今还有一个十几人的全职团队在上面做开发。我当时想让程序再输出几个流场信息，于是信心满满的打开write_fields subroutine。瞬间看到满屏的goto，不下100个。立刻退出vi，假装平静的走出办公室，确认我没有怀疑人生。。。
还是上面的这个古董。加上我的组件后，开开心心的设置了一个算例。结果在1000K煤的炉子里几秒钟就算出了-100K。再次怀疑人生。一周没有查到错误原因。直至我把我加的组件删掉，同样的错误再次出现，才开开心心的把bug提交给软件开发团队了。对方团队的一个核心开发人员用了整整8小时才查到错误原因：当一个软件支持但不常用的选项打开后，温度module里的温度场被另一个module里的一个不经常被调用的函数悄悄的改了。。。
fortran大程序难维护可见一斑。我偶尔也会做一些反其道的作死节奏，提几个fortran的坑吧。
(1)2012-2014年间使用intel fortran 编译器编写使用了fortran2003标准语法的程序，主要是想骚一下OOP的新语法。当时知道fortran编译器对标准的支持比较慢所以才特意限制在了2003标准而非2008标准，当时最新版本的ifc声称支持全部2003语法。结果经常出现一个符合新语法标准的语句编译报错。我甚至遇见了好几次intel 编译器自己segmentation fault。是的你没有看错，是编译器崩溃了，而不是我的程序。然后不停的追查原因，不停的尝试更小的例子直至找到不被支持的语法的MWE(minimal working example)。经常查到原因后在网上搜索解决方案时发现几个月前有人报告intel官网了，解决方案是升级编译器到最新补丁或者等下一个补丁。这种事情发生了三四次，导致在这两年间我不得不一直使用最新版本的ifc。稍微再复杂一点的数据结构，比如封装一个pointer list，每个pointer指向一个基类的事情根本无心试验。而这种功能在c++中已经被广泛使用了十几年了。最后发现我在查找编译器错误上花费的时间已经超出了我在自己的程序上花费的时间，完全本末倒置了。从那一刻起我再也不愿意使用fortran的OOP功能了。我使用编译器是为了完成我的工作，而不是志愿测试编译器。
(2)fortran二进制文件总是能给你带来惊喜。如果你从来没有见识过一个fortran生成的二进制文件的内容，你可以写一个小程序把一个double precision的数组写到一个二进制文件中。然后用一个高级点的编译器以16进制方式打开。我保证不管你脑子里预想的是啥样子，你打开的都不是你想的那样。PS，现在有多少人知道big endian和small endian/p>
(3)fortran的字符串处理能力真是让人痛不欲生。
文章知识点与官方知识档案匹配，可进一步学习相关知识Python入门技能树首页概览212702 人正在系统学习中 相关资源：基于WinCC组态软件的加热炉炉温优化与仿真研究_winCC实现加热炉…
来源：莫博之
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！