COBOLのドコが最悪なのか【前編】

現行バージョンのCOBOLは、レアものなので、論ずる事自体意味を持たない。
ここでは、1970頃のCOBOL全盛期のものを前提にしている。

  1. データ宣言部
    • N88-BASICのFIELD文である。
  2. プロシージャ
    • N88-BASICのIF-GOTO-GOSUB-RETURNで出来ている。

こう書くとN88-BASICそのもののように思えるが、まぁ大して差は無い。
強いて言えば、実行手順に差がある。
UNIXで ps -elf  |  grep   java   |   grep  jboss > /tmp/jboss.log
とパイプで繋いでいくようにプログラムを束にして実行するのがCOBOL風である。
N88-BASICでは、
LOAD xxxx
RUN
となるので、続けて別のプログラムを実行するのは何かと面倒であった。
つまり、COBOLでは、1個のプログラムをいくつかのパート分けするのが普通で、
急ぐ仕事程、細かなパートに分けられていった。
※パート分けという仕事は、設計というより、分担であった。
しかし、この方法によって、大きな方法論上の収穫があった。
なんでも、一本のプログラムにしてしまうと、ちょっと変ったものが必要になっても、
一から作り直した方がマシなのはVisual-Studioを使っている人なら理解して
もらえるだろう。
プログラムをある程度の大きさに分類するという基本的な考え方はCOBOLで成立した。
しかし、物事が複雑になると、ある程度の大きさに分類しても大まかすぎで訳がわからない。
例) 月旅行 = 月に行く + 地球に帰る
もっと、人を動員して、
「月に行く」チーム+「地球に帰る」チーム
更に細かく・・・と、普通のプロジェクトが人海戦術で組みあがっていくように、
COBOL社会でも上級SE,中級SE,下級SE、PG(プログラマ)、CD(コーダー)と
階層社会が出来上がっていったのである。
つまり、上級SEとは予算や人材確保などプロデューサ役のことであった。
しかし、今では、下級SE~CDまでは、PG+テキストエディタ+階層構造を持ったコンピュータ言語で十分。
人件費削減というわけではなく、SE階層化社会が生み出す延々数百(あるいは数千)ページの【仕様(あるいは願望)定義書】よりも、
図式化した【アルゴリズム】や【フローチャート】の方が、まだ理解しやすいし、今でもある【ワークフロー】の方がマシである。
※個人的には【UML】は、【仕様(あるいは願望)定義書】の子孫だと思っている。だって、意味不明でしょ???
この辺の事情から、SEの階層を増やす続けるよりもプログラミング言語の方に階層構造を持った方がマシと
思う人が少しづつ増えていった。
エドガー・ダイクストラ etc
そうは云っても現実社会を支え活躍中のCOBOLとFORTRANに変革(言語仕様変更)は混乱の元でしかなかった。
そして、今やCOBOLとFORTRANは取り残された化石言語になったのである。
しかし、

  • 何が必要なのか?
  • 何を求められているのか?

目で肌でしっかり感じることが可能だった時代にはSE多重階層化社会が一番向いていたのかもしれない。

合掌。




コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA