【解説/プログラミング言語】世界初の高水準言語「Fortran」が考案から約70年経ってもいまだに使用されている理由とは？ [すらいむ★]

世界初の高水準言語「Fortran」が考案から約70年経ってもいまだに使用されている理由とは？

　1954年に考案され、広く用いられた世界初の高水準言語が「Fortran」です。
　多種多様なプログラミング言語が存在するにもかかわらず、考案から約70年が経過した「Fortran」が依然としてプログラマーに愛用されている理由を、カリフォルニア工科大学のMartin D. Maas氏が解説しています。

　5 Reasons Why Fortran is Still Used
　https://www.matecdev.com/posts/why-fortran-still-used.html

（以下略、続きはソースでご確認ください）

Gigazine 2022年11月08日 07時00分
https://gigazine.net/news/20221108-fortran-programming-code/

某重工にFortranで制御された計測システムがあったw

英語がなくならないと一緒。
言語だから、コンパイラが時代を作ってくれるのさ

今はスパコン専用言語みたくなって、性能を失わず並列処理が簡単に書けるからね

いまだ 1Hスペースが忘れられない

ナムコのUGSFシリーズの宇宙戦闘機はフォートランが動いてる

>>4
自分も勘違いしてましたが今のスパコンはCだそうです。
Pythonもいけるらしいです。

57歳のコボラーだが定年まであと３年
就職した時点でCOBOLは無くなるみたいに言われてたが、こんなに長寿だとはｗｗｗ
SQLだけは身に着けたけどね

パンチカードシステムが動くから

誰にも話題に出してもらえないRPGさんはどうなっていますか
認知度低すぎてゲームだと思われるんです

愛されてるってのと感覚が違う気がする。
cobolも愛されてはいないだろ？

>>8
お勤めは銀行系か鉄道系?
cobolだけでキャリアを終えるなんてスゴイね。

>>7
並列処理って面ではFortranが良さげかな、自由度が高い言語は並列処理の最適化がしんどい。今時はパラレルプロセッサ積んでいるのをスパコンと言わんのかも知れんけど

>>10
コボルドもいるぐらいだしな。

FORTRAN77で流体の数値解析してたよ

ラダーでよい

FORTRANすごいよね
はじめて学生時代に教わったときはWindows3.1だった

やっほー フォートランランラン

>>17
パンチングカード？
マークシートも有ったな。

鉄道系もCOBOLなんだね。
金融系のイメージしか無かった。

パンチカードとラインプリンターが学生時代の思い出

量子テレポーテーションデータ伝送技術を応用したスマートフォンを開発しろよ！www

ループが無限ループになりやすくてロケットを宇宙のかなたに飛ばしてしまうFortran

>>22
その前に量子テレポーテーションデータ伝送技術を開発しないと駄目だなwwwwww

オイラはBASIC一本で社長になった

理由は特に変える必要がないから

ファイルのゲット/プットすら2進法で記述してたマシン語が懐かしい

>>27
マシン語とかインライン埋め込み数十行しか使ったことしかないな

>>24
量子テレポーテーションデータ伝送技術が出来る様になると光ファイバーが不要になるかもしれんなwwwwwwwww

>>19
プログラミング用紙というのがあって
実習はそれに鉛筆で書かされた

>>26
様変わりしてるって

フォーフォーフォートランランラン
フォトフォートランランラン
フォトフォートランランラン
フォートラン

90の頃に使ってたわ
いまだに自分で一番書いたコード量の多い言語だと思うw

4倍にするのに左シフト2とかできてとっても軽量

Fortran for TRONはないの？

>>19
Windowsがあった頃はテープもカードももうほとんど無かったかと。
マークシートのカードも1980年代までかな、一枚一行だけどズボラしてカードに番号書かない奴は床にうっかりぶちまけて泣きっ面で2進数読みながら並べ直してたわw

マークシートは現役じゃないかな？
人間の試験やギャンブルだけど

>>7
Fortran2018とか知らない人?
今はFORTRAN77じゃないんだぜ?

>>37
このスレでマークシートと言えばFORTRAN CARDのことだろう
Facom mateのやつとか

>>30
コーディンシートか
なついな

>>40
×コーディンシート
○コーディングシート

>>39
そうそう、画像のはパンチカードだけどこんなの
https://ja.m.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:FortranCardPROJ039.agr.jpg

>>42
https://i.imgur.com/OeLGQQI.jpeg

>>7
でもCに関してパラレル向けの言語拡張の話は聞かないな。

>>30
>>41
本番カードに穴をパンチあるいはマークする前に
試しにコード書いてみるカードのことね
バージョン管理システムとして
・コーディングカード version 0~0.99999…
・パンチカード、マークシートカード version1.0
という役割

>>44
Parallel CとかαCとかXL C/C++とか色々あったけどベンダー間で統一されてないからね
スパコンのデータパラレルはFortranの圧勝だよ
CよりもPython scipy/numpyの方が統一されてる
まあ下位層は独自C/C++拡張で書いてあるんだけど

昔：FORTRAN
今：Fortran

随分変わってんよ

>>46
そうそう、Cとかで並列化率高いコード書こうと思ったら意図的なコードでかつ使うコンパイラの特性知っているかどうかでかなり変わる

I/Oに載ってたマシン語を入力した人いる？

>>49
チェックサムがたまたま合致して入力ミスを見逃したことがある

別言語に移行するコストがかかり過ぎるからだろ
特にFortranが得意とする科学技術系の計算は誤差の問題が発生するから、労力が凄くかかる

>>49
oh!PCやoh!FMには毎回ゲームのマシン語ソースリストが載ってて、
入力して遊んでた

oh! その他!

>>7
Fortranが科学技術に特化してるからだよ
それが並列処理できるよう拡張されたのはもう1980年代
いくらCができてもユーザーが科学者ならその視点で書きやすいのが使われやすいわけよ

>>49
I/Oでなくともマシン語はデバッグで見たんだよ昔はね
COBOLでもFortranを使っていたとしてもシステム寄りのモディファイルーチンつまりOSのユーザーカストマイズにはアセンブラ必須だったし

デバッグはマシン語とビットの意味を読めない
と

入力よりもシステムが何やってるのか知るには必須だったんだよ

>>47
大文字しかつかえなかったから当然だよね
大文字しか使えないのに小文字使ったら突っ込まれる

