和 C++ 相比，用 Fortran 編程是怎樣的體驗？

01-14

流體力學學生，這學期編程都要求用 Fortran，可我還不會……

體驗。呵呵。體驗。

我因此砸爛過一支鍵盤。具體情形，請參照「德國 boy」相關視頻，自行腦補。

哪怕知道可能要因此遭受一些人蔘公雞，我也還是來學王垠，開一發地圖炮吧。

特別聲明，以下內容基本都是調侃和玩笑，請看官不要太認真；特別地，這些問題，很大程度上是學界的代碼開發模式的問題，Fortran 不過是這些問題的一個替罪羊罷了。

開噴。

Fortran 是一個應該得到恰當的榮譽並下葬安息的亡靈。只是，今日之學界中，這個亡靈喜歡跳出來詐詐屍，口中念叨著些咒語，大致是些「祖宗之法不可破」、「前人智慧的結晶」、「語法嚴謹、簡單易學、運行如風」之類，聽著讓人心裡發毛。就不多說這殭屍還誕下了一個名叫 IDL 的怪胎的事兒了，省得過分地得罪同行。

這裡並不全是說 Fortran 本身的不好：（被這幫人視若無物的）C/C++ 中的未定義行為、泛濫的宏定義，也會坑得人生活不能自理。

更多的，是 Fortran 所代表的編程範式的問題，因為一門語言包含了它的編程範式。 Fortran 有編程範式么？若說有，那大概可以用這幾個詞來形容：粗暴、混亂、不計後果。這時，Fortran 的「語法嚴謹」便顯得有些可笑：這反倒使得程序員不再小心謹慎，結果把自己陷入更多的坑中。

一旦一份代碼用上了 Fortran，則往往意味著，這份代碼背上了沉重的歷史負擔——你可以說它融匯了前人的智慧，但你更應該看到前人的局限，以及，由涓滴之流般的偷懶匯成的江河般泛濫的愚蠢和短視。所以，以下幾個問題中，至少出現一個的幾率，將變得非常大：

1. 更換平台編譯時、編譯舊代碼時，動輒出錯，且難以排查——很多時候是因為 gfortran 的 F77 兼容模式不能完全兼容某些寫法，剩下則多是 ifort 和 gfortran （以及它們各自的用戶）間的恩♂恩♂怨♂怨，少數時候是代碼中調用的某些庫的 API 做了個不痛不癢的改名（沒錯 fftw 我說的就是你）；

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 的數值計算庫豐富、容易使用、高度優化」（我真的不信有啥東西的優化的高度能比過 -O3 下的 STL）的迷思不放了。知乎上已有夠多的人詳細論證這個問題了，英文網站上相關的論述更是一挖一麻袋。

以及，最重要的，我一直認為，作為一份科研用途的代碼，可維護性的提升比運行速度的提升，重要得太多太多太多太多了。平庸的運行速度，至多消耗了更多的機時——這在至今仍然日新月異地發展著的計算機那兒常常不是個事兒；低劣的可維護性，吞噬的則是科研中兩樣最重要的東西：一曰可重現性，二曰（有經驗的）科研人員的生命。我承認，用 C/C++/Julia 仍然有一定概率寫出難以維護的代碼，但至少，客觀上看，Fortran 帶來的沉重歷史負擔，基本摧毀了」存在可維護性「的可能性；同時，Fortran 的低門檻，客觀上使得太多人養成了大鍊鋼鐵式的編程習慣，讓很多原本可圈可點的代碼落到最後臭不可聞。

我心目中的」優秀代碼「，也算是有個參照標準的——比如，Linux 內核。它固然有過並有著許許多多的 bug，可是它是一個龐大卻可以維護的系統。如果 Linux Kernel 是荷馬史詩，那麼，那些（以 Fortran 為首的）科研所用代碼，至多只能算是《尤利西斯》了。

然後，是的，我知道孤證不立，我知道有人喜歡噴「這是邏輯錯誤」，也有人會講另一面的故事，但我還是要講故事。

