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

オブジェクトって関数より再利用しにくいのではないだろうか
オブジェクトでthisコンテキストにアクセスできるようになったのと引替えに
再利用のために、関数なら引数のことだけ考えれば良かったが
オブジェクト単位で再利用を考えない意図いけないようになった。
そのため、継承・仮想メソッド・インタフェース・デザインパターン・ジェネリック
などのテクニックでその欠点を補っているのではないだろうか。

17 ：デフォルトの名無しさん：2009/06/01(月) 22:36:15

>>14
そんな元レスと話の絡まないレスでは意味がわからん

18 ：デフォルトの名無しさん：2009/06/01(月) 22:36:34

オブジェクトと関数を比べるのはバランスが悪い。
比べるなら、
片やオブジェクト郡、
片や関数郡とそれに渡されるであろうパラメータ郡。

そう考えると、再利用がどうかはさておき、
オブジェクトを中心にすえて考えていくほうが、
少なくとも、「散らかってない」と思う。個人的に。

19 ：デフォルトの名無しさん：2009/06/01(月) 22:37:16

まだオブジェクト指向で再利用とか言ってる奴がいるのか。

20 ：デフォルトの名無しさん：2009/06/01(月) 22:40:58

>>10
すべてオブジェクトにするからおかしくなる。
そんなのは理論屋がやってろ。

21 ：デフォルトの名無しさん：2009/06/01(月) 22:47:27

メッセージ（メソッド）が規格化されてないからいけない。
メッセージに使える単語を制限したらどうか。
オブジェクト指向じゃなくなるか。

22 ：デフォルトの名無しさん：2009/06/01(月) 22:48:33

天才チンパンジー　アイちゃんって２番にしか出てこないのか
さっさと埋めれば良かった

23 ：デフォルトの名無しさん：2009/06/01(月) 23:12:20

python のリストや辞書型くらい整備してくれてりゃ
クライアントとしては使いやすいとは思うけどね。
まあ速度とか気にしだせば結局再利用なんて無理でしょ。

24 ：デフォルトの名無しさん：2009/06/01(月) 23:16:46

再利用が無理と言い切るのもなんだかな
魔法のように何でも再利用できる！みたいなのは違うのは確かだが

25 ：デフォルトの名無しさん：2009/06/02(火) 02:05:24

迷った時は両方!

オブジェクト指向な関数型言語のocaml使えw

26 ：デフォルトの名無しさん：2009/06/02(火) 03:53:36

再利用しないからｗｗｗ

27 ：デフォルトの名無しさん：2009/06/02(火) 08:42:50

>>18
再利用の単位が関数よりも大きいだけと言うことか
オブジェクト指向のメリットって理解のしやすさと言うことだけ？

28 ：デフォルトの名無しさん：2009/06/02(火) 08:43:31

>>23
ホットスポットの解析もせずにライブラリに文句をいう厨房ですか？

29 ：デフォルトの名無しさん：2009/06/02(火) 09:32:05

>>27
理解のしやすさ、というかなんというか。
メリットは色々あるんじゃないかな。

オブジェクトという単位でモジュール化できて、
内部構造としての、変数の表現、メソッドの実装を隠す。
んで、そのオブジェクト郡のインタフェースには関連が見出せたりして、
実行時にはポリモーフィズムで一括して扱える。
あくまで、オブジェクト郡の相互作用で作っていく。

OOPでの再利用云々は、設計の正しさの拠ってると思われる。
再利用しやすい単位で、使用される文脈に想定をおいたりせず、
他のオブジェクトを無闇に知っていたりせず、うまいこと作る。
逆に、そこんとこをきちんとしてないとうまく再利用できないだろうし、
それもってOOPの力不足としてしまうなら、なんか違う気がする。

明白な特性をひとつだけ与えられたクラスは長持ちすると思う。
特性があいまいだったり、コブが着いてたりすると、弱いと思う。

30 ：デフォルトの名無しさん：2009/06/02(火) 09:43:49

無駄が多いですよね

31 ：デフォルトの名無しさん：2009/06/02(火) 12:48:31

100円節約するために1000円掛けるようなところがあるよね

32 ：デフォルトの名無しさん：2009/06/02(火) 13:10:49

業務用プログラムならばそれでいいんだよ。
運用費を100万円削るために開発費1000万円上乗せすればいい。

33 ：デフォルトの名無しさん：2009/06/02(火) 13:36:31

>20
そういや、Javaで基本型がオブジェクトじゃないのは、現在の視点で見ても、
良い判断だったんだろうか？

34 ：デフォルトの名無しさん：2009/06/02(火) 14:12:39

こんなモノ作るのになんで1年もかかるんだよと思うことは多々ある。
俺なら1週間で作れるモノを。

35 ：デフォルトの名無しさん：2009/06/02(火) 14:14:38

最初一週間でできるよって思ってたのが、一年たっても終わらないのはよくあること。

36 ：デフォルトの名無しさん：2009/06/02(火) 14:18:41

それは要はやる気が持続するかどうか　だけなんじゃねーの

37 ：デフォルトの名無しさん：2009/06/02(火) 15:13:59

コロンブスの卵だな
誰にでも出来るのに誰もやる気を出さない

38 ：デフォルトの名無しさん：2009/06/02(火) 15:34:41

その点東大生は優秀だよな。
つまらない受験勉強を継続的にこなしてきたんだから。
途中で飽きて投げ出すようなやつがＦランに行くんだよな。

継続性ある性格が成功を生み出すんだよ。

39 ：デフォルトの名無しさん：2009/06/02(火) 15:37:18

と・・こんなことを書くと、「俺は1ヶ月勉強しただけで東大受かりましたがなにか」とか言ってくる奴がでてくるんだよな・・
別にイレギュラーを探してるわけじゃないので＾＾；

40 ：デフォルトの名無しさん：2009/06/02(火) 16:10:37

>>37
コロンブスの卵は、そんな話じゃないだろwww

41 ：デフォルトの名無しさん：2009/06/02(火) 19:03:09

随分と安っぽい卵だなぁ

42 ：デフォルトの名無しさん：2009/06/02(火) 19:27:36

HaskellやOCaml、Erlangなどには対話環境があるけど
OOだと対話環境って無いし、あってもほとんど意味ないよな
関数型なら一行でかける関数作りまくればいいだけだし、無名関数も書きやすいから
エディタすら無しでいろいろできるわ。
間違いなくこれらは学習のコストと効率とモチベーションに大きく影響するね。

43 ：デフォルトの名無しさん：2009/06/02(火) 19:29:38

つ　Smalltalk

44 ：デフォルトの名無しさん：2009/06/02(火) 19:30:20

pythonてOO系の言語じゃないの？

45 ：デフォルトの名無しさん：2009/06/02(火) 19:36:04

スクリプトとOOPの良いトコ取り

46 ：デフォルトの名無しさん：2009/06/02(火) 19:49:08

>>44
そうだな

>>45
スクリプトとOOPは直交する概念

47 ：デフォルトの名無しさん：2009/06/02(火) 19:59:59

>>42
その場でがしがし付け足していけるのは楽そうだなと思うけど、
そういうコーディングしてても、保守は大丈夫なの？
関数型言語使ったこと無いから感覚がわからんけど。

48 ：デフォルトの名無しさん：2009/06/02(火) 20:10:23

>>42
python, ruby (irb), CINTなど色々あるのを知らないのか？

関数型言語でもToplevelをそのまま使うなんて面倒なことはしないで
Emacsのmajor-modeを使ったりするのが普通だと思うが。

49 ：デフォルトの名無しさん：2009/06/02(火) 20:41:31

対話型環境のメリットって関数の仕様を調べたい時とかにちょこっと実験する程度じゃないの？
rubyのirbとか普通に使えるよ。
OOP言語だと役に立たないって意味分からんね。
まさかOOPの概念を対話型環境で勉強したいって言ってんのかな

50 ：デフォルトの名無しさん：2009/06/02(火) 20:45:05

要は、IDEのデバッグ環境に対抗して
対話環境を関数型パラダイムで理論武装したいんだと思う

51 ：デフォルトの名無しさん：2009/06/02(火) 21:24:14

関数型言語が好きでML(SML, OCaml)を日頃使ってるが、ことさらOOを貶めるのも
どうかと思う。特にC++などの手続き型言語においては、OOを使わない場合と比べて
メンテナンス性が向上するのは明らかだし。

52 ：デフォルトの名無しさん：2009/06/02(火) 22:08:45

静的型のコンパイル言語であるScalaやってますが、ちょっとした確認なら対話型環境でやってますよ。

言語と実行環境って、分けて議論するべきものじゃないのかな？

53 ：デフォルトの名無しさん：2009/06/02(火) 23:22:04

そりゃOOとOOAとOOPと手続き型が一緒に語られるこんなスレじゃ、ポイズン

54 ：a36 ◆K0BqlCB3.k ：2009/06/02(火) 23:28:05

>>53
区別するほどのものでもないだろう

55 ：デフォルトの名無しさん：2009/06/02(火) 23:29:46

>>53
なんで区別したいの？
話聞いてやるから詳しく話してみろ

56 ：デフォルトの名無しさん：2009/06/03(水) 00:08:37

>>53
OOとOOAとOOPと手続き型を全部厳密に定義してみろよ

57 ：デフォルトの名無しさん：2009/06/03(水) 00:27:53

お前が先に定義しろよカス

58 ：デフォルトの名無しさん：2009/06/03(水) 00:31:29

>>57
俺等は違いなんてどうだっていいもんｗ
全部同じぃ～で問題ないよｗ

59 ：デフォルトの名無しさん：2009/06/03(水) 00:33:50

はぁ？厳密に区別する必要は無いと思っているから定義する必要も無し。
一緒に語られたくなかったら定義しろよってことだ。その程度も分からんか？

60 ：a36 ◆K0BqlCB3.k ：2009/06/03(水) 00:36:08

オブジェクト指向には厳密な定義は無いんじゃないかな。

61 ：デフォルトの名無しさん：2009/06/03(水) 00:37:39

>>59
いや、だから俺等はOO,OOA,OOPに違いはないよ組でいいんだろ？

62 ：59：2009/06/03(水) 00:40:06

>>61
そうだよ

63 ：デフォルトの名無しさん：2009/06/03(水) 00:51:41

威勢のいい>>57は逃亡しますた

64 ：デフォルトの名無しさん：2009/06/03(水) 02:17:57

ひどい自演を見た

65 ：デフォルトの名無しさん：2009/06/03(水) 02:26:47

どれが自演なんだ？

66 ：デフォルトの名無しさん：2009/06/03(水) 10:58:26

　　　　　　　　ゴガギーン
　　　　　　　　　　　　　ドッカン
　　　　　　　　　ｍ　　　　ドッカン
　　＝＝＝＝＝）　）)　　　　　　　　　☆
　　　　　 ∧_∧ |　|　　　　　　　　　／　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣
　　　　　（　　　）|　|＿＿＿＿＿　　　　∧＿∧　　　＜　　おらっ！出てこい>>53
　　　　　「　⌒￣　|　　　|　　　　||　　　（´Д｀　）　　　　＼＿＿＿＿＿＿＿＿＿＿＿
　　　　　|　　　/ ￣　　　|　　　　|/　　「　　　＼
　　　　　|　　　|　|　　　　|　　　　||　　　 ||　　 /＼＼
　　　　　|　　　 | |　　　　|　　　　|　　へ//|　　|　　| |
　　　　　|　　　 | | 　　　ﾛ|ﾛ　　　|／,へ＼|　　|　 | |
　　　　　|　∧　| |　　　　|　　　　|／　　＼　　/　（　）
　　　　　|　|　|　|〈　　　　|　　　　|　　　　　|　|
　　　　 / /　/ / |　　/ 　|　　　〈|　　　　　|　|
　　　 / /　 / /　|　　　　|　　　　||　　　　　 |　|
　　　/ /　/ /　=-----=--------　　　　 |　|

67 ：デフォルトの名無しさん：2009/06/03(水) 21:03:39

雑魚ばかりだなこのスレ
俺の話についてこれる奴がいない

68 ：デフォルトの名無しさん：2009/06/03(水) 23:21:24

よし何か話せ

69 ：デフォルトの名無しさん：2009/06/03(水) 23:32:48

>>67に期待

70 ：デフォルトの名無しさん：2009/06/04(木) 01:21:01

簡単なエディタなら機械語で書けるぜ

71 ：デフォルトの名無しさん：2009/06/04(木) 01:23:43

>簡単なエディタで機械語が書けるぜ
は？

72 ：デフォルトの名無しさん：2009/06/04(木) 01:35:27

え？

73 ：デフォルトの名無しさん：2009/06/04(木) 02:31:27

　　　　　　　　ゴガギーン
　　　　　　　　　　　　　ドッカン
　　　　　　　　　ｍ　　　　ドッカン
　　＝＝＝＝＝）　）)　　　　　　　　　☆
　　　　　 ∧_∧ |　|　　　　　　　　　／　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣
　　　　　（　　　）|　|＿＿＿＿＿　　　　∧＿∧　　　＜　　おらっ！出てこい>>67
　　　　　「　⌒￣　|　　　|　　　　||　　　（´Д｀　）　　　　＼＿＿＿＿＿＿＿＿＿＿＿
　　　　　|　　　/ ￣　　　|　　　　|/　　「　　　＼
　　　　　|　　　|　|　　　　|　　　　||　　　 ||　　 /＼＼
　　　　　|　　　 | |　　　　|　　　　|　　へ//|　　|　　| |
　　　　　|　　　 | | 　　　ﾛ|ﾛ　　　|／,へ＼|　　|　 | |
　　　　　|　∧　| |　　　　|　　　　|／　　＼　　/　（　）
　　　　　|　|　|　|〈　　　　|　　　　|　　　　　|　|
　　　　 / /　/ / |　　/ 　|　　　〈|　　　　　|　|
　　　 / /　 / /　|　　　　|　　　　||　　　　　 |　|
　　　/ /　/ /　=-----=--------　　　　 |　|

74 ：デフォルトの名無しさん：2009/06/04(木) 03:08:51

そのオブジェクト必要？みたいな

75 ：デフォルトの名無しさん：2009/06/04(木) 06:55:09

オブジェクト指向と直接関係ないけどマルチスレッドが扱い易い言語が欲しい。

76 ：デフォルトの名無しさん：2009/06/04(木) 07:04:20

77 ：デフォルトの名無しさん：2009/06/04(木) 07:28:52

最近、でかいこと言い放つ割に逃亡する奴が多いな

78 ：デフォルトの名無しさん：2009/06/04(木) 07:37:39

昔からだろ

79 ：デフォルトの名無しさん：2009/06/04(木) 10:25:31

顔が真っ赤な人がいますね

80 ：デフォルトの名無しさん：2009/06/04(木) 18:49:01

ＣＷニコルさんですね

81 ：デフォルトの名無しさん：2009/06/04(木) 20:13:58

いまならへび、かめの卵と幼稚園の防止は俺のもの

82 ：デフォルトの名無しさん：2009/06/04(木) 20:15:15

>>73
　　　　　|┃三　　　　　　　／￣＼
　　　　　|┃ 　　　　　　　　|　　　　|
　　　　　|┃　　　　　　　　＼＿／
　ｶﾞﾗｯ.　|┃　　　　　　　　　|
　　　　　|┃　ﾉ//　　　.／￣￣￣＼
　　　　　|┃三　　　　／　 ::＼:::／::::　＼
　　　　　|┃ 　　　／　 <●>::::::<●>　　＼
　　　　　|┃　　　 |　　　　（__人__）　　　　|
　　　　　|┃三　　＼　　　｀ ⌒´　　　　／
　　　　　|┃三　　／￣￣￣￣￣￣￣＼

83 ：デフォルトの名無しさん：2009/06/04(木) 23:46:03

ある言語がチューリング完全であれば、その言語でオブジェクト指向は可能である。

84 ：デフォルトの名無しさん：2009/06/05(金) 00:06:11

programming "into" a language

85 ：デフォルトの名無しさん：2009/06/05(金) 00:41:56

>>75
文を並べると、逐次で実行してね、と
言わない限り全部並列に実行されてしまう
言語が主流になれば、並列度も上がる
だろうなあ。

86 ：デフォルトの名無しさん：2009/06/05(金) 01:41:09

スーパーハッカーな俺にはオブジェクト指向なんて要らんわ

87 ：デフォルトの名無しさん：2009/06/05(金) 01:51:31

>>86
どんなパラダイムがおすすめですか？

88 ：デフォルトの名無しさん：2009/06/05(金) 01:53:58

>>86
好きなプログラミング言語はなんですか。
よく利用するプログラミング言語はなんですか。
趣味で使うプログラミング言語はなんですか。

やっぱりシンプルなC言語ですか。

89 ：デフォルトの名無しさん：2009/06/05(金) 02:01:26

好きな言語はCだ。趣味ではlispをよく使うな。
お前らも努力すればハッカーになれるから頑張れ。

90 ：a36 ◆K0BqlCB3.k ：2009/06/05(金) 02:21:42

ノイマン型コンピュータを扱っているなら、たとえ関数型言語を使っていたとしても最終的には手続き的な考え方をせざるを得ない。
ノイマン型コンピュータの仕組み自体が手続き的なのだから。

91 ：デフォルトの名無しさん：2009/06/05(金) 05:44:21

この辺で纏めてgc

92 ：デフォルトの名無しさん：2009/06/05(金) 08:31:50

>>89
こいつはとんだインチキハッカーだな。
どこかでハッカーは、 Cとlispを使うとでも洗脳されたのだろうか。
自分の利用する言語の正式名称も言えないなんてハッカーの資格無しだ。
lispってなんだよ。あのMITのトイレで生まれたというevalとatomとlistのことか。
どれだけ方言があると思っているんだよ。

93 ：デフォルトの名無しさん：2009/06/05(金) 10:33:43

そもそもコンピュータ自体が質的に有限なので
オブジェクト指向とかは作法の違いにすぎず、
本質的な違いはない。

94 ：デフォルトの名無しさん：2009/06/05(金) 10:58:05

～なので～にすぎず～はない。論理の飛躍。無根拠。
～とかは。焦点があいまい。

95 ：デフォルトの名無しさん：2009/06/05(金) 13:40:50

ジャンケンプログラムで、審判オブジェクトが必要とか未だにようわからん

96 ：デフォルトの名無しさん：2009/06/05(金) 13:54:25

グーチョキパーが互いに知り合って、
それぞれが勝ち負けを判断するような密な結合より、
グーチョキパーの関係性を記述するために特化したMediatorオブジェクトを用意し、
グーチョキパー事態は互いを知らなくていい、
ポーとかペーとかが発生した場合に修正を個々にしなくていい、
という緩い結合にしておくことに、そこにメリットを見出すため。

97 ：デフォルトの名無しさん：2009/06/05(金) 13:54:52

後だしする奴とかいるから、ちゃんとジャッジしてくれる人がいたほうがよくね？

98 ：デフォルトの名無しさん：2009/06/05(金) 14:04:30

>>96
単に独立した判定役がいればいいわけで,
object とか class じゃなくてもええんちゃう

CLOS 的には審判 object(審判 class)は作らんな, たぶん

99 ：デフォルトの名無しさん：2009/06/05(金) 14:19:00

>>93
有限/無限は量概念なのに、「質的に有限」ってw

100 ：デフォルトの名無しさん：2009/06/05(金) 14:31:33

>>95
審判作りたくないのなら、
プレイヤー同士で判定して、合意の下に
勝負を付ける仕組みでいいんじゃないか？

101 ：デフォルトの名無しさん：2009/06/05(金) 14:35:58

>>98
じゃんけん大会の内容に応じて取り替えられればいいだけなんで、
別にobjectでもええんちゃう

102 ：デフォルトの名無しさん：2009/06/05(金) 14:47:27

「構造化しないで上から下に書いていけばいいんちゃう？」
と言うのと同じな気がしてきました。

103 ：デフォルトの名無しさん：2009/06/05(金) 19:01:47

>>95
変化とか量産とかが無いとオブジェクト指向で書くメリットはあんまりないよ
グーチョキパーの勝ち負けのルールが変わるとか
非同期で同時に100個のジャンケン判定しないといけないとか
そういうのが無いと

104 ：デフォルトの名無しさん：2009/06/05(金) 19:33:20

ここで話すオブジェクト指向て実装面だけか？

設計だけオブジェクト指向でやって実装はオブジェクト指向にしないって現場もあるが。ゲーム開発とか。

105 ：デフォルトの名無しさん：2009/06/05(金) 20:19:04

>>104
設計と実装を分けて論じてはいけないスレです。

106 ：デフォルトの名無しさん：2009/06/05(金) 20:27:05

もし設計と実装が無関係なら、なんのために設計するんだ？

107 ：デフォルトの名無しさん：2009/06/05(金) 20:36:30

抽象レベルが違うのだから、いっしょくたに論じるほうがよほど問題だろ

108 ：デフォルトの名無しさん：2009/06/05(金) 20:43:23

多様性が必要無いならオブジェクト指向ってのは意味が無いどころかマイナスだ

109 ：デフォルトの名無しさん：2009/06/05(金) 21:30:19

要するに、異なる抽象レベルが互いに影響し合うシステムが
同じソースコードにいっしょくたに書かれてるんで
ソースコードから特定の抽象レベルだけを抽出したものを論じるなり何なりすればいい

110 ：デフォルトの名無しさん：2009/06/05(金) 21:38:41

それ「要するに」してない
それ以前に日本語してない

111 ：デフォルトの名無しさん：2009/06/05(金) 23:20:25

>>104
常識的に考えたら、設計がオブジェクト指向なら実装もオブジェクト指向じゃないの？
オブジェクト指向言語（機能）を使わない、オブジェクト指向実装じゃないの？

112 ：デフォルトの名無しさん：2009/06/05(金) 23:31:40

>>104
実際にオブジェクト指向の設計をどう非オブジェクト指向な実装に落とすのか
具体例を出してもらえる？

113 ：a36 ◆K0BqlCB3.k ：2009/06/05(金) 23:33:55

>>112
つ　コンパイラ

114 ：デフォルトの名無しさん：2009/06/05(金) 23:42:30

>>113
それはレイヤーが違う。
設計->ある言語による実装と、ある言語での実装->バイナリを混同するな。

115 ：デフォルトの名無しさん：2009/06/06(土) 00:35:06

メッセージングはインターネットのような広い空間の緩い結合には適してる。
でも、プログラムの世界はもっと情報同士が密結合で信頼性も高い。
そういう世界でオブジェクトみたいな殻を作ると、無駄な伝言と依存性の不透明さが増して、
弊害が大きいと思うんだよね。
特にすべてがオブジェクトとか言われると。
# それはおまえの設計が悪いとか言わないでね。
# 不都合な事は全部設計が悪くてOOのせいじゃないというセリフは聞き飽きた。

116 ：デフォルトの名無しさん：2009/06/06(土) 00:43:53

少々プログラムの効率性犠牲にしてでもコード中に秩序を作り上げた方が生産性が高まることは多々あるわけで。
すべてがオブジェクトというやり方も、それが常にベストな解では無いと思うが、
LLなどではそういうやり方もありだろう。

117 ：デフォルトの名無しさん：2009/06/06(土) 00:47:37

>>116
いや、私が言いたいのは効率の話じゃなくて。
メッセージングやオブジェクトという仕組みでは、プログラムの秩序がより乱されてる
だけだと思う訳です。

118 ：デフォルトの名無しさん：2009/06/06(土) 00:56:28

すべてがオブジェクト、とかで作ると、でしょ？
それぞれに適した書き方すればいいんじゃないの
汚い部分を一手に引き受けるクラスとかがあっても問題ないでしょ
デザインパターンのfacadeみたいな

119 ：デフォルトの名無しさん：2009/06/06(土) 01:02:11

>>115
メッセージングはいいけど、たとえばJavaやSmalltalkでのオブジェクト間のメッセージングはただの関数呼び出しだよね？
たくさんのオブジェクトが存在する中で、実行中なのが常に一つっていうのはちょっと変じゃないのって話。
それって実世界の間隔とはかけ離れているよね。

120 ：デフォルトの名無しさん：2009/06/06(土) 01:03:30

×間隔
○感覚

121 ：デフォルトの名無しさん：2009/06/06(土) 01:09:48

オブジェクト云々の話は置いとくとしても、結合度は下げた方がいいと思うんだが。
「なんでも自由にお触りください」というものを使ってきれいに仕上げるのには
強い心が必要になるけど、あらかじめ「可能な操作はこれだけです」と決めておけば
心の支えにはなるでしょ。

122 ：デフォルトの名無しさん：2009/06/06(土) 02:25:26

>>115
前半はいまいち理解できない(普段そのように感じてはいない)けど、後半は納得。

>　特にすべてがオブジェクトとか言われると。
特にこういう部分がOO(の教祖、信者)のダメなところだと思う。

以前会社の後輩が設計、実装したプログラム(C++)では、
普通の数学的な意味の関数を作るだけですむような計算処理を、
あえてクラスとして実装していた。
このため、計算処理を行うためには、そのクラスのインスタンスを生成し、
そのインスタンスのメソッドを呼ばなくてはならなかった。
(そのメソッドを呼んだあとはインスタンスは用済みなのでインスタンスの破棄まで
しなければならない。)

123 ：デフォルトの名無しさん：2009/06/06(土) 03:28:02

いや、仮にOOPの信者でもそういうのは普通に関数にしたり
ユーティリティクラスにしたりすると思うんだが。
問題は後輩がOOPの信者だったことではなくて、単に経験が
足りなかったことなのではないかと。

124 ：デフォルトの名無しさん：2009/06/06(土) 03:48:11

>>122
普通そういうのはnamespaceに閉じ込めた関数にするか、OO信者でどうしても
クラスにしたかったとしてもstaticメソッドにするはず。
C++をあまり知らないから何でもインスタンスメソッドにしたがるんだろう。