Fortran パラレルの歴史書いてる人いたよ
https://wvuhpc.github.io/Modern-Fortran/20-Parallel-Programming/index.html

Fortranが今でも使われている5理由
https://www.matecdev.com/posts/why-fortran-still-used.html

スタンフォードのアーカイブ
新しいFORTRAN90 77とどこが変わったか
1997年12月
http://sepwww.stanford.edu/public/docs/sep70/biondo/paper_html/node2.html

>>7
未だにFORTRAN(Fortranではない)ライブラリがデファクトスタンダードだぞ　BLAS/LAPACKとか

Cとかpythonの遅いライブラリ使って、ループ一回が0.01秒でも余計にかかるなんてやってられない　そもそもライブラリ以前にコンパイラがクソだが

ちなみに大抵の技術部はFORTRAN使ってた
そんななかホストコンピュータでもCを使いたいというんでCメーカーがサポートしたないアメリカモンのCをインストールした新人時代
まだCは方言がきつかった

てかこのあたりでアセンブラとかマシン語ができるとすごいみたいにいうやついるだろ
逆
ビットってのはオンオフスイッチ一つのことだから
豆電球つけるスイッチがただたくさん並んでるだけ
そのオンオフの組み合わせをこういう意味にしましょうって決めてるのがコンピュータのシステム
カッコつけて建築から借りてきた言葉でアーキテクチャって言ってるだけ
ビット列の取り扱いを決めたのは人間
それでCPUとメモリーとコントローラの動きを決めただけ
これが作る人によって違うから別のアーキテクチャと呼んでるだけ
んでそのCPUを使うならそのビット列の取り扱いで動かすだけ
いろいろ動かしたいならソフトウェアで動かすだけ
そのソフトウェアはそのビット列の取り扱いで動かそうとするだけで
そのソフトウェアが例えばLinuxならマシン毎にLinuxが違うわけ
でそのLinuxの上でC動かしたいならそのCもそのビット列で動くように仕込んでないといけないだけで
そのCを使ってコーティングする人はいちばん下のビット列の違いはそんなに考えなくて良くなったのは楽だよねー
そのかわり細かいことは気にせずでかいことをやれよーって話でAIとかやるのが楽になってると
端折りすぎたけどだから楽なんだよいろいろできるんだよね

みんな誰かの作ったルールとツールでプログラミングできてんだから感謝しながらでかいことやろーねー

機械語でプログラミングするのは
車を鉄インゴットから作るようなもの。

パーツ一つ程度なら可能かもしれないが、
全体を作るのは現実的ではない。

>>13
そのとおり。言語仕様が簡素なのが良い。

>>60
言語とライブラリの区別がついてないね
BLAS,LAPACKならscipyから使える
問題は自前で書いた配列演算も並列にできるかどうか
そこはFortranが優位
ただしLAPACKもマルチスレッド対応ではなく既に古臭い

もう最後にFortran書いたのは三十数年前だが今でも書けと言われれば書ける

>>65
Fortranは複雑化するばかりだけどな
計算が速いライブラリ、コードが可搬性高い方がいいからな
速いは正しいの世界だから
ただ昔と違ってハードウェアアーキテクチャ乗り換えても速いことが求められてる

そこに愛など無いと思っていたが実は愛されていたのか？

>>6
今はCでも書いてるんだ。昔スパコンでシミュレーション作ってた時は精度の問題でFortran一択だったが。

例えば倍精度と指定すれば、
大抵の言語はそれで演算できるので
なぜフォートランばかりなのかよくわからん。

過去の資産を手直しして再利用しやすいからじゃないかな?

>>71
数値計算で桁落ちって習わなかった？
数式通りに計算してはダメで
桁落ちが起きないよう式を変形させて計算しないといけない
>>60のBLAS/LAPACKはその叡智の結集
だから計算精度面でライブラリは重要

80年代末くらいから他言語でバインディングされて
それでC/C++が増えた
けどやっぱり言語がnative coarrayを持つFortranが復活してきた
Fortran90以降のFortranね
FORTRAN77じゃない

>>4
頑なに配列添字まで()を使って秘蔵していた[]を、スレッド/プロセス添字に使ったイノベーションがFortranの地位を確固たるものにしたと思う
並行/並列プログラムでの各変数をvar[i]で参照できる利便は他言語の追随を許さない

>>72
元々forallとか並列性を明示する文は豊富にあったけど、それでもcoarray拡張標準化以前はディレクティブだらけの汚いコードだったな(専用構文を全く欠くc程ではないが)

モジュール等名前空間管理やインターフェイスもしっかりしてるし、20xxは本当にモダンになったと思う、むしろSteele先生が関わってから厳格、というかJava臭くなったのと、OOPはオーバーヘッドで不評だけど

C++の目指したかっただろう言語になってるよね
Cとの互換性ガーとか言ってるうちにパフォーマンスでも言語デザインでも先を越された

>>66
>>1のコード例見て言ってる？
python/scipy/numpyはFORTRANバインディングが便利(f2py)で糊としてよく使うけど、配列演算含め(モダン)Fortranの方が遥かに簡潔で分かりやすいぞ

先史時代からの互換性を担保しても、どんどん新しい言語構文を導入してるからキレイには書ける
但しマニュアルでかなりの構文がdeprecated記載祭りなのはかなりアレ
大抵の言語は関数レベルでdeprecated→廃止で構文には手を入れないけど、Fortranは文レベルかつ廃止が(ほぼ)ない

マニュアルにノイズが多過ぎるから、正しい作法を身につけるのは長い道のりだと思う

いくら新構文を付け足しても、implicit noneだけは除けないのよなあ…

電子計算機の時代の
プログラミング言語が
まだ現役なんだね
カセットテープとどっちが長生きするか

>>72
精度について仕様でとやかく言ってる訳ではないと思うが、80年代から大抵のコンパイラは4倍精度(無ければエミュレート)+複素数=8倍以上のサポートがされてた
c系で右翼なgccでも結構最近になってからじゃなかったかな

あと言ってるのはもっと高水準なライブラリについてだと思うぞ
大体プロプライエタリだが、デファクトスタンダードで網羅的なmkl等の存在が大きい
mklは呼び出しが古風だけど、他の言語でここまで高機能なライブラリは無いんじゃないか
Pythonでデファクトなscipyでは明らかに機能不足だし

