アカウント名:
パスワード:
COBOLという言語自体には大きな問題が無いってのいいとして, 本当に問題なのは分からなければならないデータフォーマットが処理に依存して設計されているということ. この処理中心設計というやつがコンピュータの性能が低かった1980年代前半ぐらいまでははびこっていて, しかも大規模なシステムほどそれ以前からの歴史を持っているため重荷になっているんですよ. すなわちデータだけではデータの意味は分からず, プログラムを伴って初めてデータフォーマットやそこに格納されているデータの意味が明かになるというのがレガシーシステムの問題の本質です.
これ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
負の遺産ってねぇ、あーた (スコア:0)
価値があるのは(継承すべきは)データだけだよ。
つまりデータフォーマットさえ解れば大した問題じゃないってこと。
データフォーマットが解らないとしてもCOBOLのせいじゃないよね。
負の遺産って人間の不手際をCOBOLのせいにされているようで気の毒だな。
なんで毎度ネタになるんだか。
分かってないのはあーた (スコア:5, 興味深い)
COBOLという言語自体には大きな問題が無いってのいいとして, 本当に問題なのは分からなければならないデータフォーマットが処理に依存して設計されているということ. この処理中心設計というやつがコンピュータの性能が低かった1980年代前半ぐらいまでははびこっていて, しかも大規模なシステムほどそれ以前からの歴史を持っているため重荷になっているんですよ. すなわちデータだけではデータの意味は分からず, プログラムを伴って初めてデータフォーマットやそこに格納されているデータの意味が明かになるというのがレガシーシステムの問題の本質です.
これ
レガシー？ (スコア:2, 興味深い)
Re: (スコア:0)
この仕事を受けた会社って、新卒のうち半分はCOBOLの研修を受けてCOBOLerに育てられるんですよね……。
腐っても上場企業だから、技術力は低くても安定してやっていける案件を好むのだろうか。
Re:レガシー？ (スコア:1)
すくなくとも、メンテナンスはNetCOBOLの方が楽になるし、ＯＳの変更に対しても自由度が高い。
# ＶＢで、低スキルのＰＧと組まされた時は、マジで死ぬかと思った
notice : I ignore an anonymous contribution.
Re: (スコア:0)
Re:レガシー？ (スコア:1)
これが利点でもあり、欠点でもある。
機能をいくらでも追加でき、呼び出しが簡単＝サードパーティの部品が豊富 → 構築工数・メンテ工数を少なくできる。
欠点は、ＯＳを変更しようとすると非常に面倒な事になる点。
多数の部品やランタイムを抱えるため、動作検証が大仕事になります。
NT -> W2k -> XP -> vista とＯＳが替わる度、サードパーティの部品の動作検証を行う羽目に……
（で、使えないコンポーネントの代替を捜してバタバタしました。RS-232C周りは、ほぼ毎回引っかかってましたね）
これがNetCOBOLなら、富士通が全部面倒見てくれますから、開発者と保守担当者は楽です。
# 他社からもwindowsやunix上で動作するCOBOLが販売されていますが、概要は、ほぼ同じです。
# 汎用機メーカが、既存顧客に用意した製品なので、サポートが薄いわけがない。
notice : I ignore an anonymous contribution.
Re: (スコア:0)
この辺はRubyなんかも同じですね。
というか、多分みんな考えることは同じなんだろうな。
>変な制約があったり、インスタンスを自由につくれなかったり
>VB.NET
言語的に強く冒険してるのはC#のほうでしょうね。
Rubyっぽいアイデアとか、関数(宣言)言語っぽいアイデアとか、
色々投入されてる。
ただ、既にRubyや関数言語を知っていたら、
「今更かよ」という感想しか抱きませんが。
そういう点も含めて
MSはやっぱり商売なんだなと思います。
真に新しいかどうかじゃなく、
マスから見て新しいかどうかで切り込んでくる。
上記のようなアイデアは、5年前の大衆には夢物語と笑われて終わりだったろうからね。
＃ C#(2.0以降)のyield returnには結構びびったのでAC