消えてなくなれよ >オブジェクト指向 part.3

消えてなくなれよ > ..

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が役立つのは、プログラム開発をしている奴だけだよ
プログラム作成している奴には、何の役にも立たないよ

次ページ