![プログラミング プログラミング](https://srad.jp/static/topics/programming_64.png)
COBOL生誕 50 周年、しかしまだまだ現役 72
ストーリー by reo
深く根を張った老木 (なかなか抜けない) 部門より
深く根を張った老木 (なかなか抜けない) 部門より
あるAnonymous Coward 曰く、
COBOL が開発されたのは 1959 年。つまり、COBOL は今年で 50 周年を迎えるそうです。進化の速い IT 業界で 50 年前の技術というと化石のようにも思えますが、COBOL はまだまだ現役で、「ビジネスの世界ではまだまだキープレーヤーである」との記事が英 The Guardian に掲載されています (The Guardian の記事、本家 /. の記事) 。
COBOL は「COmmon Business-Oriented Language」の略であることは有名ですが、現在でも英国の上場企業の 7 割から 8 割は COBOL ベースのシステムを利用しているそうで、まだまだ COBOL を使ったシステムへの依存は続く見通しだそうです。記事では COBOL がこれほどに使われている理由として、「シンプル」だからであり、バッチ処理が高速で、またビジネスロジックにマッチした処理が書きやすいから、などが挙げられています。
COBOL よりも古い言語で現在もそこそこ使われている言語は多くありますが、COBOL ほどビジネスの世界で使われている言語はほかにないでしょう。新しいもので古いものを簡単に置き換えられるわけではない、ということをとても良く表している例だと思います。
現役です (スコア:5, 興味深い)
'75年生まれの現役COBOLerです。
現在の会社に入社して8年、もうすぐ9年になりますが、
入社してCOBOLを本格的に覚えました。
(個人的にはいろいろ言語はかじっていた)
環境は汎用機からの移行なのでサーバのベースがWindowsServer2003だったり、
ShiftJISデータとのやりとりなんかもできるようになってますので、
入出力ができればWindows上の適当なソフトをフロントエンドにする事も多いです。
業務的には15年以上続く定型業務が多いのですが、
「~な帳票を作って」や「~年から~年の○○の集計が欲しい」だのと、
大規模な新規開発はありませんが、定型から少し離れた部分での作成が、
月数件程度です。
別の方も書いてらっしゃいますが、金利計算等の部分で
ブラックボックスとなっている部分も多くあり、
わざわざ別の言語・システムを導入する必要がないのが現状です。
個人的に考え方がわかっていれば、書き方の問題なので、
FORTRANでもLispでもJavaでもC++でもPHPでもPerlでも
VisualBasicでもRubyでもJavaScriptでも何でもいいんですけどね。
できれば手数が少ないプログラムがいいなぁ。
アセンブラは手数が多そうなので勘弁してくだしあ。
Re: (スコア:0)
>できれば手数が少ないプログラムがいいなぁ。
金計算なら、結局はCOBOLにフロントエンドを別ソフトって既にやっているのが一番手数が少ないんじゃないかな?
ブラックボックスになっているってのはブラックボックスで済むって事でもあるし。
レガシー=悪とは思わないけれど (スコア:2, 興味深い)
銀行や証券・生保など金融機関の勘定系システムで多く利用されているため
スケジュールと人員面で移行が困難なせいもあると思います。
特に金利計算なんかはブラックボックス化していて下手にいじると収集がつかなくなったりして。
今COBOLで問題なく動いているものを、不要なリスクを背負ってまで他言語へ移行する理由もない、
と経営層は判断するでしょうし。
バッチ処理に強いとか言われるけど、日本語環境ではいまだに全角/半角文字の混在処理が苦手だったり、
GOTO多用で簡単にスパゲッティコードになったりするのはいい加減勘弁して欲しいです。
でもまだ当分現役なんだろうな・・・
/* pegiminh (aka .thx) */
必要なものでは? Re:レガシー=悪とは思わないけれど (スコア:2, すばらしい洞察)
>COBOL資産の他言語移行が進まないのは、
>銀行や証券・生保など金融機関の勘定系システムで多く利用されているため
>スケジュールと人員面で移行が困難なせいもあると思います。
>特に金利計算なんかはブラックボックス化していて下手にいじると収集がつかなくなったりして。
COBOLの最大のメリットって、BCDを採用している・・・それにつきると思います。
アセンブラ、FORTRAN、C、C++、Java、と渡り歩いてきたのですが、これらの言語で必ず付きまとってくるのが、有効数字ですね。
金融機関に限らず、生産管理系でも勘定系システムですと、利益と損失を日々集計していきますが、加減算の世界で閉じられるものであれば、・・・COBOLの存在価値は、低いでしょう。
問題は乗除算で、有効数字以上の桁数の値は、保障されません。
(借入金の利率をかけて、・・・とか、手形処理手を・・・とか)
これを1年間、誤差なしで処理できるメジャーな言語系は、今のところないのでは?
C++でもJavaでもよいので、BCDを扱える機能も取り込めば、状況がかわるかも。
# IBMがSUNにM&Aを仕掛けたのは、JavaにBCD機能を組み込んで覇権を制覇するため・・・・って、ふと思った私^^;
Re:レガシー=悪とは思わないけれど (スコア:1)
言語のコア仕様にBCD演算が入っているのは COBOL だけかもしれないですが・・・本当のところはどうなんでしょう。
COBOLの最大のメリットは「変わらない」こと (スコア:2, 興味深い)
だと思ってます。
そして、例えば住宅ローンの場合は最長35年あるわけで、いにしえのシステムが残っていてそのままCOBOLで運用されてても不思議ではないです。ただ、今後積極的に使われることは少なくなってくるでしょう。
かつて(今もですね!)金融を中心に一時代を築いた言語が今もある部分でメインストリームとして頑張っていることを思うと、哀愁を感じるというか、仙人と呼びたいとか、言語マニアといえるほどではない私ですが感慨深いものがあります。
消えていった言語に哀悼の意を表したいと思います。
# なんだこの締め
COBOL よりも古い言語? (スコア:1)
私はFORTRAN(元祖)くらいしか知らないのですが、他にどんなのがあるのですか?
現行Fortranは元祖とは随分違う言語となっているので、古い言語と言ってよいのか疑問ではあるのですが。
Re:COBOL よりも古い言語? (スコア:3, 興味深い)
・ユニバックのFlow-Matic
・IBMのCommercial Translator
・ハネウエルのFACT
Re:COBOL よりも古い言語? (スコア:2, 参考になる)
「Manchester Mark 1」の記事のリンクをたどると、 Autocode(1952年) [wikipedia.org]が「世界初の高級言語コンパイラとされることもある」って書いてあるね。
けど、 FORTRAN(1954年) [wikipedia.org]の方にも「史上初」って書いてある(^^;
# 自分ではFORTRANが最初と習ったつもりだけど。「されることもある」ってのはなにか条件あるのかしら?
Re:COBOL よりも古い言語? (スコア:1)
FORTRAN, COBOL, LISPの御三家よりは新参ですが, その後の多くの言語に影響を与えた点ではALGOLも捨てがたい.
Re:COBOL よりも古い言語? (スコア:1)
#質問の意図は, 高級言語 だと思うけど...
Re: (スコア:0)
#COBOLでcarとcdrとappendもどきのサブルーチンを作ったことがあるのでac
古いテレビ (スコア:0)
「壊れてないから使ってる」
「テレビがAV端子しかないんでAVケーブルを買ってきた」
とかいうだけな気がする。
別に、新しいもので置き換えられないわけでもないでしょう。
正直、COBOLを使う理由が「昔のソースがあるから」以外分かりません。
Re:古いテレビ (スコア:2, すばらしい洞察)
業務の裏と表を知り尽くした真のプログラマーの遺産が、
ロストテクノロジー化してる所が結構あるのかも。
再構築するのに、どれだけコストがかかるかさえ分からないような。
単純ということ (スコア:2, すばらしい洞察)
イギリスのIT関連には、鶏を裂くのに無理やり牛刀を使わない柔軟な人が多いということですよ。
Re:単純ということ (スコア:3, 興味深い)
そんな気質も影響しているのかも。
(そう言えば昔からPC・UNIX用ではこれしか思い浮かばないCOBOLコンパイラのこの会社 [microfocus.co.jp]もイギリスだった)
そういえば日本でこうした統計はないのだろうか (スコア:1)
少なくとも、こうした明快な表現で解説してくれる一般向けの記事は見かけないように思います。
資料はあるけど、噛み砕いた記事にできる記者やライターがいないのか、
記者が書いても「何が書かれてるかわからない」「こういう内容に興味を持つ読者はいない」というようなデスクレベルの判断で記事が出ないのか、
あるいは、研究者ら業界関係者がこうした調査そのものに興味を持たないのか…
Re:古いテレビ (スコア:2, すばらしい洞察)
私が関係したシステムは、
・スパゲティコード。GO TO, ALTER 使いまくり
・PROCEDURE DIVISIONが1万行を越す
・数百のグローバル変数
で、ソフトウェア作法にスタイルを学んだ自分にはすごいカルチャーショックでした。
結構、日常生活に影響するシステムだったので、必死で解析したのを覚えています。
特に、COBOLは抽象化性能が悲惨だと思います。
グローバル変数ばかりなのは、システムがトラブったときのメモリダンプ解析が
楽という点ではいいのですが、やはりなにかパワーの使い方が違うような気がします。
タレコミのように、COBOLにはいくつかの利点がるのかも知れませんが、
しがらみのない、新規のシステム開発の案件で、COBOLを使う理由はあまりないと思います。
Re: (スコア:0)
Re:古いテレビ (スコア:1, すばらしい洞察)
. 正直、COBOLを使う理由が「昔のソースがあるから」以外分かりません。
『COBOLを使う理由』はよくわからんが、『COBOL ベースのシステムを利用している』理由なら、むしろ「昔のソースがないから」だったりするかも。
道具の向き不向き (スコア:1)
もともとCOBOLって事務処理向けに規格策定された言語で、その規格の中で必要なシステムを、経済的に十分に組むことができるのであれば使いつづけられるでしょう。
そういう私も十数年前は「なんでCOBOLなんか使ってるんですか」と訊いたりしてたなあ。
プログラムは遊びや本来業務の片手間でしか関わっていないので、COBOLを使ったことはないけど、作法をきちんと守っていればソースコードの可読性はよさそうですね。
Re:古いテレビ (スコア:1)
変数がプログラム内で共通なので、変数破壊が怖い。
REDEFINEも罠を仕掛けているようなもんだし。
FILLERを確保しとかないとプログラム改定が大変。
基本固定長だからRDBとの相性もいまいちだし。
いろいろ欠点があるけど、できることが少ないことで
逆に分かりやすいというメリットがある。
Re:古いテレビ (スコア:1)
Re: (スコア:0)
タレコミ本文でも引用されてる利点が理解できないと見える
もう一度読みなおしたほうが良いね
Re: (スコア:0)
定型的な帳票処理をするのにわざわざ新しいプログラミング言語を使う理由がないから
いまだにdBASE(xBASE)が生き残ってるのも同じような理由ですよ
Re: (スコア:0)
皆さんにお知らせとお願いです。
COBOL 開発は、2011 年 7 月 24 日で、終了します。
ご理解とご協力をお願いします。
java生誕 13 周年、しかしまだまだ現役 (スコア:0)
jdk1.3(wikipediaによれば2000年リリース)で現役で動いてるシステムもあります。
今動いてるのにリスクを犯してまでわざわざ変える必要はないっていう考え方は
言語がなんであろうと変わらない気がしますね。
(COBOL2002で書かれてるシステムってどれくらいあるんだろう)
Re: (スコア:0)
そうですね。
アナログ放送を受信する理由も「古い受信機があるから」以外分かりませんよね。
ネタとして成り立たないんじゃ? (スコア:0)
だとしたら、雑談を始めることもできそうにないですねぇ。
Re: (スコア:0)
単に「COBOLerが嫌い」ってだけかも・・・。
# 自分自身、そうかもしれない・・・。
Re:ネタとして成り立たないんじゃ? (スコア:1)
COBOL経験者の一定割合が全然違う言語でCOBOL的コードを吐き散らした結果(それをするのがCOBOLer)。VB厨と同じ。
...じゃなかったっけ?
Re: (スコア:0)
つい最近の話ですが、COBOL使いの書いたCのコードを目にしました。
例のごとく、GOTO文使いまくりです。
というか、生まれて初めてですね。
CのGOTO文を見たのは。
#工数掛けられないから、そのまま流用しますがね。
Re:ネタとして成り立たないんじゃ? (スコア:1)
階段状の for の中に、ちらほらと goto が見えると、暗澹たる気分になりますね。
Re:ネタとして成り立たないんじゃ? (スコア:1)
いわゆる VB 厨や VBA 上がりの人が書くコードは、どこを見てもつっこみどころ満載でほほえましいです。ただ、こういうコピペや反構造化コーディング技法?というのは検収の仕方によってはステップ数水増しという詐欺行為にもなりえる。人月費固定なら問題はないけど、これで稼いだところも多いでしょうね。
こちらとしてはストレスになるとは言え、リファクタリングやら部分移行など後始末してる間に既存システムの勉強にもなるし、そのまま新規開発にもつながるし、書いた人を引退させる強力な理由まで揃ってて至れり尽くせりだったりする。まあ、上司になってもらっても構いませんが、その場合コーディング以外の管理的な仕事でもオネガイしておけば、みんなハッピーになれる。
意図があることを無視して自分流にやれるのは仕事が標準化されるより前の古きよき時代と個人的な趣味だけ、という事で。
Re:ネタとして成り立たないんじゃ? (スコア:1)
おそらく言語自体よりも古COBOLerの行う設計の酷さから来ているんじゃないかと.
基本的にロジックと処理の区別がついていないんですよね. ですから特に上位レベルの抽象性が高い段階での設計でも, いきなり実装レベルの個々のフィールドの取り扱いに拘ったりとか. 典型的な木を見て森を見ずの例です.
よく言われるビジネスロジックとの親和性なんてのも, 言っている当人がビジネスロジックを分かっているわけではなく, 単に既存の手書き伝票処理を業務分析・設計を省いてベタ移植しているだけ(しかも当人はそのことに気づいていない).
これが古いプログラムの保守とかになったら…永遠にスキルアップの可能性のないSE/プログラマの墓場と忌み嫌われてもしかたないと思います. そういう面から言えば, COBOL「も」使う仕事/職場ってのとCOBOL「しか」使わない仕事/職場ってのは似ているようで全く違う環境だと思います.
Re: (スコア:0)
(昔何かの本で読んだのに「銀行のシステムの開発をやっています」なヒトに対してクチでは「それは凄いですね」と言いながら、内心では『勝った、オレは人工衛星の制御だ』なんてのがあったな)
言語としてのCOBOL (スコア:0)
いにしえのCOBOLでその評判を落としているのは、
compute ステートメントのせいじゃないかな?
あと、identification division とか。
一生懸命に書いてると、バカにされてるみたいで思わず笑ってしまう。
ビジネスロジックの記述に適している?シンプルである?
本気ですか?って感想しか出てこないな。
# 業務ではCOBOLSしか使ったことないけど。
Re: (スコア:0)
>あと、identification division とか。
そんなとこコピペで終わりでしょ。
ENVIRONMENT DIVISIONもそうだし、DATA DIVISIONのFILE SECTIONはCOPY句でライブラリ参照するし。
自分で書くのはWORKING-STRAGE SECTIONの変数と、PROCEDURE DIVISIONのロジックだけじゃん。
ロジックなんて言っても、大半は式と代入を順序に従って書いていくだけ。
たまに単純な条件分岐はあるが複雑な制御なんてほとんど出る幕すらない。
これがシンプルでなくてなんなの?
もしそういうやり方をしてなかったのなら、言語以前の問題があるんだよ。
Re: (スコア:0)
ちがうな。
コピペで済むような部分が、全プログラムに必要なところが、
バカにしているところなんだよ。
昔の容量の少なさから考えたら、
コピペで終わらす所なんか捨てて当然。
COBOLの設計者は、そんな事もわからないのか?ってね。
Re: (スコア:0)
Re: (スコア:0)
程度の問題で、量的に冗長って事です。
compute ステートメントについてもそれ。
coboler を除く tecky は、一般的には冗長が嫌い。
結果、嫌われる…と、思う訳。
Re: (スコア:0)
レッドリストには載っているかもしれないけれど、決して絶滅してしまう訳でもないと思いますよ。
別に何でもかんでもCOBOLで書けと言っている訳じゃなし、何故悪いイメージが流布するんだか…
Re:ネタとして成り立たないんじゃ? (スコア:1)
入社以来何年かぶりにCOBOLのプログラムを見ることになりました。
もしかすると2010年代生まれの人も、同様に2038年問題対応でCOBOLに向き合うことに
なるかもしれません。
Re:ネタとして成り立たないんじゃ? (スコア:1)
COBOLには爺さまの盆栽いじりのような古臭さがあるのは否めません。
若いのに盆栽いじりをする人もいるでしょうけど、そういうのは敬遠したい
ものじゃないんですかね。
Re: (スコア:0)
>COBOLで書けと言っている訳じゃなし、何故悪いイメージが流布するんだか…
最初に仕事で使った機械が汎用機やオフコン、ビジネスパソコンで言語は
COBOLから入ったと言う人が90年代のオープン化やダウンサイジングの流行で
PC系の仕事にシフトしてきた時に仕事のやり方の違いとか言語の違いに
戸惑った人を多く見てきた人の印象が大きいのでは無いでしょうか?
COBOLしかできない人を無理やりそういう仕事に押し込んだ営業も数多くいましたし・・
自分もCOBOL出身の一人です。
今ではWEB系の仕事でjavaばかりですが・・・
所詮言語も人も適材適所だと思います。
Re: (スコア:0)
Outlook をバカにすればカッコいいと思っている
Windows をバカにすればカッコいいと思っている
PHP をバカにすればカッコいいと思っている
Java をバカにすればカッコいいと思っている
C をバカにすればカッコいいと思っている
#以下延々と続く
からでしょうな
Wikipediaによると (スコア:0)
現在でも稼動しているCOBOLによるコードは2000億行に上るとされておりこれはFortranとAssemblerをあわせた数10億行に比べても圧倒的に多い。
とか。
もしこれが本当ならば、現在のコボラーの少なさからすると、
COBOLはメンテ不要なほど完成度が高いプログラムが書きやすい言語なのでしょうか?
あるいは、単にどのシステムも既に枯れてしまっているだけのかなぁ...
COBOLは全然知らんのです、教えてエロい人。
Re: (スコア:0)
改行が多いだけです:-)
Re: (スコア:0)
帳票デザイン部分もライン数に数えられてるんだろうな。
そりゃ行数増えるわなあ。
Re: (スコア:0)
>現在のコボラーの少なさからすると
ここがちがう。
めちゃくちゃ多いぞ。うちの会社でも新規案件には外注も含めるとものすごい数投入する。
多言語の比ではないと思う。
私はLISPとアセンブラで食ってるのでたまに検証ツール書いてやるくらいしか関わってないが