どうもIT系の世界ではCOBOLは悪者にされやすい。たとえば、

2000億行もの負の遺産――COBOLコードの近代化はどのように進めるべきか

とか。

悪者にしたい気持ちもわからないではないが、「それはCOBOLのせいじゃないだろう」なことまでCOBOLのせいにされてしまっているのが気の毒だ。「COBOLのせい」にされているもののうち、何割かはCOBOLのせいじゃないし、それはCOBOLのせいじゃないが故に、他の言語やプラットフォームも陥る危険がある。その辺を正しく切り分けておかないと、「今時流行りのもの」もいずれ「○○は悪者」「○○は古い」になってしまう。

忘れちゃならないのが、今は「古いもの」の代名詞となっているCOBOLであっても、出た当初は最先端のバリバリだったということ。つまり、「今」最先端でバリバリだと思われているものであっても、何10年かすると「過去の遺物」とされる危険があるということだ。

という話をすると、すぐ「LispはCOBOLと同じくらい古いけど、過去の遺物じゃない」という反例を挙げる人がいる。それは確かにそうなんだけど、Lispは「汎用言語」としての過去を持っていない。それゆえ使う人が少ない。そういった「一部の人達」にウケているだけだから、「Lispは古くならない」というのはまずちょっと割り引く必要がある。と共に、世の中の言語は2つに分けられる。それは、

Lispかそうでないか

だ。今使われているLispは、40年前のLispとは別のLispだ。現代のLispとどれくらい違うかと言えば、アセンブラとRubyくらい違う。Lispは「括弧つけてる」というただそれだけの特徴でLispであって、その背景に括弧以外に確固たるものがあるわけじゃない。格好は同じでも、まるっきり別の言語になっていると言ってもいい。だから、「Lispは古くならない」なんてのは、「どの言語にも代入文があるから同じ言語だ」というくらい乱暴なのだ。そんなわけでLispの話は除外だ。

実はCOBOLも似たような側面がある。40年前のCOBOLと今のCOBOLでは、アセンブラとRubyくらい違う。まるっきり違う言語と言っても良いくらい違う。でもCOBOLとLispが違うのは、そういった「40年前のCOBOL」で書かれたソースであっても、現代のCOBOL(ISO 2002)で問題なくコンパイル出来てしまい、問題なく走ってしまうことだ。Lispはいろいろ異なる言語になって発展したのだが、COBOLはそうじゃない。全く同一の言語に機能を加除したことによって現在の言語仕様がある。除かれるのは仕様にあっても実装されなかったり、(ほとんど)使われなかったりしたものだけだ。つまり、常に完全な上位互換性があったわけだ。

言語に完全な上位互換性があって、永年使われて来ると何が起きるかと言えば、

新しい言語仕様を学習しない

ということが起きる(*1)。新しい機能が実装されるのは、言語仕様が発表されてから数年かかるし、古い処理系では新しい機能は使えないということもあって、なかなか新しい言語仕様が定着しない。すると何が起きるかと言えば、

スキルの停滞

が起きるのだ。つまり、プログラマが新しい機能 — それは時代の流れに合わせて追加されている — について学習しようとしなくなる。また新しい機能にはバグがあることが少なくないから、そういった意味でも「新しいもの」を使わないし、それは「良いこと」とされてしまう。つまり、プログラマの知識が古いままで固定されてしまうことが起きてしまうわけだ。

その結果、今ではごく常識でしかない、動的な諸々とか、OOPや構造化、あるいはモジュール化といったことを、プログラマが学ばない。つまり、古い技術で仕事をしてしまうわけだ。だから、「COBOLのせい」とされていることの、何割かはそういった「古いタイプのプログラマ」が「古い技術」を使い続けてしまった結果だ。件の記事に、

プログラム開発者というものは最先端テクノロジを好むものであり、プログラミング言語、開発環境、開発ツールなどはいずれも最新のものを使いたがる傾向にある。実際、プログラミング関係の参考書やコンファレンスはどれも、Java、Ruby on Rails、C#、Ajaxなどのタイトルで目白押しだ。

なんてことが書いてあるのだが、これは「嘘」だ。確かにその傾向を持った人は大量にいるし、そういった人達が「新しいテクノロジ」を支えているのは確かであるが、世の中のプログラマはそんな人ばかりじゃない。

