COBOLが長いあいだ「死んでいた」とする祖父の記録
(wumpus-cave.net)- 1992年6月の Technical Support 誌に掲載された文章はすでに COBOLの死 を宣言していたが、30年後になってもその言語が完全には消えていないことが要点
- 当時の 4GL のような流行語の大半は長続きしなかったが、COBOLは多くの後発の代替より長く生き残った 事例として残っている
- COBOLを動き続けさせた決定的なきっかけは Y2K問題 であり、実際の対応では新しい COBOL プログラマー世代を訓練する必要があった
- かつて導入基盤が大きかった言語は突然消えるのではなく、新たな学習者が減る ロングテール を残しながら維持されうる
- 筆者の祖父は2024年9月1日に91歳で亡くなり、個人的な回想と古い技術予測が重なり合う文章となっている
1992年にすでに出ていた「死んだ COBOL」宣言
- 筆者の祖父は1992年6月、Technical Support 誌に COBOL の死を宣言する文章を発表した
- 当時の文章には 4GL のような時代を感じさせる用語が登場し、筆者は Wikipedia の 4GL の例示一覧のかなりの部分よりも COBOL のほうが長生きしたと付け加えている
- 原文テキストは NaSPA アーカイブに残っている: http://www.naspa.net/magazine/1992/t9206003.txt
- 1992年の文章は
deadという言葉の意味を分け、COBOL を死んでいても消えてはいない Zombie のような存在として扱っている- Autocoder も COBOL の前身として紹介され、死んだ言語と見なされつつも一部の痕跡は残りうる例として比較されている
Y2Kが生んだ COBOL の長寿命
- COBOL ゾンビを動かし続けた大きな要因は Y2K問題 だった
- 当時はニュースで大きく取り上げられ、その後は何事もなかったように見えたが、実際には巨大な問題だった
- 対応の過程で、新しい COBOL プログラマー世代を訓練しなければならなかった
- この過程が COBOL をより長く維持することに寄与した可能性がある
- 筆者は今ではプログラミング言語に dead という表現をあまり使わない
- かつて大きな導入基盤を持っていた言語は完全に死ににくい
- その代わり、新しいプログラマーが学ばなくなりながら徐々に薄れていく ロングテール を残す
個人的回想へとつながる技術史の一場面
- 筆者の祖父は2024年9月1日に91歳で亡くなった
- 公式の死因は肺炎
- 祖母はその年の4月に亡くなっており、祖父は治療を受けないよう求めていた
1件のコメント
Hacker News のコメント
記事で 4GL に触れているが、本当に久しぶりに聞く用語だ
COBOL も「人間が読む文章のように見えるので、もはやプログラマーは不要になる」という約束を掲げていたし、これは最近のローコードプラットフォームや LLM 生成コードに似ている
問題は、普通の人は動作する解決策が出てくるほど十分に詳細に問題を説明し、分解できないことだ。そのプロセスをやり遂げれば、結局プログラマーになるわけで、COBOL の核心的な教訓は、プログラマーが必要な理由がコンピューターのインターフェースや言語だけにあるのではない、という点にある
業務プロセスをよく知る人が、コンピューターの動作方式をあまり学ばずに COBOL へ書き写せるようにする、という方向に近く、SQL でデータベースと対話するアナリストやデータ担当者に似た面がある
COBOL と 4GL は、給与、銀行、人事、在庫のような 業務アプリケーション の構築が主目的で、とくに精算のような反復的な大量作業を減らすバッチ処理に焦点があった
専用 DBMS がなかった時代の産物なので、ファイル構成やファイル関連の動詞が非常に発達しており、今日の SQL に似た部分もある
LLM が魔法のように解決策を生成するとしても、問題を簡潔かつ正確に表現しなければならない責任が上流へ移るだけだ
結局プロンプトで「プログラミング」し、LLM が提案した形式化された成果物であるコードをレビューすることになる。プログラミングの性格がプロンプトエンジニアリングへ変わることはあっても、形式言語であるコードを理解しなければならない作業は残る
記事では 1990年代初頭に 4GL が大流行したとしているが、メインフレームの外でもそうだったのかは疑わしい。4GL 運動は当初から強くメインフレーム志向で、Wikipedia も初期目標として、プログラムに必要なパンチカードの枚数を減らすことに言及している
1992年にはすでに Linux が登場しており、Python の作業も進行中で、Perl は人気を得ていて Haskell も初期バージョンが出ていた。技術の最前線は高価なワークステーションから消費者向け PC へ移りつつあり、言語設計者たちは dBase、HyperTalk、AppleScript のように結果的に 4GL と見なせるものを作るときでさえ、4GL という概念をあまり意識していなかったと思う
自然言語のようなテキストがほとんどのプログラミング用途にとって悪いアイデアだという点には同意するが、4GL 運動が失敗した理由はそれだけではないと思う。大半の 4GL は、3GL である COBOL より自然言語らしかったわけでもなかった
より大きな問題は、4GL 運動が新しい世代とは何か、何が有用なのかをきちんと定義できなかった点だ。2GL はアセンブリから機械語への翻訳、3GL はコンパイルという革命的変化をもたらしたが、4GL でどうにか定義できる変化は「外部ルーチンやライブラリにあった機能を、もっと言語内に取り込もう」程度だった
このアプローチはドメイン特化言語ではうまく機能し、そのため SQL、R、MATLAB のような成功した 4GL が生まれた。一方で汎用 4GL という概念は、結局は過度に肥大化した言語へ帰結する運命だったと思う
今日では、そうしたことができる、あるいはする必要がある人はほとんどいない
この文脈では Scala が思い浮かぶ。記事でCOBOLを描写しているやり方で見ると、Scalaも実質的には死んだ状態に近いと思う。
いまでもScalaで書かれた中核コンポーネントを持つ企業やサービスは多いが、新規プロジェクトでの関心は大きくしぼんでいる。
2012〜2014年ごろはHNで「ScalaでXをする」記事をずっと見かけていた気がするが、今ではほとんど見ない。自然で避けられない現象なのかもしれないが、Scalaには他の主流言語がいまだに拾えていない良さがあったという点では惜しい。
テストシステムのように社内エコシステムにとってかなり重要なプロジェクトもあり、かつてこうしたシステムを作ったエンジニアたちは今ではほとんどが上級管理職になっている。
当時の技術選定を今も支持している人もいるが、振り返る機会を与えると、よりオープンな姿勢を見せる人もいる。全体としては、当時Kotlinがあったり、Swiftがバックエンドサービスに使えるものだったりしたら、Scalaは選ばなかっただろうという雰囲気だ。
https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2...
初期の過熱は冷めたが、それで問題ない。どの言語にも過熱のサイクルがあり、予測もたいてい外れる。主流のプログラミング言語は、もはやCOBOLのようには死ににくい。
Javaは2001年から死ぬと言われていたが、ドットコムバブル、.NET、LAMPのP、Ruby、JS、Goをすべて耐え抜いた。Pythonもバージョン3への移行時に、人々がRubyへ移っていき、死ぬだろうと言われていた。
Scalaは世界で最も人気のある関数型プログラミング言語であり、ツールとライブラリが優れていて、Scala 3は素晴らしいアップグレードだと思う。
かつては非常に大きく、どこにでもあるように感じられたが、今ではだんだんニッチへ追いやられている。COBOLと同じように、実際の現場にはPerlのコードがまだたくさん残っている。
Jack Henry、SiriusXM、Starbucks、Disneyのストリーミングサービス、Capitol Oneも、過去5年から現在にかけて、データサイエンスではないサービス部門で Scalaの新規プロジェクト を作っている。
もちろん他にも多くのチームがあるが、すぐ思い浮かぶ有名どころだけを挙げてもこの程度はあるので、死んだとは見なしにくい。
ただし、PlayやAkka中心のフレームワーク系の求人や、Airflowではない純粋なSpark作業は減っているように見える。これらはScalaエコシステムから生まれたフレームワークの仕事だっただけで、Scala自体は副次的だった場合が多かったのだと思う。
Scalaは好きだが、ずっと 周縁的な言語 だったし、COBOLは本当にどこにでもあった。
いつかFortran、COBOL、Ada、APLのような レガシー言語 を、実際に腰を据えて触ってみるべきだと思っている。
人気は確かに落ちているが、今でも重要な場所で使われている言語だ。
同時に、膨大な量のJavaコードも思い浮かぶ。Javaは良くも悪くもエンタープライズ領域をほぼ食い尽くしたが、30〜40年後には、退職者だけが古い銀行システムを保守するためにJavaを使う、という姿になる理由があるのだろうかとも思う。
巨大な単一コードベースやプラットフォームであることも関係していそうだ。言語が難解で難しいわけではなく、単に構造が見えにくいコードがあまりにも多いだけだ。
今後100年にわたって、市場の0.05%くらいは占めるのではないかと思う。
ただしここ数年、新しいコードの大半は Kotlin で書かれている。
個人的にも愛着があり、90年代に会社でPC上で実際に使っていた。データをどう取り込むかを突き止める仕事で、最終的には浮動小数点数を1と0のベクトルのように扱い、ビットを変更してMicrosoft形式からIEEE形式へ変換するルーチンを書いた。
もちろん、ベルトに玉ねぎをぶら下げていた時代の話だ。
純粋な数値シミュレーションをするなら、C++やPythonよりFortranを好むと思う。NumPyを除けば、という話だが、NumPy自体も結局はFortranとC++に依存している。
2025 Carolina Code Conferenceでは、今も COBOLの発表者 を探している。
特にGnuCOBOLが最近更新されたこともあり、しばらく前からCOBOLの発表を入れたいと思っていた。
https://gnucobol.sourceforge.io/
https://carolina.codes
「2000年の言語がどんな姿をしているかは分からないが、名前はFortranだろう。」—Tony Hoare
COBOLは時代ごとに変わり続けてきたので、生きていると見なせる。現代のCOBOLは、人々がその名前を聞いたときに本能的に思い浮かべる1950年代のCOBOLとはかなり違う。
まるでJavaがAlgol-94のような名前で呼ばれていて、そのために私たちが今もAlgolでプログラミングしていると言うようなものだ。
MULTIPLY A BY B GIVING C ON SIZE ERROR STOP RUN.のような書き方はしない。<https://dtss.dartmouth.edu/sciencearticle/index.html>
COBOLは死んではいないが、取っつきにくい。Linuxで使えるオープンソースツールがほとんどないためだ。
OCamlProでは、GnuCOBOLオープンソースコンパイラを中心にオープンソース環境を作るため、SuperBOLというプロジェクトを始めた。GnuCOBOLはすでに成熟しており、企業でも使われている。
すでにCOBOL用LSPを組み込んだVSCode拡張を公開し、現代的なIDE体験を提供しているほか、顧客の要望に応じて他のツールにも取り組んでいる。
COBOLは1日か2日あれば学べるし、「退屈な」COBOLの仕事をしてみたいが、メインフレームの経験がない。
https://gnucobol.sourceforge.io/
https://cobolworx.com/pages/cobforgcc.html
いつものことだが、こうした議論は「死んだ」と「生きている」をどう定義するかにかかっている。
ある技術の上に新しいビジネスがもう作られていないなら死んだと呼べる、というなら、COBOLは死んだと見なして差し支えない。一般にCOBOLの代名詞のように使われるIBM 390x、つまりZ/OSプラットフォームも同様だ。
逆に、本番環境でまだ使われていれば生きていると見るなら、COBOLは当然生きており、自分より若い多くの技術よりはるかに生きている。
ただし、それをCOBOLやメインフレームエコシステムの長所として受け止める必要はない。組織は最初にうまく動いたものを握り続ける傾向があり、初期のデジタル化の主役だった政府、銀行、航空会社のようなところでは、その最初の選択がたいていIBMメインフレームとその上のソフトウェアだったというだけだ。
私たちのメインフレームは、1時間あたり1億件のトランザクションを余裕で処理する。しかもその大半は同期式で、各トランザクションが複数のSQLトランザクションにつながっている。
結果整合性も方法ではあるが、金融分野とは非常に相性が悪く、軍事・保険・医療・保健でもおそらく同様だろう。作業をパーティションに分けることもできるが、シャード境界を越えると整合性の問題が生じる。
COBOLはまだ死んでいないが、ゆっくりとそちらへ向かっている。メインフレームから脱却しようと積極的に取り組んでいない銀行を私は知らない。それでも、予測ではメインフレームとCOBOLは少なくとも2050年までは残ると言われている。
つまり、今後26年間はCOBOLコードを書くということだ。COBOLプログラマは需要も高く報酬も良いほうなので、今COBOLプログラマとしてキャリアを始めても、ほぼ一生に近い勤務期間を埋められる。
参入障壁は常に極端に高く、当時の主要顧客も古くからの保険会社、銀行、政府のようなところだった。新しい会社がコンピューティングを行えるようになったのは、ミニコンピュータ以降に近い。
その意味では大きく変わったことはなく、製品のターゲット市場を考えると、プラットフォームの生死を判断する基準として「新しいビジネスが使っているか」は適切ではないと思う。
新しい事業部や社内スタートアップチーム、たとえば新しい保険商品のカテゴリであっても、銀行の他のシステムと統合するには一部をCOBOLで書くことがある。
少なくともCOBOLで直接書かないとしても、新しいx86ラックとそれを管理する人員を買う予算がないため、既存のCOBOL実行インフラ、つまりZ/OS上に載せることもある。
クラウドは新しいメインフレームだが、より悪い版だ。欠点はすべて備えているのに、最大の長所はない。
かつてはCICSで非常に安定して高性能なサービスを作り、同じトランザクション内で別のサービスを呼び出せた。プラットフォームがデータ整合性の維持のような複雑な仕事を処理してくれていた。
同じトランザクション内で互いに呼び出し合うAWS Lambdaを一度書いてみれば、その違いが分かる。
それに、なぜ比較対象が「同じトランザクション内で互いに呼び出し合うAWS Lambda」なのか分からない。メインフレームへのデプロイも、開発者にアクセス権を与えたAPIにコード入りの
.zipを投げ込むのと同じくらい簡単だったのだろうか？一部の人が、私がモダンな言語よりCOBOLを選んでいる、あるいは好んでいると受け取って批判しているが、そういう意味ではない。枠の外から見た悪魔の代弁者的な観察をしただけ
皮肉なことに、Rustより読みやすく理解しやすい、メモリ安全で安定した言語はCOBOLとしてすでに存在していた。しかし誰も使いたがらないため「死んだ」言語になり、実際には現代を可能にしたシステムはその上で動いている
例として、数値を入力して偶数・奇数を出力するRustコードとCOBOLコードを比べると、COBOLのほうがより直接的に読める
同じレベルの性能を出せるのか、他の言語のネイティブコードと同じように連携できるのか、合成と後方互換性を助けるモジュールシステムの上で使えるパッケージマネージャがあるのか、Rustの代数的データ型のようにデータやエラーの形を手軽に表現できるのか分からない
COBOLが今も使われているのに理由があるように、新しい言語が作られたのにも十分な理由がある
実際に必要なボイラープレートを付けて実行可能なCOBOLプログラムにすると、
abcの入力に対して「even」を出力し、12の入力に対して「odd」を出力するRustの構文を特に問題視するのも変わっている。最近の多くの言語と同様、RustもおおむねC系の構文で、OCamlの要素が少し混ざっている程度。構文はさておき、RustとCOBOLは目的が大きく異なるため、「ただCOBOLを使えばいい」でRustの存在理由がなくなるわけではない
https://www.ibm.com/docs/en/cobol-zos/6.2?topic=statement-ex...
ALLOCATE、ポインタアドレスの設定、FREEのようなコードが登場するこのツイートが妙に良い
https://x.com/grauhut/status/1000017084435312642
訳すと「顧客先でCOBOLを見つけた。大丈夫だ。メインフレームだ。特別なことではない。最後のコメントは1985年のものだった。書いたのは私の母だった」という内容