アカウント名:
パスワード:
>COBOLで組まれたシステムの大半をJavaやオープンプラットフォームへ切り替えるJavaかぁ、Java…… うーん、Javaなぁ…… なんでJavaなんだろうなぁ……
あと、ITProのコメント欄がすごい。>なぜにCOBOLからJAVAに替えれば、IT投資が減るのか意味わかりません。COBOL書けない人は見た事ないけどJAVAを書けない人は多数います。JAVAのが俗人化すると思いますが。。共通オブジェクトの設計こそ、高度なプログラマーでなければ無理ですが。。
俗人化の反対を考えると、聖人化か、仙人化か、尊師化でしょう。髪型から尊師を考えるとRichard M. Stallman [google.co.jp]ですよね。
聖イグヌチウス調べました。なるほどrmsは聖人でしたね。勉強不足でした、すみません。
"仙人か"? "専任化"のtypoですか?
属人化のtypo俗人化を皮肉っているだけですよ。Javaが俗人ならCobolはなんだ？って。
COBOL以外を触らないで三十歳になったとき、人は仙術が使えるようになるのです。
# 四十にして惑はず、五十にして天命を知る。以下略
属人化が俗人化してるのは置いといて、自分の周りじゃJava書けない人は見たこと無いけど、COBOL書ける人は皆無だな。このコメント書いた人の職場ってどこなんだろう。大手ベンダーの大型ホスト担当の部署で、他の部署を見たことも無いような人かな？
もう二十年近く前、この業界入りたての頃にCOBOL書かされたけどベンダーやバージョン別の方言？みたいなのが酷くて面倒くさかった。統一規格みたいのがあるということになってるのに、何だったんだあれは。あれに比べりゃJavaのほうが圧倒的にマシだろう。
今のJavaの価値の99%はJVMの価値、こと並列処理において、こなれたJITコンパイラと、規格化されたメモリ一貫性モデル、高速なコンカレントGCを備えたJVMに勝るものはない。現在において、シングルスレッドで間に合わないプログラムは、JVM上で実行するのが最善であり、JVMを使用しない場合、生産性、保守性共に多大なディスアドバンテージを負うのである。
Javaにしたら年間保守費が倍になったりしてｗ
ガベコレがある言語なんて採用して大丈夫なんだろうか。処理時間保証とかできるのだろうか？
運用が始まってから、リソースリークで目も当てられないことになるのか。
銀行のオンラインシステムならともかく保険会社のシステムなら応答速度のシビアさはそんなに求められないのでは。
まぁ、今ではCOBOLほとんど使われないので、COBOLかけない人もいっぱいいると思う。
＞共通オブジェクトの設計こそ、高度なプログラマーでなければ無理ですが。。そう思う。
後、JAVAはコロコロバージョンあげてしかも平気で過去のAPIを切り捨てるので、今作り直していつまでそのまま動くやらね。。。。
> 後、JAVAはコロコロバージョンあげてしかも平気で過去のAPIを切り捨てるのでそれは発展途上の言語ならばどれも同じじゃない？PHPであってもそれは同じ。
発展途上ならねぇ…
きちんと設計された言語なら、後方互換性は保証されているでしょ。ロードマップもひかず場当たり的な変更をしてるから、そうなるんですよ。
＞後、JAVAはコロコロバージョンあげてしかも平気で過去のAPIを切り捨てるので、ウソばっか。
たぶん使ったことの無い人のご意見だね。やっぱCOBOLerのFUDかな？むしろJavaは過去との互換性が高くて、APIをなかなか切り捨てないことで有名なんだが。違うというなら、まずはその切り捨てた過去のAPIとやらを具体的に挙げてからにしなさい。一つもあげられないに１００ペリカ。
＞ガベコレがある言語なんて採用して大丈夫なんだろうか。＞処理時間保証とかできるのだろうか？こっちも同様。FUDお疲れ。
キャッシ
http://www.oracle.com/technetwork/jp/java/javase/overview/8-compatibil... [oracle.com]
> Thread.stopメソッドは、リリース1.2以降廃止されています
1.2って何年前だよむしろ下位互換性を重要視している実証なんじゃないの、これｗ
〉むしろ下位互換性を重要視している実証なんじゃないの、これｗその通りでも、彼は「一つもあげられない」に賭ちゃったからしょうがないね
> むしろJavaは過去との互換性が高くて、APIをなかなか切り捨てないことで有名なんだが。
deprecated なメソッドがいつまでも残ってたり、1.5 で generics 導入したのに VM の互換性維持に傾注して、バイトコードでは型情報消えてるくらいなのにね。そでも互換が大事だったってのはすごくよく分かる。実際 Java の言語仕様は超安定してる。
(標準以外の)ライブラリやフレームワークの流行り廃りが激しいし、フルスクラッチはやだもんなので、そのレイヤで困ることは多いけど。
> (標準以外の)ライブラリやフレームワークの流行り廃りが激しいし、> フルスクラッチはやだもんなので、そのレイヤで困ることは多いけど。
たぶん、org.foo.hoge.* を使ってたら、いつの間にかJSRに入ってて、APIが変わって、javax.huga.* になったが、org.foo の更新が止まって、新しい Java に対応しなくなって、古いプログラムが動かなくなった人だよ。（非標準の機能が標準に入って仕様が変わった）
昔のJavaあるあるだよ。でもこれは、Java言語自体の後方互換性の問題じゃないからな。
そういうの今でもあるけどそれはJCPが悪い。仕様もRIも更新止まってるのにBD-Jの実装の一部としてだけは残ってるJMFとか
引用訂正：ITProのコメントは
なぜにCOBOLからJAVAに替えれば、IT投資が減るのか意味わかりません。COBOL書けない人は見た事ないけどJAVAを書けない人は多数います。JAVAのが俗人化すると思いますが。。共通オブジェクトの設計こそ、高度なプログラマーでなければ無理ですが。。
までです。
> COBOL書けない人は見た事ないけどEXCEL使えないって人は見た事ないけどって話に聞こえる。
うちの周りは、JAVA書けない人は見た事ないけど、COBOLかけない人は多数います・・・
＃なんか、日本人が「日本語書けない人は見たことないけど、英語をかけない人は多数います。」、＃アメリカ人が「英語書けない人は見たことないけど、日本語をかけない人は多数います。」って言ってるのと同じ気がしてきた
うちの職場の隣りの島が丁度、このストーリーのようにCOBOLをJavaに置き換えるプロジェクトを進めているのですがJavaが判らないという声が多数です。
これCOBOL書いてる人の発言だろうな
＞COBOL書けない人は見た事ないけどJAVAを書けない人は多数います。こんな人見たこと無いわ。逆に、Java書ける人ならいっぱい知ってるけど、COBOL書ける人見たこと無いわ。
＞JAVAのが俗人化俗人化なんて今時言う？今コード見てる中小会社のコードだと俗人化してて笑うけど、それなりの企業なら俗人化なんて今時あり得ないよ。
あれですかね。
知識0から教えた際に、COBOL書けないままの人は見た事ないけどJAVAを書けないままの人は多数います。要求する知識量が多いのでJAVAのが属人化すると思いますが。。
ってことですかね。
勉強したのにJava書けないけどCOBOLは書けるというのは、頭を使わずにルールに従ってなにか書き写す作業をしているだけの人だから、別にいなくていい。
「オブジェクト指向が理解できるかどうか」なんじゃない？Cのポインタと双璧をなす、篩だと思う。
そうするとやはりCOBOLが優れた言語であることは否めない事実
ストーリー by hylom なのだから推して知るべし
先に言っとく。(#2900985) の人気に嫉妬
> なのに言葉をそのまんまに捉えて「COBLOerなんてそんなにいないよ！」とか
いや、「COBOL書けない人は見た事ない」って人もいるってば。
> オープンプラットフォームへ切り替える
open cobol ってあったよなと、調べたら、2013年から gnu cobol に変わったって、書いてあった。
こういうのじゃ、性能的にダメなんかね？
食わず嫌いな気がする
Javaができる人なら、COBOLなんて教科書を一通り読めばすぐソースを読めるくらいの難度の言語でしょ逆は無理な場合もありますが。
GCが何とか言っている人もいるけど、COBOLからそのまま移植するならガベージアウトするような変数は使わないJavaなのにソースがCOBOLに見えてくるようなのでいいのならですけど
…という問題ではなく、多分COBOLソースから仕様書をひねり出すのが大仕事なのだと思う
>>GCが何とか言っている人もいるけど、COBOLからそのまま移植するならガベージアウトするような変数は使わない
Javaのプログラマでそこまで質のいいのを数揃えるのは不可能ですｗ ＃「そこまで質のいい」＝「その程度のことがなんとか理解できる」
文法的には仰る通り、COBOLは単純な言語だと思います。COBOL79準拠のソースを見たりすると正直かなり頭痛がする事間違いなし。＃サブルーチンの概念がないので、GOTOでそれっぽく処理するとか
>…という問題ではなく、多分COBOLソースから仕様書をひねり出すのが大仕事なのだと思うまさにこれだと思います。
> サブルーチンの概念がないので
平気でこういう嘘を書く
gnu cobolに変更することでコストが抑えられるのならやる意味があるんじゃないでしょうか。
性能よりも責任の所在が不明確なのがまずいのでは。
費用面が移行の主な理由でしょ。COBOLやれる奴なんていまどきほとんどいないから、高単価の高齢プログラマー抱えてるところと言い値で契約するしかないんじゃない?
ベンダーロックイン状態で酷い目に遭ってるから、そう言う状況を改善したいんじゃないかな。
最近の銀行系のトレンドはどのプログラミング言語なんでしょうか？
俺だたったらVisual Studio(C#)にしとくな。楽したいし。あとクライアントがWindowsだとすると、ユーザーが細かな操作性に注文付けて来るだろうから、Windowsの機能がフルに使えるようなツールも必要になるし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
Java死すべし (スコア:0)
>COBOLで組まれたシステムの大半をJavaやオープンプラットフォームへ切り替える
Javaかぁ、Java…… うーん、Javaなぁ…… なんでJavaなんだろうなぁ……
あと、ITProのコメント欄がすごい。
>なぜにCOBOLからJAVAに替えれば、IT投資が減るのか意味わかりません。COBOL書けない人は見た事ないけどJAVAを書けない人は多数います。JAVAのが俗人化すると思いますが。。
共通オブジェクトの設計こそ、高度なプログラマーでなければ無理ですが。。
Re:Java死すべし (スコア:2)
俗人化の反対は尊師化だろう (スコア:2)
俗人化の反対を考えると、聖人化か、仙人化か、尊師化でしょう。
髪型から尊師を考えるとRichard M. Stallman [google.co.jp]ですよね。
Re:俗人化の反対は尊師化だろう (スコア:2)
聖イグヌチウス調べました。なるほどrmsは聖人でしたね。勉強不足でした、すみません。
Re: (スコア:0)
"仙人か"? "専任化"のtypoですか?
Re: (スコア:0)
属人化のtypo俗人化を皮肉っているだけですよ。
Javaが俗人ならCobolはなんだ？って。
Re: (スコア:0)
COBOL以外を触らないで三十歳になったとき、人は仙術が使えるようになるのです。
# 四十にして惑はず、五十にして天命を知る。以下略
Re:Java死すべし (スコア:1)
属人化が俗人化してるのは置いといて、
自分の周りじゃJava書けない人は見たこと無いけど、COBOL書ける人は皆無だな。
このコメント書いた人の職場ってどこなんだろう。
大手ベンダーの大型ホスト担当の部署で、他の部署を見たことも無いような人かな？
もう二十年近く前、この業界入りたての頃にCOBOL書かされたけど
ベンダーやバージョン別の方言？みたいなのが酷くて面倒くさかった。
統一規格みたいのがあるということになってるのに、何だったんだあれは。
あれに比べりゃJavaのほうが圧倒的にマシだろう。
Re:Java死すべし (スコア:1)
今のJavaの価値の99%はJVMの価値、
こと並列処理において、こなれたJITコンパイラと、規格化されたメモリ一貫性モデル、高速なコンカレントGCを備えたJVMに勝るものはない。
現在において、シングルスレッドで間に合わないプログラムは、JVM上で実行するのが最善であり、
JVMを使用しない場合、生産性、保守性共に多大なディスアドバンテージを負うのである。
Re: (スコア:0)
Javaにしたら年間保守費が倍になったりしてｗ
ガベコレがある言語なんて採用して大丈夫なんだろうか。
処理時間保証とかできるのだろうか？
Re: (スコア:0)
運用が始まってから、リソースリークで目も当てられないことになるのか。
Re: (スコア:0)
銀行のオンラインシステムならともかく保険会社のシステムなら応答速度のシビアさはそんなに求められないのでは。
Re:Java死すべし (スコア:2)
Re: (スコア:0)
まぁ、今ではCOBOLほとんど使われないので、COBOLかけない人もいっぱいいると思う。
＞共通オブジェクトの設計こそ、高度なプログラマーでなければ無理ですが。。
そう思う。
後、JAVAはコロコロバージョンあげてしかも平気で過去のAPIを切り捨てるので、
今作り直していつまでそのまま動くやらね。。。。
Re: (スコア:0)
> 後、JAVAはコロコロバージョンあげてしかも平気で過去のAPIを切り捨てるので
それは発展途上の言語ならばどれも同じじゃない？
PHPであってもそれは同じ。
Re:Java死すべし (スコア:1)
業務システムなら私も発展途上の言語でプログラム作るのは間違いだと思うな。
Re: (スコア:0)
発展途上ならねぇ…
Re: (スコア:0)
きちんと設計された言語なら、後方互換性は保証されているでしょ。
ロードマップもひかず場当たり的な変更をしてるから、そうなるんですよ。
FUD乙 (スコア:0, 興味深い)
＞後、JAVAはコロコロバージョンあげてしかも平気で過去のAPIを切り捨てるので、
ウソばっか。
たぶん使ったことの無い人のご意見だね。やっぱCOBOLerのFUDかな？
むしろJavaは過去との互換性が高くて、APIをなかなか切り捨てないことで有名なんだが。
違うというなら、まずはその切り捨てた過去のAPIとやらを具体的に挙げてからにしなさい。
一つもあげられないに１００ペリカ。
＞ガベコレがある言語なんて採用して大丈夫なんだろうか。
＞処理時間保証とかできるのだろうか？
こっちも同様。FUDお疲れ。
キャッシ
100ペリカ払ってね (スコア:1)
http://www.oracle.com/technetwork/jp/java/javase/overview/8-compatibil... [oracle.com]
Re:100ペリカ払ってね (スコア:1)
> Thread.stopメソッドは、リリース1.2以降廃止されています
1.2って何年前だよ
むしろ下位互換性を重要視している実証なんじゃないの、これｗ
Re: (スコア:0)
〉むしろ下位互換性を重要視している実証なんじゃないの、これｗ
その通り
でも、彼は「一つもあげられない」に賭ちゃったからしょうがないね
Re: (スコア:0)
> むしろJavaは過去との互換性が高くて、APIをなかなか切り捨てないことで有名なんだが。
deprecated なメソッドがいつまでも残ってたり、
1.5 で generics 導入したのに VM の互換性維持に傾注して、バイトコードでは型情報消えてるくらいなのにね。
そでも互換が大事だったってのはすごくよく分かる。実際 Java の言語仕様は超安定してる。
(標準以外の)ライブラリやフレームワークの流行り廃りが激しいし、
フルスクラッチはやだもんなので、そのレイヤで困ることは多いけど。
Re:FUD乙 (スコア:1)
> (標準以外の)ライブラリやフレームワークの流行り廃りが激しいし、
> フルスクラッチはやだもんなので、そのレイヤで困ることは多いけど。
たぶん、org.foo.hoge.* を使ってたら、いつの間にかJSRに入ってて、APIが変わって、javax.huga.* になったが、org.foo の更新が止まって、新しい Java に対応しなくなって、古いプログラムが動かなくなった人だよ。（非標準の機能が標準に入って仕様が変わった）
昔のJavaあるあるだよ。
でもこれは、Java言語自体の後方互換性の問題じゃないからな。
Re: (スコア:0)
そういうの今でもあるけどそれはJCPが悪い。
仕様もRIも更新止まってるのにBD-Jの実装の一部としてだけは残ってるJMFとか
Re: (スコア:0)
引用訂正：ITProのコメントは
なぜにCOBOLからJAVAに替えれば、IT投資が減るのか意味わかりません。COBOL書けない人は見た事ないけどJAVAを書けない人は多数います。JAVAのが俗人化すると思いますが。。
共通オブジェクトの設計こそ、高度なプログラマーでなければ無理ですが。。
までです。
Re:Java死すべし (スコア:2)
> COBOL書けない人は見た事ないけど
EXCEL使えないって人は見た事ないけど
って話に聞こえる。
Re:Java死すべし (スコア:1)
うちの周りは、JAVA書けない人は見た事ないけど、COBOLかけない人は多数います・・・
＃なんか、日本人が「日本語書けない人は見たことないけど、英語をかけない人は多数います。」、
＃アメリカ人が「英語書けない人は見たことないけど、日本語をかけない人は多数います。」って言ってるのと同じ気がしてきた
Re: (スコア:0)
うちの職場の隣りの島が丁度、このストーリーのように
COBOLをJavaに置き換えるプロジェクトを進めているのですが
Javaが判らないという声が多数です。
Re: (スコア:0)
これCOBOL書いてる人の発言だろうな
＞COBOL書けない人は見た事ないけどJAVAを書けない人は多数います。
こんな人見たこと無いわ。
逆に、Java書ける人ならいっぱい知ってるけど、COBOL書ける人見たこと無いわ。
＞JAVAのが俗人化
俗人化なんて今時言う？
今コード見てる中小会社のコードだと俗人化してて笑うけど、
それなりの企業なら俗人化なんて今時あり得ないよ。
Re:Java死すべし (スコア:2)
自分みたく，Androidアプリのプログラミング止まりでも
Javaが使える，には違いないわけだし。
金融システム経験のあるプログラマでJavaが使えるのがいない，ってえのも，いるだろ？普通？みたいな。
フロントエンド作ってるやつらは使えるだろ？
一から作るんだから，ちゃんと金融システムを策定できるシステムエンジニアの存在こそが必要なんであって，
言語がどうの，ってのは，それこそシステムにしたときのパフォーマンスとかそういう部分の話になるだけで，
プログラマーなんざどうとでも集められるというか。
Re: (スコア:0)
Re: (スコア:0, すばらしい洞察)
Re: (スコア:0)
あれですかね。
知識0から教えた際に、COBOL書けないままの人は見た事ないけどJAVAを書けないままの人は多数います。要求する知識量が多いのでJAVAのが属人化すると思いますが。。
ってことですかね。
Re:Java死すべし (スコア:1)
勉強したのにJava書けないけどCOBOLは書けるというのは、頭を使わずにルールに従ってなにか書き写す作業をしているだけの人だから、別にいなくていい。
Re: (スコア:0)
「オブジェクト指向が理解できるかどうか」なんじゃない？
Cのポインタと双璧をなす、篩だと思う。
Re: (スコア:0)
そうするとやはりCOBOLが優れた言語であることは否めない事実
Re: (スコア:0)
ストーリー by hylom
なのだから推して知るべし
Re: (スコア:0)
先に言っとく。
(#2900985) の人気に嫉妬
Re: (スコア:0)
> なのに言葉をそのまんまに捉えて「COBLOerなんてそんなにいないよ！」とか
いや、「COBOL書けない人は見た事ない」って人もいるってば。
Re: (スコア:0)
> オープンプラットフォームへ切り替える
open cobol ってあったよなと、調べたら、
2013年から gnu cobol に変わったって、書いてあった。
こういうのじゃ、性能的にダメなんかね？
Re:Java死すべし (スコア:1)
食わず嫌いな気がする
Javaができる人なら、COBOLなんて教科書を一通り読めばすぐソースを読めるくらいの難度の言語でしょ
逆は無理な場合もありますが。
GCが何とか言っている人もいるけど、COBOLからそのまま移植するならガベージアウトするような変数は使わない
JavaなのにソースがCOBOLに見えてくるようなのでいいのならですけど
…という問題ではなく、多分COBOLソースから仕様書をひねり出すのが大仕事なのだと思う
Re: (スコア:0)
>>GCが何とか言っている人もいるけど、COBOLからそのまま移植するならガベージアウトするような変数は使わない
Javaのプログラマでそこまで質のいいのを数揃えるのは不可能ですｗ
＃「そこまで質のいい」＝「その程度のことがなんとか理解できる」
Re: (スコア:0)
文法的には仰る通り、COBOLは単純な言語だと思います。
COBOL79準拠のソースを見たりすると正直かなり頭痛がする事間違いなし。
＃サブルーチンの概念がないので、GOTOでそれっぽく処理するとか
>…という問題ではなく、多分COBOLソースから仕様書をひねり出すのが大仕事なのだと思う
まさにこれだと思います。
Re: (スコア:0)
> サブルーチンの概念がないので
平気でこういう嘘を書く
Re: (スコア:0)
gnu cobolに変更することでコストが抑えられるのならやる意味があるんじゃないでしょうか。
Re: (スコア:0)
性能よりも責任の所在が不明確なのがまずいのでは。
Re: (スコア:0)
費用面が移行の主な理由でしょ。COBOLやれる奴なんていまどきほとんどいないから、
高単価の高齢プログラマー抱えてるところと言い値で契約するしかないんじゃない?
ベンダーロックイン状態で酷い目に遭ってるから、そう言う状況を改善したいんじゃないかな。
Re: (スコア:0)
最近の銀行系のトレンドはどのプログラミング言語なんでしょうか？
Re: (スコア:0)
俺だたったらVisual Studio(C#)にしとくな。楽したいし。あとクライアントがWindowsだとすると、ユーザーが細かな操作性に注文付けて来るだろうから、Windowsの機能がフルに使えるようなツールも必要になるし。