いや、実は「最先端テクノロジを好むプログラマ」だって、「普段使いのもの」はそうじゃない。だって、いまだに「普段使いの言語」で何でもやりたがるし、そういった「何でも出来る言語」が大好きな人は多い。エディタは「ここ20年ばかりEmacs」な人は大勢いる。「新しいもの」に飛びつくのは、それまでのものに不足があったからであって、「それまでのものに満足」していれば、そんなことはしないのが普通の人だ。もしプログラマが最先端テクノロジを好むだけの人達であれば、エディタにEmacsを使い続けているのはおかしい。

「COBOLの問題」というのも実は同根で、COBOLのプログラマ達が「それまでのものに満足」している結果、新しいものに手を出さない。だから、いつまでたっても古いテクノロジが使い続けられてしまって、新しいテクノロジから見ると「時代遅れ」になってしまっている。たったそれだけのことがほとんどだ。そして残りの何割かは、「マトモなドキュメントがない」ということが原因だ。そうして調べ挙げれば、

COBOLという言語の問題ではない

ことがわかるはずだ。

COBOLにどっぷり漬かると、プログラマライフは結構快適だ。COBOLさえあれば、たいていのことが出来てしまう。私がかつてCOBOLしか使えない環境にいた時は、COBOLで簡易言語の処理系まで書いていた。つまり、その程度には汎用言語なのだ。友達がstdio的な処理に使える入出力ライブラリを作ってくれたのがあったので、ツールはホイホイそれで作れた。

幸いなことに私は他の言語がもっと快適であることを知っていたし、本当に「新しいもの好き」だったから、心の底までCOBOLに染まることはなかったけれど、「プログラムは仕事」と割り切った人なら、十分に染まり切ったことだろう。

そうやって「古いもの」に縛られた結果が「COBOLが負の遺産」ということになってしまったわけだ。つまり、悪いのはCOBOLという言語そのものじゃなくて、「COBOLサイコー」とばかりにCOBOLにしがみついていた、

真性COBOLerの働き

の結果なのだ。「設計に柔軟性がない」というのも、COBOL以外の環境や、今使っているプラットーム以外のことを考えもしなかった結果だ。ウォータフォールに固執する開発体制も、エンジニア達が「それ以外」に目を向けなかった結果だ。

COBOLであってもOODは出来るし、アジャイル開発だって出来る。GUIバリバリのアプリケーションも書けるし、webアプリだって書ける。RDBだってRDBらしく書ける。さらに今時だと本物のOOPだって出来る。そういった点を見れば「現代の他の言語」と何らひけを取ることはない。まぁ「簡潔に書きにくい」という問題はよく指摘されるのだが、その辺はCOBOLという言語のコンセプト的な部分でもあるから、責めるべきことじゃない。

ということを見れば、COBOLの「負の遺産」というのは、たいていのプログラム言語とプログラマが陥りやすい罠に落ちた人がいる結果だということがわかると思う。つまり、同じことは他の言語や環境でも起こりうるのだ。つまり、

そこそこ便利で使いやすい

ものであれば、十分に起こりうる。

COBOLだって出た当初は最先端だったし、「新しい規格」はそれが出た時点では最先端を取り込んでいる。つまり、COBOLそれ自体が古かったわけでも古くなったわけでもない。問題は

使う人が進歩しなかった

ということで、それは「そこそこ便利で使いやすい」ものであれば、どれにもある罠なのだ。そのことを反省しない限り、

負の遺産の再生産

を繰り返すことにしかならない。

PS.

*1 「COBOLの中の人」の端っくれとしては、「新しい規格を使ってくれない」というのは非常に虚しい。「入れろ！」と提案される仕様は山盛りあるのだけど(諸伴の事情で最近は減ったが)、「そんなもんCOBOLerは使わんだろ」と言いたくなる。実際のところISO 2002を完全実装した処理系はまだないのだけど、OOPあたりくらいは実装したものがある。でも、それが使われているという話は、聞いたことがない。「酷いCOBOL」と呼ばれるコードは、実は85規格以前のものだったり…

PS.2

はてブのコメントに「その論法だとたいていの言語が悪者でなくなる」という意味のことがあった。まぁ極論すれば「物」は「無為」なので、それを良くするかどうかなんてのは人の業… ということにはなるのだけど、「PL/I」なんてのは言語それ自体が「負の遺産」になりつつあるよね。

PS.3

そう言えば、「COBOLの新機能」と同じような立場になるものに、「C++の新機能」ってのがあるよね。最新のC++の仕様を見ると随分と立派でちゃんとしてるけど、Cや古いC++から見るとわけわかだったり、習得している人が少なかったり。