Topics

・関数型プログラミングとオブジェクト指向のパラダイムとしての対立 国内の【自称】関数型コミュニティと海外の論調の違い

ガラパゴス・ネットスラング=「関数型ポエム」という呪詛、先入観的読書と、フェアなレビューの登場

Qiitaの騒動から派生して、東北大学の住井 英二郎@esumii氏、らくだの卯之助@camloeba氏その他が、犯罪者集団に合流して2ちゃんねるでの誹謗中傷チームの「8賢者」「ウィザード組」とかアホなことをやってる件について

JavaScriptではES6+とReact-JSXからES5へのトランスパイルが標準に / ATOMエディタで最速環境構築 厳選パッケージ 3 + 3 2015年夏バージョン

2016年のnode、ES6、React、Babel、Atomエディタ界隈の方向性

Dockerじゃないsystemd-nspawn+machinectlが非常に良い

99%のプログラマがIQ145のJKに「ダサい」と言われてしまう理由とは?【その1】「計算機科学のほんとうの基礎」を理解していない。IQ145のJKと同じ事を語るMITの権威とSICPという聖典の権威を借りてマインドコントロールを解いてみよう

99%のプログラマがIQ145のJKに「ダサい」と言われてしまう理由とは?【その2】関数型プログラミングのイミュータブルな世界観とイミュータブルな実世界を完全に統合

10年先を行く斬新な関数型(FRP)データベースについて説明する 99%のプログラマがIQ145のJKに「ダサい」と言われてしまう理由とは?【その3】

