【コボル】COBOL不要論【ただのDSLだよね?】

全然話が変わるんだが、昔何処かのサイトで「人類最後のコボラー」みたいな話を読んだ記憶があるのだけど、誰か知らないかな？

亀ネタだけど、Rubyが国際規格として承認されたね

主にCOBOLが未だ死なない理由は・・・
・夜間処理等、定時で動くバッチシステムとしては比較的軽量。
UNIXサーバのシェルとの相性も悪くない。
・半世紀前からあるようなホスト現役の所とか、誤差がダメ！ゼッタイな金融機関等々、
大幅システム再構築を嫌がる所では重宝される。

いくらなんでも中小企業でメインフレーム(オフコン) + COBOLを現役で使用しているところは随分減ったと思うけど
民間の金融機関（特に保険）や社会インフラ系（鉄道・電気・水道・ガス）、各省庁ののバックエンドなどの
案件で扱ってる言語は、今でもCOBOLが入ってるメインフレームが大絶賛稼働中だよ。
ウォール街やTOPIXにて毎日取り引きされている何十億ドルもの株、債券、オプションなどもCOBOLを使ってるところが多い
ただそういったところでも一般ユーザーが目にするフロントエンド系は殆どオープン系だったりするから
エンドユーザーが稼動しているCOBOLを実際に目にすることは皆無だろうね。

一番問題なのはスパゲティコード化してる事。もはや解読不能。　
継ぎ接ぎだらけなのにさらに言語自体を理解してるやつがいなくてブラックボックス化なのに使うことは止められない
現在正常に動いているシステムがあったら、ソースは絶対いじるなってのはどこの業界も同じ。

IDENTIFICATION DIVISION.
PROGRAM-ID. AD3410SB.
AUTHOR. ASNN.
INSTALLATION. SYSTEM PROG.
DATE-WRITTEN. 2011.10.10.

システムまるごと捨てる思いがないと、COBOLは無くならないよ
最新言語に置き換えることは可能だけど、現行の再現は一部困難

トップがシステムごとCOBOL捨てます！って宣言しないとダメだねｗ

リライト案件もあるんだけど現行保障をしなきゃいかんてことで
COBOL設計をそのままJavaに置き換えただけの「見た目だけJava」が横行していたり。

なんというかCOBOLは死んでも精神は死んでないというか、はよ死んでくれというか。

企業の基幹システムなんざ今も昔も思想は大して変わらんからな…
変える必要が無いものをリスクを負ってまでわざわざ他の言語に変える必要な無いという事じゃね？

COBOLがいかんのじゃなくて、COBOL脳がいかんのだと思う

優秀なCOBOL脳はいまでも優秀、もう現場にはいないけどｗ
ダメなCOBOL脳は昔からダメ、そしていまでも現場に残ってるｗ

アルゴリズム（死語？ｗ）を理解してない奴ばっかり！

まあたしかにCOBOLみたいに書きたいんだったらCOBOLでいいじゃん
とJavaで１クラス１メソッドプログラムを見てそう思った。

この時期になんとか内定をもらったんですが、その会社はCOBOLが中心のようなんです
COBOLには将来性がないらしいですが、そんなに深刻なんですか？
あと、まったくのど素人なんですが、やっていけるものなんですかねえ

つべこべ言わずに勉強しろ

技術に興味を持って普段から色々と勉強してればそんな酷いことにはならないけど
COBOL「しか」できないようだと将来的に辛いだろうな。

>>339
今更の亀レスだが、、、
COBOLそのものはそんなに難しくはない
JCLやらなんやら覚える必要は勿論あるけど。

それ以上に難しいのが業務ロジック
なんでこんな処理をここでやる？ってのは業務を知らんと判らん

後、家では他の言語を勉強しとけ
C,Java etc

>>342
COBOL以外の言語に慣れた奴にとってはとても難しいと思うぞ

業務ロジックに関しては他の言語でもやってることじゃん

で、 「業務ロジックは俺に任せとけ!!!」な、 SEとかって日本固有の
馬鹿な職業ができる、と…

本屋でCOBOLの本を立ち読みしたことあるけど、コードを5行くらい読んだだけで
つらくなって棚に戻した

