オブジェクト指向は愚かな考え。この世は計算式 ★3©2ch.net

**デフォルトの名無しさん転載ダメ©2ch.net** · 2016/01/05(火) 02:10:25.72

オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
https://twitter.com/ProgrammingMono/status/665702678006140928

研究グループは、血管新生注において血管が伸長する際の血管内皮細胞注運動を制御するしくみを、生物学と数理モデル・
コンピュータシミュレーションを融合させた先端的な研究手法により明らかにしました。

生物は、最小の機能単位である細胞が寄り集まった多細胞体です。しかし、細胞の集まりが、組織や器官といった
秩序ある形態や構造をつくり機能するしくみはほとんど分かっていません。中でも血管は、体中の全組織に十分な
酸素や栄養源を効率よく供給するため、組織や組織の間に入り込み、血管外の環境との相互作用により、巧妙な
枝分かれ構造をとっています。

これまでに本研究グループは、新しく血管がつくられる（血管新生）際の細胞の動きに着目し、特に血管内皮細胞の
動きをリアルタイムで可視化し、定量的に捉えることを可能にしてきました。

今回さらに、血管の伸長を制御するしくみについて、細胞が自発的に自らを制御して動く過程（自律的過程）と、
隣接した細胞から適宜影響を受けて動く過程（協調的過程）がうまく共存することで、全体の動きが巧みに統制
されていることを世界に先駆けて実証しました。

興味深いことに、血管内皮細胞が前後したり、お互いに追い抜きあったりという血管新生で見られる複雑な細胞集団の
動きを制御している中枢部分は、細胞一つ一つの動き（スピードと方向性）の「確率的な変化」として十分説明できる
ことをコンピュータシミュレーションで実証しました。
http://www.jst.go.jp/pr/announce/20151120-2/#YOUGO3

前スレ
オブジェクト指向は愚かな考え。この世は計算式 ★2
http://peace.2ch.net/test/read.cgi/tech/1450153388/

**デフォルトの名無しさん** · 2016/01/09(土) 19:39:23.22

メッセージングのオブジェクト指向の言い方で言うと、
主語はメッセージのレシーバであり、文の残りはメッセージだ

**デフォルトの名無しさん** · 2016/01/09(土) 23:40:46.34

>>58 チンパンジーのアイちゃんかな？

**デフォルトの名無しさん** · 2016/01/09(土) 23:55:42.86

>>58
x.sin() では x がオブジェクトで、sinというメソッド（もしくはメッセージ？）を処理していて、
sin(x) では sin がオブジェクトで、xという入力を処理している。

どちらかの方がよりオブジェクト指向的だという序列なんかない。
数学関数それ自体をオブジェクトと認めようとしない思想（？）の根源は何なんだ？

**デフォルトの名無しさん** · 2016/01/10(日) 00:13:34.71

ポーランド記法嫌いそう

**デフォルトの名無しさん** · 2016/01/10(日) 00:21:12.30

演算子前置のポーランド記法は嫌いだなぁ
存在する意味がわからないレベルで嫌い。
演算子後置の逆ポーランドじゃないとね。

**デフォルトの名無しさん** · 2016/01/10(日) 00:34:49.51

> 存在する意味がわからないレベルで嫌い。

なんで？

> 演算子後置の逆ポーランドじゃないとね。

なんで？

**デフォルトの名無しさん** · 2016/01/10(日) 00:40:13.45

Add 3 to 5, then multiple it by 2.

**デフォルトの名無しさん** · 2016/01/10(日) 01:09:07.40

逆ポーランドの方が実装しやすいと思う。
人それぞれの範疇だが。

**デフォルトの名無しさん** · 2016/01/10(日) 01:11:54.59

>逆ポーランドの方が実装しやすいと思う。

意味がわからん。
構文木作るのに一番前と後でなんか変わるか？
AST作らずにそのまま逐次実行するならスタックに
積むだけでいい逆ポーランドの方がいいかもしれんが

**デフォルトの名無しさん** · 2016/01/10(日) 01:16:08.27

x.sin() では x がオブジェクトで、sinというメソッド（もしくはメッセージ？）を処理していて、
sin(x) では sin がオブジェクトで、xという入力を処理している。

どちらかの方がよりオブジェクト指向的だという序列なんかない。
数学関数それ自体をオブジェクトと認めようとしない思想（？）の根源は何なんだ？

