アカウント名:
パスワード:
同一ソース内で整理するなら PERFORM でいいんじゃないの? テンプレート機能とかが欲しい、とかいう世界なら微妙ですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
COBOL の嫌なところ (スコア:0)
ここは似たような処理だから関数にしてまとめよう → 組み込み関数しか使えないので、内容がちょっと違うだけでもコピペ
ここはファクトリメソッドを使えばIF文を減らせる → 組み込み関数しか使えないので、内容がちょっと違うだけでも全部 IF 文
そりゃ、順次・分岐・繰り返しさえあれば全ての処理は書けるけど、そりゃねえよなっていう…。
Re:COBOL の嫌なところ (スコア:2, 興味深い)
文句言ってる気がするよ。
ここは似たような処理だから、
→違う部分だけ別段落で書いてPERFOMEで処理分岐しよう
ファクトリメソッドを使えば、
→複数の条件を持つ段落と、その段落で使うデータ領域定義を
ライブラリにしてCOPY(コピペじゃないよ)して利用しよう
くらいがCOBOL的発想。つかCOBOLよりCとかJavaとかの、ローカル
スコープのある言語の方が何も考えないコピペ開発者多い(私見)。
-- Tig3r on the hedge
Re: (スコア:0)
コピペ坊やはどんな言語使ったって一定数出てきてしまう「文化」だ、というのが最近の感想。
コピペ文化は空気感染するウィルスのような部分があるから、被害大きいのがいただけないけど。
(Haskellでコピペしまくるなよ・・・)
COBOLで限界を感じるのは、その再利用を適用できる範囲の狭さ。悪いけど、PERFOMEやCOPYじゃできる再利用性に限界があるな、と感じる。
そのあたり、やっぱり構造体概念やスコープ概念の存在って大きいよ。
もちろん、COBOLでもすばらしいプログラムを組む(組んだ)人はいる。
でも、それってプログラマの能力がすばらしいんであって、言語特性の優劣の問題ではないよね。
個人的には、そういった凄い人達のために「明示的で決まりきった、つまらない部分」をいかに言語仕様から無くすか、そのためにどのような言語構造が適しているか、なんてところをどう工夫していくかがプログラミング言語の永遠の課題だと思う。
そういう意味では、オブジェクト指向言語もまだまだだよね。
Re:COBOL の嫌なところ (スコア:1, すばらしい洞察)
誰が書いても同じになるようにってのを狙った言語仕様として、よく出来てると思うよ。
これ(レガシーなシステム)がみんなC言語だったりしたら、もっと怖いかも。
Re:COBOL の嫌なところ (スコア:1)
コンパイル後のコードが読みにくくなるから使うなって。
# そ~ゆ~先輩に鍛えられたのでS370の機械語(?)が読めたりします…
# これほど役に立たないスキルもないと思う。
notice : I ignore an anonymous contribution.
Re: (スコア:0)
COPYやINCLUDE使えよ
Re: (スコア:0)
COBOLでまともにシステム組んでるなら、パラメータ渡して結果を得る自前のサブルーチンを用意したり、使い回しの利くCOPYライブラリを用意するのは当たり前のことですね。
親コメントのいう関数って多分同一ソース内で整理する程度の話なんだろうけど、そんな使い回しの利かない部分はコピペで十分。
Re:COBOL の嫌なところ (スコア:1)
同一ソース内で整理するなら PERFORM でいいんじゃないの?
テンプレート機能とかが欲しい、とかいう世界なら微妙ですが。