我剛到某屯搬磚的時候，與一個師兄合作，用上一份叫做 Pinocchio 的代碼（PINOCCHIO Home Page）。這份代碼是用來模擬星系團尺度上的暗物質演化的，使用微擾論替代直接求解 N-S 方程，使其可以在小計算機上跑出效果還不錯的大尺度結構模擬。首先，花了一個周末，這貨才能被成功編譯，原因是 gfortran 不接受某些 ifort 的寫法——這還不是整形長度之類的細節，而就是關於某些日常用法的語法不一致——以及 fftw 更改 API 的坑。編譯成功，隨即跑了個 $500^3$ 的，looking good。接著，就遇上大坑了。我們需要 $1500^3$ 的解析度，可一把邊長設置為 1500，程序馬上就崩潰了。整形溢出。那好說嘛，把數組指標改為長整型不就得了——當然不，這樣更改後的代碼，同樣跑 $500^3$ ，得出的結果與數組下標為普通整型時不！一！致！（固定隨機數種子之後，這個代碼每次得到的結果是完全一樣的）調了整整一周，毫無進展。決定暫時不管那麼多，先跑 $1500^3$ ，跑完後，看到輸出數據裡頭一堆 *****（輸出超寬），心都碎了……

以及，我要噴我最想噴的貨色：Enzo（The Enzo Project）。正是這個奇葩，讓我失去了對天體物理 simulation 的幾乎所有興趣和信心。雖然這個 code 的 C++ 部分也很爛，但 Fortran 部分更是坑得人生活不能自理，最後便合成了一篇集 C++ 和 Fortran 爛法之大成的東西。

就在前不久，我這個 rotation 項目都快結束了，還被它給坑過。我那位 rotation 老闆在二十年前為此寫過一個模塊，用 F77 寫的。時至今日，他一直以為該模塊在此程序中發揮著巨大的作用，直到我發現，調用這個模塊的部分，被人注釋掉了。他頓時花容失色，令我重啟該調用，卻發現巨量無法修正的編譯錯誤——是的，gfortran 的「兼容模式」下支持的 F77 已經不是他當年那個 F77 了。老闆長嘆一聲道，幸好我後來用了 C++……

然後，再來看點兒來自 enzo 的酸掉你大牙的東西，F77 和 F90 都有。比如，這個宏偉的參數列表：

以及前一個函數在 C++ 中的調用，是不是感受到了一種靈壓：

這個賦值方式真是不錯：

此朵數組的眼神，憂鬱得讓人蛋疼：

Fortran，Let"s GOTO places（廣告語原句：Toyota, let"s go places）：

當然還有很多 crap，比如：

現在的計算機，緩存都已經夠大了；函數調用帶來的開銷，早都是零頭了；還在以這種手段拚命避免函數調用，簡直就是防止他人維護，良心大大的壞了。若是用 cpp 寫個 class，也能省得一不小心寫錯一個參數的位置啊——面向對象再是大坑，至少能讓人們有一個靠譜的 namespace 可用（F90/95 的命名空間？呵呵）。

就那種可維護性，算得再快，又能怎樣？

最後，私貨。

高德納（曾經記成 RMS 了，感謝糾正）：「過早的優化是萬惡之源」。我得加一句，「自以為是的優化是萬惡之源」，包括在今日仍然堅持使用 Fortran 開發新項目。

人在做，天在看，implicit 留隱患；

GOTO 一出親友散，非結構化天下亂。

誠心誠念 CPlus 好，抓緊重構滅退保。

眾生皆為數值來，Fortran 險惡殺時間。

CPlus 弟子說真相，教你脫險莫拒絕。

天滅 Fortran，快看 Julia！Numpy/Scipy/Cython 墜吼！Haskell 賽高！

全世界被 Fortran 坑過的人，聯合起來！Fortran-sufferers of the world, unite!