違うよな
どちらがオブジェクト志向的かといえばx.sin()でしょ
xというオブジェクトにsin()というメソッドが属しているという考えなんだから
sin()は関数に対してxというオブジェクト、あるいは単にデータを引き渡しているだけ

後者は明らかに関数的な考え方、動詞優位

**デフォルトの名無しさん** · 2016/01/10(日) 01:27:11.07

関数へのエイリアスのようなメソッドはドットで繋ぐのでなく、
別の文字にした方がいいよな。

**デフォルトの名無しさん** · 2016/01/10(日) 01:29:17.31

釣りじゃなくて単に本当にあたまおかしいのかな？
Xはデータであって演算ではない。Xは演算しない。
Xをオブジェクトとして扱った場合、その操作として実装されるメソッドは
データのゲットセットなど内部状態を隠蔽するためのメソッドと
可変不変などのデータ状態をあらわすメソッド。

まだお前の脳内じゃおまえがコーヒーを飲むんじゃなくて
コーヒーが勝手に口に飛び込んで来てんのか。

**デフォルトの名無しさん** · 2016/01/10(日) 01:29:19.21

x.sin()は手続き言語的だと思うけどなあ
もちろんsin(x)も。
オブジェクト指向ならメッセージを送るような記述の方が自然では

**デフォルトの名無しさん** · 2016/01/10(日) 01:52:12.61

現実世界をオブジェクト指向に当てはめるやついるけど馬鹿だよなー

コーヒーが勝手に口まで運ばれてくる機能をコーヒにつけただけじゃんw
ついでにコーヒーがしゃべる機能もつけたよ。

問題がないからそういう設計にしたんですよ

**デフォルトの名無しさん** · 2016/01/10(日) 01:53:23.52

どちらがより汎化されているかではなく
具体例で語ろうとする人間は、プログラムを実装したことがないのでは？

具体的な手続きによる具体的な文字通りのプログラムを書きたいなら
Cでかいてどうぞ

**デフォルトの名無しさん** · 2016/01/10(日) 01:59:31.92

オブジェクト指向だろうと関数志向だろうとやってることは変わらない

オブジェクトはメソッドの第一引数でしかない

コーヒーを飲むという行為を書くためには手続き的に書くしか無い
コーヒーが俺の口の中にあるという結果を宣言的に書きたいのに
その手続きを丹念に描写したいならそうすればいい

I.drink(coffee)と書けばいいんだよ
I.drink(coffee)とyou.drink(coffee)は飲み方が違う！というのならそう実装すればよい

モデリングとは物事を単純化する行為、汎化する行為であって具象化する行為ではない
Iとyouの違いがモデルのキーポイントなら、Iとyouという（メソッドの第一引数）をパラメータに加えればいいし
そうでないなら含まないほうがモデルがシンプルに保たれる

数学ができない自称モデラーはプログラムを手続き的に書いたらいいんだよ

**デフォルトの名無しさん** · 2016/01/10(日) 02:00:42.57

特化させたいのに汎化する必要ある？
狭い世界で使うなら特化させていい。
広い世界で使うなら汎化させる。

それだけ。

**デフォルトの名無しさん** · 2016/01/10(日) 02:03:41.63

汎化と特化させるもんを決めるのが設計な

**デフォルトの名無しさん** · 2016/01/10(日) 02:42:12.92

>>74
言ってることはわかるがコーヒーを主語に対象を汎化なら
coffee1.drunkBy(me);
coffee2.drunkBy(you);
だろ

**デフォルトの名無しさん** · 2016/01/10(日) 03:01:38.69

>>72
普通モデリングなんて想定される実装の多さや効率の問題で変えるものだからね
感性にまかせる初心者ほど文脈や抽象に拘って依存性の上下を無視するよ

**デフォルトの名無しさん** · 2016/01/10(日) 04:22:46.36

アクセル→エンジン→ギア→タイヤじゃなくて
タイヤ.回転で自動車設計してそうだなおまえら。

**デフォルトの名無しさん** · 2016/01/10(日) 05:12:47.23

>>79
そうやって現実の構造を想定している時点でもう駄目なんだよ

**デフォルトの名無しさん** · 2016/01/10(日) 05:20:12.43

ちうかこれオブジェクトが目的語とか言ってる人か？
英語とプログラミングのobject混同とかとてもまともとは思えないよ

