COBOLとか談義 on Twitter

なにやら盛り上がっていた。

COBOLは使ったことないしおそらく今後使うことはないので言及はしない。ただもくもくとふぁぼるのみ。適当なタイミングでまとめる。

ということで途中経過をまとめた。

まとめ方法

議論と関係ないエントリをどんどんクリックして隠していくところまでは↓
Twitter議事録 - 文殊堂
その後実行するscriptは↓
9626’s gists · GitHub
クリップボードにコピーされるのではてダにペースト。

まとめ本文

nagise 新システムで敢えてCOBOLか。ビジネスロジックって要は誰が書いても同じ部分のことだろうなぁ http://slashdot.jp/developers/article.pl?sid=08/09/09/0252214
nagise 要するに、順次・反復・分岐という情報処理の基礎部分だけでやれる簡単なお仕事という部分で、その辺ならCOBOLだろうがLLだろうが、なんだって対して変わらない
nakawankuma @nagise 生産性と、性能はだいぶ違いますよ
nagise 一番末端の部分の誰が書いても同じなんてところのためにCOBOLってのはちょっといただけない。システムの品質を決めるのはコード量的には少数になる抽象部だ
nagise 自分が「ビジネスロジックを書くのはCOBOLでやらせるように」という指示でシステムを作るとしたら、Java6のスクリプティングAPICOBOLを呼べないか検討する
uokumura http://slashdot.jp/developers/article.pl?sid=08/09/09/0252214COBOLを選択した理由は、部品化とシステム構成のシンプル化を実現しやすい」COBOLが部品化しやすいってどういう意味だろう。
uokumura COBOLの方がノウハウとかが完成しててCOBOLの時代の方がより「定義されたプロセス」で回しやすかった、とかいう話は効くのだけれど、知らないのでイメージがわかない。
nagise @uokumura 採用にあたってどのような検討をしたのか詳しく聞きたいところですよね
nakawankuma @nagise レビューアがそれしかよめないとかでしょ
uokumura @nagise まぁ間違いでもないと思うんですけどね。銀行系の業務知識を持った人はCOBOLerが圧倒的多数な訳で、じゃあ言語はCOBOLにした方が業務知識の豊富な人が得やすいですし、構造化するならJavaよりCOBOLですし…
nagise @nakawankuma COBOLは化石って言うのに「ビジネスに携わる技術者として見識を疑う」とか言うならどういう見識でCOBOLを採用したのか気になるじゃないですか
nakawankuma @nagise 文脈が読めない! Cobolは化石じゃないし、ばりばり現行技術だと思いますよ
uokumura @nagise でもJavaで構造化しようとするから変な事になる、という認識がなくて、「JavaCOBOLより部品化しにくい」と勘違いしてそうな臭いがプンプン…
nagise @nakawankuma 参照元記事を読んでくださいw
nagise @uokumura や、Javaでも構造化はしないといかんのですけど、構造化以上をしちゃいかんと言われるとツライですね。OOPは構造化の上に成り立っている。
nakawankuma @nagise あー、なるほど。私も見識を疑いますよ?
nagise @uokumura Javaで構造化まででOOPを使わないという条件だと変なことになるのはそうだと思うけど。staticだけでプログラムなんてしたくないw
nagise @nakawankuma COBOLというだけで否定するなら見識を疑っていいですけど、COBOLを積極的に推す理由もわかりませんが。
repeatedly @uokumura 結局の所,システム作れる人の大半がCOBOLerという,昔のライブラリがあるからFORTLAN使っている,というのと余り違いがない気がします.
uokumura @nagise 言葉足らずでした^^; いいたかったのはそういう事です > Javaで構造化まで
uokumura でもJavaで機能分割、とか多いですよねー。「JavaよりCOBOLの方が良い」ていう人は、ほとんど機能分割しかした事がない人で…
nakawankuma @nagise 推す分野はやっぱりあって。またCOBOLしか動かない機械というのもあります。あとはコードコンバートの成功率が高いのは認めざるを得ない
repeatedly ま,COBOLがどれだけ業務系のシステムが組みやすいのか知らないので,単なる想像.ただ,COBOLJavaとか他の言語を同レベルで作れる人ってのは想像しにくいw
uokumura @repeatedly あ!それうまい対比ですね!>昔のライブラリがあるからFORTLAN使っている,というのと余り違いがない。それはそう思います。構築だけなら当たりでも、10年後にどれだけ現役のCOBOLerが残っているか考えると…
repeatedly 最近COBOLやる人が少ないから,逆にCOBOLが出来ると実は仕事に困らない,というのは聞いたことがある.
nagise 現代の言語を舐めるなと言いたい。だけど、それでも欠点はいろいろあるわけで未来の言語に期待をする。過去の言語は歴史として語られれば十分じゃんと思う
nagise @nakawankuma 特定の条件下でCOBOLが一番だろうという状態になることがあろう、というのは一切否定する気はないですが、この件では疑わしく思います。
uokumura @oredoco 固定長のレコードってDBとのマッチング良いでしょうねー。COBOLのレコードに入れば確実にDBにも入る訳で…
nagise この案件にはCOBOLが最適なんだという説得力ある言説があればいいのですけども。
pascalmk COBOLって言語仕様以上に文化が悪いって言う印象なんだけど、言語仕様的にはどうなんだろう。実行速度は速いらしいけど
pascalmk HelloWorldを書いた感じだと、結構冗長というのがイメージ。あと、PIC(ryで型宣言をするから何型かわからない。
ogochan @uokumura 既に定まった業務をやる時には、COBOLは書きやすいんだよ。伝票とか帳表とか決まってるものは多いから。
ogochan なんだかんだ言って、世の中の大半の仕事は定型業務
repeatedly COBOLって最新の規格ではオブジェクト指向をサポートしてるのか…
uokumura @ogochan 事務処理とか会計って基本ルールに従って転記転記、ですもんね。それをそのまま移すには向いてる、と言うのはイメージ湧きます。
nagise 固定長レコードで構成されたデータを扱うことにかけてはCOBOLは扱いやすいとは思う
repeatedly ただ一つ言えるのは,もう少しデザインに凝ってもいい気がする. http://www.coboler.com/
nagise ただ、ストレージ部分の抽象化で、つまるところRBDMSのようなモノによって陳腐化した感じ
ogochan @uokumura 大勢の人を動かす業務って、業務設計の時点で定型化されているしね。
nakawankuma @nagise メインフレームJavaはないでしょ。部分的にもサブシステム単位とかで切り出せとかおもうけど、子会社社員のモチベーションとかもじつは重要な要素だったりね
uokumura そうか、つまり伝票と転記のモデルに落とせて、RDBにデータを貯めれるシステムなら、COBOLが向いてるのか。…結構世のたいがいのシステムはCOBOLの方が良いんじゃないか?
repeatedly 事務処理に特化した故の冗長さとシンプルさでCOBOLが使われてると思うのだけど,オブジェクト指向を採用する意味はあったのか?
nagise Javaとかで1レコードがXXバイトで、先頭からYバイトがZZを表現していて、ってのはやりにくい。
ogochan @uokumura 世の中の動きが早くなって、特にUIの絡むところは柔軟性が求められるから、昔のようなわけには行かないってのもまた事実です。
nagise @nakawankuma メインフレームJavaとか普通みたいですよ。わりと。
darc0113 東京海上日動COBOLの話、もしかしたら前職の会社が関わってたやつじゃなかろうか……。スラド見て思うのは、未だに新卒の半分にCOBOL教育をほどこしている企業というのはそんなに異質なのかと小一時間……でも自分もあそこに回されたくないと思ったもんなぁ……。
norahmodel @darc0113 いやそんな事無いだろ。高校の情報処理科とか未だに第一言語COBOLだったりするし。.NETで走るCOBOL何ていうのも存在するくらいだからなー
darc0113 @buzztter COBOLがばずったw
darc0113 TwitterでもCOBOL=過去の言語、扱いが主流だなぁhttp://buzztter.com/ja/k/cobol
repeatedly というか,COBOLの冗長さを削った新しいCOBOLが出来なかったのは何でなんだろう?皆満足しているってことなのかな.
nagise CORBAで接続とかもやったなぁ。
ogochan @darc0113 新しい仕様提案しようとしても、「どうせCOBOLerは使わないし」とか思うと萎えるのよね。と、仕様を作っている私が言ってみる。
uokumura Java使いのdisCOBOLって正確にはCOBOL汚染されたJavaの「COBOL的部分」をdisってるんだと思う。でJava批判も「COBOL汚染されたJava」の批判が多い気がする。
darc0113 @ogochan 前職も、COBOLなどの汎用機に回されるのは新しいことに興味のない、職業プログラマが大半でしたね……年配の人はどう思っているのやら。
uokumura @nakawankuma JavaneseになりきれないCOBOLerな人がJava批判をしてる時って、「JavaCOBOL汚染しにくい!COBOLの方がCOBOLだ!」て言ってるように聞こえます…
ogochan @darc0113 我々の頃は結構COBOLでもhackしてたんだけどなぁ。私はawkOOPな処理系とか作ってた。メインフレームの上でね。
uokumura http://tinyurl.com/5lyqln Javaのパッケージは「種類は異なるが、協調して動くものを同じパッケージに置いておく」物だと思ってたけど…あんまり一般的な認識じゃないのかなぁ。
repeatedly でもひげぽんさんによれば,言語の大統一理論で全てはLispに帰るらしいので,COBOLがどうとか言っても意味が無いww
ogochan メインフレームCOBOLを使って言語処理系とか作る時は、まずマクロアセンブラを使ってI/Oルーチンを作るのが最初だった。そうしないと使いにくい。
uokumura 「デフォルトスコープの可視範囲をパッケージ割りに反映させる。」ていうと違うけど。クラス図 or オブジェクト図を書いて、関連線で出来たクラスタがパッケージ、てイメージ。
keisuke_n 別にすぐ捨てろっていってるわけじゃないし、たぶん現状ではなかなか無理(に近い)のはわかってるから、なら何もしなくてもいいとはならないのじゃないかと思ってる
keisuke_n 私の要点はそこかな。
Horiuchi_H @uokumura 自分もそう思ってました。機能別に分けていましたが、一般的じゃなかったんですかねぇ? *Tw*
keisuke_n COBOLの一番よくないところはコピペ文化じゃないだろうか(ほらそこ笑わないw
uokumura でも「ヒエラルキー的分類をパッケージ割りに反映させる」のほうがよく見るなぁ。
nagise 使える設計パラダイムがどれだけあるか、使えるライブラリがどれだけあるかは気にするな
uokumura ヒエラルキーが継承階層という意味なら、完全に間違い。レイヤ毎にパッケージを切るのは、レイヤ毎に担当者が変わるなら有りかなぁ。
nagise @keisuke_n ところが、なんとコピペ率が高いソースが以外にも安定しているという論文が!
darc0113 こーいうWebサービスにいる人たちには、銀行・保険系の開発って異世界なのかなー。
darc0113 上流に行ければそれはそれで面白いだろうなー、とは思いますね……。そんじょそこらのWebサービスとは規模が比べ物にならないし。<金融系
pascalmk VBAは一番成功した4GLってイメージだけど、そもそもVBAを4GLと定義していいものか...
darc0113 あと、一旦Javaで書かれたプログラムを「パフォーマンスが悪いから」という理由でC++に書きかえる、というJava主流の世界から見たら卒倒もの(?)な事例もあったなー。
t_yano COBOL ソースのコピペ率はすごいよ。というかコピペ奨励されてるしな。 *Tw*
youkan Javaは作業者単価や要員確保の観点から、現場では重要な言語の一つです
youkan 言語的に古いのを引きずっているのもある意味長所
repeatedly とりあえずは @buzztterCOBOLが色々と載ったのでよしとするかww
heppoko COBOL 案件なんて、今でもそのへんにゴロゴロ転がってるでしょ。 *Tw*
heppoko 巨大なシステムのプラットフォーム選定なんて、顧客・SIer・ベンダの様々な(主に政治的な)思惑によって決まるのであって、そんな中でプログラミング言語論争しても不毛だと思うよ。 *Tw*
t_yano 念のためいっておくと、 COBOL は LL ですよ。 *Tw*
t_yano 後データの分割・マージ・ソート・転記が処理の中心、という世界では LL 度はかなり増す *Tw*
tarchan COBOLってコピペして項目調整して完了!というプログラムが多い気がする
t_yano 事務処理用 LL といっていいんじゃないの。だってメモリ管理不要、演算は十進演算。 *Tw*
shuyo @t_yano それは LL じゃなくて DSL では?w
t_yano なぜ転記に強いかというと、宣言部に長さ指定して構造を定義しておいて、バイト列を転記すると、定義した構造どおりの構造体として扱える。 *Tw*
keisuke_n COBOL動かすのにPower6は本当にいいCPUです。なにせ10進演算できますから(それだけかい
basyura 言語的に LL だとしても、環境的にはちがうよね。tinycobol ってお手軽なの?
t_yano あるプロトコルに沿った電文を受け取って転記するだけで、その瞬間から、電文をプロトコル規定どおりに各種変数に代入しまくったのと同じになる。 *Tw*
keisuke_n 確かに使いやすいか冗長でないかはともかく、LLの走りではあるかも
t_yano 金融系のプロトコルはオクテット長で定義されているのは COBOL で便利だからなんだろうきっと。 *Tw*
repeatedly 内の学科だとCOBOLのCもでてこないので,アンケートとったら半分以上の人はCOBOLを知らない気がしてきた.
repeatedly 結論:仕事に困ればJavaCOBOL
t_yano REDEFINES を使うと、同じ200バイト長のデータ構造を途中から多重定義できるという意外とキモい技もある。 *Tw*
t_yano あ、200バイトというのはあくまでサンプル。別に何バイトでもいいけど。まあ長さ違う構造を多重定義する場合は、みなさんおなじみの FILLER が登場です。 *Tw*
t_yano 浮動小数点誤差? BigDecimal なにそれ? お金の計算するんだから浮動小数点誤差なんて言語レベルでなくしてほしいよねー、というビジネス LL 。 *Tw*
t_yano あ、私は COBOL の仕事は請けるつもりはないですけどね。 *Tw*
keisuke_n @t_yano COBOL使えると、この前聞かれたばかりです:-)
basyura 事務処理用ってのはそういうことなのか > 浮動小数点誤差を言語レベルでなくす
keisuke_n COBOLやるときは、たぶんCOBOL用マクロ(テンプレート)作るだろうなw
ogochan COBOLの仕事か。コンサルとかSESなら受けてもいいけど、開発はやりたくないな。
repeatedly Object COBOL Mapper とか誰か作ってそう.ってこれ単なるトランスレータか…
t_yano ただまー COBOL は言語的には Perl よりも Ruby よりも簡単なんで、精密な批判をするために知っておいてもよいかとは思う。あービジネスに特化した言語だなーと思う。 *Tw*
keisuke_n 生のCOBOLコードはしこしこ書く。でも最初のベースはマクロで生成w
nagise Javaみたいな基幹言語よりは、何かに特化して設計された専用言語の方が、そのジャンルに関して言えば楽に決まってる
basyura 数値に対する10進数から2進数への基数変換時に計算誤差の発生しない2進化10進数による数値型(固定小数点数)を用いることができる
keisuke_n トランスレータとかはまぁ書かないだろうなぁ。めんどくさすぎw
ogochan @t_yano いや、全仕様を把握するのは大変ですよ。最新のCOBOL仕様書のドラフトは、英語で1000ページ近いです。
keisuke_n でもいかんせん古臭いのは否めないよね。今だったら(ryとかいっぱいある。
keisuke_n COBOL大人気だなw
t_yano @ogochan 死ねる ww >1000 ページ *Tw*
t_yano オライリーあたりから二分冊で「プログラミング COBOL 」とか出そうだ。 *Tw*
keisuke_n ちなみにEclipseCOBOL対応してるの?
ogochan 1000ページの仕様書は、運ぶだけで大変。とは言え、pdfをノートPCに入れてだと、読むのが大変。どうしようもない。
keisuke_n あるのか、さすが腐っても鯛 > COBOL for Eclipse plug-in
ogochan ちなみに、最新のSQLは2000ページもあるんで、翻訳するのは諦めたそうです。まぁ2000ページのほとんどはサンプルコードらしいんだけど。
basyura だれか COBOL で LT しないかなぁ
ogochan でも、それだけでっかい仕様を作っても、COBOLerは使ってくれないという罠。場所によってはいまだ74規格のままのコードとかありそうだ...
ogochan そーいやー私はCOBOLで金の計算ってほとんど書いてないな。計算って、主に時間ばかりだった。あとは普通にデータ処理。