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

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

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

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

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

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

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

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

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


のうち、これは最初のエントリとなります。



前回のエントリ

関数型プログラミングと私の著書の正確性についてきちんと議論（論争）します。

を書いたところ、
【自称】関数型コミュニティの「メンバー」よりお返事がある、とのお知らせを親愛なる読者の方からご一報いただきました。

らくだの卯之助‏@camloeba
疑似科学者と論争はしませんよ。議論にならないし最後は勝手に勝利宣言するだけですから。
5:22 AM - 26 May 2015

なるほど、今度は「疑似科学者」ですか。随分な言われようですね。
私も貴方がたは、いろいろ上から目線で偉そうには言うが、ほんとうに肝心な部分では逃げまわるばかりなので、議論になりにくいな、と思っています。

疑似科学者？ならば、らくだの卯之助‏@camloebaさん、あなたが自身の関数型プログラミングのスキルが「机上の空論」でないことを示せ。

科学的方法（かがくてきほうほう、英語：scientific method）とは、物事を調査し、結果を整理し、新たな知見を導き出し、知見の正しさを立証するまでの手続きであり、かつそれがある一定の基準を満たしているもののことである 。科学的手法、科学的検証ともいわれる。

科学者は実験を重視します。
科学は証拠となる事実（生データ/証拠物件）を要求する。
それが示されない限り、その仮説は最終的には「机上の空論」に終わる。
「机上の空論」なんと適切なワーディングなのでしょうか。
机上 ＝ Desktop デスクトップ
らくだの卯之助‏@camloebaさん、あなたは、そのアカウント名のとおり、OCaml愛好者でおられて、私の関数型プログラミングの主張や、「理解」について、いろいろ言っておられますよね？延々と。まあ、よほど当方の主張が気になるんでしょう。現代人として恥ずべき焚書みたいな真似が大失敗してしまったし。
『関数型プログラミングに目覚めた！』のレビュー（Day-1）
でも、どこでも、貴方のTweetが結構利用されてるので、いやでも目につきます。

らくだの卯之助‏@camloeba
0 から 9 まで列挙した配列、この本の問題として本質的ではないという意見。しかし、この例を選んでしまっているところにリスト、配列、空間コスト、評価戦略などの関数型プログラミングの大切な概念に対する無理解が見て取れるため極めて象徴的であるのです
5:43 PM - 8 May 2015

これみたらわかるけれども、例の東北大学の住井 英二郎@esumiiさんもリツイートされていますね？
素朴な疑問なんですが、貴方がた、延々と私の関数型プログラミングの「無理解」やらスキルに偉そうなことを言い続けているけど、実際のところ、貴方たちは、関数型プログラミングで、実用に耐えうるデスクトップアプリとか書いたことあるんでしょうか？というか、書けるんですか？？
机上 ＝ Desktop デスクトップのアプリをOCamlで書いて見せてくださいよ。議論はしなくて良いから。
「疑似科学者」なんて罵倒するなら、自分で証明しろ、って思いますね。
さあどうぞ。
個人的に、OCamlを振り回して、国内で関数型プログラミングで、なんかこういう、私の主張にたいしても上から目線で偉そうにごちゃごちゃ文句いってくる連中が、GUIアプリ書いてる事象を目撃したことがこれまで一度もない。
なんで？
まあ、技術者ならば、科学的精神をリスペクトするならば、
らくだの卯之助‏@camloebaさん、あなたが自身の関数型プログラミングのスキルが「机上の空論」でないことを示してください。

私はすでに拙書でも、当ブログでも、関数型プログラミングで実用に耐えうるGUIアプリが書けるポテンシャルを証明している

React (.js Facebook)解説 関数型プログラミングに目覚めた！ IQ145の女子高生の先輩から受けた特訓５日間 サポート記事【静的HTML編】
React 解説【動的HTML-FRP編】
という、技術記事をUPしています。
特に後者は、拙書の延長で、FRPの適用をしています。

Click Counter

Click Counterなる、
「ああこれが出来るなら、多分どんなWebアプリも書けるだろうな！」
というシンプルかつ要点をおさえているWebアプリを
React＋worldcomponentで構築してみます。

各グレーの「カード」をクリックすると、

Localのクリック数、Totalしたクリック数がカウントアップされます。
そして、前回の
【静的HTML編】の一番最後のコードが、ベースになっています。
ChildrenComponentなど、よく見比べてみてください。
コード

