5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

COBOLの現状について教えてください

1 :仕様書無しさん:2006/07/13(木) 17:12:24
知り合いが大手金融会社などのシステム保守を請け負っているとこに内定したらしいんです。
正直COBOLって、昔の言語って感じであまりイメージがよくなかったんですけど

「大手の銀行とか重要機関は全部COBOLだし、COBOLから変更の予定もない。
 若手にはCOBOLは不人気だからCOBOLの担い手が減ってきている。
 COBOLは一番安定してて、需要もあるから、むしろやるならCOBOLだ」

って言われた。
なるほどと思うと同時にホントかな?とも思います。

皆さん、実際のところはどうなんでしょうか?
COBOLは安定優良なんでしょうか?ご意見よろしくお願いします。

62 :仕様書無しさん:2006/09/02(土) 11:45:58
COBOLってプログラム組んでても楽しくないんだよな。
ほとんどの仕事が他人が作ったグチャグチャになったソースを修正することだしorz
帳票関係はさすがにCOBOLはスゲーと思うけど、それだけだからな。
COBOLで.netとか出てきて、かなり無理してるのが滑稽orz

63 :仕様書無しさん:2006/09/05(火) 03:52:37
COBOLは可読性が高くてすばらしい。
Javaみたいな無駄に肥大化して手に負えなくなるようなヘタレ言語とはわけが違う。

64 :仕様書無しさん:2006/09/05(火) 08:21:43
Javaの無駄な肥大化について、一例でも挙げて見ろやww

65 :仕様書無しさん:2006/09/05(火) 16:38:09
ほれ、自分で探せ。
ttp://www.google.co.jp/search?hl=ja&q=Java+%E8%82%A5%E5%A4%A7%E5%8C%96&lr=

66 :仕様書無しさん:2006/09/06(水) 00:36:37
>>63
COBOLの可読性って、きれいなソースだけだろ。
修正しまくってドキュメントがまったくないソースなんて見れたもんじゃねーぞ。