簡單點評一下Fortran歷史上幾個大的變化：

FORTRAN 77的可讀性很差，很多作者都提到了。我讀過不少FORTRAN 77格式下的源代碼，例如著名的FEAP 8.3. 真是要了命了。

Fortran 90之後略好，但不支持OOP。出現了module，類似於C++的namespace，如果好好安排還是可以讓一組程序顯得很有序。

Fortran 2003之後支持了OOP，但各種IDE對Fortran 2003之後的支持都很糟糕。

我自己的感覺是這樣：C++肯定是很好的，但需要非常用心的學習，C++就好象是一把瑞士軍刀，用C++干Fortran擅長的科學計算，需要好好學一些更深層次的東西，否則計算效率一個疏忽就下來了。這就引出一個挺尷尬的事情，一些工科專業由於學時和師資力量，暫時還提供不了很專業的指導老師來指導科學計算的程序設計；而計算機系一般也不會有針對科學計算的課程。

我自己的經歷是，本科時候所謂的「學過」C++。讀博的時候學的Fortran，感覺上手很快，且一些自帶的數學函數（尤其是關於向量矩陣的）很好用。由於導師的安排，我自己開發了一個通用有限元程序，代碼量10萬+，包含代碼4萬+，注釋4萬+，其餘1萬+空行。又用C++基於Gmsh（基於FLTK庫）開發了一個簡單的界面。對自己的Fortran的評價是：能規避包括很多答主提到的Fortran的各種奇葩的限制，能儘可能提高程序的可讀性，能運用簡單的OOP的思想儘可能提高程序的可維護性、可延展性。我組裡的同學拿了代碼之後很快就能上手，也算是一個小的佐證。

---

曬一下代碼風格吧，給從事科學計算的朋友一些Fortran 2003/2008的感覺。這個類的定義很簡單，存儲的是系統的wall time，用來計算一個FEM model的運行時間等。

這個是文件頭注釋：

這個是Fortran裡面一個類（其實還是用的自定義數據結構type來實現，只是增加了type-bounded subroutines）

這個是type-bounded subroutine的具體函數體（部分）：

你們來感受一下 VASP 裡面一個普通的函數調用（VASP 的文風算好的了）

既然發在CFD標籤下，我轉載一個。下面是OpenFOAM創始人Henry weller的口述：

CFD界：你為什麼選擇C++開發CFD代碼而不是FORTRAN？

Henry：在1984年本科之前，我最開始的時候從Basic語言學起，然後轉移到Pascal和C。在我的論文里我使用FORTRAN-77，不得不說，這實在AWFUL！！！太差勁了！C和Pascal比FORTRAN-77會好一點，實際上在1960年ALGOL-60問世之後，FORTRAN就差不多廢棄了。

當我開始我的CFD研究的時候，我拿到的代碼是一堆不能編譯的令人費解的FORTRAN-77代碼。在我學習了幾個月之後，我認為我可以玩的更好。在1989年，我接觸到了C++，並立即看到了對象起源編程的優勢。從那時起，我就開始用C++設計FOAM。然而，在那個年代，C++剛剛問世，並且編譯器VERY脆弱甚至不能工作。慢慢的我認識到泛型編程（Generic Programming）對操作場、矩陣、方程等是非常有必要的，在C++模板問世之前，我就使用C方法、宏和腳本得方法來實現。在C++模板問世之後，以及gcc編譯器的發布，我把我之前寫的代碼用C++模板重寫，這就是OpenFOAM的前身。

當然了，FORTRAN不能做這些。不過FORTRAN-90有一些面向對象的能力，但是它完全沒有泛型編程的功能，據我所知，FORTRAN以後亦不會添加泛型編程的概念。基本上，我個人認為FORTRAN語言快要廢了，在1960年那時候就應該埋在土裡了。目前使用FORTRAN的人大部分是由於歷史原因，只為了新代碼能和非常久遠的代碼兼容。