それでもmkl呼ぶコードを書いてラップし、簡単に拡張できるscipyは良いものだけど

>>79
常に機能的には最先端だぞ、少なくとも俺の知る2000年以降から現在までは

FORTRANもCOBOLも
もうよしなよ

GPGPUなんかの新興デバイスもメーカー公式でマニュアル示すのはC(++)/Fortranが慣例だしな

Fortranの慣習を尊重して後方互換性を切り捨て、事実上モダンFortranとされていた部分のサブセットそのものなjuliaこそ正当な後継者だと思うんだが、Fortranの成長が速すぎてもはやモダンじゃなくなってしまった感

cは絶対になくならないだろ
windows OSのソースコードはcで書かれてるからな

日本語のFortran入門書は90/95水準止まりが多いし、77やそれ以前のコードの読み方への注釈に終始してるから、シンプルなjuliaはFortran入門に良いと思う

2008水準以上は学術出版社から出てて数万円で敷居が高い
自習できるマニュアル読解力があればいいけど

新しいcは記事にあるようにrestrict導入(Fortranのintent in/out)や、特にFortranに比べて決定的に遅い主因だったstrict aliasing問題も解決できたから、パフォーマンス指向でもこれから盛り返せると思う
atomic保証はまだ普及してるとは言えないが、システムプログラミング言語としての地位を盤石にするだろう
Cは着実に正しい進化をしてる、ナイス

それに比べてc++ときたら、何者にもなれない

配列演算や非同期処理の抽象度がすごく高い
Fortran風の配列演算はnumpyと比較されるけど、row-major, 0-indexのcコンベンションだからMatlabからの間接輸入になるのかな？

にも関わらず半世紀以上前の古代記法も有効というエキゾチックさが好きだわ

汎用言語の文法に手を入れないライブラリ実装では、where, forall, mask, do concurrentのようなフィルタやセレクタ処理がメソッド呼び出し構文等の流用になるし、多少見た目が汚くなるのは仕方なくね

例に挙げた程度のものならプログラミング全般に役立つものだし、もっと文法に入れても良いと思うが

俺はオライリーの行列プログラマーって本をFortranで自習したけど、強力過ぎて勉強にならんな

低レベルの問題でも、多重ループの添字はメモリが連続するように動かす云々、みたいのはちゃんとやるべき
添字の処理順に明確に依存して、等価な結果を出すうまい最適化のない処理じゃないと差が出ないけど
ifortはほんとかしこい

Fortran単体で書くことはむしろ少ないし、C系の言語とやり取りする時には常に意識しないといけない

68歳cobol現役だわ
もうすぐ終える

FORTRANから派生したBASICでマイコンのプログラムを組んでるで(´ω｀)
ふつうに仕事用の治具を組むのに今でも使ってるよ

>>80
桁落ちを全然分かってない
それじゃ単位は出せない

>>75
C++の言語デザインは別次元です
それ以後の言語デザインを変えた
templateとかSFINAEとかconceptとか

cとその亜種はサブルーチンと関数の文法上の違いがないから、最適化コンパイラを書くのが本当に難しい

スタックすら積まなくていい副作用のみのsubroutineと値を返すfunction、副作用を禁ずるpure functionとの区別と、値渡し参照渡しを分けてれば良かったのに
たったそれだけでinline地獄は回避出来たはず

入出力変数にintent指定があれば、変数のメモリ領域を一時作業用に上書き流用など自由度が高まったはず

人間にとっても値を評価する関数fun(a, b,)と副作用目的であることが明確なcall sub(a, b)の区別や、引数のin, out, inout指定は分かりやすいと思うわ
欠いてる言語も結局ミュータビリティ概念で代用したりコメントで示すわけで

>>96
> cとその亜種はサブルーチンと関数の文法上の違いがないから、最適化コンパイラを書くのが本当に難しい
>
> スタックすら積まなくていい副作用のみのsubroutineと値を返すfunction、副作用を禁ずるpure functionとの区別と、

色々とおかしい

>>88
わざわざ総称型関数を定義しなくても、集成体に対して自動で特殊化してくれるelemental functionが簡潔で便利よな、elemental修飾するだけでいいし、ついでに演算子オーバーロードしても
まあnumpyにもufuncという名で同等の機能があるが

ただし組み込み演算子のオーバーロードは要素毎の自明なものに限った方がいい(element-wise)
配列演算には行列積内積外積クロネッカー積…と無数のものが考えられて、Fortranではほとんど任意文字列の演算子定義が許されているのだから、記述的な名前を付けるべし

>>95
Fortranには定番のテンプレートエンジンや、ましてテンプレートライブラリみたいのは無いな
ベンダ固有、CPPの変種やFORTLANの為に書かれた由緒正しき？m4とか
そもそも規律あるチーム開発の文化が無かったり、クラスや複雑な構造型は好まれないので総称関数で済むケースが多い
c++のSTLのようにロジックまで実装する試みは長続きした試しがない、STL移植を目指したFTLなるものもあったはずだが、やはり最近音沙汰ない

c++のようにコンパイラがマクロ風のテンプレートを認知する言語はむしろ珍しくね？
後発言語で型変数を扱うものは、むしろ初めから構文の一部として実装か、コンパイラの認知しない単なるマクロかだろ
cに継ぎ足して生じたキメラみたいなもの

実体化の検出、構文として正しいかのチェック、コード生成
コンパイラを通さないと意味論のチェックまでは出来ないから2パスになる
STL移植は筋が悪いわ

m4に象徴されるように、Fortranは昔からスクリプト言語やマクロ言語でshoot yourself in the footの精神

>>96
ごちゃごちゃ言ってないで自分でかいて提案しろよ
日本の大学教授みたいな評論だけ日本人に向かって偉そうに喋る
世界相手にやればいいじゃないの
批判が怖いの？

>>96
AdaやPascal&Delphi系の人かな。

BASICを最強にしろ
コンパイラが頑張ればいいだけだろ

速度重視の世界ではインタプリタ系は無い。
機械の仮想化が進むとどうなんだろう。

Fortranで進まないプロジェクトにスパコン噛ませるのと
インタプリタですいすい進むプロジェクトにスパコン噛ませるの
どっちが早いんだろうか。万年レベルの差が出るならともかく

