日々の破片

babie さんのところにも書かれてましたが、COBOLの件って、Matzさんの日記コメントの話ですよね。<br>http://www.csg.is.titech.ac.jp/~chiba/notes/oosympo02.pdf<br>にはIDCの調査結果の孫引きが載ってますが、2000年に110[万人]/(300+230+180+120+110)[万人]=11.7%以下(全体が不明なため「以下」としか言えません)のシェアになってます。この時既にJavaは120万人でCOBOLを抜いてます。<br>IDCとは別の調査になる下記のURLでも<br>https://www.rbccmresearch.com/drw1.0.4/pdf/0,,6402,00.pdf<br>1998年にCOBOL:Java=8%:4%だったのが、2003年末にCOBOL:Java=4%:13%で、やはりJavaがCOBOLを抜いてます。<br>また、どちらの結果も、COBOLは10%を切るシェアしかありません。1998年といえば2000年問題対応で、一時的にCOBOLが盛り上がっていたことを覚えてますが(知合いも旧システムのメンテに駆り出されてました)、それでもシェア8%という調査結果なわけですし。<br>なお、下記のように、COBOLが50%弱という調査(日本のみ、2003年)もありますので、もしこのような調査結果が、全体の比率と等しいと仮定した場合、おごちゃんのような結論に到達することがあるかもしれません。<br>http://www.atmarkit.co.jp/fbiz/data/index.html<br>ただ、実際にはこの結果は単に母集団が偏ってことの反映に過ぎず、全体の比率とはまったく異なるものでしょう。それにこの調査にしても、50%を微妙に切ってますから、おごちゃんのいう「世の中の半数以上のプログラマはCOBOLに投入され」という情報のソースではないですね。というわけで、おごちゃんがどの情報を信じたのかには興味があります。

> それにこの調査にしても、50%を微妙に切ってますから、<br><br>おっと、すいません、なぜか勘違いしてました。<br>この結果はCOBOL 54%で過半数でした。すいません。<br>ということで、おごちゃんの情報ソースはこれかもしれませんね。<br>ただ、この結果をもってCOBOLがいまだに過半数だと主張するのは、かなりまずいと思います。IDCやrbccmresearchの結果の方が、はるかに実態に近いでしょう。

ポインタ、どうもありがとうございます。特に最後の調査が興味深いです。<br>2003年のアンケートは、企業に納入された汎用機のほぼ全てとUnixでの相当数がCOBOLで書かれているという結果ですね（しかもそもそも汎用機が半数弱ある）。確かに、このへんから生越さんはビジネス市場を想定して書いたんでしょうね。（大学でのシェアなら間違いなく有り得ない）<br>僕の勤め先(たいてい2歩半くらい遅れている)は2000年前にCOBOLをほぼ捨てた（一部お客さんが開発したプログラムは残っていると思う）のと、数年前に汎用機リプレース→Javaをやったのでトレンドとしてもう汎用機市場は縮小したのだろうな、と考えていました。<br>ただ、Javaのプログラミング言語っぽさ(いや異論があるのはいいけど)に対して、COBOLのDSLっぽさとRailsのDSLが受け入れられているということには相関関係があるのかな？ という点やどうしてこうJavaで……と感じるような点から、シンプルなCOBOLが復活してもいいのかな、とも思ったりします。たとえばもしRailsをみんなが使うようになったら、コントローラで定義したインスタンス変数をビューで使うというのは、そのままデータディヴィジョンとプロシージャディヴィジョンと同じ意味になるんじゃないか、とかそういったことです。<br>#で、それはそれでありかも知れないと思ったと。でも僕はそういうプログラムは書きたくはないんだけど。

> しかもそもそも汎用機が半数弱ある<br><br>これが調査の母集団をよくあらわしてますよね。ビジネス方面に限っても、この調査が全体を反映しているとは考え難いです。<br><br>DSLについては、それが適合する問題領域については、非常にコンパクトに書けて生産性が高いというのがポイントではないでしょうか？<br>COBOLが生産性の高い言語だとは思えないんですが。<br>帳票を作るだけなら、今ならCOBOLでガリガリ書くよりもっと生産性の高いパッケージが沢山ありますよね。<br>データベースに関しても、CODASYL+COBOLより、RDB+(SQL or ORマッパー)の方がはるかに生産性・保守性が高いですし。

同感。COBOLってDSLっぽい。というよりも、そもそもDSLでは?

