Tiobe 今月も 20 位

www.tiobe.com

f:id:fortran66:20210507005936p:plain

ZDnet 記事

www.zdnet.com

まず最初に目につくのは、三枚モニターに同じ画面を出しているおじさんの写真が使われている事です。この三枚同画面おじさんは有名なフォトストック写真で、以前どこかで物笑いの種にされていたのですが、Fortran 記事で再会するとはｗ

f:id:fortran66:20210515232325j:plain

記事内容は、ちゃんと取材したオリジナル記事です。やや悲観的に未来を見ていますｗ　悲しすぎて最後の方のパラフラフで exception handling が execution handling に化けています。

個人的には Fortran の再浮上は、計算機の最前線が文字列処理・データベース処理主体のＷＥＢから、計算主体の AI にシフトしてきたことと関連していると思います。過去を振り返っても GUI が最前線だったころはオブジェクト指向がもてはやされたけれど、WEB 主体となって文字列処理に長けた軽量スクリプト言語がもてはやされたようなものです。

他言語にあるからという理由で、例外とジェネリックが喫緊の課題とされていますが、本当に必要なのか損得勘定が示されているのを見たことがありません。

かつてオブジェクト指向にあらずば人に非ず、継承と多相に非ずば OOP に非ずと世間が騒ぐので Fortran もそれらを取り入れたけれど、今や新流行で Rust やら Julia やらは継承は過剰に制約を引きずり過ぎるからと、取り入れてなかったりするし。

Fortran も元のモジュラー言語の枠組みで、抽象データ構造を表現する方向を取った方が、今の新流行に近づいていたはずｗ

例外は MPI の C++ で期待通りに機能せず、C のエラーコードで一本化された点を鑑みて、本当に有効なのかよく分かりません。バッチジョブで実行する場合、どうせ異常終了するなら、即死してシステム出力をダンプさせた方がいいような気もするし、モダン言語で便利とされるカジュアル例外は、単にバルク処理と界面処理とかの場合分けなどに使われていたりするので、それならば境界条件処理として実行時ではなくコンパイル時に解決できる文法構造を出す方が建設的な気がしなくもないです。

ジェネリックの方は、単なる型パラメータならコンパイラの複雑化、低速化、バグ導入に対して、損得勘定が合うのかよく分かりません。代数的データ構造として、型の型を入れるなら、引き合うかもしれませんが、数学を横滑りさせるデータ構造が浮動小数点数に適するのかよく分かりません。実数は全順序で実数の公理を見たしますが、IEEE754 は NaN が数直線上にない付加点なので全順序でもなければ実数の公理も満たさず NaN が関われば a<b, a=b, a>b のいずれも成り立たちません。それどころか a==a が偽で a/=a が真となります。

まぁ整数の二の補数表現も、2ⁿ の最小剰余と考えないと整数の公理が成り立ちませんが。

損得勘定なしに他言語にあるからと欲しがるのは、昔の PL/I クレクレ病です。