FORTRAN和C++都因為「為了和過去兼容」而有一些致命的缺點。FORTRAN為了和FORTRAN-77兼容，C++為了和ANSI C兼容。然而最大的區別是，ANSI C本身就是一個非常好的語言，FORTRAN可不是。

在未來，我希望C++被一個更乾淨、簡單、有力的語言代替，這個語言需要支持泛型編程，這對OpenFOAM以及其他相類似的代碼非常重要。我一直關注編程語言的發展，我認為C++的可能的代替品有Nim，Rust以及Chapel，然而目前這些語言缺少一些我需要的必要功能，添加這些功能，比如C++中的高度的泛型編程概念，可能需要很多年。我希望他們在若干年後添加這些特性。同時，C++的缺陷需要妥善處理。在C++17中，我希望「概念」（concept）和「模塊」（module）特性會被加入，所有的C++編程人員都會受益。

額，這個問題我想說的太多了，尤其是關於C++的缺陷以及我對未來編程語言的期望。這越說越遠了，就這樣吧。

全文將在下周五發布在：

http://weixin.qq.com/r/90MNFf3EDaByrbl29xbl (二維碼自動識別)

Live and breath CFD

CFD界

讀博以來做的最正確的事情是花了兩個月用c++重寫了一遍組裡的遺產fortran代碼。

Fortran遺產代碼多數是F77.畢竟在F90逐漸流行的年代C++已經很流行了，沒多少人在那個年代開新項目會堅持選擇Fortran。

F77的噁心寫法在高票答案基礎上再提幾個，比如

implicit type，某些字母開頭的變數默認某類型

common block ，

global constant

直接導致程序結構失去控制，沒有清晰的進入和退出點，數據交換也是一團亂。

F77的另一個噁心之處是由於以上缺點導致的程序結構一團亂，就算想把功能分離出來寫個wrapper然後在c++里調用都很難。

新標準F2003/2008號稱也可以做OO但是寫起來實在是非常噁心，跟c++11比起來差太遠了。編譯器、開發工具也沒有很快跟上。

最後說一點，現在已經很難找到靠譜的免費Fortran編譯器了。gfortran對f77、f90/95我都遇到過加某些選項出現很奇怪的行為。

要是買ifort、pgi fortran，也很難保證在十年這個尺度上的靠譜。

我的手機解鎖畫面上寫著 implicit none

別問為什麼，這是一個傷心的故事

說到畢設，我的也是改導師的程序的一個模塊的代碼，他所有字母全部是大寫。。。那酸爽。。。。。

更新：

common和equivalence簡直是一坨一坨翔

幾點看法更新

= 注意，本人不是挺fortran，而是討厭一些人的無腦噴。本人目前也較少使用fortran。

參數多的問題。參數多是蠻恐怖的，為啥不封裝以下嘛。你要知道，很多代碼開發時，只有f77是最好的數值計算程序語言，c語言都沒發展利索呢。不要嘲笑郭大俠不會用巴雷特。此外，參數多比無腦封裝要好！動不動就搞個class封裝，看起來很美而已，其實沒有什麼卵用。原汁原味的自變數-因變數是基本的基礎構件，具備更大的靈活性。你把一切都封裝了，結果發現最後是作繭自縛了。這不是c++使用者獨有的毛病，我用fortran也犯過type滿天飛的錯誤。科學計算有時候就是這麼難以把代碼寫漂亮，複雜性總是沒法避免的。
遺留特性問題。goto，implicit申明，equivalence……。這都是歷史遺留特性，不鼓勵使用。c也有goto啊，c++還能 &與&混用。別拿這個來黑，顯得big太low。
使用c++最大的誤區之一是：過早陷入設計，整出一大堆類和複雜繼承關係，最後把自己和別人暈死。想想，自己把大多數時間用在了搞類關係上了，你有多少時間考慮計算效率與物理原理？
我目前比較喜歡C99搭建基礎構件，而後用c++或者python配合其自身高階數據結構來實現上層複雜邏輯。
在目前異構體系下，C99的優勢比C++顯然更大。
請讀為什麼我時不時會看到「珍惜生命，遠離 C++」?