**デフォルトの名無しさん** · 2016/01/10(日) 05:34:14.40

>>74
JavaScriptだと実際foo.barは第０番目の引数を指定するための糖衣構文でしか無い
オブジェクト指向は別にそんな大したものでも、手続き型と相容れないものでもない
指向とは言うが実際の所スタイルの一部だね

**デフォルトの名無しさん** · 2016/01/10(日) 08:13:48.91

いいえ、自転車.操業で設計しています

**デフォルトの名無しさん** · 2016/01/10(日) 08:49:55.36

>>82
そういう嘘をまき散らさないでもらいたいなあ。
毛の人といい、技術の普及は嘘との戦いだな。
オブジェクト指向は嘘つきが多すぎた。

**デフォルトの名無しさん** · 2016/01/10(日) 09:36:41.30

>>68
いいえ。
sin(x) と書いたときのsinは十分オブジェクトに見えるでしょ。
xとsinは違う階層（空間）に属するモノだけど、後者の方が階層としては高い。
x.sin()と書くと、あるオブジェクトが自分より高い階層のオブジェクトを所有しているように見えてしまう。
これは俺にとっては不自然なので好きになれない。

**デフォルトの名無しさん** · 2016/01/10(日) 09:42:21.66

オブジェクト指向は手続き型と直行する概念だと理解してないのが何人かいるな

**デフォルトの名無しさん** · 2016/01/10(日) 09:44:41.71

>>80
"現実の構造を想定しちゃダメ"て
おまえの作るシステムはどんな現実離れした
脳内妄想ベースなんだよ。

**デフォルトの名無しさん** · 2016/01/10(日) 09:52:56.57

sinは関数だろね。
テーブルを持つためにクラスを使わなければならない言語があったとしても、
極力、ユーザーにとって関数に見えるように実装するべきじゃないのかな。

**デフォルトの名無しさん** · 2016/01/10(日) 10:08:13.09

関数がオブジェクトじゃ何か困ることでも？

**デフォルトの名無しさん** · 2016/01/10(日) 10:09:40.58

>>79
君が設計する自動車ではエンジンブレーキが効かないようだな。

**デフォルトの名無しさん** · 2016/01/10(日) 10:29:26.64

ブレーキなんてのは外部から
ベクトルの力を操作するんだから
後付けで全然構わないんだが。

**デフォルトの名無しさん** · 2016/01/10(日) 10:41:27.70

関数を手続きだと思ってるならそれでいいけど、名前が関数ってだけで数学関数をそういうカテゴリーのものとするのは不適当でしょうね。

**デフォルトの名無しさん** · 2016/01/10(日) 11:09:22.36

クロージャーって、関数なの？オブジェクトなの？
rubyだとProcのインスタンスでしかないよね

**デフォルトの名無しさん** · 2016/01/10(日) 12:33:30.21

>>91
わからないなら無理に口を挟まないほうがいいよ。

**デフォルトの名無しさん** · 2016/01/10(日) 13:26:28.06

>>92
関数が状態を持つべきかどうか考えると自ずと答えが出るのではないだろうか。

**デフォルトの名無しさん** · 2016/01/10(日) 13:37:48.58

sin(x)は関数の値であって関数ではないよな。　関数は∀x∈double.sin(x)のことだよな。

**デフォルトの名無しさん** · 2016/01/10(日) 13:51:03.83

>>85
実装がどうあれ、OOPではメソッドはオブジェクトに属するものとして考えるから、
x.sin(value)の表記は不自然じゃ無いだろ。sinはオブジェクトxに属している。

**デフォルトの名無しさん** · 2016/01/10(日) 14:13:06.68

>>97
それは不自然な考え方じゃないかな。
原点に立ち返ってみると、オブジェクト志向とはコード再利用に際して
コンポーネント化の要求から発生したもの。
現実に存在する物のように、ディスプレイ上のウィンドウに四角形を
描画しろとメッセージを送るというようなシンプルなものだ。
この場合、四角形自体がオブジェクトであることは問題が無いように感じる。
これは、四角形が状態を保持しているからかもしれない。
一方、数値に対してsinを要求するのは突拍子もないように感じる。
これは、数値を日常いたるところで使用していて、数値がメッセージを受け取る性質を
もたないと良く知ってるからではないだろうか。
あるいは計算機オブジェクトに対してsinを要求するなら不自然に感じないのかもしれない。
どうだろうか？

