数値計算屋がFortranを捨てるべき3つの理由

パンチカード時代の負の遺産として数値計算系を中心に今も生き続けている言語Fortran。本稿では仮に数値計算用途であってもFortranを使うべきでない理由を説明することで、悪しき文化の終幕を促進したいと思います。

因みに筆者は量子系を中心にした数値計算を生業としています。C++Pythonがメインですが数値計算ライブラリの拡張などの用途でFortran77も90も触ったことがありますし、Fortran製のライブラリは頻繁に利用しています。

あくまで筆者の経験に基づいたものでありFortranを使っている技術者からすれば反論もあるものとおもいます。

 

【1.教材として不適切である】

Fortranの長所として計算向けに設計されているため、行列や複素数の計算が簡単であるという点がよく挙げられます。確かに、Fortranの計算はC++などに比べ直感的で簡単です。しかし、高度なプロダクトを開発する上でボトルネックとなるのは実装ではなく、エラー処理やバグ取りなどの設計/実装後の処理です(*)。バグ取りという観点においてFortranは最悪です。まずユーザが少ないので些細な文法ミスでも原因を探すのに苦労します。C++であれば大抵のバグは誰かが引いていて何らかの記事があるものですが、Fortranでは逆に、大抵のバグの解決方法はQiitaやstackoverflowには記載されていません。

更に悪いことに、Fortranで書かれ現役で使われているライブラリの多くは前時代的で劣悪なコード設計となっています。変数の文字名が1文字であったり、関数の名前が名前から機能を推定するのが不可能なレベルであることはザラです。例えば行列計算でお馴染みのblasの関数の一つ"sgemv"をsingle精度で計算されるgeneralなmatrixとvectorの積であると初見で理解できる人はいないでしょう。この手のネーミングはコードの長さに厳しい制約があった時代の負の遺産であり、今のコーディング規約的には真似するべきではありません。この他にも、Fortranの規約を守っていないため古いgccでないとコンパイルできない量子計算ライブラリ(**)や、入力ファイル、出力ファイル、中間ファイル(全部で10個以上ある)を全て同じディレクトリに置きたがるディレクトリ汚しなど、負の遺産はデザインやUIにも深く根付いています。即ちFortranは先人から学べば学ぶほどクソコードが再生産されるという悲劇的な仕様を持っているのです。


*自身の経験に加え https://www.quora.com/How-much-time-does-a-programmer-spend-on-debugging などを参考にしています。より統計的なデータがあったら教えてください。

** Quantum EspressoかWannier90のどちらかだと記憶しています。どちらだったかは覚えていません。そして再現実験はやりたくないです許してください。


【2.計算が早い言語としての価値が急激に失われている】

Fortranの第二の長所として計算が高速であることが挙げられます。Fortranは用途を狭くする代わりにコンパイラの最適化が行いやすく、他言語で書かれたエンジンに比べ高速で動作することが多いのです。しかし、計算が早いことのメリットは年々小さくなってきています。

高速化の究極的なメリットは時間の節約です。しかし、計算機の普及と計算手段の増加に伴い、計算そのものの高速さは急激に重要度を失っています。クラウドを使えば計算時間をお金で買うことができますが、コーディングそのものはお金で高速化することは出来ません。前世紀と違い、今は人間の時間のほうがコンピュータの時間よりも遥かに高額です。それ故、計算機言語にも学習がしやすく、再利用できる先人の財産が多いといったユーザフレンドリーさが求められています。コミュニティが小さく、学習環境が劣悪なFortranはこの観点においてライバル候補に比べ遥かに劣っています。

また、昨今の計算のニーズの多様化に伴い、高速化の手法にも多様化の波が訪れています。GPUやTPUの躍進に加え、将来的には量子アニーリングマシンが出てくるかも知れません。Rustのように堅牢性と速度を両立した言語も生まれつつあります。幸い、FortranはまだCUDAのサポートは受けられているようですが、早いといえばFortranと言われる時代は何時終わってもおかしくありません。


【3.Fortranのライブラリを拡張するのにFortranの知識は必要ない】

私自身は量子物理系の数値計算屋としてFortranのライブラリを解析/拡張したことがあります。先人のライブラリの流用はFortranの利用が正当化される数少ないケースです。しかし、Fortranで書かれた100のプロダクトを101にする上でFortranの知識は重要な要素にはなりません。

というのも、先人のライブラリを拡張する上で一番時間がかかるのはコードを書くことではなく、ライブラリの意図を理解することだからです。そして、先人のコードを読む上で重要なのはFortranの知識ではなく、ライブラリの実装が糞であるか否かに依存した運の良さと、クソコードの設計思想を脳内でエミュレートしてコードの意味を忖度する勘の良さだからです。

C++erがFortranのコードを読む上で理解しなければいけない文法はそう多くありません。モジュールの読み込みのルールと、配列のdimensionが可変であることあたりを理解していれば大体読むことが出来ます。コードを書くとなると配列が1スタートであるとか、多次元配列のアクセス順序がC++と異なるとかを覚える(そして苛つく)必要がありますが、コードを読む作業に比べれば誤差みたいなものです。

できるだけ既存ライブラリを書き換えない形で拡張が出来ないかを考え、無理だったら祈りながらコードを読み、書くべきコードが理解できたら検索とコピペを繰り返して実装するぐらいがFortranとの適切(かつ、合理的な)付き合い方だとおもいます。


【4.最後に】

私はFortranを激しく嫌っていますが、Fortranが生み出した様々なプロダクトの恩恵を享受してもいます。素晴らしいプロダクトを生み出してくれた先人たちには感謝しているし、尊敬もしています。ただその一方で、計算機系の研究室に入ったからFortranでプログラミングを勉強するという行為は絶対に避けるべき愚行であると考えていますし、乳歯が生え変わるようにFortranはその役割を次の言語に託し滅びるべき時代に入ったと思っています。

億万長者になった暁にはFortran製のライブラリを滅ぼしてくれる計算系研究者に科研費をばらまくのでその時はよろしくお願いします。いや、それまでに滅んでいてくれFortran