「自分たちに都合の悪い岡部への弁護」は「岡部の自作自演」みたいな都合の良い決め付けはやめなさい。全部のやりとりを引用するとhttp://anond.hatelabo.jp/20160518164005状態を変数に持つ必要はない、というところは伝わってるのかな状態を引数で与えて新たな状態を得る、という形で書ける、とそのほうが関数型的、というと反発するんだろうけど岡部氏もやろうと思えばそういう風に書けるんじゃないの?http://anond.hatelabo.jp/20160518170332そんな「状態渡し」の話はもう周回遅れでとっくに終わってる。複雑なGUIアプリを関数型で「状態渡し」で書いたら、そのうちスケールしなくなる、ってのは例の当事者が認めてて、FRPに話がようやく移ったのが今。http://kenokabe-techwriting.blogspot.jp/2016/05/timeengine-frp.htmlhttp://anond.hatelabo.jp/20160518171946まあお絵かきは綺麗に書けるってことでいいんじゃないの?そんで岡部氏のFRPでは綺麗に書けて、状態渡し派の関数型には書けない次なるお題でとどめを刺せばいいんでは?と言う感じです。岡部は孤立している、要するにそういう図式を堅持したい、という魂胆はいつもミエミエでわかりやすいですが、自分の信じたい世界を作り上げる、自分の都合の悪い真実については、岡部の妄想というのもわかりやすいです。他にもこんな書き込みがあります。自称関数型コミュニティの圧力を恐れて、表立って肯定できない」とのことです。「nonstarter氏や住井教授のようなエントリの内容は、日本国内でのみ少数の合意が得られてるに過ぎず、海外では主流ではない。国内ネットでは、地雷、滅多なことを言わないほうがいいという風潮がありました。「純粋関数型」が何か?というさえ、海外では関数型プログラミング界隈の著名人、たとえば岡部さんが引き合いに出す論文のエリオットはじめ、合意が取れていません。http://conal.net/blog/posts/the-c-language-is-purely-functiona「nonstarter氏や住井教授のようなエントリの内容は、日本国内でのみ少数の合意が得られてるに過ぎず、海外では主流ではない。」よって、これは岡部さんのほうが公平な現実について発言しており、が正しいと判断します。住井さんをはじめ、岡部さんが批判する相手は、議論となっている関数型プログラミングの定義などが、まるで世界的に合意がされており岡部さんのみが異端だという主張ばかりしており、あまり信用できません。自分の言っていることが正しい、と断定的に論じているところです。functional「純粋関数型」についての議論です。Elliottについては、私もその発言について信頼しており引用してみます。Iryは、同じ理由でErlangは関数型ではない、という結論も出せる、答えた。関数型言語ではないとサジェストしたいというものだった。かわりに、C言語も純粋関数型であるということをここで説明しようと思う。absurd.これはある質問にたどりつく:じゃあHaskell+IOというのは、純粋関数型言語なのか?もちろんそうだ。その先行者であるC(正確に言うとC++)も同じ程度にそうなのだが。訳知り者はこう文句言うことだろう:Haskell+IOのみが唯一「テクニカル」に純粋である、と。私はこう返すしか無い、ではその場合、Cプログラムのみが唯一唯一「テクニカル」に純粋である、と。コメント欄もふくめて、要するに明確な合意に至っていない、ということは普通にわかります。むけて、まるで学会で明確な合意がなされており確固たる「一般的説明」があり、私のような「別の意見」を表明すると、「勉強しろ」だの「独自見解」で「合意と違う」という嘘を平気で押し付けてくることです。参照透明性これらの用語は、別のものと定義されているようだ、しかし、自分はいつもお互いがお互いを暗喩的に意味しているように考えている。「ある表現が参照透明であって、純粋でない」というケースがおもいつかないし、逆方向についてもそうだ。appreciated.なんか、その純粋性と参照透明性についての違いみたいなものを理解できる、もっと単純な方法はないのか?「違い」みたいなものがあれば、明確に表現している例を教えてくれるとありがたい。success.)もし、自分の知り合いの3人の理論家を集めたら、少なくとも、2人は、「参照透明性」という用語について合意しない。it.わからない、でも、アドバイスできることとして、「あきらめなさい」、なぜならば、インテリ言語学者の少数集団でさえ、それが何を意味するのか合意できていない。「参照透明性」っていう用語は役立たずだ。・・・・という感じです。「純粋関数型」っていう概念を「参照透明性」という用語、概念をもって説明しようとするものであり、わかったようなわかってないような人らを量産しています。その上、たとえば、http://anond.hatelabo.jp/20160516112619kenokabeさんの心の中ではそうなのかもしれませんが、ライブラリのユーザから客観的に見れば(分析哲学ではなく関数型言語の意味で)参照不透明なので、関数型プログラミングのメリットは享受できない、命令型の破壊的代入と等価ですね。参照不透明だから→関数型プログラミングではない、論法を取っています。参照透明性」っていうのと「分析哲学での参照透明性」の違い、なんて、まともに合意なんてされていません。この人物も適当に「(分析哲学ではなく関数型言語の意味で)参照不透明」とか、「この人物の心の中」での「参照透明性」を語っているにすぎません。わからないことを、あたかもわかっているように断じる、これがこの連中の悪い癖です。ああ、ちなみに、この私のFRPライブラリは参照不透明?で、命令型の破壊的代入っていう中傷について、またしばらく後にエントリします。あたらしい課題つきで。「これ以上は説明も回答もしない。」という嘘説明のFRPの基本原理コードなるものこの辺の続きとなります。この際、成り行き上かなり「気が向いた」ことと、延々と悪質な連中の(真性の天然の可能性もあるにはあるが、相手は複数であるし、総体としては多分わかって誤魔化している)誤魔化しがまかり通っていることを再確認したし、いろいろ中傷(嘘,誤魔化しをしている自覚があれば批判でなく中傷だ)してる君らに、改めて課題を出しておこうと思います。第三者による書き込みhttp://anond.hatelabo.jp/20160518171946まあお絵かきは綺麗に書けるってことでいいんじゃないの?そんで岡部氏のFRPでは綺麗に書けて、状態渡し派の関数型には書けない次なるお題でとどめを刺せばいいんでは?を目撃して、「なるほどそのとおりだ」と思ったこともあります。「お絵かきアプリ」にしても、直近の自作FRPライブラリ=TimeEngine公開後も、こちらから提示するまでもない、と思っていた、というか連中の妄想、思い込み度合いを見くびっていたことがあり、この際きちんと白黒つけるべきだと思いました。無理なら別にやらなくていい。君らが言い連ねているのは、机上の空論だから。机上の空論じゃない、と証明できる場合のみ、今回の課題をクリアしてみせてくれれば良い。その前に、この「机上の空論」の議論について、今回の課題にむけて、これまでの経緯の復習も兼ねて、重複、再掲する部分多々ある形式で、前提をまとめてみます。英二郎@esumiiさんとか、らくだの卯之助@camloebaさんに聞きたいのだけど、そもそも貴方たちはOCamlでデスクトップアプリ書けるんですか?と題するエントリにおいて、こう書いた。デスクトップのアプリをOCamlで書いて見せてくださいよ。議論はしなくて良いから。「疑似科学者」なんて罵倒するなら、自分で証明しろ、って思いますね。個人的に、OCamlを振り回して、国内で関数型プログラミングで、なんかこういう、私の主張にたいしても上から目線で偉そうにごちゃごちゃ文句いってくる連中が、GUIアプリ書いてる事象を目撃したことがこれまで一度もない。なんで?まあ、技術者ならば、科学的精神をリスペクトするならば、らくだの卯之助‏@camloebaさん、あなたが自身の関数型プログラミングのスキルが「机上の空論」でないことを示してください。追記(2015/05/30):デスクトップアプリケーション??(当該の記事で著者がOCamlで「お絵かきロジック」を実装してみせよと要求する一方で自身ではJavaScriptによるそれを公表していない点も気になります)。OCamlであれHaskellであれ破壊的代入の類の副作用を使用せずに書くのもなんら困難ではありません。「OCamlで「お絵かきロジック」を実装してみせよと要求する」ときちんと要件は理解しているようでした。OCamlであれHaskellであれ破壊的代入の類の副作用を使用せずに書くのもなんら困難ではありません。言いながら、なぜか急にHaskellのコードが貼り付けらら得ており、Haskellのお絵かきアプリのコードしか書いていない。なにかと、elmのコードを持ち出してくる。あのね、OCamlの関数型のコーダに向かって、OCamlで実用的なアプリを書けるのか?と確認しているのに。お絵かきアプリ(関数型リアクティブプログラミング/FRPのトイプログラム)にもすでに書いたけれど、(追記:コメント欄にてyataketa9056さんに、既存のGUIライブラリを前提にスケールするコードを書こうとするとOCamlでは困難であろうという指摘を頂いています。利点はともかくHaskellと同じようにモナドを利用したライブラリを作成するなら純粋な関数型でのプログラミングも可能になる(けれどもOCamlプログラミングとしてはわざわざそのようなことをしても嬉しくはない)ということになります。いえ原理的に不可能でないのなら(そして不可能でないので)、純粋な関数プログラミングでGUIアプリケーションを作成するのにFRPがなんら必要でない、という趣旨には充分です。この主張自体はHaskellでのコードによっても充分に示されています。)とまた「原理的に不可能でない」などという「机上の空論」を自覚ない天然なのか、わざとやってるのかわらからないけれど、繰り返している。畳み掛けるように、いずれにせよ、状態機械の数学的構成では状態遷移が状態と入力から状態への関数として表現されるというだけのことではあり(状態渡し)、状態遷移が複雑になれば状態遷移を純粋な関数として表現する作業も複雑になり困難になるので(そしてそれはしばしば綺麗な関数合成では上手くいかないようなものになることが多いので)、結局のところ少なくとも現状のFRPも(イベントのシグナルから状態のシグナルを構成する際に状態遷移をそうした関数で表現する必要が出てくるので)本質的には銀の弾丸にはならないと言わなければなりません(関数プログラミングで書けるということの恩恵はもちろんあるとしても)。いうように、とにもかくにも、(状態渡し)に固執しながら、でもいちおう(状態渡し)の限界を別のひとから指摘されたから、それは一応発現する、でもなおFRPの否定にやっきになる、まったくもってわけのわからない理由で。状態遷移が複雑になれば状態遷移を純粋な関数として表現する作業も複雑になり困難になるそしてそれはしばしば綺麗な関数合成では上手くいかないようなものになることが多いということです。この捨てアカウントの人物はその程度の理解と自覚はしっかりあるようですし、ここまでは言ってる意味はわかるし、普通に正しい(それ以降は全部間違っていますが)。彼が言ってる正しい部分をまさに私は指摘している。それは根本的に、時間遷移の概念を関数型のパラダイムに抽象化したFRPを適用していないのが問題なのであって、あんたらはそんなことは一切触れずに、まるで、「(状態渡し)」で最終的になんでもできるかのように、初学者に向けても説明してるじゃないか、というか、実際、OCamlで実用的なデスクトップアプリを書いてるのみたことないけど、できるの?そんなに言うなら書いて見せてよ?、、、というところまでが、私の「問題提起」なのでした。結局のところ少なくとも現状のFRPも本質的には銀の弾丸にはならないと言わなければなりません(多分何がなんでも自分の理解を超える要素は否定したいと大風呂敷を広げる)一応とってつけた理由:(イベントのシグナルから状態のシグナルを構成する際に状態遷移をそうした関数で表現する必要が出てくるので)???????意味不明。この人物がFRPが何たるか理解していないのは、ほぼ確実でしょう。FRPの本質は「時間軸」のプログラミング言語上での抽象化であり、なんかわけわかりませんが、この一連の議論で、FRPという言葉さえでてくるも、「時間」とか言っているのが私ただひとりだけ、という非常にわけのわからない、もとい、ある意味、連中がどういう知見レベルをもって当方を批判、あるいは中傷しているのかが非常にわかりやすい状況です。http://stackoverflow.com/questions/1028250/what-is-functional-reactive-programmingにおいて、こう宣言しています。動的に時間発展する値(つまり時間軸上の値)はファーストクラスである、ということです。「いずれにせよ、状態機械の数学的構成では状態遷移が状態と入力から状態への関数として表現されるというだけのこと」とか、そういうおはなしとは全く別の話題ですし、FRPでは「(イベントのシグナルから状態のシグナルを構成する際に状態遷移をそうした関数で表現する必要が出てくる)」なる言及は、FRPのパラダイムを論じる上で意味を成しません。(関数プログラミングで書けるということの恩恵はもちろんあるとしても)。これもどういう意味なのか全く意味がわかりません。力づくで理屈を捻じ曲げても、とにかくFRPという彼にとっては新しい未知の概念の導入なんて無意味だ、ということを力説したいという熱意だけは伝わってきます。ちなみに、大した意味はありませんが、敢えてFRPライブラリ(Reactive-Banana)を使うとこうなります:大した意味がないどころか、FRPライブラリを導入するということは、時間軸上の展開している値をファーストクラスにして、時間発展する系を関数型プログラミングの枠組みで統一的に取り扱えるようにする、という甚大なパラダイムの変化であり、大きな意味があります。FRPライブラリを使ってもコードが先のものと殆ど変わらないことに注意してください。要するにこれらのコードの本質は状態遷移を純粋な関数(ここではeTrans)で表現するところにあり、イベントストリームやシグナル・ビヘイビアといったFRP特有の要素を用いるか否かにはないということが示されています。状態遷移が複雑になれば状態遷移を純粋な関数として表現する作業も複雑になり困難になるそしてそれはしばしば綺麗な関数合成では上手くいかないようなものになることが多いという状況が顕在化するばするほど、「殆ど変わらない」どころか、本質的な違いが顕在化する。批判ありきで私個人を中傷するにとどまらず、何も知らんくせに、FRPの意味もわかってないくせに、批判ありきのFRP不要論の大風呂敷を広げる、適当な屁理屈をとってつけて読者を惑わせて恥ずかしくないの?と思う。自称大学の教職にある捨てアカウントらしいが、知的誠実さが少しでも残っているのならば、ただちに修正することをおすすめする。言っても無駄でしょうが。捨てアカウントだし、こちらを中傷し放題で、自分は間違ったデマを垂れ流しても、恥はかき捨てで大変結構ですね。割を食うのは学習者です。恥を知ってほしいです。「関数型言語」に関するFAQ形式の一般的説明においても、それだと入出力や状態(state)すら表せないのでは?いいえ、純粋な関数型プログラミングでも、入力を引数、出力を戻り値とする関数を考えることにより、入出力も表現できます。@nonstarterらへのOCamlのデスクトップ(Web)アプリの宿題を出したいと思う。繰り返し念の為ですが、もちろん別に義務なんてないし、多分出来ないとおもうから、無理してやる必要もない。やらない、ということが一つの答えとなるから。課題ToDoListという単純なGUIアプリを書け。考えましたが、状態の更新があるGUIアプリとして適度に複雑で、適度に単純な課題を選択しました。連中が誤魔化せたので、今回はそれ以上に、誤魔化しにくい程度に複雑である、ということです。第三者による書き込みhttp://anond.hatelabo.jp/20160518171946まあお絵かきは綺麗に書けるってことでいいんじゃないの?そんで岡部氏のFRPでは綺麗に書けて、状態渡し派の関数型には書けない次なるお題でとどめを刺せばいいんでは?で提起されるような要件のとおり、ある程度の複雑さのハードルを満たしながら、当方のFRPのアプローチでは極めてシンプルに記述できることを示せる程度に単純な課題です。君らがお題目唱えているとおり、(状態渡し)の関数型のコードで書くこと。これまで君らが誤魔化してきたように、HaskellやElmなど他の言語を「都合よくつまみ食い」してはならない。FRPのメリットなんてない、とかぶちあげているみたいなので、たとえFRPのメリットをようやく今更途中で気づいたとしても、間違ってもOCamlのFRPライブラリなんかを検索して探し出して、そのFRPライブラリを利用して書いてはならない。(状態渡し)の関数型コードで書くこと。これは、君らが延々とこちらの主張を押さえ込むように強弁してきた要件なので、当たり前。出来なきゃ、その時点で君らの嘘が確定する。以上の条件に反しなければ別にどんなライブラリを使おうが自由。当方は、JavaScript+TimeEngine+Reactをもって、FRPで実装しますJavaScript(いろいろ君らが関数型プログラミングの文脈で否定してきた言語)+FRPライブラリTimeEngine(いろいろ君らが真のFRPでなく破壊的代入だの命令型だの適当に中傷している当方によるライブラリ)+React(FRPの末端(View)を担う、君らが否定的なJavaScriptでは今時デファクトのFBによるフロントエンドライブラリ)をもって実装。document.getElementById('todo'));})();基本、すべてconstのみのFRPコードです。念の為ですが、http://anond.hatelabo.jp/20160514005947kenokabe氏のコードは破壊的代入バリバリの命令型プログラムそのものhttp://anond.hatelabo.jp/20160515231526またすさまじいスパゲッティコードkenokabeさんのコードはライブラリの内部実装だけでなく、ライブラリのユーザに見えるレベルでももろに命令型の破壊的代入ですね。http://anond.hatelabo.jp/20160516112619kenokabeさんの心の中ではそうなのかもしれませんが、ライブラリのユーザから客観的に見れば(分析哲学ではなく関数型言語の意味で)参照不透明なので、関数型プログラミングのメリットは享受できない、命令型の破壊的代入と等価ですね。http://anond.hatelabo.jp/20160517094425kenokabe氏のコードでもマウスが動くたびに同じ__drawFrom.tへの破壊的代入が行われるんですがそれはhttp://anond.hatelabo.jp/20160516192742これは岡部健氏が著書で「論理破綻」と批判していた、命令型言語の破壊的代入そのものです。命令型の破壊的代入と等価と思うのは、あなたの本来の意味におけるFRPにたいする哲学的理解あるいは概念の理解が足りないからです。関数型プログラミング、そしてFRPのメリットを享受しています。「論理破綻」などどこにもありません。http://qiita.com/nonstarter/items/2763f5d85f2b8df3b18bJavaScriptか、少なくともその処理系が、関数型プログラミングに不適切です。実装を使う事に固執したためであるという事も意味します。@yataketa9056岡部氏の著書やコードは拝見しましたが、実用的なGUIアプリはありません。ReactやFRP以前に岡部氏のJavaScriptコードは無意味に複雑・冗長で、失礼ながらまさに「スパゲッティ」と言わざるを得ません。@Lambadakenokabeさんに代わって(もちろん変数の破壊的更新を伴わない純粋にFRPなJavaScriptコードで)実装されると一連のご主張に説得力が多少は増すかと思いますのでとてもお勧めです。@nonstarterすでに述べたとおり2です。@Lambada素人としては深入りを避けたいと思いますが、そうだとすればそもそもJavaScript選んじゃったのが関数プログラミングへの無理解を象徴的に示すものなのだということになるような気がします。好き勝手な言い分のJavaScriptをもって、好き勝手な言い分のFRPで関数型プログラミングしたことと、FRPと極めて親和性の高いJavaScriptのフロントエンドとしてのReactのおかげで、かなり楽にコーディングできました。OCamlでFRPを使わない関数型プログラミングでの実装のコードを見れる日は来るんでしょうか?できたら知らせてください。お互いのコードを比較して精査してみましょう。どんなコードが出てくるんでしょうか?精査して、簡潔さにおいて比較しうるに足る代物が出せたのなら、次のレベルに進めましょう。これでもまだ「状態渡し」で誤魔化しきれるかもしれないから。あああと、駱駝に言っておきますが、自分が不慣れな理解できないコードを眺めて「スパゲッティ・コード」と侮辱するのは悪い癖です。「無意味に複雑・冗長」だと思うなら、ハッタリでないのなら、切り詰めて簡約したコードをさっと出しましょう。今回も「無意味に複雑・冗長」な「スパゲッティ・コード」と思うのならば、どの部分がそうなのか?明示した上で書き直したものを見せてください。Posts量子コンピュータが超高速である原理と量子論とそれに至るまでの科学哲学史をゼロからわかりやすく解説01これは連載記事です。これは連載記事で、順次更新されます。この宇宙があらかじめ持っている計算能力に量子のレベルでアクセスして計算するマシン。都内の進学校に通っている。プログラミングが趣味でコンピュータ部に入部した。IQ145の知能を持つ美少女。セキヤの学校のコンピュータ部の先輩で、セキヤを厳しく指導する。