  |
はてなキーワード: FRPとは
第一に、それは、ストリーム（FRPの値の定義）の問題であって、ユニットテストすれば良い。もしくは単にFRPのログを取れば良い。
グローバル変数ではそういうことはできない。FRPでは、岡部氏のFRPライブラリも特にそうだけど、基本的にミュータブルな値同士が関数でリアクティブに連携されて常に整合性を保っているのだから、グローバル変数の、各所で更新されたそれぞれの値によって全体の整合性が損なわれないように気を配らなければいけないという（テスト自体困難な）問題は発生しない。それがFRPの唯一とも言えるメリットだとも言える。
使用する関数の問題じゃないし、「印」として引数に加えても別に構わないと思うが、君のいうグローバル変数の問題と一緒というのはまったく違う。
いや、それがそもそもの発端であるとブログの経緯には書かれている。説明されている方式でGUIアプリまで書けるのか？と疑念が呈されたことがきっかけ。
この論点は聞いたことがない。岡部氏がこだわっているのは非手続き型の宣言型で、純粋がどうとか議論はされてないように思う。
あと、OCamlでGUIを状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね？
原理的に可能かという議論ではなく、実用的な範疇か？という議論。反対派ブログで出てきたコードは、本人が認めるように普通のやり方ではなく、実用的なコードだとは思えない。あと、FRPと状態渡しは同じ複雑さだという主張も崩されている。そこが重要。
段階を踏んだ上で、非FRPのHaskellのIOモナドのコードを誰かが書いたらいんじゃない？当面、最初はOCamlの話だったのに、いきなりHaskellやElmのコードで書いて、そういうのがごちゃまぜに、何がどの言語でできるのかできないのか、誤魔化しがあると見做されたから制限されたんでしょ。実際には、OCamlの関数型では冗長でしか書けないと実証されたけど、そういうのがバレないように、別の言語を利用していたと看破されて当然の状況だと俺は思うね。
関係ある。君ひとりは、そうじゃない、と君ひとりが言ってもそれが本当だとは確認のしようがないし、
定数って、プログラム中で更新不可能で、いつ読みだしても同じ値が出てくるから、グローバルでも問題無いんだよ。
ストリームは定数だ、って言ってみたところで、プログラム全体から更新可能なんじゃ、グローバル変数と同じでしょ？
バグがあって、ストリームに変な値が入った時、どこがバグなのか、追跡するのが困難でしょ？
なんで伝わらないんだろ。
複数人でプログラム開発したり、他人のプログラムをデバッグしたり、したこと無いんだろうか。
「純粋関数型」とは何か、という話と、とOCamlでそれが推奨スタイルか、って別の話だよね？
岡部氏との争いって「OCamlでGUIアプリを純粋関数型(状態渡し)で簡潔に書けるか」ってところじゃないよね？
純粋関数型とは何かといった時にHaskellのように、IOも含めて引数と戻り値で表現する、関数のふるまいが関数の外の状態に依存しない、関数に副作用が伴わないとかの性質をいうと思うんだけど、岡部氏はFRPで状態を関数の外部に持ってても純粋関数型だ、と言ってて、そこで争ってるんだよね？
あと、OCamlでGUIを状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね？
Haskellで書けて、OCamlで冗長になっても、書けるなら「書ける」、「可能」だよね？
その発言が事実か確かめる術はないし、ここで岡部氏攻撃しているのは君ひとりなのか？他の人間まで一連の誹謗中傷集団ではない、す駱駝、住井が含まれていないみたいに断言する根拠は何か？
俺の書き込みが他人といきなり結び付けられたから、電波だな、と思ったの。
ReactはJavaScript界隈の関数型プログラミング化の潮流で登場。
最近、炎上している別の方面で、特にFRPと組み合わせると圧倒的なパワーを発揮すると一部では実例とともに指摘されている。
http://kenokabe-techwriting.blogspot.jp/2016/05/frptimeenginereactjsocaml.html
Reactは、関数型あるいは宣言型に書けるように用意されている。DOMは、「仮想DOM」として、JS（JSX）上の「値」として統合されていて、それは自由に変形し、組み合わされ、リアクティブにJSX上の仮想DOMから実DOMにリアルタイムでマッピングされ描写される。
JQueryも、実DOMを関数型で操作できるような拡張ではあるが、Reactのように宣言的に書くことは不可能。
coffee scriptは、ES6登場までの過渡期の橋渡しみたいなもので、登場したのも消えたのも合理性がある。
React.jsは、関数型の潮流で登場したものでこれも合理性があり、この延長線上でさらに洗練された代替物が登場する可能性はあれど、このパラダイムが消えることはない。
否。ストリームに限らず、定数は引数で与えなくても純粋関数型である、という見解はごく普通。
つまり、GUIになればもはや関数型では書けない、というのが推奨スタイルだ、って言ってるようなもので、OCamlベースでいくら関数型の講義やっても、最終的にはその関数型でまともなGUIアプリすら書けない、という批判でしょ。その批判が岡部氏からされたら、あたかも関数型で書ける、という強弁から生まれたのが「状態渡し」理論。それが無理筋だ、ということが今回実証された。
その発言が事実か確かめる術はないし、ここで岡部氏攻撃しているのは君ひとりなのか？他の人間まで一連の誹謗中傷集団ではない、す駱駝、住井が含まれていないみたいに断言する根拠は何か？
あのね、グローバル変数の欠点とは、それが「変数」だからなの。
ストリームを関数の外部に持つFRPを純粋関数型っていうのは少数派でしょ。
ユーザからの入力をリアルタイムに処理するプログラムにはFRPは有効だよね。
「OCamlでは」じゃないの？
全部純粋関数型(引数と戻り値に収める、状態渡し)にするのを良しとするHaskellと違って、OCamlは副作用も部分的に使うのが普通で、IOモナドみたいな入出力までも純粋に書くための道具立てが揃ってない、それでちょっと冗長になる、ってことでしょ？
OCamlの元々の推奨スタイルならもっと短く書けるんでしょ？
俺はそう読んだけど。
それっぽい書き込みほどそうやって、事実誤認だ、と強調するから、なんで当事者でもないのに、そんなことが断言できて、電波だということになるんだ？
だって駱駝でも住井でもない面識も無い俺の書き込みが住井扱いされるんだもの。
いやだから、どの関数で読み書きされようと、誰が書き換えようとも、時間にたいしてイミュータブルな定数なんだから、定数は定数なのよ。
関数型という枠組みを拡張しているのではなく、関数型という枠組みの中にミュータブルな時間要素が純粋に収まるようにしているのがFRPだろ。「関数型を拡張してるから」というのは、また独自拡張だ、という批判を許すし、FRPが関数型の拡張だというのは誤解を招くし、語弊もある。
いやそもそも岡部氏が複雑なアプリになるとFRPが必要だ、と批判すると状態渡しで充分だ、という反発があった。それが誤魔化しだとして、今に至るし、否定されているから一連のブログでの徹底的なまでの反撃がなされている。
事実、「駱駝」は「状態渡しはむしろ異常」って書いた上に、岡部氏のコードの倍の分量の複雑なコードしか示せなかった。あの無理して書いたのが第三者にもまるわかりの状態渡しの実装って間違ってるんじゃないの？
これまでのアンチ岡部のやり方を眺めていると、被害者の岡部氏の分析には一定の信ぴょう性が認められるよね？
しかも、それっぽい書き込みほどそうやって、事実誤認だ、と強調するから、なんで当事者でもないのに、そんなことが断言できて、電波だということになるんだ？という素朴な疑問がある。当事者だから否定してるんだろ、と誰が見てもおもうだろ。
ストリームだから定数とか、過去の値保存してるから定数とか言ってみたところで、プログラム内の色んな関数から読み書きされる可能性があって誰が書き換えたか中身読まないとわからないんじゃ、グローバル変数使ってるプログラムの欠点をそのまま持ってるじゃん
いやだから、どの関数で読み書きされようと、誰が書き換えようとも、時間にたいしてイミュータブルな定数なんだから、定数は定数なのよ。
FRPライブラリのサブタイトルに、 library that provides first class reactive value 'over time' と書かれている、これ拡張じゃないのか？
拡張なら「関数型的じゃない」っていわれたら「関数型を拡張してるから」って答えればいいだけの話
「これが正しい関数型でお前らの状態渡しは間違ってる」みたいに言うから荒れる
間違っている電波だ
個人的に電波だと思うのはこういう匿名の書き込みを住井だ駱駝だ言い出すところ
ストリームだから定数とか、過去の値保存してるから定数とか言ってみたところで、プログラム内の色んな関数から読み書きされる可能性があって誰が書き換えたか中身読まないとわからないんじゃ、グローバル変数使ってるプログラムの欠点をそのまま持ってるじゃん
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://okaml.blogspot.jp/2016/05/done2.html#more
↓
kenokabe氏に、
JavaScript+React+TimeEngineのFRP : 29行
kenokabe氏のFRPじゃ半分以下のコードで実装できたと、トドメをさされて終了
http://kenokabe-techwriting.blogspot.jp/2016/05/frptimeenginereactjsocaml.html
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だ。
