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

消えてなくなれよ > ..

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を自習したクチか？

次ページ