COBOLを馬鹿にするな!!

このエントリーをはてなブックマークに追加
1山崎13 ◆5c5udzFPUI
俺が二種とったときはとても世話になったぞ!!
2仕様書無しさん:04/03/20 17:26
馬鹿にされてんのはJavaだよ。間違えんな
3仕様書無しさん:04/03/20 17:30
バカにされてるのは>>1
4仕様書無しさん:04/03/20 17:50
MOVE "バカ" TO >>1
5仕様書無しさん:04/03/20 17:55
これももう昔から言われ続けている事ですんで何度も繰り返しませんが、
誰もCOBOLを馬鹿にしてはいません。
COBOLerを馬鹿にしているのです。
6仕様書無しさん:04/03/20 18:25
流石、糞スレ製造器山崎
半端な糞スレじゃない。
7http://bulkfeeds.net/app/search2?q=COBOL&sort=date:04/03/20 19:06
【ABEND】メインフレーム万歳5【JCL ERROR】 (プログラマー@2ch掲示板)のまとめ

http://pwiki.chbox.com/pukiwiki.php?COBOL
8仕様書無しさん:04/03/20 22:10
>>1
なんで?
COBOLを押しつける奴は馬鹿にするよ 
9仕様書無しさん:04/03/21 01:08
>>8
COBOLを押し付けるやつも問題だが、COBOLを知りもしないくせに
古いだのダサいだの言っているやつは、もっと問題だ。
これは、1990年代初頭、C/S型システムが流行しだしてC系列の
言語がマンセーになった頃から存在した傾向だが、そもそも言語なん
てものにこだわること自体が視点が低すぎるんだ。
なんだかんだ言いつつも40年間も業務システムの現場で使用され続
けてきた理由もそれなりにあるわけなんだから、言語についても適材
適所を客観的に考えるのが正しい姿勢だ。
仮に今現在、流行の最中にある言語だって、いつかは陳腐化して保守
フェーズで苦労するんだ。
あんまり簡単に馬鹿にしてはいけないよ。どんなことについても。
10仕様書無しさん:04/03/21 12:37
> そもそも言語なんてものにこだわること自体が視点が低すぎるんだ。
> 言語についても適材適所を客観的に考えるのが正しい姿勢だ。

矛盾してると気づいてますかー?
11仕様書無しさん:04/03/21 12:43
>>10
・言語にこだわる:俺はこの言語が好きし、これは速いから(自分の好きな機能があるから)使うんだ。
・適材適所:この言語は苦手だけど、このシステムに適してるから、勉強して使うかな。

というような意味で書いたに違いない。
12仕様書無しさん:04/03/21 13:32
>11
でも、一番俺が不適材不適所だから、明日職安にでも行ってくるかな

というような意味で書いたに違いない。
13仕様書無しさん:04/03/21 14:18
まぁ、vbよりかはいいだろ
14仕様書無しさん:04/03/21 15:04
>>13

その通り。VBや.NETに比べたら救いがある。
15仕様書無しさん:04/03/21 15:36
COBOLは事務計算に特化した記述言語だからね。

汎用機の時代から、制御系のASMや、科学技術計算のFORTRAN、
AIのLISP/PROLOGとかと分業してた。

英文に近く、高い技術が不要で、誰が書いても同じようになり、
業務以外の部分(OSとかネットワークとかDISKとか)や機種を、
ほとんど意識しないで済むのが利点。

数値の型を言語で持ってるので、別機種に移植しても丸めや精度にはまらない。
事務計算では、機種ごとの性能より、数字の精度の方が命だから。