普通に超便利だからだろ
静的言語でOctave(Matlab), scipy以上に簡潔な配列演算記法をサポートしてる言語って他に無くね？
奇怪な記法に目を瞑れば、APLが対抗馬

array comprehension(数学の集合内包表記)ワンライナーでパパっと配列組み立てて
述語を渡してフィルタ
スカラ関数が配列にそのまま使えて
ブロードキャストで添字マジック

世界初の高級言語にして、現代でも静的言語としては間違いなく最高級言語

COBOLみたいなレガシーロートル言語と比べるのは失礼

>>107
表記だけで言えばHaskellやFortran2018もイケてる
Haskell fusionとか
ecosystem的にはPythonが圧倒的な勝者
wrapper library書くのが簡単
昔のPerlのように

cより遥かいにしえの言語は、出力のフォーマット指定子ミニ言語が辛い
lispとfortran
どちらもprintfより強力ではあるが、特にlispのはそれ自体でチューリング完全

他人の書いた古いコードを癇癪を起こさずに読むことができるから。

>>105
BASICがインタプリタな時代ではないのだが
それでもコンパイラが糞なのでマシン語やCより遅い
それが気に入らない
コンパイラがとにかく頑張って、超最適なマシン語に変換すりゃいいんだよ

最強はRPGでしょう。　RPGで組めない時はアセンブリー言語で乗る抜けました。

>>43
なんでfortranなのに空白入れるかな？

>>96
なんか言ってることがよくわかんないんだが、
JUNETの初期の頃を思い出す

Fortran使わない世界の奴は一生使わないけど、使う世界の奴はないといられないってことで良いじゃないか。棲み分けしようぜ。

fortran が使われ続けているのは数値の精度、言語レベルでの複素数対応
とかいろいろあるけど一番は長い歴史からくる膨大なライブラリによる

program hello
print *, "Hello world!"
end program hello

例外的に科学者が音頭を取ってる標準化団体なんで
込み入った現代風のプログラミング言語の文法は分からずに
そのまま進んだおかげだ

平たく言うと「言語学者」がいないからだ

IT屋と違って、ニッチな言語を使っても、キレイなコードを書いても成果には何ら関係ないからな

>>117
数値の精度なんて言語としてのFORTRANの選択に何の意味もない

Pascalに若干似ていると思ったら、Pascalのコンパイラーを作った人は最初それをFortranで書いたんだってな。

>>119
言語屋の知恵を借りずに言語を定義できるわけない
ただの数値計算屋には浮動小数点の10進表記の定義すらままならない

>>120
コードに興味が無く学者が興味あるのはデータだけって感じか

>>120
そんな時代は去って
コードの再利用性を数値計算屋は考えなくてはいけなくなって
それでFortranの型システムが強化された
再利用というのはライブラリだけじゃなく自分で書いたコードもね

理数系の講義で使う事もまだ多いし、少し書ける程度の人口はかなり多いのでは
東大の弥生の計算機センターの講義はまだ全部Fortran、理工合同の計算化学演習とか
教養はPythonも増えてきた

情報系じゃないとちゃんと言語自体の講義はやらないし、もうかなり怪しいけど

print, write, readなどI/Oが行毎の処理、フォーマット指定子忘れても型のデフォルト出力で無難、stdin/stdoutをデフォルトで指してて組み込み関数が多い(trimとか)
数行のフィルターを書くのに結構便利、というかそれくらいしか使ってないわ…

>>124
計算のアルゴリズムには興味がある人も多い

言語というかコンパイラの問題だけど、gccのcはヒアストリングとか一時ファイルだとファイルを2回開こうとして死ぬし、ヘッダとか全く覚えられないという理由で、最近までcを忌避してた

tccはワンパスのようで、バイナリを残さない-runオプションもあり、(ワーニングは出るけど)ヘッダへ言及せずとも何故か走って簡便
lexも標準出力に吐けるしパイプで繋ぐだけでもうawkより強い、勉強中

>>93
わかる、カジュアルユーザーは何となく習った言語使い続けるのよな
f95とawkとdcで全部やってきた

(クラシックな)BASICも似た感じだったと思うけど、引数処理もget_command_argument呼んでwrite/readで変数の型に合わせて収まるし、main定義してargv舐めてatoi/f呼んで謎のSEGVで死んで面倒くさくて折れる、思考停止

何やるにも大抵専用の文があるってのは覚えやすいんだよな、一貫性は無いが
一々添字回して配列集計とかこの関数どのライブラリだったっけとか

>>125
iso_fortran_envは重宝するな
標準ユニット番号が0, 5, 6だとか古い慣習が多いし、人に見せるのは憚られるからと一々マクロ定数振るのも面倒、まあ見せる機会もないけど
良く使う行列演算や型基本的な定義集めたモジュールくらいはカジュアルな俺でも使う、useで好きな識別子にバインドできるのがいいな、今時の言語なら当たり前かもしれんが

ただ、独自型をuseする際にリテラル表記のサフィックスも好きにバインドできるのは珍しい？なかなか便利

>>127
gamma、erf[c]、bessel_(j|y)(0|1|n)まで組み込み関数なのはFortranらしいと思うけど
呼べるかな？で試して使えた/シンタックスハイライトされたみたいなケースがよくある
どこまでが標準なのか良くわからず使ってる

言語としては十分高水準で整ったものだと思う、構造化やクラスシステムはほぼJavaだし
まあ70年の歴史を単系統で積んでるから微妙に変なとこもあるけど

にも関わらず職業プログラマが使うのは皆無なのは文化だろう、カジュアルシリアル問わず、非プログラマがメインユーザーというのが本質
なので使用頻度は高いにも関わらず、プレゼンスが認知されにくい

理数系に進めばまず一応は習うものだし、先に指摘があったように、BASICのように個人用のsoftware toolとしてよく使われ、それは普通公開を意図したものでは無いのがまず一点

もう一点も同様、こちらは数理に長けた非プログラマに好まれること
言語そのものは十分汎用にも関わらず必要な数理の教養(ある種のdomain specifc knowledge)が多過ぎて、職業プログラマがコーディング&リードするのは現実的に無理

2つの主用途が共に、IT業界と独立してるのが普及問題の障壁

今でも最速言語(多いに実装によるが)というのがFortranの強みとしてよく挙げれるが、この2点の方がより本質だと思う