var ___ = worldcomponent;
___.world = ___.log('start!'); //debug log

var CARDS = 4;
var ___totalClicks = ___(0);

var TopComponent = React.createClass(
{
  render: function()
  {
    var divStyle = {background:"#aaaaaa"};
    var el = (
      <div style={divStyle}>
        <h1>Click Counter</h1>
        <ChildrenComponent/>
      </div>
    );
    return el;
  }
});

var ChildrenComponent = React.createClass(
{
  render: function()
  {
    var createChild = function(n)
    {
      return (<ChildComponent id={n} ___clicks={___(0)}/>);
    };

    var array = Immutable.Range(0, CARDS).toArray();
    var elArray = array.map(createChild);

    var el = (<div>{elArray}</div>);
    return el;
  }
});

var ChildComponent = React.createClass(
{
  componentDidMount: function()
  {
    var com = this;

    ___.world = com.props.___clicks
                .compute(function(x){com.forceUpdate();});
    ___.world = ___totalClicks
                .compute(function(x){com.forceUpdate();});
  },
  handleClick: function()
  {
    var com = this;

    ___.world = com.props.___clicks
                  .appear(com.props.___clicks.now() + 1);
    ___.world = ___totalClicks
                  .appear(___totalClicks.now() + 1);
  },
  render: function()
  {
    var com = this;

    var divStyle = {background:"#dddddd",
                    width:"210px",height:"210px",
                    margin:"5px",float:"left",
                    "user-select": "none",
                    "-moz-user-select": "none",
                    "-webkit-user-select": "none",
                    "-ms-user-select": "none"};

    var el = (<div style={divStyle} onClick={com.handleClick}>
                <h2>id : {com.props.id}</h2>
                <h4>Local Clicks : {com.props.___clicks.now()}</h4>
                <h4>Total Clicks : {___totalClicks.now()}</h4>
              </div>);
    return el;
  }
});

var mount = React.render(<TopComponent/>, document.getElementById("mountpoint"));

ちなみに

もちろん、OCaml FRPで検索したら、なんかあるようですが、
https://www.google.co.jp/search?q=OCaml+FRP&oq=OCaml+FRP&aqs=chrome..69i57j69i59l2&client=ubuntu&sourceid=chrome&es_sm=0&ie=UTF-8#q=OCaml+FRP&lr=lang_ja
OCamlで実用的なWeb・デスクトップアプリを書く情報って、日本語ではほぼ皆無に等しいし、
住井 英二郎@esumiiさんが、Qiitaで直接、私にむかって「読め」とおっしゃられた、ご自身のWeb記事
数理科学的バグ撲滅方法論のすすめ—目次

連載目次
第1回　OCamlを試してみる
第2回　「単一代入」と「末尾再帰」
第3回　計算量の工夫でプログラムは劇的に速くなる
第4回　関数型言語とオブジェクト指向，およびOCamlの”O”について
第5回　LablGLで3Dグラフィックス ～OCamlの「多相バリアント」と「ラベル付き引数」～
第6回　OCamlの「モジュール・システム」
第7回　「代数データ型」でいろいろなデータを表してみる
第8回　独自のプログラミング言語を開発してみよう（その1）
第9回　独自のプログラミング言語を開発してみよう（その2）　プログラムを実行できるようにする
第10回　静的スコープと関数クロージャ
～関数型言語のインタプリタを書いてみる～
第11回　クロージャによる超軽量並行プロセスの簡単実装法
第12回 「型推論」の実装法
第13回 「表明」と「契約」による命令型プログラムの形式的検証　
第14回 型＝命題，プログラム＝証明　
第15回 型からプログラムを当てる　
第16回 すべてのものは関数である　

をざっと拝読したわけですよ。
もちろん、ここで、
関数型プログラミングたるものが「机上の空論」ではない、と示すべき、なのが

第5回　LablGLで3Dグラフィックス ～OCamlの「多相バリアント」と「ラベル付き引数」～

であるわけです。

ティーポットの描画と回転

これだけでも描画はできるのだが，せっかくの3Dグラフィックスなので，少しくらいは動きを入れたい。そこで，キーボードから入力があったら回転する，という関数も定義・登録しよう。

