  |
はてなキーワード: FRPとは
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
で
まあ、すでに別の流れで、おまえにはFRP語るな、と釘さしておいたが。
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だ。
あのさ、それ
とか、言い切って、別の人間からスケールしない、とつっこまれた後だから。
最初の時点で「限界がある」と自覚しているのに、学習者や読者にむかって何も言わない隠し玉してたのか、
本気で何でもできると思ってたのかまでは不明。
いずれにせよ、突っ込まれて自ら限界を認めた。ついでにFRPの限界も同じに設定したっぽい。
岡部氏は、これは誤魔化しだとして、FRPで書いたコードを提示し、
岡部式FRPが絶対に必要、と断言しておいて実際にすぐ実装されてしまったら
私も専門家ではありませんがkenokabeさんよりはFRPもよく知っていると思いますし、
kenokabeさんのいうFRPが普通の世界でいうFRPとは全く違うこと、そして
kenokabeさんが決してそれを認めようとしないことはとてもよくわかりました。
言うだけ言うのはただだよねｗ なんもできてないし。
あの、処理系で「現在時刻が」って言いたかっただけのアホな人？
普通に読んだら「FRPも状態渡しと同様の限界がある」と言ってる文章だし、
状態渡しで何でもできるなんて誰も言ってないのに、相変わらず凄まじい捻じ曲げだな。
http://qiita.com/nonstarter/items/2763f5d85f2b8df3b18b
＞いずれにせよ、状態機械の数学的構成では状態遷移が状態と入力から状態への関数として表現されるというだけのことではあり（状態渡し）、状態遷移が複雑になれば状態遷移を純粋な関数として表現する作業も複雑になり困難になるので（そしてそれはしばしば綺麗な関数合成では上手くいかないようなものになることが多いので）、結局のところ少なくとも現状のFRPも（イベントのシグナルから状態のシグナルを構成する際に状態遷移をそうした関数で表現する必要が出てくるので）本質的には銀の弾丸にはならないと言わなければなりません（関数プログラミングで書けるということの恩恵はもちろんあるとしても）。
私も専門家ではありませんがkenokabeさんよりはFRPもよく知っていると思いますし、
kenokabeさんのいうFRPが普通の世界でいうFRPとは全く違うこと、そして
kenokabeさんが決してそれを認めようとしないことはとてもよくわかりました。
さんざん言われてることだが「状態渡し」について「原理」のことじゃなくて、実用的なアプリの実装の証拠が求められている。
岡部氏はすでに、FRPライブラリで実装してみせていて、机上の空論じゃにのなら、原理原則論じゃないのなら、法螺ふくとおりやってみせてみな、と課題が出ている。
ちなみに私の知っているFRPはHaskellの各種FRPライブラリとか
誰がいつ「まやかしだ」なんて言ってる？
「状態渡し」に限度がある、って認めたのは、nonstarter自身であり、その他、限界があるのに何でもできる、みたいな嘘をまきちらしていることが批判されている。
じゃあなくて、おまえの限定的な脳では、FRPなる世界は存在していない。
状態渡しはまやかしだ、とか時間を軸にしたストリームを外部に持ったFRPこそが正しく実用的な関数型、みたいに言うから反対されるって言ってんの。
大丈夫、
つまり作者の脳の中では関数型ということですね。よくわかりました。ありがとうございます。
おまえみたいにコードは書けるが、想像力が致命的で柔軟性が皆無なやつはおまえだけじゃないから。
関数型PGに時間のイミュータブル化した値を導入する、という意味が理解できないやつはいる。馬鹿は馬鹿で静かにして居れば良い。
そういう集団にとっては、FRPなるパラダイムはそもそもこの世の中には存在しない。おまえの世界に存在しえないものについてわかったフリして発言することが問題。
発言はするな。
