COBOLのソースを直接読む事は無いけれど、設計書を読む。その関係でCOBOLの文法もほんの少しだけ勉強してみた。大学院のころにも少しだけやっていたので、時間はかからなかったが、あらためていろいろ発見できた。
COBOLは、ファイルの入力と変換、そして出力ということだけに特化した言語だといえる。そして、ビジネスで用いるシステムの処理とよばれるものは、ほぼそれだけで事足りる。
COBOLのモジュール化は関数によっては実現されない。すべてファイルの入出力である。つまり、機能毎にファイルを生成するため、適切に機能分割されたCOBOLプログラムは中間的に生成されるファイルを大量に持つ。例えば、一つのプログラムでファイルの突き合わせ(「とつごう」という)と変換を行うわけではなく、突き合わせするモジュールと変換するモジュールをわけ、その間に突き合わせした結果だけの中間的なファイルを生成する。こういうことをしても、格納形式と処理が密接に関連してしているCOBOLプログラミングは、格納形式が独立で、トランザクション管理を行っているRDB上の処理よりもずっと高速に処理できる。
RDBはフラットな２次元テーブルしか扱えないが、COBOLは繰り返し項目や、項目のグループ化が可能である。よって、RDBでは複数のテーブルに分散する情報が、COBOLでは一つのファイルにまとめて管理する事が可能である。これ自身はメリットでもデメリットでもないが、COBOLの方がより直観的かもしれない。一方、SQLのような手軽さが、COBOLにはない。対話的なプログラムの記述は難しい。
COBOLはよくいわれるように表現が冗長で、予約語が多い。これは仕様書をそのまま動かしたいと言うホッパーさんの言語設計上の意志によるものだろう。
データの構造をきっちり決める必要があり、上限の無い可変長データは扱えない。これはミッションクリティカルなビジネスシステムにとってはむしろ好都合と言える。
ファイルの構造にプログラムが左右されてしまうため、ファイルの構造変化に弱い。とくに桁数の変更はプログラムに重大な変更を及ぼす。そのため、フィラーとよばれる予備項目を多く持つ事が多い。
COBOLは決して悪い言語ではない。むしろ、人が習得しやすいという点だけでも、落し穴が多く、半端な技樹者による半端なコードが多いJavaよりも優れていると思う。ただ、Cのマクロのようなものは存在しないし、処理だけでなくデータ構造自体の局所化ができないため、モジュール化という意味ではやや弱い。BASICのgosubのようなperform命令によるファイル構造を共有化した上でのサブルーチンが主なモジュール化の手段になっており、独立性を高めるためには先程のように中間ファイルを用いる形になってしまう。よって、モジュール化がかえってプログラマの負担になる可能性もある。そういう意味では、COBOLにおいてモジュール分割の積極的な導入にためらいがあるのはやむをえないのかもしれない。
COBOLを積極的に使おうと言う気にはあまりならないが、COBOLを使っているプロジェクトとjavaを使っているプロジェクトでは圧倒的にCOBOLを使っているプロジェクトの方がうまくいく確率は高く、故障も少ないことがおおいはずだ。