# let keyboard ~key:k ~x:x ~y:y = (* 入力されたキーkとマウスの座標x,yを引数とする *)
    if k = int_of_char 'q' then exit 0; (* 入力された文字がqだったら終了 *)
    GlMat.rotate ~angle:2.0 ~x:0.25 ~y:0.5 ~z:1.0 (); (* そうでなければ回転 *)
    display () (* 描画関数displayを呼び出して，全画面を再描画 *) ;;
val keyboard : key:int -> x:'a -> y:'b -> unit = <fun>
# Glut.keyboardFunc keyboard (* キーボード処理関数keyboardを登録 *) ;;
- : unit = ()

なるほど、
99%のプログラマがIQ145のJKに「ダサい」と言われてしまう理由とは？【その１】「計算機科学のほんとうの基礎」を理解していない。IQ145のJKと同じ事を語るMITの権威とSICPという聖典の権威を借りてマインドコントロールを解いてみよう
で、こんなものは関数型プログラミングのコードではない、と批判した、「お絵かきロジック」のミュータブルな破壊的代入はなされていないようです。
でも、これ見て私が率直に何を思ったか？
「うまく逃げているな」と思いました。
この「ティーポットの描画と回転」のGUIアプリのコードは、たしかに、関数型プログラミングの要件を満たしていますが、それが可能になっているのは、とりもなおさず、このサンプルが簡単、もっというとGUIアプリとしてはかなり例外的で特殊だからです。
じゃあ、この調子で、「お絵かきロジック」を書けるのか？というと、書けないですよね？
ならば、あなたのすべての解説は、最終的には、「机上の空論」に帰着する。
関数型プログラミングたるものが「机上の空論」でない、という必要な情報がまったく提供されていない。
いったい、なんでこんなことになっているんでしょうか？？

背景考察

関数型プログラミングのパラダイム内で、そういうマウスボタンが押されているのか、押されていないのか？入力の状態が時間遷移していく場合、上記ブログエントリでも論じたSICPでも、拙書でも解説しているとおり、FRPの実装が必ず必要となります。
「時間」が本質的だから、時間をを集合、SICPの言葉でいえば「遅延ストリーム」とした実装が必要です。
少なくとも、これまで私が見た、すべてのOCaml解説で、このFRPの解説を体系的になしている文献は皆無です。もちろん、この住井氏によるWeb記事も含めてそうですよね。非常に巧妙にそこを避けて、あたかもGUIでもなんでも出来るようには見せては、いるが、実際FRPを導入しないと、「お絵かきロジック」のように、状態変数の破壊的代入は避けられないので、破綻します。
私が一貫して、批判している、住井氏による、
「関数型言語」に関するFAQ形式の一般的説明
という、Qiita記事ですが、

それだと入出力や状態(state)すら表せないのでは？
いいえ、純粋な関数型プログラミングでも、入力を引数、出力を戻り値とする関数を考えることにより、入出力も表現できます。非常に簡単に言うと、例えばhello(x) = “Hello, ” + x + “!”みたいな関数で（これも文法は適当です）、文字列hogehogeを入力するとHello, hogehoge!と出力する、みたいなプログラムを書くことができます。
同様に、状態（の変化）についても、古い状態を引数として受け取り、新しい状態を戻り値として返す関数により表すことができます。

という、状態（の変化）の解説、（太字にした）最後部分の「一般的解説」を拝見して、「ああこの人はFRP理解していないんだ」と思いました。
同様に、状態（の変化）についても、古い状態を引数として受け取り、新しい状態を戻り値として返す関数により表すことができます。
という作法で「お絵かきロジック」のアプリを書けるんでしょうか？書けるわけがありません。時間が本質的なのに、時間の処理を関数型プログラミングのパラダイムで一切考慮されていないからですね。
まったく、時間軸上のデータの集合化、FRPについてはかすってもいません。
要するにこの理解は間違いです。
いろいろあれ読め、これ読めという方なので、
念の為ですが「権威ある」SICPでは、オブジェクト指向と、遅延評価のストリーム（FRP）が対比的に論じられています。

