ま た 大 森 敏 行 か

一連のCOBOLの話で、また日経BPがアホな記事を上げている。

COBOLは難しいか、記者が試しにコードを書いてみた

まぁ努力は認めるが、間違いだらけである。で、記者を見ると、以前にクソ記事で私に叩かれた「大森敏行」氏である。

以前に叩いたエントリはこっち。

「悪い大人」

どうもこの人の傾向として、よく知りもしないことをよく調べもせずに、わかったようなことをわかったような文章で書くというのがあるようだ。てめーは自分が物事をよく知らないってことに謙虚になれんのか?

細かい間違いを一々指摘するのは馬鹿げているので、大きな部分だけ挙げておく。

まず、題材を「FizzBuzz」に持って来たのが間違いである。

COBOLは「データ構造の扱い」を記述する言語であるので、「処理」を書くことはあまり得意ではない。この「得意ではない」というのは、出来ないとか表現能力が低いとかではなくて、

簡潔な表現が出来ない

ということである。

最近のCOBOL(85以降)は処理の記述力が高くなったので、何かの処理が書けないということはない。モダンな言語にあるようなことは、たいていCOBOLでも表現が存在している。書けるか書けないかという点では、まぁ何でも書ける。

とは言え、COBOLの出自は「データ構造を定義してそれを永続記憶や表現の間をやりとりする」ものであって、それが一番得意だ。もうちょっとわかるように言えば、ファイルやデータベースと画面や帳票の間のデータ構造を定義したり転記が得意分野であって、そういったこととはあまり関係がない処理主体のものを書いても、あまり嬉しくない。とゆーか面倒臭いだけである。awkやExcelでやるようなものを書けば、なるほどと思えることは多いと思うが、CやRubyの真似をしても、まどろっこしくなるだけである。

と言うのも、COBOLと他の言語を大きく分かつ特徴は、

DATA DIVISION

にある。私がCOBOLを習った頃(74規格の頃)は、

DATA DIVISIONとPERFORMを征したらCOBOLはわかったようなもの

とか言われていたくらいである。それくらい、DATA DIVISIONは特徴的であり、COBOLという言語のメリットが集中する部分でもあるし、COBOLの厄介なことが集まる部分でもある。

「FizzBuzz」のような「いかに上手に処理を書くか」というような題材を持って来ると、DATA DIVISIONに書くことが少ない割に面倒臭いので、デメリットしか見えて来ないし、見えるデメリットも大したことがない(冗長だというだけ)。この題材で扱うデータも構造を持ってないから、01レベルが並ぶことになってるのだが、これもまたメリットもデメリットも見えて来ない。単に冗長だなぁと思うだけである。古来、このようなことを表現する言葉として、

鶏を裂くに牛刀を持ち出す

と言うのだが、まさにこれである。ちょっと穴をあけるのにCNCを持ち出せば面倒臭いのは当たり前である。

COBOLがよく冗長だと言われるのは、この手の「宣言」が大仰だからである。とは言え、同じような大仰さはHDLの類(VHDLとか)にもあるし、PLC言語(ST)にもある。なんとゆーか、「どこでどう使われているか明記したい」類のものにはありがちのものだと言ってもいい。

いろいろな反省や面倒臭さから、モダンな言語はこの手の宣言を極力少なくするようにしている。その分、さっさと本題に入れる。

問題はそういったことで、「わかった」気になって記事を書いてしまったことにある。

たとえば、

例えば、COBOLでは「グローバル変数」しか使えない。

というのがある。これはいろんな意味で大嘘である。

最新のCOBOLは1つのコンパイル単位(ソースファイル)の中に複数の手続きが記述出来るし、その中のみをスコープにする変数が定義出来る。つまり、「ローカル変数」は存在している。

また、この記事で「グローバル変数」と呼んでいるものは、1つのコンパイル単位の中しかスコープを持たない。つまり、コンパイル単位が異なると別のものになってしまう。COBOLで真のグローバル変数である「複数コンパイル単位にまたがる変数」を定義するのは、実のところ容易ではない(正確には「なかった」である)。