[React (.js Facebook)解説 関数型プログラミングに目覚めた! IQ145の女子高生の先輩から受けた特訓5日間 サポート記事【静的HTML編】React 解説【動的HTML-FRP編】

量子コンピュータが超高速である原理と量子論とそれに至るまでの科学哲学史をゼロからわかりやすく解説01量子コンピュータが超高速である原理と量子論とそれに至るまでの科学哲学史をゼロからわかりやすく解説02

『関数型プログラミングに目覚めた!』のレビュー(Day-1)について

LISPデータ構造の問題点の指摘と抜本的解法としての新プログラミング言語の策定/純粋関数型言語「SPINOZA」

著書『関数型プログラミングに目覚めた! IQ145の女子高生の先輩から受けた特訓5日間』 [Day1]たち読み記事 無料公開中

『関数型プログラミングに目覚めた! IQ145の女子高生の先輩から受けた特訓5日間』を大変多くの方々にお買い求めいただき、感謝します。本書の全目次を公開し、質問を受け付けます。

2016年5月20日金曜日

TimeEngineの  __x.t = __x.t + 1; について

住井 英二郎@esumiiさんとか、らくだの卯之助@camloebaさんに聞きたいのだけど、そもそも貴方たちはOCamlでデスクトップアプリ書けるんですか?

住井 英二郎@esumiiさんとか、らくだの卯之助@camloebaさんに聞きたいのだけど、そもそも貴方たちはOCamlでデスクトップアプリ書けるんですか? の続き

『関数型プログラミングに目覚めた!』のレビュー(Day-1)の嘘と誤魔化し ー 自分たちが非実用的な「机上の空論」を語っている事をけして読者に語らないこと

Qiitaの騒動から派生して、東北大学の住井 英二郎@esumii氏、らくだの卯之助@camloeba氏その他が、犯罪者集団に合流して2ちゃんねるでの誹謗中傷チームの「8賢者」「ウィザード組」とかアホなことをやってる件について

TimeEngine お絵かきアプリ(関数型リアクティブプログラミング/FRPのトイプログラム)

本来のFRPを理解せず中傷を重ねる連中への再度宿題

「これ以上は説明も回答もしない。」という嘘説明のFRPの基本原理コードなるもの

OCamlでの関数型コードのGUIアプリ課題 あらあためて、住井 英二郎@esumii (東北大)、らくだの卯之助@camloeba、@nonstarterその他へむけて

C言語は純粋関数型である。 「純粋関数型」と「参照透明性」国内の自称関数型コミュニティの胡散臭さと海外論調の違い

この辺の続きとなります。

特に、前回のエントリ

TImeEngineは命令型でも破壊的代入でもない

の続きです。

前回、


const items = (true);
という、時間軸上の世界線の「定数」 const
であるのならば、
「破壊的代入」なんておこりうるはずもない。
ということです。

「破壊的代入」がなされている、と批判した時点で、
その人物は、
FRPのValue ”OverTime” がイミュータブルな定数である
という意味なんて、本当はこれっぽちも理解していない、ということが白日の下にさらされます。
つまり、中傷してる連中は、FRPの哲学的理解が足りないからそういうことが言えるのだ、ということですね。


と説明しました。

それでもなお「どうしても理解できない人」はいます。まあ仕方ないです。
仕方ないですが、それはその人物の知的素養の問題であって、私の問題でもTimeEngineというFRPライブラリの問題でもありません。

執拗に繰り返されるのが、

本来のFRPを理解せず中傷を重ねる連中への再度宿題
で、すでに説明したこれです。

(再掲)


http://anond.hatelabo.jp/20160516192742

実際、timeengine.js を読み込んだ状態で、以下のようになります。

> const __x = __();
undefined
> __x.t = 1;
1
> __x.t = __x.t + 1;
2
> __x.t;
2

なお私を他の誰かと決めつけるのは、その方たちにご迷惑ですのでおやめください。
……と言っても聞き入れていただけるとは思えないので、私ももうこれ以上の書き込みはやめます。
できるだけ丁寧に技術的な誤りだけを指摘したつもりですが、やはり誹謗中傷しか返ってこないようで残念です。

http://anond.hatelabo.jp/20160517094425

kenokabe氏のコードでもマウスが動くたびに同じ__drawFrom.tへの破壊的代入が行われるんですがそれは

などと書いているのですが、いま説明しているように、

Date.now = Date.now + 1

というステートメントが、概念的な意味を成さないように、
=の両辺が等しいという、関数型プログラミングのパラダイムにおいては、

__x.t = __x.t + 1;

というFRPライブラリの使用は概念的な意味を成しません。
なんでこういうことをするのか?というと、なんか悪意があるか、
それとも、FRPが「時間軸上の値を表現したデータタイプ」についてのパラダイムである、
ということを全く理解していないから、こういう文句のつけかた、それこそ誹謗中傷をして平気なのでしょう。

あえてこの住井らしき人物がわざとやらかした「破壊的代入」という命令型パラダイムにおいて、考えてみると、この人物の意図によると、
「右辺の現在値」を「左辺の現在値」に代入するという命令型の時系列的意図しかありえないでしょうから、

右辺の現在値に1を加えて、改めて、左辺の現在地とする

ということです、つまり、左辺、右辺の現在時間が異なる、FRPライブラリにおいては、
.tによって表現される時刻による「時間軸上の値」は異なって当然であるということになります。

よって、

__x.t = __x.t + 1;

というのは、
右辺を評価した現在時間における
__x上のある値に1を加えたものを
次の瞬間以降の
__x上の値として更新する、という意味合いになります。

もちろん、これは、=の左右で値が異なるという命令型ステップの解釈であり、
そういう命令形パラダイムを大前提とした記法においては、TimeEngineの振る舞いはこう解釈される、
ということにすぎませんし、そのような記法を禁じるようなSanityCheckを実装しているわけではありません、
ご自由にどうぞ、といったところでしょうか。


(再掲ここまで)

なんかよくわかりませんが、そんなに難しいこと言っていますかね?

同じことを言うと思いますが、また同じことを言いたいと思います。

まず、第一に、

__x というのが、時間軸の世界線の無限リストで、
イミュータブルな定数である、

__x.t というのが、now などで表される、それ以外では表しようがない「現在時刻」における、
__x上の分布値である、

という意味を理解しておれば、これらはすべてイミュータブルな定数なので、
「破壊的代入」など原理的に起こりえない、と自然に理解できる、ということです。

理解できないのならば、それはその人の哲学的側面における知性の問題であり、
そもそも時間にまつわる、関数型プログラミング、FRPのことなどははなっから諦めたほうが良い、ということです。まず、身の程をわきまえて、こちらを中傷することなどもっての他です。

次に、

関数型プログラミングとは、宣言型プログラミングなので、
根本的に、式を用意したならば、その両辺が等しい、という数学的宣言をすることと同じです。

__x.t = __x.t + 1;

という、方程式の左右で値が異なる「論理破綻」した記述をするのは、
そういう宣言を記述した、コーダーその人の責任です。
TimeEngineでは、そんなところまでSanityCheckするつもりもないですから、どうぞご勝手に、ということですが、こう書けるから、TimeEngineは命令形で、破壊的代入だ!

つまり、

これは岡部健氏が著書で「論理破綻」と批判していた、命令型言語の破壊的代入そのものです。
できるだけ丁寧に技術的な誤りだけを指摘したつもりですが、やはり誹謗中傷しか返ってこないようで残念です。

とか、表明するに至っては「頭がおかしい」としか思えません。

関数型、宣言型のパラダイムにおいて、= の両辺がことなる宣言をわざわざして、
破壊的代入を試みたたのは、この人であるし、FRPライブラリの領分でもなんでもないわけです。

「思い込みの激しい」人間に説明をするには、困難を極めるのですが、できるだけこの人物の意図を想像しながら、こちらもやってあげましょう。

まず、この人物の意図としては、

命令型プログラミングをやりたい!

というのがあるのでしょう。

繰り返しますが、

__x.t = __x.t + 1;

ってのは、両辺の値が明らかに異なっているので、論理破綻しており、
=の両辺の値が等しいと宣言することで、コーディングする関数型、宣言型のパラダイムからは逸脱しています。

次に、

破壊的代入をしたい!

という強い意図が感じられます。

もちろん、=の両辺の値が等しいというパラダイムにおいては、そういう行為は意味を成さないし、そういうスタイルで書いてはいけないのですが、JavaScriptのネイティブな仕様としては、破壊的代入も自由にできるので、やろうと思えば可能です。もちろん、関数型プログラミングを志向するならやるべきではないのは自明です。でもこの人物は、破壊的代入をしたい!と駄々をこねているわけです。自由にさせておきましょう。
でもそうしたいというのは、FRPライブラリの責任でも設計者の私の責任でもなく、彼自身の強い希望なのです。私のせいだ、みたいなことは言わないでください。というか言われてますが、あほらしいですが。

JavaScriptのネイティブな仕様として、

__x.t = __x.t + 1;

と書いた場合、

右辺   __x.t + 1
が先に評価され、
左辺  __x.t

に代入されます。

この人物の強い意図として、

  • 命令型プログラミングをして
  • 破壊的代入をして

と、__x の挙動に興味がある、ということみたいなので、

  const __x = __(true);
        __x.t = 99;
        __x.t = __x.t + 1;

こんなコードを書いてみましょう。

FRP値のフラグをtrueとするのは、
この人物が、「破壊的代入」に興味があるからです。
つまり、
命令型のフローのあるコードを書いて、

破壊的代入前
破壊的代入後

という、
コードの上下
コードの左右 (方程式の左右)

の時間経過みたいなことを前提にしてコードを書きたがっているからです。

関数型、宣言型のスタイルにおいては、このような、
コードの上下、左右で、時間が経過するような概念は用いませんが、
彼がそうしたいと熱望しているわけです。好きにさせてあげましょう。

結果はどうなるか?というと、すでに書いています。

const x = (true);
という、時間軸上の世界線の「定数」 const
であるのならば、
「破壊的代入」なんておこりうるはずもない。
ということです。

  const __x = __(true);
        __x.t = 99;

        __x.t = __x.t + 1;

        __.log.t = __x[0]; //99
        __.log.t = __x[1]; //100

となります。

イミュータブルな時間軸上の世界線の「定数」
__x には、

その命令型のコードフロー時間における、
それぞれの分布値 
__x.t
が分布しています。

もうちょっと正確にいうと、
別の、__x.t に切り替わるまで、
直近の__x.t が継続して分布しています。

式の右辺を先に評価して、というこのコーダーの意図で、
その時点の、__x.t が読み出される。
一個上の行で評価された時間での、 __x.t = 99;というのがありますから、
それが得られています。それに1を加算して、
今度は、左辺の時間の、__x.t に値を代入します。

「破壊的代入」というのは、そういう行為です。
前あった、右辺の値を、
新たに、左辺の値を上書き破壊するように代入する。
だったら、「時間」が違うわけです。BeforeAfter 破壊前、破壊後。

当然、TimeEngineはその意図のとおり振る舞いますから、
結果、格納された集合値の__xの全体としては、
破壊前、破壊後と、この人物が、意図したであろう、2つの異なる時間の値が存在するはずです。

   __.log.t = __x[0]; //99
   __.log.t = __x[1]; //100

意図したとおりになってるじゃないですか?なんか問題あります?
どこにも論理の破綻はない。

まあ、命令型であったとしても、かように、
= っていうのが、関数型、宣言型とは意味合いが異なる、
コードの上下、
式の両辺で時間が異なる、という自覚があればこのように整合的にコーディングすることは可能です。

まあしつこい中傷行為は、いい加減にしてほしいです。

おわり。

0 コメント:

コメントを投稿

Popular Posts