2016-05-21

http://anond.hatelabo.jp/20160302090242

http://kenokabe-techwriting.blogspot.jp/2016/05/timeengine.html

nonstarterの言うことがハッタリじゃなければ、さっさとToDoListの課題Ocaml関数型の状態渡しをもって実装してみせればいいだけだが、言い訳始めてるからな。

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

nonstarterはこの発言の時点では、Ocaml関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。

しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。

そのうち、OCaml実際的環境じゃスケールしないという指摘がはいる。

nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない!」ってことなんだろw

しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリお絵かきアプリを示して、

ついでに、ハードルを引き上げた。

nonstarterの言うとおり、

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

かつ、FRPも同じ複雑さへの限界ならば、

岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。

もちろん、他のHaskellFRPは使うな、という至極当然の縛りつき。

ちょっと本気出されたら、言い訳始めた、それが今。

http://anond.hatelabo.jp/20160520153948

OCamlでは」普通に副作用を使うライブラリしかいかスケールしない、って書いてあるのに

なんで勝手一般化して、Haskellとかでもスケールしないことにしたいの? 本当に牽強付会オンパレードですね。

そもそもの最初がesumiiやlambadaなどのOCamlユーザへむけての課題で、

nonstarterが、

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

と急に何故かいきなりHaskellを持ち出し、Haskellコードを引っ張り出した。

いろいろとっちらかしてんじゃねーよ、ってことだろ。

OCamlではライブラリも足りず机上の空論だったという、ひとつ区切りはついた。

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

とこの点について「一般化」を試みた、誤魔化そうとしたのは、nonstarterだ。

からごましてんじゃねーよ、ってそこをまず明確化されている。

記事への反応 -
  • 状態渡しはまやかしだ、とか時間を軸にしたストリームを外部に持ったFRPこそが正しく実用的な関数型、みたいに言うから反対されるって言ってんの。

    • 誰がいつ「まやかしだ」なんて言ってる? 「状態渡し」に限度がある、って認めたのは、nonstarter自身であり、その他、限界があるのに何でもできる、みたいな嘘をまきちらしているこ...

      • 普通に読んだら「FRPも状態渡しと同様の限界がある」と言ってる文章だし、 状態渡しで何でもできるなんて誰も言ってないのに、相変わらず凄まじい捻じ曲げだな。 http://qiita.com/nonstarte...

        • あのさ、それ もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用を使用せずに書くのもなんら困難ではありません。 とか、言い切って、別の人間からスケールしない、とつっ...

          • 「OCamlでは」普通に副作用を使うライブラリしかないからスケールしない、って書いてあるのに なんで勝手に一般化して、Haskellとかでもスケールしないことにしたいの? 本当に牽強付...

            • http://kenokabe-techwriting.blogspot.jp/2016/05/timeengine.html nonstarterの言うことがハッタリじゃなければ、さっさとToDoListの課題をOcamlの関数型の状態渡しをもって実装してみせればいいだけだが、言...

            • http://anond.hatelabo.jp/20160520153948 「OCamlでは」普通に副作用を使うライブラリしかないからスケールしない、って書いてあるのに なんで勝手に一般化して、Haskellとかでもスケールしない...

            • もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用を使用せずに書くのもなんら困難ではありません。 nonstarterはこの発言の時点では、Ocamlの関数型の状態渡しに限界があること...

            • http://kenokabe-techwriting.blogspot.jp/2016/05/timeengine.html nonstarterの言うことがハッタリじゃなければ、さっさとToDoListの課題をOcamlの関数型の状態渡しをもって実装してみせればいいだけだが、言...

      • 俺は書いた本人じゃないから違うかもしれないけど「限度」ってのはプログラマの能力的に、ってことじゃないの? 必要な情報は引数で全部渡して、中で書き換える(副作用)じゃなくて...

        • さんざん言われてることだが「状態渡し」について「原理」のことじゃなくて、実用的なアプリの実装の証拠が求められている。 岡部氏はすでに、FRPライブラリで実装してみせていて、...

          • お絵かきできてたじゃん…

            • お絵かき以上のレベルになったら、いろいろ言い訳しはじめて逃げてるのが今。 もうバレたんじゃない?書けるのならお前が書いたら?ToDoのアレ。状態渡しで。

              • そのお絵かきすらkenokabe氏は脳内FRP(実際には普通の命令型)でしか実装できてないのに…

                • 馬鹿がFRPのこと語るな、って書いたよな? おまえの脳内にはFRPなんて存在してねーだろ? そのお絵かきすらkenokabe氏は脳内FRP(実際には普通の命令型)でしか実装できてないのに…

      • 岡部式FRPが絶対に必要、と断言しておいて実際にすぐ実装されてしまったら 今度は「お絵かきアプリは簡単すぎたからこれをやれ」か。本当に勝手だな。

        • 今度は「お絵かきアプリは簡単すぎたからこれをやれ」か。本当に勝手だな。 そんな問題じゃないだろうな。 最近のブログにも書かれているのだが、 「お絵かきアプリ」は、批判...

記事への反応(ブックマークコメント)

ログイン ユーザー登録
ようこそ ゲスト さん