--------------------------------------------------

我大學上課學過F77，看不上，自學了C以及C++。一段時間是C++的粉絲，狂扁fortran。
但是，後來工作了，卻用fortran更多，也發現了fortran的優點。
所以為FORTRAN辯護一下吧

1 不要用fortran 77的標準來評價現在的fortran。確實f77有許多蛋疼的規定，居然沒有自定義類型，動態開闢空間也沒有，全局變數也沒有，需要用公共塊這種醜陋的東西做全局數據共享，更不必說goto還被作為一種常用語句。但是要知道這是70年代的標準，也就是說其基本規範比77年還要早不少。那時候，C還沒影子。80年代標準的C要是沒比F77強那真是沒臉見人。但是，f90,f95,f2003,f2008甚至f2015標準，推得還是很快的。目前的標準可以說相當不錯了。

2 爛程序員用什麼語言都爛。自稱c++程序員，難道素質就一定高？？好程序員寫的fortrtran代碼絕對具有良好的設計和風格。當然問題是，fortran有許多歷史包袱，那些古老風格的代碼在今天的人看來糟糕透頂了，但是在當時可能是上乘之作，比如blas,lapack之類現在還是標準。嘲笑那些古老代碼爛，好比嘲笑老學者不會用鍵盤打字。

3 我所認為的現代fortran的優點：簡單易學，強大的多維數組功能，簡單的動態空間開闢。這三點其實時針對C/C++的缺點而言的。
c++確實很麻煩，功能太多，語法複雜，陷阱很多。多維數組及其動態開闢一直是個麻煩。相比而言，fortran實在是簡單多了，可以很快入門。C也比較簡單。
多維數組，在fortran裡面有豐富的功能，c/c++裡面？數組就是數組，而且還是二等公民。
動態開闢，特別是多維數組的動態開闢，fortran裡面就一句話，c/c++裡面就算是2D的也麻煩得很。別提那些用vector&搞的東西，又慢又丑，沒法和fortran比。
c++確實強大，但是好的c++程序員很少，科學計算領域的好c++程序員更少。我剛工作時，在一個小公司主管一個項目，技術方案上我說了算，因此我推c++開發。結果是組裡5個人，能用c++的也就一個半（包括我自己），於是大多數c++編程的活都是我幹了。

4 fortran的缺點，我覺得主要有一個：缺乏豐富的標準庫。雖然資源很多，但是都不是標準強制的。

說點 Fortran 行而 C++ 不行的。