125 ：デフォルトの名無しさん：2009/06/06(土) 07:28:12

シナリオ書いてクラス図やインタラクション図を起こして、
一旦OODで機能とデータを洗い出してから、
機能毎にモジュールを切り直してCで実装、
ってのは結構ありがちなパターンだったりする。

126 ：デフォルトの名無しさん：2009/06/06(土) 09:02:38

staticメソッドの無い言語って多分無いからな
つまりはそういうことだ

Needless Complexityは避けろって普通は言われる

127 ：デフォルトの名無しさん：2009/06/06(土) 09:29:30

まあ、普通の関数ですむと思ってるのは自分だけで
文字列操作のように、関数にするよりもクラスにして操作するほうが自然な物だったりしてな

128 ：デフォルトの名無しさん：2009/06/06(土) 10:16:19

プログラム内のある意味のある塊をどうまとめるか。
オブジェクトというまとめ方しか知らない・出来ないのは不幸だ。

129 ：デフォルトの名無しさん：2009/06/06(土) 10:18:03

日本人は「自分だけ」に弱い。

130 ：デフォルトの名無しさん：2009/06/06(土) 11:35:10

「俺の周りは」なんて言ってる奴には、永遠に理解できないもの
それが、オブジェクト指向

131 ：デフォルトの名無しさん：2009/06/06(土) 12:23:50

Eiffelｻｲｺｰ!!!!!!!!!!!!!

132 ：デフォルトの名無しさん：2009/06/06(土) 12:41:53

「実はただの関数呼び出しだよね？」と聞くと、
「関数呼び出しにたとえるのはダメ」と言われることがある。
関数呼び出しを使わないOOPの実装もありえると言いたいんだろう。

でも、一般論の前にまず特定の実装を知るべきだよな。
一般論だけを語りたがる風潮にも問題があると思う。

133 ：デフォルトの名無しさん：2009/06/06(土) 13:57:18

関数を動的に探索して、適切な関数を呼びだす、
ということを実行時におこなうのが普通の「関数呼び出し」だと主張するのなら、
OOPLでのメッセージ送信の多くの実装は関数呼び出しと言えるかもしれないけどね。

実際には普通の「関数呼び出し」では呼び出される関数はコンパイル時に確定しているから、
OOPLでのメッセージ送信の多くの実装は単なる関数呼び出し以外のこともやっているよね。

134 ：デフォルトの名無しさん：2009/06/06(土) 14:02:00

>>133
>>119

135 ：デフォルトの名無しさん：2009/06/06(土) 14:05:04

はあ？
>>133は>>119への反論だと思うが？

136 ：デフォルトの名無しさん：2009/06/06(土) 14:09:41

自分で処理系を書いたことがない人は>>119みたいな発想になるんだろうな。

137 ：デフォルトの名無しさん：2009/06/06(土) 14:13:58

>>130
永遠に理解できないなんて、なんてえらそうな技術。
それがオブジェクト指向という宗教。サイエンスのかけらもない。

138 ：デフォルトの名無しさん：2009/06/06(土) 15:09:22

>>136
処理系はバリバリ書いてきた方が、
それはともかくとしてなんで処理系を書いたことがないと>>119みたいな発想になると思うのか、
その論理のつながりが解らん。

139 ：デフォルトの名無しさん：2009/06/06(土) 15:15:13

お前らの頭悪そうなレス見てると優越感に浸れる
ありがとう

140 ：デフォルトの名無しさん：2009/06/06(土) 15:15:36

つーかメッセージングか関数呼び出しかについては前スレで終わったんじゃないの？
前スレで出ていないような新規の主張をするならいいが、そうとは思えないぞ。

141 ：デフォルトの名無しさん：2009/06/06(土) 16:53:14

>>138
実際には処理系を書いたことがないから、わからないんじゃないかなあw

142 ：デフォルトの名無しさん：2009/06/06(土) 17:11:59

>>141
俺にはお前が口先だけの奴に見える

143 ：デフォルトの名無しさん：2009/06/06(土) 17:18:25

>>142
では、インターフェース型の変数がメッセージレシーバになっている場合の
メッセージ送信をおこなうために必要な処理をCで書いてみなさい。
同様に、簡易版でいいからC風の言語のコンパイラも書いてみなさい。
この2つの実装がまるで別物だということがよく理解できるから。

144 ：デフォルトの名無しさん：2009/06/06(土) 17:19:03

>>143
できるが、お前の態度が気に入らない

145 ：デフォルトの名無しさん：2009/06/06(土) 17:20:50

技術への攻撃が続かなくなったから、
今度は人格攻撃ですか。なるほど。

146 ：デフォルトの名無しさん：2009/06/06(土) 17:22:47

誰が見ても>>143の態度は気に入らないだろうな。
それ以前に言ってることが意味不明だし。

147 ：デフォルトの名無しさん：2009/06/06(土) 17:25:25

>>143
もったいぶらずに違いを教えてくれよ（*´∀｀*）
さあさあ。

148 ：デフォルトの名無しさん：2009/06/06(土) 17:26:37

確かにもったいぶり過ぎだな
本当にこいつは自分が言ってることが解って言っているのかと疑問に思えてくる

149 ：デフォルトの名無しさん：2009/06/06(土) 17:28:14

こんなクソスレでコンパイラ書けなんて言われて書く奴がいるかっつーの。
こういう非現実的なことを押し付けようとする奴って何様なんだろうかね。

150 ：デフォルトの名無しさん：2009/06/06(土) 17:28:47

>>143読んでわからないようなら能力がないからこの業界から足を洗ったほうがいい。
本人も周りもそのほうが幸せになれる。

151 ：デフォルトの名無しさん：2009/06/06(土) 17:29:12

コンパイラ作成系の本読んだところで
それっぽいこと語りたいガキだろ

152 ：デフォルトの名無しさん：2009/06/06(土) 17:29:29

erlangとかのメッセージ送信を見ればオブジェクト指向のメッセージングのモデルがいかに不自然かわかるだろ。
そもそもオブジェクト指向はメッセージングじゃない。
ただの関数呼び出しだ。

153 ：デフォルトの名無しさん：2009/06/06(土) 17:29:47

Cardelli厨の再来か？

154 ：デフォルトの名無しさん：2009/06/06(土) 17:30:48

>>150
早く「俺はまだまだ未熟でした、ごめんなさい」と言えよｗ
潔く負けを認めないかぎり、お前のスキルは一歩も前に進めないんだぞ。

155 ：デフォルトの名無しさん：2009/06/06(土) 17:36:17

最終的には「リンク先読め」「本読め」だの言ってお茶濁すやつ多いなｗ
自分の言葉で簡潔に表現できないｗ

あと、文章を引用してきて朗読するだけとかｗ

156 ：デフォルトの名無しさん：2009/06/06(土) 17:39:24

>>152
> そもそもオブジェクト指向はメッセージングじゃない。
> ただの関数呼び出しだ。

それを言うのなら、
「そもそも現在のOO実装は関数呼び出しがベースになっているから、
メッセージングによる本来のオブジェクト指向じゃない」
だろう。

157 ：デフォルトの名無しさん：2009/06/06(土) 17:43:22

そもそもメッセージングを厳密に実装してなんか良いことあんの？

158 ：デフォルトの名無しさん：2009/06/06(土) 17:43:54

必要なものはただの関数呼び出し。
だから、本来のオブジェクト指向は必要ないんだな。

>>127
関数が外部の変数に依存しないときは関数を作る。
関数の外側の変数を使いたいときはクラスを作る。
これで間違いない。

159 ：デフォルトの名無しさん：2009/06/06(土) 17:45:26

メッセージ送信という抽象モデルと、
メソッド探索＋関数呼び出しという実装を、
ごちゃごちゃにするから混乱してるんじゃね？

160 ：デフォルトの名無しさん：2009/06/06(土) 17:46:27

>>158
たぶんお前が一番レベル低い。

161 ：デフォルトの名無しさん：2009/06/06(土) 17:48:21

>>159
そういうことだな

162 ：デフォルトの名無しさん：2009/06/06(土) 17:48:24

>>158
> 関数が外部の変数に依存しないときは関数を作る。
> 関数の外側の変数を使いたいときはクラスを作る。

キミ、どこの土方よ？

163 ：デフォルトの名無しさん：2009/06/06(土) 17:50:17

オブジェクトAとオブジェクトBがそれぞれ別スレッドで動作してるとき、
AからBに(関数呼び出しによる)メッセージを送ったばあい、Bのメソッドを実行する実体は
Aのスレッドだったりして、そういうのが気持ち悪いと思うことはある。

164 ：デフォルトの名無しさん：2009/06/06(土) 17:53:09

非同期管理はまた全然別の話だろう

165 ：デフォルトの名無しさん：2009/06/06(土) 17:54:05

ちょくちょくスレッド間の同期を混ぜるやつが居るなｗこのスレにはｗ

166 ：デフォルトの名無しさん：2009/06/06(土) 17:55:44

>>162
レッテルを貼るだけでは何の意味もないだろ

167 ：デフォルトの名無しさん：2009/06/06(土) 17:55:59

この中でerlangをさわったことがある人、もしくはpi-calculusを勉強したことがある人はいるの？

168 ：デフォルトの名無しさん：2009/06/06(土) 17:59:02

>>167
俺は、無い！（´；ω；｀）　一番処理系に近づいたのはRHGを読書した時ｗ

169 ：デフォルトの名無しさん：2009/06/06(土) 18:09:27

>>159
実装と無関係な抽象モデルを作っても無駄じゃないの
関数呼び出し前提でモデル作ればいいじゃん

170 ：デフォルトの名無しさん：2009/06/06(土) 18:16:50

>>143
コンパイラ書けとか言うなら、せめてお前さんがASTに落とすまでのフロントエンドと
中間形式に変換した以降のアセンブリコードを吐くまでのバックエンドを自分で
書いて用意したらどうだ？これらの部分はお前さんの主張を「理解させる」上で
本質的ではないからな。
人にやれと言うくらいだから、この程度は簡単に書けるだろ？

171 ：デフォルトの名無しさん：2009/06/06(土) 18:27:12

>>169
実装ありきでモデルを作るんじゃなくて
まずモデルがあってそれを実現するために実装があるんだぞ

172 ：デフォルトの名無しさん：2009/06/06(土) 18:42:40

>>171
デスマを防ぐためにモデルを作るっていう発想はないんだな
絶望した

173 ：デフォルトの名無しさん：2009/06/06(土) 18:42:55

erlangって変数を設定したら２度と値を変えられないんだよね。
頭が硬くてプログラムを作れなくて使うのをあきらめますた。

174 ：デフォルトの名無しさん：2009/06/06(土) 18:43:08

？？？

175 ：デフォルトの名無しさん：2009/06/06(土) 18:53:40

>>172
そうじゃなくてモデルを作る時は
実装時に変な足かせになったりしないように抽象的な書き方をするのが基本だろ
論点ずらしもいいとところだぞ

176 ：デフォルトの名無しさん：2009/06/06(土) 18:59:59

>>175
関数呼び出しを前提にすることが、変な足かせになるの？

177 ：デフォルトの名無しさん：2009/06/06(土) 19:37:18

erlangは知らんが、ScalaのActorみたいなのがオブジェクト指向の
メッセージパッシングの理想型だったりするのか？

オブジェクトがそれぞれ別のスレッド（もどき）で動いてて、それぞれの
メールボックスに入ってるメッセージを順次読み出して実行・返信みたいな。

178 ：デフォルトの名無しさん：2009/06/06(土) 21:23:35

あーまだやってたのか

結局 OO なんてのは「明確な定義もないただの幻想」
ってのが、前スレの結論じゃなかったのか？

179 ：デフォルトの名無しさん：2009/06/06(土) 21:30:10

「前スレの結論」っていうのは大抵、
前スレで一番最後に目立っていた香ばしい強弁のことだよね。

180 ：デフォルトの名無しさん：2009/06/06(土) 21:31:13

「前スレで俺が言ったこと」だろ

181 ：デフォルトの名無しさん：2009/06/06(土) 21:43:08

じゃ、誰か OO の明確な定義をしてみてくれよwW

182 ：デフォルトの名無しさん：2009/06/06(土) 21:45:00

関数がない言語は少ないが、クラスがない言語はたくさんある。
クラスが役に立たないわけじゃないが、
クラスに似た方言がたくさんあって統一できてない感じがする。

183 ：デフォルトの名無しさん：2009/06/06(土) 21:53:49

大学出てる奴いないだろｗ
お前らは市販の参考書でお勉強した程度のレベルだ

184 ：デフォルトの名無しさん：2009/06/06(土) 21:55:37

> 大学出てる奴いないだろｗ
それは暴言だろ?
Fランだって大学は大学だろうに…

185 ：デフォルトの名無しさん：2009/06/06(土) 22:16:28

λ計算、オートマトン、関係代数、述語論理、π計算、グラフ理論など
まともな議論が出来る土台がソフトウェア技術を大幅に進歩させている中、
OOに関する議論はメッセージだのオブジェクトだのカプセル化だの、相変わらず不明確で不毛な論争が続くのみ。
これはOOが属人的なノウハウの域を脱していない証拠。
さて、ではOOをまともな議論の土台に載せるにはどうすればいいのでしょう？
やっぱりσ計算？

186 ：デフォルトの名無しさん：2009/06/06(土) 22:17:29

σ計算＝型理論＋操作的意味論

187 ：デフォルトの名無しさん：2009/06/06(土) 22:18:03

そもそも大学でオブジェクト指向とか教えてるのか？

188 ：デフォルトの名無しさん：2009/06/06(土) 22:34:31

>>186
操作的意味論があるなら、そこからクラス設計の優劣が定量的に計れたりしないだろうか？
総合的なものじゃなくても、特定の側面（結合度とか）だけでもいいので。
そういう論文が読みたい。

189 ：デフォルトの名無しさん：2009/06/06(土) 22:56:09

凝集度ならcohesion metricsで検索すればそれらしいものがでてくる

190 ：デフォルトの名無しさん：2009/06/06(土) 23:11:13

>>189
ありがとう。こんなに親切な御仁がいるとは思わなかった。
実はσ計算についても殆ど何も知らないので、OOの特徴(例えばMLのモジュールとの違い）を
σ計算の言葉で言い直すことができる事を期待して勉強してみます。
五十嵐先生まんせー。

191 ：デフォルトの名無しさん：2009/06/06(土) 23:18:41

σ計算について詳しい本なんてこれぐらいしか知らない

Amazon.com: A Theory of Objects (Monographs in Computer Science): Martin Abadi, Luca Cardelli: Books
http://www.amazon.com/dp/0387947752/

簡単に概要を知るだけならLuca CardelliのサイトのPaperの
Objectカテゴリにある論文を見ればいいんだけど

192 ：デフォルトの名無しさん：2009/06/06(土) 23:26:44

>>185
> さて、ではOOをまともな議論の土台に載せるにはどうすればいいのでしょう？
> やっぱりσ計算？

それ以前に OO の明確な定義付が必要だってば
何見てもオレオレ定義じゃん

193 ：デフォルトの名無しさん：2009/06/06(土) 23:32:13

http://lucacardelli.name/Papers/ObjectEncodings.pdf
ベースはFω<:かぁ。ふむふむ。

194 ：デフォルトの名無しさん：2009/06/06(土) 23:38:57

>>192
まともに議論できる土台であるσ計算の言葉でOO（に似たなにか）を言い替えてみる。
↓
これをOOの定義にしよう！（というコンセンサスが広がる）
↓
うまー

195 ：デフォルトの名無しさん：2009/06/06(土) 23:51:27

ちなみに、さっきから教えて君している私は学生でも院生でもなく、
職業プログラマなので、学生乙は禁止。

196 ：デフォルトの名無しさん：2009/06/07(日) 01:50:45

Software Engineering != Computer Science
http://www.ddj.com/architect/217701907

この人は学者じゃないが、まあ言ってることは大体正しいな。

197 ：デフォルトの名無しさん：2009/06/07(日) 02:11:53

懐かしい、DDJじゃないか。
日本でも雑誌出してたよな。

198 ：デフォルトの名無しさん：2009/06/07(日) 05:35:37

オブジェクト指向ってのはスパゲッティ指向をカッコヨク表現したものなんだよ

199 ：デフォルトの名無しさん：2009/06/07(日) 08:07:29

DDJの記事についてスラドで話題になってるな。
いきなりCを関数型言語だとか言う奴がいたり、それに食ってかかる奴等がいたり
このスレに似てるな。

http://tech.slashdot.org/story/09/06/06/0210229/How-Software-Engineering-Differs-From-Computer-Science

200 ：デフォルトの名無しさん：2009/06/07(日) 08:11:23

>>126
VBScript(否.NET)なめんな

201 ：デフォルトの名無しさん：2009/06/07(日) 11:53:58

>>198
スパゲティ指向ってのは言いえて妙かもしれない

202 ：デフォルトの名無しさん：2009/06/07(日) 12:33:10

茹でる前のスパゲティが理想なのに、気が付けば茹で上がったスパゲティって事か?

203 ：デフォルトの名無しさん：2009/06/07(日) 12:54:04

だとしても生麺なんて食いたくないね

204 ：デフォルトの名無しさん：2009/06/07(日) 12:58:05

OOはOOPだけにして、柔軟性と抽象化のためのテクとして受け取ればよかった。

分析と実装がどうの、現実世界＝オブジェクト、メッセージがうんたら、
これをばっさり捨てたらよかったのにね。

205 ：デフォルトの名無しさん：2009/06/07(日) 13:00:33

それがDbC
ユーザ定義の抽象型上の動的多態と拡張されたホーア論理を使ったよる制約プログラミング

206 ：デフォルトの名無しさん：2009/06/07(日) 13:16:43

お歳暮に渡すソーメンを買ってきたのに
何故か、そのソーメンで昼飯を作っちゃうみたいなwwww

207 ：デフォルトの名無しさん：2009/06/07(日) 14:53:38

>>204
> 分析と実装がどうの
この人たち OO を出せば客が尊敬してくれると思ってる連中だと思うよ

一昨年かな、急遽、長年付き合いのある映像関連のシステム作ってる
会社の手伝いをする羽目になった。

内容としては「既にあるシステムの出力フォーマットをMP4でラップしたい」だった

最初に頼んだところは、「いまから OO 分析してどーたらこーたら」と言うばかりで
実質的には何もしなかったそうだW

208 ：デフォルトの名無しさん：2009/06/07(日) 15:47:00

オブジェクト指向とそれ以外の違いなんて
instance.method()とmethod(instance)の違いくらいしかないんじゃないの？

209 ：デフォルトの名無しさん：2009/06/07(日) 15:53:55

CLOS では (method instance) なわけだが

210 ：デフォルトの名無しさん：2009/06/07(日) 15:58:20

>>208
そういう不用心な事を言うと、マルチプルディスパッチこそがOOの肝だろうが、
って言われちゃうぞ。

211 ：デフォルトの名無しさん：2009/06/07(日) 16:41:26

・カプセル化
・継承
・ポリモーフィズム

212 ：デフォルトの名無しさん：2009/06/07(日) 17:20:38

いまだにカプセル化とか言うアホがそんざいするんだ

213 ：デフォルトの名無しさん：2009/06/07(日) 17:33:44

>>212
カプセル化とか言うアホとは？

214 ：カプセル化：2009/06/07(日) 17:34:49

俺俺、俺のこと

215 ：デフォルトの名無しさん：2009/06/07(日) 17:40:19

　　　　　　　　ゴガギーン
　　　　　　　　　　　　　ドッカン
　　　　　　　　　ｍ　　　　ドッカン
　　＝＝＝＝＝）　）)　　　　　　　　　☆
　　　　　 ∧_∧ |　|　　　　　　　　　／　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣
　　　　　（　　　）|　|＿＿＿＿＿　　　　∧＿∧　　　＜　　おらっ！出てこい>>212
　　　　　「　⌒￣　|　　　|　　　　||　　　（´Д｀　）　　　　＼＿＿＿＿＿＿＿＿＿＿＿
　　　　　|　　　/ ￣　　　|　　　　|/　　「　　　＼
　　　　　|　　　|　|　　　　|　　　　||　　　 ||　　 /＼＼
　　　　　|　　　 | |　　　　|　　　　|　　へ//|　　|　　| |
　　　　　|　　　 | | 　　　ﾛ|ﾛ　　　|／,へ＼|　　|　 | |
　　　　　|　∧　| |　　　　|　　　　|／　　＼　　/　（　）
　　　　　|　|　|　|〈　　　　|　　　　|　　　　　|　|
　　　　 / /　/ / |　　/ 　|　　　〈|　　　　　|　|
　　　 / /　 / /　|　　　　|　　　　||　　　　　 |　|
　　　/ /　/ /　=-----=--------　　　　 |　|

216 ：デフォルトの名無しさん：2009/06/07(日) 17:47:52

カプセル化機能のないOO言語って山ほどあるのに…

クラス定義でアクセス属性決定する意味あるのか?

217 ：デフォルトの名無しさん：2009/06/07(日) 18:13:30

アクセス属性が必要ないのに、アクセス属性が付いてるって?
ご冗談をwww

218 ：デフォルトの名無しさん：2009/06/07(日) 18:15:29

private/publicとかの存在意義に疑問を投げかけてるのか・・・？

219 ：デフォルトの名無しさん：2009/06/07(日) 18:18:42

>>215
　　　　　|┃三　　　　　　　／￣＼
　　　　　|┃ 　　　　　　　　|　　　　|
　　　　　|┃　　　　　　　　＼＿／
　ｶﾞﾗｯ.　|┃　　　　　　　　　|
　　　　　|┃　ﾉ//　　　.／￣￣￣＼
　　　　　|┃三　　　　／　 ::＼:::／::::　＼
　　　　　|┃ 　　　／　 <●>::::::<●>　　＼
　　　　　|┃　　　 |　　　　（__人__）　　　　|
　　　　　|┃三　　＼　　　｀ ⌒´　　　　／
　　　　　|┃三　　／￣￣￣￣￣￣￣＼

220 ：デフォルトの名無しさん：2009/06/07(日) 19:07:16

お前らの話のどこがおもしろいのか解らん。
議論してる奴らもUMLとC/C++とJavaぐらいしか知らない奴ばっかりっぽいから、
知識不足で底が浅い議論になってるように見える。

221 ：デフォルトの名無しさん：2009/06/07(日) 19:08:12

話に面白さを感じるには、一定の知能が必要だな。

222 ：デフォルトの名無しさん：2009/06/07(日) 19:59:43

その一定の知識ってハードルがすごく低いんだと思うよｗ

223 ：デフォルトの名無しさん：2009/06/07(日) 20:05:52

どうせ2chじゃまともな議論にならないしな。
他でやれば結構面白い議論に発展するかもしれんが。

224 ：デフォルトの名無しさん：2009/06/07(日) 20:25:53

こんなところで議論とかｗ

225 ：デフォルトの名無しさん：2009/06/07(日) 21:57:07

ぶぴぶぴ
最高だこの力・・・

226 ：デフォルトの名無しさん：2009/06/07(日) 22:06:55

中を見えなくするとか隠蔽とか言われても中知りたくなる件ｗ

227 ：デフォルトの名無しさん：2009/06/07(日) 22:19:27

好きな子のパンツはやっぱり見たいよな

228 ：デフォルトの名無しさん：2009/06/07(日) 22:39:06

・カプセル化したければinterfaceを使い、classは全部公開
・継承はinterfaceのみ可
・ポリモーフィズムは↑に反しない限り自由

229 ：デフォルトの名無しさん：2009/06/07(日) 23:00:04

>>228
それはww構造的www部分www型ww

230 ：デフォルトの名無しさん：2009/06/07(日) 23:14:46

お前らOOPの影響で不況になったの解ってる？
OOPが原因でアウトソーシングなんて発生したんだよ？

231 ：デフォルトの名無しさん：2009/06/07(日) 23:33:59

こら！
なんでもかんでもオブジェクト指向のせいにするなアホ
OOを使う人間が無能だっただけでOOが悪いわけじゃないということにいい加減きづけよな

232 ：デフォルトの名無しさん：2009/06/07(日) 23:46:22

>>231
実際経営者というか管理の上流は
OOすることにより、製造業の部品が簡単に作れると勘違い
するようになった。もう複雑なOSなんて知らなくてもいいし
OOするだけで製造コストが劇的に下がると妄想を抱くようになった。

もし構造化のみだったらそんなこと無かったよ
コンサルなんて意味のない職業が台頭することもなかったし
管理のみの上流工程とか意味のない職種も誕生しなかった
全てがC++やJavaなどに代表されるOOがもたらした弊害でしょ

ジョエルもJavaスクール（笑）の影響でITがおかしくなったと言ってるぞ
金融破たんだって、JavaなんかのOOで簡単かつ乱雑にマネーゲームを
しかけることができるのが原因の１つだし

OOが無ければこれだけ異常な下請けや不況は起きなかった

233 ：デフォルトの名無しさん：2009/06/07(日) 23:52:41

多重下請け構造とアウトソージングは別物のような…
日本の業界だと一緒くたにされがちだけど

234 ：デフォルトの名無しさん：2009/06/07(日) 23:57:32

弊害といえば弊害だけど
最後の方はさすがに飛躍し過ぎ

235 ：デフォルトの名無しさん：2009/06/07(日) 23:58:28

経営者はooとかしらないよw
なぜかというと、彼らは

236 ：デフォルトの名無しさん：2009/06/08(月) 00:04:23

>>231
>OOを使う人間が無能だっただけでOOが悪いわけじゃない
もう聞き飽きたよ、そのセリフは...。
はいはい、私は無能です。

237 ：デフォルトの名無しさん：2009/06/08(月) 00:09:18

それに見てみろ
Javaなんかはバージョン上がる度にがどんどん複雑になるが生産性が
Java1.3や1.4の頃とかわらない