**デフォルトの名無しさん** · 2016/01/10(日) 14:14:35.30

この種のくそ議論って恣意的な答えしかないんだから、
議論するだけ無駄なんだけどねぇ。

**デフォルトの名無しさん** · 2016/01/10(日) 14:15:24.10

>>95
状態をもつかどうかは実装しだい。
関数を初期化するとき係数のセットを与えるとかあると思う。

関数がグループとしてまとまって環をなすとか

**デフォルトの名無しさん** · 2016/01/10(日) 14:17:25.96

つか、sin(x)ってなんやねんw
引数無しのメソッドの話か？　それならsinは例として不適当だ。

sinを例にするなら、x.sin(value) か、sin(x, value) だろ。

**デフォルトの名無しさん** · 2016/01/10(日) 14:17:26.78

>>97
そりゃメソッドはオブジェクトに属するだろ。
メソッドとして位置付けるのが適切かどうかの議論をしてるんだよ。

**デフォルトの名無しさん** · 2016/01/10(日) 14:17:31.05

こういうシンプルな考えに基づくと、四角形と三角形は形状クラスから
派生すると思われる。
しかし、四角形オブジェクトと三角形オブジェクトの合成メソッドは、形状クラスあるいは
その派生クラスにあってはならないように感じる。
それは形状合成器クラスに、あるいは単純な関数であった方が良いように感じる。

**デフォルトの名無しさん** · 2016/01/10(日) 14:21:04.23

>>87
物理的構造物とは違うんだよ
それすら理解できないならもう向いてないとしか

**デフォルトの名無しさん** · 2016/01/10(日) 14:21:57.10

属すじゃなくて依存するだと思うが。

**デフォルトの名無しさん** · 2016/01/10(日) 14:25:29.45

例えばゲームでキャラクターが特定のアイテムを使用するモデル
キャラ.使う(アイテム)はもらうアイテムによってメソッドの動作を変える必要があるが
設計としてはアイテム.適用(キャラ)のが遥かに取り回しやすい
なのにあえて前者のクソ設計を選ぶのが>>87のようなオバカさん

**デフォルトの名無しさん** · 2016/01/10(日) 14:26:22.66

>>102
それならOOPの議論じゃないな。

>>105
いや、属する/所有するという概念の方が適当だと思う。（実装は違うが）
実際クラスを書くときそう書くだろ。

**デフォルトの名無しさん** · 2016/01/10(日) 14:44:22.50

>>101
現実の姿を模すという意味だとsinなどは連想配列であって、sin(x)という書き方はそのまんまだよね。
実装においては計算手続きだろうけど。

**デフォルトの名無しさん** · 2016/01/10(日) 14:48:45.22

Smalltalkerが引き上げたらもう初心者しか残ってないのかよ

**デフォルトの名無しさん** · 2016/01/10(日) 15:22:03.47

そもそもクラスだってオブジェクト指向とは直接関係ない
>>84
嘘ではなく現実だ

**デフォルトの名無しさん** · 2016/01/10(日) 15:23:27.70

美少女が云々言うのも一般的なクラスベースは融通が効かないねという話であって
オブジェクト指向とは直接関係ないし

**デフォルトの名無しさん** · 2016/01/10(日) 15:44:15.32

>>111
ほう、それならウンコをしない美少女をオブジェクト指向で設計して貰おうか

**デフォルトの名無しさん** · 2016/01/10(日) 15:50:56.07

>>97
見逃したいたが、x.sin(value)の value って何だい？

**デフォルトの名無しさん** · 2016/01/10(日) 16:06:27.16

>>113
引数だよ。
クラスxのメソッドsinに渡す引数。
俺はそういう話をしてると思ったから。

**デフォルトの名無しさん** · 2016/01/10(日) 16:18:07.80

xって中身は例えばfloatのデータ自身だぞ？
だから、引数は必要ないんだぞ？

**デフォルトの名無しさん** · 2016/01/10(日) 16:26:17.41

>>115
理解した。
それなら、x.sin() なんて形が出てくる余地は無いよな。

**デフォルトの名無しさん** · 2016/01/10(日) 16:29:21.43

