どうも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++から見るとわけわかだったり、習得している人が少なかったり。
orca.medがorga.medになってるっすよ。
後は、COBOLはプラットフォームに依存しがち(COBOLの欠点?ベンダの欠点?)なんですが、プラットフォーム(メインフレーム)がやたらと高値なのも問題な気がします。
結局、OOPもできちゃうオープンソースなコンパイラ、実行系があればな~という・・・もしあれば、今あるコードたちがプラットフォーム別のに移せるし、改良はリファクタだけで済むから負の遺産になりにくいように思います。
他の言語はその辺割と慎重だから、やっぱりCOBOLが槍玉にあげられやすいのかもしれませんね。
> COBOLはプラットフォームに依存しがち
それはCOBOLの問題じゃないですね。あくまでも、「COBOLプログラマ」が「現状のプラットフォーム」にということです。
JavaはSunが頑張ったお陰で、EJBの範囲であれば互換性があるので良いですが、Rubyは互換性の全くないフレームワークがいったいいくつあるのやら… Rubyな人達は簡単に「作り直せばいい」とか言ってくれるけど、「エンタープライズ」なアプリでそれが通るかどうか…
> OOPもできちゃうオープンソースなコンパイラ、実行系があれば
OOPは出来ないけどオープンソースなコンパイラはあります。まぁOOPまで出来る(2002規格を完全実装した)コンパイラなんてのは、世の中に数える程しかないんですが。
あ~。印象として、COBOLってプラットフォーム(ベンダ)違うと言語仕様もがっつり違う気がするんですね。なので、プラットフォームの違いを吸収するハードルは結構高いと思います。SQLの違いより相当大変だと思うんです。
後は、もうちょっとメインフレーム安くしてっていう気が。安くなるとまた違うんじゃないのかって思うんですが、どうですかね?COBOLを刷新したい一番の理由はメインフレームの値段の高さにあると思うんです。
Rubyは、まだまだなんじゃないんでしょうか?あれをエンタープライズっていうと、安定性、互換性、速度のリスクを覚悟しておくか、しばらく見守るかが普通の選択だと思います。
僕はCOBOLをあんまり使ったことがないので印象で語ってるから間違ってるかもしれないですがw
> COBOLってプラットフォーム(ベンダ)違うと言語仕様もがっつり違う気がするんですね。
それCOBOLの責任じゃないです。メインフレーム*ビジネス*の責任。だから、メインフレーム上のオンラインプログラムって、みんな同じ問題を抱えてます。
でも、今時メインフレーム捨てるというつもりなら、Linux上でもWindows上でもエミュレータ動かせばいいって話もあるんですよね。「捨てる」くらいの時代のものだから、そんなpoorな環境でも十分過ぎるくらい高速だし。
メインフレーム上で動いていたTPモニタくらいだったら、いくらでもオープン系で動かせるはずなのに、メーカはそれをやらないんです。不思議ですね。
# 遅まきながらあけましておめでとうございます
COBOLの言語仕様に馴染まないで読むのも気が重くなる(Pythonと同じくらい)人ですけど、確かにCOBOLがよく使われてたから「負の遺産」なんやろ!的な物が多いですね。
「とにかく動かせ」って感じでずぶずぶのスパゲッティであっても許容されつづけた結果、可読性も移植性もダメダメなコードが蔓延してるという
…一昔前のアセンブラやC、今だとASP.NETやJava、PHPの商業プログラマがハマりやすいあたりと同じ原因の物が(基幹系の事故の原因とか聞いていると)多そうですね。
まぁ、初期の設計段階で練れ!コーディングにかかる時間を多少削ってでもデバッグ工数で取り返せるから!って持論で仕事やって来て(で部下がついてるときは叩き込む)ますけど、いやがられるんですよねorz
日本の電機業界が納期優先で特に下請けの仕事は買い切りが大多数だからしかたないんでしょうけどorz
まあ,Guy Steele Jr.みたいに,CでもCommon LispでもJavaでも言語仕様書いちゃう人もいるわけで.
COBOLは仕事で使ったことはないのだけど,COBOLだからどうの,っていうのは本質論じゃないですよね.
こんなのもあるらしいし.
OpenCOBOL
http://www.opencobol.org/
> COBOLだからどうの,っていうのは本質論じゃない
要するにそういうことです。そして、同じ危険はあらゆる「わりと便利なもの」が抱えている問題だと。
> OpenCOBOL
これの最初のコードは、私の業務命令で作らせたものです。今は開発者も私も、当時の会社を辞めちゃってるわけですが。
偉い→作らせた
この辺のエントリにその辺の事情が書いてあります。
ORCAのアーキテクチャ(言語とデータベース)
http://www.nurs.or.jp/~ogochan/essay/archives/956
OpenCOBOL 1.0リリースされてた。
http://slashdot.jp/articles/08/01/20/2036224.shtml
自演乙www
まだ某APIに関して調査してないので、某システムで使えるかどうかは謎。