javaとのOOPの類似は設計がGuy L. Steeleだからだろう
common lispとscheme考案したlispハッカー
さすがにlispのOOPシステムCLOS/MOP(とschemeのCLOS-like OOP)とはかなり違うけど、まあ権威

複素数そのまま扱える

使えるなら使ってりゃいいわけで、自分が開発したわけでもない他人様の言語の優劣をアホみたいに争うバカが多くて困る

>>132
最後はHaskell由来かな？

x=[1]; do; print*, x; x=[0,x]+[x,0]; enddo

integer, allocatable :: x(:)

スプレッディングで動的配列を育てるイディオムが趣深い
なおx(:, :)とランクを上げていくと…

[ ... ]は遠いむかしに配列構成子(\ ... \)の略記と習ったのだが、2xxx以降で随分拡張されてるみたいね

未だに無数のベンダーがプロプライエタリなコンパイラ売ってるのはcommon lispとFortranくらいでは
もうフリーで良い処理系なんて沢山あるし、商用もお試し版で十分だったりするが
しかしclもそろそろlispworksの一人勝ちかね？
そのクオリティに加え、試用版が数時間で強制終了するという安売りしない姿勢から、むしろ趣味lisperの高嶺の花となってる

ifortは本当に寛容で有り難いけど、安売りしない道もあったのでは

フリーだとg95を愛用してたが、もう十年くらい開発停滞してて機能不足が目立ちはじめ、同じGNUプロジェクトのgfortran(gcc)に食われつつある
悲しい

あ、Visual Studioを忘れてた…

>>142
g95の人は優秀過ぎて某Fortranコンパイラベンダーにヘッドハントされた

>>108
金利計算にCOBOLは最適だからよ
勝手に丸めたりしない10進デシマル

2進デシマル

>>54
ベクトルだよベクトルな
並列計算

>>128
実は
扱うデータがどんなものかで計算速度が違うから
アルゴリズムだけみていたら間違う可能性がある
結局結果を求めるのに正確性か
いや正確でなくともある程度で早く切り上げてくれる方がいいのか
という実利面がある

AIが当たり前になってきた今は正確性より
判断に使える程度の確からしさでいいから早めに
という
ヒューリスティックもよく言われるだろ

アルゴリズムも目的に応じて取捨選択するものだしね

つまり計算ってなにという

ベクトルとは行列計算のこと

AI と fortran は関係あるのか？
AI様がアルゴリズムを選択してfortran使う？

過程を人間に見せる必要はない。
aiは結果だけ見せれば良い。

aiとfortranは今後も交わる事は無いのでは。

>>149
大丈夫か
とりあえずWikipediaのベクトル計算機くらい眺めてみとりあえず

>>151
aiは神が作ったとかおまえ思ってんだろ
あ〜あ

そもそもaiって言葉が素人騙しなんだよな
ニューロンとか言ったりするからな
全く違うのに

インテリジェンスを知能とか訳してるのに
脳とかとすり替えたりしてんだろおまえら

参加できそうな話題だと思ったけど、やっぱりレベルが違った　ごめん

ニューロンなんて考え方は
それまでのバイナリがオンオフスイッチだったのを
多段階にしてるくらいのもんだからな
大した話じゃない

AI さんがインプットに使うパラメータを準備してくれるだけでもいいかも。

>>153
ベクトル=行列 であることは知ってるよね?
その計算に特化しているのが
ベクトル計算機ということも。

>>49
呼んだ？
フォートランの歌も背理法の歌もI/Oで知ったわ

>>152
https://qiita.com/implicit_none/items/8229d1931cd236d62ca9
CUDA Fortranというのがある
頑張って書けば出来るかもなｗ

まあユーザー数が少な過ぎて今後の発展が望めないだろうな

スカラー、ベクトル、マトリックス、テンソル
自然数、整数、有理数、実数、複素数

>>154
スレを見てる人間はもう少し合理的だと思う。

>>159
どのパラメータが適切か判断するのを自動化したいって事かな。

FORTRANが未だに使用されているんじゃない
時代に合わせ進化したから今でも現役なのだ

以前も書かれたが職業プログラマ向けの言語では無いって事が他の言語との違い。
ツールとして関数電卓の延長なのだろうね。

>>166
進化したところ使ってる？

素粒子物理学に必須級のソフトウェア「FORM」の保守はたった1人の老科学者が担っている、新しい機器では使えなくなり研究が停滞する危険性
https://gigazine.net/news/20221207-particle-physics-computer-program-maintenance-retiree/

https://en.m.wikipedia.org/wiki/FORM_(symbolic_manipulation_system)

言語そのものというよりドメイン固有知識が多過ぎて職業プログラマが触れるような物ではないから、互換性を保ちつつ進化していくしかないよね

clerだけどまさにFortran勉強中
Fortranは義務教育的なモノゆえhacker文化と相容れないと思われがちなんだと思うけど、俺が本当のhackerとリスペクトしてる人の第一言語もFortranなので惹かれる

基本が個人プロジェクトだから、経験に基づくtips&tricksが集積されがたい、マメなブロガだから検索するとかなりの量がヒットする
非常にhackしがいのある言語に思える
希少なリソース

この人↓
GNUのscheme処理系guileと無数のschemeライブラリのメンテナ、大手jsエンジンv8, jscore, spidermonkey(chrome, safari, mozilla系 &c)コミッタ
http://wingolog.org/projects/

>>168,169
FORMは聞いたことないな
数式記号処理といえば、まさに記号処理の為に産まれたlisp実装のMaxima(とMacsymaのフォーク)が、機能面も数値計算(float/rational)も他の追随を許さないと思ってた

優しいUIで売ってるMaple/Wolframと比べる記事の意図がわからんけど

実際、記号処理システムは各言語にあるけど、ほぼ全てMaximaのバインディング、というかタダのラッパでしょ？
(最近流行ってるpythonではSymPyってパッケージ)
なのでにわかには信じがたい話

でもまあ、Fortranは型システムと型パターンマッチが充実してるから、記号処理をフルスクラッチ実装するなら明らかにcより楽
lex/yacc的なインフラがあるのかは不明だし、ML系の方がもっと楽だけど

ごめんSymPyのmaximaバインディングはオプショナルだわ、Maximaフロントエンドは対抗馬のSage(Math)の方
ライブラリとしても引けるけど、かなり改変されたPythonインタプリタとしての使用が主な方言だから馴染めず、すぐアンインストールしてしまった