一般に sin に必要な引数は、 pi/2 とかの実数(もしくは複素数) かな。
あとはいくつまでの級数和をとるとか何桁まで計算するとかが引数になるんじゃないかね。
その辺をあいまいなまま value とか x がクラスだの引数だの言ってることに何か意味があると思ってんのかね。

**デフォルトの名無しさん** · 2016/01/10(日) 16:34:25.26

>>117
いや、sinの引数がオブジェクトの場合はあるよ。
実数や10進型をクラスで表現したりするし、俺も実際やる。
xがそういうオブジェクトなら、sin(x)でいいし、x.sin()はおかしい。
まあ絶対におかしいとか無理ってわけじゃないけどなw

**デフォルトの名無しさん** · 2016/01/10(日) 16:54:55.24

新しいC++ではsin(x)でもx.sin()でも、どちらの方法でも統一的に呼び出せるようになる予定だから
こんな議論は全く意味ないんだよ？

呼び出す側からしたら、sinがメンバ関数だろうが外部関数だろうが、何であれ、知ったことではないからね
気にしなければならないのは実装する側だけ
だからどちらの方法でも呼び出せるようになる、らしい

どちらの方法でも呼び出せるんだから、喧嘩する必要ないし、気にする必要ないよね

**デフォルトの名無しさん** · 2016/01/10(日) 16:57:47.72

どちらの方法でも呼び出せるんだから
どちらの方が、よりオブジェクト指向的か、考えるのは意味がないんだよ
等しいわけ、等価と考えてよい
見た目が違うだけ
大した問題じゃない

**デフォルトの名無しさん** · 2016/01/10(日) 17:00:24.30

なんか違うような気がするなw

**デフォルトの名無しさん** · 2016/01/10(日) 17:07:10.06

こんなにややこしいプログラムがオブジェクト指向を使って
こんなに簡潔になりましたって事例が欲しい

**デフォルトの名無しさん** · 2016/01/10(日) 17:12:10.48

>>112
思うんだけど、
うんｋをしないというのが、
意思を持ってひたすら我慢して（人の目がある場所では）しないのか、
それとも腸内の美少女菌のおかげでする必要が無いのか、
もしくは他の何かなのかによってイメージが変わってくると思う。
でもしないにしろする必要がないにしろ、排便メソッド自体は備わっててもなんら問題ないと思う。
逆に、腸内やなんかの問題を解決せずに、排便メソッドだけ外して他を流用するということは、
オブジェクト指向的であろうがなかろうが不可能だと思う。
それこそ亞人として設計しなおして全ての手続やメソッドを別に用意することが妥当かもしれない。
だから結論を言うと、この例はそもそも良くないと思う。

**デフォルトの名無しさん** · 2016/01/10(日) 17:51:06.88

>>122
サイズを持っていてくれるのですら俺は嬉しいと思う
文字列や配列を扱うとき
int string::size() {return strlen(data);} // 数える関数を使うって例
↑こーいうのじゃなくて
int string::size() {return end - begin;} // 簡単な計算（ポインタの差分）で返す
int string::size() {return size;} // 内部でケアしていたprivate変数を返す
こういう実装をしうるのが嬉しい
使うときに
a = s.size * s.size / s.size % s.size
みたいにいっぱい呼び出しても安心
逆に言うとせっかく用意されたsizeメソッドが内部で数えなおしてる場合はつまらないと思う

**デフォルトの名無しさん** · 2016/01/10(日) 19:10:53.94

>>124
なるほどねー。

**デフォルトの名無しさん** · 2016/01/10(日) 19:16:06.37

>>112
美少女はマーカーインターフェースであり、
美少女として扱うとき排便は隠蔽される。

interface 美少女 {
}

class おっさん implements 美少女 {
　void 排便() {
　}
}

**デフォルトの名無しさん** · 2016/01/10(日) 20:20:59.69

>>126
それは「何もしない」という排便メソッドを持つ
持たない，ではない

**デフォルトの名無しさん** · 2016/01/10(日) 20:34:00.62

>>127
何を言うてんの？排便メソッドを持つのはおっさんだよ。

**デフォルトの名無しさん** · 2016/01/10(日) 20:41:36.36

聖水メソッドもないのに美少女とか笑わせんなよｗ

**デフォルトの名無しさん** · 2016/01/10(日) 21:17:46.16

オブジェクト志向の考えだと
大便ableインターフェースを実装するんだろ

