アカウント名:
パスワード:
友人にPL/Iプログラマが居ます。(まだ20代なのに…)過去の資産があるのと、それを動かす処理系が現役なのも、原因なのかなと思いました。特にメインフレームなどは過去の資産(負の遺産とも…)がバカにならないため古いシステムをオープン系に移行し損ねる → それを動かすメインフレームに需要が出て処理系が存続 → メインフレーム上の資産がまた増えるというようなループがあり、なかなか言語・処理系共に滅びないと。
んー、PL/Iのどこが具体的にだめなんか。例外なんかの非同期処理が文法規則としてちゃんと決められているし独自のデータ構造(構造体)を定義することもできるよね。
COBOLやFORTRANよりよほどスジがいいとおもうけどな。PL/Iは原子力関係で人気があると聞いたことがある。今はどうかしらんけど。宇宙関係もAda作ろうとしてぽしゃったので結局PL/I書いてるんとちがうんか。
非同期処理なんかは原理自体は潰しがきくし、JavaScript書き捨てるよりよほどいいと思うんだが。
おそらくメインフレームの処理系使っていること自体を「滅びるはずのものを使っている」と理解しているのでしょう。PL/Iはそこで動いているから滅びるべき負の遺産だと。オープン系に移行が流行った時、メインフレームのどこが問題だったのかを理解せず流行してたから受け入れ過去の物は100%だめとする人に居そうな感じです。
メインフレームが負の遺産なんて一言もかいてないじゃない。メインフレームにある過去の資産が負の遺産(の場合もある)ていう意味だろ?たぶん。
地球に優しくないことは確かだろう。ワットパフォーマンスという意味で。
ワットパフォーマンスの点でいうと、PCよりもよほどいいが?
確かに電力消費的には悪いでしょうけど、本来の処理系の信頼性や可用性はオープン系より全然よろしいかと。
オープン系は小回り利くのが良かったけど、リソースの有難味が全然無くなってきた昨今では、メモリ馬鹿食い、余計なサービス立って割り込み遅れとか、更にはネットワークリソースまでめんどくさい事になってて、何かにつけてウンザリしてしまうことが多くなった。
いろいろな意味での拡張性かな?パフォーマンスを向上させるには、機器を高性能なものにリプレースするより低性能の機器を複数台運用した方が簡単で安価であるとgoogleが証明しました。そうすると、プログラム言語も分散処理やスケーラビリティを考えたものにした方が良くなります。結果として機器の需要もプログラマの需要も減少方向にあり、現在使用しているプログラムも確保しているプログラマもつぶしがきかないものになっています。
メインフレームを負の遺産としないためには今後もメインフレームを使い続ける必要がありますが、機器およびプログラマの需要減によるコストと確保労力の増大は避けられません。
Googleが手掛けている業務については分散型の方が有利であるということが証明されただけ。金融機関やエアラインの基幹システムのような業務ではいまだに分散型に移行する兆しはないでしょ。
>金融機関やエアラインの基幹システムのような業務ではいまだに分散型に移行する兆しはないでしょ。
分散型に移行する兆しはないけど、ホスト離れは(業界の速度なりに)進んでますよ。今や、金融機関の基幹系システムも Linux サーバ上で Java で書かれはじめたりしてる時代です。まあ、それが IBM の z サーバで動いてたりもしますけど、まあ、昔ながらのホスト-COBOLシステムではない。
この方はなんで分散化していないと思い込んだのだろう。
では基幹業務で分散化が一般化してきている実例をどうぞ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
処理系が滅びぬ限り (スコア:4, 興味深い)
友人にPL/Iプログラマが居ます。(まだ20代なのに…)
過去の資産があるのと、それを動かす処理系が現役なのも、原因なのかなと思いました。
特にメインフレームなどは過去の資産(負の遺産とも…)がバカにならないため
古いシステムをオープン系に移行し損ねる → それを動かすメインフレームに需要が出て処理系が存続 → メインフレーム上の資産がまた増える
というようなループがあり、なかなか言語・処理系共に滅びないと。
Re: (スコア:0)
んー、PL/Iのどこが具体的にだめなんか。
例外なんかの非同期処理が文法規則としてちゃんと決められているし
独自のデータ構造(構造体)を定義することもできるよね。
COBOLやFORTRANよりよほどスジがいいとおもうけどな。
PL/Iは原子力関係で人気があると聞いたことがある。今はどうかしらんけど。
宇宙関係もAda作ろうとしてぽしゃったので結局PL/I書いてるんとちがうんか。
非同期処理なんかは原理自体は潰しがきくし、JavaScript書き捨てるよりよほどいいと思うんだが。
Re: (スコア:0)
おそらくメインフレームの処理系使っていること自体を「滅びるはずのものを使っている」と
理解しているのでしょう。PL/Iはそこで動いているから滅びるべき負の遺産だと。
オープン系に移行が流行った時、メインフレームのどこが問題だったのかを理解せず
流行してたから受け入れ過去の物は100%だめとする人に居そうな感じです。
Re: (スコア:0)
メインフレームが負の遺産なんて一言もかいてないじゃない。
メインフレームにある過去の資産が負の遺産(の場合もある)ていう意味だろ?
たぶん。
Re: (スコア:0)
地球に優しくないことは確かだろう。
ワットパフォーマンスという意味で。
Re: (スコア:0)
ワットパフォーマンスの点でいうと、PCよりもよほどいいが?
Re: (スコア:0)
確かに電力消費的には悪いでしょうけど、
本来の処理系の信頼性や可用性はオープン系より全然よろしいかと。
オープン系は小回り利くのが良かったけど、
リソースの有難味が全然無くなってきた昨今では、
メモリ馬鹿食い、余計なサービス立って割り込み遅れとか、
更にはネットワークリソースまでめんどくさい事になってて、
何かにつけてウンザリしてしまうことが多くなった。
Re: (スコア:0)
いろいろな意味での拡張性かな?
パフォーマンスを向上させるには、機器を高性能なものにリプレースするより低性能の機器を複数台運用した方が簡単で安価であるとgoogleが証明しました。
そうすると、プログラム言語も分散処理やスケーラビリティを考えたものにした方が良くなります。
結果として機器の需要もプログラマの需要も減少方向にあり、現在使用しているプログラムも確保しているプログラマもつぶしがきかないものになっています。
メインフレームを負の遺産としないためには今後もメインフレームを使い続ける必要がありますが、
機器およびプログラマの需要減によるコストと確保労力の増大は避けられません。
Re: (スコア:0)
Googleが手掛けている業務については分散型の方が有利であるということが証明されただけ。金融機関やエアラインの基幹システムのような業務ではいまだに分散型に移行する兆しはないでしょ。
Re:処理系が滅びぬ限り (スコア:1)
>金融機関やエアラインの基幹システムのような業務ではいまだに分散型に移行する兆しはないでしょ。
分散型に移行する兆しはないけど、ホスト離れは(業界の速度なりに)進んでますよ。
今や、金融機関の基幹系システムも Linux サーバ上で Java で書かれはじめたりしてる時代です。
まあ、それが IBM の z サーバで動いてたりもしますけど、まあ、昔ながらのホスト-COBOLシステムではない。
Re: (スコア:0)
この方はなんで分散化していないと思い込んだのだろう。
Re: (スコア:0)
では基幹業務で分散化が一般化してきている実例をどうぞ