【IT】そろそろCOBOL絶滅のシナリオを考えようか
■ このスレッドは過去ログ倉庫に格納されています
いやぁ、調査結果を読んで腰が抜けそうになった。何の話かと言うと、日経 xTECHが実施した「COBOLに関する実態調査」の件だ。社内にCOBOLを使ったシステムがあると答えた人が、なんと回答者全体の61.6%を占めたのだ。
この「極言暴論」の読者ならよくご存じかと思うが、私は「反COBOL」の急先鋒(せんぽう)と見なされている。COBOLを巡る「大問題」について警鐘を鳴らす記事を書き続けてきたためではあるが、若手を「コボラー」に仕立て上げている人月商売のITベンダーの経営者らからは目の敵にされている。
そんな訳なので、この調査の結果に腰が抜けそうになったのだ。正直に言って「まだこんなにCOBOLプログラムが残っているのか」と衝撃を受けた。もちろんCOBOLプログラムが金融機関や官公庁を中心に多数残存しているのは承知しているが、まさか半数をはるかに超える回答が「COBOLあり」とは衝撃的な結果だった。
関連記事:還暦COBOLはお荷物?リプレース計画が独自調査で判明
中堅企業などではIT部門が絶滅状態になってしまい、ITベンダーからも見捨てられた「IT棄民」とでも呼ぶべき企業が多数存在する。こうした企業の基幹系システムは十数年、数十年にわたり塩漬け状態になっている。当然、多くはCOBOLプログラムだろうが、もはや誰も調べたことが無いので表には出てこない。そんな「ダークCOBOL」も含めると、残存するCOBOLプログラムはかなりの数に上るはずだ。
関連記事:「IT棄民」の企業が急増中、見捨てられても気づかない愚
COBOLプログラムがこんなに残存するなら、例の「昭和100年問題」も本当に起こるかもしれない。日付を和暦の2ケタで扱う、昭和期に作られたプログラムを改元などのタイミングで改修していないならば、昭和100年に当たる2025年にシステム障害が起こる。それが昭和100年問題だ。
実は、私は昭和100年問題を一種の都市伝説と思っていた。30年以上も前のプログラムはわずかしか残っていないはずだし、残っていても改修ぐらいしているだろう。そう高をくくっていたが、その前提が崩れるような事態だ。COBOLプログラムに限った話ではないが、30年以上にわたり使われてきたプログラムは決して“わずか”ではない。
そういえば、こんな調査もある。経済産業省が公表した、新元号に対応するための企業のシステムの改修状況に関するアンケート結果だ。それによると、1割弱の企業が「業務に大きな影響は無いので改元日以降に対応する」としている。平成への改元の際にも、そして新元号への改元の際にも「業務に影響がない」とスルーされたCOBOLプログラムは2025年にどんな影響を及ぼすだろうか。
以下ソース
https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00148/032700052/ さすがに今時COBOLは貧乏な地銀くらいしか使っとらんやろ。。 いいじゃんCOBOLがあっても!
こいつレイシストだな! 日立で勤めてた頃にCOBOL97?みたいな日立のCOBOLを使ってたな
自社向け給与計算ソフト
配列宣言してデータの羅列にガチャっとデーターが流し込まれて
それに対して処理して戻り値を返す感じだった
知らんけど 人は記憶型と思考型に大別できる
始めっから4桁にしとけよ、と思うけど・・・作られた当時は容量を小さくするために必死だったんだろうな 20年前にSE辞めたけどまだCOBOL使ってるのに驚き
未だにCOBOLのバッチプログラムも走ってるのかねwwww 僕らの知らない生活スレにいた半引退プログラマーのおじいちゃんが時々依頼くるって書き込んでたなあ 作り変えが簡単じゃない金融系のシステムの多くがCOBOLなんだから
メンテ・改修の仕事はあと20年はあるんじゃないか?
使えるPGが増えないから単価は安くならないし、ビジネスとしては良い言語だと思うが。 COBOLをリプレイスさせたいSIerの提灯記事
COBOLはバカでも読み書き出来るように設計されてるのでメンテが簡単 結局のところ安定して稼働してれば言語は問わない
むしろ新しいもんに飛びついてもそれが10年、20年持つかわからない COBOL使ってる企業をリストアップして、
不買運動して倒産に追い込めば
COBOLはちゃんと消えるじゃん。 無理 日本の中枢はいまだにCOBOL。
最先端の携帯各社もCOBOL 私はシステム開発をしたことがない馬鹿です まで読んだ COBOLは世界最先端のハッカーがハッキングできないのが残留理由の大きな部分。
新しいハッカーが生まれてこないのがセキュリティ。 COBOLをJAVAにリプレースしたって、
どうせ20年とか30年後に「まだJAVA使ってるのか絶滅させろ」って言われるんだろ? まあ、考え方で、COBOLを現代に合うように進化させればいいだけだと思うがな。
と1週間だけCOBOLを使ったことがある俺が言ってみるw まだまだ全国で使って、そんな簡単になくならない
費用がない 業務ロジックはCOBOLでもDBアクセスはSQLだったりするから
全く進化してない訳ではない 日経コンピュータの記事は大昔からこういうばかり
8,90年代の雑誌残してある
煽るなw 全面核戦争が起きれば、EMPでCOBOLもろとも全部消えるじゃん。 俺はJAVAを学んだが何の役にも立たなかった
どうせ役に立たないならコボラーの方がかっこよかった >>33
格好が良いとは思わんが、JavaはSUNの消滅と共になんか魅力無くなった気がする。
汎用機の伝票発行用オーバーレイなんかはCOBOLどころかアセンブラで動いてる半世紀モノが未だ有るんじゃねえの?
わざわざ汎用機ベンダ各社独自のやつ新たに買わんでも安定して動くとか言ってな。
このいつもの日経BPのコラムニストが反COBOL気取るのは勝手だが、JCLの記載を全部調べて現状調査報告書みたいなもんを全ての法人の情シス要員に作成か検証させて見りゃ、もう少し面白い記事書けると思うぜ。
極言だけで金払う会社ばかりなら、従来型SI業者だって随分楽だと思う 十分な範囲の数値を割り当てをしなかったという問題はCOBOLに限らないから RPGの進化はすごいね
COBOLより読み書きしやすくなった 【4月1日、コリアン移民解禁】 統一教会ファミリー、岸信介、安部晋三、稲田朋美、世耕弘成、中村格
https://rosie.5ch.net/test/read.cgi/liveplus/1554084624/l50
いよいよ令和=対日破壊命令が下るぞ COBOLをずっと使い続ければいいじゃん
移植も大変なんでしょ?
職人を増やしなさいよ メンテがまともに出来ないシステムが悪いのであって
COBOLが悪いわけじゃねえだろ 受けを狙ってCOBOLで絞ったんだろうけど、
COBOLと同時代のレガシーなら珍しくない
街工場の生産ラインとか 根本的な問題としてCOBOLじゃ何が駄目なの?
今まで特に問題ないならこれからも特に問題ないのでは? IT土方に今求められてること、それは当たり前のことを当たり前にやる事、言われたことをきちんと聞くこと。 大手金融機関に居たけど、金融機関の原則は『リスクを取らない』なので
今動いている物をコンバージョンしてまで無くさない。
新しい言語にしたって同じ事になるなら枯れた技術を使う。
金融機関の話じゃないけどPentium時代に486チップを並列処理で使用してたトマホークが良い例。
COBOLなんて、どうでもいい!
新しい元号「令和」と共に
新しい日本を創っていこう!
そのためにはまず
パヨク(ゴキブリ在日韓国人)
をスリッパで叩きつぶそう!
言語の問題なのかねえ?
なんかピントがずれてる気がする Railsで作って周辺ライブラリの非互換アップデート食らって
爆死した数の方が多そうだけど >>45
世の中で人気がない
プログラミング言語だけじゃなく、誰も学ばなくなったモノは滅びる >>23
可能性はある
javaがずっと続くわけではない COBOLが使われなくなるよりも記事書いた木村岳史の方が先に亡くなりそう >>58
最近は技術的負債になるとかで
過去の仕様を削除する
cobolはそんなことしないのを売りにしていると思うよ もともとrubyの作者がいる会社はCOBOLで飯を食っていた
今も使ってて思うよ
今さらCOBOLの仕事はやりたくないのが
多くのエンジニアの意見じゃねーの
俺に選択があるならける これ以上、開発言語を増やすなよ。
流行りに乗って使いたがる若い奴らが導入を繰り返し、
阿呆みたいに多種多様の言語のプログラムが散乱し、
自分達が歳をとった時に頭抱える事になるんだから。 >>45
AWSやAzureのようなクラウドサービスにまともに対応していない
これは致命的
もうメインフレームでCOBOLの時代じゃないんだよ スクラッチでリメイクする場合でも、最近ぽっと出の言語より最新のCOBOLは仕様が安定していて、結果的にメンテナンス性に優れるのでは?
お金を扱うなら、完全十進法ででなきゃ。 一通りレスを読んだが、おまいら、COBOLでプログラム組んだことないだろ。
COBOLの一番の問題点は、まず、記述力の低さ。
Pythonで1行でかける処理がCで5行くらい必要なことがあるが、COBOLは
20〜30行ということすらある。全部の処理を中学生レベルのフローチャートで
書かされる感じを想像するといい。
次に、変数の種類が複雑すぎること。2進化10進数を使っていることもあるが、
10進数で整数部分30桁、小数部分2桁といった変数の指定ができる。
例えばこの例で、「30桁」や「2桁」がなぜ必要なのか、実は適当に決めただけ
なのか、深い理由があるのかが、後になるともう分からない。小数部分では
計算が進むにつれて自動的に切り捨てが行われていくが、これが例えば「3桁」
だと違う結果になるのは容易に想像がつく。
ファイルの指定もそう。今ではファイルはバイトの列だと思っていればいいが、
メインフレームのファイルの形式の指定はめちゃくちゃ大変。レコード単位、
ブロック単位、さらにそれぞれが固定長なのか可変長なのか、キー付きなのか
シーケンシャルなのか。
こういった塩梅なので、計算結果が一円でも違うと担当者の首が飛ぶような
金融システムでおいそれとリプレースはできないのだ。 >>69
COBOLが必要悪であることの記述にしかなってないが >>69
だからといって金利計算をpythonでdecimal使ってやれと言われたら
それはそれでお断りしたい 勤労統計問題の原因は「COBOLプログラムのバグ」 >>66
そもそもクラウドに移すのが人的エネルギーがね… 銀行システムは外部から導入され、人類を金の奴隷に貶めた 2000年問題でのAP修正処理の対応年がもうすぐな筈だから自然に別言語&システムに変更しないと使えなくなる ソフトバンクのシステムは謎が多いが
LinuxでCOBOL動かしてるとか噂で、コレは無理じゃないのか 昭和から、FORTRAN,PL/I,COBOL,ALGOLを推奨
してきたメディア、ベンダー、今度はたたきですか イージス艦とかがCOBOL使ってるって噂あるけど、本当なの? Authorに当時のIDO携帯の番号を書いてたけどまだ番号は生きてるから何かあったら連絡してくれw COBOLより歴史の古いFORTRANもいまだに残っている。 >>91
半角はアルファベット含めて廃止か使用禁止で さっさとやってくれるプログラマを過去に
低賃金化した× COBOLは滅びぬ!何度でも蘇るさ!
COBOLの力こそ企業の夢だからだ! 日本人って変更することを異常に嫌うし懼れます
いままで上手くいってたんだから、これからも上手く行くに決まってる
こう思い込んでるから、当然、COBOL依存礼賛する AI「プログラム言語は人間が理解不能な程度には複雑で多様であるべき ばかじゃねえの
COBOL使おうが使うまいが自由だろ
絶滅とか余計なお世話だ
FortranもCobolもたぶんまだまだ残るよ。
新規開発はありえないわけだし、ほっと毛羽そのうち消える
>>69
もっと核心を突けよ。
金融関係では利息その他の計算方法が厳密に法律で規定され、
もちろんこれは10進数ベース。
これに添って忠実に計算するには10進計算のハードと
これを動かす10進でインプリするのが妥当と言わざるを得ない。
たいていのプロセサには10進命令があるが、
言語が10進をサポートしているとは限らない。
サポートしていて最も実績があるのがCobolということになる。
カネ勘定で問題を起こしたら金融機関として命取りになりかねず、
結果としてCobolを選択する場合が多くなる。
>>93
ごくごく一部でな
全く金にならん言語なのが現実
それならpythonやった方がいい >>104
何進数で計算しようが、スペック不足とかおこらなければ結果は一緒だ。
10進数命令というのが特にあるとしても、どの言語でも導入できる。 元号対応もCOBOLが一番苦労してると思うよ、なんとなく。 Fさん未だに業務アプリF-COBOLで量産しとるで…(´・ω・`) よく古い企業と官公庁でCOBOLと言われるが
官庁って一定期間ごとに入札でシステム管理会社が変わるよな
著作権買い取りとかの契約じゃなかったらプロプライエタリのコードは持ち越せないだろうし、
COBOLが残る余地がそんなにあるんだろうか? バカはインフラと同じに考えてるからな
道路や建物なら古くなったら止めて壊せばいい
専用の土建業もウジャウジャいる
そういう物の見方しか出来ないんだよ
でも止めたら困るシステムなんてのは市役所そのものの代理だ、
bkの頭の中の比喩は土建で埋まってるからITも同じモンだと考えてるからアホなんだよ
一番簡単な方法は役所の中の奴らを全員プログラミング出来るようにすることだ
これが一番かんたんな解決法だよ
そしてそれ以外の方法は無い
要するに内製だ
土建みたくかんたんに発注できると思ってるから役所のアホどもはアホなんだよ 地銀はほとんどM/Fなんだな
M/FイコールCOBOLかは知らないけど いくつか古い企業にいたけどバッチはCOBOLそのまま(でもOPEN COBOL化)オンラインはJAVAで新たにシステムつくってあるパターンだった
ハードの問題がクリアされた場合割としぶとく生き残る傾向があるわ >>69
すっげえ良くわかった
金融機関の場合、COBOLと言う言語だけの問題じゃないな
そもそもの、消費税は端数切り捨てとかの、端数に関する法律を緩和しないと、どの言語で書いたとしても、保守できないモジュールの嵐になる
ファイルの構造指定は、メインフレームの時代の遺物だから、これは解消できる >>106
何進数でも結果が同じというなら、10進数の0.1を2進数で書いてみてよ。 調子の良い機械は弄るな。これ機械の鉄則。車、産業機器も同様です。
新規開発にCOBOLを使用しないでしょう。調子が良ければ残るでしょう。マイコンは
アセンブラレベルの開発した製品は、設備そのものがなくなり、新規開発がほとんど。 >>115
元の文は規格が定まって無く適当にやったから面倒だということだろ。
緩めたら余計に移行が難しくなる。
厳密に設計する、厳密に規格が定まってると別へ移行しやすい。 >>117
何で分数なんだよ、直接書けよ。
それか10進数じゃなきゃ誤差が出るのを認めるかどっちかにしろ。 2つの数字ペアを扱うことはどの言語でもできるだろ。分数は取り扱えないなんて事はない。
配列なら3つ以上の数字でも。 1÷10ってのは計算式であって結果じゃないだろ。
1÷10の結果を変数に入れたときのダンプを2進数で書いてみろよ。 木村ネタはニュー速のヒュンダイネタと同じ扱いでいいよ
批判しても何も解決しない
原稿料が発生して、読者の暇つぶしにになってるだけ どっちにしろコボルでさえ2進で計算してるわけだが。
ハードウェアから10進対応しなけば2進に帰着させられる。
2進でも4ビットで16種類つかえるから10進できる。 LD A,$12
LD B,$34
ADD A,B
DAA
結果は0x46だが今更これをやるのか >>124
ここでうじゃうじゃ文句たれてる分には、コラムニストに直接カネは落ちないがな…某モータージャーナリストの様な評価は得られるのだろうが。
Pythonにはdecimalモジュールが有る様だが、cやJavaやらには明確なライブラリとか有ったっけ?
汎用機のパック固定少数点十進みたいに型とCPU命令をギッチリ繋いでいる印象が、IAで動くコンピュータには何故か薄いのは何故だろう。 よく考えたら例えおかしいな
LD A,$19
LD B,1
で結果0x20のほうが解りやすいか >>69
Cのほうがコード数はかかる
そもそもCOBOLがCで出来ている COBOLより後で出来た当時最先端の言語がとっくに絶滅しとる
今、流行の言語が絶滅しても、、 汎用機は、本当に機械語で直接10進演算ができることを知らない奴がいて笑える >>133
だから、君ならどうしますか?
いくつかやり方があるよ
ただし桁落ちは頻発 >>134
小さなオーバヘッドでは無理なんだな
特に2進→10進スケール変換のときに大量の除算が入る JCLなんか苦労しないでしょ
メーカーが提供しているマニュアル読んだら記載してある
ハードメーカー提供マニュアルに事例まで記載してある
そういうのがあるのを知らなかっただけ >>138
JCLってメーカー毎、System毎、sub system毎に全部違う言語だったわけだが
おまえは全部知ってのか??w 古いシステムはCOBOLが問題じゃなくて
ドキュメントがない、メンテされてないのが問題じやね?
言語自身に致命的問題あるの? >>141
田舎から財務省まで
警察が横取りしたのか知らないが
出所不明の汎用機でJCLとか無茶苦茶だぞ >>135
電子計算機な電脳に「小数点」という概念は元々無い
だからこそ、「浮動小数点」法を採用
いまの電脳はスペックが高いからこんな変則技を駆使しなくて済みます
そんなもん必要ない
ただこれって科学計算なら許されるが、実務計算では許されませんわ 単精度、倍制度とかの世界は、初期の電脳にない概念
ともかく、一点突破な「速度」最優先
したがって、それをインタラプトするものはすべて排除
もともと、命がけの戦争用に研ぎ澄まされた機材
平時のバカにノンビリした話でしかないわけだ 科学計算の肝は、近似値でOK
ただし複雑怪奇な計算を如何に速く仕上げるか、これが命
数値の厳密な精確さを取れば、処理速度は落ちる
わかるでしょ? いまの計算機の主流は浮動小数点だろ?
スパコンとかもグーグルの人工知能とかも浮動小数点だろ? 機械語の前なPGは、バイナリ・コードが読める人でした
0101の流れが電流の流れであり、物理層まで解釈可能な達人
ひと昔前のメイン・フレームって、そのくらい単純明快さがあったんだな
0=オフ
1=オン
富士通の赤いスイッチにある通りです
あそこは電話機と電話交換機で売買して、そこまでデカくなりますた
元、富士電機通信機な古川財閥ぼ富士電機から分離独立 リレー回路ですよ、そんな単純なもん、小数点、知らねーよ 浮動小数点型でも厳密計算できるだろ
320億桁まで計算できるGPU用円周率計算ベンチ 2014/12/5
GPUPI Beta 1.3 オーストリアのオーバークロッカー向けサイト「overclockers.at」にて、
GPUの並列演算を利用した円周率計算ベンチマークソフト「GPUPI Beta 1.3」が公開されている。
このプログラムはGPUの並列演算を利用することで、CPUよりはるか高速に円周率を計算できる。
例えば有名な円周率計算ソフト「SuperPi」を用い、Core i7-3770Kを7GHz超で駆動させて100万桁の円周率計算を行なった場合の世界記録は5.078秒だが、
GPUPIは筆者が現在使っているエントリー向けのGeForce GT 640でもわずか0.086秒で終了する。
https://pc.watch.impress.co.jp/docs/news/yajiuma/679028.html
円周率の小数点以下8000兆桁めをGeForceで求める方法〜GTC 2013の「π」
数学者の間で「円周率の日」と呼ばれる3月14日。
2013年のこの日に,米国サンタクララ大学,Ed Karrels氏らの研究グループは,円周率計算に関する新記録「小数点以下8000兆桁め」を達成したと発表した。
しかもその計算をCPUではなく,ましてはHPC向けGPUであるTeslaでもなく,ごくごく一般的なGeForce製品で達成したというのだから驚きだ。
https://www.4gamer.net/games/120/G012093/20130323002/ 公務関係って今でも富士通信機がショバ張ってます
次がパナソニックな松下電器産業株式會社
この二社、公務の入札完了のテラボスクラス
そのむかし、パナファコムなる怪しいJV会社もあったもん
1973年 - 富士通と松下電器産業(現・パナソニック)の合弁で、パナファコム設立
松下通信工業なパナファックスはある時期までファクシミリの特許独占企業
ここに貿易障害は一切ないのでした
まるで飛ぶ鳥落とさんある時期の「XEROX」みたいだ 1980年前後の製造業で最高水準の給与と福利厚生できたのが
西の松下電器産業株式会社
東のトヨタ自動車工業株式会社
これが製造業における「両雄相並び立てた」瞬間ですた
先に一旦大没落したのが松下
これは電気喰うプラズマディスプレーに肩入れし過ぎた結果が招いた経営戦略の失敗
シャープの十八番な液晶があそこまで綺麗に速く動作するとはね〜
そのシャープもここで慢心して今や台湾の子会社とは如何にも情けない
V字回復したけど幸之助が最も嫌った「馘首」というリストラで人員削減っした結果でもあるのだ いまのところ、トヨタだけは無傷に近い超越した製造大ボスしてるが、一寸先は闇である 画像処理のチップな石があそこまで急激な進化を遂げるとは松下幹部も知らないどころか
御釈迦さまでも、モス化すると知らない シャープは外資化
パナはその必要なしって
公務関係への不快くて深いコネクション力の差が大きい 最新鋭の尼崎工場を殆ど稼働せずに叩き潰す
一方は、堺のスゲー工場を捨て値で転売だっけ
カラフィルタ製造な凸版もDNPも延焼しますた
多くの血が流れた模様らしいねwww この辺の惨めな失敗談はNHKで
【プロジェクト マイナスX】で放映希望痛し早漏座衛門
>>131
x86でも10進あるよ。
でないと、オープンシステムで勘定系は構築できない。
一応実績は乏しいがあることはあるからな、新生とか。
金融業では、法律で厳密に計算方法が規定されている。
もちろん10進数でだ。
2進や浮動小数点で法律に添った金融計算をしたいなら、
プログラミング段階で物凄い誤差解析をして、
10進計算した場合と全く同じ結果になることを保証しなければならない。
「1円くらい違ってもいいだろう」
は通らない。
開発効率は最悪な上、危ない橋まで渡る意味は無い。
今はどうか知らんが、
マイコン系だと、多桁の10進演算があるか分からん。
メインフレームならそこそこの桁数がサポートされてるけどね。
もしかしたら、マイコンの場合、
少数桁単位で分割して計算する必要があるかもしれない。
でも、それでも性能的には問題無いでしょ。
性能は物凄く向上している。
アメリカのトップクラスの半導体企業でVAX見たことあるぞ。意外とデカイんだ。
COBOLくらいなんてことない。 アイデンティフィケーションディビジョンってやつで挫折した。
英語多すぎやで。
あと、計算式の前に必ずコムプットって付けないといけないのが
どうしても納得ができんかった。 >>161
それは10進演算を「補助する」命令な
それとコプロにもBCD演算があったか
でも、ストリング命令系で直接長いBCD演算ができないと、十分な性能は出ないんだ
ネイティブで動作するメインフレームは、国産では一時死滅した。
どうやってたか?
FやNは、IA-64、いわゆるitanium、これでメインフレームの命令を模していた。
それでも所定の性能は出た。
勘定系の計算負荷など全然どってことない。
ちなみにHはたぶんIBMから買ってたと思う。
ネイティブはネイティブだが国産部分は0。
itaniumはHewlett-Packardで辞めて
Intelでやってるかも不明、続けてるかもしれんが
日本電気も次の汎用機のコアCPUがない
>>173
itaniumはもう開発してないし、先が無い。
FもNも自前に回帰したよ。
FはSparc、ARM、メインフレームの共用設計、
Nはitanium以前の独自プロセサの焼き直し(負担が重いのでitaniumに逃げていた)。
どっちもパッとしないけどねw
富士通の6000なんて、クラウドオフコンとか出してるからまだ残るだろう カンタンな話、少しの誤差が出ても大丈夫なように社会全体を作り変える、だろ
キッチリした一円未満の計算は社会的に大コストだ
数億回の一円未満計算のために50億円くらいつかってんじゃねえの?
そしたらンなバカなことをしてる集団に未来はねーじゃん decimal型をサポートするだけでいいのに新言語はそんな事もできないのか >>179
各言語で多倍長の型があると思う
JavaだとBigDecimal、扱う最大桁数は2793926648桁だったと思う スルーのスペルをCOBOLで覚えた。
難関だった。 フィンランドの悪行見てると、Linuxになかなか行けない >>185
電力の制御とかやってるはず、電気なんてそんな前性器のかたまり >>185
そのCOBOLを超えるメンテナンス性を備えた言語が作れないのさ。
前世紀だろうが何だろうが、優れた言語であることには違いない。
>>1の反COBOL論も、昭和和暦2桁計算が残ってたら事故が起こるというだけで、これはCOBOLの問題ですらない。
一番手っ取り早いのはCOBOLを超える保守性を備えた言語を作って公開することだ。
筆者は反コボラー原稿で飯を食うという芸風のライターでしかない。 >>185
前世紀の遺物、java javascript python ruby fortran cobol c c++ c# ...
今世紀の産物、julia nim rust golang ... >>185
全くその通りですが、10進数の言語がないのが問題。 COBOLを他の高級言語と一緒にしちゃダメ。
事務処理に特化した簡易言語と考えれば今でも立派なもんだ。
正にCommon Business Oriented Language。 これはCOBOLの話というより、
化石システムの保守をさせられたSEは将来使い捨てに合うという話なんだな
木村の信者の多さに納得 化石システムは不死だから、使い捨てにはならないで永遠の命を授かるよ そういやゴブリンやオーク、オーガは映画やアニメで観るが、コボルトは観ないな >>188
OSも作れないなw
pythonは21世紀のBASICかも?
何Mステップもあるプログラムは簡単にリプレースできないから、ハード変えてもプログラムはほとんど変えないで動作するようにする方が楽
したがってCOBOLは消えない
木村とやら残念だな COBOL言語が悪いんじゃなくて
既存の拡張を繰り返させる経営層が悪いのに 日経がよくこんな乱暴な語句をつかった記事を公表できますね
新聞社じゃない >>195
どこの世界にシステム拡張のたびに、スクラッチして1から作り直す会社があるの?
MSでさえ1から作り直しやめちゃったし
たぶん128ビットCPUが出てネイティブで動くOS開発するまでない >>188
年代で分ければPythonは20世紀だが、仕様は21世紀のトレンドだろ
逆に、golangは年代は21世紀だが、言語仕様は20世紀の遺物だわ
cobolは20世紀だが、あの10進数演算は21世紀の言語では書けないので、深海魚みたいに生き延びてる 【12日まで】500円を貰える春のばらまきキャンペーン開催中です
@ スマホのApp Storeから「プリン(pring)」をインストールする
A 会員登録を済ませる
B 下図の通りに進む
https://pbs.twimg.com/media/D3pILVCUEAEKnN6.jpg
C コードを登録 [5gAYSz]
これで五百円を貰えます
スマホを使ってセブンATMからお金を下ろせたり(キャッシュカード不要)便利なアプリですので是非お試し下さい。 コボルはまだ残り続ける。
大規模で複雑怪奇なコードのオバケを解析する資金が無ければ今のシステムは残される。 ニーズあるから無くならないよ
20年前も同じこと言ってたけど
結局一番強い >>198
Pythonのどのあたりが21世紀なんだろう ■ このスレッドは過去ログ倉庫に格納されています