COBOLはまだまだ終わらんよ 96
ストーリー by GetSet
適材適所で 部門より
適材適所で 部門より
pinbou 曰く、
本家/.の記事より。チューリング賞受賞者エドガー・ダイクストラ曰く、
「COBOLの利用は精神を損なう。よって、COBOLを教えることは犯罪行為とみなされるべきだ」
……とはいえ、このDr. Dobb's Journalの記事によれば、COBOLのしぶとさには度外れたものがあるらしい。21世紀に入ってもCOBOLは最も広く使われている言語であり、今日のソフトウェア開発における最もホットな領域のいくつかで重要な地位を占めている。あなたが次に学ぶべき言語はCOBOLかもしれないのだ。
1997年、Gartner Groupが発表した調査によれば、現在使われているアプリケーションのうち2400億行はCOBOLで書かれており、毎年何十億行ものCOBOLコードが新たに書かれている。加えてCOBOLはXML/メタデータ、ウェブサービス、SOA、eビジネスと言った分散型ビジネスソフトウェアアーキテクチャコンセプトの具現化においてカギとなる存在なのだそうだ。
プログラム行数 (スコア:1, 興味深い)
過去にソフトウェアの生産性を計られたとき、その結果としてC言語よりCOBOLの方が数倍も生産性が高いのでCOBOLを使うべし、という報告が出て来たことがあったのを思い出した。
COBOLで書かれたプログラムが多いのは認めるが、単純な行数比較はあぶないぞ。
Re:プログラム行数 (スコア:2, すばらしい洞察)
Re: (スコア:0)
1
TO
HOGEHOGE-FLG.
これで4行いっちゃいますね。
Re:プログラム行数 (スコア:1)
Re:プログラム行数 (スコア:2, 興味深い)
Re:プログラム行数 (スコア:1)
プログラムの量ならC言語に勝てないから、こういった微妙な言いまわしになっているんだろうね。
まあ、C言語の手続の多さや基本関数の少なさは効率良いとはいえないけど、COBOLで何でもできる
わけでもない。
他の言語の方が効率が良い場面は多々あるので適材適所で使い分ければいい話。
問題は、使い分けられるほどプログラマーが多数の言語を習得してないことだよね。
根本的な問題として、COBOL→C言語のコンバーターとかで解決しないのかな?
ああ、そのままならいいけど、改良や、ベースに仕様変更する場合はダメか...
C言語のソースの読みにくさは、格別だからなぁ
いっそのことpascalに....
Re:プログラム行数 (スコア:3, すばらしい洞察)
そういう自動変換されたソースは普通は死ぬほど読みにくいですよ。
#手動変換されたソースでも、死ぬほど苦労したことがある。orz
>C言語のソースの読みにくさは、格別だからなぁ
普通レベルだと思います。
(トリッキーなテクニックを駆使した)Perlに比べれば可愛いもんですよ。
マクロの乱用などがあれば別だけど、そういう糞プログラマが書けば
どんな言語だろうとスパゲッティプログラムになることでしょう。
でそれを誰が検証するんです? (スコア:1)
Re:プログラム行数 (スコア:1, 興味深い)
コンセプトの具現化 (スコア:1)
まさか、XMLパーザやウェブサーバやアプリケーションサーバ自体をCOBOLで書く気ではあるまい。 またウェブサーバやアプリケーションサーバにアクセスするためのクライアントライブラリもCOBOL自身で書きはしまい。
COBOLのプログラムは、それらのライブラリやサーバを利用して従来COBOLが得意としていた金計算を行うだけではないのか? COBOLがコンセプトなるものの具現化のカギになるのではなく、そのコンセプトと称するものがCOBOLの延命のカギになっているのではないのか? COBOLの立場は、C, C++, C#, JavaよりもむしろPHP, Perl, Ruby, Pythonに近づいている気がする。
Re:コンセプトの具現化 (スコア:4, 参考になる)
するどいですね.原文読まれました?>#1423575
興味がでてきたので4ページ目 [ddj.com]を粗訳してみました.
CobolはWebとのゲートウェイか?
しかしCobolを学ぶ魅力的な理由がある.単に古いコードを保守や移植するんじゃなく.
Cobolはモダンな分散型ビジネスソフトウェアアーキテクチャのコンセプトを具体化するキー要素だ. そのコンセプトとはXML/メタデータ,Webサービス,サービス主導アークテクチャ(SOA),そしてeビジネスである. トレンディな要素,つまり次回のWeb 2.0 カンファレンスでCobolのセッションがあるかもしれないというだけでなく,決定的な要素でもある. Lemmel (この人 [www.ecdl.at]かな?) はメタデータのエッセンスを,CobolのIDENTIFICATIONおよびENVIRONMENTセクションと,Webサービスが利用するCICSトランザクションの中に見ている.
Cobolアプリケーションの真のコンセプトは,oversimplication(シンプル化のやり過ぎ)とでもいうものだ. Cobolプログラマは,SOAモデルに類似した方法でまとめられたテクノロジの集合体を扱う. Scott McMahan [scottmcmahan.net] はeメールで次のように述べている. “モダンなCobolを理解したければ,glue(接着剤)言語だと思えばいい. IBM [ibm.com] はデータ処理用にCICS, DB2, IMS, VSAM, ISPFなどのテクノロジの‘スタック’を持っており,それらはCobolでつなげられている.”
トラディショナルな実装からWebベースのモデルへの移行におけるCobolプログラマの役割は,いろいろな姿をとることができる.
プログラマはCobolコードと新しいアプリケーションを橋渡しするかもしれない. それにはCobolと,レガシなCobolコードの背後にあるビジネスルールと,そしてモダンな言語とシステムの理解が欠かせない. SOAおよび共通ランタイム環境を持つIBMの言語環境の出現によって,既存のCobolコードは他のコードと,より容易に統合できる.
CobolとWebの統合に利用できるツールは急速に進化している. Veryant [veryant.com]社はWeb 2.0の開発をCobolの中で直接行えるようにしている: “最新のWebアプリケーションの多くに含まれるウィンドウのグラフィカルなサイズ変更と同じことが,今やCobolプログラムのエンドユーザに対しても容易に実装できる.” Micro Focus [microfocus.com]社はMicrosoft [microsoft.com]社とのパートナーシップを通じて,Cobolアプリケーション開発に向けた強力なSOAサポートを開発中だ. さらに富士通 [fujitsu.com]は,コードの統合より“数歩進んで”CobolプログラマがWebを直接プログラムできるようにすることを検討している. 例えばASP+ページにCobolコードを埋め込んだり,CobolでWebサービスを直接書くことができる.
“これは静かなる現実だ”とCrookは言う. “ビジネスの世界はCobolに載って動いている. [そして]今のCobolはとてもモダンな言語で,新しい価値をビジネスへ迅速にもたらすという昔からの力を,引き続き及ぼしている.”
=^..^=
Enjoy Computing, Skiing, as much as Horse Racing.
Re:コンセプトの具現化 (スコア:1, 参考になる)
某社が作った某システムでは、COBOLで書いたCGIが動いてたなぁ.....(遠い目)
Re:コンセプトの具現化 (スコア:1)
可変長レコードの問題がなければ、画面=レコードのメタファが効いて、かつ
セッションレスな一過性オンラインであるCGIは、COBOLで書くオンラインシステム
との親和性は高いと思うよ。
CGI黎明期に、C/Sやってた人は、どうしてもセッションレスオンラインの概念が
理解できてなかったけど、COBOLやってた人はすんなり入った。まあ狭い経験論
だけど。
-- Tig3r on the hedge
Re:コンセプトの具現化 (スコア:1)
"分散型ビジネスソフトウェアアーキテクチャの実現"に当たっては、
既存/新規のCOBOLで書かれた膨大な業務ロジックの実装を、
きちんと理解して利用する必要がありますよ。
と、いうことではないかな?
結局の所、各サービスの断片においては、
外界とのやり取りの形式に変化はあったとしても、
本質的な部分は何も変化がありませんよね。と、
そういうことを言っているのかと思います。
実装がCOBOLでもPL/1でもFORTRANでも、
既存の優れたものは膨大にあり、さらに、これからも、
古典的な言語で優れたものは生み出されるでしょうし。
-- LightSpeed-J
カギはXMLのほうでは? (スコア:1)
「XMLでデータ吐いてくれれば他システムとの連携や再利用しやすいよ」
って言ってるだけみたいな感じで、
別にCOBOLそのものはカギでもなんでもないのでは?
帳票出力部分をXML出力にする?
--------------------
/* SHADOWFIRE */
最近はjavaもCOBOLっぽくね? (スコア:1)
いずれにせよ、COBOLもjavaも適材適所だね。
全体的なコストパフォーマンス (スコア:1)
もちろん、今ゼロから作るならJavaでFAですが
「納期」「要求仕様」以外に「既存システム」という前2つと相反する要素が出てくるので
システム拡張という名目でツギハギをしようとした場合にCOBOLが使われているだけの話でしょう。
COBOLだから良いのではなく、前もCOBOLだったから次もCOBOLなんです。
「今のプログラムを活かすと2年かかります。でも一から作り直すなら1年以内で出来ます」 (スコア:1)
うちの会社の場合 (スコア:0)
Re:うちの会社の場合 (スコア:1)
反対に (スコア:0)
Re:反対に (スコア:3, おもしろおかしい)
Re:反対に (スコア:1, 参考になる)
Re: (スコア:0)
大体それ自然言語だし。
あと、ラテン語ってまだ専門用語では使うしな、学名とか。COBOLもそんなんだな・・
しかしスパン長過ぎだ。生きてる間にはわからないってレベルじゃないか・・・
えーと、そうだな、プレーンなBASICを初心者に教えるのは廃れたと言っても良いかな?
Re:反対に (スコア:1)
JIS Full Basic ですが、(仮称)十進BASICは、
複数の高校数学の教科書で紹介されています。
http://hp.vector.co.jp/authors/VA008683/ [vector.co.jp]
教える側が慣れているということもあるのですが、
数学的なサンプルなども豊富なので、結構悪くない選択だと思います。
Re:反対に (スコア:1)
その前に「ある程度広まった」と言えるものが非常に少ないと思うけど。
Forte とか、UNIFACE とか、NATURAL とか、PROIV とか。
Re:反対に (スコア:1, 参考になる)
S/3 -> S/32 -> S/34 -> S/36 -> AS/400 -> System i とハードの進化に合わせて、RPGも進化してます。
ちなみに、今は RPG IV ね
Re:反対に (スコア:1)
I'm out of my mind, but feel free to leave a comment.
Re:反対に (スコア:2, 興味深い)
平成20年度センター試験 数学II・数学B [dnc.ac.jp] ※PDF注意
#実用性は皆無だけど
Re:反対に (スコア:1)
Re:反対に (スコア:1)
Re:反対に (スコア:1)
Re: (スコア:0)
Re:反対に (スコア:1)
Cから始めると、世の中C言語しかないと思ってしまうということらしい。
Re:反対に (スコア:2, おもしろおかしい)
「なんでCじゃないんですか」と尋ねる学生も毎年いくらかは現れますが
こういう学生はつまり「自分はCなら既に知っているから講義もCなら楽なのに」と考えているので
こちらは「新しいことを学べて嬉しいだろ」と答えています。
Re:反対に (スコア:1)
Cが新しいとは思えないが、Fortranはそれ以上に新しくない。
CならC++にもJavaにもつながるかもしれないが、Fortranを覚えたところで何になるんだ?
高校の時に商業科(?)の奴が授業でCOLBOLやってる orz と言っていたのを聞いて同じ事を考えてた。
ちなみにそのときには「COBOLは10年前くらい前の本に"COBOLは古すぎて使ってられない"って書いてあった」って言っておいた
Re:反対に (スコア:1)
一見無駄なことが、人間の幅を広げる効果があったりするんですよ。
Re:反対に (スコア:1)
元コメントに対して… そんなこと言ってたら、shとかLispとかBasicとかアセンブラとか毛色の違う言語には手が出せませんね。
結局、言語というのは、他の言語と共通する部分と、他の言語とは異なる部分の2種類しかないわけで、その差分を理解していく、もしくは歴史の流れを理解していく、いい足がかりになると思いますけどね。
そうすればJavaScriptのコンストラクタに感動したり、変数のスコープでクロージャが実現されているのかと理解できるってもんです。
Re:反対に (スコア:1)
Re:反対に (スコア:1)
正確には,論理型の1次元配列
("一次元のアレイ"だけだと構成要素の型がわからん)
Re:反対に (スコア:1, すばらしい洞察)
Pascalじゃ、世の中Algol60しかないと思ってしまうことに変わりはないでしょう。
Re:反対に (スコア:1)
Lispは最初に教える言語には適さないかと。
Re:尋ね人 ada (スコア:1)
本家では (スコア:1)
Re:COBOL の嫌なところ (スコア:2, 興味深い)
文句言ってる気がするよ。
ここは似たような処理だから、
→違う部分だけ別段落で書いてPERFOMEで処理分岐しよう
ファクトリメソッドを使えば、
→複数の条件を持つ段落と、その段落で使うデータ領域定義を
ライブラリにしてCOPY(コピペじゃないよ)して利用しよう
くらいがCOBOL的発想。つかCOBOLよりCとかJavaとかの、ローカル
スコープのある言語の方が何も考えないコピペ開発者多い(私見)。
-- Tig3r on the hedge
Re:COBOL の嫌なところ (スコア:1, すばらしい洞察)
誰が書いても同じになるようにってのを狙った言語仕様として、よく出来てると思うよ。
これ(レガシーなシステム)がみんなC言語だったりしたら、もっと怖いかも。
Re:COBOL の嫌なところ (スコア:1)
コンパイル後のコードが読みにくくなるから使うなって。
# そ~ゆ~先輩に鍛えられたのでS370の機械語(?)が読めたりします…
# これほど役に立たないスキルもないと思う。
notice : I ignore an anonymous contribution.
Re:COBOL の嫌なところ (スコア:1)
同一ソース内で整理するなら PERFORM でいいんじゃないの?
テンプレート機能とかが欲しい、とかいう世界なら微妙ですが。
Re:押し付けはよくない (スコア:1)
ま、流行り廃りはあっても需要だけは残るわけですがね。
COBOLに限らず、ほとんど遺失技術と言いたくなる代物は結構ありますよ(苦笑)、流行廃りでユーザー不在だから、そうなっちゃうんですが。
Re:押し付けはよくない (スコア:1)
ダイクストラがこう言ってる、という文脈を無視しちゃいけないよ。
COBOLのアンチテーゼとしてALGOLを産んだ人なんだから。
ダイクストラがCOBOLを悪と認識してないと、その後のPascalも
CもJavaも生まれないよ。だから彼においては頭ごなししてくれなきゃ
気持ち悪いのだ。
-- Tig3r on the hedge