09/06/01 12:30:25
前スレ
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
09/06/01 13:14:10
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
3:デフォルトの名無しさん
09/06/01 13:16:32
でもライブラリはオブジェクト指向で書かれている方が圧倒的に使い易いのは確かかな。
4:デフォルトの名無しさん
09/06/01 15:36:17
ライブラリがどの言語で書かれていようが
オブジェクトファイルなってしまえば関係ないわけだが
5:デフォルトの名無しさん
09/06/01 16:21:52
>>4
>>4
>>4
6:デフォルトの名無しさん
09/06/01 18:53:38
京都大学はどこまで研究熱心なんだよ・・・
7:デフォルトの名無しさん
09/06/01 19:50:55
>>6
京大だけに、狂ったように研究熱心なのさ
8:デフォルトの名無しさん
09/06/01 20:57:39
オブジェクトはすべて非同期に動くべき。
9:デフォルトの名無しさん
09/06/01 20:58:38
ナンデ？
10:デフォルトの名無しさん
09/06/01 21:39:04
>>8
全てがオブジェクトな言語だと
1+1でもスレッドが起動されることになるが…
なんという無駄
11:デフォルトの名無しさん
09/06/01 21:56:11
>>8
ナンデ？
12:デフォルトの名無しさん
09/06/01 22:20:55
>>10
>>8 の肩を持ちたいとは思わんが
非同期 = スレッド
ってのは、ちゃうと思う
つ 遅延評価
13:デフォルトの名無しさん
09/06/01 22:26:42
>>12
遅延評価と非同期は全く関係ないが
14:デフォルトの名無しさん
09/06/01 22:28:19
>>13 ハード作るときは、ほぼ等価
15:デフォルトの名無しさん
09/06/01 22:32:03
遅延評価と非同期と…ハード？？
16:デフォルトの名無しさん
09/06/01 22:33:24
オブジェクトって関数より再利用しにくいのではないだろうか
オブジェクトでthisコンテキストにアクセスできるようになったのと引替えに
再利用のために、関数なら引数のことだけ考えれば良かったが
オブジェクト単位で再利用を考えない意図いけないようになった。
そのため、継承・仮想メソッド・インタフェース・デザインパターン・ジェネリック
などのテクニックでその欠点を補っているのではないだろうか。
17:デフォルトの名無しさん
09/06/01 22:36:15
>>14
そんな元レスと話の絡まないレスでは意味がわからん
18:デフォルトの名無しさん
09/06/01 22:36:34
オブジェクトと関数を比べるのはバランスが悪い。
比べるなら、
片やオブジェクト郡、
片や関数郡とそれに渡されるであろうパラメータ郡。
そう考えると、再利用がどうかはさておき、
オブジェクトを中心にすえて考えていくほうが、
少なくとも、「散らかってない」と思う。個人的に。
19:デフォルトの名無しさん
09/06/01 22:37:16
まだオブジェクト指向で再利用とか言ってる奴がいるのか。
20:デフォルトの名無しさん
09/06/01 22:40:58
>>10
すべてオブジェクトにするからおかしくなる。
そんなのは理論屋がやってろ。
21:デフォルトの名無しさん
09/06/01 22:47:27
メッセージ（メソッド）が規格化されてないからいけない。
メッセージに使える単語を制限したらどうか。
オブジェクト指向じゃなくなるか。
22:デフォルトの名無しさん
09/06/01 22:48:33
天才チンパンジー アイちゃんって２番にしか出てこないのか
さっさと埋めれば良かった
23:デフォルトの名無しさん
09/06/01 23:12:20
python のリストや辞書型くらい整備してくれてりゃ
クライアントとしては使いやすいとは思うけどね。
まあ速度とか気にしだせば結局再利用なんて無理でしょ。
24:デフォルトの名無しさん
09/06/01 23:16:46
再利用が無理と言い切るのもなんだかな
魔法のように何でも再利用できる！みたいなのは違うのは確かだが
25:デフォルトの名無しさん
09/06/02 02:05:24
迷った時は両方!
オブジェクト指向な関数型言語のocaml使えw
26:デフォルトの名無しさん
09/06/02 03:53:36
再利用しないからｗｗｗ
27:デフォルトの名無しさん
09/06/02 08:42:50
>>18
再利用の単位が関数よりも大きいだけと言うことか
オブジェクト指向のメリットって理解のしやすさと言うことだけ？
28:デフォルトの名無しさん
09/06/02 08:43:31
>>23
ホットスポットの解析もせずにライブラリに文句をいう厨房ですか？
29:デフォルトの名無しさん
09/06/02 09:32:05
>>27
理解のしやすさ、というかなんというか。
メリットは色々あるんじゃないかな。
オブジェクトという単位でモジュール化できて、
内部構造としての、変数の表現、メソッドの実装を隠す。
んで、そのオブジェクト郡のインタフェースには関連が見出せたりして、
実行時にはポリモーフィズムで一括して扱える。
あくまで、オブジェクト郡の相互作用で作っていく。
OOPでの再利用云々は、設計の正しさの拠ってると思われる。
再利用しやすい単位で、使用される文脈に想定をおいたりせず、
他のオブジェクトを無闇に知っていたりせず、うまいこと作る。
逆に、そこんとこをきちんとしてないとうまく再利用できないだろうし、
それもってOOPの力不足としてしまうなら、なんか違う気がする。
明白な特性をひとつだけ与えられたクラスは長持ちすると思う。
特性があいまいだったり、コブが着いてたりすると、弱いと思う。
30:デフォルトの名無しさん
09/06/02 09:43:49
無駄が多いですよね
31:デフォルトの名無しさん
09/06/02 12:48:31
100円節約するために1000円掛けるようなところがあるよね
32:デフォルトの名無しさん
09/06/02 13:10:49
業務用プログラムならばそれでいいんだよ。
運用費を100万円削るために開発費1000万円上乗せすればいい。
33:デフォルトの名無しさん
09/06/02 13:36:31
>20
そういや、Javaで基本型がオブジェクトじゃないのは、現在の視点で見ても、
良い判断だったんだろうか？
34:デフォルトの名無しさん
09/06/02 14:12:39
こんなモノ作るのになんで1年もかかるんだよと思うことは多々ある。
俺なら1週間で作れるモノを。
35:デフォルトの名無しさん
09/06/02 14:14:38
最初一週間でできるよって思ってたのが、一年たっても終わらないのはよくあること。
36:デフォルトの名無しさん
09/06/02 14:18:41
それは要はやる気が持続するかどうか だけなんじゃねーの
37:デフォルトの名無しさん
09/06/02 15:13:59
コロンブスの卵だな
誰にでも出来るのに誰もやる気を出さない
38:デフォルトの名無しさん
09/06/02 15:34:41
その点東大生は優秀だよな。
つまらない受験勉強を継続的にこなしてきたんだから。
途中で飽きて投げ出すようなやつがＦランに行くんだよな。
継続性ある性格が成功を生み出すんだよ。
39:デフォルトの名無しさん
09/06/02 15:37:18
と・・こんなことを書くと、「俺は1ヶ月勉強しただけで東大受かりましたがなにか」とか言ってくる奴がでてくるんだよな・・
別にイレギュラーを探してるわけじゃないので＾＾；
40:デフォルトの名無しさん
09/06/02 16:10:37
>>37
コロンブスの卵は、そんな話じゃないだろwww
41:デフォルトの名無しさん
09/06/02 19:03:09
随分と安っぽい卵だなぁ
42:デフォルトの名無しさん
09/06/02 19:27:36
HaskellやOCaml、Erlangなどには対話環境があるけど
OOだと対話環境って無いし、あってもほとんど意味ないよな
関数型なら一行でかける関数作りまくればいいだけだし、無名関数も書きやすいから
エディタすら無しでいろいろできるわ。
間違いなくこれらは学習のコストと効率とモチベーションに大きく影響するね。
43:デフォルトの名無しさん
09/06/02 19:29:38
つ Smalltalk
44:デフォルトの名無しさん
09/06/02 19:30:20
pythonてOO系の言語じゃないの？
45:デフォルトの名無しさん
09/06/02 19:36:04
スクリプトとOOPの良いトコ取り
46:デフォルトの名無しさん
09/06/02 19:49:08
>>44
そうだな
>>45
スクリプトとOOPは直交する概念
47:デフォルトの名無しさん
09/06/02 19:59:59
>>42
その場でがしがし付け足していけるのは楽そうだなと思うけど、
そういうコーディングしてても、保守は大丈夫なの？
関数型言語使ったこと無いから感覚がわからんけど。
48:デフォルトの名無しさん
09/06/02 20:10:23
>>42
python, ruby (irb), CINTなど色々あるのを知らないのか？
関数型言語でもToplevelをそのまま使うなんて面倒なことはしないで
Emacsのmajor-modeを使ったりするのが普通だと思うが。
49:デフォルトの名無しさん
09/06/02 20:41:31
対話型環境のメリットって関数の仕様を調べたい時とかにちょこっと実験する程度じゃないの？
rubyのirbとか普通に使えるよ。
OOP言語だと役に立たないって意味分からんね。
まさかOOPの概念を対話型環境で勉強したいって言ってんのかな
50:デフォルトの名無しさん
09/06/02 20:45:05
要は、IDEのデバッグ環境に対抗して
対話環境を関数型パラダイムで理論武装したいんだと思う
51:デフォルトの名無しさん
09/06/02 21:24:14
関数型言語が好きでML(SML, OCaml)を日頃使ってるが、ことさらOOを貶めるのも
どうかと思う。特にC++などの手続き型言語においては、OOを使わない場合と比べて
メンテナンス性が向上するのは明らかだし。
52:デフォルトの名無しさん
09/06/02 22:08:45
静的型のコンパイル言語であるScalaやってますが、ちょっとした確認なら対話型環境でやってますよ。
言語と実行環境って、分けて議論するべきものじゃないのかな？
53:デフォルトの名無しさん
09/06/02 23:22:04
そりゃOOとOOAとOOPと手続き型が一緒に語られるこんなスレじゃ、ポイズン
54:a36 ◆K0BqlCB3.k
09/06/02 23:28:05
>>53
区別するほどのものでもないだろう
55:デフォルトの名無しさん
09/06/02 23:29:46
>>53
なんで区別したいの？
話聞いてやるから詳しく話してみろ
56:デフォルトの名無しさん
09/06/03 00:08:37
>>53
OOとOOAとOOPと手続き型を全部厳密に定義してみろよ
57:デフォルトの名無しさん
09/06/03 00:27:53
お前が先に定義しろよカス
58:デフォルトの名無しさん
09/06/03 00:31:29
>>57
俺等は違いなんてどうだっていいもんｗ
全部同じぃ～で問題ないよｗ
59:デフォルトの名無しさん
09/06/03 00:33:50
はぁ？厳密に区別する必要は無いと思っているから定義する必要も無し。
一緒に語られたくなかったら定義しろよってことだ。その程度も分からんか？
60:a36 ◆K0BqlCB3.k
09/06/03 00:36:08
オブジェクト指向には厳密な定義は無いんじゃないかな。
61:デフォルトの名無しさん
09/06/03 00:37:39
>>59
いや、だから俺等はOO,OOA,OOPに違いはないよ組でいいんだろ？
62:59
09/06/03 00:40:06
>>61
そうだよ
63:デフォルトの名無しさん
09/06/03 00:51:41
威勢のいい>>57は逃亡しますた
64:デフォルトの名無しさん
09/06/03 02:17:57
ひどい自演を見た
65:デフォルトの名無しさん
09/06/03 02:26:47
どれが自演なんだ？
66:デフォルトの名無しさん
09/06/03 10:58:26
ゴガギーン
ドッカン
ｍ ドッカン
＝＝＝＝＝） ）) ☆
∧_∧ | | ／ ／￣￣￣￣￣￣￣￣￣￣￣
（ ）| |＿＿＿＿＿ ∧＿∧ ＜ おらっ！出てこい>>53
「 ⌒￣ | | || （´Д｀ ） ＼＿＿＿＿＿＿＿＿＿＿＿
| / ￣ | |/ 「 ＼
| | | | || || /＼＼
| | | | | へ//| | | |
| | | ﾛ|ﾛ |／,へ ＼| | | |
| ∧ | | | |／ ＼ / （ ）
| | | |〈 | | | |
/ / / / | / | 〈| | |
/ / / / | | || | |
/ / / / =-----=-------- | |
67:デフォルトの名無しさん
09/06/03 21:03:39
雑魚ばかりだなこのスレ
俺の話についてこれる奴がいない
68:デフォルトの名無しさん
09/06/03 23:21:24
よし何か話せ
69:デフォルトの名無しさん
09/06/03 23:32:48
>>67に期待
70:デフォルトの名無しさん
09/06/04 01:21:01
簡単なエディタなら機械語で書けるぜ
71:デフォルトの名無しさん
09/06/04 01:23:43
>簡単なエディタで機械語が書けるぜ
は？
72:デフォルトの名無しさん
09/06/04 01:35:27
え？
73:デフォルトの名無しさん
09/06/04 02:31:27
ゴガギーン
ドッカン
ｍ ドッカン
＝＝＝＝＝） ）) ☆
∧_∧ | | ／ ／￣￣￣￣￣￣￣￣￣￣￣
（ ）| |＿＿＿＿＿ ∧＿∧ ＜ おらっ！出てこい>>67
「 ⌒￣ | | || （´Д｀ ） ＼＿＿＿＿＿＿＿＿＿＿＿
| / ￣ | |/ 「 ＼
| | | | || || /＼＼
| | | | | へ//| | | |
| | | ﾛ|ﾛ |／,へ ＼| | | |
| ∧ | | | |／ ＼ / （ ）
| | | |〈 | | | |
/ / / / | / | 〈| | |
/ / / / | | || | |
/ / / / =-----=-------- | |
74:デフォルトの名無しさん
09/06/04 03:08:51
そのオブジェクト必要？みたいな
75:デフォルトの名無しさん
09/06/04 06:55:09
オブジェクト指向と直接関係ないけどマルチスレッドが扱い易い言語が欲しい。
76:デフォルトの名無しさん
09/06/04 07:04:20
C#
77:デフォルトの名無しさん
09/06/04 07:28:52
最近、でかいこと言い放つ割に逃亡する奴が多いな
78:デフォルトの名無しさん
09/06/04 07:37:39
昔からだろ
79:デフォルトの名無しさん
09/06/04 10:25:31
顔が真っ赤な人がいますね
80:デフォルトの名無しさん
09/06/04 18:49:01
ＣＷニコルさんですね
81:デフォルトの名無しさん
09/06/04 20:13:58
いまならへび、かめの卵と幼稚園の防止は俺のもの
82:デフォルトの名無しさん
09/06/04 20:15:15
>>73
|┃三 ／￣＼
|┃ | |
|┃ ＼＿／
ｶﾞﾗｯ. |┃ |
|┃ ﾉ// .／￣￣￣ ＼
|┃三 ／ ::＼:::／:::: ＼
|┃ ／ <●>::::::<●> ＼
|┃ | （__人__） |
|┃三 ＼ ｀ ⌒´ ／
|┃三 ／￣￣￣￣￣￣￣ ＼
83:デフォルトの名無しさん
09/06/04 23:46:03
ある言語がチューリング完全であれば、その言語でオブジェクト指向は可能である。
84:デフォルトの名無しさん
09/06/05 00:06:11
programming "into" a language
85:デフォルトの名無しさん
09/06/05 00:41:56
>>75
文を並べると、逐次で実行してね、と
言わない限り全部並列に実行されてしまう
言語が主流になれば、並列度も上がる
だろうなあ。
86:デフォルトの名無しさん
09/06/05 01:41:09
スーパーハッカーな俺にはオブジェクト指向なんて要らんわ
87:デフォルトの名無しさん
09/06/05 01:51:31
>>86
どんなパラダイムがおすすめですか？
88:デフォルトの名無しさん
09/06/05 01:53:58
>>86
好きなプログラミング言語はなんですか。
よく利用するプログラミング言語はなんですか。
趣味で使うプログラミング言語はなんですか。
やっぱりシンプルなC言語ですか。
89:デフォルトの名無しさん
09/06/05 02:01:26
好きな言語はCだ。趣味ではlispをよく使うな。
お前らも努力すればハッカーになれるから頑張れ。
90:a36 ◆K0BqlCB3.k
09/06/05 02:21:42
ノイマン型コンピュータを扱っているなら、たとえ関数型言語を使っていたとしても最終的には手続き的な考え方をせざるを得ない。
ノイマン型コンピュータの仕組み自体が手続き的なのだから。
91:デフォルトの名無しさん
09/06/05 05:44:21
この辺で纏めてgc
92:デフォルトの名無しさん
09/06/05 08:31:50
>>89
こいつはとんだインチキハッカーだな。
どこかでハッカーは、 Cとlispを使うとでも洗脳されたのだろうか。
自分の利用する言語の正式名称も言えないなんてハッカーの資格無しだ。
lispってなんだよ。あのMITのトイレで生まれたというevalとatomとlistのことか。
どれだけ方言があると思っているんだよ。
93:デフォルトの名無しさん
09/06/05 10:33:43
そもそもコンピュータ自体が質的に有限なので
オブジェクト指向とかは作法の違いにすぎず、
本質的な違いはない。
94:デフォルトの名無しさん
09/06/05 10:58:05
～なので～にすぎず～はない。論理の飛躍。無根拠。
～とかは。焦点があいまい。
95:デフォルトの名無しさん
09/06/05 13:40:50
ジャンケンプログラムで、審判オブジェクトが必要とか未だにようわからん
96:デフォルトの名無しさん
09/06/05 13:54:25
グーチョキパーが互いに知り合って、
それぞれが勝ち負けを判断するような密な結合より、
グーチョキパーの関係性を記述するために特化したMediatorオブジェクトを用意し、
グーチョキパー事態は互いを知らなくていい、
ポーとかペーとかが発生した場合に修正を個々にしなくていい、
という緩い結合にしておくことに、そこにメリットを見出すため。
97:デフォルトの名無しさん
09/06/05 13:54:52
後だしする奴とかいるから、ちゃんとジャッジしてくれる人がいたほうがよくね？
98:デフォルトの名無しさん
09/06/05 14:04:30
>>96
単に独立した判定役がいればいいわけで,
object とか class じゃなくてもええんちゃう
CLOS 的には審判 object(審判 class)は作らんな, たぶん
99:デフォルトの名無しさん
09/06/05 14:19:00
>>93
有限/無限は量概念なのに、「質的に有限」ってw
100:デフォルトの名無しさん
09/06/05 14:31:33
>>95
審判作りたくないのなら、
プレイヤー同士で判定して、合意の下に
勝負を付ける仕組みでいいんじゃないか？
101:デフォルトの名無しさん
09/06/05 14:35:58
>>98
じゃんけん大会の内容に応じて取り替えられればいいだけなんで、
別にobjectでもええんちゃう
102:デフォルトの名無しさん
09/06/05 14:47:27
「構造化しないで上から下に書いていけばいいんちゃう？」
と言うのと同じな気がしてきました。
103:デフォルトの名無しさん
09/06/05 19:01:47
>>95
変化とか量産とかが無いとオブジェクト指向で書くメリットはあんまりないよ
グーチョキパーの勝ち負けのルールが変わるとか
非同期で同時に100個のジャンケン判定しないといけないとか
そういうのが無いと
104:デフォルトの名無しさん
09/06/05 19:33:20
ここで話すオブジェクト指向て実装面だけか？
設計だけオブジェクト指向でやって実装はオブジェクト指向にしないって現場もあるが。ゲーム開発とか。
105:デフォルトの名無しさん
09/06/05 20:19:04
>>104
設計と実装を分けて論じてはいけないスレです。
106:デフォルトの名無しさん
09/06/05 20:27:05
もし設計と実装が無関係なら、なんのために設計するんだ？
107:デフォルトの名無しさん
09/06/05 20:36:30
抽象レベルが違うのだから、いっしょくたに論じるほうがよほど問題だろ
108:デフォルトの名無しさん
09/06/05 20:43:23
多様性が必要無いならオブジェクト指向ってのは意味が無いどころかマイナスだ
109:デフォルトの名無しさん
09/06/05 21:30:19
要するに、異なる抽象レベルが互いに影響し合うシステムが
同じソースコードにいっしょくたに書かれてるんで
ソースコードから特定の抽象レベルだけを抽出したものを論じるなり何なりすればいい
110:デフォルトの名無しさん
09/06/05 21:38:41
それ「要するに」してない
それ以前に日本語してない
111:デフォルトの名無しさん
09/06/05 23:20:25
>>104
常識的に考えたら、設計がオブジェクト指向なら実装もオブジェクト指向じゃないの？
オブジェクト指向言語（機能）を使わない、オブジェクト指向実装じゃないの？
112:デフォルトの名無しさん
09/06/05 23:31:40
>>104
実際にオブジェクト指向の設計をどう非オブジェクト指向な実装に落とすのか
具体例を出してもらえる？
113:a36 ◆K0BqlCB3.k
09/06/05 23:33:55
>>112
つ コンパイラ
114:デフォルトの名無しさん
09/06/05 23:42:30
>>113
それはレイヤーが違う。
設計->ある言語による実装と、ある言語での実装->バイナリを混同するな。
115:デフォルトの名無しさん
09/06/06 00:35:06
メッセージングはインターネットのような広い空間の緩い結合には適してる。
でも、プログラムの世界はもっと情報同士が密結合で信頼性も高い。
そういう世界でオブジェクトみたいな殻を作ると、無駄な伝言と依存性の不透明さが増して、
弊害が大きいと思うんだよね。
特にすべてがオブジェクトとか言われると。
# それはおまえの設計が悪いとか言わないでね。
# 不都合な事は全部設計が悪くてOOのせいじゃないというセリフは聞き飽きた。
116:デフォルトの名無しさん
09/06/06 00:43:53
少々プログラムの効率性犠牲にしてでもコード中に秩序を作り上げた方が生産性が高まることは多々あるわけで。
すべてがオブジェクトというやり方も、それが常にベストな解では無いと思うが、
LLなどではそういうやり方もありだろう。
117:デフォルトの名無しさん
09/06/06 00:47:37
>>116
いや、私が言いたいのは効率の話じゃなくて。
メッセージングやオブジェクトという仕組みでは、プログラムの秩序がより乱されてる
だけだと思う訳です。
118:デフォルトの名無しさん
09/06/06 00:56:28
すべてがオブジェクト、とかで作ると、でしょ？
それぞれに適した書き方すればいいんじゃないの
汚い部分を一手に引き受けるクラスとかがあっても問題ないでしょ
デザインパターンのfacadeみたいな
119:デフォルトの名無しさん
09/06/06 01:02:11
>>115
メッセージングはいいけど、たとえばJavaやSmalltalkでのオブジェクト間のメッセージングはただの関数呼び出しだよね？
たくさんのオブジェクトが存在する中で、実行中なのが常に一つっていうのはちょっと変じゃないのって話。
それって実世界の間隔とはかけ離れているよね。
120:デフォルトの名無しさん
09/06/06 01:03:30
×間隔
○感覚
121:デフォルトの名無しさん
09/06/06 01:09:48
オブジェクト云々の話は置いとくとしても、結合度は下げた方がいいと思うんだが。
「なんでも自由にお触りください」というものを使ってきれいに仕上げるのには
強い心が必要になるけど、あらかじめ「可能な操作はこれだけです」と決めておけば
心の支えにはなるでしょ。
122:デフォルトの名無しさん
09/06/06 02:25:26
>>115
前半はいまいち理解できない(普段そのように感じてはいない)けど、後半は納得。
> 特にすべてがオブジェクトとか言われると。
特にこういう部分がOO(の教祖、信者)のダメなところだと思う。
以前会社の後輩が設計、実装したプログラム(C++)では、
普通の数学的な意味の関数を作るだけですむような計算処理を、
あえてクラスとして実装していた。
このため、計算処理を行うためには、そのクラスのインスタンスを生成し、
そのインスタンスのメソッドを呼ばなくてはならなかった。
(そのメソッドを呼んだあとはインスタンスは用済みなのでインスタンスの破棄まで
しなければならない。)
123:デフォルトの名無しさん
09/06/06 03:28:02
いや、仮にOOPの信者でもそういうのは普通に関数にしたり
ユーティリティクラスにしたりすると思うんだが。
問題は後輩がOOPの信者だったことではなくて、単に経験が
足りなかったことなのではないかと。
124:デフォルトの名無しさん
09/06/06 03:48:11
>>122
普通そういうのはnamespaceに閉じ込めた関数にするか、OO信者でどうしても
クラスにしたかったとしてもstaticメソッドにするはず。
C++をあまり知らないから何でもインスタンスメソッドにしたがるんだろう。
125:デフォルトの名無しさん
09/06/06 07:28:12
シナリオ書いてクラス図やインタラクション図を起こして、
一旦OODで機能とデータを洗い出してから、
機能毎にモジュールを切り直してCで実装、
ってのは結構ありがちなパターンだったりする。
126:デフォルトの名無しさん
09/06/06 09:02:38
staticメソッドの無い言語って多分無いからな
つまりはそういうことだ
Needless Complexityは避けろって普通は言われる
127:デフォルトの名無しさん
09/06/06 09:29:30
まあ、普通の関数ですむと思ってるのは自分だけで
文字列操作のように、関数にするよりもクラスにして操作するほうが自然な物だったりしてな
128:デフォルトの名無しさん
09/06/06 10:16:19
プログラム内のある意味のある塊をどうまとめるか。
オブジェクトというまとめ方しか知らない・出来ないのは不幸だ。
129:デフォルトの名無しさん
09/06/06 10:18:03
日本人は「自分だけ」に弱い。
130:デフォルトの名無しさん
09/06/06 11:35:10
「俺の周りは」なんて言ってる奴には、永遠に理解できないもの
それが、オブジェクト指向
131:デフォルトの名無しさん
09/06/06 12:23:50
Eiffelｻｲｺｰ!!!!!!!!!!!!!
132:デフォルトの名無しさん
09/06/06 12:41:53
「実はただの関数呼び出しだよね？」と聞くと、
「関数呼び出しにたとえるのはダメ」と言われることがある。
関数呼び出しを使わないOOPの実装もありえると言いたいんだろう。
でも、一般論の前にまず特定の実装を知るべきだよな。
一般論だけを語りたがる風潮にも問題があると思う。
133:デフォルトの名無しさん
09/06/06 13:57:18
関数を動的に探索して、適切な関数を呼びだす、
ということを実行時におこなうのが普通の「関数呼び出し」だと主張するのなら、
OOPLでのメッセージ送信の多くの実装は関数呼び出しと言えるかもしれないけどね。
実際には普通の「関数呼び出し」では呼び出される関数はコンパイル時に確定しているから、
OOPLでのメッセージ送信の多くの実装は単なる関数呼び出し以外のこともやっているよね。
134:デフォルトの名無しさん
09/06/06 14:02:00
>>133
>>119
135:デフォルトの名無しさん
09/06/06 14:05:04
はあ？
>>133は>>119への反論だと思うが？
136:デフォルトの名無しさん
09/06/06 14:09:41
自分で処理系を書いたことがない人は>>119みたいな発想になるんだろうな。
137:デフォルトの名無しさん
09/06/06 14:13:58
>>130
永遠に理解できないなんて、なんてえらそうな技術。
それがオブジェクト指向という宗教。サイエンスのかけらもない。
138:デフォルトの名無しさん
09/06/06 15:09:22
>>136
処理系はバリバリ書いてきた方が、
それはともかくとしてなんで処理系を書いたことがないと>>119みたいな発想になると思うのか、
その論理のつながりが解らん。
139:デフォルトの名無しさん
09/06/06 15:15:13
お前らの頭悪そうなレス見てると優越感に浸れる
ありがとう
140:デフォルトの名無しさん
09/06/06 15:15:36
つーかメッセージングか関数呼び出しかについては前スレで終わったんじゃないの？
前スレで出ていないような新規の主張をするならいいが、そうとは思えないぞ。
141:デフォルトの名無しさん
09/06/06 16:53:14
>>138
実際には処理系を書いたことがないから、わからないんじゃないかなあw
142:デフォルトの名無しさん
09/06/06 17:11:59
>>141
俺にはお前が口先だけの奴に見える
143:デフォルトの名無しさん
09/06/06 17:18:25
>>142
では、インターフェース型の変数がメッセージレシーバになっている場合の
メッセージ送信をおこなうために必要な処理をCで書いてみなさい。
同様に、簡易版でいいからC風の言語のコンパイラも書いてみなさい。
この2つの実装がまるで別物だということがよく理解できるから。
144:デフォルトの名無しさん
09/06/06 17:19:03
>>143
できるが、お前の態度が気に入らない
145:デフォルトの名無しさん
09/06/06 17:20:50
技術への攻撃が続かなくなったから、
今度は人格攻撃ですか。なるほど。
146:デフォルトの名無しさん
09/06/06 17:22:47
誰が見ても>>143の態度は気に入らないだろうな。
それ以前に言ってることが意味不明だし。
147:デフォルトの名無しさん
09/06/06 17:25:25
>>143
もったいぶらずに違いを教えてくれよ（*´∀｀*）
さあさあ。
148:デフォルトの名無しさん
09/06/06 17:26:37
確かにもったいぶり過ぎだな
本当にこいつは自分が言ってることが解って言っているのかと疑問に思えてくる
149:デフォルトの名無しさん
09/06/06 17:28:14
こんなクソスレでコンパイラ書けなんて言われて書く奴がいるかっつーの。
こういう非現実的なことを押し付けようとする奴って何様なんだろうかね。
150:デフォルトの名無しさん
09/06/06 17:28:47
>>143読んでわからないようなら能力がないからこの業界から足を洗ったほうがいい。
本人も周りもそのほうが幸せになれる。
151:デフォルトの名無しさん
09/06/06 17:29:12
コンパイラ作成系の本読んだところで
それっぽいこと語りたいガキだろ
152:デフォルトの名無しさん
09/06/06 17:29:29
erlangとかのメッセージ送信を見ればオブジェクト指向のメッセージングのモデルがいかに不自然かわかるだろ。
そもそもオブジェクト指向はメッセージングじゃない。
ただの関数呼び出しだ。
153:デフォルトの名無しさん
09/06/06 17:29:47
Cardelli厨の再来か？
154:デフォルトの名無しさん
09/06/06 17:30:48
>>150
早く「俺はまだまだ未熟でした、ごめんなさい」と言えよｗ
潔く負けを認めないかぎり、お前のスキルは一歩も前に進めないんだぞ。
155:デフォルトの名無しさん
09/06/06 17:36:17
最終的には「リンク先読め」「本読め」だの言ってお茶濁すやつ多いなｗ
自分の言葉で簡潔に表現できないｗ
あと、文章を引用してきて朗読するだけとかｗ
156:デフォルトの名無しさん
09/06/06 17:39:24
>>152
> そもそもオブジェクト指向はメッセージングじゃない。
> ただの関数呼び出しだ。
それを言うのなら、
「そもそも現在のOO実装は関数呼び出しがベースになっているから、
メッセージングによる本来のオブジェクト指向じゃない」
だろう。
157:デフォルトの名無しさん
09/06/06 17:43:22
そもそもメッセージングを厳密に実装してなんか良いことあんの？
158:デフォルトの名無しさん
09/06/06 17:43:54
必要なものはただの関数呼び出し。
だから、本来のオブジェクト指向は必要ないんだな。
>>127
関数が外部の変数に依存しないときは関数を作る。
関数の外側の変数を使いたいときはクラスを作る。
これで間違いない。
159:デフォルトの名無しさん
09/06/06 17:45:26
メッセージ送信という抽象モデルと、
メソッド探索＋関数呼び出しという実装を、
ごちゃごちゃにするから混乱してるんじゃね？
160:デフォルトの名無しさん
09/06/06 17:46:27
>>158
たぶんお前が一番レベル低い。
161:デフォルトの名無しさん
09/06/06 17:48:21
>>159
そういうことだな
162:デフォルトの名無しさん
09/06/06 17:48:24
>>158
> 関数が外部の変数に依存しないときは関数を作る。
> 関数の外側の変数を使いたいときはクラスを作る。
キミ、どこの土方よ？
163:デフォルトの名無しさん
09/06/06 17:50:17
オブジェクトAとオブジェクトBがそれぞれ別スレッドで動作してるとき、
AからBに(関数呼び出しによる)メッセージを送ったばあい、Bのメソッドを実行する実体は
Aのスレッドだったりして、そういうのが気持ち悪いと思うことはある。
164:デフォルトの名無しさん
09/06/06 17:53:09
非同期管理はまた全然別の話だろう
165:デフォルトの名無しさん
09/06/06 17:54:05
ちょくちょくスレッド間の同期を混ぜるやつが居るなｗこのスレにはｗ
166:デフォルトの名無しさん
09/06/06 17:55:44
>>162
レッテルを貼るだけでは何の意味もないだろ
167:デフォルトの名無しさん
09/06/06 17:55:59
この中でerlangをさわったことがある人、もしくはpi-calculusを勉強したことがある人はいるの？
168:デフォルトの名無しさん
09/06/06 17:59:02
>>167
俺は、無い！（´；ω；｀） 一番処理系に近づいたのはRHGを読書した時ｗ
169:デフォルトの名無しさん
09/06/06 18:09:27
>>159
実装と無関係な抽象モデルを作っても無駄じゃないの
関数呼び出し前提でモデル作ればいいじゃん
170:デフォルトの名無しさん
09/06/06 18:16:50
>>143
コンパイラ書けとか言うなら、せめてお前さんがASTに落とすまでのフロントエンドと
中間形式に変換した以降のアセンブリコードを吐くまでのバックエンドを自分で
書いて用意したらどうだ？これらの部分はお前さんの主張を「理解させる」上で
本質的ではないからな。
人にやれと言うくらいだから、この程度は簡単に書けるだろ？
171:デフォルトの名無しさん
09/06/06 18:27:12
>>169
実装ありきでモデルを作るんじゃなくて
まずモデルがあってそれを実現するために実装があるんだぞ
172:デフォルトの名無しさん
09/06/06 18:42:40
>>171
デスマを防ぐためにモデルを作るっていう発想はないんだな
絶望した
173:デフォルトの名無しさん
09/06/06 18:42:55
erlangって変数を設定したら２度と値を変えられないんだよね。
頭が硬くてプログラムを作れなくて使うのをあきらめますた。
174:デフォルトの名無しさん
09/06/06 18:43:08
？？？
175:デフォルトの名無しさん
09/06/06 18:53:40
>>172
そうじゃなくてモデルを作る時は
実装時に変な足かせになったりしないように抽象的な書き方をするのが基本だろ
論点ずらしもいいとところだぞ
176:デフォルトの名無しさん
09/06/06 18:59:59
>>175
関数呼び出しを前提にすることが、変な足かせになるの？
177:デフォルトの名無しさん
09/06/06 19:37:18
erlangは知らんが、ScalaのActorみたいなのがオブジェクト指向の
メッセージパッシングの理想型だったりするのか？
オブジェクトがそれぞれ別のスレッド（もどき）で動いてて、それぞれの
メールボックスに入ってるメッセージを順次読み出して実行・返信みたいな。
178:デフォルトの名無しさん
09/06/06 21:23:35
あーまだやってたのか
結局 OO なんてのは「明確な定義もないただの幻想」
ってのが、前スレの結論じゃなかったのか？
179:デフォルトの名無しさん
09/06/06 21:30:10
「前スレの結論」っていうのは大抵、
前スレで一番最後に目立っていた香ばしい強弁のことだよね。
180:デフォルトの名無しさん
09/06/06 21:31:13
「前スレで俺が言ったこと」だろ
181:デフォルトの名無しさん
09/06/06 21:43:08
じゃ、誰か OO の明確な定義をしてみてくれよwW
182:デフォルトの名無しさん
09/06/06 21:45:00
関数がない言語は少ないが、クラスがない言語はたくさんある。
クラスが役に立たないわけじゃないが、
クラスに似た方言がたくさんあって統一できてない感じがする。
183:デフォルトの名無しさん
09/06/06 21:53:49
大学出てる奴いないだろｗ
お前らは市販の参考書でお勉強した程度のレベルだ
184:デフォルトの名無しさん
09/06/06 21:55:37
> 大学出てる奴いないだろｗ
それは暴言だろ?
Fランだって大学は大学だろうに…
185:デフォルトの名無しさん
09/06/06 22:16:28
λ計算、オートマトン、関係代数、述語論理、π計算、グラフ理論など
まともな議論が出来る土台がソフトウェア技術を大幅に進歩させている中、
OOに関する議論はメッセージだのオブジェクトだのカプセル化だの、相変わらず不明確で不毛な論争が続くのみ。
これはOOが属人的なノウハウの域を脱していない証拠。
さて、ではOOをまともな議論の土台に載せるにはどうすればいいのでしょう？
やっぱりσ計算？
186:デフォルトの名無しさん
09/06/06 22:17:29
σ計算 ＝ 型理論 ＋ 操作的意味論
187:デフォルトの名無しさん
09/06/06 22:18:03
そもそも大学でオブジェクト指向とか教えてるのか？
188:デフォルトの名無しさん
09/06/06 22:34:31
>>186
操作的意味論があるなら、そこからクラス設計の優劣が定量的に計れたりしないだろうか？
総合的なものじゃなくても、特定の側面（結合度とか）だけでもいいので。
そういう論文が読みたい。
189:デフォルトの名無しさん
09/06/06 22:56:09
凝集度ならcohesion metricsで検索すればそれらしいものがでてくる
190:デフォルトの名無しさん
09/06/06 23:11:13
>>189
ありがとう。こんなに親切な御仁がいるとは思わなかった。
実はσ計算についても殆ど何も知らないので、OOの特徴(例えばMLのモジュールとの違い）を
σ計算の言葉で言い直すことができる事を期待して勉強してみます。
五十嵐先生まんせー。
191:デフォルトの名無しさん
09/06/06 23:18:41
σ計算について詳しい本なんてこれぐらいしか知らない
Amazon.com: A Theory of Objects (Monographs in Computer Science): Martin Abadi, Luca Cardelli: Books
URLﾘﾝｸ(www.amazon.com)
簡単に概要を知るだけならLuca CardelliのサイトのPaperの
Objectカテゴリにある論文を見ればいいんだけど
192:デフォルトの名無しさん
09/06/06 23:26:44
>>185
> さて、ではOOをまともな議論の土台に載せるにはどうすればいいのでしょう？
> やっぱりσ計算？
それ以前に OO の明確な定義付が必要だってば
何見てもオレオレ定義じゃん
193:デフォルトの名無しさん
09/06/06 23:32:13
URLﾘﾝｸ(lucacardelli.name)
ベースはFω<:かぁ。ふむふむ。
194:デフォルトの名無しさん
09/06/06 23:38:57
>>192
まともに議論できる土台であるσ計算の言葉でOO（に似たなにか）を言い替えてみる。
↓
これをOOの定義にしよう！（というコンセンサスが広がる）
↓
うまー
195:デフォルトの名無しさん
09/06/06 23:51:27
ちなみに、さっきから教えて君している私は学生でも院生でもなく、
職業プログラマなので、学生乙は禁止。
196:デフォルトの名無しさん
09/06/07 01:50:45
Software Engineering != Computer Science
URLﾘﾝｸ(www.ddj.com)
この人は学者じゃないが、まあ言ってることは大体正しいな。
197:デフォルトの名無しさん
09/06/07 02:11:53
懐かしい、DDJじゃないか。
日本でも雑誌出してたよな。
198:デフォルトの名無しさん
09/06/07 05:35:37
オブジェクト指向ってのはスパゲッティ指向をカッコヨク表現したものなんだよ
199:デフォルトの名無しさん
09/06/07 08:07:29
DDJの記事についてスラドで話題になってるな。
いきなりCを関数型言語だとか言う奴がいたり、それに食ってかかる奴等がいたり
このスレに似てるな。
URLﾘﾝｸ(tech.slashdot.org)
200:デフォルトの名無しさん
09/06/07 08:11:23
>>126
VBScript(否.NET)なめんな
201:デフォルトの名無しさん
09/06/07 11:53:58
>>198
スパゲティ指向ってのは言いえて妙かもしれない
202:デフォルトの名無しさん
09/06/07 12:33:10
茹でる前のスパゲティが理想なのに、気が付けば茹で上がったスパゲティって事か?
203:デフォルトの名無しさん
09/06/07 12:54:04
だとしても生麺なんて食いたくないね
204:デフォルトの名無しさん
09/06/07 12:58:05
OOはOOPだけにして、柔軟性と抽象化のためのテクとして受け取ればよかった。
分析と実装がどうの、現実世界＝オブジェクト、メッセージがうんたら、
これをばっさり捨てたらよかったのにね。
205:デフォルトの名無しさん
09/06/07 13:00:33
それがDbC
ユーザ定義の抽象型上の動的多態と拡張されたホーア論理を使ったよる制約プログラミング
206:デフォルトの名無しさん
09/06/07 13:16:43
お歳暮に渡すソーメンを買ってきたのに
何故か、そのソーメンで昼飯を作っちゃうみたいなwwww
207:デフォルトの名無しさん
09/06/07 14:53:38
>>204
> 分析と実装がどうの
この人たち OO を出せば客が尊敬してくれると思ってる連中だと思うよ
一昨年かな、急遽、長年付き合いのある映像関連のシステム作ってる
会社の手伝いをする羽目になった。
内容としては「既にあるシステムの出力フォーマットをMP4でラップしたい」だった
最初に頼んだところは、「いまから OO 分析してどーたらこーたら」と言うばかりで
実質的には何もしなかったそうだW
208:デフォルトの名無しさん
09/06/07 15:47:00
オブジェクト指向とそれ以外の違いなんて
instance.method()とmethod(instance)の違いくらいしかないんじゃないの？
209:デフォルトの名無しさん
09/06/07 15:53:55
CLOS では (method instance) なわけだが
210:デフォルトの名無しさん
09/06/07 15:58:20
>>208
そういう不用心な事を言うと、マルチプルディスパッチこそがOOの肝だろうが、
って言われちゃうぞ。
211:デフォルトの名無しさん
09/06/07 16:41:26
・カプセル化
・継承
・ポリモーフィズム
212:デフォルトの名無しさん
09/06/07 17:20:38
いまだにカプセル化とか言うアホがそんざいするんだ
213:デフォルトの名無しさん
09/06/07 17:33:44
>>212
カプセル化とか言うアホとは？
214:カプセル化
09/06/07 17:34:49
俺俺、俺のこと
215:デフォルトの名無しさん
09/06/07 17:40:19
ゴガギーン
ドッカン
ｍ ドッカン
＝＝＝＝＝） ）) ☆
∧_∧ | | ／ ／￣￣￣￣￣￣￣￣￣￣￣
（ ）| |＿＿＿＿＿ ∧＿∧ ＜ おらっ！出てこい>>212
「 ⌒￣ | | || （´Д｀ ） ＼＿＿＿＿＿＿＿＿＿＿＿
| / ￣ | |/ 「 ＼
| | | | || || /＼＼
| | | | | へ//| | | |
| | | ﾛ|ﾛ |／,へ ＼| | | |
| ∧ | | | |／ ＼ / （ ）
| | | |〈 | | | |
/ / / / | / | 〈| | |
/ / / / | | || | |
/ / / / =-----=-------- | |
216:デフォルトの名無しさん
09/06/07 17:47:52
カプセル化機能のないOO言語って山ほどあるのに…
クラス定義でアクセス属性決定する意味あるのか?
217:デフォルトの名無しさん
09/06/07 18:13:30
アクセス属性が必要ないのに、アクセス属性が付いてるって?
ご冗談をwww
218:デフォルトの名無しさん
09/06/07 18:15:29
private/publicとかの存在意義に疑問を投げかけてるのか・・・？
219:デフォルトの名無しさん
09/06/07 18:18:42
>>215
|┃三 ／￣＼
|┃ | |
|┃ ＼＿／
ｶﾞﾗｯ. |┃ |
|┃ ﾉ// .／￣￣￣ ＼
|┃三 ／ ::＼:::／:::: ＼
|┃ ／ <●>::::::<●> ＼
|┃ | （__人__） |
|┃三 ＼ ｀ ⌒´ ／
|┃三 ／￣￣￣￣￣￣￣ ＼
220:デフォルトの名無しさん
09/06/07 19:07:16
お前らの話のどこがおもしろいのか解らん。
議論してる奴らもUMLとC/C++とJavaぐらいしか知らない奴ばっかりっぽいから、
知識不足で底が浅い議論になってるように見える。
221:デフォルトの名無しさん
09/06/07 19:08:12
話に面白さを感じるには、一定の知能が必要だな。
222:デフォルトの名無しさん
09/06/07 19:59:43
その一定の知識ってハードルがすごく低いんだと思うよｗ
223:デフォルトの名無しさん
09/06/07 20:05:52
どうせ2chじゃまともな議論にならないしな。
他でやれば結構面白い議論に発展するかもしれんが。
224:デフォルトの名無しさん
09/06/07 20:25:53
こんなところで議論とかｗ
225:デフォルトの名無しさん
09/06/07 21:57:07
ぶぴぶぴ
最高だ この力・・・
226:デフォルトの名無しさん
09/06/07 22:06:55
中を見えなくするとか隠蔽とか言われても中知りたくなる件ｗ
227:デフォルトの名無しさん
09/06/07 22:19:27
好きな子のパンツはやっぱり見たいよな
228:デフォルトの名無しさん
09/06/07 22:39:06
・カプセル化したければinterfaceを使い、classは全部公開
・継承はinterfaceのみ可
・ポリモーフィズムは↑に反しない限り自由
229:デフォルトの名無しさん
09/06/07 23:00:04
>>228
それはww構造的www部分www型ww
230:デフォルトの名無しさん
09/06/07 23:14:46
お前らOOPの影響で不況になったの解ってる？
OOPが原因でアウトソーシングなんて発生したんだよ？
231:デフォルトの名無しさん
09/06/07 23:33:59
こら！
なんでもかんでもオブジェクト指向のせいにするな アホ
OOを使う人間が無能だっただけでOOが悪いわけじゃないということにいい加減きづけよな
232:デフォルトの名無しさん
09/06/07 23:46:22
>>231
実際経営者というか管理の上流は
OOすることにより、製造業の部品が簡単に作れると勘違い
するようになった。もう複雑なOSなんて知らなくてもいいし
OOするだけで製造コストが劇的に下がると妄想を抱くようになった。
もし構造化のみだったらそんなこと無かったよ
コンサルなんて意味のない職業が台頭することもなかったし
管理のみの上流工程とか意味のない職種も誕生しなかった
全てがC++やJavaなどに代表されるOOがもたらした弊害でしょ
ジョエルもJavaスクール（笑）の影響でITがおかしくなったと言ってるぞ
金融破たんだって、JavaなんかのOOで簡単かつ乱雑にマネーゲームを
しかけることができるのが原因の１つだし
OOが無ければこれだけ異常な下請けや不況は起きなかった
233:デフォルトの名無しさん
09/06/07 23:52:41
多重下請け構造とアウトソージングは別物のような…
日本の業界だと一緒くたにされがちだけど
234:デフォルトの名無しさん
09/06/07 23:57:32
弊害といえば弊害だけど
最後の方はさすがに飛躍し過ぎ
235:デフォルトの名無しさん
09/06/07 23:58:28
経営者はooとかしらないよw
なぜかというと、彼らは
236:デフォルトの名無しさん
09/06/08 00:04:23
>>231
>OOを使う人間が無能だっただけでOOが悪いわけじゃない
もう聞き飽きたよ、そのセリフは...。
はいはい、私は無能です。
237:デフォルトの名無しさん
09/06/08 00:09:18
それに見てみろ
Javaなんかはバージョン上がる度にがどんどん複雑になるが生産性が
Java1.3や1.4の頃とかわらない
Rubyなんて10年前からあるけど脚光浴びてるだけで
なんら普通の生産能力しかない。むしろ無い部品が多いから
キャッキャとエテコウのようにオナプロ実装しているに過ぎない
そしてC++はいまだに0xの仕様を最終局面まで詰めれないし
このまま永遠に仕様策定ごっこして終わり
つまりだ、OOはその仕組みを作ることからして莫大で無駄な時間を浪費
する悪魔でしかないのだよ。技術の技術として仕上げていくことに対して
OOは無駄なことが多い単なる技術屋が金を長期間搾取できるための悪材料
でしかないんだよ
238:デフォルトの名無しさん
09/06/08 00:11:44
>Rubyなんて10年前からあるけど脚光浴びてるだけでなんら普通の生産能力しかない。
普通筏と思われ。
239:デフォルトの名無しさん
09/06/08 00:17:53
で、
240:デフォルトの名無しさん
09/06/08 00:24:16
っていう
241:デフォルトの名無しさん
09/06/08 07:44:14
>>232
> もし構造化のみだったらそんなこと無かったよ
> コンサルなんて意味のない職業が台頭することもなかったし
コンサルは構造化以前から台頭していましたが何か？
> 管理のみの上流工程とか意味のない職種も誕生しなかった
ウォーターフォールは構造化以前から存在していましたが何か？
> OOが無ければこれだけ異常な下請けや不況は起きなかった
メインフレーム時代はもっとひどかったぞ。
242:デフォルトの名無しさん
09/06/08 08:01:50
OOA/OODって、結局現実世界のメタファーを使うことで、計算機科学を全く
理解していない素人が分かった気になってコンサルタントとか名乗り出して
美辞麗句を並べた。で、経営者もそれに騙されて無駄金使った挙句、結局
ろくな成果が出なくてOO自体が忌み嫌われる存在になってしまったのが
一番の悲劇だろうな。
OOのテクニック的には基本的に構造化の延長だし、そこまで筋は悪くないのに。
243:デフォルトの名無しさん
09/06/08 09:03:58
憂鬱本の方がOOSCより売れたという時点で南無…
244:デフォルトの名無しさん
09/06/08 09:18:45
OOSCたけぇ～もん。値段分の価値はあると思うけど。
245:デフォルトの名無しさん
09/06/08 09:22:21
言語によって実装方法が違ったこと。
滅茶苦茶な翻訳、訳語の混乱があったこと。
更にオレオレオブジェクト指向が大量に出現したこと。
混乱がありすぎた。
246:デフォルトの名無しさん
09/06/08 09:28:08
>>232にはオブジェクト指向が理解できないであろう事は良く分かった
247:デフォルトの名無しさん
09/06/08 09:42:24
OOには、goto的なものが多すぎる。
便利な機能を使いすぎると、かえって複雑になる。
バランスが非常に難しい。
C++なんて、マルチパラダイムとか言ってるが正気じゃない。
あれもこれも詰め込んだら、普通の人には適材適所で使うのが難しい。
248:デフォルトの名無しさん
09/06/08 10:14:00
>>247
× 普通の人には
〇 土方の人には
249:デフォルトの名無しさん
09/06/08 12:10:35
OOではなくて関数型の言語の方が良い、っていう意見もここで
よく見るけれども、それほど良いものならなぜOOPLを駆逐して
広く普及しなかったのだろう? 皮肉ではなく、純粋な疑問として。
250:デフォルトの名無しさん
09/06/08 12:24:27
マイクロソフトが関数型言語を出さなかったから。
関数型言語なんて知らなくても使えるようにならないと流行らないよ。
251:デフォルトの名無しさん
09/06/08 12:24:47
>>249
ポピュラーなオブジェクト指向言語はC++やJavaなどのCの派生言語だから。
MLやHaskellなどは考え方を結構変えないと理解しがたいから、取っつきにくかったから。
252:デフォルトの名無しさん
09/06/08 12:26:10
>>250
MSができる前から関数型言語は存在したけど、PascalやCよりずっとマイナーだった。
253:デフォルトの名無しさん
09/06/08 12:32:33
schemeをほんの少しだけ触ったが括弧に混乱した
アレは人間の扱うもんじゃないと思うｗ
254:デフォルトの名無しさん
09/06/08 12:38:21
>>247
> OOには、goto的なものが多すぎる。
具体例を挙げよ (2点)
255:デフォルトの名無しさん
09/06/08 12:42:05
手続き型言語に慣れた人には関数型言語はとっつきにくいから。
そしてLispのシンタックスが抽象構文木そのものだったというのも
一般に広めるという上では仇になったと思う。
関数型も慣れれば非常に快適なんだけどね。
256:デフォルトの名無しさん
09/06/08 12:45:03
論理プログラミング言語はSQLって形で広まってるよ☆
257:デフォルトの名無しさん
09/06/08 12:47:49
ＳＱＬはプログラミング言語ではありません
知ってるプログラミング言語は何って聞かれてＨＴＭＬって答えるタイプ？ｗ
258:デフォルトの名無しさん
09/06/08 12:52:43
>>256
SQLはDBからデータをざっくり(下手すりゃ全行)引っ張るのだけに
使って、あとはJava等々で手続き的に処理したがる御仁も多いよう
ですが・・・手続き型の呪縛は強い。
259:デフォルトの名無しさん
09/06/08 13:00:51
教育とか普及度もあるだろうけれども、シンプルに人間の脳は
関数型より手続き型言語の方が理解しやすいように出来ているの
だと思う。関数型言語を使うには一段階脳の改造というか訓練を
必要とするというか。
260:デフォルトの名無しさん
09/06/08 13:22:25
短期記憶の容量が少ない奴は関数型言語に向いてないってこった。
261:デフォルトの名無しさん
09/06/08 13:24:42
短期記憶の容量を大きく要求しない手続き型スゲー。
262:デフォルトの名無しさん
09/06/08 13:26:52
>>260
つまり関数型言語が普及しない理由は短期記憶の容量が少ない奴
が多いからであると。
それなら初めっから普及の面で関数型に勝ち目なんて無いじゃん。
263:デフォルトの名無しさん
09/06/08 13:32:07
>>261
短期記憶の容量が少なくて済む代わりに、型バグ・副作用バグに悩まされるんだよね。
264:デフォルトの名無しさん
09/06/08 13:33:41
関数型言語が普及したら低学歴が業界から減ってくれそうでうれしい
265:デフォルトの名無しさん
09/06/08 13:35:11
低学歴だけじゃないな
ご隠居さんの戯れ言や長老達の世迷い言からも解放される
266:デフォルトの名無しさん
09/06/08 13:38:48
短期記憶ができないなら紙の上で色々式変形すりゃいいじゃん
267:デフォルトの名無しさん
09/06/08 13:39:59
>>266
どっちにしろラムダ計算を知らない奴らには荷が重いだろ。
268:デフォルトの名無しさん
09/06/08 13:41:07
関数型言語大好きなご隠居さんも大量にいるんだけど…
しかも実務経験に乏しいのとか…
269:デフォルトの名無しさん
09/06/08 13:46:07
>>268
そういうのは大学とかIT系以外に多いんじゃね？
270:デフォルトの名無しさん
09/06/08 13:48:07
なんだか関数型言語を使ったこと無い奴が多いようだけど、
情報系の学科で関数型言語を使った講義が無い大学ってあるのか？
それとも文系上がりのなんちゃってOOプログラマが多いのか？
271:デフォルトの名無しさん
09/06/08 13:51:59
理系学部出てプログラマになる奴なんて情報系でも少数派
272:デフォルトの名無しさん
09/06/08 13:53:36
そもそもOO言語ってSmalltalkとかでしょ？
関数型よりユーザー少ないような
273:デフォルトの名無しさん
09/06/08 14:07:18
>>271
職業プログラマじゃなくても仕事でプログラマしてる奴はいくらでもいるだろ？
274:デフォルトの名無しさん
09/06/08 14:10:21
おっと>>271が真理を言い放った。
275:デフォルトの名無しさん
09/06/08 14:10:48
>>258
そっちの方が速ければ、そうする。
276:デフォルトの名無しさん
09/06/08 14:11:31
>>273
s/仕事でプログラマ/仕事でプログラム
277:デフォルトの名無しさん
09/06/08 14:25:19
結局、
・歴史はある
・情報系の人間ならまず習う
・短期記憶が足りなくてもどうにかなる
それでもマジョリティになり切れない関数型言語って
どうなのさ。なんか根本的に残念なところとかある
んじゃないのかな。
278:デフォルトの名無しさん
09/06/08 14:31:45
モナドを知らないとHello Worldも書けない、とか？
279:デフォルトの名無しさん
09/06/08 14:35:13
M$を始めとするソフトウェアベンダー様方が力を入れてこなかったから
280:デフォルトの名無しさん
09/06/08 14:37:19
>>278
それはない
281:デフォルトの名無しさん
09/06/08 15:50:40
Pascalの残念なところを改良した、たぶん>>277でも気に入りそうな
Turingという言語があったけど、ちっとも広まらなかったよｗ
282:デフォルトの名無しさん
09/06/08 17:02:36
>>278
モナドもHaskellも知らない奴が「モナドを知らないとHaskellではプログラミングできない」と言い張る
283:デフォルトの名無しさん
09/06/08 18:02:39
関数型言語の欠点は、
1箇所の変更の影響が広範囲にわたること。
高階関数に微妙なバグがあると、
バグを特定してインパクトの小さな修正をするのが困難
284:デフォルトの名無しさん
09/06/08 18:06:23
現代の関数型言語を語る時にLisp系の話を持ち出すのは間違い。
あれはもう何年経ってもアカデミックな界隈でしか使われない。
誰がやってるのか、どこの会社がやろうとしてるとか等を考慮すれば、
F#とScalaだけに注目してればいい。
285:デフォルトの名無しさん
09/06/08 18:15:04
>>283
いや、影響はその関数の中だけでは？
要は関数ってのは入力と出力だよ。
出力以外の状態に変化が無いことが保証されているから、
入力されたデータに対する出力だけを見ていれば正常に動いているかどうかが一目瞭然なんだよ。
正しい入力をしたとき正しい出力が出ていればそれは正しい関数。
バグの特定は普通にprintデバッグとかいろんなデバッガを使ったデバッグでするところは他の手続き型言語と何も変わるところはないね。
286:デフォルトの名無しさん
09/06/08 18:19:04
>>284
> 現代の関数型言語を語る時にLisp系の話を持ち出すのは間違い。
> あれはもう何年経ってもアカデミックな界隈でしか使われない。
アカデミックな界隈ではLispは古くさいってイメージしかない。
使っているのは長老だけでは？
287:デフォルトの名無しさん
09/06/08 18:31:23
>285
それは、関数型言語の中でも特に誰も本番で使ってないといわれる、
純粋関数型言語の話でしょ。
オブジェクト指向言語の話する時にSmalltalkを大前提に語るぐらい
意味のない行為。
288:デフォルトの名無しさん
09/06/08 18:37:55
>>287
純粋関数型言語HaskellはOCamlやF#より話題に上りやすい言語なんだが。
289:デフォルトの名無しさん
09/06/08 19:58:52
>>287
それは lisp のように代入を許してる言語の話だろ?
だからと言って, ダイナミックバインドがある汚染された関数型言語でも,
スペシャル変数の使いどころとか理解できない糞には触ってほしくはない
# つか, クラス変数より遥かに役に立つダイナミック変数
290:デフォルトの名無しさん
09/06/08 20:11:04
関数型言語っていう括りはおおざっぱすぎるんじゃないかな。
Lisp, Schemeは関数型言語の仲間だけど、理論的な背景は無い。
そういう意味では、基礎の無いOOと同じ。
291:デフォルトの名無しさん
09/06/08 20:15:41
>>290
書かないだけで, 書こうと思えば純粋関数的に書けるわな > lisp 系
そもそもが型なしラムダ計算なんだから
292:デフォルトの名無しさん
09/06/08 20:26:08
>>291
いや、書けてしまうという時点で純粋じゃないんだよ。
そもそも純粋関数型言語であるのは機械的な解析がしやすいこと。
それはデバッグの自動化への将来性を意味する。
293:デフォルトの名無しさん
09/06/08 21:14:33
>>292
チューリング完全な任意の言語は
純粋関数型言語に機械的に翻訳できるが、それでも解析がしやすいと言うのか？
294:デフォルトの名無しさん
09/06/08 21:17:08
>>292
> それはデバッグの自動化への将来性を意味する。
実際には型エラーのデバッグだけでも自動化にはほど遠いけどな。
型推論自体がNP完全問題という現実を忘れないように。
295:デフォルトの名無しさん
09/06/08 21:27:07
>>294
まぁ、いろいろ研究があるから調べると良いよ。
特に奈良先端とかいっぱい論文出してる。
296:デフォルトの名無しさん
09/06/08 21:30:53
この話題は永久機関のように無限ループするな
297:デフォルトの名無しさん
09/06/08 21:32:37
無限ループせずして何が2chか！
298:デフォルトの名無しさん
09/06/08 21:37:16
>>295
型について質問することでバグを特定するシステムなら知ってるよ。
俺もその研究に関わってたことあるし。
でもあれは自動化の対極だ罠。質問に対して人間が適切に返答することが前提。
つーか、自動化は不可能なことが証明されているのに何を今さら？って感じ。
299:デフォルトの名無しさん
09/06/08 21:47:54
>>298
お前の知識は古すぎる
300:デフォルトの名無しさん
09/06/08 21:48:56
定理証明支援系じゃあるまいし。
301:デフォルトの名無しさん
09/06/08 21:57:26
>>299
では、型エラーのデバッグを完全に自動化することに成功した論文を挙げてくれ。
302:デフォルトの名無しさん
09/06/08 22:06:51
オブジェクト指向は分かるけど、便利なものを集めたオブジェクト的なものを作ってしまいますよね
303:デフォルトの名無しさん
09/06/08 22:08:48
>>301
関数型言語ではそもそも型エラーが起こりえないだろ？ｗ
304:デフォルトの名無しさん
09/06/08 22:12:13
>>302
それはオブジェクト指向を正しく理解していない。
オブジェクトが並列で動くイメージで作るんだよ。
でも実際にスレッドで並列で動かすと無駄が大きくなるから並列じゃないんだけどね。
どうしても本当の並列が必要になったときだけスレッドを使えばいい。
305:デフォルトの名無しさん
09/06/08 22:12:59
>>294
型推論がNP完全？決定不能の間違いでは？
NP完全は計算量のオーダーの話。
決定不能(undecidable)は計算可能性の話。
まぜるな危険。
306:デフォルトの名無しさん
09/06/08 22:19:14
ひょっとして停止性問題の事を言っているの？
307:デフォルトの名無しさん
09/06/08 22:21:13
>>291
>そもそもが型なしラムダ計算なんだから
Lispは形なしλ計算ではない。セルとその操作(carやcdr)を基礎とする言語。
一方λ計算とは、値とλ抽象とλ適用を項とし、βリダクションによって計算を進めるもの。
全く異なります。
308:デフォルトの名無しさん
09/06/08 22:22:42
×形なしλ計算
○型なしλ計算
309:デフォルトの名無しさん
09/06/08 22:23:54
関数型のほうが十分に生産効率も実行効率もいいなら、関数型が流行るだろうよ。
オブジェクト指向のほうが、現実のモデル化には適している。
問題は、モデル化にこだわって、かえって複雑になりがちなことだ。
310:デフォルトの名無しさん
09/06/08 22:39:10
>>304
>それはオブジェクト指向を正しく理解していない。
属人的なノウハウであるオブジェクト指向に「正しい」なんてないと何度言ったら(ry
311:デフォルトの名無しさん
09/06/08 22:44:18
正論だけど扱い辛い設計をする奴ほど態度がデカい
312:デフォルトの名無しさん
09/06/08 22:44:39
必要十分で適切なモデル化ならその複雑さは必要な複雑さ。
問題はモデル化と称していらんものをやたらと詰め込むこと。
313:デフォルトの名無しさん
09/06/08 22:45:52
単独の関数をオブジェクトと認めたがらないのが不思議。
関数ポインタで済むところでもクラス＋仮想関数を使わせるのは不自然。
314:デフォルトの名無しさん
09/06/08 22:47:54
関数ポインタがタイプセーフに扱えなかった頃の名残だよ
315:デフォルトの名無しさん
09/06/08 22:52:49
>>310
そんなことを言ってるんじゃないのｗ
属人的な要素が強いなら先輩の言うことは聞きなさい。
316:デフォルトの名無しさん
09/06/08 22:54:11
>>313
関数とオブジェクト指向で言うところのオブジェクトは別物だろ。
関数自体にメッセージを送れるか？
関数自体がメッセージを受信するか？
317:デフォルトの名無しさん
09/06/08 22:55:45
>>313
ファンクタがあるよ。
318:デフォルトの名無しさん
09/06/08 23:17:11
>>307
Lispがラムダ計算じゃないなんて馬鹿丸出しだぞ。
お前はChurch encodingも知らないのか？偉そうな事を言うなら少しは勉強してからに
したらどうだ？consもcarもcdrもラムダ式で表せるんだよ。
319:デフォルトの名無しさん
09/06/08 23:17:53
Scalaだけがこの暗黒の時代を救う
日輪となる唯一の言語
Scalaこそ最強
Scalaこそ救い
320:デフォルトの名無しさん
09/06/08 23:27:00
>>316
ドシロート意見だけど引数とは違うのん？
321:デフォルトの名無しさん
09/06/08 23:29:54
>>318
>consもcarもcdrもラムダ式で表せるんだよ。
λ計算で表現できる事とλ計算の定義とを混同していませんか？
Lispはλ計算の定義(>>307で簡単に書きました)をその基礎に採用していません。
これではLispはλ計算だと言えないと思います。
本当にλ計算を基礎としているのはMLです。
322:デフォルトの名無しさん
09/06/08 23:46:01
>>310
属人的だから、ノウハウで高い給料もらえるんじゃん。
323:デフォルトの名無しさん
09/06/08 23:46:19
>>320
関数は状態を持たないでしょう？
だから前に送ったメッセージの事は覚えてない
324:デフォルトの名無しさん
09/06/08 23:48:14
>>318
はいはい、習ったことを言いたいのは解るけど、恥ずかしいからやめてね
325:デフォルトの名無しさん
09/06/08 23:51:52
>>318
Lispが型無しかどうかはラッセルパラドックスが成り立つかどうかで調べれば良いんじゃないの。
326:デフォルトの名無しさん
09/06/08 23:52:34
>>321
Lispって処理系の実装法まで定義してるのか？
基本的にLispのコードはラムダ式で表せるのだから、後はbeta reductionすれば
良いだろう、というのが俺の意味するところなんだが。
327:デフォルトの名無しさん
09/06/08 23:56:55
>>304
スレッドなんて作ったって並列になんて動かないじゃん
こっちちょっと動かして、そっちちょっと動かしてを繰り返すのはまったくいっしょ
スレッドにしてなにか変わることあるの？
一定時間毎に呼び出したいとかハード的な何かのメッセージを待ってとか
通信でメッセージを待つとか
そういうコールバック的な用途でしか使う機会ないんだけど
スレッドって俺等ＰＧにとって並列に処理するためのもんか？（いや、定義は知らんけどね）
328:デフォルトの名無しさん
09/06/08 23:59:19
>>327
コールバックとスレッドは全く違う。
コールバックって関数の中の処理が終わるまで他のところに処理が移れないじゃん。
329:デフォルトの名無しさん
09/06/09 00:04:52
>>326
いいたい事の意味は分かります。
Common Lispは言語仕様ですが、その基礎的な仕様に例えばS式の定義があります。
その中でS式とは、シンボルとそのペアによって成り立つと定義されています。
これはλ項（値とλ抽象とλ適用によって成り立つもの）とは異なります。
もちろん、Lispのプログラムはλ計算に変換可能(だと思う。証明したことないけど）ですが、
それをもってLispはλ計算だという表現は拡大解釈だと感じます。
330:デフォルトの名無しさん
09/06/09 00:21:46
>>329
「値」じゃないよ。variableは「変数」
331:デフォルトの名無しさん
09/06/09 00:24:17
>>328
いや、コールバックじゃねぇなｗ
なんだっけ？
ポーリングだｗポーリングｗ
332:デフォルトの名無しさん
09/06/09 00:26:32
>>328
つまりよ
ハード的な要因があって何かを監視する必要があってそれと辻褄を合わせる的な用途でもないと
無理やりスレッドって形でプログラムを組む必要ってないじゃんってこと
333:デフォルトの名無しさん
09/06/09 00:27:22
非同期コールバックの事じゃねえの？
334:デフォルトの名無しさん
09/06/09 00:33:19
>>316
> 関数自体がメッセージを受信するか？
普通に受信しますがそれが何か？ ｗ
| func |
func := SmallInteger compiledMethodAt: #+.
func valueWithReceiver: 3 arguments: #(4) "=> 7 "
335:デフォルトの名無しさん
09/06/09 00:34:17
>>330
どうも。うっかりしてました。
いい機会なので、λ項の定義を書いておきます。
1. 変数a,b,c,...はλ項である
2. M,Nがλ項のとき、(M N)はλ項である （関数適用）
3. Mがλ項、xが変数のとき、(λx.M)はλ項である （λ抽象）
336:デフォルトの名無しさん
09/06/09 00:34:23
>>334
副作用があるから関数ではない
337:デフォルトの名無しさん
09/06/09 01:11:56
>>327
マルチコア／マルチプロセッサになると違ってくるよ。
シングルコアだと動いてるのに、マルチコアにすると不具合が出るソフトは、
大抵スレッドがらみのバグだね。
プログラミング面から見たら、それぞれのタスクが独立して動いてくれた方が
楽なことがあるんだよ。もちろん、独自のタスク管理システムつくっても
いいんだけど、それはそれで面倒くさい。
338:デフォルトの名無しさん
09/06/09 02:11:12
>>337
スレッドのバグは状態を共有するところに問題の種がある。
だからこそ状態を共有しないメッセージングが重要なんだよ。
339:デフォルトの名無しさん
09/06/09 02:34:34
並列が便利だというのは手続き的に並列実行する感覚だとわかりにくいと思う。
340:デフォルトの名無しさん
09/06/09 03:29:50
>>338
一瞬解ったような気もしたけどやっぱり解らないのですが・・・
状態を共有する以前に、各スレッドが状態を持っていること自体が
問題の種だと思うのだけど、違うのかな。
341:デフォルトの名無しさん
09/06/09 03:40:11
>>340
各スレッドが状態を持っていると問題になる具体的な例を挙げてもらえますか？
各スレッドが状態を持つ問題点というのはおおよそ手続き型故の問題だと思いますが。
342:デフォルトの名無しさん
09/06/09 04:19:40
>>303
> 関数型言語ではそもそも型エラーが起こりえないだろ？ｗ
↑こいつ馬鹿？
343:デフォルトの名無しさん
09/06/09 04:27:31
>>305
Type inference with simple selftypes is NP-complete
URLﾘﾝｸ(portal.acm.org)
344:デフォルトの名無しさん
09/06/09 04:36:07
>>340
状態を共有しているから相互干渉が発生するんだよね？
状態を共有せずにメッセージングで疎に結合しておけば
それぞれのスレッドの問題はそれぞれのスレッドに閉じるよね？
345:デフォルトの名無しさん
09/06/09 05:13:26
そんなにメッセージングが大好きならスレッドなんか使わずにMPIでも使ってろよ
346:デフォルトの名無しさん
09/06/09 05:18:14
>>343
selftype無しの言語だとP-completeじゃねーかよ
>>294は嘘つきも大概にしろよ
347:デフォルトの名無しさん
09/06/09 05:23:59
>>346
型推論一般ではNP-completeということじゃ？
348:デフォルトの名無しさん
09/06/09 05:29:29
>>347
selftypeってOO言語で使う物だろ
関数型言語の話をしている時にそういう言い方をするのは詭弁
349:デフォルトの名無しさん
09/06/09 05:40:47
つ 岡村その他
350:デフォルトの名無しさん
09/06/09 06:08:36
>>349
Cardelli厨乙
351:デフォルトの名無しさん
09/06/09 06:41:41
ていうかスレッドがオブジェクト指向となんの関係があるのよ？
352:デフォルトの名無しさん
09/06/09 06:42:54
NP完全な場合とP完全な場合があるなら
全体はNP完全になるだろ常識
353:デフォルトの名無しさん
09/06/09 07:07:30
そもそも全体の話なんかしてないだろうが
354:デフォルトの名無しさん
09/06/09 07:08:32
全然関係ないことを無理やり結びつけて話を進めるやつがいるよね
355:デフォルトの名無しさん
09/06/09 07:30:02
スレッドもOOで考えたいという人もいるのかもな。
まぁ世の中なんでもかんでもオブジェクトですよ。
356:デフォルトの名無しさん
09/06/09 07:32:25
>>338
状態の共有がオブジェクトの共有に変わっただけだな。
直接アクセスせず関数を経由すると便利になるのは当たり前のこと。
357:デフォルトの名無しさん
09/06/09 07:40:56
トランザクションメモリがあれば
バグなんて発生しない
358:デフォルトの名無しさん
09/06/09 07:43:32
>>355
スレッドの原型であるlightweight processがactorモデルと相性よかったという歴史的背景があるわけだが。
359:デフォルトの名無しさん
09/06/09 08:31:02
関係無いじゃん
じゃ、普通の処理で済むところをスレッドにすることで扱いやすくなるの？
解釈間違ってんじゃない？
360:デフォルトの名無しさん
09/06/09 08:35:16
そもそも、並列にしか目が向いてなくね？
委譲したり継承したりできるわけだが
361:デフォルトの名無しさん
09/06/09 08:35:33
おまえは今、世界中のerlangerを敵に回した！
362:デフォルトの名無しさん
09/06/09 09:05:32
オブジェクト指向マンセーって言う人の
メイン使用言語は大抵
オブジェクト指向との親和性が微妙なのは何故？C++とかJavaとか
363:デフォルトの名無しさん
09/06/09 09:37:06
STL便利じゃん javaいらね
364:デフォルトの名無しさん
09/06/09 09:38:59
親睦性の高い言語って何かある？
Excelの裏で動くVBAとか？
365:デフォルトの名無しさん
09/06/09 09:52:13
つ 【emacsの裏で動くelisp】
366:デフォルトの名無しさん
09/06/09 11:53:43
>>342
少なくとも強く型付けされたHaskellなどの言語では実行時の型エラーはありえなくね？
367:デフォルトの名無しさん
09/06/09 11:58:06
unsafeCoerceを使ってですね…
368:デフォルトの名無しさん
09/06/09 12:00:22
>>367
そんなやばい関数があるのか。
FFI用だろ 女子高生
369:デフォルトの名無しさん
09/06/09 12:08:07
でもunsafeって名前を付けたのは偉いと思う。
危険なところと安全なところを切り分けて考える事は重要だしね。
370:デフォルトの名無しさん
09/06/09 13:07:10
>>362
>>オブジェクト指向との親和性が微妙なのは何故？C++とかJavaとか
オブジェクト指向との親和性って何？
C++とJavaの何処が微妙なんだ？
371:デフォルトの名無しさん
09/06/09 13:53:49
>>370
30越えてるなら今のうちにコボラにごめんなさいしとけ
多分お仲間になる
372:デフォルトの名無しさん
09/06/09 14:22:37
>>371
そういうこと言ってる人って、大学に行かずにプログラマになった人で、40歳ぐらいの人に多いんだけど。。
3人ぐらい同じような事を言ってる奴がいたけど、全員大学は出ていなかった。
一方で関数型言語やオブジェクト指向をバリバリやってる人は会社の社長さんに多かった気がする。
てか俺の周り社長大杉ｗ
373:デフォルトの名無しさん
09/06/09 15:20:28
>>372
つまり、オブジェクト指向やってる奴は協調性が無くて長く会社にいられないから、
起業する奴が多いということか。
374:デフォルトの名無しさん
09/06/09 18:36:02
型エラーはコンパイル時のも含むだろ
往生際わるすぎ
375:デフォルトの名無しさん
09/06/09 18:42:37
>>374
お前、ム板で暴れてる奴だろ？
376:デフォルトの名無しさん
09/06/09 19:08:44
>>375
ここはどこ？ >>374 ってよそでもやってるの？？？
377:デフォルトの名無しさん
09/06/09 20:11:17
ほどほどにオブジェクト指向しようや
378:デフォルトの名無しさん
09/06/09 21:09:32
> ほどほどにオブジェクト指向
の定義が山ほどあるから、みんな、困ってるんじゃないか？
とくに OOA とか OOD とか言ってる連中と、その他の設計理念の立ち位置とか
C++/Java で言ってるカプセル化の位置付けとか
よそから見たら単なるオナヌーだろ？
379:デフォルトの名無しさん
09/06/09 23:25:01
なぁ………
ハード屋とか組み込み屋連中はシステムの安定度とかを計算するための
数式的手法を山ほど持ってて, 有効に使ってシステム組んでるわけだが
実は, そのたぐいってOOにも応用可能なことが分かってるのに, OO屋が
そうゆうの使わないのは, なんか理由があるのか?
380:デフォルトの名無しさん
09/06/09 23:27:50
>>379
昔からあるだろ形式言語使って
調べるとかそんなのは日の目みないだけで
腐るほど研究されてるぞ
OO使い特にJAVAスクール（笑）に通ってるような
奴らには数式なんて理解できないでしょう
381:デフォルトの名無しさん
09/06/09 23:39:54
>>380
> 数式なんて理解できないでしょう
要はOO屋ってのはアホの集団ってことか?
382:デフォルトの名無しさん
09/06/09 23:47:16
オブジェクト指向＝文系（再掲）
383:デフォルトの名無しさん
09/06/09 23:50:08
>>378
＞よそから見たら単なるオナヌーだろ？
オナニーして悦に入ってる奴に限って
他人にも押し付けて来るんだよなぁ
ああいうのは本当に邪魔だ
384:デフォルトの名無しさん
09/06/09 23:55:58
>>379
そんなツール山ほどあるんじゃないの
メトリクスで検索したら山ほど引っかかるぞ
ウチの職場でも富士通の使ってるし
385:デフォルトの名無しさん
09/06/09 23:57:26
>>381
そうOO屋はアホの集合体
特に日本は設計もできないし、問題を解決する道具
としてOOをまともに使えないから世界でもカスレベル
のアホ集団といっても問題無い
386:デフォルトの名無しさん
09/06/10 00:01:48
>>384
あの設計段階ではほとんど全く役に立たない奴ね
その手のツールとは違うだろ, ハード屋とか組み込み屋が使ってる設計手法は?
387:デフォルトの名無しさん
09/06/10 00:16:11
ソフトウェアを開発する作業はハードウェアとかでの設計にあたる、みたいなことを誰かがいってたのを思い出した
388:デフォルトの名無しさん
09/06/10 00:21:52
>>387
> ハードウェアとかでの設計
って言ってるのは、図面を引くところで
それ以前の工程のでやるべきことはほとんど同じなんだけどな
使ってる手法は大きく異なる
389:デフォルトの名無しさん
09/06/10 01:37:38
>>379
ソフトウェア開発では、その手のものはまず役に立たないから。
390:デフォルトの名無しさん
09/06/10 01:46:12
> ソフトウェア開発では、その手のものはまず役に立たないから。
「ソフトウェア開発では、その手のものを役立たせる能力をもった人材が
ほとんどいないから」
の、間違いだろ
391:デフォルトの名無しさん
09/06/10 07:01:51
>>390
君、ソフトウェア工学についてちゃんと系統立った教育を受けてないでしょ？
学んでいれば、ハードウェアにはないソフトウェア固有の問題を知っているはずだ。
392:デフォルトの名無しさん
09/06/10 07:12:04
>>391
>>196 >>199
393:デフォルトの名無しさん
09/06/10 09:44:44
構造化プログラミングの時代には、
仕様から数式的に記述して、できたプログラムを検証するとか、
理論的研究としてはいいところまで行ったが、
オブジェクト指向が出てきて振り出しに戻ったｗ
394:デフォルトの名無しさん
09/06/10 09:49:30
オブジェクト指向っていうのはアルゴリズムを実装する手段だから
アルゴリズムを考える手段としてはあまり役に立たないように俺は思うよ。
395:デフォルトの名無しさん
09/06/10 10:04:43
>>372
悔しいのか？
396:デフォルトの名無しさん
09/06/10 10:14:43
>>392は何の反論にもなっていないアンカーを落として何がしたいの？
頭おかしいの？死んじゃうの？
397:デフォルトの名無しさん
09/06/10 10:17:18
ビジネス分野なんて、仕様そのものが不安定なのに、
仕様を形式化できるような分野の話をしても意味が無いと思うが。
それこそ、なんでもOO厨と変わらないだろ。
398:デフォルトの名無しさん
09/06/10 10:22:28
>>396
必 死 だ な
Software engineering will never be a rigorous discipline with proven
results, because it involves human activity.
399:デフォルトの名無しさん
09/06/10 10:22:44
将来的に、仕様は形式化できないといけないと思うけどね。
で、仕様を変更したら、プログラムの中で修正すべき部分が色つきで表示されるとか。
400:デフォルトの名無しさん
09/06/10 10:26:27
形式化された仕様を書く際にバグが生じるわけですね。
401:デフォルトの名無しさん
09/06/10 10:39:13
>>398
その英文を読んで、理由がそこに直接挙げられているものだけだという主張だと解釈するのなら、
おまえは二度と英文を読まないほうがいい。おまえ本人にとってもおまえの周囲にも不利益にしかならない。
402:デフォルトの名無しさん
09/06/10 10:44:25
テスト駆動は数学あんまり関係ないからなぁ
オーバースペックな学問やってると応用を考えるのが大変だな
403:デフォルトの名無しさん
09/06/10 10:51:10
仕様形式化廚からiPhoneみたいなものが生み出されることはないだろうな
404:デフォルトの名無しさん
09/06/10 10:51:48
>>401
読まずに反論してるのが丸分かりだな。まあ全部読んでから反論しろよ。
それともこの程度の量も楽に読めない程英語に不自由しているのか？
405:デフォルトの名無しさん
09/06/10 10:59:51
>>404
すごい妄想だな。
やはりお前は>>391が言うようにSoftware Engineeringの基本中の基本がわかっていない。
VBScriptを自習したクチか？
406:デフォルトの名無しさん
09/06/10 11:09:14
どんな分野でも、過去の考え方にとらわれない設計・開発から、
革新的なヒット商品が生まれる。
だけど、それと、オブジェクト指向には、
なんかすっきりした設計・開発の法則がないんじゃないか？
という話も、また別の問題だろう。
過去の定跡を破る前に、その定跡がどうもはっきりしない。
407:デフォルトの名無しさん
09/06/10 11:34:41
>>405
余計なことはいいから、読んだのなら内容について反論しろよ。
それが出来ないなら英語に不自由していると思われて当然だ。
408:デフォルトの名無しさん
09/06/10 11:36:56
>>405
人を妄想だと言っておきながら自分も妄想を並べ立てるとか
自己矛盾も甚だしいぞw
409:デフォルトの名無しさん
09/06/10 11:48:24
過去の考え方にとらわれない設計・開発をするためには、過去を知らなきゃ駄目じゃん
基礎を知らないので、応用が出来ないのと同じ理屈だよ
410:デフォルトの名無しさん
09/06/10 16:55:45
>>407-408
ミエミエの自演とはいえ、もうちょっと時間をおくとかしたほうがいいぞ。
あとな、おまえちゃんと全文読んでないだろ。読んでたら>>392のようなマヌケなことはしない。
411:デフォルトの名無しさん
09/06/10 17:06:39
>>410
第三者から見てもお前の方が１００倍ぐらい痛いぞ
412:デフォルトの名無しさん
09/06/10 17:08:00
オブジェクト指向について語れ。
413:デフォルトの名無しさん
09/06/10 17:32:00
>>411 「第三者」プ
414:デフォルトの名無しさん
09/06/10 19:59:10
なんだ、まっとうな議論してんのかと思ったら
オブジェクト指向が理解できない可哀想な人たちの巣でしたか
415:デフォルトの名無しさん
09/06/10 20:39:31
ループ入りました
416:デフォルトの名無しさん
09/06/10 20:43:55
最善の「オブジェクト指向開発」の方法論って何よ？
それがまっとうな技術者なら、誰でもある程度身に付くなら、そこから議論しないと。
417:デフォルトの名無しさん
09/06/10 21:11:32
VBScriptは、土方用に特化されたC++ライクなオブジェクト指向言語だな
418:デフォルトの名無しさん
09/06/10 21:44:17
VBScriptは他に無い独自のオブジェクト指向だろ
なんせ継承が無い
419:デフォルトの名無しさん
09/06/10 21:50:52
継承がないから、土方用なんだろ?
420:デフォルトの名無しさん
09/06/10 22:16:36
「関数から値が返ってくる」というのより、
「オブジェクトの状態を調べる」というほうが、素人に分かりやすい。
関数って、実体が感じられないんだよね。
421:デフォルトの名無しさん
09/06/10 22:27:58
関数が汗水たらして働いてるドカタなんだよ
422:デフォルトの名無しさん
09/06/10 22:29:52
>>416
銀の弾丸はありません。
423:デフォルトの名無しさん
09/06/10 22:34:06
>>420
どっちもいっしょだろ。
c じゃ返ってくる値じゃ使い物にならんから
しゃーないってのはあるが。
424:デフォルトの名無しさん
09/06/10 22:36:11
> 「オブジェクトの状態を調べる」
って言うと、インスタンス変数なりクラス変数なりの参照をイメージするが…
425:デフォルトの名無しさん
09/06/10 22:37:14
>>420
素人の意見で決めるのかｗ
426:デフォルトの名無しさん
09/06/10 22:42:26
マスコミがよく使う手だな
427:デフォルトの名無しさん
09/06/10 22:46:45
仕様決めるのに素人意見の大きさは無視できんからな。
その辺がハード屋とは大きく違う。
428:デフォルトの名無しさん
09/06/10 22:55:36
>>424
教育の話だけど、すごく単純なプログラムで、
関数とオブジェクトのメソッドを教えようとしたら、
メソッドのほうが教えやすいということに気づいた。
文系脳でも大丈夫。
429:デフォルトの名無しさん
09/06/10 23:02:52
>>410
自演？なにそれ？
妄想や抽象論はいいからさっさと内容について具体的に反論しろよ。
お前本当に英語読めないんだな。
430:デフォルトの名無しさん
09/06/10 23:16:55
教えやすさは大切だよね。
手続き型は何だかんだ言いつつも変数を箱として視覚的に表現
したりと工夫する事で初心者にも処理の流れを理解させやすい。
OOPは犬や猫をなかせたりとやや迷走気味だけど、まだ努力
は見せている。
前にここで関数型言語における初心者向けの良い例え話を
尋ねたらラムダ演算が答えとしてかえってきた。
説明下手なうちは普及も難しいだろうなと正直思った。
431:デフォルトの名無しさん
09/06/10 23:19:43
バカ野郎、関数型言語は選ばれた人材だけの占有物なんだから初心者向けとか普及とかいう泥臭いことは考えなくていいんだよ
432:デフォルトの名無しさん
09/06/10 23:57:06
例え話なんて必要か？
普通に中学・高校で習う関数と一緒だと思うが。
高階関数のこと？
433:デフォルトの名無しさん
09/06/11 00:00:38
圏論程度でもたとえ話なんて不要なのに
それ未満の内容でたとえ話っているのか？
434:デフォルトの名無しさん
09/06/11 00:15:24
>>433
じゃぁ例え話なしで
君のまわりの鼻たれ小僧に関数型言語について教えてみて
例え話を使った所で"理解"にそのまま至ることは無いが
"どの程度話が通じるか"に差が出る
435:デフォルトの名無しさん
09/06/11 00:16:37
>>434
まずは、日本語を正しく書けるようになれ
436:デフォルトの名無しさん
09/06/11 00:34:04
「初めてプログラムします」っていうような人が対象の教育について
OOと関数型とを比べてもつまならい。どっちもまぁ頑張れとしか言いようがない。
それよりも、一定以上の規模かつ一定以上の品質という条件を両立したプログラムを書ける
レベルまでにどれだけスムーズに到達できるようになるかを比べたい。
437:デフォルトの名無しさん
09/06/11 00:44:28
アルゴリズムの勉強するなら関数型の方が楽
438:デフォルトの名無しさん
09/06/11 00:47:28
そういう比べ方をした場合、JavaやC++のような言語では、クラスやオブジェクトの
基本的な機能まではすぐに分かるのだけれど、クラス設計をしようとした途端難しくなる。
これがネック。
そして少し分かりかけてきたかなと思っても、規模についていけずに破綻する。
一方でHaskellやOCamlのような関数型言語では、型や関数やモジュールの基礎は難しくなく、
そこまで分かれば一定以上の規模に耐えられる。
それ以上難しい型の応用やファンクターの活用などになると壁があるけど、
そこはもうプラスαの世界。
439:デフォルトの名無しさん
09/06/11 00:54:18
Haskellはあの空白でエラーでるとか
旧世代言語みたいなキモイ文法が無ければ流行る
OCaml最高～
Java（笑）市ねｗ
440:デフォルトの名無しさん
09/06/11 00:56:07
大抵の事は、VBScriptで十分
自分でオブジェクトを作ろうとするからややこしいんであって、利用するだけなら馬鹿でも出来るし
VBScriptを使いこなせるようになってからC++なりJAVAなりC#なり好きな言語を使えばいいんでないの?
まあ、VBScriptを使いこなせるようになったら、わざわざ他の言語に移る必要性を感じるかどうか...
馬鹿避けには良い言語だよマジで
441:デフォルトの名無しさん
09/06/11 00:56:58
業務アプリの8割5分がVBScriptだしなぁ
442:デフォルトの名無しさん
09/06/11 00:59:30
8割5分とか、統計細かすぎwワロタw
443:デフォルトの名無しさん
09/06/11 01:02:22
俺の職場はJavaとC#だから、たぶん残りの1割5分。意外とマイナー。
444:デフォルトの名無しさん
09/06/11 01:30:55
これからはマルチパラダイム言語だな。
って事で、Scala最高。
445:デフォルトの名無しさん
09/06/11 02:18:15
ネットの盛り上がり方みてるとやっぱScalaなんだろうな
と思いつつもclojureに心惹かれてる俺
446:デフォルトの名無しさん
09/06/11 05:36:35
Scalaってそんなに流行ってるのか？
俺はOCamlでいいや
447:デフォルトの名無しさん
09/06/11 07:28:13
>>432
その高校で習う関数が分からないんだよ。
文系脳では、1行で書けない関数は理解不能。
Fortranの文関数が限界。
448:デフォルトの名無しさん
09/06/11 08:27:18
>>435
プ
449:デフォルトの名無しさん
09/06/11 13:48:24
>>447
大丈夫。そいつ等は日本語も読めない連中だから切って捨てても無問題
450:デフォルトの名無しさん
09/06/11 18:10:11
>>449
抽象概念としては中学で習う関数と同じでも、
扱う対象が数だけではないところが関数プログラミングの難しさだとおもうが。
リストや文字列という概念を理解した上で、関数という概念と結びつけるのが
一番の難関だと思う。
たとえば、関数は関数でも、
f(x) = a * x + b
と
f x (y:ys) = (str (x y)):(f x ys)
では理解するために必要な抽象力がまるで違うだろ？
451:デフォルトの名無しさん
09/06/11 18:46:15
そこで素朴集合論ですよ
関係のグラフ、値の対応付け等の概念を知れば
どんな○○でも簡単に理解できるようになるでしょう
452:デフォルトの名無しさん
09/06/11 18:55:04
関数が必要だと思える具体的な場面を想像できないんだろ
抽象力（笑）なんて言われたら、ますます想像力が低下するんだろうなぁ
453:デフォルトの名無しさん
09/06/11 20:42:12
中学校レベルで f(x) = 2x + 1 をどう理解しているかというと、
関数と言うよりテンプレートという感じだろう。
xの場所を数字に置き換えて計算するという感じ。
何か関数という実体があるというイメージはない。
大学で理系の学部に進学する人間以外は、この程度の理解。
454:デフォルトの名無しさん
09/06/11 20:46:29
抽象化して、劇的に生産効率が上がるならいいんだけどね。
高度な抽象化のわりには、それほど生産性上がるのかどうか微妙な感じ。
オブジェクト指向の仮想関数にも同じようなところがあるんだけど。
455:デフォルトの名無しさん
09/06/11 22:15:56
しかも、覚えたからって工数減るわけじゃないしねぇ
「あの人はオブジェクト指向を知ってるから工数は普通の人の２分の１でいいよ」
なんて死亡フラグ以外なんでもないなｗ
456:デフォルトの名無しさん
09/06/11 23:06:51
むしろきれいな構造作ろうとして無駄に時間費やしてる事の方が多いｗｗｗ
457:デフォルトの名無しさん
09/06/12 00:38:14
綺麗な構造作るのは未来のためだから、しょうがないんじゃね？
使い捨てのプチツールなんか、アホらしくて綺麗な構造なんて考えないけどね
458:デフォルトの名無しさん
09/06/12 00:40:50
未来が来てから綺麗にすりゃいいじゃんか。未来の保障も無いのに綺麗にしてもな。
459:デフォルトの名無しさん
09/06/12 00:43:51
このままじゃさすがにヤバいなという臭いを感じたら全力を出せ
とリファクタリングの本にも買いとった
460:デフォルトの名無しさん
09/06/12 00:46:10
綺麗にするって言っても、何度もやってればだいたい使うパターンは
決まってくるんで、そんなに苦痛でもないけどな。
461:デフォルトの名無しさん
09/06/12 01:36:50
OOPの教え方。
赤いまん丸の風船があったとして、
これに「ポンジュース」って書かれた
蛇口をつっこむと、ポンジュースが出てくる。
これがメソッドです。風船はオブジェクト。
462:デフォルトの名無しさん
09/06/12 01:41:34
ｗ
463:デフォルトの名無しさん
09/06/12 03:26:32
俺は手続き型を何年かやった後、OOPについて
犬やら猫やらその親クラスの動物やらで説明されてた時はよく意味が解らんかったが
文字列や配列がクラスってのを学んだらピコーンと来た
でもまだその時点じゃレベル1だった
「文字列化」するメソッドを学んだ時にレベル2になったかな
464:デフォルトの名無しさん
09/06/12 05:25:43
OOPもFPも土方には不要というのがこのスレの結論ですね。
465:デフォルトの名無しさん
09/06/12 06:12:58
土方がいなくなったあとの荒野をOOPマンやFPボーイが代わって
少数精鋭で耕して豊かな土地にしてくれるのならそれでも良いけど、
そこまでの頭数も一人あたりの根性もあるとは思えない。
良い技術であっても広まらないと社会にはクソほどの役にも立た
ないんだけどね。ここでFP持ち出してOOP叩く面々にはFPを振り
かざしはしても普及させようとかそういう気は全然無いみたい。
466:デフォルトの名無しさん
09/06/12 07:48:19
良いかどうかを証明できない上に
これっぽっちも工数を削れない
数字に出せないってことは駄目なんだよ
数字をみないとなにやっても駄目
いつまでも無駄なことを延々とやり続ける
467:デフォルトの名無しさん
09/06/12 08:47:00
いわゆるプログラミングもやるコンサル、とか
全世界市場に向けてリリースするパッケージの開発者、とか
そういう連中の言うことに自己同一化して
単なる下請けコーダーがたけえ本買ってんのは滑稽といえば滑稽だな
辞めちゃえばいいんだよ
業界が腐ってんのはホントのことなんだから
辞めて自分のシステム作ってそれ運用して食っていけばいい
WEBサービスとかシェアウェアとかのこと言ってんじゃないよ
468:デフォルトの名無しさん
09/06/12 09:44:35
とりあえず、プログラム作成しかしてないのに、プログラム開発をしてるつもりの奴が多すぎるのは確かさ
顧客専用のシステムを作成するのに、OOなんてこれっぽっちも役に立つわけがないだろうが
将来的に使うかも?
そんなもん使えるかよ!!!
同じことをするのでも、未来の自分の方が上手いコードを書けるだろうよ!!!
OOが役立つのは、プログラム開発をしている奴だけだよ
プログラム作成している奴には、何の役にも立たないよ
469:デフォルトの名無しさん
09/06/12 09:52:22
まだ再利用とかいってる馬鹿がいるのか。
470:デフォルトの名無しさん
09/06/12 09:57:33
フツーに再利用してるが
471:デフォルトの名無しさん
09/06/12 10:21:44
> まだ再利用とかいってる馬鹿がいるのか。
という馬鹿がいるのが驚きだ
VBScript程度でも使えば再利用の重要性が分かると思うんだが
まあ、VBScriptを使ってても、再利用しているとは思ってない可能性があるけどなwwww
472:デフォルトの名無しさん
09/06/12 10:26:12
互換性を大切にしない言語は再利用しにくい
なので、いまだにCで書く奴が多すぎるわけですよ