ソフトウェアだけどプログラミング言語ではないよね
数式を扱うソフトってだけ

FORM is a symbolic manipulation system. It reads text files containing definitions of mathematical expressions as well as statements that tell it how to manipulate these expressions. Its original author is Jos Vermaseren of Nikhef, the Dutch institute for subatomic physics. It is widely used in the theoretical particle physics community, but it is not restricted to applications in this specific field.[1]

FORM
Developer(s) Jos Vermaseren, et al.
Initial release1989
Written in C
Operating system Linux, Mac OS X, Windows
Type Mathematical software
License GPLv3
Website www.nikhef.nl/~form/

>>169
Maximaも2001年に死ぬ前の1998年にオープンにして今も有志がメンテしてるらしいじゃん
当人が死んでも嫌ならそれは期待しないで別なの作ればいい

>>167
解釈の違いだとは思うが
職業プログラマーというのも千差万別だ
テニスなのかゴルフなのか陸上なのかどれでプロになる？ってのと同じ
仕事があるからその仕事するって立場と
この能力で仕事を切り開くってのもまたプロ
職業プログラマーってのも単に現代的多数派を意図してるだけだろ
時代が昔はFORTRANだけで十分職業プログラマーの言語だったし
今もそれを必要としてる仕事場から見たら立派なプロ用言語

しかも仕事ってのはそれだけで済むんじゃない
プログラミングだけが仕事の職種こそ少なくなってきて

仕事の中身でプログラミングスキルも使う職業が増えている
研究者がプログラミングするのは論文書くための実験と同じレベル

職業実験者がいるとかいないとかいうレベルが職業プログラマーがいるとかいないとか

いま哲学者でも社会学者もプログラミングできて当然
それぞれが必要時に必要な道具をつかう
プログラミングもその一つ
プログラミングのどの言語を使うのかも適時必要に応じて

そういう時代
職業プログラマーなんてのは工場ライン工みたいな存在になってる

>>172
そもそもscipy(numpy etc)の本体はf2pyという自動でFortranライブラリをコンパイルし、呼び出し規約を書き換えるだけのスクリプトなので今更

ビルド違いが沢山あるのはライブラリの実装が沢山あるから
デフォルトでは参照実装リポジトリのwww.netlib.org（分かりやすく書かれているがすごく遅い）からソースを取得してきたり、ベンダ提供の実用実装を使ったりしてるから
intel提供のビルド済Scipyが自炊より数百倍速いのはそういう理由

確かにコードだけ見ればブロードキャストやマスクなど配列演算はFortranより汚い
それでもあえてラップする理由は、対話的に試行錯誤できるインタプリタの利便性
もうバイナリ吐く言語が表に出る時代なんて来ない、永遠に裏方

LISPはREPLも良くて、Cより速いバイナリを吐けるsbclのような処理系もあるけど、見た目がな…

>>174
それがCASというプログラミング言語のカテゴリ、気軽にwebで使えるWolflam Languageを想像すれば
素論特化なら確かに代えは効かないかもね、需要も少ないけど

>>177
Maximaは実装も言語もlispなのに、妥協して代数風のinfix糖衣構文を提供してるし、lisp自体が取っつきにくいのは認める
コンパイル専用言語をラップする意義も分かる

しかし、UIも対話性も標準的なインストール手順で、Python+SciPy+Sage+matplotlib…の環境より優れているMaximaをラップする意義は何なんだ？

https://maxima.sourceforge.io/
この公式HPの美麗なGUIと平易な言語を見て、同等の環境構築をすると10GB、おまけにライブラリ依存地獄のPythonを科学計算教育用途に選ぶ風潮が全く理解できない

ちなみにpure pythonは好きだぞ、むしろプライベートで一番使ってる言語
小道具作りたのしい

要するに、なんか世の中変な方向に向かってね？という話

知名度は最近落ちてきてるように感じてるが、リリースを見るとむしろ活発に開発進んでるのか
やはりバックエンド需要？

こういう歴史あるソフトウェアこそ素で使った方が快適なのに、皮肉なものだ
素というかプロットソフトやら各種ツールの連携した環境と言うべきだけど

世の中は何でもパイソンブームだが、本当のITリテラシーを身に着けるにはこういう疎結合で柔軟、ゆえにロバストなシステムに触れておくべき
モノリシックなエコシステムに閉じこもるべきではない

https://en.m.wikipedia.org/wiki/Maxima_(software)
macsymaから半世紀以上コードベースが途切れることなく、実装言語と共に進化しつつ現在も活発に開発が続いてるのか
埃被ったユティリティの類を除き、本格的なソフトウェアでこれ以上の物は存在するのだろうか？もはや畏怖

LISPの得意なコード生成で苦手な配列演算やnumber crunchingをFortranに投げたり、周辺ユティリティとの共進化も興味深い

Common Lisp実装を名乗っているようだけど、公的な規格は約30年前くらいなわけで、実態はどうなんだろう？
もちろんほぼCLな無数の実質方言、Common Lisp拡張/準拠(できる)処理系があるのは知ってる

LISPは手習い程度だけど、これはコード覗いてみたい

>>180
Pythonだからモノリシックって発想どっからくんのかね

>>182
それは使い方次第
俺はベターシェルスクリプトであるべきと思ってる
コミュニティがこのままの勢いで突き進めば、間違いなくjsのように歪められてしまう末路

>>178
んーそっすねー
だけど大きく見れば数式は数学の言語だから
数学言語をコンピュータ実行に変えてるのは
工場の生産管理の計算をコンピュータが実行するのと同じで
数式を仕事で使い慣れてる人のためのアプリケーションって見れる

数式はコンピュータの世界とは違うから
その間をうめる計算補助アプリケーション


だからエンドユーザーのシステム環境だよ

ソートのアルゴリズムが複数あるのと同じレベルで微分積分とかをどうしたら効率よく計算するかとかは別で
数式を与えて結果を教えてくれるという上位のシステムだから

python公式ドキュメントも以前は参照実装としてページから参照実装.pyへの直リンが豊富にあった
今は性能求められてc実装になり、直リンが減り、参照実装.pyリンクがあっても冒頭でcモジュールを読み込んでおわり

cpythonはもはや本来の目的を果たせていない、なんとか他の実装に頑張ってもらいたい

