為什麼越來越多的科學家使用Python、Ruby而非Fortran？

---

需要強調的一點是， 語言只是工具， 在特定應用場景下滿足特定需要的工具， 脫離應用場景來談不但沒有意義而且還會扣友善度。以下經驗（吐槽）都是針對大規模科學計算的， 個人電腦寫一個下午的代碼，然後跑十分鐘的代碼趁早去用 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


詳情見IBM Knowledge Center

---

Python就算了，在科學計算上Ruby真的沒多少人用

---

科學計算領域需要大量矩陣運算，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有真相

---

其實，學術圈也是一個市場，用的人少了自然是有個更好的產品。

最大的問題：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用的不多的。另外，面向對象這個功能在科學計算領域用的真心不多，一般把同一對象的信息封裝起來就足夠了，用不著多少高深的語法。

---

因為Ruby/Python這類語言可以讓科學家更專註於科學研究本身。

---

看科學家對編程的需求了。數據科學的興起讓人們對數據挖掘和可視化功能要求越來越高，python好用，lib多，但就其內核而言根本沒法控制memory，更深入的不是特別了解。

對於數值模擬，比較重視計算效率和可行性，對memory 的allocation甚至acccess都要嚴格的控制，相對更加底層。Fortran主要是之前有大量數值模擬code遺留下來，但是好多功能確實不太uptodate，function call對argument的數量都沒有控制。感覺現在模擬方面c++是主力，strongly typed 有助於計算的嚴謹規範，美國勞倫斯伯克利國家實驗室LBNL計算組的code是C++。

---

這是個偽命題。現有的底層工具已經比較全了，blas，lapack這些高性能數值計算庫有了不需要重新寫。儘管如此，開源的blas，lapack還都是fortran寫的，每年也都在更新。

每個人處理數據的代碼需要自己寫，python這類腳本語言容易開發，還能通過numpy scipy調用blas庫性能能接受。有多少組是專職更新blas和lapack，或者開發相應計算套件需要寫fortran的？

但用python做前後文本處理的人多，不代表python的寫個矩陣乘法就能超過blas。

最後，在模擬計算領域，要成大拿最後都得搞搞新演算法新模型，並且集成到現有包里去。要這麼搞就繞不開fortran以及他的歷史遺留庫。

---

只想說一點，基本數值庫(blas, lapack等)的性能跟fortran沒關係……fortran只是它們的介面語言而已。所有性能說得過去的實現應該都是彙編寫的。

更何況C也是它們的介面語言，然後因為C是，所以所有正常的語言都能通過調用C介面獲得性能的好處。

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

---

作為一個用過 Fortran 的 pgplot 庫作死畫圖的人類表示；

讓 Fortran 這麼難用簡直是超乎想像的系統工程，比如 mod 編譯坑，變數聲明坑，依賴鏈坑

---

Fortran語言作為一種上古語言，其實被淘汰也不為過，單就編程語言來講，估計要被很多語言吊打。

但是啊但是，你看，搞科學研究的，不是每個人都可以做吧？很多科學家並不是特別地偏愛Fortran，只是在很多研究領域，早於計算機的發明，對科學家而言，很多時候計算是一個很大的瓶頸。

剛好計算機出來之後，Fortran整出來，科學家們十分高興地找到了能代替他們完成計算的編程語言，然後就一發不可收拾了，慢慢地就積累了一批優秀的代碼（以及更多你看不到的稀爛的代碼），等老闆帶徒弟搞研究，一來已經有很多大量的Fortran代碼可以用，二來你自己搞個其他語言寫的代碼，老闆表示看不懂可如何是好。所以自然地繼承下來（並順便發揚光大了）。

如果Python和Fortran處在同樣的歷史機遇下，我估計現在很多人都不知道有這麼個語言了。

和Fortran語言境遇類似的還有一個叫做COBOL，據說現在還有代碼運行在商業應用上。

---

http://www.zhihu.com/question/21017354 反對那些說Python只能寫寫腳本，畫圖的回答，很多大型項目也在使用Python，不要人云亦云

---

FORTRAN太老了吧……

但是人家老當益壯啊，畢竟還有單位在用，我校的好些東西仍然用的是Fortran，沒人改是一方面，更主要的私以為是改了之後效率提升並不明顯而且浪費時間。

ruby雖然有個gem叫sciruby但是已經很久沒有維護了。

python，python是活著的語言。有人用，就有人維護，有人安利，而且效率也不差。

當然純效率還是C++快，面向大工程還是Java方便。

所以說，語言各有差異，比來比去沒什麼意思，什麼好用用什麼不就行了，又不是逼你用C寫個物理環境引擎。再說非得用一個語言去做不擅長不是強迫症就是自己和自己過不去。

何必呢

但是

當我真正開始老老實實的用fortran95寫東西的時候，我越發的覺得我應該用c++去搞，因為我受夠了那個夜郎自大的老師和不明所以的批評。

---

Fortran以90年以後的編程思想和語言發展來看，簡直連渣都算不上，僅此而已。

另外，Fortran做不到的事情（至少是不能方便做到的）簡直太多。

作為一個在科學計算界早就被C/C++淘汰，後續又被各種動態語言秒殺，棺材都快爛透的語言，為什麼要選擇它？大型計算只有Fortran？扯淡，PyPI上大氣建模的輪子都夠開火車了。複雜工程用腳本寫不出來？更是扯淡，你當Python真是腳本了？就算不說Python，現在的C/C++/Java哪個不比你組織工程項目有優勢？說效率的更扯淡了，你有本事找個拿C寫出來開個O3編譯完比Fortran慢的情況說話。

用Fortran的基本只有一種情況，大量老舊代碼還是Fortran，重寫一遍太麻煩，做計算又不是當碼農，學Python學C++豈不是傷了高貴的科研計算人員的自尊……

如此而已。

---

@Coldwings說PyPI上大氣建模的輪子都夠開火車了。

基本的大氣動力模式簡單的要死，正壓大氣模式是我們本科《數值天氣預報》的課後作業，斜壓模式的code就在fortran教材的後面，沒幾頁的。動力框架估計都是用的幾十年前的東西，這個數學不發展，估計沒什麼改進空間了。

現在大氣模式開發重點根本就不是大氣動力過程，基本上都是大家都是做得物理化學過程參數化部分，這個不知道你說的模式有沒有提供。要做天氣氣候的模擬，再單獨的大氣模式沒什麼人用了，至少要搭配一個陸面模式，再多就是海洋海冰模式了，還要搭配耦合器。大氣模式是八九十年代比較高端的東西，現在是2015年！

別的不說，FORTRAN在大氣模式開發中根本就無法替代，你要開發模式最重要的一是模擬的效果，二是計算效率。模擬效果不說，你用別的語言開發出來，就算不算高的2°解析度，計算一年牆鍾要多久？開發過程需要調參數，少說前後要積分千把年，這得多久，後面如果想在國際上得到認可至少要參加個IPCC的報告，不同的情景預估又是幾百上千年的計算了，又得積分多久。算得慢了，你還要不要大家畢業啦！

fortran就是為科學計算而生的，什麼面向對象編程，什麼繪圖啊，根本就是歧路，搞科學計算的誰關心這個的，你矩陣算的快點大家才開心！

---