09/01/28 02:25:45
アイちゃんはそんな難しいこと気にしなくていいんだよ
3:デフォルトの名無しさん
09/01/28 02:31:09
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
4:デフォルトの名無しさん
09/01/28 02:35:14
また新しいオブジェクト指向が広がるだけだよ。
5:デフォルトの名無しさん
09/01/28 02:41:10
未来
6:デフォルトの名無しさん
09/01/28 02:54:54
オブイェクト指向
T-72神は偉大なり、オブイェークト！
7:デフォルトの名無しさん
09/01/28 03:29:08
>6
46サンチか88かそれが問題だ
8:デフォルトの名無しさん
09/01/28 03:32:46
Javaの先には何も見えない
9:デフォルトの名無しさん
09/01/28 03:35:28
>Javaの先には何も見えない
節穴じゃなかろうか？
10:デフォルトの名無しさん
09/01/28 06:07:28
空っぽのスパゲッティ
11:デフォルトの名無しさん
09/01/28 09:46:23
マジレスすると、Ｃ＋＋のようなマルチパラダイム言語
すべてをオブジェクト指向でやろうとするＪａｖａは気持ち悪すぎ
12:デフォルトの名無しさん
09/01/28 11:05:17
>>11
なんでもじゃないだろ
プリミティブな変数が残ってる時点でうんこ
13:デフォルトの名無しさん
09/01/28 15:09:17
じゃあ、Rubyがいいの？
14:デフォルトの名無しさん
09/01/29 16:34:49
このあたりでSmalltalk原理主義者とLisp原理主義者登場
15:デフォルトの名無しさん
09/01/29 20:35:26
細胞指向が登場します。
16:デフォルトの名無しさん
09/01/29 21:17:07
棟方志功
17:デフォルトの名無しさん
09/01/29 22:49:03
２１００年頃には人間指向プログラミング言語（NOPL）が台頭しはじめる。
これは当時普及していたC↑が仕様を拡大しすぎたため、
プログラミング言語にヒトへの優しさを取り戻すことを謳って提唱された。
端的にいえば、当時は高度な文脈判断能を持つコンパイラが完成していたため、
NOPL系言語では、かなり適当にプログラムを組んでも大丈夫である。
例：NOPL系の代表的な言語HUMANによるHello Worldプログラム
"hello, world.";
この１行だけである。includeもusingもclassもmainも要らない。
また、主要な「アプリケーション型」も始めから組み込まれており、
TextEditApp app;
これだけでワードパッドのようなアプリケーションは完成してしまう。
もちろん細かく仕様を設定することもできる。
18:デフォルトの名無しさん
09/01/30 05:02:34
オブジェクト指向でも不足で、もっと、というとこれかな
Equivalent transformation programming 等価変換型プログラミング
URLﾘﾝｸ(assam.cims.hokudai.ac.jp)
19:デフォルトの名無しさん
09/01/31 01:07:11
オブジェクト爪向
20:デフォルトの名無しさん
09/01/31 11:09:05
且つ分散型
21:デフォルトの名無しさん
09/01/31 15:47:20
至高のオブジェクト
22:デフォルトの名無しさん
09/02/06 21:39:49
JAVAはC++が使いにくすぎだから
使いやすいように整理しただけの言語
JAVAが凄いなら、C++はその2倍
23:デフォルトの名無しさん
09/02/07 01:36:52
ウェルベール指向(←多分だれもわからない)
24:デフォルトの名無しさん
09/02/07 08:11:12
>>17
ただのシェルスクリプトやん
25:デフォルトの名無しさん
09/02/08 00:05:33
オブジェクト指向なんて所詮一時的な暇つぶしに過ぎない。
小学生でも綺麗なコードを書ける指向が次の志向。
26:デフォルトの名無しさん
09/02/08 14:03:45
>>23
知ってるベル
とでも反応すればいいのか?
27:デフォルトの名無しさん
09/02/09 14:40:25
>>25
自分に解らないものは全部「汚い」で済ませるのか。
28:デフォルトの名無しさん
09/02/10 15:32:53
初恋指向
29:デフォルトの名無しさん
09/02/27 13:50:16
玄人指向
30:デフォルトの名無しさん
09/02/27 22:35:48
VBだったり
31:デフォルトの名無しさん
09/02/27 23:33:52
シコシコウ
32:デフォルトの名無しさん
09/02/28 18:48:56
あらゆる現場で開発本題そっちのけでオブジェクト指向にはまって
文明終了
33:デフォルトの名無しさん
09/03/04 17:17:31
オブジェクト指向
34:デフォルトの名無しさん
09/03/04 18:24:26
はい、ここまでエージェント指向無しｗ
アプリケーション型とかねーなｗｗ
35:デフォルトの名無しさん
09/03/04 18:36:25
うんこー
36:デフォルトの名無しさん
09/03/04 21:45:51
ここに「社会党」という、なんの役にも立たないオブジェクトがある。
管、ポッポ、オザワというプロキシオブジェクト(それぞれ憎み合ってる)を作って、
「社会党」オブジェクトを管理させ、全体としてラッピングして民主党の出来上がり。
自民党と同等のメソッドがあるように見えるが、
ほとんどのメソッドはNotImplementedException例外を送出する。
37:デフォルトの名無しさん
09/03/05 13:55:28
例外を出してくれるならいいが得体の知れてる外国籍の
特定団体にdelegateしかねないから実装は計画的に
38:デフォルトの名無しさん
09/03/05 21:19:13
Smalltalkの生みの親であるアラン・ケイの予測：
ハイレベルなコミュニケーションの３番目の、そして最も新しい方式は
オブザーバ言語である。メッセージ＝機能言語はデータ＝手続き方式から見れば
前進ではあるが、様々な機能面の関連は独立的であり分析的である。
しかし、多くの概念は非常に混交しており分析しようとすれば実質上、
霧消するするほどである。例えば２０世紀の物理学ではある現象とその状況に
同等の重要性を認めてる。これは状況が異なった観察者は違った風に
知覚するためである。
オブザーバ言語では、機能は互いにくっついて概念と概念とが対応する「視点」に
置き換えられる。例えば犬は、抽象的には「動物」として、分析的には「器官、
細胞、分子から成る存在」として、実用主義的には「子供の乗り物」として、
比喩的には「童話の中の人間的存在」として、そして前後関係を考えれば
「骨が芝生の材料となる過程」と見ることができる。オブザーバ言語は
開発段階にあるが、１９８０年代のコミュニケーション手段となるだろう。
ASCII, Vol.4, #3 March, 1980「特集：パーソナルコンピュータ」から引用
原題は "Microelectoronics and The Personel Computer" sep '77
39:デフォルトの名無しさん
09/03/07 12:58:28
今何年だよ
40:デフォルトの名無しさん
09/03/07 20:19:29
オブジェクト指向より棟方志功のほうが好き
41:デフォルトの名無しさん
09/03/08 01:09:53
劇団ひとり乙
42:デフォルトの名無しさん
09/03/13 23:39:00
憧れのアーキテクトに会いに行こうぜ
待ってる。
URLﾘﾝｸ(www.microsoft.com)
43:デフォルトの名無しさん
09/03/14 09:07:04
経済危機を脱する処方箋はすでに解っている。量的緩和だ。
なのに日銀はかたくなにその実行を拒否している何故か？
不況を脱出する政策もすでに解っている。給付金だ。（ただし額が足りない。今の100倍は必要。
それを毎年やることだ）
なのに国民にはきわめて評判が悪い。何故か？
今の日本（いや世界は）は生産力余りまくり。足りないのは需要。未来はIT化とロボット導入が
ますます進み、失業者は増加する。
金は、配ればよい。その裏付けとなる生産力はあるのだから。
なのに、「働かざる者食うべからず」「モラルハザードだ」という旧来の道徳・価値観が
これらの人類の次のステージを邪魔している。
この道徳教育は糞。これを推進すれば、未来の日本人は人類の中でもっとも割をくうだろう。
そして、予言しておく。アメリカは消費大国として復活する。
「人間は、労働から解放されつつあるし、そうあるべきだ」この新時代の真理に
気づくべきだ。
44:デフォルトの名無しさん
09/03/14 13:08:40
>>43
>不況を脱出する政策もすでに解っている。給付金だ。
>（ただし額が足りない。今の100倍は必要。それを毎年やることだ）
荒唐無稽にもほどがある
45:あぼーん
あぼーん
あぼーん
46:デフォルトの名無しさん
09/06/20 00:51:52
＿＿ ‐ ''"￣￣ ｀ﾞ' ..、
. | . ／ : : : : : : : : : : : : :.' ,
≠ ／ : : : : : : : : : : : : : : : : : ∨ﾞ＼
| _ｲ. ／: : : :/ ﾊ: :、: ､: : ､: : r‐┴| く
イ:/: /: /:/:Χ./ .}: 八:.|::!:.:.|: : ! :| .ﾉ
{:::{: /:|/ﾚ|ｨ心≧ |/ .ィﾅ什ﾉ: : Ｌ...ノｲ.､
. ／／|',::::（,| .ﾋ::ﾘﾞ. ′ 匕:::ﾘﾚ∨: : |＼冫
/／::ﾊ: : : : :', ::::::: ｀'-'ﾞ :: ﾊ:.: レｲ S（そんな）O（オカルト）A（ありえません）！
／ : ﾉ ∨: : : ﾍ __ :::::: ,≠ヽ',: : ::ﾄ、
,./: : : :/._,.-∨: ::＿丶 _ . イ ∨: :.!: ＼
. , '＞.-‐''二＞''.´＼ ,.二つ￣￣￣二＞. ',: :',: : : :＼
く く//__.ﾊ .i＼.ヾ{_:_: : :＿ : : :＿_ミ､__ ﾏ: :ヾ､: : ::ゝ
. ,' .＼ .{|::|─､U （/ﾞ .二⊃|ヽ＼ {:::::::|:|.､ ﾏ:..'., ヽ: : : : :＞ー - ､
{ .＼_.＞‐ " ￣￣ﾞ´!.: :: :.∨＼＼|:::::::|:}. ',. ',: :..'., × : : : : : : : : :ヾ
∨: : ├─.! ／ マ::::::┐::://::k.} ﾏ: :...'., ￣ ヾ´
. ∨: : ＼. |.Ｙ. ヾ.__{_/彡Χ ',: : : .'.,
. マ: : : :ー┤| ,' ∨ﾞ| ＼ ∨: : : :＼
＼＿ イ! | : ∨､ ＼ ' ,: : : : .:＼
∨.', }::::ヽ ∨ .＼: : : : ヾ
. ∨.' , / ,' ﾉ.::::::::.＼ :ﾉ ＼: : :::
47:デフォルトの名無しさん
09/06/30 16:03:22
>>44
いや案外荒唐無稽とも言えない
１）技術が進めば進むほど余剰生産が増える
２）金は労働の対価でしかない
この２つを仮定した場合、
技術の進歩＝余剰生産増加＝労働力が不要になる＝対価としての給与は下がる一方
こうなる
もちろん現実はこんな単純ではないが
（生産が余剰になれば会社が潰れて生産力が落ちるわけで･･･）
ひたすら生産し続ければいつまでも儲かり続ける時代は終わった、と言われれば確かにそうかもとは思う
48:デフォルトの名無しさん
09/07/09 01:10:35
派遣切り
49:デフォルトの名無しさん
09/07/18 00:14:27
Lispは良い言語だ。
なんだっけ、アスペクト志向とかのもあるんだっけ
Earlang見たいな分散型もはやるかもねー
サーバーも小さい奴を組み合わせるのが流行って
みたいだし
50:デフォルトの名無しさん
09/07/18 14:10:54
アスペクトって限られたヤツだけ使うべきだよな
あるメソッド呼んだ時に副作用ある処理が勝手に呼ばれたとか
ヘボが組むと結構悲惨な事態になる予感。
51:デフォルトの名無しさん
09/07/19 03:43:19
アスペクトって言うと難しく聞こえるけど、要はアスベストのこと
52:デフォルトの名無しさん
09/07/19 05:03:08
アスベスト渦がオブジェクトの世界にまで
広がっていたとは…
53:デフォルトの名無しさん
09/07/20 11:42:06
アスペクト指向でうまくいった例って、
セミナー屋のインチキ講師以外にあるのか？
54:デフォルトの名無しさん
09/07/20 11:44:22
アスペクト指向の元が腐ってると
55:デフォルトの名無しさん
09/07/20 11:45:03
えらいめにあうがアスペクト指向をありがたがるです
56:デフォルトの名無しさん
09/07/20 14:14:46
高度なツールほど、馬鹿には使いこなせない。
57:デフォルトの名無しさん
09/07/20 19:18:08
馬鹿が使うと
58:デフォルトの名無しさん
09/07/20 19:19:39
高度なツールほど、馬鹿でも使えるようになっている。
59:デフォルトの名無しさん
09/07/20 19:32:57
高度なツールほど、賢い奴には使いづらい
60:デフォルトの名無しさん
09/07/22 01:17:23
オブジェクト指向の先？今のトレンドだと、関数型じゃない？
61:デフォルトの名無しさん
09/07/22 07:07:26
ここ数年で関数型界隈で何か画期的な進展があったかというと、何もない。
単にヤマ師が「次は関数型の時代」とわめいているだけで、
中の人達は、みんなさめてるよ。
62:デフォルトの名無しさん
09/07/22 08:02:17
C#は関数型になりつつあるけど
63:デフォルトの名無しさん
09/07/22 08:19:17
それって何てF#？
64:デフォルトの名無しさん
09/07/22 19:19:04
何もないといえば何もないが
そもそもC言語のようなものがなぜ広まったかというと
65:デフォルトの名無しさん
09/07/22 19:24:05
なぜ広まったかというと
66:デフォルトの名無しさん
09/07/22 21:55:48
OSを記述するための…ってのが、なんかあれだったんじゃないの
Web用言語として売り出したphpとかも
あれだけどあれじゃないか
67:デフォルトの名無しさん
09/07/23 00:41:23
つまり共通項は何かに特化してるってこと
特定の分野をこなす最適解だと
半端な言語はいらねえってことだ
68:デフォルトの名無しさん
09/07/23 01:22:48
ｽﾚﾘﾝｸ(tech板)
69:デフォルトの名無しさん
09/07/24 18:05:00
>>67
しかしそうなると、作るソフトによっていちいち言語から覚えなければならなくなるのでつらい、と。
Cは軽くて高速に組めるので、いろいろ潰しがきくところが便利なので使われているだけだと思う。
ただ、規模が大きくなるとそのうち誰も保守できなくなるので、高速性より保守性優先なら
比較的コード量が少なくて保守しやすいオブジェクト言語が使われるということだと思う。
70:デフォルトの名無しさん
09/07/24 19:06:00
そこでメタ言語だろ。
71:デフォルトの名無しさん
09/07/25 01:45:04
マクロとかテンプレートとか
72:デフォルトの名無しさん
09/07/25 15:39:23
うちの会社に使用書からCOBOLを吐き出すツールがあるけど、
そのうち他の言語でも当たり前になるんだろうな。
(モックレベルじゃなくて即本番稼働できるレベル)
73:デフォルトの名無しさん
09/07/25 15:53:23
UMLからC++のクラス定義を吐き出すレベルじゃなくて
もっとすごいの？
74:デフォルトの名無しさん
09/07/25 16:52:45
だからモックじゃねなくて即本番稼動って書いてるだろ
75:デフォルトの名無しさん
09/07/25 18:47:25
>>72
てことはプログラマいらないってことだよね。
仕事で、作りたくもないプログラム組まされる苦労がなくなるのはいいことかも。
言語のことで悩まなくてもいいし,仕様変わってもすぐ対応できる。
つまりオブジェクト指向の次に来るのは「仕様書→ソースジェネレータ」てことか？
76:デフォルトの名無しさん
09/07/25 19:08:27
それ、なんて４ＧＬ？
77:デフォルトの名無しさん
09/07/25 19:56:20
>>75
既にそうなってるフレームワークはいくつかあるぞ
78:デフォルトの名無しさん
09/07/25 22:47:46
クラウドに決まってるだろ
そんなことも分からないから、日本のITプログラマは馬鹿にされるんだろ
79:デフォルトの名無しさん
09/07/25 23:09:02
sage も分からん馬鹿は黙ってろ
80:デフォルトの名無しさん
09/07/25 23:13:29
URLﾘﾝｸ(www.jma-net.go.jp)
81:デフォルトの名無しさん
09/07/25 23:52:18
コピペ君って馬鹿だな、まで読んだ。
82:デフォルトの名無しさん
09/07/26 15:36:24
クラウド（笑）
83:デフォルトの名無しさん
09/07/26 15:55:14
ITプログラマってｗ
84:デフォルトの名無しさん
09/07/26 16:43:21
/ / / / / / /
＿_,____
/. ／// |ヽヽ＼ / / /
^^^^^.|^^^^^^
. / / ∧__∧
( ´・ω・)∧∧
/ /⌒ ,つ⌒ヽ) // / /
(___ ( __)
"''"" "'゛''` '゛ ゛゜' ''' '' ''' ゜` ゛ ゜ ゛''`
もし、またメール送っても嫌いにならないでね。
85:デフォルトの名無しさん
09/07/27 23:04:36
ITプログラマってすげーぞおいｗ
86:デフォルトの名無しさん
09/07/29 21:48:05
よし、明日からは「俺はITプログラマだ」って言うよｗ
87:デフォルトの名無しさん
10/01/03 18:08:09
オブジェクト指向を理解するのならば、
下記が良書だな
↓
URLﾘﾝｸ(www.amazon.co.jp)
88:デフォルトの名無しさん
10/01/03 19:45:46
エクセルのマクロみたいに、やりたいことを行動で教えるプログラミングが好き。
ソースが見えるから修正も楽だし。
89:デフォルトの名無しさん
10/01/03 21:52:21
>>88
そんなあなたにwsh
90:デフォルトの名無しさん
10/01/06 22:41:20
>>87
今さらオブジェクト指向を学ぶなんて歴史的価値しかないけどな
はじめからλ計算をベースにしておけばよかったものを、
人類は無知のために横道にそれた時期がありました、という歴史
91:デフォルトの名無しさん
10/01/07 15:51:55
ITプログラマ吹いた
なんでこんなのがム板に紛れ込んでるんだろ
92:デフォルトの名無しさん
10/01/07 15:57:13
>>90
それじゃあまるでOOPとλ計算が同じ用途で、排他的な関係みたいじゃない
両者は全く別物であって、排他的でも何でもないんだが
93:デフォルトの名無しさん
10/01/07 16:54:47
>>90
まったくもってその通りだな。
ラムダ計算をモデルとする関数型言語が近代的な構文を備えるようになったのは、
KRCやMirandaあたりの80年代から。そして言語の進化が続き、
今ではHaskellやOCamlが普通のプログラマに注目されるまでに成長した。
もしLISPが発表されていた70年代に、LISPのS式のような原始的な構文ではなく、
現在の関数型言語のような近代的な構文を備えた言語が発表されていたのなら、
プログラミングに関する人類の回り道は存在しなかったはずだ。
進化を阻害したすべての原因は、当時の関数型言語研究者の怠慢さにあり、
しかもLISPで満足して自画自賛していたLispプログラマの見識の低さにある。
もし彼らに真摯な姿勢があったのなら、今頃オブジェクト指向は遺物になっていた。
94:デフォルトの名無しさん
10/01/07 17:31:15
>>93
そうなったらきっと、モダンな構文のCLOSが誕生したんだろうな。それだけ。
95:デフォルトの名無しさん
10/01/07 19:06:33
Dylanはなかったことですかそうですか。
96:デフォルトの名無しさん
10/01/08 00:45:53
オブジェクト指向の言語なんて所詮、
なんかこうしたらうまくいくかも
っていうフィーリングで作られてる
しかも未だにオブジェクト指向とは何かみたいな馬鹿げた議論をしている
一方ラムダ計算をモデルとする言語は、
その表現能力や自動化の限界、最適化の手法まで
全て理詰めで議論されて深まっている
この差は歴然www
97:デフォルトの名無しさん
10/01/08 01:13:34
Ｃ言語が最高傑作だな
Ｃ＋＋はただの改悪で終わった希ガス
導入したもんがすべて～かもしれない～っぽくね？の域を出られないとか
ホント落ちたもんだよな＞言語開発者
98:デフォルトの名無しさん
10/01/08 01:45:30
C言語→NULLあり、破壊的代入のみ、キャストあり、ガベコレ無し
どこがどう最高傑作？
99:デフォルトの名無しさん
10/01/08 01:50:20
そうだ、忘れてた、多相型すらないわ＞C言語
100:デフォルトの名無しさん
10/01/08 05:15:03
オブジェクト指向は構造化されたスパゲッティ
101:デフォルトの名無しさん
10/01/08 05:43:34
>>96
>しかも未だにオブジェクト指向とは何かみたいな馬鹿げた議論をしている
馬鹿げた、っつーか、未だに理解できてない馬鹿だからこそ
議論 (の余地なんかないが) してるだけ。
102:デフォルトの名無しさん
10/01/08 07:05:54
という議論が繰り返されるわりには誰もメリットいえないよね？
メリットっぽいのだしてもそれが本当にメリットかどうか判断できない内容ばっかり
103:デフォルトの名無しさん
10/01/08 07:56:56
君自身が判断できないってだけじゃないのか？
104:デフォルトの名無しさん
10/01/08 08:04:38
OOみたいな古典をいまだに最先端だと思いこんでる奴も少なくないのが現実
105:デフォルトの名無しさん
10/01/08 09:29:56
>>98
はガベコレ環境であるがゆえの悩みを持ったことがないんだろう。
GCを働かせたくないから、ヒープを使わないように書き換えていくような作業を。
106:デフォルトの名無しさん
10/01/08 09:43:24
オブジェクト指向プログラミングを理解できてる奴なんていないよ
107:デフォルトの名無しさん
10/01/08 09:52:43
誰も彼もがオブジェクト指向とは何か、という事を適当に書き散らしてるからか
最近ゲシュタルト崩壊気味になってきた
結局オブジェクト指向ってなんなんだ・・・
108:デフォルトの名無しさん
10/01/08 11:15:19
>>98
C言語は高級言語とアセンブリの中間の言語としてはかなりのものだと思う
アセンブリや高級言語として見ると非力な感じはするけどな
C++はもうちょっと煮詰めれば良かったんだろうがな…
109:93
10/01/08 13:08:07
>>94
CLOSというのはCommon Lisp Object Systemのことかな？
もしそうであれば、「モダンな構文のCLOSが誕生」することはありえない。
S式を捨てたLISPは、LISPと呼べるのか？否である。
従って「モダンな構文のCLOS」は日本語として矛盾している。
近代的な(モダンな)構文を持つ関数型言語の研究が、
S式の否定から始まったことを忘れてはならない。
>>95
Dylanに思い入れがあるのなら、過去にDylanが他の言語へ与えた影響、
あるいは(オブジェクト指向を含む)未来の言語に与えると予測される影響を
大いに語って欲しい。Dylanは名前しか知らないから、それを聞きたい。
110:デフォルトの名無しさん
10/01/08 22:28:40
>>105
どんな状況になったら、そんな苦行をしなきゃいけなくなるの？
単純に興味深いわ
111:デフォルトの名無しさん
10/01/09 00:22:28
オブジェクト指向よりか関数型だとか言ってる奴がいるが、
そのトレンドの変化は単純にここ数年の計算機の適用領域が変わってるだけなんだよ。
今までは、計算ロジックにリッチなGUIを付ける事が主眼だったからオブジェクト指向のパラダイムが最も重要視された。
今は、GUIよりもそのバックでの文字列処理・大規模分散処理が大きな課題となっているから関数型言語が注目されているだけ。
これからは、大規模分散のバックエンドはいくつかの巨大資本がクラウド上で提供されるようになって、
その他の領域では再びリッチクライアントへの回帰が進むと思う。（というか、並行して進むかな）
そうなると俺は、再び関数型言語の理解よりもオブジェクト指向への理解を求められる時代になるのではないかと思うぜ。
112:デフォルトの名無しさん
10/01/09 00:32:44
いまだにオブジェクト指向とか言ってるやつが化石に見えるのは俺だけだろうか・・・ｗ
これからは関数型言語だ！とか言ってるやつが原始人に見えるのは俺だけだろうか・・・ｗ
113:111
10/01/09 01:54:33
>>112
実際どちらも素養レベルであって、それより上位の問題を検討するときに選択する低レイヤの道具でしかない。
けど、俺はお前みたいに上から目線で見下ろすだけで満足するって言う考えにはいきつかないなぁ。
お前がオブジェクト指向や関数型言語を既に通過したとして、
その次に出てくる問題が何でそれに対してどういう見識を抱えているかって言うのを
示さないまま優越感に浸ったって、何の意味もない。
114:デフォルトの名無しさん
10/01/09 02:26:01
>>111
いいところ突いてると思うけど、実はGUIも関数型言語が牽引していく
そもそもオブジェクト指向の言語でGUI作ろうってのが
間違ってるんだよ
あんな破壊的状態変化を管理しろってのが無理難題
functional styleでGUI作る利点に早く気づくといいよ
115:デフォルトの名無しさん
10/01/09 02:53:55
>>109
DylanはＳ式抜きのCLOSだよ。
116:デフォルトの名無しさん
10/01/09 04:52:05
>>114
> あんな破壊的状態変化を管理しろってのが無理難題
> functional styleでGUI作る利点に早く気づくといいよ
GUIをつくれば状態変化を管理する必要がある。
手続型でもOOでもFPでも、それは変わりない。
ただ、管理する方法が変わるだけ。
手続型なら手続で。OOならばオブジェクトの情報隠蔽で。
FPならばMonadやUnique typeなどで。
117:デフォルトの名無しさん
10/01/09 08:56:27
しかしFRPはまだ発展途上
118:デフォルトの名無しさん
10/01/09 09:36:42
>>110
C#で60FPSのゲーム。
GCが動くと性能がガタ落ちするので、
スタックオブジェクトを効率的に使っていく必要がある。
119:デフォルトの名無しさん
10/01/09 10:43:54
>>113
だって、オブジェクト指向のオブジェクトってぜんぜんオブジェクト的じゃないじゃん。
あるオブジェクトを見ているとき、別のオブジェクトは時間が止まったみたいになってるし。
120:デフォルトの名無しさん
10/01/09 13:39:14
>>118
60FPSのゲームをC#で！
逆にGCを必死で抑えると60FPSが実現できるんだ
そっちの方が驚き
お疲れさまです
121:デフォルトの名無しさん
10/01/09 13:43:31
>>116
>ただ、管理する方法が変わるだけ。
そう、ただ管理する方法が変わるだけ
その方法が変わることによって、
人間がかけなければならない手間と注意の量はずいぶん変わるけどね
122:デフォルトの名無しさん
10/01/09 21:01:43
>>121
そのうえで、オブジェクト指向より関数型を推す理由ある？
俺はGUIはオブジェクト指向で考えたほうがわかりやすいと思ってるんだが。
関数型はGUIに向かん。
123:デフォルトの名無しさん
10/01/09 21:50:52
>>122
わかりやすいところで言えば、
F#で採用されるfirst class composable eventsとかは
イベントとイベントを合成してfunctionalに新しいイベントを作る優れた手法
.NET用のRxライブラリもそんな感じ
こういうコンビネーター的な考え方は関数型ならでは
元々FRPの一部だしね
もしかしてfirst class composable eventsも知らずに
関数型はGUIに向かないとか言ってる訳じゃないよね？
124:デフォルトの名無しさん
10/01/09 21:54:47
RxはC#で使えるでしょ
関数型ならではというのはおかしいんじゃない
125:デフォルトの名無しさん
10/01/09 22:14:23
どうでもいいけど、なんで「指向」と「型」を比較してんの？
126:122
10/01/09 22:28:23
>>123
一応、何かそんな話はどっかのページかスレで見たけど、GUIでイベント合成すると何がうれしいのか俺の脳では分からなかった。
使いどころがほとんど無いような事が関数型のみで出来てもあんまり意味ないっしょ？
(つーか>>124の言うには関数型ならではのものでもないらしいが)
>>125
わからん。とにかく、マルチパラダイムを認めず、二つのパラダイムを比較しているのがこのスレの流れだと思ったからこう書いた。
関数型とオブジェクト指向が対になる言葉じゃないって言うのは俺も感じていたが関数指向なんて言葉も無いし、どう表現していいか分からなかった。
127:デフォルトの名無しさん
10/01/09 22:31:33
たぶん誤解している人もいるかもしれないので補足しておくと
関数型の言語
ではなくて
関数と型理論の言語
という意味なんでよろしく
128:デフォルトの名無しさん
10/01/09 22:47:01
>>122
変わらないだろ
クラスは構造体と違ってインスタンスのコピーが気軽にできないだけ不便になったってのならあるけどな
129:デフォルトの名無しさん
10/01/09 23:04:53
関数型の簡潔なアルゴリズム表記はいいよね
オブジェクト指向言語の機能モジュールを持ち運べるって感じもいい
要するにクラスの中身を関数型風に記述できるような言語がいいかなって感じ
でまあ、ある程度のユーザー持ってる大方の言語はだいたいそんな感じに進んでると思えるので無問題
130:デフォルトの名無しさん
10/01/09 23:18:53
>>126
>一応、何かそんな話はどっかのページかスレで見たけど、GUIでイベント合成すると何がうれしいのか俺の脳では分からなかった。
なんとも残念な感じ
例えばこれのイントロとか読むと分かり易いんだが
www.cs.brown.edu/~greg/thesis.pdf
131:デフォルトの名無しさん
10/01/09 23:31:24
ああ・・・一般人＋αレベルの2chのム板の「オブジェクト指向の先には一体何があるんですか？」
なんていうタイトルのスレに英語の論文晒してもまじめに読む奴がいるわけないのは
常識的にわかるだろうに・・・
英語なんて生活の一部だぜかっこいいだろ、とか
英語の論文晒しとけば反論できないだろ、とか
晒し主の心情がわかる今日この頃ですが・・・
ここは日本語でおｋと返すのが2ch流ですかね
132:デフォルトの名無しさん
10/01/09 23:43:41
>>131
日本語だとあんまり無いのよね
URLﾘﾝｸ(igeta.cocolog-nifty.com)
133:デフォルトの名無しさん
10/01/09 23:54:32
イベントキューの上のレイヤーにリアクティブな高階関数のセットを提供
イベントキューを遅延評価のリストに見立てるとリスト処理のボキャブラリがそのまま使えて便利です
宣言的な記述がやっぱいいです
という話なのかな
結構いいかも
134:デフォルトの名無しさん
10/01/10 00:19:59
仮に関数型言語でGUIを扱うのがオブジェクト指向より便利だとするなら、
なぜ関数型言語界隈でオブジェクト指向ＧＵＩライブラリラッパーがまかり通っているんだ。
135:デフォルトの名無しさん
10/01/10 00:22:46
流行だろ
136:デフォルトの名無しさん
10/01/10 00:37:06
オブジェクト指向の代替として今注目されているのがプロセス指向だろ。
137:デフォルトの名無しさん
10/01/10 00:41:55
今？注目されてるの？どこで？
138:126
10/01/10 00:46:38
>>130
んー、英語の方も日本語の方も読んでみた。
便利＆考えることが減る気もするけど、そうでもない気もする。
情報を永続化するタイプのアプリケーションや、
ボタン押したら無意味に派手なアニメーションをさせるようなGUI(Appleみたいな)と相性が悪い気がする。
気がするだけで、どう相性が悪いのかは俺もはっきりしない。明確な反論じゃなくてすまん。
139:デフォルトの名無しさん
10/01/10 06:14:26
手続き型言語でジェネリックプログラミングしてるなら非純粋関数型言語は
単にジェネリックな実装を簡潔に記述できるという程度の認識でいい気がする
C++でbindとか使いまくってるなら大差ない。
純粋関数型言語はまだよく分かってない
140:デフォルトの名無しさん
10/01/10 07:24:42
だから両方同時に使えば良いじゃない
141:デフォルトの名無しさん
10/01/10 07:32:37
イベント合成できるのは関数型だけと思ってる能天気…
142:デフォルトの名無しさん
10/01/10 07:34:31
そもそもイベント駆動とGUIは本来別々だっての。
イベント処理の記述や合成が簡単にできるということと、
GUIを容易に構成できるということは全然別問題だろ。
143:デフォルトの名無しさん
10/01/10 07:49:23
>>138
>ボタン押したら無意味に派手なアニメーションをさせるようなGUI(Appleみたいな)と相性が悪い気がする。
functional reactive animationでぐぐってみるといいよ
144:デフォルトの名無しさん
10/01/10 07:52:26
SmalltalkやXのイベント駆動がアタリすぎて、
今だにGUI＝イベント処理という妄想がまかり通ってるらしい。
しまいには、イベント処理さえできればGUIは全てＯＫとか
あまりにもイタい主張をする人間が現われる始末。
145:デフォルトの名無しさん
10/01/10 08:00:12
>>144
誰がそんな主張をしてるの？何番のレス？
146:デフォルトの名無しさん
10/01/10 08:06:45
ゴネたところで、
GUIに一番向いているのは関数型だという根拠として
イベント処理しか出てきていないということは、
イベント処理さえできればGUIは全てＯＫという前提だろ。
147:デフォルトの名無しさん
10/01/10 08:35:30
>>131
自分の言葉で説明できない奴はどの世界にいても絶対に認められることはないよね
それがどんなに正しい主張をしていようとも絶対だ
148:デフォルトの名無しさん
10/01/10 09:06:19
上っ面でしか説明できないならマ板でやればいいと思うんだ。
149:デフォルトの名無しさん
10/01/10 11:41:12
関数型言語はGUI処理を美しく記述できる、という主張を
「自分の言葉」で表現している日本語のblogがあったので紹介。
2006年という古い記事であり、blog主さんの興味が他へ移ってしまったのか、
その後の記事が見つけられなかったのが、とっても残念なところ。
・2006.03.13: [funcgui] GUIで学ぶ関数プログラミングで学ぶGUIアプリケーション
URLﾘﾝｸ(d.hatena.ne.jp)
・2006.03.14: [funcgui] 続き
URLﾘﾝｸ(d.hatena.ne.jp)
・2006.03.15: [funcgui] イベント再考
URLﾘﾝｸ(d.hatena.ne.jp)
150:デフォルトの名無しさん
10/01/10 11:51:08
GUIで一番大切なのはペタペタがやりやすいかどうかだろｗｗｗｗ
151:デフォルトの名無しさん
10/01/10 13:20:59
関数型言語でも線分や四角形が簡単に書けるから、
GUIに最適な言語は関数型だと？
馬鹿も休み休みに言え。
そういうくだらん強弁を張るから孤立するんだYO！
152:デフォルトの名無しさん
10/01/10 22:34:49
つうか画面表示自体が、関数型の考え方でいくと副作用だろ。
その時点で副作用ガンガン使うGUIみたいなアプリを関数型の方が扱いやすいって主張は受け入れがたいんだよ。
153:デフォルトの名無しさん
10/01/11 02:11:22
は？意味わかんね
結局落ちてきたメッセージをどう処理するかでしかないのに
わざわざクラスにしておく必要を感じない
微妙なことやると確実にメッセージ飛ばしたりガメたりもう画面単位でどうせ完結できないのに
無理やりクラスにしたところで意味が感じられない
154:デフォルトの名無しさん
10/01/11 07:15:41
結局、関数型でGUIをつくるのが簡単だと言ってる人は、
自分ではGUI部品やCGライブラリをつくらずに、
ただ単にイベント処理をつなげるだけでGUIをつくったつもり
になっている人でしかないということ。
HaskellにもGUI toolkitあるけど、ライブラリのソースは
関数型として美しいとは到底言えないシロモノ。
155:デフォルトの名無しさん
10/01/11 12:24:22
現実、win32apiをはじめとしてほとんどメッセージの受け渡しで動いてる限りそんなもんじゃね？
156:デフォルトの名無しさん
10/01/11 12:32:16
土方にとっては、そんなもんだろうな。
157:デフォルトの名無しさん
10/01/11 15:00:34
FRP系の応用の中でもCall By Valueな言語で語られているFrTimeの考え方を理解できれば、
関数型言語でGUIというのが身近に感じられるかなと思うのだが、
急には難しいですね
FrTimeの日本語の解説は、これくらいかなぁ
URLﾘﾝｸ(d.hatena.ne.jp)
あとはJavaScriptでFRP的なFlapjax
URLﾘﾝｸ(www.flapjax-lang.org)
Web系の人は参考になると思うよ
158:デフォルトの名無しさん
10/01/11 22:38:54
すごいすごい
よくまとまった記事がアップされてる
URLﾘﾝｸ(d.hatena.ne.jp)
これを読むといいと思う
159:デフォルトの名無しさん
10/01/12 00:30:00
>>157
自分の言葉で説明する気がねーならわざわざレスするなよクズ
160:デフォルトの名無しさん
10/01/12 00:32:58
>>159
俺は157ではないが、自分の言葉で説明したら1000レス楽勝で埋まると思うが。
161:デフォルトの名無しさん
10/01/12 00:35:43
俺らが知りたいのは名無しの誰かさんの有能さを証明することじゃなくて、
新しい技術への知識だろ。
履き違えるな。
162:デフォルトの名無しさん
10/01/12 00:54:21
勝手に俺らって括るなよ
俺は名無しの誰かさんの有能さを証明することなんだよ
163:デフォルトの名無しさん
10/01/12 00:57:29
>>162
だったらスレ違いだ。
マ板に池。
164:デフォルトの名無しさん
10/01/12 01:03:43
関数型は型にはまった事以外をやるとしんどい
まるで書き方を強制されてる気分になる
オ略向は酒飲んでても組める
165:デフォルトの名無しさん
10/01/12 01:04:40
>>160
許可する
1000レス埋めてくれ
166:デフォルトの名無しさん
10/01/12 01:20:34
結局マルチパラダイム言語Lisp最強という結論に・・・
167:157
10/01/12 01:29:58
>>159
自分の言葉かぁ
私が2chに書きちらすより、リンク先を読む方が100倍分かり易くてためになるとおもうけど？
万一参考になるなら読んでくだされ
えっと、GUIの特徴というと、
「イベントがあがったら、あれこれをする」という連鎖や
「ここがこーなったら、あっちがこーなる」という依存関係が
複雑に絡み合っている点が挙げられます
このような仕組みは、抽象的に考えると、
依存関係がグラフ構造を成しており、そこをデータが流れるように見えるので、
Dataflow Programmingなどとも言われます
極端に言うと、この依存関係をfunctionalに（そしてDynamicに）記述することで、
GUIを書こうという方向性が関数型言語界隈にはあり、
それが結構成功しつつある訳です
(続く?)
168:デフォルトの名無しさん
10/01/12 01:32:42
>>167
まず何を言いたいのか結論からかけよ
それで詳細をたずねられたらはじめて詳細を答えるように練習しろ
そんなに長い文章になること事態おかしいんだよ
169:デフォルトの名無しさん
10/01/12 01:35:03
人と話さないでひきこもって独りよがりなプログラムばっかり組んでるから
掲示板のレスもそうやって聞き手を意識できない
この下手糞が
170:デフォルトの名無しさん
10/01/12 01:43:24
>>167
判りやすいから続けてくれ。
168-9みたいな中身スカスカは無視してよし。
171:デフォルトの名無しさん
10/01/12 01:52:09
>>159で
>自分の言葉で説明する気がねーならわざわざレスするなよクズ
自分の言葉による説明を求めているのに
>>168で
説明は要らん。結論だけ言え
とかどうすりゃいいのｗ
172:157
10/01/12 02:05:30
結論から言うと、FRPの仕組みを使えば、関数型言語でもGUIは綺麗にかけますし、
今まで以上に簡単になります
例えば、イベントの連鎖をfunctionalに書こうとすると、
イベントからイベントを生成したり、
複数のイベントを組み合わせて新しいイベントを生成する書き方になります
ボタン1とボタン2のどちらかがクリックされたイベントはこう書けます
(define b1-or-b2
(merge-e b1-click b2-click))
そして、そのイベントが挙がった回数を数えるのはこうです
(define click-count
(accum-b (map-e add-one b1-or-b2) 0))
このような仕組は、所謂コールバックの代わりになるものです
また、click-countという値には、
明示的にset!といった破壊的代入を利用せずとも
常にクリックされた回数が入り込みます
（続く?）
173:157
10/01/12 02:20:11
このような依存関係の値(behaviorとかsignalとか呼ばれます）の面白い応用として、
"マウスの現在座標を数秒遅れて追随するアニメーション"が簡単に実現できるデモもあります
URLﾘﾝｸ(www.flapjax-lang.org)
(javascriptなのですぐ見れます)
このようなイベントの連鎖や依存関係の記述は、上っ面だけではありません
コンポーネントの描画属性、フォーカス、レイアウト、可視性
GUIツールキット自体にあれこれの依存関係が満載で、
FrTimeは実際にこれらをFRPの枠組で実装しています
(続く?)
174:157
10/01/12 02:36:06
残念ながらFRPの仕組みと利用方法は今現在あまり普及していませんが、
Microsoftがかなり強力に.NETの世界へこれらを導入しようとしていますし、
WebUIの世界にも進出しつつあるので、
一般的になってくるのも時間の問題かと思われます
えっと、他に書くことあったっけ？
質問あったらどぞ
175:157
10/01/12 02:51:30
少し詳細に踏み込むと、FRPでは入れ子や高階の関係も同様に扱える点が興味深いです
behaviorから別のbehaviorを入れ子に作り続けるbind(monadのbindですね)
behaviorをeventによって別のbehaviorに切替えるswitch
eventのeventをフラットなeventにマージするjoin
これらがあれば、動的な依存関係の組み替えが可能な訳です
176:デフォルトの名無しさん
10/01/12 03:28:13
よく判ってないけど、副作用が起きるのは諦めて、
入力を入れ替え続けると解釈することで矛盾の無い形で
実現してみましたって感じ？
CPSで関数が戻らないことを利用して関数の引数を更新し続けるような。
177:157
10/01/12 03:51:47
>>176
内部実装の話でしょうかね
純粋関数型言語ではそんな感じで、新しい値を次々と持ち回っています
イベントループの度に新しい値を生成するので、
アプリケーション全体では副作用は無くなります（描画は別）
純粋でない言語では、内部実装的には破壊的代入しちゃってる例が多いですね
178:デフォルトの名無しさん
10/01/12 06:26:25
>>172
>結論から言うと、FRPの仕組みを使えば、関数型言語でもGUIは綺麗にかけますし、
>今まで以上に簡単になります
はい、しゃべりすぎはじめの２行から君の話って意味ないんです
聞いておくけどFRPとかいうのを使わなかったら関数型言語だとGUIは綺麗にかけないっていってるのね？
179:デフォルトの名無しさん
10/01/12 09:34:44
俺からみるとあんまりGUI関係ないんだよね。FRPの仕組みの利点も。
画面描画がGUIの難しさの一番だろ。
抽象化しすぎると全然パフォーマンスが出なくて、
ある程度下のレイヤでゴリゴリ書かないと実用にならないっていう事が
いつまでたってもなくならない。
結局、どっちらもGUIに対して銀の弾丸にならない事だけは知っておかないとね。
（役に立つ事は認めつつも
180:デフォルトの名無しさん
10/01/14 01:01:56
オブジェクト指向の先には関数型言語があるでFA?
181:デフォルトの名無しさん
10/01/14 09:29:54
どうしてそれがFAになるんだ。
関数型言語で有用だと分かった技法が既存言語に取り入れられていくって
形になりそうだから、依然メインはオブジェクト指向なのかなぁと俺は感じた。
182:デフォルトの名無しさん
10/01/14 12:27:27
先の先の先は自然言語だけどね。その手前に論理型が来るのかな。
183:デフォルトの名無しさん
10/01/14 16:32:49
>>1
マイクで、ハローコンピュータとか言うと
勝手にプログラムしてくれるようになるんじゃなかったのか？
ソースはスタートレック。
184:デフォルトの名無しさん
10/01/14 16:46:36
んなもん少なくとも俺らが生きているうちは無理だろ
次元が違いすぎる
185:デフォルトの名無しさん
10/01/14 16:50:24
最近のグーグルとか見ていると
結構、言葉の解釈はしているじゃん。
中の人はあと10年位したら、ベストな検索結果を１つだけ生成したいと
言っている。
セマンティックウェブって奴？
パソコン君が意味を理解したら、次はどういう手続きでそれが実現するかを
考えられるんじゃねーの。
そうなったらプログラミングもしだすと思う。
186:デフォルトの名無しさん
10/01/14 16:56:23
意味と意図は別でしょ。
人間同士のコミュニケーションだって中々うまくいかないから、わざわざチーム内の規定や規則など作って曖昧さを無くそうと必死なのに、
話しかけるだけでコンピュータがやりたいことを理解してくれるとか無理だろ。
脳波でコントロールする入出力装置ができて、思うままに動かせるようになるって方が早いと思う。
187:デフォルトの名無しさん
10/01/14 16:57:35
脳波キーボードは早期に実現して貰いたい
188:デフォルトの名無しさん
10/01/14 17:01:54
>>186
> 意味と意図は別でしょ。
意図は人間が支持するんでしょ？
意味を理解できれば、どれとどれを組み合わせれば良いのか
どこを変えればよいのか、パソコンでも理解できる。
またそうなるように、人間が部品に意味をつける。
タグの凄い奴が出てくるんじゃねーの。
189:デフォルトの名無しさん
10/01/14 17:05:17
人間の発言にはたいてい膨大な前提条件や考え自体の矛盾があるから、
結局コンピューターからものすごい量の質問される事になって実用化は難しそうだと思う。
190:デフォルトの名無しさん
10/01/14 17:08:47
>>189
そこはライフログで自動的に属性を判断しましょうって事でしょ。
あとは力技で、
1000万台単位のパソコンを並列化したパワーで
人類の全てのデータを格納して、考え出そうという魂胆。
191:デフォルトの名無しさん
10/01/14 17:59:46
>>188
それが「プログラミング」なんだけどね
ビットの並びに意味付けするというのが本質
192:デフォルトの名無しさん
10/01/14 18:05:53
そうそう、意味をビットに落とす。
それを簡単にしたい->プログラミング言語とかで。
193:デフォルトの名無しさん
10/01/14 18:14:48
>>189
"いろんな言語で宿題スレ" の前スレで、Prologの人が2-3行に達する
長い述語名で定義を繰り返してたでしょ。あれは、ファジィにプログラムを
呼び出すための準備ですね。厳密に解釈していくだけがアプローチではない。
194:デフォルトの名無しさん
10/01/14 18:32:46
機械が人類を抹殺する時代が早くやってきてほしい
195:デフォルトの名無しさん
10/01/14 18:54:12
>>191
うーん、そういう風に言ったら、いつまででもプログラミングしている
という事になっちゃうので、ここでの議論とは合致しないと思う。
オムレツが食べたい。材料は卵となんかと指定するだけで
オムレツが出てくれば、それはもうプログラミングとは言えないと思う。
196:デフォルトの名無しさん
10/01/14 19:00:10
>>195
んー？
どういう立場で喋ってる？そりゃオムレツのレシピがプログラム済であるということでしかないのはプログラム経験あればわかるよね
197:デフォルトの名無しさん
10/01/14 19:27:00
セマンティックウェブってあれは８０年代のlispでやってたようなAI技術そのまんまでびっくりしたわ
198:デフォルトの名無しさん
10/01/14 19:28:51
温故知新
199:デフォルトの名無しさん
10/01/14 19:30:26
>>196
卵など個々の材料の意味づけと
オムライスのレシピから
セマンティックウェブで
コンピュータが推測して
オムレツを作っちゃうようなイメージ。
200:デフォルトの名無しさん
10/01/14 19:41:52
>>199
卵など個々の材料の意味づけ＝プロパティ設定
オムライスのレシピ＝焼き方メソッド
オムライスとオムレツは継承関係、みたいなことを指示すると言ってんじゃないのそれは
201:デフォルトの名無しさん
10/01/14 19:42:05
>>199
レシピのコーパスがライブラリ
「オムレツつくって」がmain関数
何も新しいことはない。
202:デフォルトの名無しさん
10/01/14 19:44:38
また、たとえ話か
そのたとえ話が適切かどうか誰が証明してくれんだろな
203:デフォルトの名無しさん
10/01/14 19:45:57
オムライスとかオムレツとか、たとえが混乱して悪いんだけど
コンピュータが既存のソースコードや部品の中身を意味として理解していて
頼んだ人のプロフィールも理解していると
前に似たようなプログラムやアルゴリズムがあったなと
コンピュータが検索して
頼んでる会社は中小企業だから、そんなに重厚な処理は不要だろうとか
この業界だから、こういう処理も必要だなとか
考えて部品を増減したり
ソースコードのこの部分は、こういう意味だから
ここには別の記述を当てはめることが出来るなとか考えて
ソースコードを挿入したり出来ちゃうんじゃないか
というイメージ。
火星に行く為のアプリケーションを作ってくれというのは
切り貼りでは解決しないので無理。
204:デフォルトの名無しさん
10/01/14 19:49:57
>>203
> 考えて部品を増減したり
考えてというと語弊が在るのかな。
アマゾンのお勧め本みたいなイメージ。
前例から似たようなものを検索。
前例を作るのは人間で、コンピュータはそれをチョイスしている
だけなんだけど
意味は理解しているので、現在のアマゾンよりは賢い。
205:デフォルトの名無しさん
10/01/14 19:55:35
どういう立場で？と聞いたのは、意味を理解できるコンピュータがあったなら、というとこで喋るのか、
「意味を理解させる」というのは突き詰めれば条件分岐であるというとこまで踏み込んで喋るのかということなんだけど
前者みたいね
それだとなんとも言いようがない
206:デフォルトの名無しさん
10/01/14 19:57:46
「卵のふわふわしたフライパンで作るおいしいやつ！」って
”俺”が言えばオムレツが出てきて
”オムライス嫌い”の奴が言えば卵焼きが出てくる
ってのは、やっぱり難しいと思うな。
その判断が出来るまでの属性を与えないといけないし、
プライバシーに案外うるさい人類がそこまでデータを提供してくれるとは思えない。
だいたいこんなものをコンピュータの究極と位置付けるのはそもそもおかしい。
考えるのをやめたニートベースの幸せではなくて、
もっと能動的に動く人間のための幸せを追求すべきだ。
と、適当な事を言って見る。オブジェクト指向全然関係ねぇ。
207:デフォルトの名無しさん
10/01/14 20:35:11
オブイェークト指向
208:デフォルトの名無しさん
10/01/14 21:31:06
>>205
> 条件分岐であるというとこまで
それはおかしいよ。
Amazonみたいな仕組みも、条件分岐なんだから
コンピュータの黎明期から、なにも進歩していません
みたいなシラケタ話にしても仕方が無い。
>>206
> その判断が出来るまでの属性を与えないといけないし、
利益があるなら、与えても何の問題もない。
オムライスの情報なんて、幾らでも与えれば良いじゃん。
また詳細に与えなくても、人間も企業も
ある程度グループ化できる。
プライバシーを全部与えなくてもAmazonでお勧め本は
紹介できる。それだけの話だ。
209:デフォルトの名無しさん
10/01/14 21:40:27
しらけてるというか、陳腐だなあということなんだけど
210:デフォルトの名無しさん
10/01/14 21:51:18
陳腐とか言われちゃったよｗ
まあ銀の弾丸を考えると
似通ってくるというのはあるんだろうけど
それなりに面白い話が出来るんじゃねーかと思ったんだ。
お前とは、あんまり話も合わないみたいだし
他所でやるよ。さよなら。
211:デフォルトの名無しさん
10/01/14 21:54:20
そりゃあんた意味を理解するコンピュータがあって
会社名入れたらプログラム出てくるといいねと言われたってそれ以外どう言いようがあるんだよｗ
さようならｗ
212:デフォルトの名無しさん
10/01/14 22:25:53
ただの妄想の話でそこまで熱くならんでも
213:デフォルトの名無しさん
10/01/19 08:30:06
少し上の方で自然言語でプログラミングの話あったでしょ。
あれって自然言語の文法を借りて、語彙も制限して使う話で、
コンピュータがなんでも理解できるという意味ではない。
214:デフォルトの名無しさん
10/01/19 08:46:39
少し上の方で自然言語でプログラミングの話あったでしょ。
あれって自然言語の文法を借りて、語彙も制限して使う話で、
コンピュータがなんでも理解できるという意味ではない。
215:デフォルトの名無しさん
10/01/19 20:52:50
ちょっと気の利いたDSLレベルのものしか作れなさそうだ。
自然言語は複雑な問題を簡潔に記述するのに向いた文法とは思えない。
216:デフォルトの名無しさん
10/01/21 18:36:30
>>215
25年以上も後の話でDSLはないだろ。
217:デフォルトの名無しさん
10/01/22 12:11:32
その時代には、プログラミングの対象はコンピュータというより
ロボットだと思うけど、それでも自然言語でいけるようになるのかな？
218:デフォルトの名無しさん
10/01/22 12:23:37
漫画みたいな人工知能は実現不可能だって結論出ただろ
219:デフォルトの名無しさん
10/01/22 12:28:23
ロボットがどうして漫画みたいな人工知能ということになるんだい
動き回るコンピュータ = ロボット ではないのかな？
220:デフォルトの名無しさん
10/01/22 15:35:32
>>219
適切な時機にアームを制御できるだけでロボットだね。
221:デフォルトの名無しさん
10/01/24 15:44:58
>>219
それが俺たちの望んでいるロボット像かってことだよ。
今ロボット関係の研究しているやつらなんてほとんどが
漫画みたいなロボットに憧れてロボット作ってるわけで。
222:デフォルトの名無しさん
10/01/25 12:47:54
ガンダムは作れるけどバルキリーはさすがに無理
223:デフォルトの名無しさん
10/01/25 13:26:39
俺はガンダムより最終形態の天元突破グレンラガンがほしい
224:デフォルトの名無しさん
10/01/25 18:17:57
デカイだけでダサイメカは嫌い
モスピーダなんてホンダがホントに作りそうじゃないか
225:デフォルトの名無しさん
10/01/25 18:29:23
>>217
自然言語は非オブジェクト指向的体系の代表だから、
オブジェクト指向的なロボティクスの動作記述に適していないんじゃないのと
いう疑問と解釈していいのかな。
226:デフォルトの名無しさん
10/01/25 18:38:01
>>225
25年とかそれ以上の先のことでしょ。現在だって、
情報家電のユーザインターフェイスにオブジェクト指向なんて
持ってきたらそれだけでアウトですよ。
227:デフォルトの名無しさん
10/02/04 03:46:10
てか家電の場合は全体が１つのオブジェクト
228:デフォルトの名無しさん
10/02/04 12:25:50
利用者が打ち込むコマンドレベルの話だろ。
229:デフォルトの名無しさん
10/02/08 19:01:55
利用者のコマンドとしてのOOねぇ…右クリックメニューみたいな感じ？
230:デフォルトの名無しさん
10/03/17 01:17:19
Googleが開発したGoっていう言語のオブジェクト指向が凄いらしい。
オブジェクト指向の良い部分だけを取り入れたハイブリッドな思考
は今後の主流になるかな？
231:デフォルトの名無しさん
10/03/18 07:49:14
よく分からんのだが、オブジェクト指向の良くない部分てなに
232:デフォルトの名無しさん
10/03/19 21:30:22
>>231
意味がないところ
別にオブジェクト単位にしたところで工数など１ｈたりとも減らすことはできない
233:デフォルトの名無しさん
10/03/20 00:36:58
>>230
対象物をすべてオブジェクトって概念で抽象化しようとするのに無理があるところｗ
234:デフォルトの名無しさん
10/03/20 15:26:43
とりあえず、仕様を記述するための規格化された優秀な言語が欲しいな。
実装は後回しでもいいから、人間の意図の表現とプログラミング言語の間を埋める、
表現の手段が欲しい。
235:デフォルトの名無しさん
10/03/20 15:56:31
Prologじゃだめなの？
236:デフォルトの名無しさん
10/03/20 20:22:15
>>232-233が何か重大な勘違いをしている気がする件。
オブジェクト指向は一次的な工数を減らすためにやるものではないし、
ましてや、対象を全てオブジェクト化することを目的としてやるものでもないぞ？
237:デフォルトの名無しさん
10/03/20 20:46:16
>>236
じゃあ、なんのためにやるの？
成果を数字で表してくんない？
238:デフォルトの名無しさん
10/03/20 21:05:38
>>237
なかなかきちんとまとまった説明はないけど、例えばこれとか参考になるんじゃないかな。
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
要求の変化に伴う保守性や再利用性、なんてのはなかなか数値化できんわな。
個人的な経験から言えば、OOの基本的な概念を軽く押さえたら、
次はデザインパターンの勉強をするのが理解の早道だと思う。
239:デフォルトの名無しさん
10/03/21 00:16:39
>>237
まぁ、グローバル変数をオブジェクトに押し込んでみました、ってだけの技術やからね…
成果なんて出ないと思うよ
240:デフォルトの名無しさん
10/03/21 00:45:10
>>239が何を言っているのか分からない
241:デフォルトの名無しさん
10/03/21 00:45:57
わかんないんです（＞＜）
242:デフォルトの名無しさん
10/03/21 00:46:32
>>238
結局、何が言いたいのかまったくわからない
自分の言葉で単刀直入に結論から言ってよ
243:デフォルトの名無しさん
10/03/21 01:18:48
>>242
俺の理解では、
オブジェクト指向の目的：
・複雑な要件を「まとまり」単位で整理することで、人間の手に負えるようにする
・「まとまり」同士を疎結合に保つことで、要求の変化に柔軟に対応できるようにする
（・多人数開発において、個々のコードの影響範囲を限定することでバグの作りこみを減らす）
「まとまり」につく名前は「オブジェクト」だったり、そうでなかったりするけど、基本は同じ。
244:デフォルトの名無しさん
10/03/21 02:11:13
>>243
つまり数字ではでてこないのね
気がするだけレベルなのがな
245:デフォルトの名無しさん
10/03/21 02:33:13
>>244
どういう種類の数字？
こうした原則に則って粛々とやっていけば、目に見えて保守しやすいコードがアウトプットできるし、
仕様変更に伴う工数も大幅に短縮できるはずだが。
つうか、見ての通り、きちんとコーディングする上でごくごく当たり前の方法論でしかないわけで、
『「工数○○日短縮」って数字で示されないとやる気が起きない』とかいう話になること自体が不思議。
246:デフォルトの名無しさん
10/03/21 02:41:06
>>245
>仕様変更に伴う工数も大幅に短縮できるはずだが。
だったら数字をだせよ
247:デフォルトの名無しさん
10/03/21 02:43:21
>>245
逆に考えよう
それが自分のただの思い込みだったら？
ぶっちゃけＣ＋＋とＣ言語とで比べてまったく同じ処理をするソースを書いたことないでしょ？
248:デフォルトの名無しさん
10/03/21 02:56:25
>>246
そりゃ、書いてるコードや仕様変更の内容による。
>>247
異なる言語で同じ処理を「試しに」書けてしまうような規模の開発でやったら、
そりゃ、「効果が薄いわりに冗長なコーディングを強要される」と感じるに決まっている。
個人的な経験で言えば、数千NCSS程度のコードでも、こういうことをきちんとやるだけで
保守性にかなり差が出てくると思う。
249:デフォルトの名無しさん
10/03/21 03:01:26
>>248
>保守性にかなり差が出てくると思う。
「思う」以上のこと言えないよね？
250:デフォルトの名無しさん
10/03/21 03:03:51
>>249
実体験と書いてあるわけだが。
251:デフォルトの名無しさん
10/03/21 03:05:24
>>250
だったら「思う」じゃなくて事実を書けばいいじゃん
252:デフォルトの名無しさん
10/03/21 03:11:45
>>251
揚げ足取りがやりたいならよそでやってくれ。
253:デフォルトの名無しさん
10/03/21 03:19:46
>>252
どこが上げ足とってんだよｗ
工数を大幅に短縮できるっていうからそれはどうして？って聞いてるのに
これこれこういう理由で具体的にこう減らせる
って話をしなきゃいけないのに「思う」とかそんなあいまいなレスつけるからだろ
知らなきゃレスしなきゃいいだろ
254:デフォルトの名無しさん
10/03/21 03:28:33
>>253
実体験に基づいて、実際にオブジェクト指向を採用することによる効果が出てくるコード規模について、
推測を交えて話したら、君の中では俺が全てについて憶測で話していることになるの？
255:デフォルトの名無しさん
10/03/21 04:15:50
>>254
だから知らないなら無理してレスしなくていいって
別に俺の問題に対する答えをもってるわけじゃないんでしょ？
256:デフォルトの名無しさん
10/03/21 04:30:53
>>255
えーっと、君の問題って何だっけ？
257:デフォルトの名無しさん
10/03/21 04:31:57
>>255
一人でコード書くなら差はあまり感じられないかもしれない
オブジェクト指向は、クラスのカプセル化と
小規模なクラス群からの継承やコンポジションで開発を進めていく
クラス型の選択で仕様変更を楽にできるメリットや
複数人で開発するにあたり、機能を細かく開発したり、拡張部分を楽に開発可能だし
カプセル可により、他人が安全に機能を運用できるメリットもある
特筆すべきなのは、直感的にソースがよめるため可読性が高くなること
部品を集めて組み立てるかのように、機能の選択で構築するから分かりやすい
言い換えると、中途半端なオブジェクト指向が一番読みづらい
スパゲティコードとなんら変わらないものになる
258:デフォルトの名無しさん
10/03/21 04:39:17
>>257
だから具体的な答えをもってないのになんでレスするの？
無理しなくていいよ
259:デフォルトの名無しさん
10/03/21 04:44:18
>>258
可読性の向上や、想定していない使用方法からくるバグとデバッグ時間
コードの修正による再コンパイル時間
諸々の理由からくる余計な時間が省けるだけ
元より開発能力の高い人だけの少人数開発で
再開発しない単発の開発なら
おそらく工数は変わらないか
余計な時間がかかるかもしれない
まあ本当に開発能力が高いなら微々たる時間だろうけど
260:デフォルトの名無しさん
10/03/21 04:52:08
>>259
>可読性の向上や、想定していない使用方法からくるバグとデバッグ時間
向上してるかどうかなんてわかんないんでしょ？
261:デフォルトの名無しさん
10/03/21 04:52:22
>>258
お前の言っている数値ってなんだ？
基準は相対基準か絶対基準か？
工数は普通相対基準で計るもの
相手が工数が減ったと言っているから充分だが
相手に、何の数値を求めている？
何も分かっていないで言ってないか？
お前馬鹿だろう
262:デフォルトの名無しさん
10/03/21 04:59:09
>>261
あー、わからないならレスしなくていいって
そこからいってなにをすれば証明にいたるのかわからない奴相手にしたくないから
263:デフォルトの名無しさん
10/03/21 05:00:16
>>260
可読性がってこと？
まあそうだね
数値化はできないな
だけど、開発規模がでかくなればでかくなるほど
自分が作成していないコードが増えることになる
そのとき、ヘッダ名(クラス名)と
外部に公開されたメソッド(publicなメンバ関数名)さえ分かれば
何をする部品なのかすぐわかる
コメント残せばいいじゃんと思うかもしれないが
他人が作ったコードと、他人が書いたコメントが一致してるかどうかなんてはっきりいって信用できん
後はUMLの設計図、クラス図さえあれば
どのクラスと関係を持ってるのかがわかればより早いよ
264:デフォルトの名無しさん
10/03/21 05:04:00
>>263
ごちゃごちゃ無駄なこと書いてるけど結局可読性が上がってる云々とは関係ないじゃないか
だからわからないのに無理してレスするなよ
265:デフォルトの名無しさん
10/03/21 05:06:40
>>264
ひとつひとつのメソッドを全て読むのと、名前だけの確認で終わるのどっちが早いのかはわからない？
266:デフォルトの名無しさん
10/03/21 05:11:03
>>265
なんで全然関係ない話をするの？
267:デフォルトの名無しさん
10/03/21 05:13:17
>>266
可読性の話の続きなんだが
268:デフォルトの名無しさん
10/03/21 05:14:33
もしかして、プログラミングしたことないのか？
理屈だけで覚えようとしてるなら用語もわからないかもしれないな
269:デフォルトの名無しさん
10/03/21 05:17:44
>>267
それがＣ言語からＣ＋＋に変わって（オブジェクト指向という意味で）のメリットなの？
君、自分がまったく関係ない話してるの気がついてる？
270:デフォルトの名無しさん
10/03/21 05:19:25
人には具体的な答えを求めて
自分は片言の日本語でやりとり
一つでもおかしな点があると思い込んだら全否定
質問して知識の物乞いしてんのに殿様気取り
普通ならぶん殴られてもおかしくないから直せよ
271:デフォルトの名無しさん
10/03/21 05:21:12
>>270
だから別に知らないならレスしなくていいって言ってるじゃん
272:デフォルトの名無しさん
10/03/21 05:35:05
>>269
外部にみせていいメソッドだけ公開できるのはC++からだろ
カプセル化ができないと全てのメソッドを公開しないといけない
だから全部読むはめになる
どこもずれていない
あといつからCとC++の話になった？
構造指向とオブジェクト指向は両極にある概念じゃない
C++の概念はCの概念を内包する
Cの考え方はわかっているのだろ？
それならオブジェクト指向が延長線上にあるのもわかっているはず
わからないなら、アセンブラからCに変わって発達した
構造化プログラミングのメリットを269なりに述べてみ
あと、はっきり言って認めた部分もあるだろ
理屈がわかるならわかっているはずだ
そうでなければただの荒らし
もうレスは返さない
273:256
10/03/21 05:43:24
>>257
代わりに答えてくれてありがとう。
どうも、彼は単に自分の知らない概念を全否定したいだけの人だったみたいだね。
時間を無駄にしてしまった。
274:デフォルトの名無しさん
10/03/21 05:46:36
あと開発速度でいえば、CとC++なら二分の一以下になる
コンテナ操作が標準であるし、templateで静的動作(コンパイル時動作)が可能になる
煩雑な型の作成すら汎用化できるため
今まで個別に作っていたクラスを一つのファイルで書ける
正直、これは説明しようにも長くなりすぎるから割愛する
275:デフォルトの名無しさん
10/03/21 05:47:26
>>272-273
なんでさっきから知らないのに無理やりレスするの？
いいって言ってるのに押し付けるのやめてよ
276:デフォルトの名無しさん
10/03/21 05:48:16
>>273
はっきり言えば、あなたの言い方が
多分オブジェクト指向を理解していると言いづらかったから横槍いれたんです
もっと勉強してください
277:デフォルトの名無しさん
10/03/21 05:50:10
>>276
そんなこといって結局メリットに関してなんも具体的な説明できないじゃん
だから知らないならレスしなくていいって言ってたのにやけにつっかかるなぁ
278:デフォルトの名無しさん
10/03/21 06:00:07
>>277
再コンパイル時間については？
可読性の向上については？
反論ないようだね
これ以上レスしないから安心していいよ
悪質なあなたの反論を掻い潜ることができたと言うことは
私の理屈は間違いないということだ
なお続けようとするあなたに同情すらしてやらないよ
理論もプログラミングも私より劣っている人に説明できて
理解を簡潔にまとめることができた
279:デフォルトの名無しさん
10/03/21 06:26:18
>>278
あれが具体的？
頭おかしいんじゃないか？
工数はいくつ減らせるの？
普段仕事してて１ｈだって根拠を求められるのに
なんで言語に対してはそういい加減なの？
ちょっとわけありでいい加減なことやってる場合じゃないから
あなたみたいな人普通に邪魔なんだけど
280:デフォルトの名無しさん
10/03/21 06:30:10
それと何度もいうけど
知らないなら無理やりレスするのやめてもらえます？
まったく同じ仕様のものをＣ言語とＣ＋＋とで比較した経験すらおそらくあなたないですよね？
281:デフォルトの名無しさん
10/03/21 06:33:43
>>280
知らないならレスしなくていいよ
282:デフォルトの名無しさん
10/03/21 06:45:02
>>279
工数？
1/2以下
283:デフォルトの名無しさん
10/03/21 11:11:28
一つの単位で機能を管理・提供できる点がoopじゃないのん。
cのstructじゃ処理(関数)を外側で指定(関数ポインタへの代入)しなくちゃならないんだし。
waveのinとoutの低レベルな関数はcでべた書きで用意して、
waveファイル, waveinストリーム, waveoutストリームってな感じで、
簡単に扱えるようにしたclassはc++で用意してってやると、
利便性も拡張性も供給できて、高レベルも低レベルも両方同じコードで提供できる。
詰まる所、需要と供給の話程度かと。
284:デフォルトの名無しさん
10/03/21 13:37:34
>>279
まぁ、貴方のように、既にデスマってしまった人を救済する銀の弾丸ではないかもね。
そもそも、そういう事態に陥らないための方法論がオブジェクト指向。
あるいは、レガシーコードをどうにかしたいって話だったら、こういう本を読んでみると良いんじゃないかな。
URLﾘﾝｸ(www.amazon.co.jp)
URLﾘﾝｸ(www.amazon.co.jp)
285:デフォルトの名無しさん
10/03/21 23:42:59
>>283
てか「処理」と「データ」をオブジェクトの名の下に一元管理できるのは大きな要素だと思う
286:デフォルトの名無しさん
10/03/22 16:33:30
>>285
処理とデータを関連づけるのはいいが
一緒にするのはダメなオブジェクト指向の典型だ
287:デフォルトの名無しさん
10/03/22 17:03:59
>>286
おまえ、手続き抽象ぐらいは理解した上で書いているのか？
288:デフォルトの名無しさん
10/03/22 17:57:47
>>287
否定してるわけじゃない
インターフェースとデータは分けて管理するのは当然だろ
289:デフォルトの名無しさん
10/03/22 18:56:51
>>288
それって細かい実装技術でしょ？
それが設計にまで影響しちゃうのってないじゃん
なんかこのスレに相応しくない話してない？
インターフェースクラスが本質の設計に影響を与えるのってないでしょ？
290:デフォルトの名無しさん
10/03/22 18:57:49
インターフェースクラス？？
291:デフォルトの名無しさん
10/03/22 19:05:19
>>290
どっちでもいっしょでしょ？
292:デフォルトの名無しさん
10/03/22 19:06:11
>>291
え？ｗ 何と何が？ｗ
293:デフォルトの名無しさん
10/03/22 19:06:42
>>292
上げ足取りたくてレスしたの？
死ねよ
294:デフォルトの名無しさん
10/03/22 19:09:19
>>293
どうせ二行費やすなら>>292答えろよｗ
とかいいつつゴメンね、ぐぐったら"インターフェースクラス"なるものの正体が分かったわ。
295:デフォルトの名無しさん
10/03/22 19:10:19
>>294
まあ、インターフェースが設計に影響与えるのはおかしいでそ？
なのでこの話はここでおしまい
296:デフォルトの名無しさん
10/03/22 19:13:58
>>295
なんか誤解していたら申し訳ないので伝えておく。
俺がここまでにレスしたのは>>290 >>292 >> 294だけ。
「インターフェースクラス」っていう謎の用語に怯えただけ。
話の続きは>>288さんとでもやってんろ。
297:デフォルトの名無しさん
10/03/22 20:37:29
>>295
だいたいの設計には必要無いかもな
でもひとつのデータに複数種類のアクセス方法(インターフェース)が必要な場合どうする
まさか一つのクラスにまとめるわけないだろ
インターフェースの管理についても設計すべき時なんてプログラムやってたらいくらでもあるだろ
298:デフォルトの名無しさん
10/03/22 20:38:36
>>297
ないよ
ないから君の話にはこれ以外のレスしない
おわり
299:デフォルトの名無しさん
10/03/22 20:39:12
そんなに実例みたくばboost読んでみろよ
300:デフォルトの名無しさん
10/03/22 20:41:30
boostのインターフェース設計がまさか設計無しに作られてるとか低能な言い訳しないでね
301:デフォルトの名無しさん
10/03/22 20:44:55
ごめん
Cがどうとか言ってた基地外か
boost読めないから無理だったね
302:デフォルトの名無しさん
10/03/22 22:51:31
あたかもboostがいいようにいうけどまったくいいことないと思うよ
303:デフォルトの名無しさん
10/03/23 01:29:06
いい悪いの話ではない
話題をそらすなよ
304:デフォルトの名無しさん
10/03/23 01:34:20
>>297
javaだとインターフェースクラスを直接作れるね
C++だと、メンバ変数のない純粋仮想関数だけのクラスだと思えばよし
305:デフォルトの名無しさん
10/03/25 01:10:49
マルチエージェント指向
306:デフォルトの名無しさん
10/03/27 01:07:56
>>303
なら、boostはどんな説明をするために話題に出したの？
こんなのオブジェクト設計なんてしてねーただのオナニーライブラリじゃん
307:デフォルトの名無しさん
10/03/27 15:22:24
>>306
論派したいんだろうけど、話題反らしたり無知披露したりで屑認定されてるよ
308:デフォルトの名無しさん
10/03/27 15:34:49
>>306
頭悪いんですね…
309:デフォルトの名無しさん
10/03/27 18:14:44
オブジェクト指向？なにそれ、おいしいの？
オブジェクトなんて構造体でしょ？なんでそんなに有り難がる必要があるだろう
ましてや構造体でシステム設計とか意味不明
310:デフォルトの名無しさん
10/03/28 01:59:40
>>309
勉強して批判しようね屑
311:デフォルトの名無しさん
10/03/28 13:46:27
熟練のプログラマって意外とオブジェクト指向で作らないんだよね。
考えが古いのかな？
実はあまり必要ないとか？
312:デフォルトの名無しさん
10/03/28 14:05:40
>>311
意味ねーし
オブジェクト指向になって具体的にいいことって出せる奴いねーもん
313:デフォルトの名無しさん
10/03/28 14:12:51
>>312
Stringクラスも不要？
314:デフォルトの名無しさん
10/03/28 14:17:16
>>313
仮に似たような機能Ｃ言語で作ったらいらないな
315:デフォルトの名無しさん
10/03/28 14:25:46
>>314
文字列の長さ順にソートするような場合どうする？
strlenを毎回呼ぶつもり？
316:デフォルトの名無しさん
10/03/28 15:15:18
>>315
それはＣ＋＋でないと作れない機能ですか？
ってことだな
同じ労力だと思うぜ
317:デフォルトの名無しさん
10/03/28 15:47:16
>>316
ってことだな？ 思うぜ？
>>315に具体的に答えることは不可能？
「仮に似たような機能Ｃ言語で作ったら」と言ってたのに。
318:デフォルトの名無しさん
10/03/28 15:52:23
>>317
は？
それって何か問題あるの？
っていうか話の主旨をどこにしたいの？
俺は別にライブラリの出来不出来の話をしたいわけじゃないんだけど？
319:デフォルトの名無しさん
10/03/28 15:53:45
>>318
ライブラリの出来不出来の話などするつもりはない。
320:デフォルトの名無しさん
10/03/28 15:55:30
>>319
じゃ、何が言いたいんだよ
さっきから
321:デフォルトの名無しさん
10/03/28 15:56:47
>>320
「文字列の長さ順にソートするような場合どうする？
strlenを毎回呼ぶつもり？」
322:デフォルトの名無しさん
10/03/28 16:16:25
stringクラスと、そのsize()メソッドがあるから、
そのインスタンスsに対しs.size()とサイズを取得できる。
char *に対してはstrlenを毎回呼び出す必要があるか、
呼び出さないためには値をキャッシュする変数を別途用意する必要があり、
それらの生成破棄など、管理する手間が別途発生してしまう。
また、キャッシュのための変数の中身は、
strlenの結果と同一であるように注意を払う必要も出てしまう。
これは非常に煩わしい。
一方、stringクラスのsize()メソッドを使う場合は、
サイズの再計測もさせないように実装しうるし、
それゆえ、別途キャッシュするような変数も、
その変数との同一性への心配も不要になる。
オブジェクト指向になって具体的にいいことのひとつだと思う。
323:デフォルトの名無しさん
10/03/28 17:02:42
>>322
っていうＣ言語の関数を用意したら？
でお仕舞いな話を出されてもねｗ
324:デフォルトの名無しさん
10/03/28 17:16:18
>>323
そんな手間をかけるくらいなら、
俺はstring#sizeを使って単に、
bool sizegreater(const std::string &a, const std::string &b) {
return a.size() > b.size();
}
こう書いて、sort(v.begin(), v.end(), sizegreater);に渡す。
> っていうＣ言語の関
ご苦労様ですｗ
325:デフォルトの名無しさん
10/03/28 17:18:23
>>324
だから君が言ってるのはライブラリの有無の話でしょ？
最近、こんな馬鹿が金もらってプログラム組んでるからな
326:デフォルトの名無しさん
10/03/28 17:20:11
#include <string>
#include <vector>
bool sizegreater(const std::string &a, const std::string &b) {
return a.size() > b.size();
}
int main() {
using namespace std;
vector<string> v;
sort(v.begin(), v.end(), sizegreater);
return 0;
}
毎回strlenを呼ばずにCで同等のことをするのは大変。
大変じゃないというのならサクッと示してほしいところ。
327:デフォルトの名無しさん
10/03/28 17:21:37
>>326
>毎回strlenを呼ばずにCで同等のことをするのは大変
大変（笑）
328:デフォルトの名無しさん
10/03/28 17:22:30
>>325
すでに>>322で書いたように、stringに対してs.size()が呼べるからこそ、
>>315の問題の部分は、return a.size() > b.size(); と書ける。
オブジェクト指向じゃないとこうならない。
329:デフォルトの名無しさん
10/03/28 17:25:55
>>328
バーカｗ
しゃべるたびに頭になにも入ってないのがバレバレだなｗ
330:デフォルトの名無しさん
10/03/28 17:26:39
オブジェクト指向不要論みたいなのを掲げて煽ってるヤツって釣りじゃねーの？
本当に不要とか思ってるのなら単なる馬鹿で相手にするだけ時間の無駄だと思うんだが。
331:デフォルトの名無しさん
10/03/28 17:27:57
文字列の長さでソートする時、strlenを毎回呼び出さないですむ方法が、
Cでスマートに表現できるのなら俺は>>329をバカと呼んだりはしないよ。
332:デフォルトの名無しさん
10/03/28 17:28:06
指摘するほうもオブジェクト指向と全然関係ないところをあげて
サブルーチン単位の細かいことしか挙げないのはどうしてなの？
はじめのオブジェクト指向にテンプレートなんて入ってなかったでしょ？
333:デフォルトの名無しさん
10/03/28 17:30:39
>>331
は？意味がわからない
仮に構造体をもって
typedef struct{
char *str;
int size;
}MYSTR;
ってやって毎回strlenを呼び出さなくていい状態にしたときに
それは君のいう「毎回」の定義に入ってるの？入ってないの？
前提がスカスカすぎて答えられないんだよバーカ
こんなことも想像できねーのか？
334:ああ
10/03/28 17:32:23
同意
URLﾘﾝｸ(d47.decoo.jp)
335:デフォルトの名無しさん
10/03/28 17:33:33
>>333
ほら、そうなる。
>>322
> 呼び出さないためには値をキャッシュする変数を別途用意する必要があり、
> それらの生成破棄など、管理する手間が別途発生してしまう。
> また、キャッシュのための変数の中身は、
> strlenの結果と同一であるように注意を払う必要も出てしまう。
別途に構造体や変数を用意したり使いまわしたりすることなく、
typedef structのsizeを隠し、
サイズ取得へのインタフェースをsize()と＊ひとつだけ＊用意したのがオブジェクト指向だ。
336:デフォルトの名無しさん
10/03/28 17:36:10
>>335
はぁ？
だからＣ＋＋の場合ライブラリとしてStringが用意されてるのは認めて
Ｃ言語ではライブラリの類を認めないってのはどういう理論なの？
Stringはライブラリでしょ？
Ｃ言語で俺が書いたMYSTRがそれに当たるんでしょ？
337:デフォルトの名無しさん
10/03/28 17:38:13
それとこの辺ってオブジェクト指向関係ないじゃん
なんでこんなサブルーチン出してオブジェクト指向云々の説明をしようとするの？
できっこないじゃない
338:デフォルトの名無しさん
10/03/28 17:38:54
データ抽象がオブジェクト指向だっていうならCだって
オブジェクト指向プログラミングできるだろう
>>335 みたいなバカが多いんだよね
オブジェクト指向脳の連中って
339:デフォルトの名無しさん
10/03/28 17:40:48
これはさすがに会話続行不能なレベルだよね
ライブラリと言語仕様と設計の区別もついてない
文字列クラス出してなんでオブジェクト指向の説明になるの？
仕事でもすごいトンチンカンなことやってそう
340:デフォルトの名無しさん
10/03/28 17:44:12
>>336
> また、キャッシュのための変数の中身は、
> strlenの結果と同一であるように注意を払う必要も出てしまう。
カプセル化を用いるからこそ、size()のみが提供され、
typedef struct{
char *str;
int size;
}MYSTR;
streln(str)とsizeの値の整合性を気にする必要がなくなる。
>>337 カプセル化はなんの話題かな？
>>338 Cでオブジェクト指向プログラミングできるか否かについては言及していない。
>>339 カプセル化はオブジェクト指向ならではだろう？
341:デフォルトの名無しさん
10/03/28 17:49:12
別に文字列クラスでオブジェクト指向を説明することについては間違ってないと思うが。
つうか、オブジェクト指向を理解しようとしない奴には何を言っても無駄だろう。
「なぜクラスをインスタンス化する必要があるのか」ってのをよく自分で考えてみたらどうなの。
いちいち説明しないとわからんなら発言すんなよ、って言いたいね。
342:デフォルトの名無しさん
10/03/28 17:50:17
>>340
なんでそうやって小手先の技にこだわるの？
オブジェクト指向設計の話をしてよ
343:デフォルトの名無しさん
10/03/28 17:53:12
>>342
オブジェクト指向設計？？
その話をするのはまだ早いとおもう。
今はまだCと比較できる部分のほうがいいかと。
344:デフォルトの名無しさん
10/03/28 17:54:21
>>341
なんで仕様書がないサブルーチンなんかでオブジェクト指向の話ができるの？
理解してないのは君のほうなんじゃないの？
だから文字列クラスでオブジェクト指向の話ができるなんていっちゃうんじゃないの？
できないよ
345:デフォルトの名無しさん
10/03/28 18:03:27
文字列に関連したオブジェクト指向のメリット
* 色々なエンコーディングの文字列を統一的に扱うことができる。
* 色々なエンコーディングの生文字列と、UNICODE等の内部表現の文字列を統一的に扱うことができる。
* 色々なエンコーディングの文字列間の比較やソートなどを簡単におこなうことができる。
などなど。
こんな簡単なことに気付きもしない生半可な知識でオブジェクト指向を否定するのって、
ほんとうに愚かで馬鹿馬鹿しいことだと思うのだが、どうよ？
346:デフォルトの名無しさん
10/03/28 18:15:52
>>345
彼らはカプセル化すら分かってないから…。
内部表現丸出しでも平気らしいし。
347:デフォルトの名無しさん
10/03/28 18:17:17
初心者ｗ
348:デフォルトの名無しさん
10/03/28 18:29:11
>>315
オブジェクト指向をまったく知らない者ですが。質問です。
ファイルから一行文字列が読み込まれ新しいstringインスタンスが
生成されるとすると、その度にsetof()が実行され属性sizeにsetof()の結果が
セットされるのですか？
そうなら分かるのですが、そうではないとするとsetof()でstrlen()でも
大差ないような気がするのですが。
349:デフォルトの名無しさん
10/03/28 19:08:36
>>345
それオブジェクト指向のメリットなのー？（爆笑）
350:デフォルトの名無しさん
10/03/28 19:24:02
追い詰められたカスの特徴ｗ 理屈で返事しないｗ
351:デフォルトの名無しさん
10/03/28 19:34:49
はぁ？文字列クラスなんて意味のねーものいじってねぇで
オブジェクト指向設計の説明してみせろよ
なんで文字列クラスなんだよバッカじゃねーのｗ
352:デフォルトの名無しさん
10/03/28 19:35:46
追い詰められたカスの特徴ｗ 理屈で返事しないｗ
353:デフォルトの名無しさん
10/03/28 19:40:26
ソースが読みやすくて綺麗になる
354:デフォルトの名無しさん
10/03/28 20:13:07
知識レベルが近ければオブジェクト志向もチームでやるには有効なケースはあるが、
揃ってないなら捨てた方が吉。中途半端な知識の奴とか覚えたてのニワカがいる場合も
クラス設計そのものがスパゲティになるから排除した方が良いｗ
355:デフォルトの名無しさん
10/03/28 20:26:42
知識レベルが低い奴が書いたコードは
オブジェクト指向であろうがなかろうが
スパゲッティーだっつーの
356:デフォルトの名無しさん
10/03/28 20:41:34
あと、オブジェクト指向じゃないとデバッグやりにくい
バグが起きないと保障されている場所もチェックして行かないといけない
357:デフォルトの名無しさん
10/03/28 21:10:36
>>355
高い低いの問題じゃない。ぶっちゃけ一人だけ知識深い奴がいても、そいつのコードは周りから見れば
さっぱり、なんてことは良くある。
358:デフォルトの名無しさん
10/03/28 22:14:51
だいたい自分のコードが見やすいかどうかなんて誰か１人にでも聞いたことあるのか？ｗ
359:デフォルトの名無しさん
10/03/28 22:17:46
複数開発なら普通にあるだろ。「見やすい？」とかじゃなくて「わかる？」とかだと思うがｗ
360:デフォルトの名無しさん
10/03/28 22:22:39
オブジェクト指向的な考え方は、メンテしやすいソフトウェアを書く上では
今や教養として必須だと思うけどな。是非を問う段階はとうに通り過ぎてる。
まぁ、一口にオブジェクト指向といっても、切り口によって色々な解釈があるみたいだけど、
# その辺の小難しい話を知りたいなら、例えば以下のエントリが参考になるかもしれない。
# URLﾘﾝｸ(d.hatena.ne.jp)
# URLﾘﾝｸ(d.hatena.ne.jp)
どれも、最終的には「メンテナンス性の向上」が大きな目的であるという点では共通していると思う。
上でstringクラスを例として挙げてる人がいるけど、それにより実現できる機能にのみ
注目すると、利点を示すのが難しくなるんじゃないか。
一番重要なのは、データと処理を統一的な方法でまとめることで、
「より使いやすく」「より分かりやすく」「より安全に」プログラムできるようになることだろう。
一口に言えば、それが「できる」ことと「簡単にできる」ことの間には大きな差があるし、
生産性の向上という量的な変化は、究極的には質的な変化に繋がりうる。
>>348の人も、そういう観点から入門書を読んでみると良いと思うよ。
361:デフォルトの名無しさん
10/03/28 22:25:55
>>356
それちがうとおもう
経験的に、関数的にまとまってる設計(副作用のない設計)の方がデバッグは楽
362:デフォルトの名無しさん
10/03/28 22:30:29
>>360
たしかにそうなんだけど, 現場ではオブジェクトの名の元に
クラスに隠蔽されたグローバル変数が飛び交ってるんだが
363:デフォルトの名無しさん
10/03/28 22:31:47
>>360
>一番重要なのは、データと処理を統一的な方法でまとめることで、
>「より使いやすく」「より分かりやすく」「より安全に」プログラムできるようになることだろう。
脳みそにウジでもわいてるのか？
それのどこが金になるの？
364:デフォルトの名無しさん
10/03/28 22:34:51
>>361
副作用のない範囲で済むコードなら良いと思うけど、それは要求次第なわけだし。
副作用が影響を与える範囲を言語仕様的に限定できるのがオブジェクト指向言語の良いところ。
早い話が、自分や他人がアホなコードを書いた時のリスクを低減できる。
非純粋関数型言語が許されるのは小学生までだよね（AA略という話ならまた話が変わるけど。
365:デフォルトの名無しさん
10/03/28 22:35:04
プロセス志向で機能分割するのに比べて、実行フローを明確にできないからOODではむしろ難しくなる。
その辺開発者全員で設計段階から意識共有できないと大変なことになる。
だから所謂「ジャンプ」コードの廃止によって少なくなって行ったスパゲティコードが、OODによって復活した。
なんてのは、15年も前にウェブスターなんかが指摘してたことだけどな。
366:デフォルトの名無しさん
10/03/28 22:39:25
>>361
そもそもオブジェクト指向を取り入れてない言語のデバッガが低次元になってる
367:デフォルトの名無しさん
10/03/28 22:39:40
>>362
そこは継続的インテグレーションと静的解析ツールを使ってコーディングスタイルを強制、
でいいんじゃね。IDEや各種ツールを導入して自動化するのは重要。
368:デフォルトの名無しさん
10/03/28 22:40:47
>>364
> 副作用のない範囲で済むコードなら良いと思うけど、それは要求次第なわけだし
それもちゃうとおもう
うまくデザインすれば、副作用のある個所は物凄く減らせる
369:デフォルトの名無しさん
10/03/28 22:44:00
オブジェクト指向ってさ、なんで無理にメソッドの集合で全ての物事を抽象化しようとするのかね？
例えば無いかもしれないデータを表現するのにメソッドの集合で定義すると、
template <class T>
class Option {
public:
T get();
bool isNone();
};
という風に抽象化されると思うけど、これだと実体がNoneなのにgetが呼ばれてエラーになる可能性がある
代数的データ型みたいにメソッドの集合と場合分けの構造と両方持てばいいのに
370:デフォルトの名無しさん
10/03/28 22:46:24
>>363
手戻りが減らせればコストを減らせて金になると思うけど。
371:デフォルトの名無しさん
10/03/28 22:48:58
>>365
ワークフローが中心になるタイプの業務システムとかだとそういう側面はあるかもしれないな。
そこは、オブジェクト指向というよりフレームワークのレベルでどうにかする問題だという気もするけど。
372:デフォルトの名無しさん
10/03/28 22:50:25
>>368
デザインによって副作用は減らせると思うけど、完全に取り除くことはできないわけだし。
それに、そういううまいデザインとオブジェクト指向の採用は矛盾しないんじゃない？
373:デフォルトの名無しさん
10/03/28 22:50:30
>>363 ではないんだけど
現実には >>362 の様な理由によって
>「より使いやすく」「より分かりやすく」「より安全に」プログラム
できていないことが問題だろ
374:デフォルトの名無しさん
10/03/28 22:53:45
>>369
参照に代入されたnullを「ない」の意味で使うか、Null Objectを定義すればよし。
375:デフォルトの名無しさん
10/03/28 22:53:59
ちんこの遊び場はここですか
376:デフォルトの名無しさん
10/03/28 22:56:39
>>373
もちろんオブジェクト指向は万能な「銀の弾丸」じゃない。
そこを補うのが、例えば>>367みたいな実践。
377:デフォルトの名無しさん
10/03/28 22:57:15
>371
オブジェクト指向の利点を活かすには、それを含めてってことだけどな。
草創期からOODに取り組んでいたウェブスターが言ったのは、人材だの会社の
政治的な側面も考えて「環境を整えてからやれ」ってこと。
378:デフォルトの名無しさん
10/03/28 23:04:29
>>374
nullを使ったらnullチェックが必要になるのでisNoneを呼び忘れる危険と変わらないのでは？
Null Objectってどうやって使うの？まさかtypeid？それこそ場合分けの構造じゃんか
こういう小手先の芸じゃなくて、言語使用として場合分けの構造をサポートした方がいいという判断で、
Scalaとかはcase classを導入したんだと思うんだけどなー
379:デフォルトの名無しさん
10/03/28 23:05:03
オブジェクト指向じゃない言語は本当に迷宮入りする事があると思う
ある意味怖い
380:デフォルトの名無しさん
10/03/28 23:08:19
>>378
URLﾘﾝｸ(www.hyuki.com)
381:デフォルトの名無しさん
10/03/28 23:14:16
>>379
200人規模のプロジェクトだとオブジェクト指向でも平気で迷宮入りするのは気のせい?
382:デフォルトの名無しさん
10/03/28 23:15:10
>>380
ありがとう
読んでみたけど、Null Objectでどうやってgetを実装するの？
戻り値がないので無理でしょ
やっぱりメソッドの集合で物事を抽象化するには限界があるのだと思うよ
限界があるというか、もっといい方法がある場合があるので、そちらも使うべき
383:デフォルトの名無しさん
10/03/28 23:15:40
200人いれば200のオブジェクト指向があるってのが事実。
大統一理論があると思ってはいけないｗ
384:デフォルトの名無しさん
10/03/28 23:17:18
>>382
べつにnullを使っちゃいけないということはないと思うけどなぁ。
いい方法があれば併用すべきというのは同意。
385:デフォルトの名無しさん
10/03/28 23:22:27
>>382
ていうかべつに代数データ型でなくてswitch caseでいいわけでしょ。
基本的にパターンマッチは記述を簡潔にするのが目的だと思うけど。
OOがやる抽象化は拡張できるようにするためでしょ。
386:デフォルトの名無しさん
10/03/28 23:26:08
>>381
そんなレベルじゃない
自分で自分が作った物が分からなくなる
オブジェクト指向だとプログラム自体がある程度設計書だがそれがない
387:デフォルトの名無しさん
10/03/28 23:28:02
>>384
同位THX
ついでだからさらに続けると、
一旦場合分けの構造の有用性を受け入れると、意外とその適用範囲が広いことが分かると思うのよ
Scalaではかなり使われているし、関数型言語ではいわずもがな
とすると、これはもう、
"メソッドの集合で全てを表現しようとしたオブジェクト指向はやりすぎでした、間違いでした"
という結論にならざるを得ないのだけど、どうよ？
388:デフォルトの名無しさん
10/03/28 23:34:30
メソッドどころか「データの抽象化がオブジェクト指向ではない」ってのは、
高名なクック船長がおっしゃってますｗ
389:デフォルトの名無しさん
10/03/28 23:35:58
>>385
>ていうかべつに代数データ型でなくてswitch caseでいいわけでしょ。
あれ？
オブジェクト指向ってsiwtch caseを使わずにオブジェクトのメソッドで抽象化するというのが原則じゃなかったっけ？
switch caseを使うって事は、場合分けの構造がやっぱり必要って事になるよ
390:デフォルトの名無しさん
10/03/28 23:36:21
>>386
それはどうしてそういえるの？
391:385
10/03/28 23:44:14
>>389
極端に言えば、パターンマッチはswitch caseがあれば、場合わけの構造とやらがあるので、いらんでしょ?
OOでわざわざ抽象化してデザインすると、それを外部から拡張できるようになる。
それとも場合わけの構造ってなにか具体的な定義があるの?
392:デフォルトの名無しさん
10/03/28 23:46:23
>>391
ぶっちゃけそんな細かいとこどーでもいいよ
実装方法なんてどーだっていいし
オブジェクト指向となんも関係ないのに
それがオブジェクト指向だと思ってる可愛そうな脳みそしてる奴多いな
オブジェクト指向はあくまでも仕様をオブジェクトに落とすだけだ
そんな細部の話が出てくる時点でもうおかしいだろ
393:デフォルトの名無しさん
10/03/28 23:55:48
>>392
個人的な意見だけど、オブジェクト指向って言葉は、
「オブジェクトという概念を中心に据えたテクニックや分析手法の集合」なんじゃないのかな。
その具体的なテクニックの代表例が、例えばデザインパターン。
だから、人によって見解に相違が出てくるのは当然だし、
「○○という定義に沿ってなければオブジェクト指向じゃない」みたいな話はあんまり意味がないんじゃないかな。
394:デフォルトの名無しさん
10/03/28 23:55:58
>>391
>極端に言えば、パターンマッチはswitch caseがあれば、場合わけの構造とやらがあるので、いらんでしょ?
確かにswitch caseがあれば、パターンマッチはそれの強力版みたいなものなので、原理的にはいらない
それは同位
うん？でも議論がかみ合ってないな
別にパターンマッチが必要と言っているのでは無く、
switch caseという便利なものを否定しようとするオブジェクト指向はいまいちじゃない？と言っている