【時事】生越昌己についてあなたの意見ください 10

1 ：login:Penguin ：04/05/04 15:20 ID:acjpuKsK

ちょっと頭おかしい人ですよね？
あほですか？
自称ネットの第一人者みたいなこといってるようなんですけど、
本当ですか？
でもパソコン好きなだけのあほみたいにみえるんですけど。
どう？すごい人？
技術でいうならあんな人どこにでもいますよね？
もしかしてこれってタブーですか？
日コンとかLinux協会とかそれっぽい名前をつけてるから
コンピュータ音痴なマスコミが
その世界の第一人者だと勘違いして取材したりするのではないしょうか？
顔もキモいし、死んで欲しいですよね。
だいたい、今時COBOLerですよ？ 化石です、粗大ゴミです。
愛が無いのは生まれつきです。

・・・などと罵倒しつつもおごちゃんと語らうスレです。

【おごちゃんの御尊影】
http://nc.nikkeibp.co.jp/jp/articles/interview/990510/ogoshi.gif
【おごちゃんのページ】
http://www.nurs.or.jp/~ogochan/

2 ：login:Penguin ：04/05/04 15:21 ID:UY2eZrfy

ふむ

3 ：login:Penguin ：04/05/04 15:22 ID:xBf/c5X9

お、再生されていた。もう止めるのかと思ったのだが．．．

4 ：login:Penguin ：04/05/04 15:23 ID:acjpuKsK

前スレ
【時事】生越昌己についてあなたの意見ください　９
http://pc3.2ch.net/test/read.cgi/linux/1077124382/
【時事】生越昌己についてあなたの意見ください　８
http://pc.2ch.net/test/read.cgi/linux/1066617022/
【時事】生越昌己についてあなたの意見ください　７
http://pc.2ch.net/test/read.cgi/linux/1054112909/
【時事】生越昌己についてあなたの意見ください　６
http://pc.2ch.net/test/read.cgi/linux/1044493706/
【時事】生越昌己についてあなたの意見ください　５
http://pc.2ch.net/test/read.cgi/linux/1038403643/
【時事】生越昌己についてあなたの意見ください　４
http://pc.2ch.net/test/read.cgi/linux/1035132995/
【時事】生越昌己についてあなたの意見ください　３
http://pc.2ch.net/test/read.cgi/linux/1028282583/
【時事】生越昌己についてあなたの意見ください　２
http://pc.2ch.net/test/read.cgi/linux/1022397569/
生越昌己についてあなたの意見ください
http://pc.2ch.net/test/read.cgi/linux/985427152/

5 ：login:Penguin ：04/05/04 15:42 ID:+OfeJofX

で、やっぱり、COBOLがOOP化しても、今のところ実行時型情報を
得る手段がないために、他の言語のようにexceptionsでは使えな
い、でしたね。

6 ：おご ◆yW.Ai2bcLY ：04/05/04 16:27 ID:TzP9JXkL

>>5
はぁ？
別に実行時型情報の取得と、例外処理は直接関係ないんでないかい？

ということとは別に、どうもアプリケーションの中で例外ってのはあまり好きではない。
使うと便利なことは少なくないけど、便利過ぎるが故に思考停止しがち。
「goto文が有害」というのも、そこで思考停止があるからなわけで、同じような問題をはらんでいると思うわけだな。

7 ：login:Penguin ：04/05/04 17:23 ID:7Rkj6WG5

>>6
使ったことある？　便利だよ。

8 ：login:Penguin ：04/05/04 17:25 ID:xr9+gfGN

>>7
まあ、標準クラスライブラリの仕様が決まっていない以上、議論しても
仕方ないでしょ。RTTIはexceptionsを実装するときに便利ですけれどね。

9 ：おご ◆yW.Ai2bcLY ：04/05/04 18:44 ID:TzP9JXkL

>>7
Rubyでいい加減なプログラムを書く時によく使ったよ。
いい加減だから、エラー処理を一々書く気も起きないから、全部例外ってことで済ませたり。

便利さを否定しないけど、便利過ぎるのがいけないのよ。

10 ：おご ◆yW.Ai2bcLY ：04/05/04 18:45 ID:TzP9JXkL

>>8
COBOLはAPIに頼らない言語だから、標準クラスライブラリみたいなものは作られないんじゃないかな。
COBOLには標準ライブラリすらないんだから。

その分処理系が頑張っていろいろやってくれるというのが、「COBOLらしさ」ね。

11 ：login:Penguin ：04/05/04 18:57 ID:1VDKTun9

新スレ乙

12 ：一応はっておく ：04/05/04 19:20 ID:9MZxXPof