CやJavaに慣れちゃった者には、あれを受け入れることは生理的に難しい
Lispとかのほうがよっぽど受け入れやすいのではないかな

C/C++のバッチ処理とCOBOLのバッチ処理はどっちが早いですか？ 理由もお答え下さい。

誰も答えられないのかぁ？

設計の話じゃなくて早さの話になる言語はクソだし廃れる。

>>339
あのねえ。仕事は言語で覚えるより、仕事の内容で選んだ方がいいよ。

COBOLの会社は大抵は特定派遣の客先常駐で、自社に机がない所ばっかだから、そういうのでメンタルやられて、鬱病になる奴が多いよ。

なるべく自社内で開発してる会社を選んだ方がいいと思うよ。あとメンタルについてもキッチリとフォローしてくれる所。

>>1
30年近くも前だけど、COBOLで書いたPROLOGというのは
見たことがあるから、単なるDSLではないね。

それを言い出すと elisp あたりは COBOL よりハルカに柔軟に
どんな言語の処理系でも実装できる
でも elisp は emacs 専用の DSL だ

>>345
そもそも処理系もそれを動かすCPUや周辺機器すらもバッチ処理に特化した環境でやるCOBOLでしょ
Cはそれに特化した言語でもなければ、動かすマシンもそれに特化してるワケじゃない

COBOLプログラムをJAVAに移植するためのライブラリってある？

age

COBOL批判してる人も経営側になったら批判できんとおもうが。
現行COBOLから移行なんてすさまじいリスク。

早く古いシステムを排除しよっぜ

オープン系の基盤が未だに脆弱過ぎる現状ではCOBOLを駆逐するのはなかなか難しいんじゃない？
SoftBankですら基幹部分は未だにCOBOLで稼働しているし…

早くCOBOLに代わるものを作りたい

COBOLから他の言語へのコンバーターとか

変換で構造やロジックが失われるようなコンバーターはダメ

C++11で書いてみるか

cobol to javaコンバータがあるよ。

変換後のソースなぞ見たくもないけど

>>359
蟻がとう

>>360
あと、Cへのコンバータもあるよ。
オープンソースで。

でも、それって変換率99%とかって奴じゃないの？

GNU CobolはCへのトランスレータだよね。
http://sourceforge.net/projects/open-cobol/

変換率100%ではなく必要なのは補償率100%

小保ラーのみなさんこんにちわ

笹井なことにこだわんな

COBOLの面白さは、後にメンテする者が、いかにメンテし易い様に作るか、に尽きるな。

グローバル変数しかないところを、シンボル名の工夫でローカル変数的な扱いだと知らせる。
COPY句使えば継承もどきもできるが、読解牲が極端に悪くなるんでやらない。
SECTIONをモジュールと見なし、その中で機能を完結させる。

よーするに、
入力−編集−出力が一目で分かるような制御構造をこさえ、
SECTIONモジュール強度とかSECTIONモジュール結合度とか、SECTION間での基本的なところをキチンとさせたプログラムを書くのは、
自己満足でも楽しい。

後で読んだ人が「すげ〜」って言うプログラムは、
概ね高度なテクニックよりも、
何をやりたいのかやろうとしてるのかが一発で分かる＝実装思想の一貫性が読み取れる
じゃないかと思ってる。

他の言語でも同じでないの？
　

>>367
メンテしやすいPGを心がけてる。

http://jobinjapan.jp/job-listing/keyword-cobol.html

COBOLの代替技術をまとめてくれ。

>>370
COBOLにローカル変数とスコープの概念を導入すれば、ほぼ一通りの物は書ける。

パックトBCDってもう古臭い技術だよな？ 4ビットで10進一桁なんてやらないっしょ？

あげ

なるほど。IEEE754-2008使えばいいんだ。

IEEE754-2008が使えるから、COBOLは要らない。ファイナルアンサー？

>>371
COBOL85からローカル変数はあるしCOBOL97にはクラスの概念もあるんじゃなかったかの？

>>376
そう、以前の記憶で最近のCOBOLはローカル変数導入したはずとgoogle先生に尋ねたんだが
どうにも見当たらなかったのさ。

COBOL2002さんはいつになったらオブジェクト指向言語として活躍するのかな…