**デフォルトの名無しさん** · 2016/01/10(日) 21:57:06.57

美少女クラスを欲する奴が美少女のウンコがついたぱんつを欲しがらないかと考えると
これは要件定義から間違っているような気がしてならない。

**デフォルトの名無しさん** · 2016/01/10(日) 22:05:43.79

実装からメソッド設計を考えるより使い方から設計したほうが上手く行くと思う
つまり美少女がうんこ出来るのか、出来ないのかで考えるのでは無く美少女にうんこをさせたいのか、うんこさせたくないのかで考える

**デフォルトの名無しさん** · 2016/01/10(日) 22:12:58.59

肛門はコンポーネントとしてアタッチする。
美少女は肛門をインプリメントしていない

**デフォルトの名無しさん** · 2016/01/11(月) 02:57:08.55

あのさ、どんな美少女もウンコするんだけど？

**デフォルトの名無しさん** · 2016/01/11(月) 03:08:27.43

真の美少女は実在しない

**デフォルトの名無しさん** · 2016/01/11(月) 03:18:02.16

>>134

http://youtu.be/_-KfZCZ4F0Q

**デフォルトの名無しさん** · 2016/01/11(月) 04:26:03.17

ｗ

**デフォルトの名無しさん** · 2016/01/11(月) 14:41:47.97

関数型言語っていい点もあるけど、変更に弱過ぎない?
ちょっと動作を変えるのにかなり見直さないといけない

**デフォルトの名無しさん** · 2016/01/11(月) 16:00:11.66

作りようだね

**デフォルトの名無しさん** · 2016/01/11(月) 17:41:31.97

>>138
関数型言語を使えば完璧なプログラミングが可能なので後から変更する必要が無い。

**デフォルトの名無しさん** · 2016/01/11(月) 17:50:34.21

>>140
完璧なプログラミングは出来ても
将来の仕様の変化を完璧に予測することは出来ないでしょ？

**デフォルトの名無しさん** · 2016/01/11(月) 17:53:14.36

仕様変更できないって実用上ヤバくないですか

**デフォルトの名無しさん** · 2016/01/11(月) 18:03:26.01

オブジェクト指向は細かい修正で済むと手を抜き続けた結果メチャクチャ悲惨なことになる
全て書き直すくらいがちょうどいい

**デフォルトの名無しさん** · 2016/01/11(月) 18:08:52.97

> メチャクチャ悲惨なこと

たとえば？

**デフォルトの名無しさん** · 2016/01/11(月) 18:13:38.40

>>144
全て書き直すはめになる

**デフォルトの名無しさん** · 2016/01/11(月) 18:18:05.61

関数型言語は仕様変更のたびにめちゃくちゃ悲惨なことをしなければならないのか

**デフォルトの名無しさん** · 2016/01/11(月) 18:31:28.27

言語の問題でなくて作ってる奴が馬鹿なだけでは？

**デフォルトの名無しさん** · 2016/01/11(月) 18:59:27.70

ただのリスト操作を関数型と呼んでいる可能性

**デフォルトの名無しさん** · 2016/01/11(月) 19:14:51.77

>>141
関数型なら完全に未来を予測できる。

**デフォルトの名無しさん** · 2016/01/11(月) 19:37:40.52

そらすげーわ

**デフォルトの名無しさん** · 2016/01/11(月) 19:38:18.20

>>149
そういうのいいから

**デフォルトの名無しさん** · 2016/01/11(月) 19:43:22.94

関数型言語はコンパイルした瞬間全てが完了される。

**デフォルトの名無しさん** · 2016/01/11(月) 19:46:13.85

コンパイルが通ればバグが無いことを保証される。

**デフォルトの名無しさん** · 2016/01/11(月) 19:47:17.32

>>153
それもいいから

**デフォルトの名無しさん** · 2016/01/11(月) 19:49:39.36

>>154
お前関数型馬鹿にしてんの？

**デフォルトの名無しさん** · 2016/01/11(月) 19:53:45.95

関数型言語にとって型とはプログラムの設計図なのである。

**デフォルトの名無しさん** · 2016/01/11(月) 19:55:09.91

>>155
関数型じゃなくてお前を馬鹿にしてるんだよｗ

**デフォルトの名無しさん** · 2016/01/11(月) 19:55:15.79

1000近くなった雰囲気だな