Both the object-based approach and the stream-processing approach raise significant linguistic issues in programming. With objects, we must be concerned with how a computational object can change and yet maintain its identity. This will force us to abandon our old substitution model of computation (section 1.1.5) in favor of a more mechanistic but less theoretically tractable environment model of computation. The difficulties of dealing with objects, change, and identity are a fundamental consequence of the need to grapple with time in our computational models. These difficulties become even greater when we allow the possibility of concurrent execution of programs. The stream approach can be most fully exploited when we decouple simulated time in our model from the order of the events that take place in the computer during evaluation. We will accomplish this using a technique known as delayed evaluation.
オブジェクト準拠の解決法とストリーム処理の解決法は, どちらもプログラミングの重要な言語学的論点を持ち込む. オブジェクト間には, 計算オブジェクトが, どう変化出来, しかも同一性を保持出来るかという点に注意しなければならない. そのため, より機械的だが理論的には制御し難い, 計算の 環境モデル(environment model)の方がよく, 古い置換えモデル(1.1.5 節)を捨てることになる. オブジェクト, 変化, 同一性を扱うことの難しさは, 計算モデルに時を取り込む必要性の根本的な結果である. これらの難しさは, プログラムの並列実行の可能性を許すと大幅に増大する. ストリームの解決法は, 評価中に計算機の中で発生する事象の順序から, モデルでのシミュレートされた時を分離すると, 十分な利用が可能になる. われわれはこれを 遅延評価(delayed evaluation)という技法を使って達成しよう.

一方で、
「関数型言語」に関するFAQ形式の一般的説明では、

オブジェクト指向と関数型は対立していますか？
いいえ
(略)
上の記述はあくまで理論の話です。紹介記事の冒頭に書いたとおり、「単純な関数型言語に、複雑なオブジェクト指向はいらない」という考え方もあります（私個人の好みもそれに近く、OCamlのOはほとんど使っていません。参考リンク：「オブジェクトは OCaml の鬼子」）。

えーっと、最初は、いいえ→同じ研究者（含む自分）が研究して、キーノートが、っていう説明だけだったものが、なんか、どんどんと「トーンダウン」して、
上の記述はあくまで理論の話です
という珍妙なエクスキューズが最近、追加されました。
「オブジェクト指向」って、そもそも「理論」じゃないですよね？
「指向」、パラダイムであって、理論ではない。
こんなものは、どこでも書かれている初歩的な知識です。
拙書では、アラン・ケイのことを延々と書いて紹介しましたが。
あなたの理解と「初心者」への説明の仕方は最初から決定的に間違っている。
直交・独立な概念だ、って言うのが流行しているようですが、オブジェクト指向って、一般的に命令形でしょ？状態変数を隠蔽するカプセル化するんだから、イミュータブルな関数型プログラミングと、排他的です。
さらに、なんか編集追加されていて、参考リンク：「オブジェクトは OCaml の鬼子」っていうのは、当初から私が展開している論説とまったく一緒なんですが、いったい何をやってるんですか？？
「鬼子」っていうのは、
直交・独立な概念だ、じゃなくって、
排他的な意味あいなのではないですか？日本語としてね。
どっちなんですか？こういうどっちつかずの説明しかできないのでしょうか？実際に、
数理科学的バグ撲滅方法論のすすめ—目次
第4回 関数型言語とオブジェクト指向，およびOCamlの”O”について
では、まるでそんな「オブジェクトは OCaml の鬼子」という明確な主張はなされておらず、ぼやーっと、どっちにでも取れるような記述になっています。
この辺が、いわゆる学者にありがちな保身的知的欺瞞であり、読者は二の次である、保身的解説なんですね。

オブジェクト指向と関数型は対立していますか？
いいえ

↓

上の記述はあくまで理論の話です　←OOは理論じゃないので間違い

↓

（私個人の好みもそれに近く、OCamlのOはほとんど使っていません。参考リンク：「オブジェクトは OCaml の鬼子」）。

こんなものは一般的解説としては成立していない、と考えます。一番割り食うのは、読者なんですね。意味不明。あなたのどっちつかずの「見解」だけが、巧妙に保身される。
関数プログラミング実践入門 ──簡潔で、正しいコードを書くために
という書籍でも、

そして，「関数プログラミングにおける思考方法」は，よく知られた構造化プログラミングやオブジェクト指向プログラミングのそれとはかなり違います。他の関数プログラミング関連書籍を読んだことのある方でも，ともすれば「どう考えて書いていったらよいか」設計方法/思考方法がピンとこない方がいるかもしれません。書き方がわかっても，考え方が伴わなければ，プログラムとはそうそう書けるものではありません。そのため本書では，関数型言語で関数プログラミングを行う際，どのように考えを進めていけば関数型言語らしい簡潔なコードになるかを説明しています。