隨手可用的多維數組。多維數組的支持在 Fortran 中是內建於語言中的，地位很高，相對而言，C/C++ 中的所謂」多維數組「只不過是」數組的數組「而己，C++ 中用模板搞出來的」多維數組「也差不多。Fortran 中可以隨手寫 A(:, 1) A(2, 得到第一列或第二行，C/C++ 中的 A 可沒辦法 A[:][1]. 從這取下標就可以看出來，Fortran 中的取下標是一個整體，而 C/C++ 是分成了兩個方括弧。
模塊機制。與模塊相聯繫的是類型檢查，這對於保證程序正確性很重要。早期的 C 跟 FORTRAN 一個德性，都是把函數返回結果聲明一下就了事。到了 ANSI C 時有了函數聲明，可以輔助類型檢查，可沒多久的 Fortran 90 也有了這些，還有更多。C 語言中包含頭文件的主要作用之一就是保存函數的參數與返回值信息的復件（函數聲明），這是需要手動維護的。頭文件的方式極為原始，而 ++ 為了兼容 C 也只能用頭文件，而不是更先進的模塊機制，這是 C++ 甩不掉的大包袱。

這兩點是我選擇現代 Fortran 而不是 C++ 去寫數值程序的重要考量，使我在沒有歷史代碼包袱的情況下仍然選擇了 Fortran.

對於答主我有一個建議，如果學 Fortran 一定要學現代的 Fortran 而不是 F77. 去找一本新一點靠譜點的 Fortran 書，裡面寫明了 deprecated 的技術都別用。ANSI C 跟 Fortran 90 可差不多是同一時代的啊，為什麼還要非得去學古老又落後的 F77 呢。

現代 Fortran 規範的趨勢是更為嚴格，更趨向」用戶友好「而不是」接近底層「。如 intent(in) 聲明，就聲明了一個變數是傳入變數還是傳出變數，給編譯器提供了更多的信息。連 f2py 都可以利用這個信息，可以直接由 Fortran 代碼直接生在可以在 Python 中使用的 .so, 跟 numpy 數組良好地交互。除此外還提供 pure, elemental 等修飾關鍵字，限制程序的副作用，更為嚴謹。

用戶友好方面的差別也明顯， do i = 1, n 就比 for(i = 0; i &< n; i ++) 更為直接明了，還包括前面的對於多維數組的支持； allocate 語句也比動態申請一塊內存再強制類型轉換直接得多得多；對於指針，也是把指針的解引用當成了默認操作，讓它可以當正常變數使用，而對指針的賦值採用了新操作符 =&>。這使都做得在 Fortran 中寫數值計算程序比用 C/C++ 更加的舒服。

Fortran 不爽的地方，一是通用的庫比較少，不如 C++ 豐富。字元串操作也不怎麼方便。Fortran 沒有 namespace, 這方面弱於 C++，但有 module, 這點強於 C++。Fortran 2003 後也增加了類與面向對象，代碼組織能力有很大的加強，不是 F77 可以衡量的。

我現在用 Fortran 也大多是用 f2py 組合 Python 來搞，數據的輸入輸與以及代碼組織等主要交給 Python，而 Fortran 負責高密度計算，配合得也很融洽。

補充兩個編譯原理老師給的例子：

1) 關鍵字不保留的弊端

if then then then=else; else else=end; end if

寫編譯器的人估計該瘋了。。。

2) 忽略空格：

do 8 I = 3.75

do 8 I = 3,75

do8I = 3.75

請說出上面的代碼等價嗎？寫編譯器的人估計又要瘋了。。

曾經做過一段時間，當時已經習慣C++，覺得Fortran可讀性不強，維護得很累。

計算化學有個著名的軟體叫高斯，源碼都是fortran 寫的，看了會覺得自己很美。

如果要程序可維護，需要手動拿數組實現結構體之類，或者至少搞類似的變數命名體系和頭文件。再加上CFD程序有大量狀態變數，感覺類似拿C寫Verilog HDL(硬體描述語言，這貨不是程序)的模擬器。

以前寫多了CFD代碼又沒掌握Matlab模電和數電混合模擬(在當時還很不常用)的時候為了模擬混合信號電路干過拿C做殼模擬Verilog這種奇怪的事情，而且脫殼之後的Verilog代碼編譯成硬體電路全都沒有問題。

如果要搞控制邏輯較複雜的程序，FORTRAN程序慣用的大量全局狀態和解耦不徹底的風格作大死，導致頭文件膨脹和狀態過多難以維護。哪怕寫成C結構體或者C++類都作死。

如B9Creator 3D印表機的單片機控制部分，一個美國空軍退役軍人業餘寫出來開源的Arduino控制程序，感覺居然像FORTRAN計算程序。只要改一點就有無窮無盡的bug，還是實時控制系統，錯一次就列印報銷。如果美軍用這種軟體風格，軟體超期就不奇怪了。

有人說寫代碼的人習慣不好，不能讓語言背黑鍋......

我想說這鍋Fortran還真是背定了！因為Fortran本身就鼓勵你養成寫代碼的壞習慣！

比如最基本的implicit變數聲明......時至今日還有很多Fortran用戶拒絕使用implicit none，這鍋不該Fortran背么？