Rubyなんて10年前からあるけど脚光浴びてるだけで
なんら普通の生産能力しかない。むしろ無い部品が多いから
キャッキャとエテコウのようにオナプロ実装しているに過ぎない
そしてC++はいまだに0xの仕様を最終局面まで詰めれないし
このまま永遠に仕様策定ごっこして終わり

つまりだ、OOはその仕組みを作ることからして莫大で無駄な時間を浪費
する悪魔でしかないのだよ。技術の技術として仕上げていくことに対して
OOは無駄なことが多い単なる技術屋が金を長期間搾取できるための悪材料
でしかないんだよ

238 ：デフォルトの名無しさん：2009/06/08(月) 00:11:44

>Rubyなんて10年前からあるけど脚光浴びてるだけでなんら普通の生産能力しかない。
普通筏と思われ。

239 ：デフォルトの名無しさん：2009/06/08(月) 00:17:53

で、

240 ：デフォルトの名無しさん：2009/06/08(月) 00:24:16

っていう

241 ：デフォルトの名無しさん：2009/06/08(月) 07:44:14

>>232
> もし構造化のみだったらそんなこと無かったよ
> コンサルなんて意味のない職業が台頭することもなかったし

コンサルは構造化以前から台頭していましたが何か？

> 管理のみの上流工程とか意味のない職種も誕生しなかった

ウォーターフォールは構造化以前から存在していましたが何か？

> OOが無ければこれだけ異常な下請けや不況は起きなかった

メインフレーム時代はもっとひどかったぞ。

242 ：デフォルトの名無しさん：2009/06/08(月) 08:01:50

OOA/OODって、結局現実世界のメタファーを使うことで、計算機科学を全く
理解していない素人が分かった気になってコンサルタントとか名乗り出して
美辞麗句を並べた。で、経営者もそれに騙されて無駄金使った挙句、結局
ろくな成果が出なくてOO自体が忌み嫌われる存在になってしまったのが
一番の悲劇だろうな。

OOのテクニック的には基本的に構造化の延長だし、そこまで筋は悪くないのに。

243 ：デフォルトの名無しさん：2009/06/08(月) 09:03:58

憂鬱本の方がOOSCより売れたという時点で南無…

244 ：デフォルトの名無しさん：2009/06/08(月) 09:18:45

OOSCたけぇ～もん。値段分の価値はあると思うけど。

245 ：デフォルトの名無しさん：2009/06/08(月) 09:22:21

言語によって実装方法が違ったこと。
滅茶苦茶な翻訳、訳語の混乱があったこと。
更にオレオレオブジェクト指向が大量に出現したこと。

混乱がありすぎた。

246 ：デフォルトの名無しさん：2009/06/08(月) 09:28:08

>>232にはオブジェクト指向が理解できないであろう事は良く分かった

247 ：デフォルトの名無しさん：2009/06/08(月) 09:42:24

OOには、goto的なものが多すぎる。
便利な機能を使いすぎると、かえって複雑になる。
バランスが非常に難しい。
C++なんて、マルチパラダイムとか言ってるが正気じゃない。
あれもこれも詰め込んだら、普通の人には適材適所で使うのが難しい。

248 ：デフォルトの名無しさん：2009/06/08(月) 10:14:00

>>247
× 普通の人には
〇土方の人には

249 ：デフォルトの名無しさん：2009/06/08(月) 12:10:35

OOではなくて関数型の言語の方が良い、っていう意見もここで
よく見るけれども、それほど良いものならなぜOOPLを駆逐して
広く普及しなかったのだろう? 皮肉ではなく、純粋な疑問として。

250 ：デフォルトの名無しさん：2009/06/08(月) 12:24:27

マイクロソフトが関数型言語を出さなかったから。
関数型言語なんて知らなくても使えるようにならないと流行らないよ。

251 ：デフォルトの名無しさん：2009/06/08(月) 12:24:47

>>249
ポピュラーなオブジェクト指向言語はC++やJavaなどのCの派生言語だから。
MLやHaskellなどは考え方を結構変えないと理解しがたいから、取っつきにくかったから。

252 ：デフォルトの名無しさん：2009/06/08(月) 12:26:10

>>250
MSができる前から関数型言語は存在したけど、PascalやCよりずっとマイナーだった。

253 ：デフォルトの名無しさん：2009/06/08(月) 12:32:33

schemeをほんの少しだけ触ったが括弧に混乱した
アレは人間の扱うもんじゃないと思うｗ

254 ：デフォルトの名無しさん：2009/06/08(月) 12:38:21

>>247
> OOには、goto的なものが多すぎる。

具体例を挙げよ (2点)

255 ：デフォルトの名無しさん：2009/06/08(月) 12:42:05

手続き型言語に慣れた人には関数型言語はとっつきにくいから。
そしてLispのシンタックスが抽象構文木そのものだったというのも
一般に広めるという上では仇になったと思う。
関数型も慣れれば非常に快適なんだけどね。

256 ：デフォルトの名無しさん：2009/06/08(月) 12:45:03

論理プログラミング言語はSQLって形で広まってるよ☆

257 ：デフォルトの名無しさん：2009/06/08(月) 12:47:49

ＳＱＬはプログラミング言語ではありません
知ってるプログラミング言語は何って聞かれてＨＴＭＬって答えるタイプ？ｗ

258 ：デフォルトの名無しさん：2009/06/08(月) 12:52:43

>>256
SQLはDBからデータをざっくり(下手すりゃ全行)引っ張るのだけに
使って、あとはJava等々で手続き的に処理したがる御仁も多いよう
ですが・・・手続き型の呪縛は強い。

259 ：デフォルトの名無しさん：2009/06/08(月) 13:00:51

教育とか普及度もあるだろうけれども、シンプルに人間の脳は
関数型より手続き型言語の方が理解しやすいように出来ているの
だと思う。関数型言語を使うには一段階脳の改造というか訓練を
必要とするというか。

260 ：デフォルトの名無しさん：2009/06/08(月) 13:22:25

短期記憶の容量が少ない奴は関数型言語に向いてないってこった。

261 ：デフォルトの名無しさん：2009/06/08(月) 13:24:42

短期記憶の容量を大きく要求しない手続き型スゲー。

262 ：デフォルトの名無しさん：2009/06/08(月) 13:26:52

>>260
つまり関数型言語が普及しない理由は短期記憶の容量が少ない奴
が多いからであると。

それなら初めっから普及の面で関数型に勝ち目なんて無いじゃん。

263 ：デフォルトの名無しさん：2009/06/08(月) 13:32:07

>>261
短期記憶の容量が少なくて済む代わりに、型バグ・副作用バグに悩まされるんだよね。

264 ：デフォルトの名無しさん：2009/06/08(月) 13:33:41

関数型言語が普及したら低学歴が業界から減ってくれそうでうれしい

265 ：デフォルトの名無しさん：2009/06/08(月) 13:35:11

低学歴だけじゃないな
ご隠居さんの戯れ言や長老達の世迷い言からも解放される

266 ：デフォルトの名無しさん：2009/06/08(月) 13:38:48

短期記憶ができないなら紙の上で色々式変形すりゃいいじゃん

267 ：デフォルトの名無しさん：2009/06/08(月) 13:39:59

>>266
どっちにしろラムダ計算を知らない奴らには荷が重いだろ。

268 ：デフォルトの名無しさん：2009/06/08(月) 13:41:07

関数型言語大好きなご隠居さんも大量にいるんだけど…
しかも実務経験に乏しいのとか…

269 ：デフォルトの名無しさん：2009/06/08(月) 13:46:07

>>268
そういうのは大学とかIT系以外に多いんじゃね？

270 ：デフォルトの名無しさん：2009/06/08(月) 13:48:07

なんだか関数型言語を使ったこと無い奴が多いようだけど、
情報系の学科で関数型言語を使った講義が無い大学ってあるのか？

それとも文系上がりのなんちゃってOOプログラマが多いのか？

271 ：デフォルトの名無しさん：2009/06/08(月) 13:51:59

理系学部出てプログラマになる奴なんて情報系でも少数派

272 ：デフォルトの名無しさん：2009/06/08(月) 13:53:36

そもそもOO言語ってSmalltalkとかでしょ？
関数型よりユーザー少ないような

273 ：デフォルトの名無しさん：2009/06/08(月) 14:07:18

>>271
職業プログラマじゃなくても仕事でプログラマしてる奴はいくらでもいるだろ？

274 ：デフォルトの名無しさん：2009/06/08(月) 14:10:21

おっと>>271が真理を言い放った。

275 ：デフォルトの名無しさん：2009/06/08(月) 14:10:48

>>258
そっちの方が速ければ、そうする。

276 ：デフォルトの名無しさん：2009/06/08(月) 14:11:31

>>273
s/仕事でプログラマ/仕事でプログラム

277 ：デフォルトの名無しさん：2009/06/08(月) 14:25:19

結局、

・歴史はある
・情報系の人間ならまず習う
・短期記憶が足りなくてもどうにかなる

それでもマジョリティになり切れない関数型言語って
どうなのさ。なんか根本的に残念なところとかある
んじゃないのかな。

278 ：デフォルトの名無しさん：2009/06/08(月) 14:31:45

モナドを知らないとHello Worldも書けない、とか？

279 ：デフォルトの名無しさん：2009/06/08(月) 14:35:13

M$を始めとするソフトウェアベンダー様方が力を入れてこなかったから

280 ：デフォルトの名無しさん：2009/06/08(月) 14:37:19

>>278
それはない

281 ：デフォルトの名無しさん：2009/06/08(月) 15:50:40

Pascalの残念なところを改良した、たぶん>>277でも気に入りそうな
Turingという言語があったけど、ちっとも広まらなかったよｗ

282 ：デフォルトの名無しさん：2009/06/08(月) 17:02:36

>>278
モナドもHaskellも知らない奴が「モナドを知らないとHaskellではプログラミングできない」と言い張る

283 ：デフォルトの名無しさん：2009/06/08(月) 18:02:39

関数型言語の欠点は、
1箇所の変更の影響が広範囲にわたること。
高階関数に微妙なバグがあると、
バグを特定してインパクトの小さな修正をするのが困難

284 ：デフォルトの名無しさん：2009/06/08(月) 18:06:23

現代の関数型言語を語る時にLisp系の話を持ち出すのは間違い。
あれはもう何年経ってもアカデミックな界隈でしか使われない。

誰がやってるのか、どこの会社がやろうとしてるとか等を考慮すれば、
F#とScalaだけに注目してればいい。

285 ：デフォルトの名無しさん：2009/06/08(月) 18:15:04

>>283
いや、影響はその関数の中だけでは？
要は関数ってのは入力と出力だよ。
出力以外の状態に変化が無いことが保証されているから、
入力されたデータに対する出力だけを見ていれば正常に動いているかどうかが一目瞭然なんだよ。
正しい入力をしたとき正しい出力が出ていればそれは正しい関数。
バグの特定は普通にprintデバッグとかいろんなデバッガを使ったデバッグでするところは他の手続き型言語と何も変わるところはないね。

286 ：デフォルトの名無しさん：2009/06/08(月) 18:19:04

>>284
> 現代の関数型言語を語る時にLisp系の話を持ち出すのは間違い。
> あれはもう何年経ってもアカデミックな界隈でしか使われない。
アカデミックな界隈ではLispは古くさいってイメージしかない。
使っているのは長老だけでは？

287 ：デフォルトの名無しさん：2009/06/08(月) 18:31:23

>285
それは、関数型言語の中でも特に誰も本番で使ってないといわれる、
純粋関数型言語の話でしょ。

オブジェクト指向言語の話する時にSmalltalkを大前提に語るぐらい
意味のない行為。

288 ：デフォルトの名無しさん：2009/06/08(月) 18:37:55

>>287
純粋関数型言語HaskellはOCamlやF#より話題に上りやすい言語なんだが。

289 ：デフォルトの名無しさん：2009/06/08(月) 19:58:52

>>287
それは lisp のように代入を許してる言語の話だろ?

だからと言って, ダイナミックバインドがある汚染された関数型言語でも,
スペシャル変数の使いどころとか理解できない糞には触ってほしくはない

# つか, クラス変数より遥かに役に立つダイナミック変数

290 ：デフォルトの名無しさん：2009/06/08(月) 20:11:04

関数型言語っていう括りはおおざっぱすぎるんじゃないかな。
Lisp, Schemeは関数型言語の仲間だけど、理論的な背景は無い。
そういう意味では、基礎の無いOOと同じ。

291 ：デフォルトの名無しさん：2009/06/08(月) 20:15:41

>>290
書かないだけで, 書こうと思えば純粋関数的に書けるわな > lisp 系
そもそもが型なしラムダ計算なんだから

292 ：デフォルトの名無しさん：2009/06/08(月) 20:26:08

>>291
いや、書けてしまうという時点で純粋じゃないんだよ。
そもそも純粋関数型言語であるのは機械的な解析がしやすいこと。
それはデバッグの自動化への将来性を意味する。

293 ：デフォルトの名無しさん：2009/06/08(月) 21:14:33

>>292
チューリング完全な任意の言語は
純粋関数型言語に機械的に翻訳できるが、それでも解析がしやすいと言うのか？

294 ：デフォルトの名無しさん：2009/06/08(月) 21:17:08

>>292
> それはデバッグの自動化への将来性を意味する。

実際には型エラーのデバッグだけでも自動化にはほど遠いけどな。
型推論自体がNP完全問題という現実を忘れないように。

295 ：デフォルトの名無しさん：2009/06/08(月) 21:27:07

>>294
まぁ、いろいろ研究があるから調べると良いよ。
特に奈良先端とかいっぱい論文出してる。

296 ：デフォルトの名無しさん：2009/06/08(月) 21:30:53

この話題は永久機関のように無限ループするな

297 ：デフォルトの名無しさん：2009/06/08(月) 21:32:37

無限ループせずして何が2chか！

298 ：デフォルトの名無しさん：2009/06/08(月) 21:37:16

>>295
型について質問することでバグを特定するシステムなら知ってるよ。
俺もその研究に関わってたことあるし。
でもあれは自動化の対極だ罠。質問に対して人間が適切に返答することが前提。
つーか、自動化は不可能なことが証明されているのに何を今さら？って感じ。

299 ：デフォルトの名無しさん：2009/06/08(月) 21:47:54

>>298
お前の知識は古すぎる

300 ：デフォルトの名無しさん：2009/06/08(月) 21:48:56

定理証明支援系じゃあるまいし。

301 ：デフォルトの名無しさん：2009/06/08(月) 21:57:26

>>299
では、型エラーのデバッグを完全に自動化することに成功した論文を挙げてくれ。

302 ：デフォルトの名無しさん：2009/06/08(月) 22:06:51

オブジェクト指向は分かるけど、便利なものを集めたオブジェクト的なものを作ってしまいますよね

303 ：デフォルトの名無しさん：2009/06/08(月) 22:08:48

>>301
関数型言語ではそもそも型エラーが起こりえないだろ？ｗ

304 ：デフォルトの名無しさん：2009/06/08(月) 22:12:13

>>302
それはオブジェクト指向を正しく理解していない。
オブジェクトが並列で動くイメージで作るんだよ。
でも実際にスレッドで並列で動かすと無駄が大きくなるから並列じゃないんだけどね。
どうしても本当の並列が必要になったときだけスレッドを使えばいい。

305 ：デフォルトの名無しさん：2009/06/08(月) 22:12:59

>>294
型推論がNP完全？決定不能の間違いでは？
NP完全は計算量のオーダーの話。
決定不能(undecidable)は計算可能性の話。
まぜるな危険。

306 ：デフォルトの名無しさん：2009/06/08(月) 22:19:14

ひょっとして停止性問題の事を言っているの？

307 ：デフォルトの名無しさん：2009/06/08(月) 22:21:13

>>291
>そもそもが型なしラムダ計算なんだから
Lispは形なしλ計算ではない。セルとその操作(carやcdr)を基礎とする言語。
一方λ計算とは、値とλ抽象とλ適用を項とし、βリダクションによって計算を進めるもの。
全く異なります。

308 ：デフォルトの名無しさん：2009/06/08(月) 22:22:42

×形なしλ計算
○型なしλ計算

309 ：デフォルトの名無しさん：2009/06/08(月) 22:23:54

関数型のほうが十分に生産効率も実行効率もいいなら、関数型が流行るだろうよ。
オブジェクト指向のほうが、現実のモデル化には適している。
問題は、モデル化にこだわって、かえって複雑になりがちなことだ。

310 ：デフォルトの名無しさん：2009/06/08(月) 22:39:10

