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のスクリプティングAPIでCOBOLを呼べないか検討する |
uokumura | http://slashdot.jp/developers/article.pl?sid=08/09/09/0252214「COBOLを選択した理由は、部品化とシステム構成のシンプル化を実現しやすい」COBOLが部品化しやすいってどういう意味だろう。 |
uokumura | COBOLの方がノウハウとかが完成しててCOBOLの時代の方がより「定義されたプロセス」で回しやすかった、とかいう話は効くのだけれど、知らないのでイメージがわかない。 |
nagise | @uokumura 採用にあたってどのような検討をしたのか詳しく聞きたいところですよね |
nakawankuma | @nagise レビューアがそれしかよめないとかでしょ |
uokumura | @nagise まぁ間違いでもないと思うんですけどね。銀行系の業務知識を持った人はCOBOLerが圧倒的多数な訳で、じゃあ言語はCOBOLにした方が業務知識の豊富な人が得やすいですし、構造化するならJavaよりCOBOLですし… |
nagise | @nakawankuma COBOLは化石って言うのに「ビジネスに携わる技術者として見識を疑う」とか言うならどういう見識でCOBOLを採用したのか気になるじゃないですか |
nakawankuma | @nagise 文脈が読めない! Cobolは化石じゃないし、ばりばり現行技術だと思いますよ |
uokumura | @nagise でもJavaで構造化しようとするから変な事になる、という認識がなくて、「JavaはCOBOLより部品化しにくい」と勘違いしてそうな臭いがプンプン… |
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がどれだけ業務系のシステムが組みやすいのか知らないので,単なる想像.ただ,COBOLとJavaとか他の言語を同レベルで作れる人ってのは想像しにくい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批判をしてる時って、「JavaはCOBOL汚染しにくい!COBOLの方がCOBOLだ!」て言ってるように聞こえます… |
ogochan | @darc0113 我々の頃は結構COBOLでもhackしてたんだけどなぁ。私はawkやOOPな処理系とか作ってた。メインフレームの上でね。 |
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 | とりあえずは @buzztter にCOBOLが色々と載ったのでよしとするか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 | 結論:仕事に困ればJavaとCOBOL |
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 | ちなみにEclipseはCOBOL対応してるの? |
ogochan | 1000ページの仕様書は、運ぶだけで大変。とは言え、pdfをノートPCに入れてだと、読むのが大変。どうしようもない。 |
keisuke_n | あるのか、さすが腐っても鯛 > COBOL for Eclipse plug-in |
ogochan | ちなみに、最新のSQLは2000ページもあるんで、翻訳するのは諦めたそうです。まぁ2000ページのほとんどはサンプルコードらしいんだけど。 |
basyura | だれか COBOL で LT しないかなぁ |
ogochan | でも、それだけでっかい仕様を作っても、COBOLerは使ってくれないという罠。場所によってはいまだ74規格のままのコードとかありそうだ... |
ogochan | そーいやー私はCOBOLで金の計算ってほとんど書いてないな。計算って、主に時間ばかりだった。あとは普通にデータ処理。 |