技術優先、業務不得手の人には向かない。
16仕様書無しさん:04/03/21 18:13
>>9
サービス残業を押し付けるやつも問題だが、真の残業を知りもしないくせに
古いだのダサいだの言っているやつは、もっと問題だ。
これは、1960年代の高度成長期、経済が右肩上がりころに会社の成長に合わせて
所得も上がっていくという頃から存在した傾向だが、
そもそも残業代なんてものにこだわること自体が視点が低すぎるんだ。
なんだかんだ言いつつも戦後60年間も労務管理の盲点であり続けけてきた
理由もそれなりにあるわけなんだから、サービス残業についても所得と能力の関係
を客観的に考えるのが正しい姿勢だ。
仮に今現在、流行の最中にある年俸契約だって、いつかは陳腐化して保守
フェーズで苦労するんだ。
あんまり簡単に労基署に訴えたりしてはいけないよ。どんなことについても。
17山崎13 ◆5c5udzFPUI :04/03/21 19:45
COBOL最強!!
18仕様書無しさん:04/03/22 09:50
>16
何を言いたいのかよく分かりませんが、過去の栄光にすがっていたい窓際のCOBOLerなんですね。
19仕様書無しさん:04/03/22 10:05
かって馬鹿にされていたのはCobolerであって、COBOLでは無い。
そういう馬鹿の受け皿としての役割は、今はJavaが果たしている。
20仕様書無しさん:04/03/22 10:13
なんにせよ、いまどきCOBOLは時代遅れ
21仕様書無しさん:04/03/30 11:05
>>1は最強!                      のバカ
22仕様書無しさん:04/04/03 22:33
あれ?COBOLの良さわかってない奴が多いのか?
コボルだからださいとかほざいてる奴ってほんとなんなんだ?
よくわからんが、コボルはコボルの良さがあり、別にかっこ悪くない。
23仕様書無しさん:04/04/13 12:55
>>22
ちゃうちゃう。
COBOLなんて俺もできるよ。良さも知ってはいる。
ただ、COBOLしかできない香具師は無能ってこと。
Cしかできない香具師と比較してはならないくらいにな。
24仕様書無しさん:04/04/28 23:27
25仕様書無しさん:04/04/28 23:48
この板COBOLだらけ。COBOL流行ってんのか?
26仕様書無しさん:04/04/29 11:03
たたくのがはやってるだけ
27仕様書無しさん:04/04/29 13:00
数値の画面出力やファイル出力で、COBOLが欲しいと思うことがある。
とりあえず、DATA DIVISIONは好きだ。
28山崎13 ◆5c5udzFPUI :04/05/06 19:02
age
29仕様書無しさん:04/05/06 19:07
・・・すっかり、お前を蹴るのが日課になった漏れが悲しい。
         ∧_∧
        _( ´_ゝ`)
      /      )     ドゴォォォ _  /
     / ,イ 、  ノ/    ∧ ∧―= ̄ `ヽ, _
    / / |   ( 〈 ∵. ・(  __ >  ゛ 、_  ←>山崎13 ◆5c5udzFPUI(白痴&総合失調症)
   | !  ヽ  ー=- ̄ ̄=_、  (/ , ´ノ \
   | |   `iー__=―_ ;, / / /
    !、リ   =_二__ ̄_=;, / / ,'
        /  /       /  /|  |
       /  /       !、_/ /   〉
     / _/             |_/
     ヽ、_ヽ
30仕様書無しさん:04/05/06 20:51
お約束コピペ

http://www.cobol.gr.jp/
“21世紀もやはりCOBOL”
31仕様書無しさん:04/05/06 20:52
32仕様書無しさん:04/05/06 21:22
コボルって二次元配列がないって本当?
しかもループの構文がなくてGOTO文でループ回してるって本当?
33仕様書無しさん:04/05/07 00:42
ウソ。
34コボ歴1年強:04/05/22 19:18
ココで質問して良いのか判りませんが・・・
凄く基本的なことでハマってます。
S9(11) COMP3で定義してある入力項目を
普通のS9(11)にMOVEさせたら1番最後の桁が英語になってしまいました。

入力値S9(11)COMP3 +2222222222
を単純MOVE
出力値S9(11) 222222222B

になってしまいました。
BはHEXでC2なので、S9の符号Cが入ってしまったと考えて良いと思います。
…これの対処法(出力値を正常に表示させたい)をご教授下さい…
周りの人間には聞きづらいもので…
35仕様書無しさん:04/05/22 19:21
今時コボルやってる奴は間違いなく馬鹿。
36仕様書無しさん:04/05/22 19:58
できるコボラー探すよりできるJava厨探すほうが早い
ただ、できるJava厨は飽きっぽいのですぐどっか行く
37仕様書無しさん:04/05/25 23:49
プログラマー適性検査で、ボロボロだったのに
COBOLプログラマーで採用されてしまいますた。
ぼくは、この先、生きてイケますか?
38仕様書無しさん:04/05/27 02:13
>1と>34は最低

何も考えずにCOBOLだけ使ってると、頭悪くなるよね。

この移送命令は何が起きるのかをきちんと把握しないから>1や>34みたいな奴が出るんだよね。

まあ、Cでもとんでもない奴はいるけど。






  使ってない変数の宣言文を削ったら、動かなくなっちゃってさぁ
とか・・・・   いい加減にしろや。
きちんと理解しないとCは動かないから、馬鹿の占有率はCOBOLより低めだね。

>36
頭の悪い発言はやめてくれ。 お願いだから。
39仕様書無しさん:04/05/28 00:19
>>37
コボルなら、適性なくても、なんとかやっていけるんじゃないの?
コボルは、まだ需要が続くだろうし、給料の高望みをしないなら、
それなりに生きていけると思います。
4038:04/05/28 03:17
>39
それも程度問題だよ。
センスのない奴に作らせれば、COBOLだってとんでもないことになる。

でも10年も前だが、すごいできるとの評判だった奴にCを組ませたら、
一発でCOBOLerとわかる物を作ってきた。
俺は自分でもCOBOLやるからわかるけど、文化が違いすぎ。

確かにバグは少なかったが、その後引き継いだ後はすんげぇつらかった。
全部書き直してぇよ〜〜〜〜 と呻く毎日だった。
41仕様書無しさん:04/05/28 13:19
>40
確かにプログラミングセンスは必要かもしれないですが、
センスっていうのも慣れの部分が多いと思います。
適性がなくても、それなりに勉強すれば、(COBOLなら)
そこそこやっていけるような気がしますけど。
42仕様書無しさん:04/05/29 09:09
馬鹿でも使えるって事だな
43仕様書無しさん:04/05/30 01:09
>>42
まぁ、バカでも半年もすれば使えるようになるんじゃない?
でも、仕事がデキるレベルに達するかどうかは疑問。
44仕様書無しさん:04/05/30 19:53
ボコルばっかしやっていて、頭が腐った
45仕様書無しさん:04/05/31 01:21
>>44
それは、もとから腐っていたのだよ。
46仕様書無しさん:04/05/31 12:51
んだよ
だからボコルしかできないの
そんで、ボコルばっかしやっていたら頭にウジがわいたっす
47仕様書無しさん:04/05/31 13:22
>>46
頭にウジが湧くなんて、カッコいいっす!シビレるっす!
もう死体並みにイカすっす!(w
48仕様書無しさん:04/05/31 16:06
NetCOBOL だとさ、言語はCOBOLでも覚えることイパーイ

http://software.fujitsu.com/jp/cobol/
49仕様書無しさん:04/05/31 21:41
F(メーカとして落ち目)も、もの作りからやくざなソフト屋さんに成り下がったのね
ボコル文法の説明が30年前の記法のまんまで、懐かしく思ったっす。
ま、ルールの多いボコルで頑張ってくんなませ > これから頭の腐るボコル屋さん

--
ちょこっとやって頭にウジがわいた元元元元々ボコル屋
50仕様書無しさん:04/06/03 20:42
COBOLばっかやってた奴がPerlとか見るとどうなっちゃうんだろう
51仕様書無しさん:04/06/03 21:00
>>50
別になんてこともないだろ。

Perlなんてうんこ小学生でも理解できる。
52仕様書無しさん:04/06/03 23:51
>>51
果たして、コボラーがコボル以外のモノを認めるかどうか・・・
53仕様書無しさん:04/06/05 00:53
ボコルは糞だから馬鹿にしてよし

ボコラの巣窟 ○○アイプロダクト
54仕様書無しさん:04/06/12 14:08
天下一の天才 ◆fYPuzeyYVY
55仕様書無しさん:04/06/12 15:04
植田ヒサシー作
コボLちゃん
56仕様書無しさん:04/06/12 16:59
おまいらあんまりコボちゃんをいぢめんなよ
57仕様書無しさん:04/06/13 02:27
COBOLは糞だと思うが、コボラーを馬鹿にするなら、
金融系の基幹システム開発を1年以上やってみてから
馬鹿にしてほしいな。
自分のバグで新聞沙汰になるスリルを味わえるぞ。
実動してるホスト系のCOBOLは、いまだにローカル変数
さえ無いから、ソース読むのに気が狂う思いも味わえるしな。
58とがしー:04/06/13 03:24
>>34
計算用項目に9タイプの符号つきを使わないのは常識です.(COBOL25歴年)
59仕様書無しさん:04/06/13 05:50
cobolとperlは同レベルの糞言語
60仕様書無しさん:04/06/13 05:51
あ、しまった、全部大文字にしないと怒られる
COBOLとperlね
perlでなくてPerlです。
62仕様書無しさん:04/06/13 07:41
>>58
>ttp://www.cobol.gr.jp/knowledge/technical/tec004.html

>USAGE DISPLAYの項目に対しては、この他に SIGN SEPARATE句を使って
>符号の表現形式を定義することもできます。

25年もやっててそんなことも経験でしか言えないから馬鹿にされんだよ。
63仕様書無しさん:04/06/13 12:45
>>57
言いたいことはわかるが、その理屈はわざと分かりにくいプログラムを
書いて、どうだ、このシステムを理解するにはお前らは10年早い、
と言い出す典型的なCOBOL屋理論ではなかろーか
64仕様書無しさん:04/06/13 14:17
COBOLは10進数を扱えるぞ!!
どーだ凄いだろう。
65仕様書無しさん:04/06/13 14:29
うわー、すごいなー(←棒読み)
66仕様書無しさん:04/06/13 14:39
1
67仕様書無しさん:04/06/13 15:58
>>61
間違えました、すいません
COBOLとPERLね
68とがしー:04/06/13 22:29
わお!
69仕様書無しさん:04/06/13 23:38
汎用機でビジネスロジックを実行するというシステム。
アプリケーションの設計を担当している。
(実装に入ったらフロントのWebアプリを担当するので、COBOL言語のことを知る必要はない)

素で分からないので教えて欲しい。


動的な要素数を持つリストや、実行時までその総数が分からないファイル群を
扱うような業務処理を設計した。
すると生粋のCOBOLerから、「ふつう使わない」と言われた。
んなことあるのか?

計算機を普通に扱えば、そんな場面はいくらでもある。
何十年と使われてきたプログラム言語にそれができないとはとても思えない。

信じられないので突っ込んでみた。
俺「技術的にできないんですか?それともやらないんですか?」
相手「ふつうやらない」
俺「その理由って何ですか?プログラムがトリッキーになるとか、運用上ですごく問題が出るとか」
相手「汎用機は、動的なことは苦手なんだよ」

お前が苦手なだけじゃないのか?とは思ったんだけど、実際のところどうなんでしょう。
本当に「できない」のでしょうか。実装上、避けたほうが良いのでしょうか。


70仕様書無しさん:04/06/13 23:45
長い釣りだな。汎用機はデータ量が「わからない」なんて言う条件でシステムを作らない時代からあるんだよ。
以上。
71のっち:04/06/13 23:46
>>69
コボルだと多分できない
※やってやれないことは無いけど、とても面倒くさい。
アセンブラでやった方が楽だと思う
72仕様書無しさん:04/06/13 23:49
>>69
ふつうやらない。それ以上でもそれ以下でもない。
73仕様書無しさん:04/06/14 00:12
通常の業務で実行時までその総数が分からないファイル群を作る事自体が難しいのでは?
汎用機では。
74仕様書無しさん:04/06/14 08:08
>>70
言っていることが理解できない。
LispはCOBOLより古い言語だが、>>69が言ってる程度の話なら
動的云々など考えるまでもなく、しごく当たり前の処理。
少なくとも古い新しいの問題じゃないだろう。
75仕様書無しさん:04/06/14 18:18
設計が汎用機の設計になっていません。
そういう駄目な設計を悪魔的って言いいます。
覚えておきなさい。

まだ君には基幹の担当は無理です。
言語うんぬん以前の問題です。
うぬぼれるな若造。
76仕様書無しさん:04/06/14 18:27
>>75
知り合いにも汎用機屋はいるが、あんたみたいなやつは馬鹿にされて当然。
77仕様書無しさん:04/06/14 18:31
>>76
知り合いに汎用機屋がいるから何だい?それがいったい何だっつの?
78仕様書無しさん:04/06/14 18:34
俺の知り合いにも芸能人はいるが、あんたみたいな奴は(ry
79仕様書無しさん:04/06/14 18:37
>>77
頭悪いなお前。
80仕様書無しさん:04/06/14 18:39
>>79
中学生かお前は
81仕様書無しさん:04/06/14 18:46
>>76
知り合いに汎用機屋がいる中学生ですか?w
82仕様書無しさん:04/06/14 18:46
>>77
汎用機屋は馬鹿だという一般論には賛同しないが、
ここにいるコボラは馬鹿ばっか、ということだ。
「頭の悪いレス」をネタで書いてるのかよ。
83仕様書無しさん:04/06/14 18:48
と知り合いに汎用機屋がいる低脳若造のセリフでした。

つーか、低脳若造に知り合い扱いされる汎用機屋がかわいそうだ。
84仕様書無しさん:04/06/14 18:49
自分に自信が無いから知り合いの力にあやかろうとしているんでしょ?w
85仕様書無しさん:04/06/14 18:51
おっさんも大変だね。
86仕様書無しさん:04/06/14 19:03
くだらない煽り合いはもうどうでもいい。

>>69
で?代替案は思いついたのか?
不確定なことを排除しているから汎用機は
堅牢なんだぞ。
87仕様書無しさん:04/06/14 19:26
>>69
1. DBに格納して処理
2. データ量を見積もって、通常発生し得る量より多めにテーブル要素数を決定する
88仕様書無しさん:04/06/14 20:10
>>87
DBに格納するのはいいとして。

> 通常発生し得る量より多めにテーブル要素数を決定する

偉そうな口聞いてた割にはもっさい設計だな。
89仕様書無しさん:04/06/14 20:28
>>88
正直珍しい例だと思いたいよ…
90 :04/06/14 23:45
>>69
COBOLもやってみたら?
この前レスでもさんざでてるPIC〜(PICTURE〜)は必ずWORKINGSTORAGEで設定するでしょ。
要は作業用テーブルは固定長になる。>これをファイルとしてWORKINGSTORAGEで定義してある。
それを可変長になるようにプログラム?どうやって?
まぁ、DBメーカの様にアセンブラレベルからDB構築するなら話は「画期的」になるかもしれない。
そうでないなら、究極のへそ曲がり。
9169:04/06/15 00:23
レスサンクス。
技術的裏付けをとるために、ざっとCOBOLマニュアルを読んでみた。
動的配列はODO(OCCURS DEPENDS ON)だとかでいけるようだけど、ファイルを動的に読み込むことができないみたいで、無理っぽい。

やっぱり道具は選びたいな。「汎用機の設計」?
ペッイラネ
92仕様書無しさん:04/06/15 01:39
>>91
レベルが低すぎる。
93仕様書無しさん:04/06/15 07:01
COBOLerの定義
(1)
・COBOLしかできない人たち。
・20年前のセオリーを後生大事にしまい込み、
 未だに使いつづけている、コンピュータ業界の重要無形文化財。
・物事を論理/順序だてて考えるという発想がおおよそない人たち。
・と、いうか「人月計算」で玉石混交で仕事ができた時代の
 「石」のほうの生き残り、コンピュータの基礎ができていない、
 簡単に言うと使えない人間がたくさんいる世界。
・「JCLとPROCEDURE DIVISIONを使っちゃダメ」と言ったら、
 なにもできないような人たち。
・・・・と。別に「敵意」「悪意」はないのだけれど、そういう
人種が多いのも事実だよなぁ〜。
(2)唯我独尊
・時代がWindowsになろうがLinuxになろうがGUIになろうが、
 どこまでもCOBOLを追い求めるらしい・・・。
94仕様書無しさん:04/06/19 15:37
我らコボラー 大塚 さん 2004/06/19 http://www.coboler.com/newpage2.htm

COBOLなら、オレに聞け!<3>

http://pc5.2ch.net/test/read.cgi/tech/1087178214/
95仕様書無しさん:04/06/25 12:56
「汎用機屋は馬鹿」というのは正しくも有り間違ってもいる。
正しいのは、「程度の低いエンジニアを大量に使わないといけないので、
エレガントだが理解するのにセンスが必要な設計をしてはいけない」から。
間違っているというのは、「そのような判断を正しく行うことができる」から。
程度の高い、少数のスーパーハッカーのみを対象にしてきたLispと、
程度が低い、大量の高卒/文系プログラマーを対象にしてきたCobolの違いもそこにあると思う。
96仕様書無しさん:04/06/26 13:11
汎用機のスキルというのは、汎用機の制約を知るということなのか…
97仕様書無しさん:04/06/27 13:55
そりゃま、何でもそうでしょ。
与えられた制約の中で最適解を求めるのがエンジニアの仕事だから。
98仕様書無しさん:04/06/27 16:21
正確に言うと「自分が最適解であると思うものを求める」だな
99仕様書無しさん:04/06/27 17:20
言語なんてどうでもいいんだよ

自分が儲かれば
100仕様書無しさん:04/06/27 17:36
ロマサガに出てきたザコキャラですね。
ロマサガのデザイナはアンチコボリストですか。
101仕様書無しさん:04/06/29 00:43
>>95

なんか、Accessみたいだな......
昔、AccessVBAで凝ったの作ったら上司に「誰もメンテナンスできないから止めてくり」って言われた.....
それからみんなにも分かるようにって説明のドキュメントをいっぱい書かされた
102仕様書無しさん:04/06/30 01:32
Accessがデビューした頃・・・
PC用のDBMSがDBASE3とかだった頃だ
低価格のDBソフトが主流の中(カード型がほとんどだった時代)
でSQLが使えるだけで感動した
MSの罠がその後にたくさんあったな

改行位置や書き込みがメチャクチャなことに対して突っ込みしてね
103仕様書無しさん:04/07/04 11:04
>>93
> ・「JCLとPROCEDURE DIVISIONを使っちゃダメ」と言ったら、
>  なにもできないような人たち。

んじゃ、おまいはmain系関数と環境変数無しでC言語
なにができるというのか?


> ・時代がWindowsになろうがLinuxになろうがGUIになろうが、
>  どこまでもCOBOLを追い求めるらしい・・・。

いーんじゃね?俺は仕事上くっついたり離れたりしてるけど
求められる事が出来ればなんだっていー気がするんだが。
104仕様書無しさん:04/07/04 12:57
COBOLerの定義
(1)
・COBOLしかできない人たち。
・20年前のセオリーを後生大事にしまい込み、
 未だに使いつづけている、コンピュータ業界の重要無形文化財。
・物事を論理/順序だてて考えるという発想がおおよそない人たち。
・と、いうか「人月計算」で玉石混交で仕事ができた時代の
 「石」のほうの生き残り、コンピュータの基礎ができていない、
 簡単に言うと使えない人間がたくさんいる世界。
・「JCLとPROCEDURE DIVISIONを使っちゃダメ」と言ったら、
 なにもできないような人たち。
・・・・と。別に「敵意」「悪意」はないのだけれど、そういう
人種が多いのも事実だよなぁ〜。
(2)唯我独尊
・時代がWindowsになろうがLinuxになろうがGUIになろうが、
 どこまでもCOBOLを追い求めるらしい・・・。
105仕様書無しさん:04/07/04 15:02
玉石混合で仕事が出来た時代?

未来から来た人がいそうだなw
106仕様書無しさん
COBOLでもCでもJAVAでも何でも良いのだよ・・・・
その業務がちゃんと判ってるやつが設計してれば・・・

はあぁ〜〜  なんでこんな物を知らないやつが担当SEなんだ・・・