（順手舉個例子，我師弟剛進組的時候堅持不用implicit none，然後發現他自己的toy code出現了愚蠢的錯誤後才認識到這個問題）

再比如蛋疼的函數interface......醜陋得不能直視......沒有頭文件這回事就不要定義interface了好么......這玩意兒直接讓代碼的可維護性下降一個量級......

再比如指針......沒有指針就沒有指針唄，非要搞假指針......直接導致很多Fortran用戶根本沒理解什麼是指針......

PS：還有數組存儲順序的事......至少跟99%的地球人思維習慣相反吧......

人類總是不斷重複相同的悲劇

只要是用Fortran的項目，基本上都是延續多年的老項目，這就意味著巨大的歷史包袱；接手一份歷時幾十年的老代碼，這感覺。。。

或者就是未經過系統的軟體訓練的非IT行業工程師的作品，這就意味著他們當初寫代碼的時候基本上是懷著一種寫草稿的心態，代碼能run，結果正確就好了么。。。。。。

我不是學計算機的，但是我們專業教過一門Fortran，沒錯，地質專業，2017年教Fortran……!

我看著老師把計算機里的上古代碼拖到xp虛擬機里運行，而且各種goto感覺讀代碼跟玩心理測試一樣。而且這寫計算，C或C++不都能做嗎？不就是多了幾個庫函數嗎？

我見過那個老師因為for90里沒有一個上古求逆矩陣的庫函數，寫到一半又打開虛擬機到77里寫。

可能讓科研工作者學一門新語言是太艱難了，所以Fortran才能依然存活

我以前用fortran寫過爛的一塌糊塗的層流問題的代碼,剛開始算方腔流動,然後是凹台流動,算了幾個例子,換一個模型就代碼就重新寫,求方程組的代碼也是.根本沒有抽象的編程思維

學了c++以後非常輕鬆了,特別是抽象的思維讓整個代碼都是非常清晰的.

還有很多老頑固一直用f77代碼的,我們老師給了個LES的,我看都不想看,直接就用openfoam,可讀性差幾百倍.我們老師還說他讀博看代碼就看了2年

1、Fortran比C++快，這是臆想的。

2、Fortran也有好代碼，C++也可以寫出渣代碼。

這就好比說朝鮮也有好的地方，美國也有不好的地方，所以朝鮮並不比美國差。呵呵。

況且語言本身的鍋，幹嘛要讓寫的人來背。

3、對於物理的都是工具，應該專註於模型公式，不應該花時間在代碼上。

然而大多數人都是是看Fortran代碼看瘋了，調試改動都要崩潰了，這不是浪費時間？

有個答主好像說他老師看代碼就看了兩年，這專註也是感人。這不是浪費時間？

4、Fortran新版本也來越嚴格。好是好，只是沒什麼意義，比較已經落後於時代了。

為什麼這麼多物理人用呢？

因為Fortran代碼已經有了，而C++要自己寫。

一是懶，二是寫不出來。

呵呵

Fortran語法簡單，對於本科只學過一點c++的我們來說很容易就能學會基本語法和功能。

如果課題組的遺產代碼可讀性好的話，很容易就能上手。當然可讀性不好，比如goto滿天飛的話，那我只能祝你好運了。我們課題組的代碼儘管是FORTRAN77的格式，但是從祖師爺開始就寫的很規範，重要的是沒有用過GOTO，看日誌記錄是在90年代開始開發的。。之前看過一個上古時代計算激波的代碼我的媽呀goto滿天飛，總共幾千行的程序，捋了三四天才捋清楚。我得謝謝我們祖師爺，賞我這碗飯吃。

xkcd關於goto的小漫畫，連小恐龍都受不了了，lol

圖片來源:https://xkcd.com/292/

漢化：https://mp.weixin.qq.com/s?__biz=MjM5OTM0MzIwMQ%3D%3Didx=1mid=404005399sn=2a7f52569cbb9044298201d936fe6089#rd