還暦COBOLはお荷物か？ 日経xTECH調査 74
ストーリー by hylom
まだまだ残るでしょう 部門より
まだまだ残るでしょう 部門より
あるAnonymous Coward曰く、
日経xTECHがCOBOLに関する実態調査結果をまとめている（還暦COBOLはお荷物？リプレース計画が独自調査で判明、還暦COBOLの何が悪い、独自調査で分かったこと）。COBOLに対しては旧時代の技術とされる風潮もあり、「若者をCOBOLエンジニアとして育てることの是非」といった議論もあるが、未だに多くの企業でCOBOLを使ったシステムが残っているという。
この調査はCOBOLは本当にお荷物なのかという視点から行われたものだという。その結果、回答者1348人のうち、85.7％に当たる1155人がCOBOLの経験があると答えており、経験年数は「10年以上~20年未満」が最も多く、23.7％を占めた。また、10年を超える経験者も多く、およそ半数に達した。
また、自社や担当企業に使ったシステムがあると答えた割合は、実に61.6％に上った。「開発言語COBOLの短所はなにか」として、問題点の上位3つを挙げてもらったところ、エンジニアの確保が難しい、新規開発案件が少ない、スキルの市場価値が低い、といったことが挙げられている。
一時はCOBOLも花形だった (スコア:2)
あと10年か20年すればJavaもこういう扱いになるのだろう…
Re:一時はCOBOLも花形だった (スコア:1)
いずれはね。
10年じゃありえないかな。
Cobolが2009年に今のJavaのような立場だったか考えりゃ分かる。
30年後くらいにはJavaも今のCOBOLのようになってるかもね。
Re: (スコア:0)
Javaとより近代的なプログラミング言語の間にパラダイムシフトと呼べるほどの差があるかどうかですかね…？
# 正直ここ10年くらいで「プログラミング言語」って進歩してる？？
Re: (スコア:0)
10年前のJavaと今のJavaを比べてみてください。
理想を諦めて現実に妥協した歴史が見られるのではないでしょうか。
Re: (スコア:0)
理解。シンタックスシュガーばかりでパラダイムシフトはしてないってことね…
Re: (スコア:0)
LISPerが言ってそうなセリフだ
Re: (スコア:0)
言語史に置けるレベルの変化では無いが、Java的にはLambdaが入ったのはパラダイムシフトだよ。単なるシンタックスシュガーでは無い。
ちょっと古いがGenericsが入ったのも大きな転換。
このレベルをシンタックスシュガーでありパラダイムシフトじゃ無いというなら、そもそも同じ言語の中でパラダイムシフトは起こせないね。
言語の意味変わっちゃうから。
Re: (スコア:0)
> ifもforもwhileもgotoのシンタックスシュガー
gotoだけでは、条件分岐もループもできないですよ。
まてよ、古のfortranには計算型goto文ってのもあったか。
あれは現代的にはcase文相当ということになりますね。
Re: (スコア:0)
どちらも馬鹿だな
言語のあたらしい概念はシンタックスシュガーで実装したり、プリプロセッサで実装したり、あるいは実装まるごと変えたりする必要があったりする
お前らは概念とその実装の区別がついていない
COBOL爺以下だよ
> ラムダは短く簡潔に書けることにこそ意味があるので
違うね
新しい概念の導入だ
Re:一時はCOBOLも花形だった (スコア:1)
Re: (スコア:0)
C#というか.NetのLinqは劇的な発明だったと思うけどな
コードを書く際の考え方やスタイルまで変わったし
Re:一時はCOBOLも花形だった (スコア:1)
LINQってメソッドチェーンと何が違うの？
Re:一時はCOBOLも花形だった (スコア:2)
LINQ ⊂ メソッドチェーン
メソッドチェーンはただの形式。
そう書けるメソッドをつなげて書いたら、なんでもそう。
LINQは「統合言語クエリ」。
何かの順序集合を加工するためのモジュール。
https://docs.microsoft.com/ja-jp/dotnet/standard/using-linq [microsoft.com]
Re: (スコア:0)
遅延評価とかクエリ式とか
Re: (スコア:0)
LINQ がメソッドチェーンとか、、、どんな発想した、そんな理屈につながるんだか。
Re:一時はCOBOLも花形だった (スコア:2)
そこは、ﾆﾔﾘとするところだと思ってみる。
合っているけど、ずれているので。
Re: (スコア:0)
ちょっとおしゃれな感じにしただけで、大した変わらないと思う。
Re: (スコア:0)
ターゲットが何かを気にしなくてもいいところ。
オブジェクトの取得もXMLの解析もデータベースへの問い合わせも同じ構文が使えて
あとはコンパイラやライブラリがいいようにしてくれる。
Re: (スコア:0)
ラムダ式もね。
Re: (スコア:0)
Kotolin とか Clojure とかの JVM 系言語はまだ息が長そうだけど、Java 本体は違うのかな？（よくわからない）
Re: (スコア:0)
元コボラーって人が結構いたりするから今もコボラーという人は逃げ遅れたのかな。
Re: (スコア:0)
新規の案件の話を聞くと8割ぐらいは、そういう位置付けでJavaを見てるよね。
まだ2割ぐらいはJavaで新規にって言ってるから、同じレベルではないのかもしれんけど。
Re: (スコア:0)
残り8割は何で開発してるの？
ああこれわひどい (スコア:2)
『開発言語COBOLの短所はなにか』の答えとして、不適切杉。
Re: (スコア:0)
で、素人の質問なのですけど、最新式のCOBOLは実用性が無いの？
最早新規開発に耐えない言語なの？
Re:ああこれわひどい (スコア:2, 参考になる)
しらんがな。
(´･ω･｀)
Re:ああこれわひどい (スコア:1)
質問に質問で答えることになるんだけど、
そこまでして新規開発に最新式COBOLを使うメリットってなんだろう？
最新式ってSQL対応とかJavaのクラスライブラリを使えるとか、便利になった面はあるけど
だったら最初からJavaでいいんでね？って思ってしまう
Re: (スコア:0)
いかに新しいCOBOLがまともになったところで古いコードが魔法のように更新されるわけじゃないし。
いかにVB.NETが優れた言語でも(C#と比べてそこまで言うほどではないと思うが)VB6の保守案件で役に立たないのと同じ
COBOLではなく古いシステムが (スコア:1)
COBOLそのものではなく、
COBOLで動かし続けリプレースもされない古くてカビの生えたシステムが諸悪の根源なのでは？
色々な事情はあるだろうけれど、ある程度の期間で更新し続けないと保守しづらくなるのは自明の理ではないかと。
COBOLが古くて使いづらい云々は、正直なところ必要な言語なり手続きを覚えずに
「あっちはこれがあるのにこっちには無いから・・・」
と文句垂れるだけの使いづらいエンジニアなのだと思ってしまう。
# 必要ならなんでも覚えてやるさ。相応の対価を出してもらえるなら
Re:COBOLではなく古いシステムが (スコア:2, すばらしい洞察)
要は「COBOLの仕様上の問題で、構造化すらされておらず、ソースコードから仕様を紐解くのが非常に難しい」
というのと、「そもそも仕様書が更新されていないか、あったとしても未記載や言外の仕様が多くて役に立たない」
という2つの合わせ技だと思いますよ。
言語側で業務に合った抽象度の高いコードにしている(=そこから仕様書を起こせる)か、
仕様書がきちんと作成され更新され続けていれば、
言語を移動することもメンテナンスすることも容易だからです。
Re:COBOLではなく古いシステムが (スコア:1)
元々構築されているシステムって本質的に複雑な仕組みだったりするんで、そのままでは仮にモダンな環境や言語でも関係なく難しいもののような気もする。
神経症のようにミスに厳格だし、丁寧な対応が当たり前で、コスト削減が当たり前な世の中であると、仕組みの刷新って難しいかもね。
Re: (スコア:0)
今では初期のハードで動いているのなんて無くて、VMの上で動いているのでは?
基本事務処理だからI/OはCSVみたいな会計データだけだろうし。
ソフト的なつぎはぎでメンテが大変とかいじれないとかはあるだろうけど。
Re: (スコア:0)
どちらかというと通信ミドルウエアに相当するCICSなんかはAPIはCOBOLのバインディングだな
Re: (スコア:0)
リプレースできずに残ってるCOBOLのシステムだと改修数千万～数十億単位かな。
現実の話 (スコア:1)
人間の気力体力には限界があって、
昔は百科事典並みのドキュメントと、印刷すれば電話帳サイズになるプログラムの精査やって
胃潰瘍になって仕事場に救急車が駆けつける修羅場を永遠に続けるわけには行かないの。
本質的にアルゴリズムは変わらないとしても、パラメタライズとジェネリクスとラムダは必要。
Ruby使えばExcelでは難儀な大量の集計作業もラクチンポン
方言がひどい (スコア:1)
やったことある人なら分かるだろうけど
COBOLって方言がひどいんだ。
COBOLが動いてるのってだいたい大型汎用機なんだけど、
メーカーや機器ごとに方言があったり、
違うメーカーで使えた関数が他で使えなかったりで
言語自体の知識の他にターゲットになる特定ハードウェアの癖まで知ってる必要がある。
昔のシステムのメンテに必要とされるCOBOLerって、そういう人なんだよね。
COBOL自体は、言語としては簡単だから覚えるのは難しくない。
ただ、ハードウェアとメーカーの癖を知ってないと使い物にならない。
逆に、そんな特定メーカーべったりの技術者になってしまうと他で使えないから敬遠される。
そういった古い言語によくある問題が、昨今の新しい言語とは違う事情なんだ。
ある程度グチャになるのは覚悟のうえで (スコア:0)
モダンな言語にトランスレートしてフィットさせるようなことは
出来たら苦労しないよねぇ。。。
同様に古いFORTRANはあまり悪口聞かない。
あるいはRATFORみたいなRATCOBOLとかできないものか
COBOLerがCOBOLで一生を終えない (スコア:0)
自分の研究だけに没頭していればいい仕事ならともかく、今どきのプログラマーが言語1個で定年まで食いつないで行くこと自体ありえない
会社を渡り歩けば、歩いた分だけ言語を書いている位が普通だと思うがなぁ
もしCOBOLを身に付けたら人生ゴールする会社があるなら、こっちが入りたいわ
Re:COBOLerがCOBOLで一生を終えない (スコア:1)
「もうゴールしてもいいよね」的な意味で?
Re: (スコア:0)
MathematicaとかMatlab なら単一言語でやっていけるはず
Re: (スコア:0)
どちらも高いのでフリーランスになったら余裕で死ねるでしょう
ちなMathematicaで巨大なデータ処理をするとそれだけで死ねます
Re: (スコア:0)
そんなに高くないような？
MATLABで高めToolboxをある程度盛っても、維持費は数十万の前半。
フリーランスなら初心者お断りの適切な参入障壁になるぐらいで、経費としては問題ない程度でしょう。
Re: (スコア:0)
MathematicaやMatlabを使う仕事でフリーランサーとしてやっていけるほどの腕前があるなら、今はでーたさいえんすとかえーあいとかがアツいので相当ボッタクれるでしょ。
ライセンスフィーくらい軽く払えるはず。
Re: (スコア:0)
それは、言語ができるのでは無くMathematicaを使った"何か"をできるだけのスキルがあるって事だと思われ
COBOLは"誰でも使える"言語として生まれて、業務の流れを書きおろせるだけでモノになったのがここまで生き残った理由のはず。
だから、COBOLを使えるということと、Mathematicaを使えるということは別次元な話。
Re:COBOLerがCOBOLで一生を終えない (スコア:3)
その昔、安田先生のマイコンピューター3部作でCobolは英文科でも書ける云々。
家族さえ居なきゃゲンコツくれて辞めてやる。ってのを思い出しました。
同級生が県職の農地系に入って研修でFortranとCobolのテキスト持ってました。
で、貸せとFortranだけ。Cobolはどうも足し算するの大変で…
私の叔父が国鉄(当時)の事務系。Cobolを覚えたと言ってました。
へー凄いねと社交辞令。興味が無かったんで…
二人とも素人というか特別な教育を受けてないんですが何故か縁があったみたいです。
時はIBM PCが出るちょっと前です。計算機が高価な時代でしたね。
意外と根は深いような気がします。
Re:COBOLerがCOBOLで一生を終えない (スコア:1)
Windows以降でいえばExcelマクロ(VBA)かな。
Re: (スコア:0)
>COBOLは"誰でも使える"言語として生まれて
じゃあ、エンジニアの確保が難しい、なんてのは幻想だね!
Re: (スコア:0)
割とCOBOLERはそう言う。
Re: (スコア:0)
COBOLerは変な癖が付きすぎてて、何も知らないほうがまだ他の言語を覚えるのが早いくらい
この2つが両立してしまうのが闇だな (スコア:0)
＞エンジニアの確保が難しい
＞スキルの市場価値が低い
確保が難しいスキルなら市場価値は上がってしかるべきなのにね。
払うカネはないがレアスキルが欲しい企業ばかりって何なんだろうね。