COBOL の出自は、CODASYLと事務処理のためのDSLと言えなくもないですね。<br>ただ、LispやFortranと並ぶ最古の言語の一つなので、少なくとも現代の生産性の観点からは、DSLとは言い難いでしょう。(もっともLispだけは現代でも生産性は最高の部類に入る言語ですけど)<br>また、CODASYLのようなネットワーク型データベースは、RDBの出現以降、少なくとも事務処理向けとしては存在価値を失ったと言って良いと思います。(既に稼働しているシステムの保守目的としての価値を除く)

いや、そうとも思えないです。>帳票を作るだけなら、今ならCOBOLでガリガリ書くよりもっと……<br>最後にCOBOLのプログラム書いてから10年近くか以上かたってしまったので間違えてる可能性もありますが、Pro*COBOLを使って右のテーブルから左のテーブルを作るようなプログラム（これだけだとSQL一発だけど、いろいろな付加情報を付ける必要からプログラミングの必要があると想像してください）なら、見てくれだけはCよりすっきりと書けてました。（僕が英語の語句より｛｝のほうが好きかどうかとは別次元の話です。当然ながら、なんでもCOBOLという主張ではないですよ。想像したのは、長くなるから後で書くけど与太だよなぁ）

あ、つまりこうも言えるんだ。ひどい言い方になるけど。<br>Javaでは繊細なプログラムが書けるが、COBOLでは書けない。だから安心して任せられる（美点1）。<br>Javaではクラスライブラリを調べたり覚えておかなければプログラミングできないが、COBOLでは構文だけ知っていればOK。高い生産性（美点2．腹が痛いがしょうがない）<br>Javaではいざとなれば言語を書けるがCOBOLでは書けない。フレームワークも同じ。プログラマは集中してアプリケーションだけを書ける（美点3．）

うーむ、すごい利点ですね。:-)<br>確かにどれもDSL的特徴ですが。<br>Pro*COBOLの件は、Cと比べたせいでCOBOLの方がすっきり書けたけど、<br>3GLや4GLならCOBOLよりもさらにすっきりしたということはないでしょうか？

僕は3GLとか4GLとか使ったことは無いのでわかりませんが、COBOLは方言はありそうですけど標準化されているのが良いのではないでしょうか？ （というか、なぜ僕がCOBOLの弁護をしてるのか良くわからないけど、成り行きってのはおもしろい。ただ、実際、Java（というか本当にプログラムが書ける言語）だとどう手をつければ良いかわからずに呆然としてしまう人もいるからなぁ、ということですね。というか、それで済むような処理は機械化するのが筋だと思います（でもDSLと考えるとすでに半分機械化されているようなものなのではないかとも思う）。なんていうか、改札の切符職人みたいなもので、それは技かも知れないけど人間がする仕事とは思えない）

すっきりというのは（と、上のが答えになってないことに気付いて追加）、記号が少なく処理そのものだけが見えるというような意味と、カラムで揃っている整然とした感じのことです。ただ、僕は混沌のほうが好きだということは（でも汚いのは嫌いだな）言っておきます。想定コードを11/30#p03のほうに書いておきました。なんか誰でも読めるというか、何してるか読めばわかるというか、プログラム知らなくてもわかるかも知れないというか、そんな雰囲気を「すっきり」と表現したみたいですね（自分でも好きでもないので良くわからないけど）。

かっこいいフレームワークの人たちが欲しがっているアレは実はCOBOLじゃないの? っていうのが傍観者な咳の感想。23:53の「ひどい言い方」は「欲しいアレ」なんだと思います。なんてね。

うーん、ERbの作者がそれを言ってはいけないんじゃないかなぁ。というか、ERbはそれを目指してるの？ >欲しいアレ<br>ただ、僕は似たような感じになりがちなコントローラのコードは好きなんだよね。(setq a b)とmove b to aの間に僕が好きなのがあるらしいのかも。

えー。そうなのか。じゃあアレちがいです。

あ、ごめんなさい。フレームワーク違い、ですね。ERBはまったく逆を目指しています。さっきの「かっこいいフレームワーク」は「俺様フレームワーク」の方。アプリケーションは「上手くない人が作るんだ」ってやつ。なので私は参加してないから傍観者みたいなところに立っている。

あ、なるほど。別の言い方をすると5人は救えないけど500人は救える＝かっこいいということですね。

（でも5人を救えないのなら、500人を救っているというのも嘘100倍だというだけなのではないかという疑問）