67 :仕様書無しさん:2006/09/06(水) 23:16:56
>>59 & 60
COBOL使いと仕事する前の自分なら
「あぁ また2chプログラマのCOBOLerたたきかよ(w」
と言うが
COBOLerと仕事をした今の自分から言わせてもらうと
「大正解〜」
と言う。

68 :仕様書無しさん:2006/09/07(木) 01:16:42
>>63
肥大化してるのは言語仕様じゃなくて要素技術の話だ。
んなもん、使わなきゃいいだけだろ。

つか、JavaとCOBOLでまったく同じことを実装したら
Javaの方が間違いなく可読性高いソースにしあがるぞ。

69 :仕様書無しさん:2006/09/07(木) 05:28:09
それはありえないな。


70 :仕様書無しさん:2006/09/07(木) 21:05:31
常識的な使い方の範囲でだが、
一般的に、COBOLで記述可能なら、JavaよりもCOBOLの方が可読性が高い。

問題なのは、COBOLの硬直的な仕様のため、記述できる範囲が限られているということだ。

71 :仕様書無しさん:2006/09/07(木) 22:08:05
COBOLの可読性のおかげで
基本情報に合格できました

72 :仕様書無しさん:2006/09/07(木) 23:54:23
素人でもある程度の文意を汲み取ることができるってのがCOBOLの可読性
短い時間で多くの情報を得ることについては、COBOLの記述性は他の言語よりかなり劣るよ

73 :仕様書無しさん:2006/09/08(金) 01:18:03
ようするに、素人でもわかる程度のプログラムしか書けないから、COBOLは可読性が高いということだな。

つまり、書籍に例えると、全部ひらがなで書かれた書物ということだ。

全部ひらがなで記述すれば、小学1年生でも夏目漱石や川端康成を読むことは可能だ。
しかし、大人が読むにはちとつらい。

結論づけると、COBOLはお子ちゃま用言語ってことですな。

74 :仕様書無しさん:2006/09/08(金) 01:29:23
出口はあちらです

75 :仕様書無しさん:2006/09/08(金) 02:26:58
>>73
高級言語とはそういうことなんだよ。
この低脳め。

76 :仕様書無しさん:2006/09/08(金) 06:20:28
COBOLの場合、複雑なアルゴリズムなんてありえないからな

77 :仕様書無しさん:2006/09/08(金) 20:49:22
>>75
JavaもCもC++も、高級言語なんだよ。
この低脳め。

78 :仕様書無しさん:2006/09/08(金) 21:55:44
>>76
go toであっちこっち跳ぶ奴見た事無いんだろう?

79 :仕様書無しさん:2006/09/09(土) 03:03:21
>>77
高級言語の意味をわかってるかテストしてやろう。
COBOLはC/C++よりも高級である。
これは真か偽か?

80 :仕様書無しさん:2006/09/09(土) 03:22:03
>>79
俺は>>77じゃないけど、プログラミング言語の高級度で
いえば、C言語よりCOBOLの方が上だろうな。
プログラミング言語の仕様がアプリケーション等、業務目的
のために策定され洗練されているし、キーワードが人間の
言語(英語)に近い。

C言語は高級アセンブラ言語に近いんジャマイカ?

C++はパラダイム肥大化で、ややプログラミング言語学者や
技術者の自慰嗜好要素が含まれている。
ISOうんぬんで品質管理の認定を受けても、実際のコードは
各自でC言語以上にバラバラなスタイルなので、これで認定?
ドキュメントだけの統一で大丈夫か? とも感じる。

81 :仕様書無しさん:2006/09/09(土) 15:02:22
高級アプリ言語と高級アセンブラ、どっちがより高級かてのは、
甘いメロンと甘い桃、どっちがより甘いか、て比べてるようなもんでは。

82 :仕様書無しさん:2006/09/10(日) 18:07:29
>>78
構造体もない。
ポインタもない。
再帰も使えない。

そんな言語で扱えるアルゴリズムなんてたかが知れてるんだよ。

83 :仕様書無しさん:2006/09/10(日) 18:17:49
ぷ。
言語に機能がないとアルゴリズム使えないんだって。

84 :仕様書無しさん:2006/09/10(日) 18:21:43
ま、所詮COBOLerにアルゴリズムの話など通じるわけはないわなw

85 :仕様書無しさん:2006/09/10(日) 18:34:57
>>82
そりゃCOBOLは事務処理言語だし・・・
構造体はレコードだけでも十分。
参照やポインタの概念は無くても困らない。
定型の事務処理に再帰の有効性はまず無い。

機能的にはSQL+αで十分でしょ。

86 :仕様書無しさん:2006/09/10(日) 18:37:24
まぁ、気の毒だとは思うよ。よりによってCOBOLだもんなぁ。
コントロールブレークだのマッチングだのといった単純なアルゴリズムしか扱えない環境じゃねぇ。

87 :仕様書無しさん:2006/09/10(日) 21:45:48
使用目的を考えずにアルゴリズムがどうこう言う奴はただの馬鹿だ。

88 :仕様書無しさん:2006/09/10(日) 21:48:56
アルゴリズムを語れないプログラマなぞ馬鹿以下だ

89 :仕様書無しさん:2006/09/11(月) 18:06:03
アルゴリズム体操はできるぜ

90 :仕様書無しさん:2006/09/13(水) 15:24:36
COBOLerを目指す若人がいるというのか、珍しいな
単純に労働条件で比べれば、まだまだ発展中の言語(代表例はjavaか)の使い手に比べて安定してるだろうな
なんせ、仕事のメインは開発ではなく保守だから
うまくいけばPGに付き物の残業地獄から逃れられるぞ





うまくいけば、な

91 :仕様書無しさん:2006/09/13(水) 18:41:33
>>90
逆にプログラミングや先端技術、コンピュータサイエンス
などに魅力を感じたらCOBOLer失格とも言えるな。

COBOL言語 仕事用!

92 :仕様書無しさん:2006/09/13(水) 18:53:10
>>90
うまくいかない場合ってのはどんな場合があるのだ?

と、内情をまったく知らない俺が聞いてみる……単純に職なしになるのか?

93 :仕様書無しさん:2006/09/13(水) 19:04:03
そういう案件が続けばって話だろ。
ある日突然ユーザー企業が目覚めなければ、だ。

94 :仕様書無しさん:2006/09/18(月) 21:56:01
まあ、2,3年コボラーやってたけど
デスマーチとは無縁の、マッタリした職場だったな
おっさんたちの開発時の武勇伝が色々聞けた

95 :仕様書無しさん:2006/09/24(日) 16:17:19
Cocolの開発環境でお薦めのものってあります?


96 :仕様書無しさん:2006/10/01(日) 23:37:42
>おっさんたちの開発時の武勇伝が色々聞けた

どんな話かしらんけど、「完全徹夜は当たり前」とかそんな話ばっかりじゃねーだろーな?
前転職活動で回ってて、「完全徹夜は当然対応できるよね?」とか聞かれて、このジジイ、阿呆とちゃうか?と
思ったよ、俺は。

97 :仕様書無しさん:2006/10/08(日) 00:11:38
WEB COBOLなるものがあると聞いたのですが、COBOLerに未来はありますか?

98 :仕様書無しさん:2006/10/08(日) 06:00:40
大昔から動いてるCOBOLのシステムは紙しか残ってない昭和の仕様書
だったり本番環境にLMがあるのみでソースがないなど新システムに
以降するのも大変ってのも多いな

99 :仕様書無しさん:2006/10/08(日) 16:17:30
職業プログラマとして先行きを考えなければならないのは
LISPerとPL/Ierくらいじゃネーの?

100 :仕様書無しさん:2006/10/08(日) 20:34:05
>99
コボラー乙

101 :仕様書無しさん:2006/10/08(日) 20:35:56
うらやましいのか?

102 :仕様書無しさん:2006/10/08(日) 20:36:53
うはwwwそういうことにしておくよwww

103 :仕様書無しさん:2006/10/10(火) 02:09:58
プログラマーの残業時間は一般職種に比べて5割増しらしいけどな、実数も感覚も
……労働時間でいえばCOBORerはプログラマーであってプログラマーではないのか

104 :仕様書無しさん:2006/10/10(火) 02:29:28
新しい言葉を発明する仕事は、マじゃねーだろ。

105 :仕様書無しさん:2006/10/10(火) 14:28:59
読み方はコボーになるか……

てか特にプログラマになろうという意思はなかったのに
就職活動中にたまたま受けたらたまたま採用されてなんとなくプログラマなったりしたら悲劇だ


106 :仕様書無しさん:2006/10/25(水) 23:34:45
>>105
それ俺

107 :仕様書無しさん:2006/10/28(土) 19:55:08
>>99
Lisperなめんなw
奴らの平均レベルは押しなべて高い。

108 :仕様書無しさん:2006/10/29(日) 17:58:10
>>107
基礎にLISPが染みついてる香具師はそうかもしれんが
>>107みたいにLISP使えますレベルじゃぁ…

109 :仕様書無しさん:2006/10/29(日) 18:08:37
>>108
句読点も使えず、アンカーも冗長。
お前はたいしたマじゃ無さそうだなw

110 :仕様書無しさん:2006/10/29(日) 18:09:59
コボラでしょ。

111 :仕様書無しさん:2006/10/31(火) 14:56:27
そういえばCOBOLとNETCOBOLって何が違うんだ
オブジェクト指向にでもなったのか?

112 :仕様書無しさん:2006/10/31(火) 20:10:43
コボルがオブジェクト指向に対応するとかどうとか聞いたことが確かにあるな。
どうなったのかしらんが。

コボルは知ってて損はないな。いまだに新規案件のバッチはコボルで作ることも多いし。
コボルしかできないってのは問題だが。
超簡単な言語だし覚えて損はないと思われ。

113 :仕様書無しさん:2006/10/31(火) 20:56:27
COBOL85しか知らないんだけどさ、最近のCOBOLって動的配列は出来るの?

114 :仕様書無しさん:2006/10/31(火) 23:03:36
>>113
何そのかっこいい言葉?

115 :仕様書無しさん:2006/11/01(水) 00:19:13
できるんじゃねーの?

116 :仕様書無しさん:2006/11/01(水) 01:59:27
COBOLって再帰できないんだ・・・。
再帰に向いている処理をする際かえって面倒じゃないのか?

117 :仕様書無しさん:2006/11/01(水) 02:49:42
とりあえず今のところ再帰処理はしてないな

118 :仕様書無しさん:2006/11/02(木) 00:18:36
富士通の新人研修でコーディングシートを貰ったよ!
あと、あのテンプレートというやつ。

119 :仕様書無しさん:2006/11/02(木) 23:11:05
>>116
どんな言語であったとしても、たとえローカル変数が使えないとしても、
スタックをエミュレートすれば再帰処理は可能だ。

120 :仕様書無しさん:2006/11/03(金) 14:23:29
俺はCOBOLで再帰処理を書いたことがある。
古いCOBOLは全部グローバルな変数なので、
スタック用の配列とスタックポインタの変数を作り、
PERFORMを呼び出す前にサブルーチン内の変数と実行している場所をスタックに積み上げ、
GOTOで自分のサブルーチン自身の先頭に飛んだ。
抜けるときはスタックから変数と戻るべき場所を取得し、戻る。

これにより、ツリーを辿る処理に深さの制限が無くなった。(もちろんスタック容量の範囲内)

121 :仕様書無しさん:2006/11/03(金) 14:54:10
>>120
それは、オナニーに近いプログラムだ。
そこまでできるなら、さっさとCOBOLを捨てて別の道に進んだほうがいいと思うぞ。

122 :仕様書無しさん:2006/11/03(金) 19:38:44
>>121
職場でオナニー 3ヌキ目
http://pc8.2ch.net/test/read.cgi/prog/1054634685/


123 :仕様書無しさん:2006/11/04(土) 06:54:40
>>120
どんな業務で必要としたのか、そっちのほうに興味がある。

>PERFORMを呼び出す前にサブルーチン内の変数と実行している場所をスタックに積み上げ、
>GOTOで自分のサブルーチン自身の先頭に飛んだ。
>抜けるときはスタックから変数と戻るべき場所を取得し、戻る。
ここ読んでるとアセンブラでやることをCOBOLで実現してるみたいでおかしい、いや面白い。


124 :仕様書無しさん:2006/11/04(土) 20:40:37
>>123
元来PGという人種はヒマになると凝りだすからな。
まぁ、現実にはアレな輩も多数含まれるわけだが。

125 :仕様書無しさん:2006/11/04(土) 23:15:02
>>120 のやり方をオナニーとは思わんなあ。
実際、良く知られた技法だし、再帰ができる言語でも、サブルーチン呼びだしの
オーバヘッドが大きい時に、チューニングの一種としてやることが稀にあるよ。
木を辿るようなアルゴリズムは再帰で考えた方が楽だから、もし俺が>>120
立場だったとしても同じことをしたと思う。

まあ、そういう処理をCOBOLで書かざるを得なかったのは、不幸だし、さっさと
別の道に進むべきというのは同意。(w

126 :仕様書無しさん:2006/11/04(土) 23:37:44
>>125
スタックをエミュレートする時点で、すでにコスト高いと思うけど・・・・

127 :仕様書無しさん:2006/11/05(日) 17:29:30
>>125
俺の会社じゃ、俺以外にスタックの意味がわかるヤツがいなかった。
これって普通ですか?

128 :仕様書無しさん:2006/11/05(日) 18:53:04
その会社のプログラマーの平均年齢とレベルによるんだろうなぁ。
20代の人間はシラネーんじゃねーか?

129 :仕様書無しさん:2006/11/05(日) 19:52:25
学歴にもよるな。
スタック、キュー、ハッシュくらいは教養レベルのデータ構造だろ。

130 :仕様書無しさん:2006/11/05(日) 20:17:53
>>127
普通は誰一人として知らない。
お前が一人だけでも知っているから、普通じゃない。


131 :仕様書無しさん:2006/11/05(日) 23:05:10
スタックとキューは自前で知らなくてもそれなりのプログラム作れるようになったからな

132 :仕様書無しさん:2006/11/05(日) 23:20:25
まあ、現状、知ってたからってだから何ができるんだって感じではある
いい時代なのか情けない時代なのかよくわからんな

133 :仕様書無しさん:2006/11/05(日) 23:30:22
>>132
COBOLerにとっては、40年前からスタックとキューは必要ありませんでした。

134 :仕様書無しさん:2006/11/06(月) 22:58:08
COBOLプログラムには歴史が詰まってんだよ。
この間、ソースを見てたら1972年とか書いてあってよ
なんか涙が出てきたな。

135 :仕様書無しさん:2006/11/06(月) 23:06:26
COBOLプログラムには歴史が詰まってんだよ。
この間、ソースを見てたら慶應元年とか書いてあってよ
なんか涙が出てきたな。



136 :仕様書無しさん:2006/11/06(月) 23:09:19
COBOLプログラムには歴史が詰まってんだよ。
この間、ソースを見てたら2006年とか書いてあってよ
なんか涙が出てきたな。

137 :仕様書無しさん:2006/11/06(月) 23:10:29
次は江戸時代初期の頃か?

138 :仕様書無しさん:2006/11/06(月) 23:11:10
COBOLプログラムには歴史が詰まってんだよ。
この間、ソースを見てたら神武天皇即位対応とか書いてあってよ
なんか涙が出てきたな。



139 :仕様書無しさん:2006/11/07(火) 00:57:47
あー
ウチは昭和で動いてるんですよ
って言ってた所、まだ動いてるのかなぁ・・81年か
さすがに3桁になったら修整するんだろうか?

140 :仕様書無しさん:2006/11/07(火) 01:51:37
>>139
それまで会社が存続しているかどうか・・・

141 :仕様書無しさん:2006/11/07(火) 02:02:58
コボラーって
COBOLERでいいの?
COBOLORじゃあるまいか?

142 :仕様書無しさん:2006/11/07(火) 03:28:23
>>141
ホントはCOGBOLLA
中生代に繁栄した

143 :仕様書無しさん:2006/11/07(火) 11:27:56
>>141
コボラってかくと可愛いよ。

144 :仕様書無しさん:2006/11/07(火) 20:40:32
ゴジラ対コボラー

145 :仕様書無しさん:2006/11/07(火) 22:17:38
コボラvsゴジラ

146 :仕様書無しさん:2006/11/07(火) 23:21:34
コボラvsメカコボラ(コードジェネレータ)

147 :仕様書無しさん:2006/11/07(火) 23:22:10
ガメラVSコボラ

148 :仕様書無しさん:2006/11/08(水) 00:09:31
http://pc.2ch.net/test/read.cgi/prog/1029933440/

149 :仕様書無しさん:2006/11/09(木) 04:44:32
コボラーが合体して、古代生物コボラになります。

150 :仕様書無しさん:2006/11/09(木) 09:22:37
コボル簡単だし大体が保守だから開発と違って
楽な気がする
いきなり廃止なんてありえないし移行は現状不可能だから
やってて損はないな

151 :仕様書無しさん:2006/11/09(木) 12:03:33
保守の方が大変

152 :仕様書無しさん:2006/11/09(木) 13:48:13
ドライバとかいうテンプレ集ってどこで手に入れたらいいんですか?

153 :仕様書無しさん:2006/11/09(木) 15:09:07
来年からSEとなる者なんですが、4月に受ける基本情報試験の言語をどれにしようか迷っています。
文型なもので簡単といわれているCOBOLかCASLUにしようと思っているのですが、やはり実務で使えるCOBOLの方がいいでしょうか?
ご意見お願いします。

154 :153:2006/11/09(木) 16:00:14
それとも需要の多いJavaにした方がいいのか・・・ものすごく悩みます。

155 :仕様書無しさん:2006/11/09(木) 16:43:21
>>153
何も知らずにコボルコボルと言ってると、ほんとにコボラになっちゃうぞ。
素直にCかJavaにしときなさい。

#問題はJavaの方が随分簡単だった気がする。

156 :仕様書無しさん:2006/11/09(木) 21:44:20
>>153
受かるのなら、何を選択しても良い。
言語問題などにこだわるな。

言語問題を全部落としてでも、他の問題の正解率を上げた方が効率的。


157 :仕様書無しさん:2006/11/09(木) 22:08:23
オープン系はやめた方がいいよ。

基幹系の方が将来性あるからね。

COBOLの方が将来性あるよ。

158 :仕様書無しさん:2006/11/10(金) 01:13:47
あと40年仕事があれば何でもいいよ

159 :仕様書無しさん:2006/11/11(土) 18:38:09
あと40年もCOBOLの仕事を受注し続けるには、かなりの営業力が必要だ。

正直、最近のCOBOL案件は少ない。
メインフレームのCOBOL案件を発注するのは大手企業だけだ。
受注さえすればウハウハだが、大手SIではないところが受注するのは至難の業。

オフコンのCOBOL案件はあるが、
オフコンでCOBOLシステムを残している企業は本業が苦しいので新システムに刷新する金がない企業だけだ。
当然、おいしい仕事は残っていない。

160 :仕様書無しさん:2006/11/11(土) 23:37:31
ホスト系はCOBOL、FORTRANとまったく違った文法、適用分野だったが、オープン系はJavaにしろ.NETにしろ、みんな同じような感じになってきたな。
組み込み系になると違ってくるけど、業務系ならJava、.net、Ruby、PHP、もうなんでもいんじゃね?

161 :仕様書無しさん:2006/11/11(土) 23:59:55
>>160
Ruby、PHP入れるあたりがダメっすよ。おぢさん。
受け売りも程々にね。

55 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)