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

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

【時事】生越昌己についてあなたの意見ください 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
前スレ
【時事】生越昌己についてあなたの意見ください 9
http://pc3.2ch.net/test/read.cgi/linux/1077124382/
【時事】生越昌己についてあなたの意見ください 8
http://pc.2ch.net/test/read.cgi/linux/1066617022/
【時事】生越昌己についてあなたの意見ください 7
http://pc.2ch.net/test/read.cgi/linux/1054112909/
【時事】生越昌己についてあなたの意見ください 6
http://pc.2ch.net/test/read.cgi/linux/1044493706/
【時事】生越昌己についてあなたの意見ください 5
http://pc.2ch.net/test/read.cgi/linux/1038403643/
【時事】生越昌己についてあなたの意見ください 4
http://pc.2ch.net/test/read.cgi/linux/1035132995/
【時事】生越昌己についてあなたの意見ください 3
http://pc.2ch.net/test/read.cgi/linux/1028282583/
【時事】生越昌己についてあなたの意見ください 2
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の利点は発揮され
ると思う。環境が変わっているのだから、プログラミング言語が変
わるのは当然だと思うけれどね。

まあ、5年後を見ろ、と言うことになるんだろうけれど、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でも2ちゃんでもそうだが、匿名で偉そうに言う奴ほど、中身が間抜けなんだよなぁ。
そんなに偉いんだったら実名晒してもいいだろうと思うんだが、間抜けがわかってるからできないんだろうな。まぁ自覚があるからかわいいもんだ。

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

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
早速、新しいスレがたっているわね〜。。。
ワタシも、クンクンの着せ替え人形作っちゃた。。。
Y!のIDは内緒よ。。。

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
一度、おごさんに聞きたかったんだけれど、NECがサポートしている
商用ソフトの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まで登場するのはなぜなんだろうねぇ。理屈はなんとでも付けるんだろうけれ
ど。1つの言語で作っておけば、開発効率も補修も簡単だろうに。

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
商標でNECと問題はないのか?

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

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

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

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

お客が望めば、それでお金出せば、統一言語で書くのも可だけど、
スクリプト5行のものを、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つしか使わないって発想は、アマチュア的な考えだと思う。
言語をやっと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として、使いやすいのよね。
>ほー。目から鱗。例外はイベントかぁ。確かにそう考えるといいな。

_| ̄|○

虚脱してる人間が山のように居ると思う(w
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
>とか思うのは、私が「何でも受け取り」ということに違和感を感じているからで、
>それがレガシーだと言われればそうですかと言うしかないけど。

言う事ナス(w

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

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

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

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


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


70 :login:Penguin:04/05/07 16:08 ID:L/LZ54dj
>>66
> 虚脱してる人間が山のように居ると思う(w
俺もその一人だ(笑)
そういう人たちが、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
おごちゃんは、一応問題点を理解したと理解しますた。
議論しずらい人だなぁ(w

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だけ見てたら分からなかった事。

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


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のことを勉強してから来てくれよ。

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


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
3歳児ぐらいに、「かくれんぼ」をしようと言うと、自分の目をふさいで
座り込む子供がいるんだ。つまり、自分が目をつぶれば、他人から見られ
ないと思いこんじゃうわけだね。>>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
具体的にどこが使いづらいのかな? 以前のレセと勝手が違うから? 設計の
センスが悪いから? 1か所でいいから、具体的にここって言うところが聞き
たいな。

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で開発することに決めちゃって、古臭い構造化しているかどうか
も分からないアプリを書き始めたら、はっきり言って、気分ワルー。
屠殺場に行って、100g 50円ぐらいの枝肉に成れと言いたい。

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の基本的な使い方や実装の方法について、未だに分かって
いないように思えるからだ。3時か...後で説明する。

127 :おご ◆yW.Ai2bcLY :04/05/08 15:22 ID:/fPD+FUC
>>125
別にCOBOLで思考停止なんぞしてないが。
私自身は普段はCOBOLでは書かんし、COBOLマンセーでもない。
新人に新しく言語を教える時には、COBOLを教えるべきかどうか悩むのだよ。

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

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

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

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

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

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)