  |
はてなキーワード: 岡部とは
ストリームを関数の外部に持つFRPを純粋関数型っていうのは少数派でしょ。
ユーザからの入力をリアルタイムに処理するプログラムにはFRPは有効だよね。
「OCamlでは」じゃないの？
全部純粋関数型(引数と戻り値に収める、状態渡し)にするのを良しとするHaskellと違って、OCamlは副作用も部分的に使うのが普通で、IOモナドみたいな入出力までも純粋に書くための道具立てが揃ってない、それでちょっと冗長になる、ってことでしょ？
OCamlの元々の推奨スタイルならもっと短く書けるんでしょ？
俺はそう読んだけど。
それっぽい書き込みほどそうやって、事実誤認だ、と強調するから、なんで当事者でもないのに、そんなことが断言できて、電波だということになるんだ？
だって駱駝でも住井でもない面識も無い俺の書き込みが住井扱いされるんだもの。
いやだから、どの関数で読み書きされようと、誰が書き換えようとも、時間にたいしてイミュータブルな定数なんだから、定数は定数なのよ。
関数型という枠組みを拡張しているのではなく、関数型という枠組みの中にミュータブルな時間要素が純粋に収まるようにしているのがFRPだろ。「関数型を拡張してるから」というのは、また独自拡張だ、という批判を許すし、FRPが関数型の拡張だというのは誤解を招くし、語弊もある。
いやそもそも岡部氏が複雑なアプリになるとFRPが必要だ、と批判すると状態渡しで充分だ、という反発があった。それが誤魔化しだとして、今に至るし、否定されているから一連のブログでの徹底的なまでの反撃がなされている。
事実、「駱駝」は「状態渡しはむしろ異常」って書いた上に、岡部氏のコードの倍の分量の複雑なコードしか示せなかった。あの無理して書いたのが第三者にもまるわかりの状態渡しの実装って間違ってるんじゃないの？
これまでのアンチ岡部のやり方を眺めていると、被害者の岡部氏の分析には一定の信ぴょう性が認められるよね？
しかも、それっぽい書き込みほどそうやって、事実誤認だ、と強調するから、なんで当事者でもないのに、そんなことが断言できて、電波だということになるんだ？という素朴な疑問がある。当事者だから否定してるんだろ、と誰が見てもおもうだろ。
ストリームだから定数とか、過去の値保存してるから定数とか言ってみたところで、プログラム内の色んな関数から読み書きされる可能性があって誰が書き換えたか中身読まないとわからないんじゃ、グローバル変数使ってるプログラムの欠点をそのまま持ってるじゃん
いやだから、どの関数で読み書きされようと、誰が書き換えようとも、時間にたいしてイミュータブルな定数なんだから、定数は定数なのよ。
＞オブジェクト指向と対比して考え方をまず学ぶって、岡部路線、住井グループはそれを目の敵にしていて集団的に攻撃している様をみたプログラミングコミュニティは逃げ、その後、不毛な大地のみが残った。
同意。俺が住井某を嫌い、岡部推しなのは、考え方を重視する姿勢や他人の自由な発想を押さえ込んでいるから。本人はそんなことしていないと言うだろうが、「哲学は関数型と関係ない」とFAQで堂々と言い切ったり、SNSその他でアンチ岡部と連携して攻撃を加えているのをしっかり見続けていたから。
FRPライブラリのサブタイトルに、 library that provides first class reactive value 'over time' と書かれている、これ拡張じゃないのか？
https://www.npmjs.com/package/timeengine
IOモナドをDisってるのかどうかまでは知らない。しかし、すでに出たサンプルからはFRPの効力がまざまざと見せつけられている。
荒れるのは自由だけど、両方正しいとかそういうのじゃなくて、間違っている電波だみたいな叩きしかなくて、要するに感情論で反対派は反発しているだけでOK?
あるよ。
関数がどのパラメータに依存して、何を結果として返すのか明確になる。
グローバルな値を参照したり書き換えたりしてたら、関数の中身読まないとわからなくなる。
短いプログラムならそれでもいいけどね。
別の誰かが書いてたように、上位スコープ内に定義されてるDOMでも、数学ライブラリでもなんでも、引数で関数に渡すのか？
グローバルな値を参照したり書き換えたりして
いやだから、定数なんだから書き換わらないんだよ、FRPのストリームはconst 定数なんだから。
オブジェクト指向と対比して考え方をまず学ぶって、岡部路線、住井グループはそれを目の敵にしていて集団的に攻撃している様をみたプログラミングコミュニティは逃げ、その後、不毛な大地のみが残った。
FRPを純粋を理想とする関数型+時間で変化するストリームを値にマップして扱うリアクティブプログラミングの組み合わせっていうなら、別に誰も反論しないと思うけど。
HaskellのIOモナドみたいな別の抽象化をDISりつつ、FRPこそ正しい関数型みたいに言うから荒れるんじゃないの？
あるよ。
関数がどのパラメータに依存して、何を結果として返すのか明確になる。
グローバルな値を参照したり書き換えたりしてたら、関数の中身読まないとわからなくなる。
短いプログラムならそれでもいいけどね。
「岡部氏のFRP」ではなくて、FRPっていうのはそういうもの。
俺も岡部氏のコード見ながら、この点考えてみたが、時間依存のFRPの値を__TIMEVALUEのようなひとつのオブジェクトにまとめて、逐一すべての関数の引数に加えれば？と思ったが、全部の時間依存の関数にそういうことをする意味はない、岡部氏のコードは、反対派ブログに書かれているコードよりも可読性が高く、コード量も半分とか圧倒しているし、「状態渡し」ではアプリは作れない、というのも岡部氏が正面切って批判するまで誰もはっきりと言わなかったことも反対派の信用性がない理由。それに「岡部氏のFRP」とか文句言う反対派の理解が怪しいと俺も思うようになった。
このように何か処理を実行した際に、入力として受けつけたデータ以外の物が変化することを"副作用がある"と表現するようです。
この辺でさ、岡部氏のFRPは、時間軸を持つストリームとしての値っていうのを、特別扱いして外部に持ってるわけじゃん？
反対してる人は、状態を外部（関数の引数でも戻り値でも無い所）に持つのは関数型的でない、って言ってたわけじゃん？
岡部氏は時間はグローバルなのが当たり前、引数と戻り値で表す必要はない（全てを引数と戻り値で表現する「状態渡し」ではアプリは作れない）って立場じゃん？
現実に岡部氏を高く評価している特定の人たちも知っていますが、住井某その他の強弁に騙されるような馬鹿なプログラマーばかりではないということです。
関数型プログラミングはまず考え方から理解しよう
http://qiita.com/stkdev/items/5c021d4e5d54d56b927c
Qiitaにこのような記事が登場するまで長い時間がかかりました。
なんとかFAQが参考になる、なんてもう誰も思ってないのでは？
http://kenokabe-techwriting.blogspot.jp/2016/01/qiita-esumiicamloeba8.html
いかんせん、Qiita以降の奴しか知らないので、不慣れなところはレギュラーが極力、バックアップ願います。
8賢枠 （暫定） 2015/10/02
・知の答弁人田中
・（空席）
以上。
「辣腕ギークのキャメル 」と@tikuwa_zeroてーとくより拝命されてたことが暴露されてた。
さすがにバレバレなので、本人の希望でNewbie伊藤 ◆p02ZTYXhPKG5として現在も２chの岡部スレで大活躍中。
AIG(A-Jiro is Guru) は仲間のEijiro Sumii / 住井 英二郎 - 小林･住井研究室だろう。
http://kenokabe-techwriting.blogspot.jp/2016/01/qiita-esumiicamloeba8.html
いかんせん、Qiita以降の奴しか知らないので、不慣れなところはレギュラーが極力、バックアップ願います。
8賢枠 （暫定） 2015/10/02
・知の答弁人田中
・（空席）
以上。
「辣腕ギークのキャメル 」と@tikuwa_zeroてーとくより拝命されてたことが暴露されてた。
さすがにバレバレなので、本人の希望でNewbie伊藤 ◆p02ZTYXhPKG5として現在も２chの岡部スレで大活躍中。
AIG(A-Jiro is Guru) は仲間のEijiro Sumii / 住井 英二郎 - 小林･住井研究室だろう。
恥ずかしい真似というのは、岡部氏を叩く２ちゃんねるスレッドに、税金をもらっている東北大学の教育者が恥ずかしげもなく書き込み、
AIG（Ajio is Guru）のようなミッションネームを与えられ、七賢者だのもちあげられていて喜んでいる真似のことだろう。
Haskellの""real world""についての等式が「代入」ならば、おまえにとっての「代入」はそれで良いのだろう。
別の言い方をすると、
仮にCが純粋関数型言語で、岡部式FRPのx.t=x.t+1;も関数型なんだったら、C言語のx=x+1;も関数型だよね。
岡部氏の本でさんざん「x=x+1;は論理破綻」って批判してたのは何だったんだろう。
頭悪いよな。
あのね、FRPについて、何かが認められている、何かの合意があるみたいなことを言ってるのだけど、
岡部氏が出したCornelEliottのいうFRPは、ことごとく他のFRPと自分の考えが違う、と各所で表明していて、
Haskell.org https://wiki.haskell.org/Functional_Reactive_Programming を見ても
The basic idea is that a time-varying value can be represented as a function of time:
newtype Behavior a = Behavior { at :: Time -> a }
http://kenokabe-techwriting.blogspot.jp/2016/05/timeengine.html
nonstarterの言うことがハッタリじゃなければ、さっさとToDoListの課題をOcamlの関数型の状態渡しをもって実装してみせればいいだけだが、言い訳始めてるからな。
nonstarterはこの発言の時点では、Ocamlの関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。
しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。
そのうち、OCamlの実際的な環境じゃスケールしないという指摘がはいる。
nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない！」ってことなんだろｗ
しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリでお絵かきアプリを示して、
ついでに、ハードルを引き上げた。
nonstarterの言うとおり、
岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。
もちろん、他のHaskellやFRPは使うな、という至極当然の縛りつき。
http://anond.hatelabo.jp/20160520153948
そもそもの最初がesumiiやlambadaなどのOCamlユーザへむけての課題で、
nonstarterが、
と急に何故かいきなりHaskellを持ち出し、Haskellのコードを引っ張り出した。
いろいろとっちらかしてんじゃねーよ、ってことだろ。
OCamlではライブラリも足りず机上の空論だったという、ひとつの区切りはついた。
とこの点について「一般化」を試みた、誤魔化そうとしたのは、nonstarterだ。
http://kenokabe-techwriting.blogspot.jp/2016/05/timeengine.html
nonstarterの言うことがハッタリじゃなければ、さっさとToDoListの課題をOcamlの関数型の状態渡しをもって実装してみせればいいだけだが、言い訳始めてるからな。
nonstarterはこの発言の時点では、Ocamlの関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。
しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。
そのうち、OCamlの実際的な環境じゃスケールしないという指摘がはいる。
nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない！」ってことなんだろｗ
しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリでお絵かきアプリを示して、
ついでに、ハードルを引き上げた。
nonstarterの言うとおり、
岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。
もちろん、他のHaskellやFRPは使うな、という至極当然の縛りつき。
http://anond.hatelabo.jp/20160520153948
そもそもの最初がesumiiやlambadaなどのOCamlユーザへむけての課題で、
nonstarterが、
と急に何故かいきなりHaskellを持ち出し、Haskellのコードを引っ張り出した。
いろいろとっちらかしてんじゃねーよ、ってことだろ。
OCamlではライブラリも足りず机上の空論だったという、ひとつの区切りはついた。
とこの点について「一般化」を試みた、誤魔化そうとしたのは、nonstarterだ。
nonstarterはこの発言の時点では、Ocamlの関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。
しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。
そのうち、OCamlの実際的な環境じゃスケールしないという指摘がはいる。
nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない！」ってことなんだろｗ
しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリでお絵かきアプリを示して、
ついでに、ハードルを引き上げた。
nonstarterの言うとおり、
岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。
http://anond.hatelabo.jp/20160520153948
nonstarterのいうことが嘘ハッタリじゃないのならば、さっさとOCamlの関数型状態渡しでToDoリストアプリ書いて見せればいいだけ。
出来ない時点で終わってる。
nonstarterはこの発言の時点では、Ocamlの関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。
しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。
そのうち、OCamlの実際的な環境じゃスケールしないという指摘がはいる。
nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない！」ってことなんだろｗ
しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリでお絵かきアプリを示して、
ついでに、ハードルを引き上げた。
nonstarterの言うとおり、
岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。
もちろん、他のHaskellやFRPは使うな、という至極当然の縛りつき。
そもそもの最初がesumiiやlambadaなどのOCamlユーザへむけての課題で、
nonstarterが、
と急に何故かいきなりHaskellを持ち出し、Haskellのコードを引っ張り出した。
いろいろとっちらかしてんじゃねーよ、ってことだろ。
OCamlではライブラリも足りず机上の空論だったという、ひとつの区切りはついた。
とこの点について「一般化」を試みた、誤魔化そうとしたのは、nonstarterだ。