あとはもう、まるまる、
関数型プログラミングとオブジェクト指向のパラダイムとしての対立 国内の【自称】関数型コミュニティと海外の論調の違い
で、さんざん、オブジェクト指向と、関数型プログラミングが「パラダイム」として「違う」と列挙したとおりですね。
オブジェクト指向は、「理論」でもなんでもないので。
曖昧にしてマルチパラダイムだ、と延々強弁する、意義もメリットもまったくわかりません。だって、考え方が「かなり」違うんでしょ？
じゃあ、その「かなり」違う考え方を説明してよ、って読者は思ってるのに、「いいえ」対立していません、直交・独立な概念だ、でも鬼子です、って何をやりたいんでしょうか？？

遅延評価とイベント駆動とFRPのおはなし

以下、この議論で、超重要な（そして、OCaml愛好者を中心とする【自称】関数型プログラミングコミュニティの連中が、まったく無頓着、理解していない）内容です。
超重要なので、
99%のプログラマがIQ145のJKに「ダサい」と言われてしまう理由とは？【その１】「計算機科学のほんとうの基礎」を理解していない。IQ145のJKと同じ事を語るMITの権威とSICPという聖典の権威を借りてマインドコントロールを解いてみよう
からまるまる再掲します。

ストリーム （SICP）

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-24.html
http://sicp.iijlab.net/fulltext/x350.html

3.5 Streams
We’ve gained a good understanding of assignment as a tool in modeling, as well as an appreciation of the complex problems that assignment raises. It is time to ask whether we could have gone about things in a different way, so as to avoid some of these problems. In this section, we explore an alternative approach to modeling state, based on data structures called streams. As we shall see, streams can mitigate some of the complexity of modeling state.
3.5 ストリーム
モデル化の道具としての代入について十分理解し, 代入が惹き起す複雑な問題も認識した. これらの問題の幾分かを回避するため, 別の方向へいった方がよかったか考えてみよう. 本節では, 状態をモデル化する, ストリーム (streams)というデータ構造に基づいた, もう一つの解決法を調べてみる. すぐ分るように, ストリームは状態のモデル化の複雑さの幾分かを軽減する.

いよいよ、SICPで、関数型プログラミングのパラダイムにおいて、
「時間」の問題をいかに鮮やかに解決するか？その具体的な解法が示されます。

Let’s step back and review where this complexity comes from. In an attempt to model real-world phenomena, we made some apparently reasonable decisions: We modeled real-world objects with local state by computational objects with local variables. We identified time variation in the real world with time variation in the computer. We implemented the time variation of the states of the model objects in the computer with assignments to the local variables of the model objects.
少し後戻りして, この複雑さがどこから来たか反省しよう. 実世界の現象をモデル化しようとして, 明らかに合理的な決定をいくつかした: 局所状態を持つ実世界のオブジェクトを, 局所変数を持つ計算オブジェクトでモデル化した. 実世界の時間変化を計算機内の時間変化と同一視した. モデルオブジェクトの状態の時間変化を, 計算機内では, モデルオブジェクトの局所変数への代入で実装した.

オブジェクト指向の「複雑さ」の「レビュー」＝「反省点」が考察されます。

実世界の時間変化を計算機内の時間変化と同一視した

これがまずいんですね。
そして、その大前提として、
「実世界の時間変化」っていう論点化がちゃんと出来ているかどうかです。
ほとんどの論者、解説文では、こんなこという水準に達していませんから、そもそもこういう発想、考察自体が無理です。

モデルオブジェクトの状態の時間変化を, 計算機内では, モデルオブジェクトの局所変数への代入で実装した.

秀逸な知見です。
状態変数への破壊的代入を繰り返すことで、そのモデルの時間変化に対応させている。
破壊的代入、っていうのはモデルの時間変化のためにやっていた、
こういう「自覚」をもってるプログラマって今、日本に何人くらいいるんでしょうか？
拙書の読者には随分いるでしょうから、少しは増えたかもしれません。