>>183
いまはコンパイルとインタープリタの差は実質ないか
そこの違いは少数以外意味なくて
それよりも何に使えるかという視点が重視

PythonかどうかではなくてPythonで何ができるか
今は画像とかテキストとかのAIライブラリが真っ先に使える
このため

統計ならRのほうが使いやすいらしいし
さっきの数式と同じで
エンドユーザーが自分で使って結果を得るための道具

そこにフォーカスかあたってる
同じ結果が出るなら別の言語でも全く構わない
が情報量からクラウドサポートまでそこがフォーカスされてる

そもそもjsをそう思ってるなら立場が違う
あんたがそれを上回る提案をして育てていく何かをあげればいい時代よ
言葉よりも実行

>>186
計算機は計算機だよ

Pythonもschemeがr6rsのエコシステムや過剰な規定でやらかした事例から習い、small/largeのように水準分けるって議論はメーリスで度々出てた

schemeの実際の処理系はgauche、chickenを筆頭に、規格を遥かに上回る実用性とエコシステムが自然発生したわけで

asyncキーワードの導入あたりまでの話だけど
デコレータやself/clsなどより重要な機構を保守的に(ナイス)ハックで導入したにも関わらず、一旦構文に手を入れてしまった後はもうズルズルと現状追認

舵取り失敗事例はperl5/rakuだね
perl5の便利さで人を集めすぎ、perl6が形になった時にはもう加熱し過ぎていた
python4.0がrakuにならないよう、早めの舵取りを願う

>>186
Fortranはエンドユーザーの為のものだったからプログラミング言語じゃないね

>>189
当時はそんな区分かない

今も昔もFortranを書く人はエンドユーザーで、書く人の層もそんなに変わってないが、意図せずインフラとしての側面を持ってしまった事を忘れずに

互換性を破らない範囲で保守性を高める機能はもう最大限に拡張されてるが
いくら保守しやすくする為に言語仕様が整備されたところで、書く人が自分が使えれば良い層なので保守性に気を配る動機が薄い

ちゃんと宣言すればJava並みの戒律も課せるが、互換性のため宣言しなければルーズ

オーパーツのようなライブラリをよく目にするから錯覚しがちだが、それは単に歴史が長いからであって、用途からしてFortranでライブラリ化するような大きいプログラムを書く事は稀

機械語やアセンブラがシステム用で
FORTRANが科学技術計算用
COBOLが事務計算用
そういう時代だ

エンドユーザーではなくてコンピュータを使う知識を持ってるやつ用

数式で∑書くより
for文のほうが楽。

>>193
ざっくり領域のΣが一番楽
そのままじゃ解けないけどｗ

それを真面目に書くとfor文になって、

それを数式で書くとk=0を下に、nを上に書いてるようなΣになって
しかもそれが連続する

状況によっては積分記号で書いたりするか
そしてその積分が解析的に解けないものの場合は
またfor文にするｗ

後はΣじゃなくて掛け算のΠになる式を使おうがご自由に

>>181
人類の叡智だな

◯（ ´∀｀ ）◯ ＜ 僕のBASICはコンパイラちゃん！

関数型プログラミングだとfor文はご法度なんだよね？

代わりにどう書くの？と素直に疑問

>>18
既にあったか…

C++が出来たころ、
C++からFORTRANのサブルーチンを呼び出すコードを書く作業を延々としていた記憶

>>198
再帰

再起だとLISPかPrologか。
見事に消えたが。

FORTRANって体育会系のかほりがあって嫌い
文化系帰宅部はCっしょ

Cはエリートが使う言語で、プログラムできない人でも結果出す為に使うのがFortranだと思ってた。
Numerical Recipes in C とか頑張ったの？

>>202
リブートしちゃうぞ

>>203
CはUnixマシンのシステム言語
FORTRANは旧来型マシンの科学技術計算言語

まずマシン環境が違う
システムを弄るためのCだ
システムを知ってることが前提
というかUnixと一体だ
Unix作るための言語だったから
だからCならUnixのなんでもできる


FORTRANはサイエンティストが使いやすいように
それまでのホストマシンのアセンブラに一枚噛ませた言語
それまでのホストマシンはマシン独自のアセンブラでCのようなシステムだけど汎用って言語層がない

比べるのが間違い

>>204
わかってないね

CはOSとしてのUnixと一体
旧来型ホストマシンはCPUも独自マシン言語
そのアセンブラも独自アセンブラ
そこで動くOSもアセンブラで書いた独自OS
その独自OSの上でサイエンティフィックな視点でプログラミングできるようにしたのがFORTRAN
事務計算で金利計算まで丸めずにできるようにしたのがCOBOL

時代が下ってミニコンの研究者用OSを作るために作ったのがC
Cで作ったのがUnix
Cはミニコンのアセンブラをラップしてる

それぞれがいいものだったから移植されていろんなマシンで動くようになってる

がそれぞれの生まれ持った特長はそのまま

>>206
FORTRANを使うにはサイエンティフィックな知識が前提

Cはシステム知識が前提

FORTRANでOSをカスタマイズするようなことはしない

Cは何でもできるから科学技術計算に使ってもいい
ただしそのためのライブラリがなければ一から自作しないといけない
いまライブラリあるのはそれを作ってくれた人のおかげ

Cなら同様になんでもできる
その反対に手間と時間がかかる

言語ってのは手間と時間とカスタム度合いを天秤にかけて必要に応じて使うもの

日本人がよくあるのは
ライブラリとか言語そのものとか
作ってくれた人がいて
その人がどんな必要性から作ったのかがあるのに
そんなことは知らないやつが多いこと

海外から出来合いものを持ってきて
俺様が持ってきたんだおまえら知らねーだろ
みたいに自慢し合う

たから自分で発展させていくことに想いが至らない

日本が世代間でケンカするのもそういう引き継ぎがないから
いつも新しいものを横から持ってきて
おまえら知らねーだろ
ジジイ！
こういう感じ

作った人のことをしれよ
どんなふうに変化したのかを人の歴史として語れよ
そうすれば世代間ケンカなんてなくなる

英語の世界ではライブラリとか紹介する時にどこどこの誰々が作ったライブラリって紹介されることもよくある

