- 1 ：デフォルトの名無しさん：2006/09/13(水) 22:37:48
- 前スレです。
ttp://pc8.2ch.net/test/read.cgi/tech/1068819212/ - 3 ：デフォルトの名無しさん：2006/09/16(土) 21:16:42
- このスレはjavaを冒涜してるのか
それともCOBOLを高く評価してるのか - 5 ：デフォルトの名無しさん：2006/09/18(月) 04:22:12
- >>3
未来なきJavaなど冒涜する気にもならない。 - 152 ：デフォルトの名無しさん：2008/07/25(金) 22:42:55
- 純粋にCOBOL、JAVAを比較して（レガシーアプリなし、新規構築という条件）
COBOLが優れている点ってないのかな。実行速度が速いとか。
今のとこ"vs"って内容になってない気がする。 - 154 ：デフォルトの名無しさん：2008/07/26(土) 10:47:49
- >>152
俺が昔やってたCOBOLの業後バッチ処理だと、
DBの内容を全て固定長のシーケンシャルファイルに吐き出して、
入出力すべてシーケンシャルファイルのバッチプログラムを
数十段も連ねて、一番最後にDBにロードして、、、ということやっていた。
今ではJavaで、殆どSQLでDBをいじっちゃうけど、
処理速度で悩まされることが多い。
SQLをチューニングして何とかなる場合は、それでいいんだが、
DBMSの諸々の設定（あるいはバグ）の問題が絡んでくると厄介。
昔は良かったなぁ、と思うことがよくある。
別にJavaだって、シーケンシャルファイル多段処理方式を
作れば出来るだろうが、やっぱり実行速度が遅いし、
固定長レコードのシーケンシャルファイルを扱うプログラムは、
圧倒的にCOBOLが作りやすい。 - 158 ：デフォルトの名無しさん：2008/07/27(日) 19:13:59
- >例えばテーブルの設計で言うと、俺が今保守しているJava+SQLのシステムは、
>正規化をやり過ぎて、何をするにしても、
>テーブルを10個ぐらい join しないとまともな仕事ができない。
>それで平気でjoin しまくった複雑なSQLが、処理速度を落としている。
>主観的には、昔のCOBOLの多段バッチAPなら
>5本を組み合わせて行うボリュームの処理を、
>たった１つのSQL、１つのAPで行おうとしている感じ。
漏れ、ABAA??ABB9みたいなテーブル数１０個以上で正規化もクソもない多段バッチ
のCOBOLのプログラム見たことあるけど。
こういう糞設計もCOBOLerが独壇場に感じる。
それにテーブル10個JOINしないと、の件もフカシが入っていると思うが。
本気だとしたら、それこそコボラーかAccessヲタが設計したんだろう。
ちなみに昔の人でもいい設計する人はいる。だからCOBOLと言う言語自体は全否定はしないが
実際に許せるレベルの設計できる人は万分の一程度だろうなぁ。
＞Java+SQL（簡単） + Java+SQL（簡単） + Java+SQL（簡単）
悪いんだが、処理速度の改善策としてこんな悪手を選択するエンジニアが
「COBOLの方式もよい」なんて発言するって事はRDBMSの基礎も
解っていない素人にしか思えん。 - 196 ：デフォルトの名無しさん：2008/08/29(金) 00:36:17
- 例えば、
在庫テーブル （品目コード、数量） と
品目情報テーブル （品目コード、名称、単価）
があって、在庫の一覧表（品目コード、名称、在庫額）を作りたい場合、
品目コードをキーに２つのテーブルを結合することを考えないか普通は？ - 197 ：デフォルトの名無しさん：2008/08/29(金) 09:52:57
- そうか。なるほど。
その例の場合、
在庫テーブルと、品目情報テーブルを読み込んで、
在庫の一覧表テーブルを、新しく作れば良くない？？
結合とか、余計な機能使ったら、遅くならないの？？
っていうか、在庫の一覧表テーブルを、新しく作っても遅いじゃん。
最初から、在庫の一覧表テーブルは用意しておいて、
在庫額だけ、数量ｘ単価を（プログラムで）計算して、更新すれば良くない？？ - 212 ：デフォルトの名無しさん：2008/08/31(日) 10:15:54
- >>197
>結合とか、余計な機能使ったら、遅くならないの？？
>>196 の例ならば、たいして遅くならない。
select
Z.品目コード, H.名称, Z.数量 * H.単価
from
在庫テーブル Z left join 品目情報テーブル H
on
Z.品目コード = H.品目コード ;
在庫テーブルも品目情報テーブルも、品目コードがプライマリキーであることは明らかだから、結合キーが品目コードだけの上記SQLは十分速い。
>在庫テーブルと、品目情報テーブルを読み込んで、
>在庫の一覧表テーブルを、新しく作れば良くない？？
良くない。そんな事する方が圧倒的に遅い。
誤解しないで欲しいのだが、俺は別にSQL結合マンセーではない。場合によっては、>>197 の主張するとおり、中間的なテーブルを設けて処理する方法もアリだと思う。しかし、>>196 のような単純な例では、
中間テーブル方式 ＞＞＞＞ SQLで必要情報を結合して取得する方式
コストを比較すればこうなる。
もし、在庫一覧表出力機能あるいはそれに類する物を設計する機会があるなら、中間テーブル方式にせよ、SQL結合方式にせよ、状況（データ構造、更新頻度、etc）によって適切な方式を選択する必要がある。
しかし、>>197 はどうも、SQLの結合に対して妙な偏見があり、無条件に中間テーブル方式を採用してしまうような気がする。技術者として、その姿勢にはいささか問題があるよ。 - 216 ：デフォルトの名無しさん：2008/08/31(日) 11:14:07
- ああごめんなさい。作るじゃなくて引っ張るですよね。
＞結合で毎回作るより速いでしょう
俺もちゃんと読もう。
＞しかし、>>197 はどうも、SQLの結合に対して妙な偏見があり、
＞無条件に中間テーブル方式を採用してしまうような気がする。
＞技術者として、その姿勢にはいささか問題があるよ。
最初から結合した結果の項目を持ったＤＢ用意しとけばいいと思うんだけどなあ・・・。
そうだね。しょっちゅうは参照しないから、
いちいちＤＢは作りたくない場合なら、結合の方がいいよね。
でも、頻度が高いのなら、めんどくさいけど最初から作っておいた方がいいと思う。
速度が気になるというお話ですし・・・。頻度は高いのかと。 - 243 ：デフォルトの名無しさん：2008/09/02(火) 10:04:32
- >「既に開発、テストが済んでいる機能」
>と
>「新たに開発、テストを行う機能」
>どちらを採用するか、
>という問いに、
>皆は「開発済み」を選択し、
>君は「新規開発」を選択している。
>君は、
>期間を要する方、
>バグの危険性の高い方を選択している。
>不自然だろ。
どうしたら速くなるか？っていうお話だよ。
設計を見直すべきだというお話。
この例では、別に複雑ではないが、
継ぎ足し、継ぎ足ししていると、
そのうちに手が入らないシステムになってしまう。
まあ、その方がカネが取れるといえばそうだけど、
そういう技術者ばかりだからダメなんだよ。
設計に良くない部分があるのなら、
早めに見直すべきだ。
何度も言うが、プログラムや機能より、設計。
結合の方が技術者は確かにラクでバグは少ないけど、
面倒くさがってはいけないよ。
その程度でバグ出す心配してるようじゃダメだよ。 - 246 ：デフォルトの名無しさん：2008/09/03(水) 01:38:06
- >>243
>設計を見直すべきだというお話。
その設計とやらが、
SQLによる複数テーブルの結合によるレコード取得を否定し、
複数テーブルから個別にレコード取得する方式を指し、
外部キーによる整合性の維持を否定し、
プログラムからの整合性チェックを指すならば、
それを設計とは誰も呼ばない。
それはムダと呼ばれ排除する為に皆が努力を重ねている。
それに対し君は、
そのような努力を怠る自らを慰める言い訳を探すかの如く、
皆の考えを否定する。
君は間違っている。 - 275 ：デフォルトの名無しさん：2008/09/09(火) 20:50:38
- ジャーナル的に受注時点のマスタ情報をトランザクションで持ってなきゃいけないとか、
法定項目だけで100以上あったりとか、
テーブル正規化すると移行が難しくなるから非正規化しとくとか、
色々ある訳よ。
テーブルがそうだとCOBOLで書こうがCで書こうが同じなんだよね。
だからsql*plusのdescを標準入力から食って
出力ファイルのCOPY句通りのレイアウトで出力する
Cのソースを自動生成するツールとか作ったよ？ - 276 ：デフォルトの名無しさん：2008/09/09(火) 21:13:32
- >>275
>ジャーナル的に・・・
単価テーブル(顧客コード,商品コード,荷姿コード,契約時刻,契約単価)
のようなテーブルを各種持っているのではいけないのですか? - 316 ：デフォルトの名無しさん：2008/12/02(火) 21:45:44
- cobolの良い点->実行速度が速い？噂で聞いた
cobolの悪い点->
行番号邪魔。目障り。
A領域？B領域？好きなとこに書かせろ。
72文字まで？ifの入れ子どうすんだよ！
全部グローバル変数って・・・（苦笑）
"break"文ねーのかよ！
大文字でよみずれーよ！
hoge = 1; が MOVE 1 TO HOGE.ながったらしいわ！
if文に括弧（）使えなくて読みづらい - 392 ：デフォルトの名無しさん：2009/02/23(月) 16:43:08
- 結論として、みんなでIBMのAS/400を使えば良いと思うのだが。
COBOLもJavaもRPGも動くよ。たしかアセンブラが提供されて
いないと思ったが、それだけが残念。 - 441 ：デフォルトの名無しさん：2009/04/09(木) 21:14:58
- 20歳の新社会人ですがCOBOLを使う事になりました。
COBOLの経験は無いですが最後のコボラーになるのも悪く無いかなと思っています。 - 447 ：デフォルトの名無しさん：2009/04/12(日) 17:30:59
- >>441
メインフレーム(汎用機)か?
こういう本が出てるので、参考にするといいぞ。高いけど。
メインフレーム実践ハンドブック
ttp://www.ric.co.jp/book/contents/book_823.html - 458 ：デフォルトの名無しさん：2009/05/01(金) 03:41:09
- >>447
この本買ったんだけどさ、メインフレームマンセーな話ばっかで５分で飽きた
メモリ管理やらジョブ管理の仕組みの話されても意味ない
そんなもん今時組み込みＯＳだってやってるっての
問題は、ＯＳとかミドルウェアの上に乗っかるアプリから見て、
アプリが動く環境がどう見えるかだろうに、
そういうところはまるで書かれていない - 580 ：デフォルトの名無しさん：2009/06/23(火) 23:43:32
- >＞オブジェクト指向云々よりもな正規表現やらSQLのクエリをスラスラ書ける方が
>正規表現やSQLは必須ですね。
入力文字列の妥当性チェックを正規表現で実装したら
「他の担当者がメンテできないような物を使うな」って叱られた事があるな。
if文と文字列操作関数で実装するのが当然だとかで。 - 581 ：デフォルトの名無しさん：2009/06/23(火) 23:49:11
- 短期的に現場で役立たせるためには、OOPLより必要なものは多いね。
でも、そればっかりやらせてると、次代の人材が育たない。
あと、SQLは大事だと思うけど、SQLのテクニック的な部分だけやってもしょうがないと思う。
DB設計が出来る用にまでなって欲しい。これがきちんとできる人は、OOにも対応しやすいと思う。 - 582 ：デフォルトの名無しさん：2009/06/23(火) 23:50:48
- >>580
「正規表現を使えないような技術者なんて居ませんよ。」
しれっと、言ってやれ。
後のことは知らんが、そんな所にいつまでも居ないほうが良いだろ。 - 584 ：デフォルトの名無しさん：2009/06/24(水) 00:05:12
- >>580
>入力文字列の妥当性チェックを正規表現で実装したら
>「他の担当者がメンテできないような物を使うな」って叱られた事があるな。
>if文と文字列操作関数で実装するのが当然だとかで。
それをしたくないための正規表現なんですけど。そういうの聞くとちょっと寂しいですなｗ
>>581
>DB設計が出来る用にまでなって欲しい。これがきちんとできる人は、OOにも対応しやすいと思う。
これは難しいところですよね。DB設計って想像力ある人のほうが上手にできますよね - 585 ：デフォルトの名無しさん：2009/06/24(水) 00:48:56
- ・メソッド内で使う変数はすべてメソッドの先頭で宣言すること
・変数宣言と同時に代入は行わず、宣言部に続けて初期化部を設け、そこで行うこと（定数除く）
・変数には型を表す接頭辞をつける事
・例外エラーはすべてメソッド内で処理すること
・Mapはメモリを消費するので極力使わないこと
Javaの規約で結構お目にかかるんだけど、妙な習慣やら用語やら・・・
これが文化交流ってやつか - 587 ：デフォルトの名無しさん：2009/06/24(水) 03:37:32
- >>580 >>582 >>584
正規表現の問題点を本気で考えたこともないんだな。 - 641 ：デフォルトの名無しさん：2009/07/11(土) 08:59:56
- 不正な処理を継続するより、一度止めちゃった方が健全。
- 642 ：デフォルトの名無しさん：2009/07/11(土) 09:25:58
- >>641
最低限の終了処理はやるべきだろ
産業用ロボットとかだと、一部のサブシステムだけが勝手に停止すると、
人を殺したりしてしまうんだが - 666 ：デフォルトの名無しさん：2009/07/29(水) 21:02:46
- java開発 => C開発 => VB開発 => COBOL保守と渡り歩いて最近、昔のJCLなんか
触ってたりしてるけど、COBOLの方がまだいいな。スレッド無いし…
中間ファイルあるだけ不具合の発見し易かったりする。
Swing使うとイベントディスパッチスレッドルール違反で落ちまくって大変な目に遭う。
java Applet <=> java Servlet <=> C Service <=> JCL <=> COBOL <=> DB
という華麗なシステムのおかげで、言語としては、どちらも糞としか見えない。 orz
Java=マルチスレッド系とCOBOL=基幹系かな？
データベースを上手く作れば良いのだろうけど、
昔のオフコンスペックで安定稼動させる事ができるならCOBOLが上かと…
>>642
Java(CORBA)で作成された制御システムを保守したけど、10日で1回、
原因不明の動作不全で落ちているのがあったよ。怖いよね。
こいつもマルチスレッドでオブジェクト崩壊起こしてた。
スレッドダンプが拾えなくてしんどかった… - 891 ：デフォルトの名無しさん：2010/05/04(火) 12:15:34
- COBOLのマイグレーションってたいへんなの？
- 892 ：デフォルトの名無しさん：2010/05/05(水) 08:57:45
- >>891
COBOLというよりオブジェクト指向のみで構造化プログラムは全く未経験の人には相当つらいみたい・・・。
この前入社してきたJAVA/C++暦10年以上の人間にCOBOLで組んでもらったら完全にバンザイしていた。
彼曰く、「JavaやC++なら必要な機能はメソッドなり関数なりで大抵用意されているからそれらを組み合わせるだけで
大抵組めるが、COBOLはそれらも含めて全部コードを書かないといけないから、とてもじゃないけど組めない。」 だそうな…。 - 893 ：デフォルトの名無しさん：2010/05/05(水) 15:01:01
- >>892
それは構造化プログラミングとか、オブジェクト指向とか関係ない問題だな。
コボラーは何でもそういう語り方するよな。だからダメなんだ。
便利なフレームワークがあろうが、充実したクラスライブラリがあろうが、
足りないものは出てきて、そいつらはスクラッチで作るしかない。
それはアセンブラから超高級言語まで等しく同じ。言語パラダイムも関係ない。
出来ないと言ってる香具師は、単にタコなだけ。
>>891
COBOLは関数のような重要な抽象化機構の導入が著しく遅れていて、
全部グローバル変数＆サブルーチンだけで書けという点がひどすぎる。
つまり、可読性と保守性が著しく悪い。
ローカル変数はプログラムを書く上でとても重要で、アセンブラでさえ
レジスタやスタックがローカル変数として機能するから、
COBOLはアセンブラ以下のクソ言語。 - 897 ：デフォルトの名無しさん：2010/05/05(水) 17:11:36
- ○○が使えないからこの言語はクソ、みたいに言語の一部分だけをとらめえて完全否定するあたり
>>893から激しくコボラー臭がするんだけとw
この前も連中、Numeric型の変数が使えない、戻り値が一つ指定出来ないからJAVAはクソ、とか言って
COBOL以外の言語を全否定していたわ。まあ色々突っ込みたかったけど、触らぬ神になんとやらでスルーしたけど…。
あとCOBOLは保守性が悪いってよく耳にするが、そんなこと言っているのは一部のコボラーだけだそ。
あんなもんただ単に自分がやっている仕事の大変さをアピールするために誇張して言っているだけ。
確かにボリュームだけはでかいから慣れない間は面食らうが、慣れりゃどうってことはない、
ただボリュームがでかい、ただそれだけのこと。
そもそも可読性や保守性なんて作り手の技量の問題で言語はあまり関係ない。 - 907 ：デフォルトの名無しさん：2010/05/06(木) 20:18:34
- >>897
俺は>>893に一票。
というか、あんたがCOBOLERじゃないの？
> あとCOBOLは保守性が悪いってよく耳にするが、そんなこと言っているのは一部のコボラーだけだそ。
> あんなもんただ単に自分がやっている仕事の大変さをアピールするために誇張して言っているだけ。
いや、確かにCOBOLは保守性が悪いよ。Dijkstra先生も認めていらっしゃる。
プログラマによっては多少マシになるが、二度と保守したくないと思うには充分な糞さ。
PROCEDURE DIVISION. が30000行を越える糞ソースを修正したときそう思った。
> 確かにボリュームだけはでかいから慣れない間は面食らうが、慣れりゃどうってことはない、
> ただボリュームがでかい、ただそれだけのこと。
自分で１から組めればそうかもね。
だけど、現実はつぎはぎだらけのソースを修正する仕事ばっかりで、新規案件なんてほとんどない。
> そもそも可読性や保守性なんて作り手の技量の問題で言語はあまり関係ない。
技量を伴ったCOBOLERが少なすぎるってことかな。
http://hibari.2ch.net/test/read.cgi/tech/1158154668/l50人気ブログランキングへ