Is there another approach? Can we avoid identifying time in the computer with time in the modeled world? Must we make the model change with time in order to model phenomena in a changing world? Think about the issue in terms of mathematical functions. We can describe the time-varying behavior of a quantity x as a function of time x(t). If we concentrate on x instant by instant, we think of it as a changing quantity. Yet if we concentrate on the entire time history of values, we do not emphasize change – the function itself does not change.52
(52 Physicists sometimes adopt this view by introducing the “world lines” of particles as a device for reasoning about motion. We’ve also already mentioned (section 2.2.3) that this is the natural way to think about signal-processing systems. We will explore applications of streams to signal processing in section 3.5.3.)
これ以外の解決法があるだろうか. 計算機内の時をモデル世界の時と同一視するのを避けることは出来るだろうか. 変化する世界の現象をモデル化するのに, モデルを時と共に変化させなければならないか. これらの論点を数学関数を使って考えてみよう. 量xの時間変化する振舞いを, 時の関数x(t)と書くことが出来る. xを時刻時刻に注目すれば, それを変化する量だと思う. しかし値の全時間の歴史に注目すれば, 変化を強調しない—関数それ自身は変らない.52
(52 物理学者は運動に関する推論の道具として, 粒子の 「世界線」を導入することでこの視点を採用する時がある. われわれは(2.2.3 節で)これは信号処理システムを考える自然な方法であると述べた. 3.5.3節でストリームの信号処理への応用を述べる.)

SICPの著者は、

物理学者は運動に関する推論の道具として, 粒子の 「世界線」を導入することでこの視点を採用する時がある.

この言及以外に何度も物理学の知見を披露しており、物理学の素養があります。
ここが非常に重要な論者の素養による洞察であり、
「計算機科学」を数学理論ではなく、我々が棲息する物質世界の一部の事象として捉えています。
これが重要。
ほとんどの「計算機科学」の研究者、あるいは技術者にはこの視点が徹底的に欠落しており、
だから、結構ろくでもない状況になっています。話してもまったく通じない。
ちゃんと勉強してるの？って私などは思ってしまうんですが。
知識としてあるだけで、異なる分野の関連を結び付けられないのであれば、それは知性のセンスのなさです。
私はだからこそ、拙書のDay1の関数型プログラミングのフックが終わった後の
Day2の最初部分で、もういきなり、物質世界のことを書き始めました。
コンピュータとは、ハードウェアとソフトウェアで成り立っている不思議な存在であり、
計算という事象も、物質世界で起こっているのである、論理世界の中で完結するものではない、
とさんざん強調しましたが、これを上記の書評のように「わかりやすい」充実した内容だ、
と素直に理解できる知性もあれば、何を言っても伝わらない愚鈍があったのは、
まさに拙書で予想したとおりとなりました。
この「計算機科学」が「物質世界」の挙動を考慮する必要があり、
物理学の知見と関係があると示すのは、最終的にはもちろん、このように最終部分のFRPのことまで一本の線をつなぐためには絶対に必要な地ならしでした。
そして、この物理学者が、物理で記述するのが、

これらの論点を数学関数を使って考えてみよう.
量xの時間変化する振舞いを,
時の関数x(t)と書くことが出来る.
xを時刻時刻に注目すれば, それを変化する量だと思う.
しかし値の全時間の歴史に注目すれば, 変化を強調しない—関数それ自身は変らない.52

という結構、中学でも高校でも習うごくごく物理の基礎的な数式展開です。

関数それ自身は変らない.

これは要するに、時間変化であろうがなんであろうが、
時間変数＝時刻にたいして、
物質世界はイミュータブルな関数として記述される、ということです。
そして、この時間変数の関数をプログラミングで実現する技術こそが、
何度も話しているFRPであり、拙書のDay4で具体的な技術として解説している、Facebook-Reactです。
もちろん、Facebook-Reactでは概念実証としては、極めて不十分ですから、
より時間の関数であることを完全に概念実証した自前の
timecomponent
を提示しました。計算可能な任意の時刻の値にイミュータブルにアクセスして
値を返す関数です。
そして、このFRP技術を可能にするのが、
まさに時間軸を無限の並びとして扱う、遅延評価なんですね。
SICPでは続いて、以下のように論じられています。

If time is measured in discrete steps, then we can model a time function as a (possibly infinite) sequence. In this section, we will see how to model change in terms of sequences that represent the time histories of the systems being modeled. To accomplish this, we introduce new data structures called streams. From an abstract point of view, a stream is simply a sequence. However, we will find that the straightforward implementation of streams as lists (as in section 2.2.1) doesn’t fully reveal the power of stream processing. As an alternative, we introduce the technique of delayed evaluation, which enables us to represent very large (even infinite) sequences as streams.
時を離散ステップで測るなら, 時間関数を(無限かも知れぬ)並びとしてモデル化出来る. 本節ではモデル化しようとするシステムの時間史を表現する並びを使い, 変化をモデル化する方法を見よう. そのためにストリーム (streams)という新しいデータ構造を取り入れる. 抽象の視点からはストリームは単なる並びである. しかしストリームを(2.2.1節のように)リストとして簡明直截に実装しても, ストリーム処理の力を十分に発現出来ない. その代り 遅延評価(delayed evaluation)の技法を取り入れよう. それを使えば非常に長い(無限でさえある)並びでもストリームとして表現出来る.