そういった意味では、件の記事は二重の間違いをしている。最新のCOBOLにある小さなスコープを持つ変数のことは無視しているし、古来からCOBOLが持つ真にグローバルな変数が持てないということも無視している(ちなみに85以降はファイルもデータも他のコンパイル単位から参照出来る)。実はCOBOLのコードのメンテを困難にしているのは、後者の方が原因であることが多い(真にグローバルな変数がないため、コンパイル単位がデカくなる)。まぁ、モダンな環境のCOBOLは何らかのミドルウェアの上で書かれるので、この問題が表面化しなかったりすることも多いのだが、バッチプログラムはそうでなかったりと、厄介なのである。

このように、単に「FizzBuzz」のようなtoyプログラムでの理解でCOBOLを理解しようとしていて、大変無理のある記事になっている。これは

丸木橋の経験で本四架橋を論じる

のと同じである。メリットもデメリットもちゃんと見えて来ないのである。あのな、FizzBuzz書いてその言語を理解したつもりになっていいのは、中学生までなんだよ。特にこういった大規模開発が前提の言語は。

そしてまあ、最後の

個人的には、COBOLはその悪い文化と共に消えていくしかないと思っている。

というお粗末な結論である。「COBOLの悪い文化」は、そーゆー生っちょろいところにあるわけでもなければ、「だから消えていくしかない」という類でもないし、てめーのような技術すらよくわからん奴の「眼」で見えるものでもない。この辺は、

COBOL「私を殺すと言ってた言語は、みんな死んだよ」

に書いたので、繰り返すことはしない。

日経BPの記者ふぜいがgdgd言ったところでCOBOLはなくならない。それでいてこのようなFUDは技術者に敬遠させる効果はある。なくなりもしないのに技術者が敬遠したら何が起きるか、それがわからない記者は腹を切って死ぬべきである。

PS.

COBOLの仕様についていくつか注釈を加えた。

COBOLの言語仕様については、「古い仕様(74以前、第二次規格とも呼ぶ)」と「新しい仕様(85以後、第三次規格とも呼ぶ)」と「最新の仕様(ISO 2002相当、JIS 2011 第四次規格)」とでは、それぞれ別の言語と言って良いくらいの改訂が行われている。そのため、メリットもデメリットも、「どれについて言っているか」を明確にしないとわけがわからないということと、新しい規格が出ても古い規格の常識で運用されるのは世の常ではあることと、「資産(レガシー)」が存在するので、新しい仕様が出たからと言って問題が解決するわけではない。出来る出来ないという議論の時には「出来る」と言えるのだが、それで問題が解決するかと言えばそうではない。ここの部分がごっちゃになっているので、注釈を加えた。

「グローバル変数」については85からあるのだが、それが活用されたコードは私の周囲にはなかった。同じ頃、「ファイル」も他のコンパイル単位から操作出来るようになって、これは使った。まぁ、ミドルウェアの中でしか使わなかったけど。

仕様としてはISO 2002は非常に強力なものになって、ローカル変数はおろかクラス定義(つまりOOP)や動的な項目定義まで仕様に加わり、モダンな言語と同じ程度の能力を持つに至った。仕様について「時代遅れ」と呼ばれる部分は、もはや何一つないと言って良い。とは言え、過去の互換性はしっかりあるため、より効率良くレガシーコードを作ることが出来るようにもっている。

私がタッチしていたのは、JIS 2011の作成とその次の小改訂の最初の方である。

PS2.

このエントリがホッテントリになっていたらしく、娘から「おとーさんホッテントリになってるよ」というメッセージが来た。まぁそれ自体はよくあることだし今回は狙って書いているので、よしよしである。

時をほぼ同じくして(どっちが先だか思い出せないレベル)、御本人から「取材のお願い」とゆーメールが来た。あまりにタイミングが良過ぎるので、「私の知ってる記者が同席か紹介があればね」と返事をしておいた。こーゆー話はこれくらい疑っておいた方がいい。

知り合いの記者からFacebookで「お願い」が来たので、「じゃあいいですよ」と返事しておいた。第三者が関われば、そうそう勝手なことでもあるまいと。

ところが翌日になって… あのな、

日経BPは当分出禁じゃ!