日本じゃ天から降ってきたみたいに元からあるようにしか紹介しないどころか
使い方を紹介してる翻訳者の大学の先生が偉そうにオレが作ったように書いたりしてる

>>202
LISPは消えてない
いろんなところに影響し続けている

>>208
違うぞ。Unix の開発当初はアセンブラ。Cで書き換えたのは開発開始から4年後。

>>213
はい訂正入りました
ありがとう

という積み重ねよ

書きやすくて読みやすければCでもFortran でもRatforでもいいよ。
コンパイラ作るの他所の人だし。
って、天の声が聞こえた気がした。

システムの発展もOSの発展も言語の発展も
こういう細かいことをみんながやってきたから

だーんと突然できたわけじゃないし
敵と敵が戦うだけじゃできない

敵にしてるのはビジネスだから
作ってる側は敵も味方もない

その代わりビジネスになると
理由や温情なしに
生き返ることのないよう徹底的に叩き潰せ
ってのがアメリカ

昔、FORTRANで仕事してたってけ。
好きな言語だったよ。
高速道路の長大トンネルの制御プログラムで
水噴霧パターンを当時覚えたばっかのビットマップで組んだ。
PL/1も使ってたなあ。
情報処理試験でPL/1を選ぶと簡単だった。
そういや本物のプログラマはPascalを使わないとかいうコピペが出回って
プロはFORTRANを使うのだみたいなことが書かれていたっけ。

>>181
lispはFPUを想定せず設計されてるから基本的な浮動小数点の罠に引っかかりにくいとか？

CL/schemeですら未だ数値型は基本有理数、リテラル1/3はそのまま1/3だし+-*/等の基本演算も有理数を返しオーバーフローも無い、数複素まで断らなければ有理係数
特にschemeはexact->inexactでfloatへのキャストや超越関数で警告出て非常にうるさい

fortran触って珍しい機能と思ったのはpointer(type, pointer :: p)だけじゃなくそのpointee(type, target :: x)を宣言するところ
コンパイラへのヒントなんだろうけど、書く側読む側にも分かりやすい
確かオプションか宣言しない限りは無くても動いてしまうはずだけど

デフォルトが参照渡しだしポインタ算術も無いから、あまりポインタ使う機会も無いんだけど
やはり型をパラメトライズ(制限)して使うジェネリックコンテナ作る時にポインタはあると便利

>>219
今はもう整数無限精度が標準の言語は多いし、浮動小数点がデフォルトでも有理数は標準ライブラリ提供の言語は多いけど、それでもlisp系標準の無限精度有理演算は簡単な線型代数に便利よね
掃き出し法等多くのアルゴリズムは四則演算のみだから、際どい0判定の必要なピボット選択がzerop/zero?だけで済む
分母分子が大きいと今のPCですらアホみたいに遅いから、シュミレーションやCG用途には全く使い物にならないけど

浮動小数点を扱う線型代数ライブラリは本当に凄いと思い知らされる、誤差伝播の上界伝播ロジックやファインチューンされたill-conditionヒューリック判定の塊

数値型の値一つが無限にメモリを食い潰す可能性があるから、全てのオブジェクトを定幅ポインタで扱う言語でないとそういう配列は面倒だな
分子分母を格納した構造体へのポインタ配列なんだろうけど、無理数の出るケースも考慮してfloatとのタグ付きユニオン型である必要もある

分子分母も無限長整数だから、動的割り当て配列へのポインタを格納した構造体とのユニオン型へのポインタの配列だな
電卓としては便利だろうが、パフォーマンスはそりゃ絶望的だろう

賢い人の書いたfloat演算ライブラリ使ってりゃok

そこで逐次評価をせず代数的に簡約する記号計算の出番ですよ、数値計算の代替にはならないけど

lisp系で有理数型がプリミティブなのは悪手だと思ってる
可能な時は約分してメモリを節約という涙ぐましい努力はしてるけど、それでも無限に時間とメモリを食う入力はいくらでも選べるから、サーバで不用意に外部入力を受け付けるとDoSで死ぬ
外部入力の評価は一般的に危ないけど、ただのプリミティブ数値型の四則演算で死に得るというのは、意識されにくいかなりの落とし穴
念入りな消毒が必要だから、むしろ自由に切り離せるライブラリ提供の方が面倒が無い

OS管理とかで
「logファイルの差分を取って増分に対して処理する」
という表現に対して

差分って数学的な用語に限定して欲しいなあ

って考えてしまう人も世の中に一定数いるんだろうかｗ

>>225
無制限に肥大するのは例えばループで値を累積するような時であって、バッファのサイズで制限すれば問題なくね？
入力の数値型がnバイト、任意だから簡約も出来ないとして、累積乗算(*=)すれば1ステップでn^2バイト、2ステップでn^3バイト、k-1ステップでn^kバイト、指数関数的に増えるという話で
例えば初期値の分子分母が8バイトでn=16バイト表現を想定すれば、たった10ループで8GB
時間的にもギガ桁の乗算とか無理だし、意義のあるループ(数回なら書き下せばいい)を使うアルゴリズムに有理型は実質使えないというだけ

ループ無しでバッファを10文字+まで制限すれば四則演算くらいは何とかなりそうなものだが、実際に無限長整数の言語でもsanitizeされたevalは許されてる
有理型は乗算より足し算の方がヤバい(乗算を必要とする)ので、見積もりが甘過ぎるとは思うが

そもそもlispでevalは本当にヤバいからやるな
式でなくフォームから決まった数のリテラルを読み取ってリストにするだけでマズい
#1=全てのリテラル表記全#1#が自己/相互参照をサポートしている
ちゃんと無限サイズのオブジェクトとして評価されるが、バッファが定数文字と思って不用意にアクセス舐めたら無限ループ
他にいくらでも罠がある

そもそも言語の評価器を流用しようという発想がそもそもの間違い、四則演算や文字列のパース程度くらい自分でやれ

πを計算させたらおちた。

>>228
なんだこれ
再帰やジャンプまでできてしまうのか
さすがエイリアン語

関数や演算子なら空環境渡してevalを制限できるけど構文なら回避不能だな

愛すべき古き良き計算機言語たち：
FORTRAN
COBOL
LISP
C
Pascal
Ada
BASIC
SQL
Smalltalk

>>232
Algol
Lisp
APL
SNOBOL
CLU
C++
Haskell

あなたはこのスレッドにはもう書けません？