プログラミング言語や環境について詳しい方に質問です。

こんばんは、ikasamtさん。

最近は銀行のそういう大型システムでも、Javaに移行しつつあります。

＞１．またアルゴリズムさえ同じであれば言語は関係あるのか？

言語的な制限で、CobolとかJavaはアルゴリズムも制限されて誰が書いてもほぼ同じになるので、管理する側は都合がよいのです。

＞３．デファクトだからライブラリなどの資産がある => 少しずつ書き換えられないほど密結合なのか？

アマゾンの奥地と同じぐらいなので、障りたい人なんていません。触ったら、どんなにがんばっててテストしても、本番で障害がでます。

＞４. 複数人での大規模開発に向いている => 数百人とかのプロジェクトは問題のスコープの範囲を間違えているのでは？数人×100プロジェクトとかに切り分けるべきなのでは？

1と同じです。

COBOLはレガシーな言語ですが、なかなか良い言語だと思います。

なぜ、未だに使われているかについては単純に過去の資産を継承しているからだと思います。

COBOLが使われる理由は以下の通りだと思っています。
　
・本来プログラム仕様書があってプログラムが正しく動作しているはずです。
　しかし、プログラムをメンテナンスしていくと仕様書が古くなり齟齬がおきていることが多いと思われます。
　よって、他言語への移行は難しいし、仕様書を作り直すことも費用的に不可能に近いと思われます。
・他言語への移行ができてもテストも入れると開発期間・費用がかかるし、稼働しても問題が起きる可能性
　がかなり高いと思われます。
・処理はオンライン系よりバッチ系が多いので、COBOL言語が最適と思われます。
・命令がかなりシンプルで誰が作成しても、見やすいプログラムになります。
・COBOLはCOBOL85等、言語仕様が明確で、他言語のようにローカルな仕様はほとんどないです。
・まだかなりのコボラーがいるので、開発要員を多く集めることができます。

確かに凄い費用を掛けて対応しますが、バグが出ると社会的に問題があるので、十分テストをするので費用が掛かるのはやむを得ないと思います。

４つの理由とのことですが…
　
１．高負荷のトランザクション処理が出来る …
　　それはないと思います。C言語とか他言語の方が処理効率も高いと思います。
　　単純にメインフレームであるハードウェアの性能で問題ない稼働を実現していると思います。
２．言語が英語に似ていて分かり易い…
　　英語というより、命令や言語がシンプルなので可読性は高いと思います。
３．デファクトだからライブラリなどの資産がある …
　　レガシー言語なので過去のモジュールは品質が高く整理されています。
　　ただ過去の資産というだけで、ライブラリの作り良さ…は感じられないですね。
４．複数人での大規模開発に向いている …
　　特にそういうことはないです。今は大規模開発のために開発環境管理（VisualSourceSafe,CVS)
　　やプログラム共同開発ツールは進んでいると思います。

以上、私の経験からの勝手な意見です。

＞１．高負荷のトランザクション処理が出来る

COBOLでは他にはない実績のあるフレームワークがあるということですよね。

「高負荷のトランザクション処理が出来る」けど実績がない、ではクリティカルなシステムでは使えません。

＞２. 言語が英語に似ていて分かり易い => 可読性が高いとは思えない

慣れの問題ですよね。どれだけ精通しているか。

新しい可読性の高い言語が生まれても、言語をとりまく開発環境が充実していなければ使えません。

環境はあるけど実績がなくて「作ってみたけどだめでした」は大規模システムでは使えません。

＞３．デファクトだからライブラリなどの資産がある => 少しずつ書き換えられないほど密結合なのか？

正直、言語そのものよりライブラリが充実しているかどうか、のほうが重要ですね。

実績というのは得難い資産です。

＞４. 複数人での大規模開発に向いている

これは単純に Java とかのほうがよくなってきているかもしれません。

一度できあがった大規模システムを変えるには時間がかかります。

今でも部分的には（例えば一部のサブシステムはJavaとか）変わってきている部分もあると思います。

あと、コメントに書いてあった部分について

＞WEB屋だと同じかそれ以上のことが１００分の１の予算で出来るんだぞということを証明してみたいという夢があり

いわゆるLAMPなシステムで同じようなシステムを作るのは低価格で可能と思います。

が、いろんな意味で信頼性を保証するのが難しいと思います。

仕様書に載ってない仕様をどうやって見つけて新システムで再実装するのか、とか

Linux で Kernel Panic が起こったら原因解析して再発防止の修正パッチ作れるか、とか

個人的には古いものは古いものにまかせて、新しい技術で新しいものを作るのが

よいのではないかと思ったりします。

私が今日未明に見た時点でikasamtさんが疑問に感じているであろういろいろなことについて回答しようと思いましたが、書いてみたら物凄い長文になり、自分で読み返しても訳が判らなくらい整理がつけられなかったので、私の観点で重要だと思うことについて絞って書き直してみました。

1. トランザクションの処理能力が重要視される
   • COBOLは言語の記述に自由度が少ないため、他の言語に比べてコンパイラを設計しやすいです。歴史も古いのでコンパイラのチューニングにより、生成される機械語の質はかなり高いです。
   • 実行時にランタイムライブラリやダイナミックリンクを使用する言語は、処理要求があってから、まずCPUに処理可能なコードを生成して、それから本来必要な動作を始めるのでオーバーヘッドが大きいです。
2. 本運用に入った場合に問題が発生した場合の影響・損害が極めて大きい
   • リスクが高いために、予め高額の費用をかけても、問題が発生する可能性を下げておく必要があります。
   • 人間は間違える可能性があります。バグが混入したり、テストでバグの検出漏れがおきる可能性を下げる必要があります。
     • うまく動いている部分はなるべくそのまま使用する。
     • 最利用可能なサブルーチンをライブラリとしてまとめる。
     • ソースコード(場合によってはバイナリも)の変更を最小限に抑え
     • 複数の人で同じものを再チェックしたり、いろんな観点から検証する必要がある。

まだ、いろいろあるとは思いますが、とりあえずここまでにしておきます。