＿＿＿＿　　　　　 ＿＿＿＿＿＿＿＿　　　　　　　　　　　　 ＿＿＿＿＿＿＿＿
|書き込む|　名前：|　　　　　　　　　　　 |　E-mail(省略可)：　|sage 　 　 　 　　　　|
￣￣￣￣　　　　　 ￣￣￣￣￣￣￣￣　　　　 　　　　　　。　￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　　　　　　　　　　　　∧_∧＿_ ／　　 ／￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　　　　　　　　　　 ／(*ﾟ−ﾟ)つ.／＼＜.　ここに「sage」(半角）と
　　　　　　　　　　　　　　　　　　　　　　　／|￣∪￣￣|＼／.　.|　入れるとスレがあがらないの。
　　　　　　　　　　　　　　　　　　　　　　 　　|＿＿＿＿|／　　　|　そうするとﾏﾀｰﾘできるの。
　　　　　　　　　　 　　　　　　　　　　　　　　 ,,,,∪∪,,, ,,　　　　　＼＿＿＿＿＿＿＿＿＿＿＿

13 ：login:Penguin ：04/05/05 00:01 ID:QzF34Ig6

>>9
Rubyはいい言語ですね。Pythonぐらいを駆逐してもいいと思うのだ
けれど、日本発、世界標準は難しいかな。Eiffelみたいにならなけ
ればいいのですがね。

Event-driven Prog.では、OOPとExceptionsでまとめるのがやっぱり
きれいですよ。Error handlingとはちょっと違う。

14 ：login:Penguin ：04/05/05 00:09 ID:KDD9HcvG

>>10
COBOLで、GUIを書くわけでもないし、DBを呼び出すわけでもないと
いうことですか。これは、CのLib.がやってくれる。
結局 COBOL'74からプログラマの考え方は変わっていないし、COBOL
consortiumも、現行プログラムの維持と書き換えが終了するまでの
お仕事じゃないですか？

15 ：おご ◆yW.Ai2bcLY ：04/05/05 14:05 ID:fDkrlyW5

>>14
>COBOLで、GUIを書くわけでもないし、DBを呼び出すわけでもない
COBOLの場合、それは処理系の仕事ということになっているわけ。
Javaの場合は、それはクラスライブラリの仕事だということになっているだけ。
JavaやCはミドルウェアの機能を直接プログラムからAPIを通じて使い、COBOLはプログラムの外でいい塩梅にやってくれる。
ただそれだけのこと。

>結局 COBOL'74からプログラマの考え方は変わっていない
その論理で言えば、プログラマの考え方なんて、EDSACの時から変わってないとも言えるぞ。

別の見方をすると、変わればいいかと言えばそうとも限らないわけよ。
新しい機能がつくのはいいけど、根本のところがコロコロ変わるようなものが、エンドユーザに信用されるわけがない。
だから4GLは便利なのにCOBOLを駆逐できなかったし、今はJavaがそうだ。
1企業の製品なんて、いろんな都合で変化してしまうもの。いつベンダの都合で根本が変わるかドキドキしながら使うのは、辛いものだ。
この辺の観点が、エンドユーザとコンピュータ屋では相容れないところだな。

16 ：login:Penguin ：04/05/05 15:35 ID:bbHRzRmm

>>15
> JavaやCはミドルウェアの機能を直接プログラムからAPIを通じて
> 使い、COBOLはプログラムの外でいい塩梅にやってくれる。
GUIもDBもいじれないから、Cで書かれたMiddle ware, external Lib.
の山になってしまう。COBOLの優れた利点である書式付き出力もGUI
では意味がない。古くからあったCOBOLのコードを著作権も気にせず、
流用する以外、COBOLを使う利点はないと思うがね。R言語をCの計算
ライブラリで使うっていう意義はそれなりに分かるが、私ならそろそ
ろCOBOLに限界を感じるけれどね。

> 別の見方をすると、変わればいいかと言えばそうとも限らないわ
> けよ。
> 新しい機能がつくのはいいけど、根本のところがコロコロ変わる
> ようなものが、エンドユーザに信用されるわけがない。
MS-DOSか、LinuxのCGIで開発を行うのなら、COBOLの利点は発揮され
ると思う。環境が変わっているのだから、プログラミング言語が変
わるのは当然だと思うけれどね。

まあ、５年後を見ろ、と言うことになるんだろうけれど、ODBCやWin
をサポートしろというクライアントの意見が通るように、COBOLをや
めてくれという意見が出れば、どうするの？

17 ：おご ◆yW.Ai2bcLY ：04/05/05 15:48 ID:fDkrlyW5

>>16
>COBOLの優れた利点である書式付き出力
別にどうってことのない機能だと思うけど。Cだってライブラリ書けば同じことできるのだし。
その程度を「優れた」とか思う認識ではCOBOLが良いとも悪いとも言う資格なし。

COBOLの最大の利点は、コンピュータのことをあまり知らなくてプログラムが書けるということ。人間の都合だけでプログラムすることが許されるということ。それでいて効率がそう悪くないこと。

>COBOLをやめてくれという意見が出れば、どうするの？
1時間もあれば全部Cに変換できるから、「COBOLをやめてくれ」という意見そのものがナンセンスだと思うが。
Cから見ればOpenCOBOLは単なる「高機能CPP」に過ぎんのだよ。

お前が専門学校でやっとこさ覚えた程度のCOBOLでCOBOLを語るなよ。

18 ：login:Penguin ：04/05/05 16:22 ID:rtKLIIPa

>>17
Open COBOLが単なるpreprocessorだということは承知している。
じゃあ、公式にCでCVSを使って公表してくれよ。その方がこの世
界への貢献度は高いと思うがね。お前もCOBOL批判に飽き飽きして
いると思って言ってやっているんだがね。

19 ：login:Penguin ：04/05/05 16:31 ID:VAXLr2sP

>>18
そうそう、CでCVSを公表するのが当たり前だろ。
COBOLチームは孤立しつつあるんだろ？　ご託を並べる前に、やるべきことをやれ。

20 ：おご ◆yW.Ai2bcLY ：04/05/05 16:43 ID:fDkrlyW5

>>19
繋ぎかえて煽りか。御苦労様。

なるべく高レベルの言語で公開するのは当然のことだろ。
gccがgasから見ればプリプロセッサに過ぎんからと言ってgasのコードでプログラムを公開する馬鹿はいないだろ。

その程度のこともわからん馬鹿がわかったようなことを言うなよ。

21 ：おご ◆yW.Ai2bcLY ：04/05/05 16:46 ID:fDkrlyW5

しかし、/.-Jでも２ちゃんでもそうだが、匿名で偉そうに言う奴ほど、中身が間抜けなんだよなぁ。
そんなに偉いんだったら実名晒してもいいだろうと思うんだが、間抜けがわかってるからできないんだろうな。まぁ自覚があるからかわいいもんだ。

中身が取るに足りない間抜けだから、偉そうにしたいんだろ？ でもそれがわかってるから実名がさらせないんだろ？

22 ：login:Penguin ：04/05/05 17:05 ID:oTORaS+s

woodyでは、Open COBOLすらcompileできない事実にはどう答えるのかな？

23 ：おご ◆yW.Ai2bcLY ：04/05/05 17:06 ID:fDkrlyW5

>>22
「君が頭悪いだけだよ」と答えますが。

24 ：login:Penguin ：04/05/05 17:26 ID:wpxSTu6l

>>21
実名かどうかは、本人の自由じゃない？　自分から実名を晒して、攻撃されている
のを、相手に実名を言えっていうのは、バカだと思うけれど。

25 ：おご ◆yW.Ai2bcLY ：04/05/05 17:43 ID:fDkrlyW5

>>24
だからそんなつもりで言ってない。

ただ、なんで匿名だと偉そうに間抜けなことが言えるかなぁと。
実名の時には同じ攻撃的になるのでも、もうちょっと調べたり考えてからするだろうに。
単なる荒し煽りの類だったら、別にガス抜きにいいだろうと思うのだけど、「偉そうに間抜けなことを言う」のが、なんかイタいなーと。

26 ：クンクン（hanajan係） ：04/05/05 20:46 ID:gY1JtPZL

早速、新しいスレがたっているわね〜。。。
ワタシも、クンクンの着せ替え人形作っちゃた。。。
Ｙ！のＩＤは内緒よ。。。

http://www.hanajan.com/cgi-bin/nextbbs.cgi

クククのクーン。。。

27 ：login:Penguin ：04/05/05 22:10 ID:LIbcviMJ

>>22
./configureと、makeのところで何か所か止まると思うけれど、それぞれ、
GNUのツールを入れるとちゃんとインストールできるよ。そのぐらいかな。
地方公費のためにリコンパイルするつもりかな？

28 ：login:Penguin ：04/05/05 22:13 ID:+gaSQyIH

一度、おごさんに聞きたかったんだけれど、ＮＥＣがサポートしている
商用ソフトのOpenCOBOLと、フリーのOpen COBOLって関係があるの？

29 ：おご ◆yW.Ai2bcLY ：04/05/05 22:44 ID:fDkrlyW5

>>27
IDがlibcに見えるぞ。

>>28
関係ないよ。

なので、GnuCOBOLにしようということで、gcc frontendの作業をしてたはず。

30 ：login:Penguin ：04/05/05 23:16 ID:LP06Ncqb

>>29
商標登録していなかったのですか、紛らわしいですね。GNUのプロジェクトとして
は古くから、"COBOB for GCC"があったはず。まあ、toolは多い方がいいですが。

31 ：login:Penguin ：04/05/05 23:20 ID:dy/0Rrl5

>>27
確かにrecompile面倒だね。ツールをまず集めて、きれいに稼働するか
チェックして、ディレクトリを指定通りに展開していないとうまく行か
ない。連休中にocbcが吐き出すソースを見ようと思ったけれど、面倒だ
から止めた。

32 ：login:Penguin ：04/05/06 02:32 ID:g1x9rgvv

>>31
結局、Naclが持っているツールを全部使わないとできないようにできているんだよ。
rubyまで登場するのはなぜなんだろうねぇ。理屈はなんとでも付けるんだろうけれ
ど。１つの言語で作っておけば、開発効率も補修も簡単だろうに。

33 ：login:Penguin ：04/05/06 02:47 ID:XvXhyC9r

>32

漏れは、ogo批判派だが、スクリプト言語の採用自体は擁護するよ。
perlであろうがrubyであろうが、
マスタデータの加工〜＞DB登録なんていうプリミティブな動作は
その方が効率がいい。

で、perlよりはrubyの方が保守性は高い（言語としては、これからだが
ソースの保守性は明らかにrubyの方が高くしやすい）から
採用したと言われても、合意する。

何でも反対しているわけでは無いのだ。
反対のための反対にならないように。

DB構造に対しては、言いたいことは山とあるが、
ogoは、何でも「正規化厨」で逃げるからなぁ。。知らないことは
知らないと言えないのが最大の欠点だろう。

無知の知を得るのは、無理だろうね

34 ：おご ◆yW.Ai2bcLY ：04/05/06 10:57 ID:NtBe94rC

>>30
cobol for gccがイマイチなんで、cobol for gccの作者と連絡を取ってGnuCOBOLを作るって話になったんだよ。

35 ：おご ◆yW.Ai2bcLY ：04/05/06 10:59 ID:NtBe94rC

>>32
1つの言語しか知らないのか。かわいそうに。

って実は私も一つの言語でやるのが好きっつーか、あんまりスクリプト言語は好きではないのよ。
でも、最近は普通にLinux入れると、それこそ山のように言語処理系が入って来るんで、いまさら抵抗しても無駄だとさとったよ。
ちょっと前までJavaなものを毛嫌いしてたんだけど、XMLなツールとかJavaを避けると急に選択肢減るんで、これもしょうがなく使うようになった。

36 ：おご ◆yW.Ai2bcLY ：04/05/06 11:03 ID:NtBe94rC

>>33
現在のDB設計そのものは私の手の届かない世界だから私に言ってもムダなだけ。

昔々、某社のDBMSの実装の仕事してたから、正規化の意義とか散々教えられて来たよ。だから、正規化が無意味と言う気はない。
実務やってて、正規化の意味がわかってて、正規化テーブルがうまく操作できる環境だったら、正規化はしたくなるものだろうと思うよ。
ただ、COBOLでISAMの延長で見ちゃうと正規化すると面倒になるから、COBOLerはあまりやりたがらないってだけのこと。

37 ：login:Penguin ：04/05/06 12:24 ID:XvXhyC9r

>36
> ただ、COBOLでISAMの延長で見ちゃうと正規化すると面倒になるから、COBOLerはあまりやりたがらないってだけのこと。

その根本のところで、意見が食い違っているまま平行線。
これ以上言っても無駄だろうけどね。

＞XMLなツールとかJavaを避けると急に選択肢減るんで

XMLとDBとのマッピングは面倒だけどなぁ。Javaとの相性もいいとは言えない。
ようやく最近になって、まともに使えるようになってきたものの。

漏れはRelax派。

38 ：おご ◆yW.Ai2bcLY ：04/05/06 15:22 ID:NtBe94rC

>>37
RDBをISAMの切り口で見たら、正規化しちゃうと「いちいち読まなきゃやってらんない」ことになるからね。面倒だよ。
# joinはISAMにはないことに注意

>XMLとDBとのマッピングは面倒だけどなぁ。
わけあっていろいろやっているんだけど、あんまり楽なものはないね。
作るのもいいんだけど、XPathとかとの親和性とか考えるといろいろ工夫が必要になるし。

まぁXMLを自分でいじくる時はゴリゴリとCで書いちゃうわけだが。
やっとlibxmlのDOMにもなれて来たんで、SAXで「俺DOM」を作らなくて済むようになったよ。

39 ：login:Penguin ：04/05/06 15:33 ID:XvXhyC9r

>38
> RDBをISAMの切り口で見たら、正規化しちゃうと「いちいち読まなきゃやってらんない」ことになるからね。面倒だよ。
> # joinはISAMにはないことに注

だから、根本的にRDB向きのデータ処理を、ISAM/COBOLでやろうと
していることが、、って水掛け論だな。

>> まぁXMLを自分でいじくる時はゴリゴリとCで書いちゃうわけだが。

規格が定まりきっていないMedXMLをベースシステムにしようと
するとなぁ。HL7の方は、ほぼ安定しているのだけど。
v3はまだか？コンソーシアムのリンクはおかしいままだし。

40 ：おご ◆yW.Ai2bcLY ：04/05/06 16:14 ID:NtBe94rC

>>39
>根本的にRDB向きのデータ処理を、ISAM/COBOLでやろうとしていることが
だからミドルウェアで頑張ってるじゃないか。
COBOLにISAMで見えるということと、正規化してあるということとは、分離可能だからね。
そのまま見せちゃってたからああなっただけで、もう平気になったからこれから正規化するさ。

>v3はまだか？コンソーシアムのリンクはおかしいままだし。
そーゆー話はORCAスレなり医療板なりでやってくれ。

41 ：login:Penguin ：04/05/06 19:22 ID:50IHbvfA

>>34
商標でＮＥＣと問題はないのか？

42 ：login:Penguin ：04/05/06 19:26 ID:50IHbvfA

>>33
rubyがwoodyの標準仕様であり、インストールと同時に使えるのなら問題はない
が、Perlと違って、別にインストールしなければいけないところに問題があると
思う。ruby自体は好きだが、フリーソフトのメンテ用になければならいものでは
ない。

43 ：login:Penguin ：04/05/06 19:28 ID:50IHbvfA

>>35
いろいろな言語を使うってのは、その言語の便利なところのみを使って
いるわけで、結局その言語のスキルが低いってことを言っているに過ぎ
ない。習得するより、つまみ食いってことになっているよ。

44 ：login:Penguin ：04/05/06 19:28 ID:XvXhyC9r

>42

？何を持って標準？？dpkgに正式に取り込まれていた筈だよ。
そうである限り、全て標準

Perlだってバージョン違いいくつもあるんだし、モジュールは
組み込まれないよ、それこそ「標準」では。

>41

商標でもめたら、「Ogochan COBOL」かいな（藁

45 ：login:Penguin ：04/05/06 19:31 ID:4DXx03F0

>>43
Debianにしか、インストールできないアプリを作っているのは、元々、
技術的レベルが低いということよ。発注者がバカなだけだよ。

46 ：login:Penguin ：04/05/06 19:34 ID:XvXhyC9r

>43

別に、つまみぐい悪くないと思うけど。
漏れも、１５年ぐらい前まではアセンブラとエディタだけで
色々書いたりもしたが、最後の５年ぐらいは高級言語と
マクロアセンブラを混ぜてつかってたよ。

言語仕様依存でお手軽プログラミングをやった
SmallTalkとか、、

逆に１つしか使わないって発想は、アマチュア的な考えだと思う。
（もちろん、結果的に１つなのは良いとして）
「納期」と「予算」の制約があるからね、現実には。

お客が望めば、それでお金出せば、統一言語で書くのも可だけど、
スクリプト５行のものを、Cでやったら高くつくよ（藁

47 ：おご ◆yW.Ai2bcLY ：04/05/06 19:35 ID:NtBe94rC

>>45
そこまで自分の低能が誇らしいのか。
ある意味凄い人だな... かこいいぞ。

>>44
>Perlだってバージョン違いいくつもあるんだし、モジュールは
>組み込まれないよ、
その辺が私は嫌いなわけなんだが、Cでも結局はそうなんで、あんまり気にしてもしょうがないなぁとも思う。

48 ：login:Penguin ：04/05/06 19:36 ID:XvXhyC9r

>45

う〜ん、そのセリフ、ボラクルなんかに言って欲しいなぁ。
M$でもいいけど（藁

現実には、どのLinuxにもインストールすることは可能。パッケージを
用意していないのは別として。。

ただ、もう少し親切に作ってくれても、、って気持ちは良くわかる。

＃これじゃ擁護派みたいだ。。あまりにアンチのレベルが低すぎるよ

49 ：login:Penguin ：04/05/06 19:40 ID:XvXhyC9r

>47
>Cでも結局はそうなんで、あんまり気にしてもしょうがないなぁとも思う。

お作法自体も変化しちゃったからなぁ。
昔は【是】だったものが、今じゃ【タコ】呼ばわりのコードに。。

現実には、目の前半年以内で安定しそうなもので作るしかないからなぁ

50 ：おご ◆yW.Ai2bcLY ：04/05/06 19:46 ID:NtBe94rC

>>46
>逆に１つしか使わないって発想は、アマチュア的な考えだと思う。
言語をやっと1つ覚えただけの人はその傾向が強いかと。
件の人はCだCだと言ってるんで、Cが書けるのがよほど嬉しいのでしょう。

私はCOBOLで書くようなプログラムはCで書きたくないなぁ。
MONTSUQIはいろんな言語に対応してるから、それぞれに同じようなプログラムを書いて試すんだけど、COBOLで書くのが楽なものはやっぱりCOBOLがいい。
いろいろCのためのマクロやら関数やら用意してやるんだけど、どうやってもあまり簡単じゃない。

昔、awkみたいなものをCOBOLで書いたけど、これはもう二度とやりたくないね。そんなプログラムはCの方が楽だ。
その時はCOBOLとFASP(アセンブラ)しか使えなかったので、しょうがなくCOBOLで書いたんだけどね。

まぁそんなふうに言語には得手不得手があるものなんだけど、だからと言って節操なく混ぜるのもどうかと思う。
寄せ集めて来たものをつなげるんだったらしょうがないけど、新しく書くのにいろいろつまみ食いみたいにするのは、あまりかっこよくないようにも思う。
必然性のある選択でそうなるのなら良いけど、既に使えるようにしてる言語でも大差なく書けることを、わざわざ新しい処理系をイントールまですのは、なんかねぇ。

51 ：おご ◆yW.Ai2bcLY ：04/05/06 19:50 ID:NtBe94rC

>>49
>昔は【是】だったものが、今じゃ【タコ】呼ばわりのコードに。。
昔はチマチマとメモリでもCPUでもケチって使って、効率良いコードにするのが良いとされていた。
でも今は「富豪プログラミング」とかで、メモリもCPUもガンガン使うのが良いとか言われてしまう。
どうしても私は貧乏ったらしいプログラムになってしまって、ちょっと恥ずかしい。
どうも「富豪の神髄」がわかってないらしい > 私

メモリはギリギリの大きさで使って、必要なら必要なだけ拡張するようなプログラムになっちゃうんだよね。

52 ：login:Penguin ：04/05/06 22:22 ID:XvXhyC9r

>51

昔は、アセンブラで、自己展開・自己書き換え型プログラムを作って
配布の際の通信コストを削減させることまでやってたよ。（遠い目）

今は、そんなコードは、「保守性皆無」「セキュリティホールの元凶」
「ウイルスもどき」呼ばわりされるんだろうなぁ。。

どうしてもx86系アセンブラ（レジスタ）になじめなくて、汎用レジスタが
使えるモトローラ系などに走ってたなぁ。
（それでもx86でバンク切り替えバンバンやるようなコードも書いていたが）

Cを使うようになったら少し楽になったが、エンディアンでバグったことが懐かしい
癖は怖いものだ

>メモリはギリギリの大きさで使って、必要なら必要なだけ拡張するようなプログラムになっちゃうんだよね。

その割りに、ORCAは、無意味にmallocしてないか？
自己矛盾。。

53 ：おご ◆yW.Ai2bcLY ：04/05/06 22:31 ID:NtBe94rC

>>52
>その割りに、ORCAは、無意味にmallocしてないか？
あんまりしてないよ。
最初にデータ構造分だけがーっと取って、あとは端末がつながる時に取るだけ。

がーっと取るのはアプリの定義体に従って取っているのであって、私が富豪にやってるわけじゃない。
matzには「アプリも他のコンポーネントも富豪にやってて、なんでおごちゃんだけがケチケチやるんだ」とか言われちゃったよ。
バランス取れってさ。

54 ：login:Penguin ：04/05/07 04:19 ID:4GZnI0CQ

>>9
例外処理は、OOプログラミングでエラー状況の把握が問題になった事から
編み出された処理系てな基本を踏まえて使うと、例外が良いとか、悪いとか
言う議論は、うまい例外処理の使い方に発展して、建設敵になると思う。
おごちゃんって、自動車の乗り心地を議論してる時に燃費の話をしたり、
高効率エンジン（燃費）の話してる時に、乗り心地の議論始めたりして、とても
胡散臭い。

55 ：login:Penguin ：04/05/07 10:02 ID:k4BylXVk

>>54
古いタイプのプログラマが、それでいいじゃないかと居直っているように見える。
そりゃ、N88BASICでも、アセンブラを呼び出せば何でもできるから、それから、
進歩は要らない。自分の時代を賛美しているだけの話だと思うな。

56 ：login:Penguin ：04/05/07 10:40 ID:aehUtnbR

>>50
あまりに常識的な意見にやや拍子抜け...

57 ：login:Penguin ：04/05/07 11:34 ID:/jogl/ko

>53

おいおい、今ですら無意味に取ってるのに、これ以上どうする気だよ。
Linux SWAP領域には制限があるんだぞ

ネットワークアプリでもスタンドアロンアプリでも無い中途半端な
仕様はさておき、、

58 ：おご ◆yW.Ai2bcLY ：04/05/07 12:49 ID:7ZdowZCx

>>54
>自動車の乗り心地を議論してる時に燃費の話をしたり、
>高効率エンジン（燃費）の話してる時に、乗り心地の議論始めたりして
乗れない車の話してもしょうがないもん。というだけだよ。

便利で有用なのは否定しないさ。
ただ、その便利で有用だってのは、gotoが便利で有用だってのに似てるってこと。
出来る限り例外に頼らないようにしておけば、例外処理しなきゃいけないところは限定されるから、そこでこそ使えばいい。
でもそーいった使い方をする時には、「なんでも型」ってのはあまり必要でないといってる。

gotoが他の制御構造に進化したように、例外もそうならないと、可読性や制御性に有害じゃないかと。

59 ：おご ◆yW.Ai2bcLY ：04/05/07 12:51 ID:7ZdowZCx

>>57
私の提供した機能をアプリケーションがどう使おうと私の知ったこっちゃない。
アプリが無駄に使っていると思うんだったら、私に言わずにちゃんとしたルートでアプリ開発に言え。

>Linux SWAP領域には制限があるんだぞ
へ？

60 ：login:Penguin ：04/05/07 13:41 ID:JLW5x7tJ

>>58
ogoちゃんの例外処理って、何に使っているの？　話がかみ合わないもの。

61 ：おご ◆yW.Ai2bcLY ：04/05/07 14:13 ID:7ZdowZCx

>>60
あーそれもそうだな。

それを言えばC以外の言語でプログラムすることが少ないから、あんまり例外のメリットやノウハウを言われてもピンと来ないのは確かだな。
使える言語でも例外に回すのが好きでないから、「もうだめ〜」な時にしか使わんので。

gotoもlongjumpも例外も、どうも「遠くで(遠くから)まとめて」ってのは、うっかり悲しいことをやってしまうので、極力使わんことにしてるのよ。
だから、「生越はgotoの使い方も知らん奴だ」というのと同じ意味で「生越は例外の使い方も知らん奴だ」でいいよ。ノウハウがある程使ってないし。

62 ：login:Penguin ：04/05/07 14:51 ID:TWVGT6c+

>>61
ogoちゃんの例外処理って、本当のdiv 0みたいな状況なのかもね。
OOPの例外処理は、型と情報を持ったobjectを任意に投げられるから、event-
handlerとして、使いやすいのよね。

63 ：おご ◆yW.Ai2bcLY ：04/05/07 15:02 ID:7ZdowZCx

例外も昔(たとえばBASICのON ERROR〜RESUME)とは随分違い、catch(あるいはその仲間)で発生する範囲を限定して、そこの中のだけ受けとるようになったのは、随分とマシになったことだと思う。
これは無節操なgotoから、setjump-longjumpくらいの進歩ではある。だから、うまく限定して使えばそう酷いことにはならないのだろう。

ところが、私のレガシーな頭では、例外ってのは「予定してないことが起きる」のが例外であって、予測のつくものは例外にするべきではないと思うわけ。だからgenericな型が必要になるというのは理解する。
でも、「例外は滅多に使うものじゃない」ということであれば、例外そのものの内容は予測つかなくても、起きた結果くらいは予想がつくわけだから、genericな型でなくても別に困らんじゃんと思うわけ。

でも、例外ってものに慣れてる人は、もっと積極的に例外を使うのではないかと思う。
あるいは型についてゆるい言語だったら、また別の考え方もできるだろうなとは思う。
なんだろうけど、長く例外ということを使わずにプログラマやって来たから、今さら「例外をうまく取り入れて」なんてのは、どうも考えるのが難しい。
これは時間的には逆になるけど、「gotoはなるべく使うな」という教育を受けて来た私が、今のような構造化制御構文のない言語でgotoを上手に使ったプログラムを書く頭を持ってないというのと似てる。
COBOLに「NEXT SENTENCE」という命令があるのだけど、これを上手に使う教育は受けてないし経験もあまりないから、そんな頭を持ってないというのと同じ。

* 「NEXT SENTENCE」は古い命令なんで、今時は使う人はいない(と思いたい)

例外を積極的に上手に使う方法があったら教えてくれ。

64 ：おご ◆yW.Ai2bcLY ：04/05/07 15:05 ID:7ZdowZCx

>>62
>本当のdiv 0みたいな状況
そうなのさ。その手のしか知らんのよ。

>event-handlerとして、使いやすいのよね。
ほー。目から鱗。例外はイベントかぁ。確かにそう考えるといいな。

65 ：login:Penguin ：04/05/07 15:16 ID:DzhWqENk

CUIが使いやすいアプリもある。入力が数字で、選択が数字なら、テンキーで
入力可能だ。文字入力のところだけは両手を使えばいい。ORCAなんて、COBOL
CUIなら一昔前のアプリとして納得はできるのだが...

66 ：login:Penguin ：04/05/07 15:31 ID:4GZnI0CQ

>>64
>>event-handlerとして、使いやすいのよね。
>ほー。目から鱗。例外はイベントかぁ。確かにそう考えるといいな。

＿｜￣｜○

虚脱してる人間が山のように居ると思う（ｗ
COBOLのOO化でみんなが欲しがってて無い機能なんやから
COBOLは言語仕様上イベントハンドラ的な部分が皆無で、だから
GUIにも弱い。

そもそも例外処理てのは、せっかくオブジェクト化カプセル化して
分離を目指してるのに、個々のオブジェクトのエラーなんかの状況
を連絡する機能が無いから、結局、オブジェクトのお腹に穴開けて、
状況聞いたり、オブジェクトから随時情報を受け取る必要が有って、
こんなじゃ、カプセル化してる意味無いやん。何とかならんか？
てなところから追加された仕様なんだから…

67 ：おご ◆yW.Ai2bcLY ：04/05/07 15:52 ID:7ZdowZCx

>>66
>COBOLは言語仕様上イベントハンドラ的な部分が皆無で、だから
>GUIにも弱い。
Cだってそうだと思うがなぁ。別にCだって例外はないけど、イベント処理は特に不自由なく書けるじゃん。

>そもそも例外処理てのは、せっかくオブジェクト化カプセル化して
>分離を目指してるのに、個々のオブジェクトのエラーなんかの状況
>を連絡する機能が無いから、
なら、なんで素直にイベントにしなかったのだろう？
もちろん私の思ってた「例外」もイベントの一種だから... ってのは納得するよ。
でも、イベントが例外の一種だというのは、「便法」としては素晴しいと思うけど、「そのためのものだ」というのには違和感があるのだよ。

とか思うのは、私が「何でも受け取り」ということに違和感を感じているからで、それがレガシーだと言われればそうですかと言うしかないけど。

68 ：おご ◆yW.Ai2bcLY ：04/05/07 15:56 ID:7ZdowZCx

>>66
おそらく言いたいのは、「イベントの内容が未知なものだ」という前提を持ったことが言いたいんだろうな。
Cとかで慣れちゃった頭には、そこに違和感を感じるわけで。
C(つか古めの言語)で書くイベントハンドラって、イベントの内容が既知だという前提で書くからね。

慣れとか文化とか頭(思考)の違いなんだろうな。
また勉強すべきことが増えたなぁ...

69 ：login:Penguin ：04/05/07 16:05 ID:4GZnI0CQ

>>67
＞とか思うのは、私が「何でも受け取り」ということに違和感を感じているからで、
＞それがレガシーだと言われればそうですかと言うしかないけど。

言う事ナス（ｗ

例外（非常に狭く考えるとエラー）をイベント的に処理しようって事で、
イベント処理とはまた違って…

おいらが>>66でCOBOLのイベントが弱い事と、例外処理導入の副産物として
イベントも強くなるかも？てな期待をごっちゃに書いたのが悪かったと思う。

＞イベントが例外の一種だというのは、「便法」としては素晴しいと思うけど、
＞「そのためのものだ」というのには違和感があるのだよ。
逆で、例外がイベントの一種で…

おごちゃんがCOBOL委員会の一員で、COBOLのOO化に口はさめるなら、
少し期待も有ったのだけど。


おごちゃん。OOに付いてはほとんど興味が無いのでしょうか？

70 ：login:Penguin ：04/05/07 16:08 ID:L/LZ54dj

>>66
> 虚脱してる人間が山のように居ると思う（ｗ
俺もその一人だ（笑）
そういう人たちが、COBOLのOOP化を進めようと言うのだから、まあ
構造体以上のものではないのだろうね。

Constructor内でのerrorとか例外処理でしかこなせない処理もある
から、event-handlerだけが目的ではないと思う。まあ、OOPと対局
にいる人なんだろうな。

71 ：login:Penguin ：04/05/07 16:09 ID:4GZnI0CQ

>>68
そう、それ、未知というか、何時どのオブジェクトが音を上げるか判らない。
てな状況でも、安全に扱えるのが例外処理の良いところで、

＞C(つか古めの言語)で書くイベントハンドラって、イベントの内容が既知だという前提で書くからね。
これがOOにとっては致命傷だったんで…

＞慣れとか文化とか頭(思考)の違いなんだろうな。
＞また勉強すべきことが増えたなぁ...
OOです。OOの文化なんでしよ…

72 ：おご ◆yW.Ai2bcLY ：04/05/07 16:31 ID:7ZdowZCx

>>69
>COBOLのOO化に口はさめるなら
それにはISOの委員にならないといかんのよね。
今のJISはISOをそのまま使うものなので。
JIS委員の仕事は、翻訳のチェックと訳語の決定くらいか。

>おごちゃん。OOに付いてはほとんど興味が無いのでしょうか？
COBOLのはね。
OOなCOBOLはずーっと昔(87年頃かな)にはいろいろやってたんだけど。

73 ：login:Penguin ：04/05/07 16:45 ID:ccyLPLYg

>>72
ってことは、OPASチームのやっていることは分かっていないと言うこと
だね。そのうち、ORCAもOOP化されていくだろうね。生産性と補修性は
勝てないだろう。

74 ：login:Penguin ：04/05/07 16:58 ID:4GZnI0CQ

>>72
＞>おごちゃん。OOに付いてはほとんど興味が無いのでしょうか？
＞COBOLのはね。

なんか、おごちゃんが痛くなってきた(；´Д⊂)
例外処理の議論は、COBOLがどうたらと言うレベルよりちょっと上
なんやけど…

言語をOO化するに当たって、例外処理＊的＊な仕掛けが必要で、
例外処理てな、C++でなじみの有る方法が有って、それをCOBOLに
もって来れないのかなぁ？なんて疑問から話が始まってると理解して
るんだけど。

おごちゃんは、OO言語扱ったことは有っても、OOでプログラミング
した事無いでしょ。

75 ：おご ◆yW.Ai2bcLY ：04/05/07 17:05 ID:7ZdowZCx

>>71
>未知というか、何時どのオブジェクトが音を上げるか判らない。
>てな状況でも、安全に扱える
そこで言う安全性を理解せぬではないけど、「わからない」という状況が納得が行かない。
もちろんカプセル化の意味とか理解した上でのことよ。

うまく継承された型の中の世界であれば、「わからないけどある程度わかってる」ということにできるので、特に問題は起きない。それはいい。
クラス階層を破壊しない範囲で使っている分には、下手くそなプログラムでなかったら問題は起きないだろう。
イベントハンドラとして使うというのでも、おそらくは継承された型の中でやるだろうから、「わからないけどある程度わかっている」ことが可能だから、下手くそな(以下略)

さて、ここに多重継承が絡んでいたり、想像のつかない型だったらどうなるのよ？
「想像のつかない型」と言っても、「一応継承関係はあるんだけど」という場合ね。全く無制限のことを考えるのは極論過ぎるだろうから、とりあえず考えない。
とか考えると、結局はある程度制限を受けた範囲でないとわけわかなことになるから、多少きつめの制限がないと困るのではないかと。

さて、COBOLの例外だけど、どうも本来の意味での例外が主眼みたいね。
そうはっきり書いてあるわけじゃないけど、そんな空気だ。

76 ：login:Penguin ：04/05/07 17:10 ID:4GZnI0CQ

>>75
＞さて、ここに多重継承が絡んでいたり、想像のつかない型だったらどうなるのよ？

だから例外処理が必要なんじゃない。

77 ：おご ◆yW.Ai2bcLY ：04/05/07 17:14 ID:7ZdowZCx

>>74
>言語をOO化するに当たって、例外処理＊的＊な仕掛けが必要で、
>例外処理てな、C++でなじみの有る方法が有って
んー。「例外」と「OO」と「genericな型」は可分な概念よ。
同時に持ってる言語が多いってだけのこと。

>COBOLがどうたらと言うレベルよりちょっと上
そうだよ。

78 ：login:Penguin ：04/05/07 17:15 ID:4GZnI0CQ

>>77
おごちゃんは、一応問題点を理解したと理解しますた。
議論しずらい人だなぁ（ｗ

79 ：おご ◆yW.Ai2bcLY ：04/05/07 17:16 ID:7ZdowZCx

>>76
うん。そうよ。
ってことで、例外な例外処理になってしまう。
まぁ同じ例外だからいいよね。って解決でしょ？

でも、そこで「ある程度想像可能な型」の範囲にしておけば、例外じゃなくてもいーじゃんと思っちゃうわけよ。

80 ：login:Penguin ：04/05/07 17:16 ID:bR9WkpFL

>>75
だから、RTTIなんじゃない（笑）

81 ：login:Penguin ：04/05/07 17:18 ID:bR9WkpFL

例外処理でobjectを投げられるとして、その中にsignal以上の情報を
入れておける訳じゃない。とすれば、例外処理の方が柔軟に実装がで
きるわけじゃないかな。

82 ：おご ◆yW.Ai2bcLY ：04/05/07 17:24 ID:7ZdowZCx

>>81
だから、柔軟だと(略)

便利なのは良いことなんだけどね。

83 ：login:Penguin ：04/05/07 17:25 ID:4GZnI0CQ

>>82
＞だから、柔軟だと(略)

だから、OODを（略）

84 ：login:Penguin ：04/05/07 17:31 ID:37wFiFKu

>>83
これは、肯定的な意見？　否定的な意見？

85 ：login:Penguin ：04/05/07 17:34 ID:4GZnI0CQ

>>84
否定的意見。
おごちゃんにはOODの概念がかなり無い。
と思う。

86 ：おご ◆yW.Ai2bcLY ：04/05/07 17:41 ID:7ZdowZCx

>>85
OOを銀の弾丸だと思って思考停止しちゃいかんと言ってるんだがなぁ。

カプセル化は確かにオブジェクトの中を深く見ることを避ける方法として有効だけど、それは思考停止のためではないのよ。
genericな型も深く見ることを避けるのに有効だけど、goto的危険性があるのよ。

87 ：login:Penguin ：04/05/07 17:42 ID:8ggqBmRX

>>85
どこかの先生の論文に、「COBOLから、VBに移行した人の中には、数年して、
COBOLに戻っていく人も多かった。」とある。VBでは、今でもOOPの真似事
しかできないんだよね。そこから、C++か、Javaへ移行できた人は別の世界
に行けたと思う。VBはDBのclientとして必要十分な環境だけれど、それだけ
なんだよねぇ。

88 ：login:Penguin ：04/05/07 17:48 ID:4GZnI0CQ

>>86
＞カプセル化は確かにオブジェクトの中を深く見ることを避ける方法として有効だけど、
＞それは思考停止のためではないのよ。
分かった風な事言っておきながら、

＞genericな型も深く見ることを避けるのに有効だけど、goto的危険性があるのよ。
直ぐそうやって無謀な使い方する人間を一般論化する。
汎化ー特化じゃなくて、一般論化だよね。

バランスを考えると、必要な機能でしょ。
gotoとして使うのは、OODの概念が無い人。
それを危惧して、そもそも例外処理なんて物は、
genericな型は、と言い出すのは暴論だよ。

プンプンヽ(`Д´)ﾉｳﾜｧｧﾝ!!

>>87
同感。

89 ：login:Penguin ：04/05/07 17:54 ID:TC11kO5o

>>88
自分でも理解していないことについて評論しようとすると、>>86のように
なるんだよ。「俺は、いつまで経っても構造化プログラミングのレベルだ、
それがどうした！」って言えばいいんじゃないの？

90 ：おご ◆yW.Ai2bcLY ：04/05/07 17:58 ID:7ZdowZCx

>>88
>直ぐそうやって無謀な使い方する人間を一般論化する。
危険性ってそんなところに潜んでるから。
自分の今まで出したバグを分析してごらんよ。

>gotoとして使うのは、OODの概念が無い人。
某所でさ、「今時の主婦の内職はHTMLとJava」とか言われちゃったんだよ。
OODの概念があってもなくても、言語の機能であったら使っちゃう人がいるんだよ。

とか思うから、ゆるい型の言語が好きでないし、Cの時はガチガチの型チェックさせちゃうんだよなぁ。

91 ：login:Penguin ：04/05/07 18:04 ID:4GZnI0CQ

>>90
もう、言ってる事が無茶苦茶だし、OOD的視点から議論したくないなら
もう、なに言っても無駄だし。
OOD的な設計を実装しずらい言語で幸せなら、それで幸せになれば良いし。

ただ、以上を踏まえない、おごちゃんの評価は的外れだよ。

92 ：login:Penguin ：04/05/07 18:13 ID:bAi/oCPa

>>90
反論せずに「知りません」でいいじゃない。無理な反論は、本当に支離滅裂だと
思う。

93 ：おご ◆yW.Ai2bcLY ：04/05/07 18:15 ID:7ZdowZCx

>>91
>OOD的視点から議論したくないなら
別にしたくないと言ってるわけじゃないよ。
ただ、「OODでちゃんとやってればうまく使えます」という類の議論がしたくないだけ。
ちゃんと使えば、たいていのものはちゃんと使えるのだから。

>OOD的な設計を実装しずらい言語
無茶を言うのはどっちやら。
OODとOOPは可分だよ。そもそも、genericな型がどうとかってのは、特定のOOPLの話であって、OODとは直接関係ない。
OOPな設計イコールOODではないことに注意。

「Javaなら」「Rubyなら」みたいな議論ならいいけど、OO一般の話をしたふりしながら特定の言語に縛られた方向の話にするからかみあわない。

94 ：login:Penguin ：04/05/07 18:21 ID:4GZnI0CQ

>>93
なんで頑張るの？（オレモナー）

＞無茶を言うのはどっちやら。
＞OODとOOPは可分だよ。そもそも、genericな型がどうとかってのは、
＞特定のOOPLの話であって、OODとは直接関係ない。
＞OOPな設計イコールOODではないことに注意。

だから、OOPを議論する時にOODの概念も必要だと言ってるんだよ。
ヽ(`Д´)ﾉｳﾜｧｧﾝ!!
OODの結果を実装しずらいOOPで充分なら、議論する意味が無い。
言語によらない設計を目指したOODの成果をどれほど素直に取り込めるかが
OOPの選択理由のひとつでも有るんだからね。

OOPの枠内だけで考えたいなら。>>91だよ。

95 ：login:Penguin ：04/05/07 18:31 ID:xII6X+0T

温故知新じゃに

96 ：おご ◆yW.Ai2bcLY ：04/05/07 18:43 ID:7ZdowZCx

>>94
今日はEDoMaEを大改造する予定だったんだが...

>OOPを議論する時にOODの概念も必要だと言ってるんだよ。
悪いがそれには同意できんから、ずっとかみ合わんよ。
だいたいOODなんてOOPより後にできてるってわかって言ってる？

>OODの結果を実装しずらいOOPで充分なら、議論する意味が無い。
これは私は永遠に議論する気はない。

これが特定の言語に縛られていると言うんだよ。
「JavaはOODから持って来るツールがいっぱいあって便利だね」ということには賛成するけど、それはJavaが偉いからでもOOPLだからでもないと思うので。

>言語によらない設計を目指したOODの成果をどれほど素直に取り込めるかが
>OOPの選択理由のひとつでも有るんだからね。
これならある程度はできるけど、そうだという人もいればそうでないって人もいるだろう。
私はむしろそういった細かいところにとらわれないで(自分でも言ってるじゃん「言語によらない設計を目指した」って)設計ができるという点がOODの魅力であり強力さだと思っているんでね。

97 ：おご ◆yW.Ai2bcLY ：04/05/07 18:45 ID:7ZdowZCx

>>96
読み返すと変なことを言ってるな。

>だいたいOODなんてOOPより後にできてるってわかって言ってる？
手法として確立された(「た」と言って良いのか？)のはOODの方が後だけど、まぁそれまでに漠然とあったのだろうとは思うよ。
でも、それは「OOPのための設計法」であって、今で言うところのOODとは随分違うことだよ。

98 ：login:Penguin ：04/05/07 19:10 ID:4GZnI0CQ

>>97
＞でも、それは「OOPのための設計法」であって、今で言うところのOODとは随分違うことだよ。

で、OODがOOPの為を脱皮したら、やっぱり例外処理とGeneric型は必要だね。
となって、OOPに逆移植された。OOPだけ見てたら分からなかった事。

時代は変わってるのに、また同じ歴史を繰り返すつもり？（ｗ

99 ：おご ◆yW.Ai2bcLY ：04/05/07 19:34 ID:7ZdowZCx

>>98
>OODがOOPの為を脱皮したら、やっぱり例外処理とGeneric型は必要だね。
はぁ？ 前半と後半は何の関係があるんだ？ OODにgenericな型がどう関係するんだ？
そーゆー細いことと無関係に(コンピュータからすら独立に)設計できるのがOODのいい点だろ。

>OOPに逆移植された。OOPだけ見てたら分からなかった事。
これも意味不明。
もうちぃとそれぞれの歴史と背景、他のOOPLのことを勉強してから来てくれよ。

私よりもわかってるかと期待して相手してたんだが、けっきょく腰砕けかい。
「イベントは例外」というところは目から鱗だったんだがなぁ。

100 ：おご ◆yW.Ai2bcLY ：04/05/07 20:05 ID:7ZdowZCx

いろいろ言われる前に「降参」しておくと、古い時代のパラダイムや言語に長く生きて来たもんだから、最新の言語や最新のパラダイムでガンガン書くのってのは、どうやっても若い連中にはかなわないよ。
「例外はイベント」みたいな発想は、「例外は例外的」という文化の中に長くいた私には出て来ない。
それは最初にも言ってるとおり。

101 ：login:Penguin ：04/05/07 21:31 ID:4GZnI0CQ

>>99
＞これも意味不明。
＞もうちぃとそれぞれの歴史と背景、他のOOPLのことを勉強してから来てくれよ。

こんな事書いてると、おごちゃん分かってるみたいじゃん（ｗ

102 ：おご ◆yW.Ai2bcLY ：04/05/07 21:59 ID:7ZdowZCx

>>101
その辺のことはね > わかってる
昔は言語ヲタだったのだし。

でも、そんなにバンバン使ってプログラムを書いてたわけじゃないから(ほとんどCだから)、OOPLの「使い方」とかはよーわからんのよ。
プログラミングテクニックとしてどう使うとかは、実のところわからん。
C++でモゲったプログラムとか公開してるけど、元が他人様のプログラムだから、あれでわかってるとは言えんから。

103 ：login:Penguin ：04/05/07 22:30 ID:hoWR7Jz1

まあ、知りたかったのは、ORCAがOOPLで書かれる可能性があるかどうかだった
わけだが、C++, Javaで書かれる可能性は担当者が変わらないうちは難しいと
いうことのようだったね。構造化するのが精一杯、COBOLから改変するのも難し
そうだ。
レセコンが書けるクラスライブラリができれば、これはこれで面白いと思った
のだが．．．

104 ：おご ◆yW.Ai2bcLY ：04/05/07 22:57 ID:7ZdowZCx

>>103
話を曲げスギ。
まぁなんだかんだ言ってケチがつけたいってことはよーわかった。
だいたい、アプリケーションは私は一切タッチしてないって何度言えばわかるのかね？

Javaで書かれる可能性は0ではないが、C++で書くことは絶対ないね。
とは言え、Javaが出る前は「ポストCOBOLはC++だ」なんて言ってた人もいたようだが。

さて、以下ORCAは表示しない単語に登録するんで、自動的にスルーだよ。

105 ：login:Penguin ：04/05/07 23:37 ID:PpTTN4Cd

ORCA
これでogoちゃんには見えないんだろう。まあ、OOPに関しては負けは見えていた
し、あまりからかうのは、かわいそうなので、本人が見えないところで書くこと
にした。ORCAは彼にとって、やっぱりtraumaなんだろうな。レセが書けるぐらい
のクラスライブラリを作れば、まあ、知的所有権を主張できて、それに対して、
億単位の収入があっただろうにな、まあ、残念ってことだね。

106 ：login:Penguin ：04/05/07 23:42 ID:88lJoOEQ

ORCA
C++も標準であることには間違いない。問題は動いているシステムは、
技術変革がない限り、新しく改変する必要がないってことだよ。2K
問題さえ乗り越えれば、同じシステムで動かしても問題のないシス
テムも多い。ただ、新しくシステムを作るときに古い道具を使う必要
があるかだね。新しくシステムを作るときこそ、新しい道具を使う
チャンスだというのに、戦略を間違えるというのはこういうことだ。

107 ：login:Penguin ：04/05/07 23:48 ID:3R1g6pn0

ORCA
３歳児ぐらいに、「かくれんぼ」をしようと言うと、自分の目をふさいで
座り込む子供がいるんだ。つまり、自分が目をつぶれば、他人から見られ
ないと思いこんじゃうわけだね。>>104はそういうことだよ。

108 ：login:Penguin ：04/05/08 00:32 ID:OLb9lsMZ

ORCA
ははははは。医者板から迷い込んできたが、なんだか面白いことやってるねえ。
ちょっとまぜて。

今月は初めてORCAでレセ提出だ。無理矢理事務員に使わせてるが使いにくいと
評判すこぶる悪いぞ。

さて、これもogoちゃんには見えないのか？

109 ：login:Penguin ：04/05/08 00:38 ID:Iu3nFKmQ

>>108
ORCA
具体的にどこが使いづらいのかな？　以前のレセと勝手が違うから？　設計の
センスが悪いから？　１か所でいいから、具体的にここって言うところが聞き
たいな。

110 ：login:Penguin ：04/05/08 00:39 ID:gTmwehqe

ORCA

＞アプリケーションはタッチしていない
と逃げているが、ミドルウェアの仕様でアプリケーション開発に
良い意味でも悪い意味でも枷がかかるということは認識していないのかな？（藁
言い訳になってないぞ。

汎用ミドルウェアになっていればまだしもね、将来性は無いよなぁ。
それこそ、COBOLの元プログラムを動かすために、無理矢理作ったんだろうがね

111 ：login:Penguin ：04/05/08 00:41 ID:Iu3nFKmQ

ORCA
> glclient ver 1.2.1
> Copyright (c) 1998-1999 Masami Ogoshi <ogochan@nurs.or.jp>
> 2000-2003 Masami Ogoshi & JMA.
これが問題の著作権のtitleだよね。完全に著作権は彼にある。彼を外して
このプロジェクトを続けるわけにはいかない。

112 ：login:Penguin ：04/05/08 00:44 ID:7T7nk5m4

ORCA

>>111
こいつまだいたのか。

113 ：login:Penguin ：04/05/08 00:46 ID:ti6c3k8P

>>110
ORCA
おっしゃるとおり。逆に言えば、PostgeSQLは完全にフリーだし、
フロントエンドはgladeで作っているから、大したことはない。データ
の管理をするMONTSUQIとレセ印刷をするMONPEがこのシステムの中核
だよ。それを握って、Open COBOLじゃないと扱えないようにしている
ところが、彼の最後の生命線なんだろうな。

114 ：login:Penguin ：04/05/08 01:52 ID:c1dh6Vpq

ORCAでコメントが消えようと消えまいとどっちでもいいんだけれどね。結局、
インドのIT技術者と同じblue workerなんだよ。そこから少しでも逃げ出そ
うとして肩書き付けたり、講演したりしているけれど、OOPで見せた程度の
技術力なわけだ。日医という騙しやすいパトロンさえいなければ、ただの零
細ソフト会社の社員に過ぎない。

115 ：login:Penguin ：04/05/08 02:24 ID:Uht2NpFz

ORCA大明神
もしさあ、金髪丸顔、丸メガネ、デブの男が同僚で、新しいプログラムの話を
したら、COBOLで開発することに決めちゃって、古臭い構造化しているかどうか
も分からないアプリを書き始めたら、はっきり言って、気分ワルー。
屠殺場に行って、１００ｇ　５０円ぐらいの枝肉に成れと言いたい。

116 ：login:Penguin ：04/05/08 07:17 ID:OLb9lsMZ

ORCA
その枝肉、食いたくはないなあ。

117 ：おご ◆yW.Ai2bcLY ：04/05/08 13:26 ID:/fPD+FUC

「あぼーん」がいっぱいあるから何かなーってしばらく考えたけど、きっとNG wordだったからなんだな。

テストありがとう。

118 ：おご ◆yW.Ai2bcLY ：04/05/08 13:28 ID:/fPD+FUC

帰ってからツラツラとなんで話がかみ合わないかを考えてみた。

私は一連の問題は「OO」という枠で考えていたのだけど、お相手の人は「現実のOOPL」をベースに話をしていたわけだ。
元の話は「OO化したCOBOL」であって、「Java化したCOBOL」の話でも「C++化したCOBOL」の話でもないんだから、そもそもそこが間違い。

119 ：おご ◆yW.Ai2bcLY ：04/05/08 13:41 ID:/fPD+FUC

例外処理にgenericな型が必要かどうかってことなのだけど、これは別に必須でないしなくてもそんなに困らない。

「object」を一級オブジェクトにしている言語(RubyとかSmallTalk80とか)やそれ風にしている言語(Javaとか)なら、型を操作することはあまり変なことではないので、genericな型は綺麗に扱える。
逆にこの手の言語でgenericな型なしで例外処理するのは、「object」を一級objectにしているということとバランスを欠く。
だからこれらの言語の時には、genericな型があることと例外処理を言語仕様に含めるということはセットになる。

このような言語の場合、私が言っていたような「ある程度知っている型だけを扱う」という要求は、たとえば

event catch {
例外イベント {
switch (例外.class) {
when あの型:
あの型の時の処理
when この型:
この型の時の処理
otherwise:
知らない例外の処理
}
}
}

みたいな記述にしておけばいい。

ただこの場合、「型による分枝をしない」という乱暴な書き方も許せちゃうので、急いでたりいい加減な人だったりすると、困った動きをするプログラムになっちゃう。
まぁこれは柔軟性とセットなんで、「そんなもの」と思うしかない。

120 ：おご ◆yW.Ai2bcLY ：04/05/08 13:49 ID:/fPD+FUC

「object」が一級オブジェクトでない言語の場合(既存言語をOO化した場合はたいていこれ)、型の操作をプログラマに許すかどうかは、言語仕様次第。
型の操作を許さない言語の場合、genericな型があっても使いようがない。
じゃそのような時には例外処理はどう書けば良いかと言えば、

EVENT-CATCH PART
BEGIN 例外イベント処理
CASE あの種の例外:
あの種の例外の処理
CASE この種の例外:
この種の例外の処理
OTHER:
知らない例外の処理
END
END

# 記法の違いは他意はなし

みたいな記述であれば、何もgenericな型がなくて同じことができる。
「どうせ同じことやってんじゃん」という声もあるだろうし、それは実際にそうなんだけど、分枝が型操作の結果の分枝じゃなくて構文に組み込まれているという違いがあるわけ。

私は言語のバランスから言えば、objectが一級オブジェクトでない言語の場合は、型の操作をプログラマには許さない方が美しいと思う。

121 ：おご ◆yW.Ai2bcLY ：04/05/08 13:55 ID:/fPD+FUC

例外をイベント処理として使うテクニックについては、これは単に特定のOOPLだとそう書けば便利だというだけ。
私には「setjump longjumpはGOSUBみたいに使えるぜ」みたいな話の延長に見える。

私はむしろ逆にイベント処理の一部として例外がある方が考えやすい。
ただそれは、「そんな文化を持っている」というだけであって、本質ではない。

既存OOPLを使うテクニックとしては「目から鱗」なんだけど、あんまり例外処理の本質とは言えないように思う。
みんなが例外例外って言って喜んでるのが、そんな理由からだったら、あんまり嬉しいことじゃないなぁ。
ただ、私は例外を積極的に使うプログラミングという経験は皆無なので、特定の言語に縛られたテクニックでない本質を突いた使い方があったら、ぜひとも知りたいと思う。

122 ：おご ◆yW.Ai2bcLY ：04/05/08 13:57 ID:/fPD+FUC

スレに書く時には空白の前置に注意しなきゃいけないんだな...

123 ：おご ◆yW.Ai2bcLY ：04/05/08 14:06 ID:/fPD+FUC

既存のものを「マンセー」するのは結構だけど、そこで思考停止したらいかんと思う。

言語だけでも、かつてPL/Iが「マンセー」され、Adaが「マンセー」され、Pascalが「マンセー」され。また諸々の4GLが「マンセー」された時代もあれば、太古はCOBOLだって「マンセー」だった。
そいつら今はどうなってる？ みんなが「マンセー」したものって、実はどこかにそれが都合の良い人がいて、それに踊らされているだけじゃないのか？
Linuxだってオープンソースだって、昨今の「マンセー」ぶりはちょっと踊らされているという感がある。

まぁ定着するまでは、一生懸命踊らせないことには始まらんわけだが、笛太鼓持ってる奴等が静かになっちゃった時に、後に価値があるものが残るかどうかは、「本質をどう掴んだか」だよ。
いつまでも踊らされる側になっていたいのであれば、踊りの練習をするのは悪くないかも知れないけどね。

124 ：login:Penguin ：04/05/08 14:57 ID:TOGRJgmP

>>116
ORCA
十分煮込めば大丈夫だよと、乗ってみる。（笑）

125 ：login:Penguin ：04/05/08 14:59 ID:TOGRJgmP

>>123
COBOLで思考停止しているのはお前の方だと思うが？

126 ：login:Penguin ：04/05/08 15:01 ID:TOGRJgmP

>>126
なぜなら、OOPLの基本的な使い方や実装の方法について、未だに分かって
いないように思えるからだ。３時か．．．後で説明する。

127 ：おご ◆yW.Ai2bcLY ：04/05/08 15:22 ID:/fPD+FUC

>>125
別にCOBOLで思考停止なんぞしてないが。
私自身は普段はCOBOLでは書かんし、COBOLマンセーでもない。
新人に新しく言語を教える時には、COBOLを教えるべきかどうか悩むのだよ。

じゃあなぜCOBOLを好むかって？
COBOLはアプリケーションを書かせるのに(私にとって)楽だからだよ。
柔軟性に欠けるという欠点は承知の上だが、世の中柔軟でなくても良いことは特に基幹系事務計算には多いから、商売としてやるにはそんなに困りはしない。

Javaも「俺言語」の一種だと思えば悪いものだとは思わない。
でも、まだ基幹業務のアプリケーションを*書かせる*のには使いたくないってだけ。
JavaがSunの支配から離れて、オープンソースになってくれれば、十分考えるべき対象になるさ。
柔軟でなければならない業務だってあるのだから。

ただそれとは別に、Javaってのは仕事そのものは多いみたいなんだけど、どうも最近安売り傾向にあって、「短納期低価格」なお仕事が多いようなんだな。
ビジネスとして見ると、一昔前のCOBOLみたいな情勢にあるのが、ちと萎える元だ。

128 ：login:Penguin ：04/05/08 17:21 ID:UZPE8zpr

>>121
ORCA

まじでイベント処理に例外使い出しそうだな（ｗ

129 ：login:Penguin ：04/05/08 22:46 ID:8SER9eVw

>>128
ORCA
やっと仕事終わった。まだ風邪引きがやってくる、萎えるわぁ...ogoちゃん
への返事は後においといて、COBOL2002の仕様は、classをどういう形で実装
するか分からないから、そう便利な使い方ができるか分からないなぁ。ruby
には詳しくないが、あれは、例外処理ができるんだろう？　なら、作者のMr.
Mに聞けばいいと思うのだがね。ちょっとシャワーでも浴びてくるね。

130 ：login:Penguin ：04/05/08 23:03 ID:PQpY3xPk

>>127
> じゃあなぜCOBOLを好むかって？ COBOLはアプリケーションを書
> かせるのに(私にとって)楽だからだよ。
結局、von Neumannの亡霊に取り憑かれて離れられないわけだね。

> JavaがSunの支配から離れて、オープンソースになってくれれば、
> 十分考えるべき対象になるさ。 柔軟でなければならない業務
> だってあるのだから。
JavaもISOの認定を受けているから、そう、なくなりはしないし、
処理系もSunだけではない。

> ただそれとは別に、Javaってのは仕事そのものは多いみたいなん
> だけど、どうも最近安売り傾向にあって、「短納期低価格」なお
> 仕事が多いようなんだな。
だから、それが可能になりつつあるってことだよ。この時代に納期
を短縮するにはOOPLに依存しなければならないってことだ。

131 ：おご ◆yW.Ai2bcLY ：04/05/08 23:56 ID:SY/xVPC5

>>130
もうちょっと賢い奴かと思ったら、受け売り君か。
その程度の頭だったら、せっかくのOOPLやOOの知識(藁)も有効には使えんだろうな。
いや、技術的には使えるくらいの奴かも知れんが、一生使われる側、踊る側の人間で終わるだろうよ。

>結局、von Neumannの亡霊に取り憑かれて離れられないわけだね。
「書かせる」と言ってるのがわからんのか？
それに、ノイマンがどーこーなんて、あんまり関係ない話だと思うが。

>JavaもISOの認定を受けているから、そう、なくなりはしないし、
>処理系もSunだけではない。
その状況は君にとって幸せかい？
だったらLinuxなんて使わないでMSの製品で喜んでても何の問題もないだろうし、オープンソースなんて寝言に聞こえるはずだ。

> この時代に納期を短縮するにはOOPLに依存しなければならないってことだ。
OOPが銀の弾丸か。おめでたい奴。

もし本当に言ってるだけの銀の弾丸だったら、「短納期低価格」になってもOOPL使ってるソフトハウスは困らないはずだよね。
仕事取れなくて潰れるところは出るだろうけど、残ったところは儲かってるはず。
ところが昔よりも辛くなったところが少なくない。それは単に「彼等の頭が悪いから」とも言い切れない。
これは「OOPは短納期で大丈夫」という宣伝の方が、OOPの能力を超えてしまってる結果で、つまり「宣伝ほどのものじゃない」という傍証だよ。

OOPが駄目だとか悪いとか言う気は全くないよ。自分のプログラムでだったら使うことだし。
ただ、「マンセー」と言えるほどの「銀の弾丸」でないことも確かだ。

132 ：login:Penguin ：04/05/09 00:03 ID:5DebL9w3

>>131
>>130じゃないけど。

COBOLに比べてJAVAの方が銀の含有量が多い少ないの議論なら
議論になるけど、JAVAは銀の弾丸じゃない。だけだと実務的じゃない
なぁと思うのね。

UMLをどう捉えるか、によって仕事を任せやすい任せにくいも180度
違って来ると思うし。

UML（OOD）−OOPの流れと構造化ー３GLの流れ、この二つの銀含有量
を考えて見ると、話しやすいなぁと思う。

133 ：login:Penguin ：04/05/09 00:51 ID:Hfr/DWej

>>132
なかなか素晴らしいご意見。
programをmoduleに分けた段階で半分は、OOPに近づいている。
問題は、Actor modelを理解して、object中心に考え方が転換
できるか否かで、開発効率が変わってくると言うことだよ。
COBOLは高等スクリプトであって、すでに言語ではないと俺は
思うわけだ。

134 ：login:Penguin ：04/05/09 02:17 ID:xeCU/PUP

>>おごちゃん
ソースは「sourse」ではなく「source」ってＤＱＮ野郎たちに教えてあげてください。
お願いします。

[coboler:1470] ＣＯＢＯＬオープンソースコミュニティー
ttp://www.coboler.com/opensourse.htm

135 ：おご ◆yW.Ai2bcLY ：04/05/09 14:21 ID:Spj45ieE

>>132
銀の含有度か。面白い尺度だし建設的だ。

とは言え、「銀って何？」ってのもあるのだよね。
「自分の手間を減らす」という尺度にするにしても、立場によって違うわけだ。
自分でプログラムを書くのか、他人に書かせて面倒見るのは、ほとんど放りっぱなしでいいのか...で違ってしまうからね。
私は自分で書く立場と、書かせる立場と両方あるから、どっちの立場で言うか違って来るし。

とかって考えると、「銀」が定義できない時点で、「銀の弾丸はない」と思ってしまうわけ。
もし「銀の含有度」という議論をするのであれば、「どんな局面か」ということをセットで論じないと、また水掛け論にしかならないと思う。

136 ：おご ◆yW.Ai2bcLY ：04/05/09 14:28 ID:Spj45ieE

>>133
いい加減にプロバガンダの盲信はやめたらどうだ？

>programをmoduleに分けた段階で半分は、OOPに近づいている。
まるで「全ての文化は朝鮮半島が起源だ」と言ってるDQN韓国人の発言みたいだぜ。

モジュール化の延長でオブジェクトという考え方が出て来たのは事実だけど、モジュール化はオブジェクト化と可分。
モジュール化を考え出した奴等にしてみれば、「OOPはモジュール化の一手法」というとらえ方になるのだよ。
まぁ世界観の違いと言えばそれまでだが。

後半の部分は全く理解できないや。
詳しい解説きぼん。ただし、受け売りじゃなくて君の言葉でね。
つーか、受け売りを半端に書くから、よーわからん話になるのだと思うが(藁)

137 ：おご ◆yW.Ai2bcLY ：04/05/09 14:29 ID:Spj45ieE

>>134
COBOLerらしくていーじゃん(藁
他人の失敗は他山の石にしとけばよろしい。

138 ：login:Penguin ：04/05/09 15:17 ID:5DebL9w3

>>135
もう少し老獪な方が楽しめるのだけど、こうなってくると
ただのDQNだな（ｗ

開発サイクル全体における工数の削減が銀の弾丸という、
共通認識が有って初めて、銀の弾丸てな言葉を使いましょう。

＃人月の神話読んだ事無い見たいだな。
＃これを機会にCOBOL2002の情報集めて見たけど、
＃COBOL2002の理解ですら怪しいと思った（ｗ

ORCA

139 ：login:Penguin ：04/05/09 18:06 ID:YCKUGtH8

>開発サイクル全体における工数の削減が銀の弾丸という、
>共通認識が有って初めて、銀の弾丸てな言葉を使いましょう。
なんか変な言い方だな。「増大する工数＝モンスター」を
倒す「必殺」の手段、すなわち「銀の弾丸」でしょう。
ドラスティックな解決というニュアンスがどっかに行って
しまったような。（含有率云々の時点で失われてるのか。）
131のおごちゃんのカキコの方が「人月の神話」の主張に
そっていると思うな。

原題は知らないが翻訳では「人月の神話」の副題は「狼人間を
撃つ銀の弾はない」で「銀の弾丸がある」じゃない。
最終解決も最終解脱も実在しないって事。

140 ：login:Penguin ：04/05/09 18:12 ID:BvOeCOrZ

>>138
ORCA
「狂信者と餌を与えられた空腹の動物には、耳はない。」ということだ。
信じているものを信じちゃいけないのか？　空腹を満たす餌の供給者を
疑ってはいけないのか？　という反論が虚しく響くだけの話だ。

141 ：login:Penguin ：04/05/09 18:15 ID:BvOeCOrZ

ORCA
ogoちゃんはプログラミングで飯を食っている１プログラマーであり、
飯を食わしているチームの管理者であると言うことだよ。その縛りか
らは抜け出せないし、まだ自己批判しながら、自分の仕事をするとい
うことはできない程度の、maturityということなんだ。

142 ：login:Penguin ：04/05/09 18:27 ID:5DebL9w3

>>141
ORCA

すごく良くわかるが、その行為はチームを何処へ連れて行くか？
という大きな大きな問題があるんやね…

>>139
君は本を読むとき、文字しか読めないタイプだね。

143 ：おご ◆yW.Ai2bcLY ：04/05/09 19:18 ID:Spj45ieE

おるかのことが書いてあると、自動で見えなくなるんで、普通に話す時には入れんでくれ(藁)
私にこっそり悪口を言うにはちょうどいいんだが。

話がよく見えんので、>>139に続けるってことで、

>>開発サイクル全体における工数の削減が銀の弾丸
そういう話だったら、私にとってはOOPよりもOODの方が「銀の弾丸幻想」抱かせてくれたよ。
もっと低レベルで言うならUMLと言ってもいい。わたし的には「UMLマンセー」だ。
もちろん「銀の弾丸はない」と思っているので、銀の弾丸だとは思ってないが、十分幻想を持たせてくれた。

開発サイクル全体とかって言うなら、たいていのシステム開発では半分くらいの期間を設計に費すものなので、そっちの方を解決してくれる方が嬉しい。
だいたい工程って半分くらい設計で、そののこりの半分の半分くらいがコーディングだってことが多いから、プログラミングに銀の弾丸があって、仮に0にできても1/4しか短縮できない。
昔の手法昔の言語で1年かかっていたことなら、半年くらいまで短縮できれば大成功。
ところが下手すると、さらにその半分くらいの工期だったりするから、ソフトハウスは苦しむのだろう。

144 ：login:Penguin ：04/05/09 21:13 ID:bpF3vjPQ

>>142
ORCA
おっしゃるとおりだが、ORCAの場合、間接的にも出資しているユーザーがいる
ってことだ。もちろん、日医は民主的な団体であるのが前提であるし、そこと
の契約に基づいているってのは分からなくはない。ただ、MLでユーザーを批評
するサービス業があるのは不思議だ。その点でフリーソフトと商用ソフトの中
間的な存在のORCAは、ユーザーにとって不利になるようにできている。

145 ：login:Penguin ：04/05/09 21:16 ID:bpF3vjPQ

>>143
ORCA
コーディングに時間の取りすぎ。７−８割設計、２ー３割コーディング
でないと、これからの時代には勝てないだろうなぁ。OPASのチームもお
なじなんだろうかねぇ。

146 ：login:Penguin ：04/05/09 21:18 ID:bpF3vjPQ

ORCA
書いている方はこそこそじゃなくて堂々と書いている。目隠しをして
いるのは自分の方だと気がつかないのは、３歳児ぐらいの精神年齢。

147 ：login:Penguin ：04/05/09 22:00 ID:5DebL9w3

>>144
ORCA

開発ライフサイクルにおける工数の削減とは、ユーザニーズとのマッチングとも
関わる話で、人月の神話をきちんとしたアーキテクトの視点で読めば、
おごちゃんの方が当たってるという発言は出てこないわけだ。

君はきちんとした問題意識は持ってるが、周辺技術に対する理解が表層的だな。

148 ：login:Penguin ：04/05/09 22:47 ID:VSJZdK+E

>>147
ORCA
これは失礼。それでは教えを請いたいのだが、soft wareを客観的に
評価する方法は確立されているのだろうか？　信頼性・補修性・安定
性・操作性などが考え得るが、comprehensive evaluationというも
のがあるのか、素人の私にも分かるように教えて欲しい。
組み込みのprog.などはバグがあれば、その製品自体が回収されるが、
デスクトップで使うようなprog.は、
「それで、誰か死んだのか？」
と言われて、不具合で終わってしまう。不思議な業界と商慣習だと
思うのだが...

149 ：login:Penguin ：04/05/09 22:49 ID:VSJZdK+E

ORCA
もし、ORCAを自分で管理している医師が、不具合で１時間過剰に労働した
としよう。だいたい医師の時給は１万円とされているから、1,000人で、
その損害を補償して欲しいと訴訟を起こせば、1,000万円の請求になるだ
ろう。ORCAで１時間の時間の消耗など短い方だ。

150 ：login:Penguin ：04/05/09 23:11 ID:5DebL9w3

>>148-149
ORCA

＞これは失礼。それでは教えを請いたいのだが、soft wareを客観的に
＞評価する方法は確立されているのだろうか？　信頼性・補修性・安定
＞性・操作性などが考え得るが、comprehensive evaluationというも
＞のがあるのか、素人の私にも分かるように教えて欲しい。

残念ながら、今まさに開発されつつ有る領域で、業界標準と言える程
体系的に完成してるものは無いね。
各企業独自にバグの発生率や、手戻りの原因評価などやってはいるけど、
（これをやってる企業ですら未だ少数派かも）各企業どころか、各グループ
各開発案件ごとに評価基準が違ったりもしてるのが現状。

評価の手順がキチンと出来てるか？何て事を第三者機関に評価させて
認定を受けるCMMなんて、おちゃらけた制度すら普及段階。

＃業界全体がこの程度のレベルと言う事と、だからと言って客観評価をしなくて良い、
＃手を抜いて良い、出来る事から目をそらして良いなんて事は全くの別問題だとは了解して
＃頂けると思うがね。

151 ：login:Penguin ：04/05/09 23:35 ID:JS7JhpXg

ＯＲＣＡの話はＯＲＣＡスレでやれや。

152 ：login:Penguin ：04/05/10 00:25 ID:OkNuDfp1

>>151
ORCA
ORCAは単にogoちゃんのリクエストで、NG wordとして使っているだけで、
ogoちゃんのprog.技術ややり方について論じているだけの話だよ。それ
とも、>>151=ogoちゃん？　自分でまいた種は上手に刈り取れよな。

153 ：login:Penguin ：04/05/10 00:34 ID:LnCDGErK

>>150
ORCA
三菱ふそうは事実上壊滅状態だし、雪印もブランドが崩壊した。
プロダクトに対して、責任を軽視した企業は市場からの撤退を余儀なくされる。
まだ、ソフト産業は同じぐらい不具合を出しているから、共存し得れるという
のも事実ではなかろうか。この状況にBreak-throughを開けられれば優位に立
てるそう思っていろいろな戦術をとっているのではないだろうかね。

154 ：女子中学生 15さい ゆうこ ◆vgyJFQ7EcQ ：04/05/10 03:29 ID:gRI67Axh

ＯＣＲＡ

とろろ芋にオクラまぜて青海苔ふってご飯にかけて食べます。

155 ：login:Penguin ：04/05/10 08:29 ID:X3wF75cR

ORCA
こいつの頭の中を分析したかったらここ
http://pc5.2ch.net/test/read.cgi/prog/1067865359/

156 ：login:Penguin ：04/05/10 10:24 ID:r73EZIkZ

>>153
雪印や三菱は陰謀＝＞人災だろ。
よく船も燃えるな。あれもたぶんそうなんだろうけど人災＝＞陰謀という感じか。

ＯＲＣＡは、

陰謀と人災(og)＝＞ＯＲＣＡ＜＝陰謀と人災(日)

こんな感じか？

157 ：login:Penguin ：04/05/10 11:31 ID:8bHer/sD

>>155
こういうスレがあったのか！

158 ：login:Penguin ：04/05/10 12:05 ID:XQqgbPjO

>>155
ORCA
結局、惰性なんじゃないのかなぁ。離婚をしない理由と同じ（笑）

159 ：login:Penguin ：04/05/10 13:43 ID:6IeuPYPp

>>158
ORCA
ま、今儲けられるものがあれば、それにしがみつくのが当然だなぁ。仕事を
しながら、新しいものを習得していく余裕があればいいのだが...他社のソースを
流用するから、COBOLのままになっているんだろうに。

160 ：おご ◆yW.Ai2bcLY ：04/05/10 17:43 ID:5fhiuATy

あぼーんだらけだ。元に戻すのも面倒だから中身は読まん。

ところで、使い勝手がどうこうということは別にして、例外処理のためのgenericな型はCOBOL 2002にもあるんだがなぁ。

それと、OOPLはいくつかの流れがあるから、そのことを理解しておかないと自分の流れ以外の言語を「OOPLの異端」とかって言っちゃうので、特に受け売り君は注意した方がいいよ。

161 ：login:Penguin ：04/05/10 20:12 ID:yay9sWjF

>>160
ORCA
ogoちゃんも暇に飽かせて、OOPの本を読んでいるみたいだね。ORCA Projectに
は、彼はもう必要ないと思うな。可能性の否定しか、主張しない守旧派でしかな
い。a typical Japanese negating white workerなんだよ。そういう連中が
たくさんいるのが、日本の社会なんだなぁ。

162 ：login:Penguin ：04/05/10 20:17 ID:L7xiFy/3

>>160
ようやくCOBOL 2002読み始めたか…
みんなが如何に脱力して、如何にニヤニヤしてたか分かる？

>>161
処世術としてアリだよね。新しい提案を却下するのではなく
ネガティブに評価して時間稼ぎ。その後おいらしてったもーん
といわんばかりの書き込み。烈しく鬱になる。

163 ：login:Penguin ：04/05/10 20:22 ID:g+mdSFQc

ORCA
医療のIT化は、厚労省の利するところであり、医療機関には不利益しか
ないというのが、今のJAMARIの意見だそうだ。執行部が変わって、180
度言うことが変わったな。ORCAのやるべきことは、確実に減点がなくな
るような、病名チェッカーに移っていくだろう。そういう事務処理では
なく、パズルのような論理的な判断をCOBOLでやれるだろうかね？　で
きなければ、ogoちゃんは、古いプログラマとして捨てられるんだろうな。

164 ：login:Penguin ：04/05/10 20:28 ID:Lnx1RhQ0

>>162
ORCA
彼は古いタイプのプログラマだよ。フローチャートが発想の原点だね。
Problem-orientedではないと思う。一つの解があるのではなく、いく
つかの対処法があると言える。これからのプログラマは、そういういく
つかの提案を根拠を示して、プレゼンしてclientのneedsを満たせる
奴が必要だと思うよ。obsoleteなCOBOLでは対処不可能だろうな。

165 ：login:Penguin ：04/05/10 20:30 ID:Lnx1RhQ0

ORCA
"OgoにNoと言えるJMARI"
これが原点だよ。

166 ：login:Penguin ：04/05/10 22:05 ID:L7xiFy/3

>>164
ポイント先が違うのかなぁ？

どうもおごちゃんも君も、情報処理系の常識が無いねぇ…
フローチャートが発想の原点なんて当たり前すぎる程
当たり前で、彼の年齢と経験考えると、これは避けられない事。

そのフローチャートに縛られてるから、こうやって議論してる
訳なので、さもおいらが気づいてないように書くのは止めて
欲しいな。

＞これからのプログラマは、そういういく
＞つかの提案を根拠を示して、プレゼンしてclientのneedsを満たせる
＞奴が必要だと思うよ。obsoleteなCOBOLでは対処不可能だろうな。
別におごちゃんの肩持つわけじゃないけど、議論の余地が有る主題。
だから議論を試みてる訳だ。
よっておごちゃんにOOとの対立点の議論深化を試みてるんだが、
おごちゃんが、説明（とうぜん業界人同士では許されるレベルの端折りはしてる）
を聞いた後に、その端折り部分を書いて来てなーにも知らないんだね
と思う。


君もおごちゃんも感じとしてはこんな感じだね。

A）昨日新幹線で青森に行ったよ。
おごちゃんや君）東京駅で切符買ったのか、いや東京駅で買ったとは
　　　　　　　　　　限らないが、とにかく新幹線の切符を買ったな。

当たり前過ぎるほど、当たり前で議論が前に進まない。
切符を買うことなど端折って構わないと思うのだが。

167 ：login:Penguin ：04/05/11 01:05 ID:jX64/QyL

>>166
ORCA
じゃあ、Programmingの手法など、この世の中で意味がないと言っているに
過ぎないね。まるで困ってコメントができなくなったogoちゃんじゃないかな。（笑）

168 ：login:Penguin ：04/05/11 01:19 ID:u58ixu+S

>>167
君全然分かってない（ｗ

素人なら素人としての立場で参加した方が良いね。
ORCAスレでは無いので、方法論の優劣議論では、
必要ないかぎり実践の経験がある事を前提にしちゃう
から。

初めてのお使いに行く子供に道順教えるような話は
端折ってるし、わざわざ書くなって事だな。
分からないなりに質問したいならそう表現すべきで、
分かった振りして書き込んで修正されるような事は、
止めておいた方が良い。

169 ：login:Penguin ：04/05/11 01:22 ID:8gHX4MOs

>>168
匿名で書くなよ、ogo.

170 ：login:Penguin ：04/05/11 01:25 ID:8gHX4MOs

>>169
１）段落ごとに改行を入れる書き方。
２）ORCA NG wordに対して反論してくる人物
３）的を射ていないプログラム技術論争
→ ogoしかいないじゃないか。

171 ：login:Penguin ：04/05/11 01:38 ID:u58ixu+S

>>169-170

おごは君の方だと思ってるんだけどネ。

１、相手は対立を目指して書き込んでるとしか理解しない、
２、説明された事の無意味な補足説明しかしない。
３、論点の整理を拒む（ｗ
４、半可通な知識しかない

172 ：login:Penguin ：04/05/11 09:43 ID:Urf8ZkQT

>>171
文章が長くなると改行を入れる書き方はogoの特徴だね。
>>171の指摘する２〜４は、ogoの特徴だが自分の資質を自覚しているという
ところかな（笑）まあ、そうやって、ORCAから話をそらそうとするのが本音
だろうがね。

173 ：login:Penguin ：04/05/11 09:47 ID:Urf8ZkQT

ORCA
ORCAの発注元である、日医総研で１８０度異なった方針の発表があった
これは、レセプトの電子化は医師会にとって不利であるという研究発表
でORCAなどのOCR印字も直ちに中止すべきであるという短絡的な意見も
でているようだ。これまで医師会のIT宣言の中心であったORCAの立場も
微妙になっている。裏切られたのかな？

174 ：login:Penguin ：04/05/11 10:43 ID:4ivkOiUs

>> 173
レセの電子化が医師会にとって不利になる，っていうのは
確かにそのとおりなんだろうけど，IT宣言ってのは政府や
支払基金に対抗できるようにデータを集めようっていうこと
じゃないのかい？

175 ：login:Penguin ：04/05/11 10:50 ID:wszNsy8b

>>174
ORCA
データを集めたら、医療側より支払い側に有利だっていいたいんじゃないの？

176 ：login:Penguin ：04/05/11 10:55 ID:wszNsy8b

>>175
ORCAなんかで、医療データを統一してオンライン化すれば、厚労省の連中は
何の調査もしないで、端末叩くだけで、医療費の無駄と称されるものを作れ
る訳じゃない。

177 ：login:Penguin ：04/05/11 11:52 ID:TmOURIs/

>>176
でもさ，現状では支払い側はレセのデータを
もってるわけじゃない？
で，医師会は全く把握してないわけだろ？
やはり対抗するには医師会もデータがほしいんじゃ
ないかな？
たしかにデータの使い方を間違えたらあんたの言うとおりだけドね．

178 ：login:Penguin ：04/05/11 12:03 ID:y8G0KVoW

>>177
医師会もレセ調査とかやっているが、現実の政策提言に結びついていない。
日医が診療報酬に対してどんな提言をしている？　
結局、厚労省の持っている人口統計とか、労働統計とか、医療保険の収支
報告とか、多種の複数のデータがないと、診療報酬の提言なんてできない
んじゃないか？

179 ：おご ◆yW.Ai2bcLY ：04/05/11 12:19 ID:6wf6DsCi

どうしてもおるかの話をしたんかいな。

医師会もNGワードにしとこっと。

180 ：おご ◆yW.Ai2bcLY ：04/05/11 12:24 ID:6wf6DsCi

>>166
私の歳だと、もうフローチャートは使ってないよ。記号とかまるでわからんし。
「フローチャートは古くさい」みたいなことを言われた時代にコンピュータ習ってる。

初めてプログラミングを習った時(高専の1年の時に先輩に習った)は、いきなりSPD(NECがやってた構造化チャート)だったのさ。
SPDは定規だけで書けて良かった。

会社に入ってからは、YAC(富士通のやってた構造化チャート)だった。
YACはテンプレートがいるのが面倒だったのと、上の方がマンセー状態だったから困ったものだった。

でも驚きなのは、まだフローチャートを教えている学校とか多いんだね。
そんな時代じゃないだろうと思うんだが。

181 ：login:Penguin ：04/05/11 12:38 ID:5p8k+C42

>>180
ORCA
Copyrightのところに自分の名前を入れなきゃ問題はなかっただろうにな。

182 ：おご ◆yW.Ai2bcLY ：04/05/11 12:44 ID:6wf6DsCi

>>162
あれ？ あるってことは言ったと思うのだが > 2002のgeneric type

ただ、それがJavaとのそれと同じことを目指したとか、同じ使われ方をするかといったことがわからん(正直わからん)ので、「ありますが何か？」みたいな言い方をしなかっただけだよ。

オブジェクトが1級オブジェクトじゃない上に、そう見せかけようという努力もしてないCOBOLみたいな言語で、果してそれがどれだけ有効なのかは、懐疑的という意味じゃなくて、「わからん」のよ。
具体的に2002のOOPを使いまくったコードとか見てないし。

>その後おいらしてったもーんといわんばかりの書き込み。
一々「これこれを知ってる」なんて全部ひけらかしてもしょうがあるまい。
勝手にあなどって話をするのが間違っているのさ。

183 ：login:Penguin ：04/05/11 13:10 ID:CIkVAA5r

>>182
ORCA
そういう話はCOBOLerスレですれば、受けると思うのにな（笑）
ここは、Linux communityでのogoの立場を論じているだけのことなんだが。

184 ：login:Penguin ：04/05/11 16:13 ID:00Q59z/G

>>182
ORCA
JIS規格を決めるのは経産省だろうが、なぜ、OOPも使ったことのないogoを
COBOL2002の規格の委員にしたりするんだろうかね？　日医にしても人選を
間違っていると思うな。どうせ、ＩＳＯあたりの規格そのままなんだろうが。
金だけもらって日本語訳して終わりなんだろうな。

185 ：login:Penguin ：04/05/11 18:05 ID:BiP3sTtv

ORCA
Mr. Ogosi is an obsolete programmer who made the ORCA that is so called
ORCA the Obsolete Resister for Cheat Accounting. He worked for the Japanese
medical association, but he has been deceiving us the members of JMA. He is
an imposter of SE's. Why was he named as a committeeman of programming by the
JMA and the Ministry of economy and industry?
Chinese IT industry actually has a superior potential to Japanese one. Mr. Ogosi
is a typical obsolete SE who will suffer disadvantage for the people who are related to him.

186 ：login:Penguin ：04/05/12 00:16 ID:gE1IuUuj

>>185
機械翻訳？意味以前にすげえ語順だな。もう一度文型からやり直したまえ。
こんなレベルじゃドキュメントを読むのも一苦労でしょう。ご同情申しあげます。
それとも日本語のドキュメントだけ読めばいいお仕事ですか？

187 ：login:Penguin ：04/05/12 00:22 ID:p2v0v7KH

各種 OSS のドキュメントを読んでると、このていどの英文は普通に出てくるよ(苦笑)
逆に、native が書く英語の方が、略したり論理をはしょったりして意味を取りにくい
ことが多かったり。

一番気になるのは who made the ORCA that is so called.. あたりだけど、
単純に who made the ORCA which is called as Obsolete ... くらいにすれば
まぁ読めるんじゃない？

188 ：login:Penguin ：04/05/12 00:56 ID:n3AyFpcW

>>187
ORCA
段落を変えるたびに空行を入れる癖は治らんみたいだなぁ。

189 ：login:Penguin ：04/05/12 01:09 ID:p2v0v7KH

まぁ、我々の世代だと修士や博士の論文書きに TeX(LaTeX)を使っていたから
その癖は一生付きまとうんだろうなぁ。

# 三つ子の魂なんとやら、、ってやつだな。

190 ：login:Penguin ：04/05/12 01:10 ID:G/JLw57N

>>188
ORCA
まあ、ムキに煽る必要もないんじゃないか？　医師板から来ているんだろ？
こちらにも情報は来ているが、日医総研の改革、かなり大胆みたいじゃない。
ogoちゃん、どうなるか、放置プレーでもいいんじゃないか？（笑）

191 ：login:Penguin ：04/05/12 01:10 ID:E1TeM2Jo

ここは ogo と粘着以外いねーのか、おい。

192 ：login:Penguin ：04/05/12 10:25 ID:nM1I3+/k

>>191
ORCA
退屈な奴とogoだろ。

193 ：おご ◆yW.Ai2bcLY ：04/05/12 12:09 ID:Zszh+F/U

>>191
私もそう思う。なんかあぼーんばっかりだな。
某システムに関係のある単語は表示しない設定にしたら、軒並あぼーんになっちゃってる。

194 ：おご ◆yW.Ai2bcLY ：04/05/12 12:12 ID:Zszh+F/U

>>189
最近はSmartDoc使うようになった。まぁ結局あれもTeXなわけだけど。

SmartDocは理想そのものじゃないけど、いろいろ加工するには便利な形式だ。
DocBookに変換しようと思えばできなくもないから、オリジナルとは別の処理系も作っちゃったんで、当分使える。

195 ：login:Penguin ：04/05/12 13:29 ID:jiiGVz7e

>193

いや、>192の言う方が合ってると思う。

一応、TeXnician。。

196 ：login:Penguin ：04/05/12 15:39 ID:DHHmwhjY

あ〜ぁ、退屈だ。eclipseででも遊ぼうかな。

197 ：おご ◆yW.Ai2bcLY ：04/05/12 15:54 ID:Zszh+F/U

>>195
おちゅーしゃって「あぼーん」になっても、参照されてるとポップアップで見えるのだね。
195のお陰で中身が見えた。

私の知らんところで会話するためにNGワードを書くようになってるのか。
それがしたいんだったら、他のスレでやれば私は見てないのに。
(この板で見てる他のスレは、おちゅーしゃスレだけ)

198 ：login:Penguin ：04/05/13 02:27 ID:Ub32T7QQ

あまりにも哀れ
ttp://slashdot.jp/comments.pl?sid=179311&cid=546520

199 ：login:Penguin ：04/05/13 03:13 ID:Iv0q/aw+

>198

う〜ん、全てにおいて、半可通の電波なのだなと納得してしまった。
相手にされなくなるまで、声を張り上げ続ける体力だけはあるようだがね。

それで「相手が逃げた」と宣言（ここでもやっているね）すると。。

行動パターンが常に同じで笑ったよ。

200 ：login:Penguin ：04/05/13 11:32 ID:O+iv7JpH

糞スレだけど200GET

201 ：おご ◆yW.Ai2bcLY ：04/05/13 12:01 ID:g9KUPOGi

>>199
別に逃げちゃおらんが。

ということとは別に、ちょいと逃げたくなったんで逃げます。
電波と言いたい人はどうぞ。
スレも削除依頼出しときます。

202 ：おご ◆yW.Ai2bcLY ：04/05/13 12:12 ID:g9KUPOGi

ここや/.のことは、まぁせいぜい「藁の一本」でしかなくって、理由は他のところにあります。

まぁ簡単に言えば理解しようとしない人達の世界に、自分のリソースを使うことをやめよういうことで、「一般大衆向けボランティア」みたいなことから撤退することにしたのです。
そういったことって大切だとは思うけど、「理解してくれる人達」に向けるリソースを削ってまでやっちゃいかんなと。

203 ：おご ◆yW.Ai2bcLY ：04/05/13 12:13 ID:g9KUPOGi

今まで使っていたトリップは、

suPer00

という文字列で生成可能です。

read.cgi ver7.20p (04/01/07)