COBOLのお話しについてもうすこし。COBOLのプロジェクトが失敗しにくく、JavaやVBなどを使用したシステムが失敗しやすいのは、単に過去の遺産が多いため、知識を持っている人が多いから、というのは一つの理由だろう。しかし、COBOLを学んでみてわかったのは、データベースを使ったシステムよりも、COBOLをつかうとブラックボックスが少ないように感じることだ。
例えば、SQLと比較してみる。SQLのほうがCOBOLよりも考える必要は少ない。SQLは「なにを必要とするか」ということだけを記述すればよく、COBOLは必要な情報をいったん、ファイルでプログラム中に定義し、ループを使ってファイルアクセスを記述しなければならない。
SQLのほうがいいように思える。しかし、これはSQLが具体的なアクセス手段を隠している、つまりブラックボックス化することによって実現しているものだ。ということは、実際にシステムを構築し、レスポンスを保証しなくてはならないような場合は、やはりSQLがどのように解釈されるか、ということを理解しなければならない。そして、その構造はCOBOLの単純な構造よりもずっと複雑で、面倒である。
COBOLは非常にナイーブな手法であるがゆえに、安心して使える。SQLそのものは単純ではあるが、実用として使うためには、SQLの効率のよい実行のための記述の仕方や、索引*1などの設定、記憶領域のカスタマイズなど、学習しなければならない落し穴が多い。
RDBは表(あるいは関係)という極めて単純な概念に基づいており、また、現実の事象はこの概念に抽象化する事が可能な事が多い。この抽象化を実現することによって、単純でかつ柔軟性のある形でデータが扱えるようになり、普及した。これはとくにアドホックな検索が多い場合に有利で、オブジェクト指向データベースがぱっとしなかったのも、このためではないだろうか。これによって、どう検索されるかという、システムに近い部分の具体的な動きを考慮しなくてもよい。これはいい面もあるが、仕事で定型的な処理、つまりまさにCOBOLが適用されるような基幹系のビジネスシステムにおいては、動きがはっきりせず、考慮しなければならない点が多いということでもある。
COBOLは前提知識も少なく全体をコントロールでき、かつ安全な言語であると思った。一種のドメイン特化言語(Domain Specific Language)であると思う。ビジネス指向言語とはやはりうまい言い方だと思う。ただ、非常に冗長で固い言語で，動的で抽象化したプログラムを記述できないため，今はやりのXPなどのアジャイルな開発とは対極にあると思う．COBOLはやはり，ウォーターフォールでしっかり設計を固めて，しっかりした仕様書を作ることに力を注げば，いい品質のコードは上がってくるはずだ．
結論として、COBOLは悪い言語ではない。問題はCOBOLではなく、COBOLの手法をそのまま他の言語の設計に使ってしまうCOBOLerさんのスキルが低いことに問題がある。*2
COBOLを使ったプログラムは、がちがちで冗長なので、私はあまり携わりたく無い。プログラムの楽しさ，という部分を思いっきり捨てているような気がする．大量のテキスト変換であれば、awkやRubyなどのスクリプト言語で作ってしまいたい。ミッションクリティカルなシステムでも、BufferedStreamxxxxxとかたくさんたくさん書かなければならないJavaなんかより、Rubyとか使いたいけど・・・，ってこういうときこそ，レポート言語であるPerlの出番？
