住井 英二郎@esumiiさんとか、らくだの卯之助@camloebaさんに聞きたいのだけど、そもそも貴方たちはOCamlでデスクトップアプリ書けるんですか？
住井 英二郎@esumiiさんとか、らくだの卯之助@camloebaさんに聞きたいのだけど、そもそも貴方たちはOCamlでデスクトップアプリ書けるんですか？ の続き
『関数型プログラミングに目覚めた！』のレビュー（Day-1）の嘘と誤魔化し ー 自分たちが非実用的な「机上の空論」を語っている事をけして読者に語らないこと
TimeEngine お絵かきアプリ（関数型リアクティブプログラミング/FRPのトイプログラム）
「これ以上は説明も回答もしない。」という嘘説明のFRPの基本原理コードなるもの
OCamlでの関数型コードのGUIアプリ課題 あらあためて、住井 英二郎@esumii (東北大)、らくだの卯之助@camloeba、@nonstarterその他へむけて
この辺の続きとなります。
まず「課題」についてですが、いまのところ、私が知る限り、まだどこにもされていません。
念の為ですが、Twitterやら幼稚な念仏唱えているだけと一部馬鹿にされている病人が誹謗中傷連ねたいだけの２chスレの書き込みなんかいちいちチェックしてるわけもないので、万一そんなとこに書きなぐっても見てるわけもありません。
本来のFRPを理解せず中傷を重ねる連中への再度宿題
の「本来のFRP」による「お絵かきアプリ」っていったいどこにあるの？という課題については、
「これ以上は説明も回答もしない。」という嘘説明のFRPの基本原理コードなるもの
と説明したとおりです。単なるごまかしです。
直近の、
OCamlでの関数型コードのGUIアプリ課題 あらあためて、住井 英二郎@esumii (東北大)、らくだの卯之助@camloeba、@nonstarterその他へむけて
ToDoの関数型GUIアプリについてもいまのところ無回答です。
2,3それらしい言い訳が
http://anond.hatelabo.jp/20160519142942
じゃあOCamlで純粋関数型や（本当の）FRPで複雑なGUIアプリが書けるかと言うと、
理論的には不可能ではないかもしれんが、もともと非純粋なので
誰もそういうライブラリを整備してないから、ライブラリから作るのは
まあ面倒だろうし、わざわざ非純粋関数型言語で純粋関数型のGUIを作る動機も
現時点ではまずないだろう。これもすでに指摘されているとおり。
http://anond.hatelabo.jp/20160520051838
「状態渡し派」なんてレッテル張りも典型的な詭弁（藁人形論法）。
誰も状態渡しで何でも簡単に書けるなんて言ってないし、状態渡しで書くべきとも言ってない。
「お絵かきアプリ」には自称FRPが絶対に必要、という明らかに誤った主張に対する反例として
nonstarter他が「状態渡し」を挙げただけ。
それなのにHaskellだから認めないとか、OCamlでも簡単だったから認めないとか……
自分で「FRPが必要」と断言して挙げた例題なのに。
「やらない」「できない」言い訳を始めているようで非常にほほえましいですね。
ちなみにこの胡散臭い人物がいう「純粋関数型」については後述します。
「お絵かきアプリ」には自称FRPが絶対に必要、という明らかに誤った主張
「実用的アプリ」を書ける、という観点において、
この程度の簡単なアプリなら書ける、書けたという誤魔化しがなされたにすぎません。
「お絵かきアプリ」というのは、あくまで複雑なものが普通である「実用的アプリ」の具体例のひとつとして登場しただけで、
その課題が「実用的なアプリ」というトピックにおいてどうも単純すぎたようだ、だからもうちょっと複雑な具体例で検討してみようか？
、というのが現在進行している議論です。
「実用的アプリ」の具体例として単純すぎた実装が、連中のいう「純粋関数型」で書けたからといって、
「原理的」に複雑な「実用的アプリ」が書ける、わけもないですが、それが
「実用的」な観点で、君ら誤魔化してるだろ？と言ってるわけです。
@nonstarterは、FRPでも結局は「状態渡し」と一緒で、実用的なアプリを関数型を書くのには問題があるのは一緒だ、とさらに、FRPにまで話を進めてもそれは一緒だ、とさらに大嘘を書いているので、
以上の２点の嘘ごまかしを証明しようというのが今のステップです。
「実用的」複雑なGUIアプリが書けるのか？というトピックにおいて、
こちらが単純すぎる課題を出してしまったことに便乗し、
「ほら書けただろ！」と、それ以上複雑になってくると通用しないことを自覚しながら、
「原理的」に問題ないというポーズだけ示し、
さらに、FRPでも一緒だ！と「誤魔化している」ことを批判されているのに、意味が伝わりませんかね？
「机上の空論」であると。
「机上の空論」じゃ埒が明かないので、こちらは、
さらに複雑な課題において、証明してみせよ、と具体的なコードを示せと言ってる。
君らのなかの「純粋関数型」君らののなかの「FRP」がどうであれ、
こちらはすでに、コードを示した。
君らは頑なに強弁してた、
Ocaml＋状態渡し（FRPのメリットなんてないらしい）関数型でコードは示せない。
それがすべてを物語っているだろう？君らの一連の関数型のGUI実用アプリのの言説なぞ机上の空論であると。
ちなみに、
『話題の岡部健（kenokabe）が自分のブログで凄いこと言ってる』
http://anond.hatelabo.jp/20160519214037
で、
ttp://kenokabe-techwriting.blogspot.jp/
このブログエントリの昨日と本日日付の分を見ると、たくさんの増田の投稿がリンク付きで引用されている。
しかもよく見ると、個々の増田の投稿を、実在の学者やツイッターユーザーが行ったと決めつけてるフシがあるんだよね。
自説を否定する増田に対して憤慨してる様子なんだけど、文脈からするとどうも「駱駝」っていう人物が投稿していると言いたげなんだよね。「あなた」とか「君ら」という言葉からすると。
というか、完全にそれを前提にブログを書いているんだどう見ても。
増田の投稿に対して憶測で特定の人物だと決めつけてこういうエントリ書くような奴は初めて見た。
あと学者の「住井」って人物にも噛みついている様子なんだけど、過去のエントリを見るとこの岡部、駱駝・住井両名に対してよくわからない挑戦状みたいなエントリを何の前触れもなくアップロードしてるんだよ。
内容からすると、やはり誰が書いたのか正体が見えない投稿を、その両名が行ったと決めつけてるようなんだよね。
このタイトルも凄い、
Qiitaの騒動から派生して、東北大学の住井 英二郎@esumii氏、らくだの卯之助@camloeba氏その他が、犯罪者集団に合流して２ちゃんねるでの誹謗中傷チームの「8賢者」「ウィザード組」とかアホなことをやってる件について
どこの厨房だよと思ったらどうも真剣に書いてるみたいなんだよね。
第三者による書き込み
http://anond.hatelabo.jp/20160518171946
って言ってるけど、これ岡部氏本人による自己弁護だよねぇ・・・・。一体何をしたらここまで常軌を逸した発言に及ぶんだ。
という
ttp://kenokabe-techwriting.blogspot.jp/
という２ch記法ではじまる、たいへんわかりやすい印象操作工作活動をあいかわらずやらかしています。
さっそく、突っ込みも入っているようですが、
「実在の学者」
とか、普通こんな不自然な言い草します？（笑）
これは、「実在のベンゴシ」と、ほうぼうでお経のように唱えていると小馬鹿にされている、まさに、
この構成員の口癖そのものです。いろいろワキが甘いですね。書き込みの癖って隠せないですよね？
誹謗中傷集団の構成員が、
事情通をアピールしながら、
文脈からするとどうも「駱駝」っていう人物が投稿していると言いたげなんだよね。「あなた」とか「君ら」という言葉からすると。
憶測で特定の人物だと決めつけてこういうエントリ書くような奴は初めて見た。
あと学者の「住井」って人物にも噛みついている様子なんだけど、過去のエントリを見るとこの岡部、駱駝・住井両名に対してよくわからない挑戦状みたいなエントリを何の前触れもなくアップロードしてるんだよ。
とか、「今初めて知りました感」を演出している。
「背景に詳しい事情通」なのに「今初めて知りました感」を演出。
こういうのを「自作自演」っていうんでしょ？いつも工作活動ごくろうさまです。
さて、最後に
第三者による書き込み
http://anond.hatelabo.jp/20160518171946って言ってるけど、これ岡部氏本人による自己弁護だよねぇ・・・・。一体何をしたらここまで常軌を逸した発言に及ぶんだ。
違いますよ。第三者です。自分が自作自演の常習だから、といって、
「自分たちに都合の悪い岡部への弁護」は「岡部の自作自演」みたいな都合の良い決め付けはやめなさい。
全部のやりとりを引用すると
http://anond.hatelabo.jp/20160518164005
状態を変数に持つ必要はない、というところは伝わってるのかな
状態を引数で与えて新たな状態を得る、という形で書ける、と
そのほうが関数型的、というと反発するんだろうけど
岡部氏もやろうと思えばそういう風に書けるんじゃないの？
http://anond.hatelabo.jp/20160518170332
そんな「状態渡し」の話はもう周回遅れでとっくに終わってる。
複雑なGUIアプリを関数型で「状態渡し」で書いたら、そのうちスケールしなくなる、ってのは例の当事者が認めてて、
FRPに話がようやく移ったのが今。
http://kenokabe-techwriting.blogspot.jp/2016/05/timeengine-frp.html
http://anond.hatelabo.jp/20160518171946
まあお絵かきは綺麗に書けるってことでいいんじゃないの？
そんで岡部氏のFRPでは綺麗に書けて、状態渡し派の関数型には書けない次なるお題でとどめを刺せばいいんでは？
と言う感じです。
岡部は孤立している、要するにそういう図式を堅持したい、という魂胆はいつもミエミエでわかりやすいですが、自分の信じたい世界を作り上げる、自分の都合の悪い真実については、岡部の妄想というのもわかりやすいです。
「実在の学者」とか、毎日「実在のベンゴシ」がどうたら異常なお経唱えてるから、不自然だと気づかないんですよ？病気？
純粋関数型
他にもこんな書き込みがあります。
http://anond.hatelabo.jp/20160519175956
岡部さん曰わくは、「ぼくの主張に同調的な国内の学者たちは、
自称関数型コミュニティの圧力を恐れて、表立って肯定できない」とのことです。
また、
「nonstarter氏や住井教授のようなエントリの内容は、日本国内でのみ少数の合意が得られてるに過ぎず、海外では主流ではない。
僕の理解こそが世界的合意を得られており、stakuoverflowでmapとreduceの理解が出来ていないような質問をしたのは、海外のレベルを探るためである」
という趣旨の主張もあるようです
それに対してさっそくついたトラックバックを引用すると
http://anond.hatelabo.jp/20160520072553
観測できる事実として、岡部さんと住井さん、nonstarteさんの振る舞いが目立ってきた頃から、
国内ネットでは、地雷、滅多なことを言わないほうがいいという風潮がありました。
しかも、「純粋関数型」が何か？というさえ、海外では関数型プログラミング界隈の著名人、
たとえば岡部さんが引き合いに出す論文のエリオットはじめ、合意が取れていません。
http://conal.net/blog/posts/the-c-language-is-purely-functiona
「nonstarter氏や住井教授のようなエントリの内容は、日本国内でのみ少数の合意が得られてるに過ぎず、海外では主流ではない。」
よって、これは岡部さんのほうが公平な現実について発言しており、が正しいと判断します。
住井さんをはじめ、岡部さんが批判する相手は、議論となっている関数型プログラミングの定義などが、まるで世界的に合意がされており岡部さんのみが異端だという主張ばかりしており、あまり信用できません。
そのとおりです。
私が 住井 @東北大をはじめとする自称関数型コミュニティによる言説が非常に胡散臭いとおもうのは、
例の関数型PGの一般的説明、なるものもそうですし、まるで学術的にコンセンサスがとれており、
自分の言っていることが正しい、と断定的に論じているところです。
http://conal.net/blog/posts/the-c-language-is-purely-functiona
というのは、知らなかったですが、
The C language is purely functional
「純粋関数型」についての議論です。2009年5月時点の投稿
Conal Elliottについては、私もその発言について信頼しており引用してみます。
There has been a scurry of reaction on twitter and reddit to Robert Fischer’s post saying that Scala is Not a Functional Programming Language. James Iry responded by saying that analogous reasoning leads to the conclusion that Erlang is Not Functional
My first inclination was to suggest that Haskell, as commonly practiced (with monadic IO), is not a functional language either. Instead, I’m going to explain how it is that the C language is purely functional.
要約すると、
Robert Fischer’のポスト ー Scalaは関数型プログラミング言語ではない、についてTwitterやReddit（海外の活発な掲示板）で、ちょっとしたリアクションがあった
James Iryは、同じ理由でErlangは関数型ではない、という結論も出せる、答えた。自分の最初の考えとしては、Haskell、(IOモナド) も関数型言語ではないとサジェストしたいというものだった。しかしかわりに、C言語も純粋関数型であるということをここで説明しようと思う。
（中略）リンク先読んでください
What about Haskell?（最後部分）じゃあHaskellはどうなの？（純粋関数型か？）
Which leads to the question: is Haskell+IO a purely functional programming language?
Sure it is, even as much as its predecessor C (more precisely, cpp+C).
Some who ought to know better would claim that Haskell+IO is only technically pure. (See claims and follow-up discussion, in response to a remark from James Iry.)I must then respond that, in that case, even C programming is only technically pure.
Which is absurd.これはある質問にたどりつく：じゃあHaskell＋IOというのは、純粋関数型言語なのか？
もちろんそうだ。そしてその先行者であるC(正確に言うとC++)も同じ程度にそうなのだが。
訳知り者はこう文句言うことだろう：Haskell+IOのみが唯一「テクニカル」に純粋である、と。
なら私はこう返すしか無い、ではその場合、Cプログラムのみが唯一唯一「テクニカル」に純粋である、と。
馬鹿げている。
コメント欄もふくめて、要するに明確な合意に至っていない、ということは普通にわかります。
住井その他の日本国内の自称関数型コミュニティの胡散臭い言動の根本的な問題は、素人全般、学習者にむけて、まるで学会で明確な合意がなされており確固たる「一般的説明」があり、私のような「別の意見」を表明すると、「勉強しろ」だの「独自見解」で「合意と違う」という嘘を平気で押し付けてくることです。
実際に「参照透明性」についても、
http://stackoverflow.com/questions/210835/what-is-referential-transparency
で示されているように、関数型プログラマーと、意味論とは食い違うことが明確化されていたり、
Purity vs Referential transparency
http://stackoverflow.com/questions/4865616/purity-vs-referential-transparency?rq=1
The terms do appear to be defined differently, but I’ve always thought of one implying the other; I can’t think of any case when an expression is referentially transparent but not pure, or vice-versa.
純粋性 ｖｓ 参照透明性
これらの用語は、別のものと定義されているようだ、しかし、自分はいつもお互いがお互いを暗喩的に意味しているように考えている。つまり、「ある表現が参照透明であって、純粋でない」というケースがおもいつかないし、逆方向についてもそうだ。
あと、Wikipedia(英語版)のデタラメな説明への疑念、が質問者によって表明されており、
Is there a simpler way to understand the differences between a pure expression and a referentially transparent one, if any? If there is a difference, an example expression that clearly demonstrates it would be appreciated.
なんか、その純粋性と参照透明性についての違いみたいなものを理解できる、もっと単純な方法はないのか？「違い」みたいなものがあれば、明確に表現している例を教えてくれるとありがたい。
もっとも支持を集めた答え
If I gather in one place any three theorists of my acquaintance, at least two of them disagree on the meaning of the term “referential transparency.” And when I was a young student, a mentor of mine gave me a paper explaining that even if you consider only the professional literature, the phrase “referentially transparent” is used to mean at least three different things. (Unfortunately that paper is somewhere in a box of reprints that have yet to be scanned. I searched Google Scholar for it but I had no success.)
もし、自分の知り合いの３人の理論家を集めたら、少なくとも、２人は、「参照透明性」という用語について合意しない。そして、自分が若い学生だった頃、自分の担当教師は、「参照透明性」というものが、少なくとも、３つの異なる意味で使われていることを説明する論文を渡してくれた・・・
I cannot inform you, but I can advise you to give up: Because even the tiny cadre of pointy-headed language theorists can’t agree on what it means, the term “referentially transparent” is not useful. So don’t use it.
わからない、でも、アドバイスできることとして、「あきらめなさい」、なぜならば、インテリ言語学者の少数集団でさえ、それが何を意味するのか合意できていない。
「参照透明性」っていう用語は役立たずだ。だから使うな。
・・・・という感じです。
実際そこらじゅうで見るのが、
「純粋関数型」っていう概念を「参照透明性」という用語、概念をもって説明しようとするものであり、わかったようなわかってないような人らを量産しています。
その上、たとえば、
http://anond.hatelabo.jp/20160516112619
kenokabeさんの心の中ではそうなのかもしれませんが、ライブラリのユーザから客観的に見れば（分析哲学ではなく関数型言語の意味で）参照不透明なので、関数型プログラミングのメリットは享受できない、命令型の破壊的代入と等価ですね。
はい、この「訳知り顔」の誰かさんも、また偉そうに、
参照不透明だから→関数型プログラミングではない、論法を取っています。
えーっとそれっていったいどういう意味？
あなたの言うこと、世界的に合意されているの？
「あなたの心の中」以外でまともな説明はされているの？
（分析哲学ではなく関数型言語の意味で）参照不透明、と（）つけたのは、多分、Qiitaでも話題になっていた、
http://stackoverflow.com/questions/210835/what-is-referential-transparency
これを警戒しているのでしょうが、実際
「関数型言語での参照透明性」っていうのと
「分析哲学での参照透明性」の違い、なんて、まともに合意なんてされていません。
この人物も適当に
「（分析哲学ではなく関数型言語の意味で）参照不透明」とか、「この人物の心の中」での「参照透明性」を語っているにすぎません。
わからないことを、あたかもわかっているように断じる、これがこの連中の悪い癖です。
ああ、ちなみに、この
私のFRPライブラリは参照不透明？で、命令型の破壊的代入っていう中傷について、またしばらく後にエントリします。あたらしい課題つきで。
というか、さっさと、
OCamlでの関数型コードのGUIアプリ課題 あらあためて、住井 英二郎@esumii (東北大)、らくだの卯之助@camloeba、@nonstarterその他へむけて
これやってくださいね？OCamlで状態渡しで、あ、やっぱり、できない、でよろしいんですね？
0 コメント:
コメントを投稿