ストリームは遅延リスト

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-24.html#%_sec_3.5.1
http://sicp.iijlab.net/fulltext/x351.html
3.5.1 Streams Are Delayed Lists
3.5.1 ストリームは遅延リスト

In general, we can think of delayed evaluation as demand-driven'' programming, whereby each stage in the stream process is activated only enough to satisfy the next stage. What we have done is to decouple the actual order of events in the computation from the apparent structure of our procedures. We write procedures as if the streams existedall at once” when, in reality, the computation is performed incrementally, as in traditional programming styles.
一般に遅延評価は 「要求駆動」プログラミングと考えることが出来る. ストリーム処理の各段階は次の段階を満足させるのに十分なだけ起動される. これまでやったのは計算における事象の実際の順を, 手続きの見かけの構造と 切り離すことである. われわれは伝統的なプログラミングスタイルでのように, ストリームがあたかも「みんな一緒に」存在したかのように手続きを書くが, 実際は計算が漸進的に実行される.

ここにも、SICPの著者のたいへん秀逸な知見があります。
遅延評価とは、一般化すると、「要求駆動」＝イベント駆動（ドリブン）のプログラミングである、ということです。
これは、もちろん拙書でも、同じであるからこそ、
「必要なときに必要な分だけ計算する方法」とわざと書いていて、
それは、「イベント駆動」と同じである、
論理と計算が分離されたやり方である、そして宣言型である、と何度も説明しています。
そして、しつこいようですが、何度も言いたいのですが、
こういう解説は、拙書とSICP以外には見たことがありません。

——

JavaScriptを関数型プログラミング言語として使う是非について

を論点として明示的に切り出し、対立論者を批判する、という予告をしていました。
というより、対立論者、反論、といっても正直ここは、

「非常にレベルが低い」論点だと思っています。

Amazonのレビュー

なぜ関数型プログラミング本でHaskell, Erlang, Clojureなどの関数型言語を採用しなかったのか。
本書を手にする人達は、少なからず関数型言語に興味があり、まさかJavaScriptで関数型プログラミングやろうとなんて考えていないかと思います。

というトンデモ見解については、ここまであからさまなもの、よりオブラートに包んでいるが根本的に同様の勘違いをしているもの、
例えば
Qiitaに、また素性の知れない文責を伴わない無責任な（恥の）書き捨て中傷記事
『関数型プログラミングに目覚めた！』のレビュー（Day-1）について

素人としては深入りを避けたいと思いますが、そうだとすればそもそもJavaScript選んじゃったのが関数プログラミングへの無理解を象徴的に示すものなのだということになるような気がします。）

とりあえず
「素人としては深入りを避けたい」
と言い訳しながら、
（著者の）「関数型プログラミングの無理解を象徴的に示すもの」
だとか、あからさまに中傷するあたり、お里がしれます。

なんにも知らないで、また「書評・レビューのフリ」をして「中傷」しているんだな・・・

と呆れるばかりです。非常に低レベルです。
こういう連中は、「技術の正確性」を喧伝し、
私にたいして「理解していない」「嘘を言うな」と文句を言いますが、自分の無理解やデマの拡散にはまるで無自覚です。

【害悪】なのは、JavaScriptは、関数型プログラミングに適していない、という事実に反するデマを拡散し、学習者に誤解させることです

上記、FRPのデモでも明らかであるが、現在、JavaScriptが一番FRPの実装が、Facebook-Reactを中心に進んでおり、実用化されている。

関数型プログラミングと言語の結びつきの思い込み

何度も持ちだして申し訳ないですが、
「お絵かきロジック」はOCamlという関数型言語で書かれていましたが、関数型のコードではありませんでした。
基本、どの関数型言語でやろうと、時間が本質的であることに無頓着で、考慮せず、なんらかの破壊的代入をやっている限り、それは関数型プログラミングではありません。