COBOLとjavaに思う

COBOLコードの近代化はどのように進めるべきか を見つけて考える。
javaだって似たような状況だと思ってる人がいて、javaの採用におっくうになっている自分がいるからだ。
自分はCOBOLは直接触ったことがない、何度か人が文句を言いながらソースを触っているのを横目で眺めたぐらい。
なので正しく評価できていない部分はあるかもしれない。
自分の聞いた範囲では、COBOLのソースは「構造化」の洗礼を受ける前のすべては上から下へ流れる形式のソースが多いらしく、今の（構造化を通過し、オブジェクト指向やあるいはジェネリックプログラミング、関数型言語のどれかを理解した）プログラマにとっては「許しがたい」ソースになっていることが多いようだ。
で、そういう「許しがたい」ソースは、CやC++やjavaや、LLを使っても記述可能な点であることを念頭に置いておく必要がある。
オブジェクト指向を理解していないプログラマにCOBOLをC++やjavaで書き直せ、と言ってもろくなクラス定義は出てこないだろう。やっぱり、すごくでかいmainの中に、だらだらと処理を書かれて終わるだけだ。
（e_c_e_tは仕事でそういうjavaのソースを見て引いたことがあります）
つまるところ、COBOL（いや、昔の「ほげ」言語と改めよう）の保守がやっかいなのは、「ほげ」言語が書かれた時代の「パラダイム」をもとに書かれていることに読みにくさ、保守のやりづらさが起因している。
それは後の新しいパラダイムは「過去のパラダイムの弱点の上に成り立っている」から、新しいパラダイムで育った世代には「やってはいけないことのオンパレード」に見えるものー例えば、グローバル変数が多数あり、至る所で値が変化する、などーは保守できない、保守やりたくない。
（断定口調で書くのは乱暴だが、そういう流儀に接したことがないと、そう感じるだろう）
閑話休題。
自分の周りのjavaのシステムのことを考えてみると少し嫌な気分になる。
とある、アプリケーションサーバ上には、jdk1.2,1.3,1.4,1.5が「それぞれ別に」入っているというのを見聞きしたことがある。
（全部クラスパスが違うらしい。。）
別々に入っている理由は、
特にバグも追加要求も今のところないから書き直す機会を失ったjdk1.2時代のプログラム
特にバグも追加要求も今のところないから書き直す機会を失ったjdk1.3時代のプログラム
特にバグも追加要求も今のところないから書き直す機会を失ったjdk1.4時代のプログラム
新しい別の業者に書かせたところ、これからはJavaSE5の時代ですよ、と言われて納入されたjdk1.5のプログラム
というところだったりする。
試験はその時々の最新のjavaVMで実施した。とのことなのでその時々の環境から触っていない。
それはそれでまぁ正しいことなんだろうが。
単なる現状維持を目的としたリプレースに金を出してくれる奇特な客はいない。
文句なく動いていて、追加機能の要求もないならそこに金をつぎ込む理由などない、から、放置される。
（仮にjdk1.2で動いているソースを1.5で書き直したと、する。現状以上のアドバンテージが見込めないなら、普通は投資しない。わざわざ金払って結果は「今と変わりません」でした、というのはプログラマにとっては意味がある行為かもしれないが、普通はそんなことしない。自分が金を出す立場だったらどう考えるだろうか）


ちなみに自分はjdk1.4のプログラムの新規追加時に参加した。
そのときにjdk1.2やら、1.3やらのソースは全部書き直す選択肢もあったはずだが、
いかんせんお客様はそれを望んではおられなかった。
自分が見積もり、請け負った仕事はjdk1.4だったため、1.2や1.3の環境には手出しできなかった（放置するとヤバいですぜ、というので精一杯）
自分が1.4環境で書いてからもう５年以上が経つ。
たった５年の間にjavaVMのバージョンは6（1.6）まであがった。


もし、お客様の心変わりがあって、自分に1.2時代のソースに機能追加を依頼されたらどうするだろう？
スレッド周りも大きく現状と違うし、なにより、現在は「推奨されない」APIだらけで構成されているゲテモノ（とはいえその当時の最先端技術）を上手に1.5以上の環境に移植するのは恐ろしく骨の折れる作業だと思う。
そもそも、とっても嫌だ。そんな作業。1.3が自分の中ではギリギリのラインだ。


COBOLerを対岸の火事だと思っているjava屋こそ、実は危険なのではないか。
同じ「java」という言語の中にもずいぶん幅がある。
少なくともjavaで飯を食っている人にも「そこにある危機」というのはあるところにはあるんですよ。と。


というわけで、今はこの先少なくとも５年は使われるであろうシステムについては極力CとC++で考えるようにしている。
そこにも当然C99だとか、C++0xだとか、時代の流れはあるが、ISOの承認プロセスを得るために、少なくともjavaよりは進化が遅いことが確定している、し、市場には一定数のC/C++技術者が（まだ）居る。
（トレードオフとして貧弱な標準ライブラリでの仕事となるが、今の一見豊富に見えるライブラリが５年後にゴミの山になることも考えると状況は似たり寄ったりの感がある）
当然、javaで作るより金も時間もかかってしまうが、５年キッチリで償却して、６年後に今書いたソースを保守できる人材がいる可能性は今のjavaよりは高いと思う。
とはいえ、文字通り「思う」で終わっており、安く早くが、ビジネス的には望まれる訳で結局のところジャバジャヴァしてたりするんだが。
いわんやLLをや。