>>304
>それはオブジェクト指向を正しく理解していない。
属人的なノウハウであるオブジェクト指向に「正しい」なんてないと何度言ったら(ry

311 ：デフォルトの名無しさん：2009/06/08(月) 22:44:18

正論だけど扱い辛い設計をする奴ほど態度がデカい

312 ：デフォルトの名無しさん：2009/06/08(月) 22:44:39

必要十分で適切なモデル化ならその複雑さは必要な複雑さ。
問題はモデル化と称していらんものをやたらと詰め込むこと。

313 ：デフォルトの名無しさん：2009/06/08(月) 22:45:52

単独の関数をオブジェクトと認めたがらないのが不思議。
関数ポインタで済むところでもクラス＋仮想関数を使わせるのは不自然。

314 ：デフォルトの名無しさん：2009/06/08(月) 22:47:54

関数ポインタがタイプセーフに扱えなかった頃の名残だよ

315 ：デフォルトの名無しさん：2009/06/08(月) 22:52:49

>>310
そんなことを言ってるんじゃないのｗ

属人的な要素が強いなら先輩の言うことは聞きなさい。

316 ：デフォルトの名無しさん：2009/06/08(月) 22:54:11

>>313
関数とオブジェクト指向で言うところのオブジェクトは別物だろ。
関数自体にメッセージを送れるか？
関数自体がメッセージを受信するか？

317 ：デフォルトの名無しさん：2009/06/08(月) 22:55:45

>>313
ファンクタがあるよ。

318 ：デフォルトの名無しさん：2009/06/08(月) 23:17:11

>>307
Lispがラムダ計算じゃないなんて馬鹿丸出しだぞ。
お前はChurch encodingも知らないのか？偉そうな事を言うなら少しは勉強してからに
したらどうだ？consもcarもcdrもラムダ式で表せるんだよ。

319 ：デフォルトの名無しさん：2009/06/08(月) 23:17:53

Scalaだけがこの暗黒の時代を救う
日輪となる唯一の言語

Scalaこそ最強
Scalaこそ救い

320 ：デフォルトの名無しさん：2009/06/08(月) 23:27:00

>>316
ドシロート意見だけど引数とは違うのん？

321 ：デフォルトの名無しさん：2009/06/08(月) 23:29:54

>>318
>consもcarもcdrもラムダ式で表せるんだよ。
λ計算で表現できる事とλ計算の定義とを混同していませんか？
Lispはλ計算の定義(>>307で簡単に書きました)をその基礎に採用していません。
これではLispはλ計算だと言えないと思います。
本当にλ計算を基礎としているのはMLです。

322 ：デフォルトの名無しさん：2009/06/08(月) 23:46:01

>>310
属人的だから、ノウハウで高い給料もらえるんじゃん。

323 ：デフォルトの名無しさん：2009/06/08(月) 23:46:19

>>320
関数は状態を持たないでしょう？
だから前に送ったメッセージの事は覚えてない

324 ：デフォルトの名無しさん：2009/06/08(月) 23:48:14

>>318
はいはい、習ったことを言いたいのは解るけど、恥ずかしいからやめてね

325 ：デフォルトの名無しさん：2009/06/08(月) 23:51:52

>>318
Lispが型無しかどうかはラッセルパラドックスが成り立つかどうかで調べれば良いんじゃないの。

326 ：デフォルトの名無しさん：2009/06/08(月) 23:52:34

>>321
Lispって処理系の実装法まで定義してるのか？
基本的にLispのコードはラムダ式で表せるのだから、後はbeta reductionすれば
良いだろう、というのが俺の意味するところなんだが。

327 ：デフォルトの名無しさん：2009/06/08(月) 23:56:55

>>304
スレッドなんて作ったって並列になんて動かないじゃん
こっちちょっと動かして、そっちちょっと動かしてを繰り返すのはまったくいっしょ
スレッドにしてなにか変わることあるの？
一定時間毎に呼び出したいとかハード的な何かのメッセージを待ってとか
通信でメッセージを待つとか
そういうコールバック的な用途でしか使う機会ないんだけど
スレッドって俺等ＰＧにとって並列に処理するためのもんか？（いや、定義は知らんけどね）

328 ：デフォルトの名無しさん：2009/06/08(月) 23:59:19

>>327
コールバックとスレッドは全く違う。
コールバックって関数の中の処理が終わるまで他のところに処理が移れないじゃん。

329 ：デフォルトの名無しさん：2009/06/09(火) 00:04:52

>>326
いいたい事の意味は分かります。
Common Lispは言語仕様ですが、その基礎的な仕様に例えばS式の定義があります。
その中でS式とは、シンボルとそのペアによって成り立つと定義されています。
これはλ項（値とλ抽象とλ適用によって成り立つもの）とは異なります。
もちろん、Lispのプログラムはλ計算に変換可能(だと思う。証明したことないけど）ですが、
それをもってLispはλ計算だという表現は拡大解釈だと感じます。

330 ：デフォルトの名無しさん：2009/06/09(火) 00:21:46

>>329
「値」じゃないよ。variableは「変数」

331 ：デフォルトの名無しさん：2009/06/09(火) 00:24:17

>>328
いや、コールバックじゃねぇなｗ
なんだっけ？
ポーリングだｗポーリングｗ

332 ：デフォルトの名無しさん：2009/06/09(火) 00:26:32

>>328
つまりよ
ハード的な要因があって何かを監視する必要があってそれと辻褄を合わせる的な用途でもないと
無理やりスレッドって形でプログラムを組む必要ってないじゃんってこと

333 ：デフォルトの名無しさん：2009/06/09(火) 00:27:22

非同期コールバックの事じゃねえの？

334 ：デフォルトの名無しさん：2009/06/09(火) 00:33:19

>>316
> 関数自体がメッセージを受信するか？

普通に受信しますがそれが何か？ｗ

| func |
func := SmallInteger compiledMethodAt: #+.
func valueWithReceiver: 3 arguments: #(4) "=> 7 "

335 ：デフォルトの名無しさん：2009/06/09(火) 00:34:17

>>330
どうも。うっかりしてました。
いい機会なので、λ項の定義を書いておきます。
1. 変数a,b,c,...はλ項である
2. M,Nがλ項のとき、(M N)はλ項である　（関数適用）
3. Mがλ項、xが変数のとき、(λx.M)はλ項である　（λ抽象）

336 ：デフォルトの名無しさん：2009/06/09(火) 00:34:23

>>334
副作用があるから関数ではない

337 ：デフォルトの名無しさん：2009/06/09(火) 01:11:56

>>327
マルチコア／マルチプロセッサになると違ってくるよ。
シングルコアだと動いてるのに、マルチコアにすると不具合が出るソフトは、
大抵スレッドがらみのバグだね。

プログラミング面から見たら、それぞれのタスクが独立して動いてくれた方が
楽なことがあるんだよ。もちろん、独自のタスク管理システムつくっても
いいんだけど、それはそれで面倒くさい。

338 ：デフォルトの名無しさん：2009/06/09(火) 02:11:12

>>337
スレッドのバグは状態を共有するところに問題の種がある。
だからこそ状態を共有しないメッセージングが重要なんだよ。

339 ：デフォルトの名無しさん：2009/06/09(火) 02:34:34

並列が便利だというのは手続き的に並列実行する感覚だとわかりにくいと思う。

340 ：デフォルトの名無しさん：2009/06/09(火) 03:29:50

>>338
一瞬解ったような気もしたけどやっぱり解らないのですが・・・
状態を共有する以前に、各スレッドが状態を持っていること自体が
問題の種だと思うのだけど、違うのかな。

341 ：デフォルトの名無しさん：2009/06/09(火) 03:40:11

>>340
各スレッドが状態を持っていると問題になる具体的な例を挙げてもらえますか？

各スレッドが状態を持つ問題点というのはおおよそ手続き型故の問題だと思いますが。

342 ：デフォルトの名無しさん：2009/06/09(火) 04:19:40

>>303
> 関数型言語ではそもそも型エラーが起こりえないだろ？ｗ

↑こいつ馬鹿？

343 ：デフォルトの名無しさん：2009/06/09(火) 04:27:31

>>305
Type inference with simple selftypes is NP-complete
ttp://portal.acm.org/citation.cfm?id=640132

344 ：デフォルトの名無しさん：2009/06/09(火) 04:36:07

>>340
状態を共有しているから相互干渉が発生するんだよね？
状態を共有せずにメッセージングで疎に結合しておけば
それぞれのスレッドの問題はそれぞれのスレッドに閉じるよね？

345 ：デフォルトの名無しさん：2009/06/09(火) 05:13:26

そんなにメッセージングが大好きならスレッドなんか使わずにMPIでも使ってろよ

346 ：デフォルトの名無しさん：2009/06/09(火) 05:18:14

>>343
selftype無しの言語だとP-completeじゃねーかよ
>>294は嘘つきも大概にしろよ

347 ：デフォルトの名無しさん：2009/06/09(火) 05:23:59

>>346
型推論一般ではNP-completeということじゃ？

348 ：デフォルトの名無しさん：2009/06/09(火) 05:29:29

>>347
selftypeってOO言語で使う物だろ
関数型言語の話をしている時にそういう言い方をするのは詭弁

349 ：デフォルトの名無しさん：2009/06/09(火) 05:40:47

つ岡村その他

350 ：デフォルトの名無しさん：2009/06/09(火) 06:08:36

>>349
Cardelli厨乙

351 ：デフォルトの名無しさん：2009/06/09(火) 06:41:41

ていうかスレッドがオブジェクト指向となんの関係があるのよ？

352 ：デフォルトの名無しさん：2009/06/09(火) 06:42:54

NP完全な場合とP完全な場合があるなら
全体はNP完全になるだろ常識

353 ：デフォルトの名無しさん：2009/06/09(火) 07:07:30

そもそも全体の話なんかしてないだろうが

354 ：デフォルトの名無しさん：2009/06/09(火) 07:08:32

全然関係ないことを無理やり結びつけて話を進めるやつがいるよね

355 ：デフォルトの名無しさん：2009/06/09(火) 07:30:02

スレッドもOOで考えたいという人もいるのかもな。
まぁ世の中なんでもかんでもオブジェクトですよ。

356 ：デフォルトの名無しさん：2009/06/09(火) 07:32:25

>>338
状態の共有がオブジェクトの共有に変わっただけだな。
直接アクセスせず関数を経由すると便利になるのは当たり前のこと。

357 ：デフォルトの名無しさん：2009/06/09(火) 07:40:56

トランザクションメモリがあれば
バグなんて発生しない

358 ：デフォルトの名無しさん：2009/06/09(火) 07:43:32

>>355
スレッドの原型であるlightweight processがactorモデルと相性よかったという歴史的背景があるわけだが。

359 ：デフォルトの名無しさん：2009/06/09(火) 08:31:02

関係無いじゃん
じゃ、普通の処理で済むところをスレッドにすることで扱いやすくなるの？
解釈間違ってんじゃない？

360 ：デフォルトの名無しさん：2009/06/09(火) 08:35:16

そもそも、並列にしか目が向いてなくね？
委譲したり継承したりできるわけだが

361 ：デフォルトの名無しさん：2009/06/09(火) 08:35:33

おまえは今、世界中のerlangerを敵に回した！

362 ：デフォルトの名無しさん：2009/06/09(火) 09:05:32

オブジェクト指向マンセーって言う人の
メイン使用言語は大抵
オブジェクト指向との親和性が微妙なのは何故？C++とかJavaとか

363 ：デフォルトの名無しさん：2009/06/09(火) 09:37:06

STL便利じゃん javaいらね

364 ：デフォルトの名無しさん：2009/06/09(火) 09:38:59

親睦性の高い言語って何かある？
Excelの裏で動くVBAとか？

365 ：デフォルトの名無しさん：2009/06/09(火) 09:52:13

つ　【emacsの裏で動くelisp】

366 ：デフォルトの名無しさん：2009/06/09(火) 11:53:43

>>342
少なくとも強く型付けされたHaskellなどの言語では実行時の型エラーはありえなくね？

367 ：デフォルトの名無しさん：2009/06/09(火) 11:58:06

unsafeCoerceを使ってですね…

368 ：デフォルトの名無しさん：2009/06/09(火) 12:00:22

>>367
そんなやばい関数があるのか。
FFI用だろ　女子高生

369 ：デフォルトの名無しさん：2009/06/09(火) 12:08:07

でもunsafeって名前を付けたのは偉いと思う。
危険なところと安全なところを切り分けて考える事は重要だしね。

370 ：デフォルトの名無しさん：2009/06/09(火) 13:07:10

>>362
>>オブジェクト指向との親和性が微妙なのは何故？C++とかJavaとか
オブジェクト指向との親和性って何？
C++とJavaの何処が微妙なんだ？

371 ：デフォルトの名無しさん：2009/06/09(火) 13:53:49

>>370
30越えてるなら今のうちにコボラにごめんなさいしとけ
多分お仲間になる

372 ：デフォルトの名無しさん：2009/06/09(火) 14:22:37

>>371
そういうこと言ってる人って、大学に行かずにプログラマになった人で、40歳ぐらいの人に多いんだけど。。
3人ぐらい同じような事を言ってる奴がいたけど、全員大学は出ていなかった。
一方で関数型言語やオブジェクト指向をバリバリやってる人は会社の社長さんに多かった気がする。
てか俺の周り社長大杉ｗ

373 ：デフォルトの名無しさん：2009/06/09(火) 15:20:28

>>372
つまり、オブジェクト指向やってる奴は協調性が無くて長く会社にいられないから、
起業する奴が多いということか。

374 ：デフォルトの名無しさん：2009/06/09(火) 18:36:02

型エラーはコンパイル時のも含むだろ
往生際わるすぎ

375 ：デフォルトの名無しさん：2009/06/09(火) 18:42:37

>>374
お前、ム板で暴れてる奴だろ？

376 ：デフォルトの名無しさん：2009/06/09(火) 19:08:44

>>375
ここはどこ？ >>374 ってよそでもやってるの？？？

377 ：デフォルトの名無しさん：2009/06/09(火) 20:11:17

ほどほどにオブジェクト指向しようや

378 ：デフォルトの名無しさん：2009/06/09(火) 21:09:32

> ほどほどにオブジェクト指向
の定義が山ほどあるから、みんな、困ってるんじゃないか？

とくに OOA とか OOD とか言ってる連中と、その他の設計理念の立ち位置とか
C++/Java で言ってるカプセル化の位置付けとか

よそから見たら単なるオナヌーだろ？

379 ：デフォルトの名無しさん：2009/06/09(火) 23:25:01

なぁ………
ハード屋とか組み込み屋連中はシステムの安定度とかを計算するための
数式的手法を山ほど持ってて, 有効に使ってシステム組んでるわけだが

実は, そのたぐいってOOにも応用可能なことが分かってるのに, OO屋が
そうゆうの使わないのは, なんか理由があるのか?

380 ：デフォルトの名無しさん：2009/06/09(火) 23:27:50

>>379
昔からあるだろ形式言語使って
調べるとかそんなのは日の目みないだけで
腐るほど研究されてるぞ

OO使い特にJAVAスクール（笑）に通ってるような
奴らには数式なんて理解できないでしょう

381 ：デフォルトの名無しさん：2009/06/09(火) 23:39:54

>>380
> 数式なんて理解できないでしょう
要はOO屋ってのはアホの集団ってことか?

382 ：デフォルトの名無しさん：2009/06/09(火) 23:47:16

オブジェクト指向＝文系（再掲）

383 ：デフォルトの名無しさん：2009/06/09(火) 23:50:08

>>378
＞よそから見たら単なるオナヌーだろ？

オナニーして悦に入ってる奴に限って
他人にも押し付けて来るんだよなぁ
ああいうのは本当に邪魔だ

384 ：デフォルトの名無しさん：2009/06/09(火) 23:55:58

>>379
そんなツール山ほどあるんじゃないの
メトリクスで検索したら山ほど引っかかるぞ

ウチの職場でも富士通の使ってるし

385 ：デフォルトの名無しさん：2009/06/09(火) 23:57:26

>>381
そうOO屋はアホの集合体
特に日本は設計もできないし、問題を解決する道具
としてOOをまともに使えないから世界でもカスレベル
のアホ集団といっても問題無い

386 ：デフォルトの名無しさん：2009/06/10(水) 00:01:48

>>384
あの設計段階ではほとんど全く役に立たない奴ね
その手のツールとは違うだろ, ハード屋とか組み込み屋が使ってる設計手法は?

387 ：デフォルトの名無しさん：2009/06/10(水) 00:16:11

ソフトウェアを開発する作業はハードウェアとかでの設計にあたる、みたいなことを誰かがいってたのを思い出した

388 ：デフォルトの名無しさん：2009/06/10(水) 00:21:52

>>387
> ハードウェアとかでの設計
って言ってるのは、図面を引くところで
それ以前の工程のでやるべきことはほとんど同じなんだけどな
使ってる手法は大きく異なる

389 ：デフォルトの名無しさん：2009/06/10(水) 01:37:38

>>379
ソフトウェア開発では、その手のものはまず役に立たないから。

390 ：デフォルトの名無しさん：2009/06/10(水) 01:46:12

> ソフトウェア開発では、その手のものはまず役に立たないから。
「ソフトウェア開発では、その手のものを役立たせる能力をもった人材が
ほとんどいないから」
の、間違いだろ

391 ：デフォルトの名無しさん：2009/06/10(水) 07:01:51

>>390
君、ソフトウェア工学についてちゃんと系統立った教育を受けてないでしょ？
学んでいれば、ハードウェアにはないソフトウェア固有の問題を知っているはずだ。

392 ：デフォルトの名無しさん：2009/06/10(水) 07:12:04

>>391
>>196 >>199

393 ：デフォルトの名無しさん：2009/06/10(水) 09:44:44

構造化プログラミングの時代には、
仕様から数式的に記述して、できたプログラムを検証するとか、
理論的研究としてはいいところまで行ったが、
オブジェクト指向が出てきて振り出しに戻ったｗ

394 ：デフォルトの名無しさん：2009/06/10(水) 09:49:30

オブジェクト指向っていうのはアルゴリズムを実装する手段だから
アルゴリズムを考える手段としてはあまり役に立たないように俺は思うよ。

395 ：デフォルトの名無しさん：2009/06/10(水) 10:04:43

>>372
悔しいのか？

396 ：デフォルトの名無しさん：2009/06/10(水) 10:14:43

>>392は何の反論にもなっていないアンカーを落として何がしたいの？
頭おかしいの？死んじゃうの？

397 ：デフォルトの名無しさん：2009/06/10(水) 10:17:18

ビジネス分野なんて、仕様そのものが不安定なのに、
仕様を形式化できるような分野の話をしても意味が無いと思うが。

それこそ、なんでもOO厨と変わらないだろ。

398 ：デフォルトの名無しさん：2009/06/10(水) 10:22:28

>>396
必死だな

Software engineering will never be a rigorous discipline with proven
results, because it involves human activity.

399 ：デフォルトの名無しさん：2009/06/10(水) 10:22:44

将来的に、仕様は形式化できないといけないと思うけどね。
で、仕様を変更したら、プログラムの中で修正すべき部分が色つきで表示されるとか。

400 ：デフォルトの名無しさん：2009/06/10(水) 10:26:27

形式化された仕様を書く際にバグが生じるわけですね。

401 ：デフォルトの名無しさん：2009/06/10(水) 10:39:13

>>398
その英文を読んで、理由がそこに直接挙げられているものだけだという主張だと解釈するのなら、
おまえは二度と英文を読まないほうがいい。おまえ本人にとってもおまえの周囲にも不利益にしかならない。

402 ：デフォルトの名無しさん：2009/06/10(水) 10:44:25

テスト駆動は数学あんまり関係ないからなぁ
オーバースペックな学問やってると応用を考えるのが大変だな

403 ：デフォルトの名無しさん：2009/06/10(水) 10:51:10

仕様形式化廚からiPhoneみたいなものが生み出されることはないだろうな

404 ：デフォルトの名無しさん：2009/06/10(水) 10:51:48

>>401
読まずに反論してるのが丸分かりだな。まあ全部読んでから反論しろよ。
それともこの程度の量も楽に読めない程英語に不自由しているのか？

405 ：デフォルトの名無しさん：2009/06/10(水) 10:59:51

>>404
すごい妄想だな。
やはりお前は>>391が言うようにSoftware Engineeringの基本中の基本がわかっていない。
VBScriptを自習したクチか？

406 ：デフォルトの名無しさん：2009/06/10(水) 11:09:14

どんな分野でも、過去の考え方にとらわれない設計・開発から、
革新的なヒット商品が生まれる。

だけど、それと、オブジェクト指向には、
なんかすっきりした設計・開発の法則がないんじゃないか？
という話も、また別の問題だろう。
過去の定跡を破る前に、その定跡がどうもはっきりしない。

407 ：デフォルトの名無しさん：2009/06/10(水) 11:34:41

>>405
余計なことはいいから、読んだのなら内容について反論しろよ。
それが出来ないなら英語に不自由していると思われて当然だ。

408 ：デフォルトの名無しさん：2009/06/10(水) 11:36:56

>>405
人を妄想だと言っておきながら自分も妄想を並べ立てるとか
自己矛盾も甚だしいぞw

409 ：デフォルトの名無しさん：2009/06/10(水) 11:48:24

過去の考え方にとらわれない設計・開発をするためには、過去を知らなきゃ駄目じゃん

基礎を知らないので、応用が出来ないのと同じ理屈だよ

410 ：デフォルトの名無しさん：2009/06/10(水) 16:55:45

>>407-408
ミエミエの自演とはいえ、もうちょっと時間をおくとかしたほうがいいぞ。
あとな、おまえちゃんと全文読んでないだろ。読んでたら>>392のようなマヌケなことはしない。

411 ：デフォルトの名無しさん：2009/06/10(水) 17:06:39

>>410
第三者から見てもお前の方が１００倍ぐらい痛いぞ

412 ：デフォルトの名無しさん：2009/06/10(水) 17:08:00

オブジェクト指向について語れ。

413 ：デフォルトの名無しさん：2009/06/10(水) 17:32:00

>>411 「第三者」プ

414 ：デフォルトの名無しさん：2009/06/10(水) 19:59:10

なんだ、まっとうな議論してんのかと思ったら
オブジェクト指向が理解できない可哀想な人たちの巣でしたか

415 ：デフォルトの名無しさん：2009/06/10(水) 20:39:31

ループ入りました

416 ：デフォルトの名無しさん：2009/06/10(水) 20:43:55

最善の「オブジェクト指向開発」の方法論って何よ？
それがまっとうな技術者なら、誰でもある程度身に付くなら、そこから議論しないと。

417 ：デフォルトの名無しさん：2009/06/10(水) 21:11:32

VBScriptは、土方用に特化されたC++ライクなオブジェクト指向言語だな

418 ：デフォルトの名無しさん：2009/06/10(水) 21:44:17

VBScriptは他に無い独自のオブジェクト指向だろ
なんせ継承が無い

419 ：デフォルトの名無しさん：2009/06/10(水) 21:50:52

継承がないから、土方用なんだろ?

420 ：デフォルトの名無しさん：2009/06/10(水) 22:16:36

「関数から値が返ってくる」というのより、
「オブジェクトの状態を調べる」というほうが、素人に分かりやすい。
関数って、実体が感じられないんだよね。

421 ：デフォルトの名無しさん：2009/06/10(水) 22:27:58

関数が汗水たらして働いてるドカタなんだよ

422 ：デフォルトの名無しさん：2009/06/10(水) 22:29:52

>>416
銀の弾丸はありません。

423 ：デフォルトの名無しさん：2009/06/10(水) 22:34:06

>>420
どっちもいっしょだろ。
c じゃ返ってくる値じゃ使い物にならんから
しゃーないってのはあるが。

424 ：デフォルトの名無しさん：2009/06/10(水) 22:36:11

> 「オブジェクトの状態を調べる」
って言うと、インスタンス変数なりクラス変数なりの参照をイメージするが…

425 ：デフォルトの名無しさん：2009/06/10(水) 22:37:14

>>420
素人の意見で決めるのかｗ

426 ：デフォルトの名無しさん：2009/06/10(水) 22:42:26

マスコミがよく使う手だな

427 ：デフォルトの名無しさん：2009/06/10(水) 22:46:45

仕様決めるのに素人意見の大きさは無視できんからな。
その辺がハード屋とは大きく違う。

428 ：デフォルトの名無しさん：2009/06/10(水) 22:55:36

>>424
教育の話だけど、すごく単純なプログラムで、
関数とオブジェクトのメソッドを教えようとしたら、
メソッドのほうが教えやすいということに気づいた。
文系脳でも大丈夫。

429 ：デフォルトの名無しさん：2009/06/10(水) 23:02:52

>>410
自演？なにそれ？
妄想や抽象論はいいからさっさと内容について具体的に反論しろよ。
お前本当に英語読めないんだな。

430 ：デフォルトの名無しさん：2009/06/10(水) 23:16:55

教えやすさは大切だよね。
手続き型は何だかんだ言いつつも変数を箱として視覚的に表現
したりと工夫する事で初心者にも処理の流れを理解させやすい。
OOPは犬や猫をなかせたりとやや迷走気味だけど、まだ努力
は見せている。

前にここで関数型言語における初心者向けの良い例え話を
尋ねたらラムダ演算が答えとしてかえってきた。
説明下手なうちは普及も難しいだろうなと正直思った。

431 ：デフォルトの名無しさん：2009/06/10(水) 23:19:43

バカ野郎、関数型言語は選ばれた人材だけの占有物なんだから初心者向けとか普及とかいう泥臭いことは考えなくていいんだよ

432 ：デフォルトの名無しさん：2009/06/10(水) 23:57:06

例え話なんて必要か？
普通に中学・高校で習う関数と一緒だと思うが。

高階関数のこと？

433 ：デフォルトの名無しさん：2009/06/11(木) 00:00:38

圏論程度でもたとえ話なんて不要なのに
それ未満の内容でたとえ話っているのか？

434 ：デフォルトの名無しさん：2009/06/11(木) 00:15:24

>>433
じゃぁ例え話なしで
君のまわりの鼻たれ小僧に関数型言語について教えてみて
例え話を使った所で"理解"にそのまま至ることは無いが
"どの程度話が通じるか"に差が出る

435 ：デフォルトの名無しさん：2009/06/11(木) 00:16:37

>>434
まずは、日本語を正しく書けるようになれ

436 ：デフォルトの名無しさん：2009/06/11(木) 00:34:04

「初めてプログラムします」っていうような人が対象の教育について
OOと関数型とを比べてもつまならい。どっちもまぁ頑張れとしか言いようがない。
それよりも、一定以上の規模かつ一定以上の品質という条件を両立したプログラムを書ける
レベルまでにどれだけスムーズに到達できるようになるかを比べたい。

437 ：デフォルトの名無しさん：2009/06/11(木) 00:44:28

アルゴリズムの勉強するなら関数型の方が楽

438 ：デフォルトの名無しさん：2009/06/11(木) 00:47:28

そういう比べ方をした場合、JavaやC++のような言語では、クラスやオブジェクトの
基本的な機能まではすぐに分かるのだけれど、クラス設計をしようとした途端難しくなる。
これがネック。
そして少し分かりかけてきたかなと思っても、規模についていけずに破綻する。
一方でHaskellやOCamlのような関数型言語では、型や関数やモジュールの基礎は難しくなく、
そこまで分かれば一定以上の規模に耐えられる。
それ以上難しい型の応用やファンクターの活用などになると壁があるけど、
そこはもうプラスαの世界。

439 ：デフォルトの名無しさん：2009/06/11(木) 00:54:18

Haskellはあの空白でエラーでるとか
旧世代言語みたいなキモイ文法が無ければ流行る

OCaml最高～

Java（笑）市ねｗ

440 ：デフォルトの名無しさん：2009/06/11(木) 00:56:07

大抵の事は、VBScriptで十分
自分でオブジェクトを作ろうとするからややこしいんであって、利用するだけなら馬鹿でも出来るし

VBScriptを使いこなせるようになってからC++なりJAVAなりC#なり好きな言語を使えばいいんでないの?
まあ、VBScriptを使いこなせるようになったら、わざわざ他の言語に移る必要性を感じるかどうか...

馬鹿避けには良い言語だよマジで

441 ：デフォルトの名無しさん：2009/06/11(木) 00:56:58

業務アプリの8割5分がVBScriptだしなぁ

442 ：デフォルトの名無しさん：2009/06/11(木) 00:59:30

8割5分とか、統計細かすぎwワロタw

443 ：デフォルトの名無しさん：2009/06/11(木) 01:02:22

俺の職場はJavaとC#だから、たぶん残りの1割5分。意外とマイナー。

444 ：デフォルトの名無しさん：2009/06/11(木) 01:30:55

これからはマルチパラダイム言語だな。

って事で、Scala最高。

445 ：デフォルトの名無しさん：2009/06/11(木) 02:18:15

ネットの盛り上がり方みてるとやっぱScalaなんだろうな
と思いつつもclojureに心惹かれてる俺

446 ：デフォルトの名無しさん：2009/06/11(木) 05:36:35

Scalaってそんなに流行ってるのか？
俺はOCamlでいいや

447 ：デフォルトの名無しさん：2009/06/11(木) 07:28:13

>>432
その高校で習う関数が分からないんだよ。
文系脳では、1行で書けない関数は理解不能。
Fortranの文関数が限界。

448 ：デフォルトの名無しさん：2009/06/11(木) 08:27:18

>>435
プ

449 ：デフォルトの名無しさん：2009/06/11(木) 13:48:24

>>447
大丈夫。そいつ等は日本語も読めない連中だから切って捨てても無問題

450 ：デフォルトの名無しさん：2009/06/11(木) 18:10:11

>>449
抽象概念としては中学で習う関数と同じでも、
扱う対象が数だけではないところが関数プログラミングの難しさだとおもうが。
リストや文字列という概念を理解した上で、関数という概念と結びつけるのが
一番の難関だと思う。

たとえば、関数は関数でも、
f(x) = a * x + b
と
f x (y:ys) = (str (x y)):(f x ys)
では理解するために必要な抽象力がまるで違うだろ？

451 ：デフォルトの名無しさん：2009/06/11(木) 18:46:15

そこで素朴集合論ですよ
関係のグラフ、値の対応付け等の概念を知れば
どんな○○でも簡単に理解できるようになるでしょう

452 ：デフォルトの名無しさん：2009/06/11(木) 18:55:04

関数が必要だと思える具体的な場面を想像できないんだろ
抽象力（笑）なんて言われたら、ますます想像力が低下するんだろうなぁ

453 ：デフォルトの名無しさん：2009/06/11(木) 20:42:12

中学校レベルで f(x) = 2x + 1 をどう理解しているかというと、
関数と言うよりテンプレートという感じだろう。
xの場所を数字に置き換えて計算するという感じ。
何か関数という実体があるというイメージはない。
大学で理系の学部に進学する人間以外は、この程度の理解。

454 ：デフォルトの名無しさん：2009/06/11(木) 20:46:29

抽象化して、劇的に生産効率が上がるならいいんだけどね。
高度な抽象化のわりには、それほど生産性上がるのかどうか微妙な感じ。
オブジェクト指向の仮想関数にも同じようなところがあるんだけど。

455 ：デフォルトの名無しさん：2009/06/11(木) 22:15:56

しかも、覚えたからって工数減るわけじゃないしねぇ
「あの人はオブジェクト指向を知ってるから工数は普通の人の２分の１でいいよ」
なんて死亡フラグ以外なんでもないなｗ

456 ：デフォルトの名無しさん：2009/06/11(木) 23:06:51

むしろきれいな構造作ろうとして無駄に時間費やしてる事の方が多いｗｗｗ

457 ：デフォルトの名無しさん：2009/06/12(金) 00:38:14

綺麗な構造作るのは未来のためだから、しょうがないんじゃね？
使い捨てのプチツールなんか、アホらしくて綺麗な構造なんて考えないけどね

458 ：デフォルトの名無しさん：2009/06/12(金) 00:40:50

未来が来てから綺麗にすりゃいいじゃんか。未来の保障も無いのに綺麗にしてもな。

459 ：デフォルトの名無しさん：2009/06/12(金) 00:43:51

このままじゃさすがにヤバいなという臭いを感じたら全力を出せ
とリファクタリングの本にも買いとった

460 ：デフォルトの名無しさん：2009/06/12(金) 00:46:10

綺麗にするって言っても、何度もやってればだいたい使うパターンは
決まってくるんで、そんなに苦痛でもないけどな。

461 ：デフォルトの名無しさん：2009/06/12(金) 01:36:50

OOPの教え方。

赤いまん丸の風船があったとして、
これに「ポンジュース」って書かれた
蛇口をつっこむと、ポンジュースが出てくる。

これがメソッドです。風船はオブジェクト。

462 ：デフォルトの名無しさん：2009/06/12(金) 01:41:34

ｗ

463 ：デフォルトの名無しさん：2009/06/12(金) 03:26:32

俺は手続き型を何年かやった後、OOPについて
犬やら猫やらその親クラスの動物やらで説明されてた時はよく意味が解らんかったが
文字列や配列がクラスってのを学んだらピコーンと来た
でもまだその時点じゃレベル1だった
「文字列化」するメソッドを学んだ時にレベル2になったかな

464 ：デフォルトの名無しさん：2009/06/12(金) 05:25:43

OOPもFPも土方には不要というのがこのスレの結論ですね。

465 ：デフォルトの名無しさん：2009/06/12(金) 06:12:58

土方がいなくなったあとの荒野をOOPマンやFPボーイが代わって
少数精鋭で耕して豊かな土地にしてくれるのならそれでも良いけど、
そこまでの頭数も一人あたりの根性もあるとは思えない。

良い技術であっても広まらないと社会にはクソほどの役にも立た
ないんだけどね。ここでFP持ち出してOOP叩く面々にはFPを振り
かざしはしても普及させようとかそういう気は全然無いみたい。

466 ：デフォルトの名無しさん：2009/06/12(金) 07:48:19

良いかどうかを証明できない上に
これっぽっちも工数を削れない
数字に出せないってことは駄目なんだよ
数字をみないとなにやっても駄目
いつまでも無駄なことを延々とやり続ける

467 ：デフォルトの名無しさん：2009/06/12(金) 08:47:00

いわゆるプログラミングもやるコンサル、とか
全世界市場に向けてリリースするパッケージの開発者、とか
そういう連中の言うことに自己同一化して
単なる下請けコーダーがたけえ本買ってんのは滑稽といえば滑稽だな
辞めちゃえばいいんだよ
業界が腐ってんのはホントのことなんだから
辞めて自分のシステム作ってそれ運用して食っていけばいい
WEBサービスとかシェアウェアとかのこと言ってんじゃないよ

468 ：デフォルトの名無しさん：2009/06/12(金) 09:44:35

とりあえず、プログラム作成しかしてないのに、プログラム開発をしてるつもりの奴が多すぎるのは確かさ

顧客専用のシステムを作成するのに、OOなんてこれっぽっちも役に立つわけがないだろうが
将来的に使うかも?
そんなもん使えるかよ!!!
同じことをするのでも、未来の自分の方が上手いコードを書けるだろうよ!!!

OOが役立つのは、プログラム開発をしている奴だけだよ
プログラム作成している奴には、何の役にも立たないよ

469 ：デフォルトの名無しさん：2009/06/12(金) 09:52:22

まだ再利用とかいってる馬鹿がいるのか。

470 ：デフォルトの名無しさん：2009/06/12(金) 09:57:33

フツーに再利用してるが

471 ：デフォルトの名無しさん：2009/06/12(金) 10:21:44

> まだ再利用とかいってる馬鹿がいるのか。
という馬鹿がいるのが驚きだ
VBScript程度でも使えば再利用の重要性が分かると思うんだが
まあ、VBScriptを使ってても、再利用しているとは思ってない可能性があるけどなwwww

472 ：デフォルトの名無しさん：2009/06/12(金) 10:26:12

互換性を大切にしない言語は再利用しにくい
なので、いまだにCで書く奴が多すぎるわけですよ

473 ：デフォルトの名無しさん：2009/06/12(金) 10:37:00

それだ。
再利用再利用と言ってる言語が、再利用しにくいように言語仕様を変える。

474 ：デフォルトの名無しさん：2009/06/12(金) 11:05:14

再利用しやすいように仕様変更されているが、馬鹿には理解できない仕様になっていってるだけでしょ

475 ：デフォルトの名無しさん：2009/06/12(金) 11:23:38

再利用しやすいように仕様変更？
馬鹿だからか理解できん

476 ：デフォルトの名無しさん：2009/06/12(金) 12:53:15

ドカタにオブジェクト指向はいらないって言ってるやつ、オブジェクト指向なんて使ってないだろ。
オブジェクト指向がまともに使われてるのってコーディングレベルくらいじゃん。
コーディングレベル以上のオブジェクト指向なんとかって、オカルトとかいんちきばっかり。

477 ：デフォルトの名無しさん：2009/06/12(金) 13:32:20

ドカタは黙っとれｗ

478 ：デフォルトの名無しさん：2009/06/12(金) 13:38:37

土方の何倍もの金で雇われると、ローリスクローリターンの仕事はさせてもらえない。
投機的な仕事しかできない仕組みになってる。

479 ：デフォルトの名無しさん：2009/06/12(金) 16:52:43

土方脳では高度＝投機的

480 ：デフォルトの名無しさん：2009/06/12(金) 18:27:33

末端ほど仕様の再利用は役に立つけどコードの再利用は役に立たない
まず、これを脳みそに擦り込むべき

481 ：デフォルトの名無しさん：2009/06/12(金) 18:32:53

脳リスク脳タリーンには過ぎたオモチャだよｗｗｗ

482 ：デフォルトの名無しさん：2009/06/12(金) 20:29:39

不快なのはOOじゃなくて
オーバーエンジニアリング（の強要・またはそれをどこまでも進める馬鹿）なのかもしれない

483 ：デフォルトの名無しさん：2009/06/12(金) 20:40:56

>>474
再利用をしやすいように機能が追加されているのだが、
仕様が変わるということ自体が、再利用の妨げになっている。

もちろん、機能は過去との互換性を考えて追加されてるのだが、
プログラミングスタイルが変わるし、心理的にも抵抗が生まれる。

C++0xなんて、お化けだよ。
もう別の言語作って、C++の機能を使えるようにすればいいのに。
Javaも仕様追加してぐだぐだな感じになってきた。

484 ：デフォルトの名無しさん：2009/06/12(金) 20:44:53

別に心理的な抵抗なんて無いけどな。
必死になって覚えたっていうものでもないし。

485 ：デフォルトの名無しさん：2009/06/12(金) 21:11:14

昔の「旧式」の機能で作ったコードを引っ張り出してきたら、
再利用するのに、ちょっと気が進まなくなったりしないか？
そこでちょっと手直ししようかな、なんて思ったりするとドツボ。

486 ：デフォルトの名無しさん：2009/06/12(金) 21:46:50

テンプレートバリバリで作ったソースってそもそもテンプレートに手を入れにくい
オブジェクト指向とまるで関係とは思うけどテンプレートを乱用することが
オブジェクト指向だと思ってる馬鹿はほんとぶんなぐってやりたい

487 ：デフォルトの名無しさん：2009/06/12(金) 21:52:06

過度に技巧に走ってるって文句言ってるのは、
本当にそうかもしれないし、本人がレベル低いだけかもしれないし、
具体的な話じゃないと同意しづらいよな。

488 ：デフォルトの名無しさん：2009/06/12(金) 22:14:15

とりあえずココではオブジェクト指向についての話題に限定したほうが…
C++は色んな方向に進化(?)しすぎてるから全部に文句言ってたら切りがないかと

489 ：デフォルトの名無しさん：2009/06/12(金) 23:18:41

テクノロジックアートレベルに
到達しないとOOなんてつかえねーしな

490 ：デフォルトの名無しさん：2009/06/12(金) 23:21:12

>>489
それでも工数は減らないけどなｗ

491 ：デフォルトの名無しさん：2009/06/12(金) 23:26:43

少なくともスパゲッティよりもおいしいわけで。
こんがらがったスパゲッティなんて食えたもんじゃないよ。

492 ：デフォルトの名無しさん：2009/06/12(金) 23:35:00

>>491
スパゲッティのがましだよ
だってスパゲッティは大抵長いだけだし
テンプレート地獄は構造がすでに死んでる
誰も触れないし触りたくない

そもそもvector string list以外で必要なもんなんてねぇよマジで
なんで自分で作ったんだこんなチンケな機能ってのが多いな
恥ずかしくねぇのかってぐらい無意味なところで使ってるのが多い

493 ：デフォルトの名無しさん：2009/06/12(金) 23:37:37

C++への愚痴はC++スレでよろ

494 ：デフォルトの名無しさん：2009/06/12(金) 23:48:29

C++ template地獄
http://d.hatena.ne.jp/yaneurao/20090104

495 ：デフォルトの名無しさん：2009/06/12(金) 23:57:10

>>494
>私はそのプログラムのごく一部のclassを流用したかっただけなのだけど、芋づるがひどすぎて切り離せない。
設計腐ってんだよ＞やね

496 ：デフォルトの名無しさん：2009/06/13(土) 00:17:30

元請の作った複雑怪奇なフレームワークに悩まされて愚痴ってるってとこか。
やつら、机上の空論で標準化とか言い出すからな。

497 ：デフォルトの名無しさん：2009/06/13(土) 00:23:51

巨大クラスは問題。
バイナリサイズも巨大になるし。

498 ：デフォルトの名無しさん：2009/06/13(土) 01:47:17

>492
スパゲッティってのは長いコードじゃなくて構造化されてないコードのことだと思うのだが。

499 ：デフォルトの名無しさん：2009/06/13(土) 02:09:04

何百行もだらだらと処理が書いてあって、まったく構造化されてないコードは
たしかに長いだけだが、読みたくない。

500 ：デフォルトの名無しさん：2009/06/13(土) 04:58:18

>>496
しかもフレームワークのバージョンごとに標準が違うwww

501 ：デフォルトの名無しさん：2009/06/13(土) 15:39:29

まとめ

・ OOPLは土方やゼネコンには不要
　　- 逆に生産性が低下するとの事例あり

・ OOPLは能力が高いプログラマ向け
　　- 実験的プロジェクトで高い生産性と品質に有用
　　- 能力が高いプログラマのコードをコンポーネント化

502 ：デフォルトの名無しさん：2009/06/13(土) 15:43:04

能力高い奴がライブラリを作成して
低い奴はそれを使うのが、オブジェクト指向

503 ：デフォルトの名無しさん：2009/06/13(土) 15:51:13

>>502
そう分離できたら
かなりすっきりするのだが
仕事では無理だろ

同人ゲームで自分が仕切ってたなら
くらいの状況でもなきゃ実現できん

504 ：デフォルトの名無しさん：2009/06/13(土) 15:58:27

>>502
OOPに限った話じゃないな

505 ：デフォルトの名無しさん：2009/06/13(土) 16:11:16

>>503
仕事だったら、ぐちゃぐちゃにされるのは覚悟の上で指導するしかないわな。
そうでもしなければ、いつまでたってもそいつは土方コーダーから抜け出せないからな。

506 ：デフォルトの名無しさん：2009/06/13(土) 16:35:57

>>486
殴るだけでいいのか？
俺なら殴った後、蹴りを入れてやる。

507 ：デフォルトの名無しさん：2009/06/13(土) 17:13:01

できる奴ってのは入社前から色々とプログラムを作った経験があった奴等。
学生時代からプログラミングで生活費を稼いでいたりする連中だ。
中には例外もいるかもしれないが、ここ10年ぐらいの傾向では、
大学受験よりも先にプログラミングをはじめた奴は当たりが多いね。

そういう連中は手続型でも仕事できるが、OOPLならもっと良い仕事をする。
1の仕事をさせれば、そこから10の仕事に使えるコードを残してくれる。

入社してからプログラミングを教わった連中だと、せいぜいが土方のカシラがいいとこだ。
OOPL使わせても他人のコードに文句つけるばかりで、ゴミしか残さない。

508 ：デフォルトの名無しさん：2009/06/13(土) 17:22:53

オブジェクト指向で生産性はあがらないよ

509 ：デフォルトの名無しさん：2009/06/13(土) 17:27:39

>>508 ゴミは家に持ち帰りましょう。

510 ：デフォルトの名無しさん：2009/06/13(土) 17:46:39

>>508
どういう物をプログラムしたんだよ。
RDB引いてウンタラするだけの中間とか？

511 ：デフォルトの名無しさん：2009/06/13(土) 18:09:12

土方がOOなんて意識しなくて済むように、OO使ってフレームワーク作る。

今までそう思っていたが、土方のレベルは想像以上に低いことに気が付いた。
DSLでも作って、そこだけ書かせたほうが良いんじゃないかと思い始めている。

土方使わないのが、ベストだけどね。

512 ：デフォルトの名無しさん：2009/06/13(土) 18:12:46

土方OO

513 ：デフォルトの名無しさん：2009/06/13(土) 18:27:13

おれがMayerだ

514 ：デフォルトの名無しさん：2009/06/13(土) 18:58:57

>>511
土方にDSL使わせる?
DSLを理解するのに時間かかる上に、
自分の無能力をDSLのせいにするだけ。

515 ：デフォルトの名無しさん：2009/06/13(土) 19:05:59

土方に特化したのがVBScript

やっぱ考えなくていいのは楽でいいなぁ

516 ：デフォルトの名無しさん：2009/06/13(土) 19:07:38

>>511
これだからプログラミング脳は困る。実装する事しか頭に無いとはね。
土方を教育するフレームワークを作れば済むこと。

517 ：デフォルトの名無しさん：2009/06/13(土) 19:12:00

>>516
今まで社内教育フレームワークで土方を量産してきただろ。
そしてその品質の低さに>>507がダメ出ししてるわけだが？

518 ：デフォルトの名無しさん：2009/06/13(土) 19:13:20

そんなに言うなら>>517がもっとまともな教育フレームワークとやらを作ればいいよ

519 ：デフォルトの名無しさん：2009/06/13(土) 19:14:32

だから教育フレームワークという考え方そのものがダメだということに
なぜ気付かないのだろうか・・・

520 ：デフォルトの名無しさん：2009/06/13(土) 19:18:46

馬鹿は馬鹿として放って置くのが一番
馬鹿が張り切って仕事しても碌なことにならに無い

昔から言うだろ、触らぬ神に祟りなしって

521 ：デフォルトの名無しさん：2009/06/13(土) 19:20:21

>>515
それはお前がVBScriptであれば考えなくていいレベルだから。
土方にどんな言語をあてがっても上手く行くはずがない。

522 ：デフォルトの名無しさん：2009/06/13(土) 19:31:39

VBScriptで頭を使わなければならない場面が想像出来ないのですが...

クラスは有っても、クラスを使う場面が無いのがVBScript
オブジェクトの利用は出来ても、オブジェクトの定義が出来ないのがVBScript
それで一体何処で頭を使えと...

523 ：デフォルトの名無しさん：2009/06/13(土) 19:46:36

これVBScriptでできるの？っていう仕様変更が来たとき。

524 ：デフォルトの名無しさん：2009/06/13(土) 20:07:01

>>523
VBScriptで出来ないことを上げるほうが難しくね?

525 ：デフォルトの名無しさん：2009/06/13(土) 20:19:40

VBscriptってVB6のサブセットじゃねえの

526 ：デフォルトの名無しさん：2009/06/13(土) 21:36:49

いまいちつまらない話が続いてるな。
スレタイから言うと、どうすれば現場からOOを消せるかという問題を話し合いたい。
「消せるか」という問題なので、始めからCOBOLやFORTRANしか使ってないような
現場は無視します。OOしない事を端的にどの言語を使うかという面から見ると、
1. C言語メインで。
2. HaskellもしくはOCaml(without object)メインで。
3. Lisp, Schemeメインで。
という選択肢が考えられる。perlは最近はOO言語になり下がっているので候補外。他には？

527 ：デフォルトの名無しさん：2009/06/13(土) 21:52:47

4.bashscript メインで

528 ：デフォルトの名無しさん：2009/06/13(土) 22:01:02

自作のクラス作らないで、継承もしないなら、
オブジェクト指向開発じゃないってことでいいんじゃないの？
それなら、CのFILE*みたいなもので、
便利なモジュール（ライブラリ）というだけだ。

だから、そういう意味ではPerlもあり。
C++でも、メンバ関数作らないで、継承もしないならありだ。
逆に、GNOMEのGObjectとかはダメ。

529 ：デフォルトの名無しさん：2009/06/13(土) 22:04:21

OCamlがOKで、perlがだめだという理由が分からない。
オブジェクト指向を使わずに組めるんだから。

530 ：デフォルトの名無しさん：2009/06/13(土) 22:14:06

>>529
イケメンとブサメンの理論で考えれば自明

531 ：デフォルトの名無しさん：2009/06/13(土) 22:25:28

クラスを作る必要がなく、クラスを作っても継承できないのにオブジェクト指向なVBScript!
OOP!OOP!

532 ：デフォルトの名無しさん：2009/06/13(土) 22:28:34

Prolog

533 ：デフォルトの名無しさん：2009/06/13(土) 22:34:25

文字列とかウィンドウとか、具体的なものを
オブジェクトにしている分にはいいんだよ。
つまり、誰にも明らかなモデル化ならいい。

ところが、何から何までオブジェクトにして設計しようとすると、
どこかに変なところが出てくる。
そういう一部分から、全体に混乱が広がっていく。

534 ：デフォルトの名無しさん：2009/06/13(土) 22:34:49

2013年だかに国が策定する
調達規約だとOOあるものは
製品として採用できないはずだけどな

535 ：デフォルトの名無しさん：2009/06/13(土) 22:37:40

>>534
そんな、OSごと否定する仕組み作る気かよwwww

536 ：デフォルトの名無しさん：2009/06/13(土) 22:37:41

>>533
オブジェクトにするとムリがあるものってたとえばどういうの?

537 ：デフォルトの名無しさん：2009/06/13(土) 22:42:25

もうADTにしようぜ。
http://ja.wikipedia.org/wiki/%E6%8A%BD%E8%B1%A1%E3%83%87%E3%83%BC%E3%82%BF%E5%9E%8B

538 ：デフォルトの名無しさん：2009/06/13(土) 23:07:35

>>536
ソフトウェアの機能をオブジェクトに分解しようとすると、
どこかに入れなきゃいけないけど、どこに入れてもなんかしっくりしない
みたいな機能が出てきたりする。
つまり、その機能を、どのオブジェクトにやらせるのか。

539 ：デフォルトの名無しさん：2009/06/13(土) 23:23:36

なんとかUtilとか、なんとかHelperってクラスが至るところにあったり

540 ：デフォルトの名無しさん：2009/06/13(土) 23:42:22

現場からOOを消したいなら、まずどんな現場を想定しているのか？から提示しないとな。

541 ：デフォルトの名無しさん：2009/06/13(土) 23:45:32

体育会系

542 ：デフォルトの名無しさん：2009/06/13(土) 23:58:05

>>538
何処に入れてもしっくり来ないなら、そのものをオブジェクトにすべきなんじゃない?

543 ：デフォルトの名無しさん：2009/06/14(日) 01:18:31

>>538
足りないのは君の経験。精進しなさい。

544 ：デフォルトの名無しさん：2009/06/14(日) 03:36:51

>541
そういや、どこぞのサイトに「COBOLは体育会系言語」って書かれてたような

545 ：デフォルトの名無しさん：2009/06/14(日) 11:04:43

>>542
んなことするならクラスメソッドじゃなくて普通に関数として
用意した方が直観的だったりする。
java じゃ仕方ないけど。

546 ：デフォルトの名無しさん：2009/06/14(日) 11:39:03

>>545
全てをオブジェクトとして扱うと言うのを
全てをクラスorプロトタイプとして扱うなんて考えたら駄目だろう
変数も、関数も、クラスも、プロトタイプも、定数も、全てをオブジェクトとして捉えろよ

全てをオブジェクトとして捉えることが出来るようになれば、
"定数は名付けろ、マジックナンバーを使うな"
って意味が理解できるようになる

547 ：デフォルトの名無しさん：2009/06/14(日) 12:05:41

オブジェクトとは何ぞや

548 ：デフォルトの名無しさん：2009/06/14(日) 12:16:35

究極的にはプログラミングにおける全ての要素、だろうね。
数値、参照、配列、コード、識別子、関数、クラス…
ただ、どこかで折り合いは付ける必要があるんだが。

549 ：デフォルトの名無しさん：2009/06/14(日) 13:04:03

C#はその辺の妥協の仕方が上手い。

550 ：デフォルトの名無しさん：2009/06/14(日) 13:27:33

オブジェクトって、プログラミングにおける全ての要素じゃなく
プログラムの実行時に影響を与えるもの全てだろ

551 ：デフォルトの名無しさん：2009/06/14(日) 13:40:10

Math.sin(x) とか。Flashも。

552 ：デフォルトの名無しさん：2009/06/14(日) 14:23:05

>550
実行時に影響を与えないものの例って何かある？

553 ：デフォルトの名無しさん：2009/06/14(日) 15:06:03

>>548
その中で「参照」だけはあんまりオブジェクトとして
とらえたくはないな。

554 ：デフォルトの名無しさん：2009/06/14(日) 15:15:59

元はシミュ用だったことを考えるとプログラム内の部品をオブジェクトとかおいちゃうのって
仕様をクラスに落とす便利さをコーダーの勝手な理屈で排除してない？

仕様書から落としてきたクラスと
コードレベルの都合でできちゃったレベルのクラスが
同列の扱いになってしまってるようなソースってのは大抵馬鹿の書いたソース

555 ：デフォルトの名無しさん：2009/06/14(日) 15:24:21

>>554
冗談は染んでから言えよｗ
関数と構造体だけで正しくプログラムは書ける
仕様書も作成可能だ

556 ：デフォルトの名無しさん：2009/06/14(日) 15:31:37

>>552
コメント

557 ：デフォルトの名無しさん：2009/06/14(日) 15:33:14

>>555
俺のレスにその内容のレスって意味わかんない

558 ：デフォルトの名無しさん：2009/06/14(日) 15:34:25

コードレベルの都合でクラスなんか作らないって事だろ

559 ：デフォルトの名無しさん：2009/06/14(日) 15:37:53

Haskell とはクイックソートが1行で書けるくらい(HQ9+のようなズルなしで)軽量な関数型言語です。
Haskell が真の能力を発揮するのは、複雑で巨大なシステムを書くときです。
一般に、プログラムは実現したいシステムが複雑になるにつれて、可読性はどんどん落ちていきます。
しかし、Haskellは違います。記述の簡潔さ、モジュールによって提供される名前のスコープの管理、関数合成による直接な記述など、他の言語に比べて機能は強力です。
何よりも型を自由にかつ厳密に書くことがすばらしい。これにより、コメントはほぼ必要なくなります。
ちろん、プログラムにコメントを付け加えておけば、それは HTML に自動的に翻訳され、そのままドキュメントになります。

560 ：デフォルトの名無しさん：2009/06/14(日) 15:38:55

>>559
haskellとか興味ない
マイナーなの広めようと必死なのわかるけど
やめてくれない？

561 ：デフォルトの名無しさん：2009/06/14(日) 15:44:24

ハスケルは良い言語だとおもいますよ。
でもほとんどのプログラマーはマイクロソフトに影響されて頭がbasic脳なんで
糞言語しか理解できないんです。
だから斬新な言語ほどマイナーになってしまうんでしょうね。

562 ：デフォルトの名無しさん：2009/06/14(日) 15:47:58

>>561
いいかどうかは関係ない
haskellとか興味ないから

563 ：デフォルトの名無しさん：2009/06/14(日) 16:05:54

>>559
簡潔に書くことに労力を取られ、肝心のシステム構築に支障が出る予感wwww

564 ：デフォルトの名無しさん：2009/06/14(日) 16:31:27

Ｈａｓｋｅｌｌはマイナーじゃないだろ……

565 ：デフォルトの名無しさん：2009/06/14(日) 16:50:04

関数型言語って、GUI（非同期的イベント処理）よりも
バッチ処理に向いてそうだけど、どうなんだろう？

566 ：デフォルトの名無しさん：2009/06/14(日) 16:54:53

再帰定義データに対する処理にうまく帰着できれば綺麗に書ける上に並列化とか
色々拡張するのも自由自在だけど、
そういうのができないような構造だと非常に面倒な事になる

567 ：デフォルトの名無しさん：2009/06/14(日) 17:38:27

GUIはイベントハンドラが書きやすい言語なら何でもいいんじゃない？

そういや、以前はオブジェクト指向言語の紹介をするのに、
死ぬほど引数並べてウィンドウを構築するCのコードと、
シンプルなコンストラクタ＋プロパティいじりたいところだけアクセッサ
呼び出しするオブジェクト指向言語を対比してみせるのが流行ってたな。

568 ：デフォルトの名無しさん：2009/06/14(日) 19:14:07

まあだからマルチパラダイムだよなー
関数型のエッセンスを取り入れたマルチパラダイム
pythonかlisp（系）か
でも大規模開発にもっていこうと思えば、
例えばCだと三項演算子は使わないこと（読めない人が居るから）、とか
一関数一ファイル（管理しやすいから）、とか
なんか連番の機能ID(SKJD001020みたいな）だかなんだかをソースファイル名とか関数名とかに使う
なんて規約作っちゃったりしてスポイルされてしまうのは目に見えてるw

569 ：デフォルトの名無しさん：2009/06/14(日) 19:19:48

大規模開発だと1関数5行以内が
国際ルールだろ

570 ：デフォルトの名無しさん：2009/06/14(日) 20:17:15

>>569
1関数5行以内を遵守してる大規模オープンソースプログラムを教えくれよ。
俺が読んだ限りでは、apache httpdもopensslもそんな事にはなってないぞ。
国際ルールなんだろ?

571 ：デフォルトの名無しさん：2009/06/14(日) 20:19:36

>>567
> GUIはイベントハンドラが書きやすい言語なら何でもいいんじゃない？
継続

572 ：デフォルトの名無しさん：2009/06/14(日) 20:28:51

>>569
脳内乙

573 ：デフォルトの名無しさん：2009/06/14(日) 20:31:17

五行以内だとムリヤリすぎて、ぜってー読みにくくなる予感ｗ

574 ：デフォルトの名無しさん：2009/06/14(日) 20:34:02

この後に及んでHaskellやOCamlに興味がないソフトウェア技術者がいるのは残念です。
VisualStudio2010にはOCamlの改造版であるF#が標準搭載されます。
Windowsをメインターゲットに開発している技術者なら、注目に値するはずです。
Software Design 2009年04月号ではHaskellでWebアプリを作る特集がありました。
Haskellの記述力の高さと安全さと並列性は、Webアプリ開発者としての責任を果たすなら
「知らなかった」では済まされません。
そもそも関数型言語の特徴（特にクロージャーやバリアント）などは次々にOOPLに取り込ま
れています。それらがなぜ取り込まれたのか、その元を知っておきたくはありませんか？

575 ：デフォルトの名無しさん：2009/06/14(日) 20:36:57

Hashkellってなんであんなにカッコとかに煩いの？

576 ：デフォルトの名無しさん：2009/06/14(日) 20:49:05

http://fxp.hp.infoseek.co.jp/arti/prag/
HaskellでGUI作ったという話。
この例だと、結局、状態変数作って共有してる。
これなら、OOPのほうが素直。

577 ：デフォルトの名無しさん：2009/06/15(月) 01:04:11

>>576
つうか電卓の機能本体をみろよｗ
こういうのをオペレータクラスだのなんだのゾロっと揃えて書くことになるんだろ

578 ：デフォルトの名無しさん：2009/06/15(月) 01:09:05

python の tk でもつかってごりごりつくりゃいいじゃんと
思ってしまうんだが。

579 ：デフォルトの名無しさん：2009/06/15(月) 01:19:45

>>577
Calculatorクラスつくって、そこに入力を放り込むってとこじゃね？

580 ：デフォルトの名無しさん：2009/06/15(月) 01:25:40

>>579
まあそりゃそうか
数式処理と勘違いしたｗ

581 ：デフォルトの名無しさん：2009/06/15(月) 01:31:54

どんな考え方でかいても、ちゃんと動くならいいんじゃないの。
それこそlogoでも。

582 ：デフォルトの名無しさん：2009/06/15(月) 05:48:59

>556
なるほど、それはあんまりオブジェクトとして扱いたくないなw

583 ：デフォルトの名無しさん：2009/06/15(月) 10:26:30

コメントで、バイナリファイルが大きくなるって事か。

未だに改修コメントとか残しているバカどもを説得する材料にはなるかもな。

584 ：デフォルトの名無しさん：2009/06/15(月) 10:40:28

それ以前にそんな言語使いたくない

585 ：デフォルトの名無しさん：2009/06/15(月) 11:09:53

「プログラムの再利用」のためには、エディタでプログラムの一部をコピーして
使えばいいのではないか。いまどきのエディタは、かなり高度な編集機能を持つので
コピーや改変は容易である。そうすれば、継承などのプログラム言語の機能は何も
習得せずに、プログラムの再利用が出来て便利である。

586 ：デフォルトの名無しさん：2009/06/15(月) 11:15:30

コードの品質を基準やメトリクスで保証しようという発想がもうダメダメ。
できる奴が書いたコードは長ヒョロくてもしっかり考えて書いてあるし、
アフォが書いたコードは短かく切ってあっても余計トレーサビリティ落とすだけ。
結局は書いた奴の能力で全て決まるんだよ。

あとは、優れた能力を持つ技術者がその能力を生かせる言語を選ぶだけ。
これならOOの糞宗教も不要だし、土方のせいでOOの評価を落とされることもない。
みんな幸せになれるんじゃないの、優秀なら。

587 ：デフォルトの名無しさん：2009/06/15(月) 11:47:25

スレタイの「消えてなくれ」っていうのが厨っぽくて好きだよ

588 ：デフォルトの名無しさん：2009/06/15(月) 11:50:25

エターナルフォースブリザード

589 ：デフォルトの名無しさん：2009/06/15(月) 11:54:41

エターナルフォースブリザード
一瞬で相手の周囲の大気ごと氷結させる
相手は死ぬ
　　　　　　V
　　　　 ∧＿∧
　　　　( ´･ω･`) 　　　∧＿∧
　　　／　　　＼　　（´Д｀　）
.＿＿|　|　　　 .|　|＿　/ 　　　ヽ
||＼　￣￣￣￣　　／ .|　　　|　|
||＼..∧＿∧　　　(⌒＼|_＿./ ./
||.　（　　　）　　　　 ~＼___＿_ノ|　　 ∧＿∧
　　/　　　ヽ　　　　　　　　　＼| 　（　　　　）　
　　|　　　　　ヽ　　　　　　　　　　＼/ 　　　ヽ.
　　|　　　　|ヽ、二⌒) 　　　　　　／ .|　　　|　|
　　.|　　　　ヽ　＼∧＿∧　　　 (⌒＼|_＿./　/

590 ：デフォルトの名無しさん：2009/06/15(月) 12:08:37

彡　　　｡･　　　　　　　彡　･ﾟ･　｡･ﾟ･｡･ﾟ･｡･｡･ﾟ･｡･ﾟ･｡･ﾟ･｡･ﾟ･　｡｡･　｡･ﾟ･彡｡･ﾟ･ﾟ･｡･ﾟ･　,.｡　ο
　･ﾟ･｡･ﾟ･　｡｡･ﾟ･｡･ﾟ･　｡･ﾟ･彡ﾟ･｡･ﾟ。 0　ｏ　＊彡　　･ﾟ･　｡･ﾟ･　｡･　　　　　　　,.｡　ο 彡
彡　　　0 ∧＿∧ ｡･ﾟ･彡｡･ﾟ･｡･　　　･｡･｡･ﾟ･　｡･ﾟ･｡･ﾟ･ﾟ･｡･　. .　　。 0　ｏ彡　　｡･ﾟ･｡･ﾟ･
o　　彡　( ´･ω･`) 　　　∧＿∧ 。･ﾟ･｡･ﾟ･　彡　　　｡･　　　　,.｡　ο
ﾟ｡･彡ﾟ･｡／　　　＼　　（´Д｀　）･　　　　　　　　　　　　　　　｡･ﾟ･　｡･ﾟ･｡･ﾟ･
ﾟ。.＿＿|　|　　　 .|　|＿　/ OO 　ヽ　｡　ο　　　　　,.｡　ο
　 ||＼　￣￣￣￣　　／ .|指向|　| ｡･　　　彡　　　　　｡･ﾟ･｡･ﾟ･　｡･ﾟ･｡･ﾟ･　｡･ﾟ･　｡･ﾟ･彡
　 ||＼..∧＿∧　　　(⌒＼|_＿./ ./ ｡･　　　｡･ﾟ･｡｡･ﾟ･｡･ﾟ･｡･ﾟ･｡･ﾟ･｡彡･ﾟ･ﾟ　･｡･ﾟ･｡･ﾟ
　 ||.　（　　　）　　　　 ~＼___＿_ノ|　　 ∧＿∧ ｡･ﾟ･｡･ﾟ･｡･ﾟ･｡･ﾟ･｡･ﾟ･　｡･ﾟ･｡･ﾟ･｡･
　　　 /　関　ヽ　　　　　　　　　＼| 　（　　　　）　彡･｡･ﾟ･｡･ﾟ･｡･ﾟﾟ･｡･ﾟ･｡･ﾟ･　｡･ﾟ･
　　　 |　数　　ヽ　　　　　　　　　　＼/ 　手　ヽ. ･｡･ﾟ･｡･ﾟ･｡･ﾟﾟ･｡･ﾟ･｡･ﾟ･　｡･ﾟ･｡
;:''`'';"|　　型　|ヽ、二⌒) 　　　　　　／ .| 続　|　| ' '';;:' ''ﾟ;:;:''"'';"'' :"' 'ﾟ　 ''ﾟ;:;:'"; 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　 .|　　　　ヽ　＼∧＿∧　　　 (⌒＼|_き./　/ 　･ﾟ･｡･ﾟ･｡･ﾟ･｡･ﾟ･　｡･ﾟ･｡･ﾟ･｡･
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　･ﾟ･｡･ﾟ･｡･ﾟ･｡･ﾟ･　｡･ﾟ･｡･ﾟ･｡･

591 ：デフォルトの名無しさん：2009/06/15(月) 12:10:29

　　　　　　　　　　　　　　　　＿＿＿＿
　　　　 ∧＿∧ 　　　　　／＿＿＿／|
　　　　( ´･ω･`)　　　　.| ∧＿∧　!／!
　　　／　　　＼　　　|（´Д｀　） |／|
.＿＿|　|__＿＿|　|______..|　OO／ヽ|／|
||＼／＿＿＿／|　　／| .| 指向　| 　| 　＿＿＿＿＿
||＼|..∧＿∧ .|/.| 　(⌒＼|_＿./ ./ |／|／＿＿＿＿／.|
||.　| （　　　） |/.|　　 ~＼___＿_ノ |.|　 ||　∧＿∧ 　|／|
　　|/　関／／|/.|　　　　　　　＼|.!／ !!（　　　　）... | /.|
　　||　数／　..|/.|　　　　　　　　　　＼.!/ ／手　ヽl／ |
　　||　型／／ |　|二⌒) 　　　　　　／|.|...|続／ |　ll／|
　　|.|／／　　.|　|　ヽ＼∧＿∧　　 (⌒＼|_き./　/.!

592 ：デフォルトの名無しさん：2009/06/15(月) 12:26:23

>>585
>エディタでプログラムの一部をコピーして使えばいいのではないか。

エディタがコピペの履歴を覚えていて、コピー元のコードを書き換える
とコピー先も書き換えてくれるようなリファクタリングを実現している
のであれば考えても良い。

593 ：デフォルトの名無しさん：2009/06/15(月) 13:17:52

>>592
いつ他人に書き換えられるか分からんようなもの誰が使うのだ。

594 ：デフォルトの名無しさん：2009/06/15(月) 13:33:00

>>593
同様の修正を施すべき場所が分散して管理できなくなることをなぜ恐れないのか

595 ：デフォルトの名無しさん：2009/06/15(月) 13:52:58

おまいら何釣られてるんだよ。釣り針が大きすぎるだろうが

596 ：デフォルトの名無しさん：2009/06/15(月) 19:08:34

>>593
それはバージョン管理システムを使って解決すべきでは

597 ：デフォルトの名無しさん：2009/06/16(火) 00:29:48

コメントもオントロジー管理すりゃいいのに。

598 ：デフォルトの名無しさん：2009/06/16(火) 00:31:17

そもそもコードをエディタでコピペして作るためにオブジェクト指向プログラミングが
存在するんだよ。

599 ：デフォルトの名無しさん：2009/06/16(火) 01:12:59

>590-591
OO指向の片方のOは何の略なんだ

600 ：デフォルトの名無しさん：2009/06/16(火) 05:14:37

おっぱい

601 ：デフォルトの名無しさん：2009/06/16(火) 13:56:23

おおきなおっぱいぱぱのもの思考

602 ：名無し＠18歳未満の入場禁止：2009/06/16(火) 15:33:38

おっさん

603 ：デフォルトの名無しさん：2009/06/16(火) 19:00:04

よくこんなスレタイで盛り上がれるな

604 ：デフォルトの名無しさん：2009/06/16(火) 19:18:18

そろそろADT(Abstract Data Type)の優位性について語ろうか。いや、語ってください。

605 ：デフォルトの名無しさん：2009/06/16(火) 19:36:18

とりあえず、ADTとは次の内容によって構成されるもの。TAPL page 368.
1. 型の名前A
2. 型の具体的な表現T
3. 型Tに対する操作の実装
4. 型の表現や操作を包み込む抽象化
OOと違って明確な定義がある。

606 ：デフォルトの名無しさん：2009/06/16(火) 19:40:34

カウンターを(OCamlの)ADTで実装すると、こう。
module Counter : sig
type t
val make : unit -> t
val inc : t -> t
val get : t -> int
end = struct
type t = int
let make () = 0
let inc x = x + 1
let get x = x
end;;

607 ：デフォルトの名無しさん：2009/06/16(火) 20:47:23

ADTもOO同様、文脈によっていろんな意味を持つからね。
リスコフ（手続きとデータのセット。原義。広義）なのか、
ストラウストラップ（ユーザー定義型。クラスとほぼ同義）なのか、
クック（型による抽象化。手続きはデータに内包させない（つまりクラスはＮＧ）。狭義）なのか
くらいははっきりさせとかないと。

608 ：デフォルトの名無しさん：2009/06/16(火) 20:50:56

あとはソート代数とか、ADTは関係あるよなないような、ってのが多い罠

609 ：デフォルトの名無しさん：2009/06/16(火) 20:56:07

>>607
クックでよろ。

610 ：デフォルトの名無しさん：2009/06/16(火) 21:00:56

とりあえず、これを読んでおこうか。
ttp://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOPvsADT90.pdf

611 ：デフォルトの名無しさん：2009/06/16(火) 21:02:15

>>610
無理読めない和訳してね

612 ：デフォルトの名無しさん：2009/06/16(火) 21:04:41

Modula-3のOpaque型もADTに情報隠蔽を加えたようなものだが。

613 ：デフォルトの名無しさん：2009/06/16(火) 21:13:30

>>605 = >>606 = >>609？
>>606の定義はCookのADTでは無いが。

614 ：デフォルトの名無しさん：2009/06/16(火) 21:27:20

>>613
え？違うの？違いが分かりません。
型と操作が含まれていて、それらを抽象化できるんじゃないの？

615 ：デフォルトの名無しさん：2009/06/16(火) 22:34:48

>>614
> クック（型による抽象化。手続きはデータに内包させない（つまりクラスはＮＧ）。
モジュールに手続きを内包させるのは違うんでないの？

616 ：デフォルトの名無しさん：2009/06/16(火) 23:07:53

>>615
>>610ではADTによる型と操作を分けたlistの実装やそのシグネチャーが言及されています。
それに、複数ヶ所でMLの抽象データ型にも触れられており、
cookのADTは>>605,>>606と捉えて問題ないように（私には）見えます。

617 ：デフォルトの名無しさん：2009/06/16(火) 23:16:38

>>616
これはADTと呼べないの？>>606と同じことを実現してるんだが。
Counterが型だからそれだけでアウト？

template <typename T>
struct Counter
{
T t;
T make() = 0;
void inc(T& t) {t += 1;}
int get(T& t) {return t;}
};

618 ：617：2009/06/16(火) 23:29:49

すまん>>617は忘れてくれ。寝ぼけていたようだ。
クラスが駄目なのは分かったが、Cで以下のようなコードをCounter.cという
モジュールにしたら、それはADTと呼べない？
ただ、Counterは例えとして良くないな。

typedef some_type Counter;
Counter c;

Counter * make() {return malloc(sizeof(Counter));}
void inc(Counter *c) {*c += 1;}
Counter get(Counter *c) {return *c;}

619 ：デフォルトの名無しさん：2009/06/16(火) 23:32:44

>>617
Counterが型だからという理由ではなく、>>605の2（型の表現）や4(型や操作の抽象化)が
ないので、ADTの定義からは外れると思います。
型を抽象化したのではなくパラメータ化したと言う方が正しいかと。

620 ：617：2009/06/16(火) 23:43:08

>>610を読んでみると、

Simula and C++ support both ADTs and PDA in the same framework; ...

とあるからC++でもADTを表現出来ると思うんだが、純粋なADTじゃないから
駄目なのか？

621 ：デフォルトの名無しさん：2009/06/16(火) 23:57:56

>>620
すみません、C++には詳しくなくて分かりません。
でもたぶん、typeid演算子を使えばできるぜというくらいの意味じゃないでしょうか。

622 ：デフォルトの名無しさん：2009/06/17(水) 00:06:12

>>621
>>610の論文は1990年頃に出たと思うんだが、当時のC++にtypeidは無かった気がする。

623 ：デフォルトの名無しさん：2009/06/17(水) 00:52:52

ここにもADTの定義が書いてある。真ん中よりちょっと上。4つの特徴で定義してある。
ttp://gd.tuwien.ac.at/languages/c/c++oop-pmueller/node4.html
やっぱり型と操作の分離や外部への抽象化がポイント。

624 ：デフォルトの名無しさん：2009/06/17(水) 02:52:13

>>623
だからリスコフとストラウストラップとクックのADTくらいはさくっと見分けがつく程度にはしておこうよ。
そうであれば、たとえば623のリンク先はストラウストラップの流れのADT（OOのサブセット）とすぐ分かるから。

http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-561.pdf
http://www.research.att.com/~bs/whatis.pdf
http://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOPvsADT90.pdf

625 ：デフォルトの名無しさん：2009/06/17(水) 04:42:10

しかしADTもOO並にカオスだな
いくつも同名の別定義を作るくらいなら別名にすればいいのに

626 ：デフォルトの名無しさん：2009/06/17(水) 09:53:16

>>625
dateが、今日の日付を表すのか、単なる日付を表すのか、彼女といちゃつく日を表すのか
それを文脈から読み取れるようにしようとしているだけだろ

空気の読めないプログラマに、空気を読むプログラムをするように言ってるようなもんだからなぁ

627 ：デフォルトの名無しさん：2009/06/17(水) 17:24:20

先生分かりにくいです

628 ：デフォルトの名無しさん：2009/06/17(水) 18:36:39

下手なアナロジーが余計に物事を分かりにくくするという典型例だな

629 ：デフォルトの名無しさん：2009/06/17(水) 19:10:32

人が嫌がりそうなことを言っときたい人ってのだけはわかるｗ

630 ：デフォルトの名無しさん：2009/06/17(水) 19:55:41

なんかこのスレは勉強になるなぁ
ところで、MLのモジュールシステムってのはどうなの？OOより使いやすいの？
クラスベースと違って型は型として組み合せて作れるので、
その点は見やすくていいかなと思ってる

631 ：デフォルトの名無しさん：2009/06/17(水) 20:13:58

> MLのモジュールシステムってのは
出来上がったシステムとは何の関係もない

使ってうまくものが動けば正解なんだと思う
問題領域に最適な手法を使うのが正しい道だろ？

俺的には、信号処理とかだとOOなデザインするより、
伝達関数とか状態方程式が飛び交ってくれた方が
分かりやすい

632 ：デフォルトの名無しさん：2009/06/17(水) 20:28:21

>>624
まだADTが良くわからん。>>620にあるように、CookのOOPvsADTnの論文で
C++でもADTが実現可能とあるけど、誰かC++でCookの言うADTを表現してみてよ。

633 ：デフォルトの名無しさん：2009/06/17(水) 20:52:21

>>630
http://www.research.att.com/~bs/whatis.pdf
の6ページにOOの方が有効な一例が載ってる。

634 ：633：2009/06/17(水) 20:54:07

途中送信してしまった。
当然のことだが、どちらが有効かは場合によるから臨機応変に選択すればよい。

635 ：デフォルトの名無しさん：2009/06/17(水) 21:10:51

>>633
6ページ目の話はなんだかexpression problemの事を言っているように見える
まー、1991年だし、バリアントを加えるのにはOO有利ってことか。

636 ：デフォルトの名無しさん：2009/06/18(木) 00:03:55

ちなみに、2009年には多相バリアントという便利な代物があるから
expression problemがモジュールシステムの弱点とは言えないと思う。

637 ：デフォルトの名無しさん：2009/06/18(木) 00:20:08

expression problemの定義は？

638 ：デフォルトの名無しさん：2009/06/18(木) 00:39:08

>>636
ちなみに6ページ目の例をpolymorphic variantsで実装するとどうなるの？

639 ：デフォルトの名無しさん：2009/06/18(木) 07:40:57

そもそもオブジェクト指向と関係無いような気がする

640 ：デフォルトの名無しさん：2009/06/18(木) 07:54:17

>>637
定義
ttp://www.daimi.au.dk/~madst/tool/papers/expression.txt
>>638
その解法など
ttp://www.math.nagoya-u.ac.jp/~garrigue/code/ocaml.html
ttp://d.hatena.ne.jp/osiire/20090516#1242456737

641 ：デフォルトの名無しさん：2009/06/18(木) 18:00:29

全文リンクレスは著作権的にＮＧだろ
自分の言葉で語れよ

642 ：デフォルトの名無しさん：2009/06/18(木) 18:10:12

直リン厳禁です＞＜

643 ：デフォルトの名無しさん：2009/06/18(木) 18:27:59

少なくともリンクがレスのメインになったらアウトだろ

644 ：デフォルトの名無しさん：2009/06/18(木) 18:31:21

直リンて懐かしいなｗ
またキチガイが無駄な屁理屈こねてんのか

645 ：638：2009/06/18(木) 18:34:24

>>640
やはりそれが定義だったのか。ググってすぐに出てきたのがそれだったから。

polymorphic variantsで継承&仮想関数オーバーライドとほぼ同様のことが
出来るのは分かった。ただ少し記述が面倒だな。あと拡張したモジュール名を
使う必要があるのも面倒というか。
どちらにもそれなりの良さがあるから一概にどちらが良いとは言えないが。

646 ：デフォルトの名無しさん：2009/06/18(木) 19:00:48

リンクだけレスは著作権法の引用の範囲をぶっちぎりで破ってる

>自分のオリジナルな文章が主（量的にも質的にも）であり、引用部分が従であること
（ちなみにこの文は法律なのでおｋ）

つまり、リンクだけレスは著作権法違反

647 ：デフォルトの名無しさん：2009/06/18(木) 19:03:34

アホがいる

648 ：デフォルトの名無しさん：2009/06/18(木) 19:06:40

OOやADTの形式論を議論している場で、
引用と参照の違いが理解できない人がいるのは、
とても滑稽だと思った。

649 ：デフォルトの名無しさん：2009/06/18(木) 19:21:32

>>647
どうした？
かかってこいよ

650 ：デフォルトの名無しさん：2009/06/18(木) 19:25:37

グーグルみたいに巨大になれば法律を捻じ曲げる力が持てるぞ
人の作った法なんて巨大になって捻じ曲げようぜ

651 ：デフォルトの名無しさん：2009/06/18(木) 20:51:30

>>645
>polymorphic variantsで継承&仮想関数オーバーライドとほぼ同様のことが出来るのは分かった。
気持ちは分かるけど、オブジェクト指向の枠組で捉え直そうという試みは
理解を助けるための最初の一歩だけにしておいた方がいいですね。
もっと素直に書くと、expression problemを解決する鍵は、
- polymorphic variantsは複数の型になり得る（多相）ので、
　基の型と拡張後の型の両方に属すことができる
- モジュールシステムは元々操作を拡張することができる
という二点で成り立っている訳です。

652 ：デフォルトの名無しさん：2009/06/18(木) 21:33:50

>>651
気持ちの問題は関係なくて、元々の話はStroustrapの6ページ目の例を
polymorphic variantsでどう解決できるかを聞いていたのであって、
だからこそ継承&仮想関数による表現がどのように対応するのかを確認したわけ。

> - モジュールシステムは元々操作を拡張することができる
これは具体的にどういう意味？当然の話だと思うけれど。

653 ：デフォルトの名無しさん：2009/06/18(木) 21:45:41

>>641
単なるリンクは、引用じゃありません。
リンクは、文献参照と同じです。
著作権的にはまったく問題ありません。
問題あるというのなら、判例か何かを出してください。

654 ：デフォルトの名無しさん：2009/06/18(木) 21:47:13

>>653
土方は放置すればいいだろ

655 ：デフォルトの名無しさん：2009/06/18(木) 22:01:28

>>653
勝手な介錯だな

656 ：デフォルトの名無しさん：2009/06/18(木) 22:03:57

切腹ー

657 ：デフォルトの名無しさん：2009/06/18(木) 22:15:32

>>652
あぁ、誤解していました。すみません。
OOでは継承と仮想関数によって「種類を増やす」事をしていた訳ですので、
polymorphic variantsが同様の役割を担っているのはおっしゃる通りです。
あと、
>モジュールシステムは元々操作を拡張することができる
というのは、"新しい操作を加えることができる"の間違いでした。
OOではこれをやろうとすると、visitorパターンを使わなきゃいけなくなります。
で、visitorパターンを使うと今度は種類を増やせなくなる。
つまり、expression problemはC++やJavaでは解決できません。

658 ：デフォルトの名無しさん：2009/06/18(木) 22:25:23

Javaでexpression problemを解決しようと頑張ってみた例↓
ttp://www.graco.c.u-tokyo.ac.jp/~nishi/semi/tm.2004-02-18.xhtml
これと比べれば、polymorphic variantsによる解法が如何に簡潔か分かると思う。

659 ：デフォルトの名無しさん：2009/06/18(木) 22:39:20

OOがゴミということは最初からなんとなく判ってたんだ
途中から総称型がもてはやされた時点で確信に変わった
次第にOOはどんどん隅に追いやられ、やがて名前だけの存在になった
つまりOOは、OOであることをやめてしまったのだ

660 ：デフォルトの名無しさん：2009/06/19(金) 00:56:11

OOPLにはなんでタプルとバリアントが無いの？バカなの？死ぬの？

661 ：デフォルトの名無しさん：2009/06/19(金) 01:01:09

どったん？死ぬん？

662 ：デフォルトの名無しさん：2009/06/19(金) 01:19:17

アメリカでOOP禁止になるかもな

663 ：デフォルトの名無しさん：2009/06/19(金) 02:05:57

>>660
その文体飽きちゃった

664 ：デフォルトの名無しさん：2009/06/19(金) 11:01:28

>>632
template <typename T, typename C> class stack {
typedef T value_type;
typedef C container_type;
public:
virtual value_type top(void) = 0;
virtual void pop(void) = 0;
virtual void push(value_type) = 0;
private:
container_type _container;
}

665 ：デフォルトの名無しさん：2009/06/20(土) 00:05:37

PythonにはタプルあるしVB系にはバリアントあるけど…

666 ：デフォルトの名無しさん：2009/06/20(土) 04:08:07

C++はboostのtupleが使えるから特に問題無いな。実装は汚いが。

667 ：デフォルトの名無しさん：2009/06/20(土) 08:29:23

>>665
バリアントの意味が違う
どの型でも代入できる変数なんてキモいやつの事じゃないからね

668 ：デフォルトの名無しさん：2009/06/20(土) 09:48:29

いわゆる代数的データ型だな

669 ：デフォルトの名無しさん：2009/06/20(土) 10:30:47

代数的データ型といえば、コンパイルは通るのに実行時にパターンマッチ失敗して
どこが間違ってるのか探すのが面倒で、静的型の意味がないと思った記憶がある

670 ：デフォルトの名無しさん：2009/06/20(土) 10:31:11

バリアントあれば継承いらねえことに気づいた

671 ：デフォルトの名無しさん：2009/06/20(土) 10:54:32

>>670
おまえ全然分かってないな

672 ：デフォルトの名無しさん：2009/06/20(土) 10:55:07

>>670
それは、継承の使い方を間違っているだけじゃないの?

673 ：デフォルトの名無しさん：2009/06/20(土) 11:23:44

>>670
「いらないこともある」だな。
継承あった方が便利って時もある。

674 ：デフォルトの名無しさん：2009/06/20(土) 12:51:11

変数に型があるからオブジェクト指向が考えにくいのかもしれん。
Lispみたいに変数の型を無くして値に型を持たせたらいいかもな。

675 ：デフォルトの名無しさん：2009/06/20(土) 13:03:22

http://practical-scheme.net/trans/noop-j.html
> 個人的には、オブジェクト指向抽象化が必要だと思ったことは一度もない。 Common Lispは
> 恐ろしいほど強力なオブジェクトシステムを持っているが、私は一度もそれを使ったことがないん
> だ。ハッシュテーブルにクロージャを詰め込むとか、弱い言語だったらオブジェクト指向テクニッ
> クが必要だっただろうと思えることはたくさんやってきたけれど、CLOSを使う必要に迫られたこ
> とは無かった。

676 ：デフォルトの名無しさん：2009/06/20(土) 13:37:55

>>673
それで設計変わっちゃうのってどうよ？

677 ：デフォルトの名無しさん：2009/06/20(土) 13:59:46

>>670も>>673もおまいらみんな土方だろ

継承の代わりになり得るのはバリアントじゃなくて多相バリアントだ

678 ：デフォルトの名無しさん：2009/06/20(土) 14:08:00

>>675
要約すると
「LISPのOOはCLOSがあるけど結局クセが強すぎて怖くて使わなかった
考えてみたらおりゃのやる範囲じゃOOいらなかった」

679 ：デフォルトの名無しさん：2009/06/20(土) 14:12:51

CLOSが変態なのはCLOS屋も認めるところだからなあw

680 ：デフォルトの名無しさん：2009/06/21(日) 10:27:22

>>669
それ、exhaustive checkの警告を華麗にスルーしてるだろww

681 ：デフォルトの名無しさん：2009/06/21(日) 11:16:47

やっぱり、無制限に新しい型を作れるオブジェクト指向と、
静的型システムとは相性が悪いんだよ。
Objective-C みたいに、別々に存在してるほうがいいんじゃないの。

682 ：デフォルトの名無しさん：2009/06/21(日) 18:09:22

まぁ臨機応変に

683 ：デフォルトの名無しさん：2009/06/21(日) 21:32:03

>>681
>やっぱり、無制限に新しい型を作れるオブジェクト指向と、
>静的型システムとは相性が悪いんだよ。
相性以前に、型なんて何にも考えずに作った構文やセマンティクスの上に
おまけで型を入れようとするから、静的にならないんじゃないかな。

684 ：デフォルトの名無しさん：2009/06/21(日) 22:29:23

型システムをおまけとして分離すると再利用しやすくなる。
例えば型システムの古いバージョンと新しいバージョンを連携させることもできる。

685 ：デフォルトの名無しさん：2009/06/21(日) 23:47:28

>>684
>型システムをおまけとして分離する
型安全とか型推論ってその言語で定義される値や構文の上に定義されるものだから、
分離すること自体が困難そうにみえるのだけど。
型システムをおまけとして扱う関連情報源ありますか？

686 ：デフォルトの名無しさん：2009/06/22(月) 00:55:42

>>685
Objective-Cの話だと思うが
動的型付けが気に入らないなら、C++/CLIとか調べてみれば

687 ：デフォルトの名無しさん：2009/06/22(月) 08:19:34

>>685
アノテーション使うヤツなら太古の昔から色々提案されてるだろ。

688 ：デフォルトの名無しさん：2009/06/22(月) 19:37:19

>>674
それって python じゃね？
まあスピードもメモリも気にしないってことなら
いいんじゃないかと思うが。

689 ：デフォルトの名無しさん：2009/06/22(月) 19:50:59

あんな括弧もないような言語は捨てちまえ

690 ：デフォルトの名無しさん：2009/06/22(月) 19:52:51

>>689 誉めてつかわす

691 ：デフォルトの名無しさん：2009/06/22(月) 20:00:33

lisperｷﾓ

692 ：デフォルトの名無しさん：2009/06/22(月) 20:19:36

lisperは巣にｶｴﾚ!!!

693 ：デフォルトの名無しさん：2009/06/22(月) 21:07:36

lisper lisperささやいて～

694 ：デフォルトの名無しさん：2009/06/22(月) 22:21:36

動的型のOOPLは、自分が書くときには最高のパフォーマンスを発揮する。
物によっては、基底クラスやオブジェクト自身の型さえ変えられる。
でも、他人のソースを読むときは、まさにカオス。

695 ：デフォルトの名無しさん：2009/06/22(月) 23:16:48

だからケント・ベックは他人が読みやすいコードの重要性にSmalltalkで気付いたのかな。

696 ：デフォルトの名無しさん：2009/06/23(火) 00:13:55

動的型のOOPLのソースコード、引き継ぎたくねー。

697 ：デフォルトの名無しさん：2009/06/23(火) 01:01:18

じゃあrubyとか最悪ですね

698 ：デフォルトの名無しさん：2009/06/23(火) 02:45:55

うちの会社じゃ、Rubyのコーディング規約として、publicなものには型を
コメントとして書く事にしてるよ。

699 ：デフォルトの名無しさん：2009/06/23(火) 05:27:32

それ最低だな。
静的型の型検査も、動的型のフレキシブルな記述も、両方とも捨ててる。

700 ：デフォルトの名無しさん：2009/06/23(火) 09:04:49

>>699
なにその一見同意しそうで、いやちょっとまてよ？ん？となる文章は。

701 ：デフォルトの名無しさん：2009/06/23(火) 09:07:37

型を意識するだけでなく、コメントとして書くぐらいなら
型シグネチャが必要な言語でいいじゃんって思うけど
強い静的型のLLなんてない(強いていうならHaskell？)現実

702 ：デフォルトの名無しさん：2009/06/23(火) 09:30:48

せめてLLを定義してから言えよ

703 ：デフォルトの名無しさん：2009/06/23(火) 09:31:09

静的型＋型推論が一番かなぁ。コンパイル言語になっちゃうが。

704 ：デフォルトの名無しさん：2009/06/23(火) 11:28:49

別に今のLLだって最初に全体をプリコンパイルしてるの多いし
そうでなくても全体をパースしちゃうのも多いから
純粋なインタプリタなんて今や希少種じゃね？

705 ：デフォルトの名無しさん：2009/06/23(火) 11:46:47

/bin/shさいこおおおおおおお

706 ：デフォルトの名無しさん：2009/06/23(火) 12:31:30

>701
スクリプトモードののScalaとか？

Rubyで、コメントにアノテーションとして型を明示する書法無いの？
なんかのライブラリのHTMLドキュメント見た時に書いてあったから、
そういうツールが出回ってるのかと思い込んでたけど。

707 ：デフォルトの名無しさん：2009/06/23(火) 13:27:32

>705
ああ、シェルスクリプトやバッチファイルはそうだっけ。

708 ：デフォルトの名無しさん：2009/06/23(火) 13:54:25

>>704
具体的に言語名は？
ruby,pythonなんか遅いからそんなことやってないと思うが。

709 ：デフォルトの名無しさん：2009/06/23(火) 13:58:32

>708
RubyもPythonも最初に全体をパースしてなかったっけ？

710 ：デフォルトの名無しさん：2009/06/23(火) 14:03:54

ファイル全体を一気にパースしたらコンパイル言語というのは少し御幣があるな。
抽象構文木を解釈しながら実行するなら、インタプリタと呼ぶべきかと。
PythonなんかだとJITコンパイルをする実装もあるが。

711 ：デフォルトの名無しさん：2009/06/23(火) 14:16:08

いや、俺（>704）は「コンパイル言語」とは言ってないよ。
ただ、どっちにしても全体を最初に見るワケだから
「静的型＋型推論」をするのにコンパイル言語である必要は無いんじゃないのか？と言いたかった。
言葉足らず過ぎてすまん。

712 ：デフォルトの名無しさん：2009/06/23(火) 14:30:20

>>708
> ruby,pythonなんか遅いからそんなことやってないと思うが。

${PYTHON}/Doc/glossary.rst
bytecode
Python source code is compiled into bytecode, the internal representation
of a Python program in the interpreter. The bytecode is also cached in
``.pyc`` and ``.pyo`` files so that executing the same file is faster the
second time (recompilation from source to bytecode can be avoided). This
"intermediate language" is said to run on a :term:`virtual machine`
that executes the machine code corresponding to each bytecode.

713 ：デフォルトの名無しさん：2009/06/23(火) 17:24:08

>>704
>別に今のLLだって最初に全体をプリコンパイルしてるの多いし

ここに反応してレスしたんだ。多いのだったらいくらでも例をあげられるだろう。
ruby,pythonをあげるととたんにパースしているはないだろう。
もしそういうのがあれば使ってみたい。

>>712
マシン語にならないのにプリコンパイルと言われても他の言語になっているだけ。

714 ：デフォルトの名無しさん：2009/06/23(火) 17:33:18

>>713
> マシン語にならないのにプリコンパイルと言われても

>>704はこの考え方が古いって言っているんだよね。
中間言語へコンパイルしてさえいないのはいまや希少。

> もしそういうのがあれば使ってみたい。

v8 javascript engine
構文木からいきなりx86に変換して実行。
eval関数がある言語なのに。
REPLでも同じようにx86に変換して実行する。

715 ：デフォルトの名無しさん：2009/06/23(火) 17:35:50

実行中に型推論うごかすのかよw

716 ：デフォルトの名無しさん：2009/06/23(火) 18:10:55

大抵はインクリメンタルにやればすぐ終わるよ
そのまま動かす方がオーバーヘッドが大きい

717 ：デフォルトの名無しさん：2009/06/23(火) 18:13:04

>>714
> eval関数がある言語なのに。
lisp 系は昔から native 吐くやつざらにあるじゃん

718 ：デフォルトの名無しさん：2009/06/23(火) 18:50:43

>>714
V8のソースを少し見てみたが、本当に抽象構文木Tから直接マシン語を
出力してるな。アセンブリ言語に近い中間言語に落として最適化を
かけてからコード生成というアプローチだとレイテンシー等の問題が
出るってこと？

719 ：デフォルトの名無しさん：2009/06/23(火) 20:01:37

>>717
ほとんど全てのLispはインタープリタも持ってるでしょ。
(Scheme実装のStarlinみたいな処理系もあるけど)
だからS式のまま実行できる。
v8はインタープリタはない。そこが違う。

>>718
二度手間だって事でしょ。
WebではJavascriptのコードはソースで提供されるわけで、
PythonみたいにILを外部ファイルに持っておけるわけじゃない。
だったらJIT一発で実行した方がいい。

それからプロパティアクセスを高速化するためにはJIT必須という考え方。
Cの構造体フィールドアクセスと同じコードになってる。

「コンパイラ・スクリプトエンジン」相談室スレに移動した方がいいかな?

720 ：デフォルトの名無しさん：2009/06/23(火) 20:03:30

つまりnativeで実行できない言語はゴミ

721 ：デフォルトの名無しさん：2009/06/23(火) 20:36:25

native実行していてもゴミ同然の言語あるよねw

722 ：デフォルトの名無しさん：2009/06/23(火) 20:41:37

>>719
IR無しだと最適化が二度手間になると思うんだが、ターゲットCPUが
x86, x86_64, ARMだけだから何とかなっているのかもしれん。
というかLLVMなどを使うより高速なコード生成が出来るなら
やっぱりGoogleは凄いってことだな。

723 ：デフォルトの名無しさん：2009/06/23(火) 20:43:32

v8はデータフロー解析みたいな最適化は一切やってないんだわ。
ピープホール的な事をちょっとやってるだけで。

724 ：デフォルトの名無しさん：2009/06/24(水) 00:00:59

民主党が政権とると
OOPは規制対象になるね税金の無駄遣いだし

725 ：デフォルトの名無しさん：2009/06/24(水) 03:21:05

民主党が政権とるとOOPを使えないってこと？
自民党だと派遣マンセーでjavaを強制的に使わされそうだし
この際OOP規制で良いや

726 ：デフォルトの名無しさん：2009/06/27(土) 14:12:33

今朝がたの会話
俺「そんなやりかたじゃ規格が満たせません」
某SE「今までこの方法で動かなかったものはないんだからこれでいいんだ」
… … …

規格書の読み方も知らんのか? > OO できる SE

727 ：デフォルトの名無しさん：2009/06/27(土) 15:04:52

OO関係ないやん。

728 ：デフォルトの名無しさん：2009/06/27(土) 18:34:56

上司「その規格書さ、間違ってるから」

よくあることである

729 ：726：2009/06/27(土) 20:14:14

>>728
某SE「OO的に書けないんだからその MP4 の規格書間違ってる」ってか

730 ：デフォルトの名無しさん：2009/06/27(土) 20:57:13

理解力の無さから察するに >>726 の方が間違ってそう

731 ：デフォルトの名無しさん：2009/06/27(土) 21:04:35

今日、次期政権担当政党で
IT詳しい人に聞いたがやっぱり
OOPは禁止だと言ってた

それってレガシーなんでしょって言ってたよ

732 ：デフォルトの名無しさん：2009/06/27(土) 22:45:16

733 ：デフォルトの名無しさん：2009/06/28(日) 10:09:49

>>731

734 ：デフォルトの名無しさん：2009/06/30(火) 14:16:49

オブジェクト指向って、せっかくまとまっているグローバル変数を
あっちこっちに散らかしてわかりにくくしたものなのですね

と言ってみる

735 ：デフォルトの名無しさん：2009/06/30(火) 16:14:11

流石にグローバル変数を持ち出されるとコボラ乙としか言えない

736 ：デフォルトの名無しさん：2009/06/30(火) 16:15:24

オブジェクト指向なんかPhotoshopで言えばレイヤーみたいなもん
あって当然使えて当然
ただ使えるだけで威張ってるのは馬鹿
「レイヤーを使わないと絵が描けません」と威張る言語も馬鹿

737 ：デフォルトの名無しさん：2009/06/30(火) 19:47:19

使えませんと言って威張ってるのはもっと馬鹿

738 ：デフォルトの名無しさん：2009/07/01(水) 00:44:29

アメリカでもEUでもOOP規制の動きが
出始めてる。ソフトウェア産業に害しか及ぼさないということで
原則使用禁止を国レベルで採択する方向が強まってるね

739 ：デフォルトの名無しさん：2009/07/01(水) 00:46:19

つまんね

740 ：デフォルトの名無しさん：2009/07/01(水) 10:39:35

>>738
何言ってんのお前
若年性認知症か？

741 ：デフォルトの名無しさん：2009/07/01(水) 22:53:57

>>740
>>740
>>740
>>740

742 ：デフォルトの名無しさん：2009/07/01(水) 23:46:22

「OOを使わない」と「OOを使えない」の差は大きいね。

743 ：デフォルトの名無しさん：2009/07/02(木) 00:03:01

この際使えなくていいよ。もう使わないから。

744 ：デフォルトの名無しさん：2009/07/02(木) 06:53:06

私も C++ Ver1 のころはOOはいいと思ってました。

745 ：デフォルトの名無しさん：2009/07/02(木) 11:14:11

C++ はそれ以外に問題が大杉だw

746 ：デフォルトの名無しさん：2009/07/02(木) 13:40:09

lisp属の()が可愛く見えるほど
変態構文だらけになってしまったもんなぁ > C++

747 ：デフォルトの名無しさん：2009/07/02(木) 13:55:39

たとえばどんな？　あるいはとくにどれが？

748 ：デフォルトの名無しさん：2009/07/02(木) 15:19:33

テンプレートとか今度入ってくるラムダとかのことじゃねぇの

749 ：デフォルトの名無しさん：2009/07/02(木) 19:17:27

boostなんかだと演算子をオーバーロードしまくってるから
とてもC++とは思えないコードになるからな。

750 ：デフォルトの名無しさん：2009/07/02(木) 19:21:29

日本を代表するc++ハッカーのやねうらお氏もlispが来ると言ってるね
http://d.hatena.ne.jp/yaneurao/20090701

751 ：デフォルトの名無しさん：2009/07/02(木) 19:27:31

こねぇｗｗｗ

752 ：デフォルトの名無しさん：2009/07/02(木) 19:53:26

ぶろっがーの間でははやるんじゃね？

753 ：デフォルトの名無しさん：2009/07/02(木) 20:18:19

やねうらってLISP知ってたのか
組み込み寄りの人かと思った

754 ：デフォルトの名無しさん：2009/07/02(木) 20:30:46

ＨＳＰerとLISPerってどっちが馬鹿なの？

755 ：デフォルトの名無しさん：2009/07/02(木) 21:09:13

あくまでも、Lispは実験言語だな。
でも、実験言語としては非常に優れている。
プログラムとデータが渾然一体としているから、
どんな革新的な機能でも追加できる。
ただし、文法がS式なことだけ我慢すれば。

756 ：デフォルトの名無しさん：2009/07/02(木) 21:16:31

S式は抽象構文木として使えばいいのであって、
具象構文は普通にパーサ書けばいいだけ。
LISPは元々は自然言語処理のために開発されたことを忘れないで＞＜

757 ：デフォルトの名無しさん：2009/07/02(木) 22:12:54

まぁ、何だかんだ言っても馬鹿にはLispは使えませんよ

758 ：デフォルトの名無しさん：2009/07/02(木) 23:27:19

だからって、Lispを練習しても馬鹿が直る訳じゃないんだが、
時々それを勘違いしてる奴が居る。

759 ：デフォルトの名無しさん：2009/07/02(木) 23:34:50

>>756が新しい言語を作るそうです

760 ：デフォルトの名無しさん：2009/07/03(金) 00:13:04

guile ctax なんてものもあったけど、使われてないね。

761 ：デフォルトの名無しさん：2009/07/03(金) 01:09:08

他人のオナニー見ても気持ちよくないからね

762 ：デフォルトの名無しさん：2009/07/03(金) 14:56:07

>>756
今時RLISPかよ

763 ：デフォルトの名無しさん：2009/07/03(金) 15:26:45

見事にLISPスレ的な流れになったな

764 ：デフォルトの名無しさん：2009/07/03(金) 16:07:14

LISP語るならCLOSについて話せよ

765 ：デフォルトの名無しさん：2009/07/03(金) 16:26:12

モノを完成させてからオブジェクト指向で書き直すなんて二度手間です＞＜

766 ：デフォルトの名無しさん：2009/07/03(金) 23:15:27

>>758が「馬鹿はLispが使えない」ことを証明しますた。

767 ：デフォルトの名無しさん：2009/07/03(金) 23:31:13

別にわざわざLisp使う意味がわからないな
C言語でいいじゃん

768 ：デフォルトの名無しさん：2009/07/03(金) 23:51:48

>>767
使いなれてしまうと日常的にCを使いたくなくなるな
つか、俺にとってはCは未だに高級アセンブラ、C++は超高級マクロアセンブラ

なんでスペシャル変数を導入しないんだろ >C++

769 ：デフォルトの名無しさん：2009/07/04(土) 00:02:52

最近、Ｃ言語で地味に堅く組むのがマイブーム

770 ：デフォルトの名無しさん：2009/07/04(土) 00:43:46

高級アセンブラと思ったことはないけど、Cは十分に高級言語なので
たいていのことはこなせる。
Cより複雑なことをしたい場合は、PerlとかRubyとかのスクリプト言語にするよ

771 ：デフォルトの名無しさん：2009/07/04(土) 05:10:49

スペシャル変数www
それがプログラミング言語設計一般で使われる概念名称だと思ってるのかwww
ひさしぶりに腹かかえたwwwww

772 ：デフォルトの名無しさん：2009/07/04(土) 07:44:15

なれるとLispはCやC++よりプログラムを考えるのが楽チン

773 ：デフォルトの名無しさん：2009/07/04(土) 08:25:34

むかしLISPを勉強しようと思ってMSDOS用のXLISPを入手した。
これが使用中にしょっちゅう落ちる。でメンテしてめったに落ちなくしてついでに
いろんな関数を作って高級アセンブラ並にしたんだが結局Cを使った方が楽で使わ
なかった。LISPはおれにとって楽チンどころか苦痛を与えるためにあるようんもんだ。

774 ：デフォルトの名無しさん：2009/07/04(土) 09:12:52

マジOOは思想ごとこの世から消えて欲しい。
CやVBでさえまだ満足に使えてないのに、
周りがどんどんOOに進んでいくので、落ちこぼれ感が半端ない。
技術的というより、精神的に追い詰められる。

775 ：デフォルトの名無しさん：2009/07/04(土) 09:34:28

相手を追い詰めることで自分が進んでいると思えるって、ひどい相対主義だな

776 ：デフォルトの名無しさん：2009/07/04(土) 09:39:41

追い詰めると言うよりは、置き去りですな。
もしくは、怠慢でついて来れないだけ。

777 ：デフォルトの名無しさん：2009/07/04(土) 09:43:58

DOSのLispっておもちゃだったからなあ。

778 ：デフォルトの名無しさん：2009/07/04(土) 10:18:36

OOを捨てることは何時だって出来るのに
これだけ普及＆定着しまくってるんだから
何かしら捨てられない理由でもあるんでしょう

779 ：デフォルトの名無しさん：2009/07/04(土) 10:28:50

GUI 関連ならそりゃ普及してるけど、
それ以外で無理に使う必要あるか？

780 ：デフォルトの名無しさん：2009/07/04(土) 10:30:56

OOPはこれから規制対象になるんだけどねぇ
品質が上がらない要因といわれている

781 ：デフォルトの名無しさん：2009/07/04(土) 11:00:56

一定以上複雑なプログラムには有効な整理方法だよ
単純なプログラムには必要ないね

782 ：デフォルトの名無しさん：2009/07/04(土) 11:04:44

LinuxカーネルもWindows7のカーネルも
すごい複雑だけど1行もOOP使ってないけどね

783 ：デフォルトの名無しさん：2009/07/04(土) 11:12:27

WindowsにOOPが使われてないとは初耳だなぁ...

784 ：デフォルトの名無しさん：2009/07/04(土) 11:21:38

>>783
VistaはカーネルのコードC++で書いて
失敗した。だから全部Cで書き直したよ

785 ：デフォルトの名無しさん：2009/07/04(土) 11:59:26

カーネルは複雑じゃないから OOP は必要ないだろうね

786 ：デフォルトの名無しさん：2009/07/04(土) 12:06:50

なぜそこにOOPをつっこもうとする

787 ：デフォルトの名無しさん：2009/07/04(土) 12:13:00

パフォーマンス問題がクリティカルな分野でOOPなんてやるわけねーだろ
そんなん言ったら大半の組み込みプログラムが非OOPだわ

788 ：デフォルトの名無しさん：2009/07/04(土) 12:13:19

>>782
嘘言うなよ
LinuxはVFS周りのコードがOOPだ

789 ：デフォルトの名無しさん：2009/07/04(土) 12:25:43

>>788
ソースみたけど全部Cで書いてあるけど？

790 ：デフォルトの名無しさん：2009/07/04(土) 12:27:16

>>789
CでのOOPに決まってるだろ

791 ：デフォルトの名無しさん：2009/07/04(土) 12:34:06

GObject…

792 ：デフォルトの名無しさん：2009/07/04(土) 12:40:47

>>790
CにOOPなんてねーだろ
バカなのアホなの？

793 ：デフォルトの名無しさん：2009/07/04(土) 12:52:43

お前本当に頭悪いな
GObjectが何か調べてから物を言えよカスが

794 ：デフォルトの名無しさん：2009/07/04(土) 12:58:34

>792
お前はまずOOPとは何かを学んだほうが良いぞ
OOPLはOOPをしやすくした言語であってOOPLじゃないとOOPができないワケじゃない

795 ：デフォルトの名無しさん：2009/07/04(土) 13:17:00

カーネルプログラミングでGObject(汗

796 ：デフォルトの名無しさん：2009/07/04(土) 13:27:35

じゃばばんばぁは言語にOOPがないとOOPができないとおもってるからなぁ

797 ：デフォルトの名無しさん：2009/07/04(土) 14:21:06

LinusがC++嫌ってるからしかたなくCで書いたんだろ

798 ：デフォルトの名無しさん：2009/07/04(土) 14:25:09

手動メソッドディスパッチ…

799 ：デフォルトの名無しさん：2009/07/04(土) 14:32:23

>>797
LinusがC++嫌いなのはその通りだけど、そんな簡単なものでもない。

http://www.tux.org/lkml/index.html#s15-3

800 ：デフォルトの名無しさん：2009/07/04(土) 14:38:58

LinusどころかOOPLユーザの過半数がC++を嫌っているという現実

801 ：デフォルトの名無しさん：2009/07/04(土) 14:41:08

C++は糞これはガチ

802 ：デフォルトの名無しさん：2009/07/04(土) 15:48:38

>>794
そう言って、Cでオブジェクト指向プログラミングができるって
テクニックを公開しているやつをなんども見てるけど、つかえそう
なのって、カプセル化、抽象データ型くらいで、継承とか多態
までいくと「おいおい、それはムリがあるだろ」って感じのばっかり
だな。

ああいうの真に受けるやつがいるから、広めるのやめてほしい。

803 ：デフォルトの名無しさん：2009/07/04(土) 15:55:45

C++ を糞だと思うのは自由だが、OOP と GP の直交が醸す広大な抽象空間を
知らずに人生を終えるのはちょっともったいないと思うよ。

804 ：デフォルトの名無しさん：2009/07/04(土) 15:56:37

多態なんて関数ポインタ使えれば誰でも考え付くこと。

805 ：デフォルトの名無しさん：2009/07/04(土) 16:03:17

>>803
GPって何？ゴールドポイント？

806 ：デフォルトの名無しさん：2009/07/04(土) 16:07:17

>805
グレートプログラム

807 ：デフォルトの名無しさん：2009/07/04(土) 16:23:57

>>803
C++ のジェネリックプログラミング:
アイデアは全部よその言語のパクリ, あの変態構文を除けば… … …

808 ：デフォルトの名無しさん：2009/07/04(土) 17:02:27

グランプリ

809 ：デフォルトの名無しさん：2009/07/04(土) 17:07:01

GenericProgramingをGPと略すのはどうなんだろう
GPといったら普通は遺伝的プログラミング(genetic programming)の方かと

810 ：デフォルトの名無しさん：2009/07/04(土) 17:09:08

Giant Penis

811 ：デフォルトの名無しさん：2009/07/04(土) 17:10:36

紛らわしいシリーズとしては
generative programmingってのもある

812 ：デフォルトの名無しさん：2009/07/04(土) 17:18:56

GP = Generic Programming のこと。C との互換性と GP によって、C++
は今後も戦力外通告されない「潰しの効く」言語の一つたりえる。Bjarne
Stroustrup は C++ の原作者として、プログラマが言語学習に投資した
時間を無駄にするような言語仕様の変更を加えないよう、絶妙のバランス
感覚で手綱をしめてる。C++ は次の改訂でさらに初心者にやさしい使い
やすい言語になるよ。

813 ：デフォルトの名無しさん：2009/07/04(土) 17:21:37

>>804
それは多態じゃなくて高階関数な。

814 ：デフォルトの名無しさん：2009/07/04(土) 17:27:26

OOと関係ない方向で性徴

815 ：デフォルトの名無しさん：2009/07/04(土) 17:38:06

Generic ProgrammingやりたきゃC++なんかよりSMLやHaskellのほうがずっといい。

816 ：デフォルトの名無しさん：2009/07/04(土) 17:48:03

scrap your boilerplate

817 ：デフォルトの名無しさん：2009/07/04(土) 18:43:29

C++は組み込み分野では利用禁止が定着しつつある
一般開発では既に利用禁止が大半となっている

818 ：デフォルトの名無しさん：2009/07/04(土) 18:47:51

ま、C++でまともにコードかけるやつがめったにいないしな。

819 ：デフォルトの名無しさん：2009/07/04(土) 20:19:45

>>817
w

820 ：デフォルトの名無しさん：2009/07/04(土) 20:21:23

まともにかける奴がいない = かける俺が偉い
というオナニーなんだろうが
lispに比べればはるかに多いだろ
lispが使われて無いのはかける奴がいないからに他ならないわけで

821 ：デフォルトの名無しさん：2009/07/04(土) 21:56:18

>>817
電子回路設計ではSystemCとかいうＣ言語の亜種が出てるのにな

822 ：デフォルトの名無しさん：2009/07/04(土) 22:04:31

組み込みの分野で使われてるのってluaとか？
あれも、オブジェクト指向はなしで、
関数型を取り入れたって感じだな

823 ：デフォルトの名無しさん：2009/07/04(土) 22:09:56

組み込みってハードに近いあれの話だろ？
Ｃ言語の変な仕様バージョンが圧倒的に多い
みためＣ言語だけどＣ言語仕様にはそってないの
なんちゃって？Ｃ言語？っての？

824 ：デフォルトの名無しさん：2009/07/04(土) 22:27:49

qsortの無いやつもあるしな

825 ：デフォルトの名無しさん：2009/07/04(土) 22:33:28

そもそも標準ライブラリなんてほとんど使わん

826 ：デフォルトの名無しさん：2009/07/04(土) 22:47:45

C++は、現実の問題に対処できるように何でもできる言語を目指しているが、
何でもできることで、かえって現実のプログラマの集団を
うまく統制できない言語になってしまった。
言語機能の一部を使用禁止する命令とか作ったほうがいいんじゃないか？

827 ：デフォルトの名無しさん：2009/07/04(土) 22:53:18

>>826
実際構文解析・チェックツール使って
スタイルに合ってないヤツを書き直させてる現場もあるよ

828 ：デフォルトの名無しさん：2009/07/04(土) 22:53:51

>>826
いやだからEUでC++0xの仕様採択中止になったしょ？
ほらEUだとソフトウェアのレベル計測する基準とかあるだろ
あれで軒並みC++は該当外になっている。

829 ：デフォルトの名無しさん：2009/07/04(土) 23:05:50

>>828
へーそうなんだ。ソースどこ?

830 ：デフォルトの名無しさん：2009/07/04(土) 23:36:50

脳内

831 ：デフォルトの名無しさん：2009/07/05(日) 00:03:58

オブジェクト指向のクソなところをまた一つ発見した。
予約語が増える。

832 ：デフォルトの名無しさん：2009/07/05(日) 00:57:59

SKI！！SKI！！

833 ：デフォルトの名無しさん：2009/07/05(日) 01:45:33

>823-824
こういう感じのやつ？
http://ja.wikipedia.org/wiki/フリースタンディング環境

834 ：デフォルトの名無しさん：2009/07/05(日) 06:51:21

>>831
SmalltalkよりもCのほうが桁違いに予約語が多いのだが？

835 ：デフォルトの名無しさん：2009/07/05(日) 07:03:12

SmalltalkはifTrueなんかも予約語じゃないのではなかったか？

836 ：デフォルトの名無しさん：2009/07/05(日) 07:10:35

ifTrueやwhileTrueもメソッド名だね < Smalltalk

837 ：デフォルトの名無しさん：2009/07/05(日) 07:54:31

予約語が増えるくらいどうということないじゃん。
もともとCやC++はオペレータの数が少ないんだし
Lispなんてオペレータが多すぎて訳ワカメやぞ。

838 ：デフォルトの名無しさん：2009/07/05(日) 07:57:05

釣り、、、だよな、、、、？

839 ：デフォルトの名無しさん：2009/07/05(日) 08:07:29

$から変数名はじめればいいだけ

840 ：デフォルトの名無しさん：2009/07/05(日) 11:19:32

予約語が多いというとCOBOLを思い浮かべるが…

841 ：デフォルトの名無しさん：2009/07/05(日) 11:33:29

エディタがハイライトしてくれるから、予約語の数なんて大した問題じゃないだろ

842 ：デフォルトの名無しさん：2009/07/05(日) 11:41:19

新しい概念なんだから予約語が増えるのは当然
似て非なる言語仕様が乱立するほうがよっぽど怖いぜ

843 ：デフォルトの名無しさん：2009/07/06(月) 00:44:35

２０，３０くらいの予約語ならいいが、
１００を超えるのはあほだろ。

844 ：デフォルトの名無しさん：2009/07/06(月) 00:59:21

予約語の数がどうの言う奴は馬鹿
それよりCのように名前空間が無い言語を使ってシンボル名が衝突する方が問題

845 ：デフォルトの名無しさん：2009/07/06(月) 02:52:55

COBOLは酷いよな…ライブラリまるごと予約語にするから予約語の数がおかしなことになってる

846 ：デフォルトの名無しさん：2009/07/06(月) 08:16:05

emacs lispは酷いよな…
hoge-moge-hage-sage-pとか
名前空間の力は偉大だよ

847 ：デフォルトの名無しさん：2009/07/06(月) 08:21:59

Cに名前空間がないって、なんだよ、その凄まじい釣りはwww

848 ：デフォルトの名無しさん：2009/07/06(月) 09:29:56

無いだろボケ。あるなら示せ。

849 ：デフォルトの名無しさん：2009/07/06(月) 10:00:05

まさか変数のスコープの話を持ち出すんじゃあるまいな？
staticに指定して翻訳単位でウンタラ～他のファイルからは見えなくなる～だの何だの。

850 ：デフォルトの名無しさん：2009/07/06(月) 10:08:30

名前空間が問題になるような状況ってそもそも命名規約ぐちゃぐちゃなのでは

851 ：デフォルトの名無しさん：2009/07/06(月) 10:17:52

一応、structのタグは別の名前空間（？）だな。

852 ：デフォルトの名無しさん：2009/07/06(月) 10:20:25

C++もC#も営業から見たらCなんだよｗ

853 ：デフォルトの名無しさん：2009/07/06(月) 10:22:02

その発想はなかった

854 ：デフォルトの名無しさん：2009/07/06(月) 11:02:07

>>851
でも struct tm tm; とか、一瞬「あれっ？」と思う。

855 ：デフォルトの名無しさん：2009/07/06(月) 14:13:29

>>848
名前空間があるから関数や変数に名前がつけれるんだろアホボケカス

856 ：デフォルトの名無しさん：2009/07/06(月) 14:41:05

最近>>855のようなキチガイが多いな

857 ：デフォルトの名無しさん：2009/07/06(月) 14:55:49

Cだとファイルごとに名前空間があるんでしたっけ

858 ：デフォルトの名無しさん：2009/07/06(月) 15:06:48

最低でも名前空間を1つは持っている言語が多い
もちろんBrainf*ckとか名前空間を持たない言語もある

859 ：デフォルトの名無しさん：2009/07/06(月) 15:13:49

それ翻訳単位…

860 ：デフォルトの名無しさん：2009/07/06(月) 15:15:16

じゃあ、ユーザー定義の木構造名前空間！

861 ：デフォルトの名無しさん：2009/07/06(月) 17:41:48

○ Cには名前空間はあります。
× Cでは名前空間は1st class objectです。

言語要素の有無と1st classかどうかを区別できないアフォが大杉。

862 ：デフォルトの名無しさん：2009/07/06(月) 17:47:38

ありません、それはスコープです

863 ：デフォルトの名無しさん：2009/07/06(月) 17:50:13

名前空間を変数に入れたり
名前空間を返す関数がかけたり
名前空間を合成した名前空間を作れたりすんの？

864 ：デフォルトの名無しさん：2009/07/06(月) 18:04:51

first class * なんて言葉が出てきたら揚げ足の取り合いになること必至だな(ｗ
これに属する要素はプログラム内部での使用に関する制約が
他の集まりに属する要素より少ないってことだけしか述べてないのに
「～はfirst class *だから～(ｷﾘｯ」とか、暗黙の了解が無ければ言えないよな
そんな前提を設けておきながら
「Cに名前空間が無いから云々」について文意を読み取らないで噛み付くなんてちゃんちゃらおかしいわ

865 ：デフォルトの名無しさん：2009/07/06(月) 18:08:25

>>862
スコープと名前空間の区別ができない子？

866 ：デフォルトの名無しさん：2009/07/06(月) 18:10:25

>>863
> 名前空間を変数に入れたり
> 名前空間を返す関数がかけたり

C ではともかく、Smalltalk とかでなら普通にできるだろ

867 ：デフォルトの名無しさん：2009/07/06(月) 18:14:29

emacs lispはfunction cellとvalue cellに分かれてるから複数の名前空間を持つことになる

868 ：デフォルトの名無しさん：2009/07/06(月) 18:17:37

>>863
Smalltalkだと、

> 名前空間を変数に入れたり
> 名前空間を返す関数がかけたり
> 名前空間を合成した名前空間を作れたりすんの？

どれも普通にできます。
st80ならSystemDictionaryクラスのインスタンスSmalltalk、
今のVisualWorksならNamespaceクラスのインスタンスが
名前空間のオブジェクトです。

869 ：デフォルトの名無しさん：2009/07/06(月) 18:18:56

名前空間なんて日本語使うから悪いんだろ
○Cにnamespaceという文法はありません。
○ウィキペディアの名前空間という項目でもCには無いと記述されています。

870 ：デフォルトの名無しさん：2009/07/06(月) 18:19:07

単一の名前空間を持つ ≠ 名前空間がない

871 ：デフォルトの名無しさん：2009/07/06(月) 18:21:54

構造体のタグの「名前空間」は変数の「名前空間」とは別、
というレベルの「名前空間」を持って、
「Cに名前空間がある」としてみせるのつまらんすぎ。脱力する。

872 ：デフォルトの名無しさん：2009/07/06(月) 18:23:20

馬鹿が揚げ足取りしてるだけ
普通に考えればCにはC++のnamespace相当のものが存在しないって分かるだろうが

873 ：デフォルトの名無しさん：2009/07/06(月) 18:25:20

「Cに名前空間があるお（キリッ」

初心者「へー」
中級者「アホか？」
上級者「いずれにせよくだらん」

874 ：デフォルトの名無しさん：2009/07/06(月) 18:35:16

言語理論的にはCはモジュール毎に名前空間を持つ。
シンボルテーブル上での名前解決のタイミングの問題。
もちろんスコープとは全く別の問題。

875 ：デフォルトの名無しさん：2009/07/06(月) 19:06:39

>>869
だからあれほどWikipediaがソースとか(ry

876 ：デフォルトの名無しさん：2009/07/06(月) 21:10:39

やっぱ、JavaScript最強ってことだな。

877 ：デフォルトの名無しさん：2009/07/07(火) 00:16:32

もともとおいらはWEBデザイナ。プログラマではありません。
いろいろあって、独学でなんとかActionScriptのオブジェクト指向を理解した。
でも独学の為か、長文のプログラムでカスタム（定義）クラスがちょっと多くなると、
ソースからプログラムの内容を把握することが難しくなって、困ってた。

「本職のプログラマの人ってすごいな！こんな長文ソースを簡単に読めて書くことも
できるんだろうなっ！」て思ってた。

で、本職プログラマの友人ができたので訊いたら、「ソースから内容は読む事はしないよ。
大体仕様書とか、クラス図とかみれば一発で、その内容を理解できる。」という。

それは、すごいなと思った。
クラス図ってなんだろ。調べてみると「UML」といわれるものみたい。

それで2ちゃんの皆さんに伺いたい。クラス図とか「UML」の習得方法について、
独学でできるものか？習得は難しいのか？
ちなみに「ActionScript」以外の言語は全く知識ありません。

どうぞ宜しくお願いします。

878 ：デフォルトの名無しさん：2009/07/07(火) 00:19:33

本職プログラマの友人に訊けよ

879 ：デフォルトの名無しさん：2009/07/07(火) 00:39:46

＞で、本職プログラマの友人ができたので訊いたら、「ソースから内容は読む事はしないよ。
＞大体仕様書とか、クラス図とかみれば一発で、その内容を理解できる。」という。

この時点ですげー偏った人間なのは間違いない

880 ：デフォルトの名無しさん：2009/07/07(火) 01:09:49

>「ソースから内容は読む事はしないよ。大体仕様書とか、クラス図とかみれば一発で、その内容を理解できる。」
笑うところですか？

881 ：デフォルトの名無しさん：2009/07/07(火) 01:13:38

>>877
その友人の言う事は話半分に聞いといた方がいい。

882 ：デフォルトの名無しさん：2009/07/07(火) 01:53:28

でも、実際。プログラムの大きさによるかも知れないけど。
大規模なプロジェクトの場合、ソースだけでプログラムの内容を
把握しているわけではないでしょ。
何か、フロー図とか。そのクラス図とか、図示できるもので把握
しているんでないんですか？

プログラムの全体構造を理解できる方法、整理できる方法があるのなら、
それを勉強したいと思ってます。

883 ：デフォルトの名無しさん：2009/07/07(火) 01:56:00

>>877
独学でしょ。
独学で習得できないのなら、いくら高い学校とかセミナー行っても無駄。

884 ：デフォルトの名無しさん：2009/07/07(火) 02:01:02

>>882
見るだけなら、決まりごとさえいくらか覚えてしまえば見て意味を理解するのは簡単。
ただ、図に記述されていること以上のことを知りたければソースコードや仕様書見るしかない。

885 ：デフォルトの名無しさん：2009/07/07(火) 02:11:56

>>882
大規模なプログラム＝長いプログラムではないのですよ
適切に分割して開発すれば、複雑さの爆発は防げるのです

886 ：デフォルトの名無しさん：2009/07/07(火) 02:13:02

ありがとうございます。独学で勉強することに決めました。
ActionScriptのUML教本は無いようなのでJavaの本で勉強します。
（JavaScriptの教本も無さそうだし。。）

887 ：デフォルトの名無しさん：2009/07/07(火) 02:17:26

885さん
ありがとうございます。
そのあたりの、プログラムの約束事を知らずに、ActionScriptを
独学してきたので、ちょっとつらいとこあります。

888 ：デフォルトの名無しさん：2009/07/07(火) 06:59:48

>>887
心配するな。苦労してマスターしたことは決して無駄にならない。

889 ：デフォルトの名無しさん：2009/07/07(火) 07:21:24

テラマトリクス2.0買えば
ソースなんて１００万ステップでも数時間で理解できるけどなｗ

890 ：デフォルトの名無しさん：2009/07/07(火) 08:23:53

>>889
宣伝乙

891 ：デフォルトの名無しさん：2009/07/07(火) 08:26:42

JavaScriptって高階関数の組み合わせでプログラミングすることも多いから
そんな場合のクラス図って役に立つんだろうか
てか関数プログラミングとクラス図ってみずとあぶら？

892 ：デフォルトの名無しさん：2009/07/07(火) 13:28:46

>>869
JIS X 3010 でも「名前空間」として
　・ラベル名
　・構造体、共用体、列挙体のタグ
　・構造体、共用体のメンバ
　・その他の識別子
が規定されているわけだが。

>>877
>独学でできるものか？習得は難しいのか？
言い訳はいいから先ずやれよ。

893 ：デフォルトの名無しさん：2009/07/07(火) 18:32:19

Cの規格書に、
7.3 Namespaces
とあるんだがなw

894 ：デフォルトの名無しさん：2009/07/07(火) 18:33:08

>>869
> ○ウィキペディアの名前空間という項目でもCには無いと記述されています。

プログラミング言語関係はレベルの低いものが多い。特に日本語。

895 ：デフォルトの名無しさん：2009/07/07(火) 18:35:09

なんつか、車の話してる時に自転車の話されて、
どっちも車両な訳だがと開き直られた気分。

896 ：デフォルトの名無しさん：2009/07/07(火) 18:48:36

そんなイマイチよくわからない喩えを持ち出されても。

897 ：デフォルトの名無しさん：2009/07/07(火) 19:15:44

Cにオブジェクトはある。

898 ：デフォルトの名無しさん：2009/07/07(火) 19:28:07

そうだね、K&Rの第一版もまずオブジェクトの定義から入ってるしね。
で？

899 ：デフォルトの名無しさん：2009/07/07(火) 21:25:05

メソッド（処理）主体のオブジェクト指向は糞。
データを扱う段階では全くその力を発揮できない。

データモデル主体の設計をなぜ出来ない！！！＞ばかちん！

900 ：デフォルトの名無しさん：2009/07/07(火) 22:46:58

対象間の関係の集合から対象が発生するのがabstract data type

901 ：デフォルトの名無しさん：2009/07/07(火) 22:57:43

これのことかね
手続きのみでデータ構造を定義
(define (cons x y)
(define (dispatch m)
(cond ((= m 0) x)
((= m 1) y)
(else "error")))
dispatch)
(define (car z) (z 0))
(define (cdr z) (z 1))
初めて見たときは目からウロコが漏れた

902 ：デフォルトの名無しさん：2009/07/07(火) 22:59:22

しばらく、オブジェクト指向の次はアスペクト指向で一儲けだ、って風潮だったけど、
ここのところは関数型（関数指向とは呼ばないよね？）が流行るよって空気だね。

MSがF#をリリースする事で何か流れが変わるんだろうか？

903 ：デフォルトの名無しさん：2009/07/07(火) 23:01:02

>>901
ウザ
上から下まで眺めないと構造がわからないってウンコじゃん

904 ：デフォルトの名無しさん：2009/07/07(火) 23:39:54

アスペクト指向とかマジイミフだな

905 ：デフォルトの名無しさん：2009/07/07(火) 23:40:03

たしかに、終始こんな感じで書かれたコードをメンテなんてしたくない

906 ：デフォルトの名無しさん：2009/07/07(火) 23:41:19

オブジェクト指向はもう古いこれからはアスペクト指向だ！とか言ってるのがいたな

907 ：デフォルトの名無しさん：2009/07/07(火) 23:59:42

>>906
言いたい奴には言わせとけ

908 ：デフォルトの名無しさん：2009/07/08(水) 07:17:29

このスレまだ続いてたのか

909 ：デフォルトの名無しさん：2009/07/08(水) 18:52:28

>>906
主に分析設計セミナー方面の人達ね。

910 ：デフォルトの名無しさん：2009/07/08(水) 18:57:53

>>909
そういう人達って今何をやってるんだろうか

911 ：デフォルトの名無しさん：2009/07/08(水) 19:10:28

古い技術に新しい名前を付けて売る
リサイクル事業なんだよ
元手なし

912 ：デフォルトの名無しさん：2009/07/08(水) 19:10:55

関数型でもやってるんじゃね？

913 ：デフォルトの名無しさん：2009/07/08(水) 19:22:29

これからはWeb2.0だ！
って言ってた人達と方向性は同じだな

914 ：デフォルトの名無しさん：2009/07/08(水) 19:22:45

ほぼ名指しじゃん、それw

915 ：デフォルトの名無しさん：2009/07/08(水) 19:26:22

俺はインターネット２．０でいくぜ

916 ：デフォルトの名無しさん：2009/07/08(水) 19:29:56

すでにあります
つインターネット２
ttp://e-words.jp/w/E382A4E383B3E382BFE383BCE3838DE38383E383882.html

917 ：デフォルトの名無しさん：2009/07/08(水) 19:42:56

じゃ、ザ・インターネット２で

918 ：デフォルトの名無しさん：2009/07/08(水) 20:51:29

ジ・・・ジジ

919 ：デフォルトの名無しさん：2009/07/08(水) 21:00:17

>>918
監督の強い希望って書いてあるだろ！

920 ：デフォルトの名無しさん：2009/07/09(木) 07:36:33

>>910
あの人達の不幸なのは、
自分達がOOブームをつくった、とか、
俺は良い技術を見分ける目を持っている、とか、
そういうカンチガイをしているところ。

921 ：デフォルトの名無しさん：2009/07/09(木) 09:37:22

未だにWeb2.0が何なのか俺知らないｗ

922 ：デフォルトの名無しさん：2009/07/09(木) 09:44:18

視力 2.0

923 ：デフォルトの名無しさん：2009/07/09(木) 10:25:09

2000以前主体だったHTMLを打っただけの日記と
昨今のコメント、トラックバック送信ができるBlogの違いみたいなものじゃね？

924 ：デフォルトの名無しさん：2009/07/09(木) 10:37:01

AJAX使ってれば2.0だみたいな感じじゃなかった？

925 ：デフォルトの名無しさん：2009/07/09(木) 10:55:26

情報発信のみがWeb1.0
対話がWeb2.0

簡単な話は、2chはWeb2.0

926 ：デフォルトの名無しさん：2009/07/09(木) 11:47:13

Perl で掲示板やチャット書いてた15年前から 2.0 ってことか。

927 ：デフォルトの名無しさん：2009/07/09(木) 12:51:01

メインコンテンツと掲示板、チャットが分かれてたのが
一緒になったのが2.0って事なんじゃね？
で、それを実現する技術がAJAXとかFlashみたいな

928 ：デフォルトの名無しさん：2009/07/09(木) 12:59:04

そーいやチャットて10年はやってないわ（メッセンジャー、スカイプ等除く）。

929 ：デフォルトの名無しさん：2009/07/09(木) 12:59:34

金になるんなら、バズワードだろうがなんだろうが構わないだろ。

930 ：デフォルトの名無しさん：2009/07/09(木) 13:58:24

むしろBuzzwordだからこそ金になる
はっきりとしない分、価値を付ける余地があるというわけだな

931 ：デフォルトの名無しさん：2009/07/09(木) 14:40:10

>>930
価値じゃなくて煙に巻くだろ

932 ：デフォルトの名無しさん：2009/07/09(木) 18:31:58

>>925
対話が2.0と言いつつ掲示板は1.0だと言われる不思議

933 ：デフォルトの名無しさん：2009/07/09(木) 18:41:10

サーバーがシリコンバレーにあればWeb2.0。
アジアの片隅にあるとWeb1.0。

934 ：デフォルトの名無しさん：2009/07/09(木) 18:45:12

じゃあWeb1.5だと？

935 ：デフォルトの名無しさん：2009/07/09(木) 19:20:09

>>933
2ちゃんはシリコンバレーにサーバーがあるから2.0なのか

936 ：デフォルトの名無しさん：2009/07/09(木) 19:21:58

自宅の誰かに乗っ取られてどこかを攻撃し続けているのはＷｅｂいくつでしょうか？

937 ：デフォルトの名無しさん：2009/07/09(木) 21:24:39

株式会社Web2.0とかに社名変更したとこいまどうなってんだろうな
ググル気もないのでどうでもいいですけどねｗ

938 ：デフォルトの名無しさん：2009/07/09(木) 21:42:18

解散してるよｗ

939 ：デフォルトの名無しさん：2009/07/09(木) 23:07:44

青いのぼり持った政党の人が
消費税もなくすしOOPもなくしてくれるって
確約してくれたよ

940 ：デフォルトの名無しさん：2009/07/11(土) 03:54:35

xmlのパースに失敗したswikiはウェブいくつ？

941 ：デフォルトの名無しさん：2009/07/11(土) 06:44:09

クラウドなんちゃらが普及していくと、
開発言語の世界はどういう影響を受けるんだろう。
とりあえずブラウザとの融和性の低いコンパイラ型の
言語は衰退かな？
難解で複雑なC++なんかが消えてくれるのは
いいことだと思う。

942 ：デフォルトの名無しさん：2009/07/11(土) 07:38:22

よくわかんねっけど
関数型言語ってのが使えるようになればかっこいいの？

943 ：デフォルトの名無しさん：2009/07/11(土) 07:52:38

クラウドなんちゃらで、これからはスクリプト言語の時代だとか言ってるアフォを見ると、
こいつらはクラウドのサーバサイドのOSまで全部スクリプト言語で書く気かと。

944 ：デフォルトの名無しさん：2009/07/11(土) 08:18:24

そうだよ^^

945 ：デフォルトの名無しさん：2009/07/11(土) 08:19:27

OO厨もスクリプト厨も同じ臭いを感じるな

946 ：デフォルトの名無しさん：2009/07/11(土) 08:22:06

関数型言語厨と形式的手法厨も忘れないでね！！

947 ：デフォルトの名無しさん：2009/07/11(土) 08:23:48

クラウドがもし本当に主流になったら、
重要なのはデータサーバ側だろ。

3つのメジャーなデータサーバが誕生する影には、
「着眼点はいいけど、たまたま流行しなかった」が30は存在する。
「残念な」データサーバは300を越える。
クラウドのクライアントサイドなんかより、こっちのサーバサイドのほうが
ずっと仕事量を稼げるのは言うまでもないw

948 ：デフォルトの名無しさん：2009/07/11(土) 11:14:15

クラウドが主流になってもスクリプト言語なんて主流にならないと思うよ。
javaみたいにVMの上でバイナリーが走るコンパイラ言語だと思う。
たぶんErlang...みたいな

949 ：デフォルトの名無しさん：2009/07/11(土) 11:23:47

だいたいスクリプト言語なんて単価さげられそうだよな

950 ：デフォルトの名無しさん：2009/07/11(土) 11:34:28

railsはゲットーだ！！

951 ：デフォルトの名無しさん：2009/07/11(土) 11:43:28

ABAPでクラウドできないなら
クラウドはやらないだろ

952 ：デフォルトの名無しさん：2009/07/11(土) 11:48:42

オジサンには居心地がよさそうなスレですね（笑い笑い）

953 ：デフォルトの名無しさん：2009/07/11(土) 12:40:38

スクリプトしか理解できないアホなユトリには、居心地わるいスレかもな(笑い笑い)