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日間』を大変多くの方々にお買い求めいただき、感謝します。本書の全目次を公開し、質問を受け付けます。

2015年4月7日火曜日

関数型プログラミングに目覚めた! IQ145の女子高生の先輩から受けた特訓5日間

登場人物

セキヤ
高1男子。都内の進学校に通っている。
プログラミングが趣味でコンピュータ部に入部した。
サクラ
高2女子。IQ145の知能を持つ美少女。
セキヤの学校のコンピュータ部の先輩で、セキヤを厳しく指導する。
コンピュータ部では、いち早く頭角を現し、現在は高3部員を差し置いて部長として君臨する絶対的存在。
プログラミングスキルは『神の眼』と呼ばれる全能レベルにまで到達していると一部では噂されているが、サクラのコードを読み解けるだけのスキルをもつ人材が部内にいない為、今のところ真相は不明である。

出版にあたって

enter image description here
▼『関数型プログラミングに目覚めた!IQ145の女子高生の先輩から受けた特訓5日間』
という当ブログエントリのタイトルの書籍名で、秀和システムより筆者の著書が出版されます。
▼発行日は、2015年5月1日ですが、実際にリアル書店の店頭に並ぶのは、4月23日(木)前後になるそうです。
Amazonでは『ただいま予約受付中です。
▼書籍の仕様は、
A5判
400ページ
本文1色
ISBNコード 978-4-7980-4376-0
ということで、ものがたりの自律的立ち上がり、解説内容の自律的構成と筆(キーボード)の勢いに任せながら書いていたら、案の定、まずまず結構なボリュームになりました。
▼本体価格は、
1,300円
で、結構なボリュームの割には入手しやすい価格帯に設定されていると思います。
今回、編集部より公式に、当ブログでも告知せよ、とのお達しが出ましたので、上記書籍フォーマットとともに、編集部の了解のもとに前回エントリで説明している騒動の影響で抹消されていた本書#Day1の素案となるドキュメントを『無料立ち読み』ということで再度公開いたします。
これは、あくまで当時の素案であり、出版される製品版とは異なります。また、あくまでDay1の立ち読みですが、これだけで、関数型プログラミングがどういうものか?おおまかな概略やメリットの説明、魅力はしっかりと伝わるように綿密に設計して書かれています。
(2015年4月13日追記)
一部、勝手な憶測をあたかも事実であるかのごとく流布している風説を確認しているので、筆者として事実を明確にし、訂正しておくと、本書の執筆と『数学ガール』とは何の関連性もありません。そのシリーズが存在するのはもちろん存じておりますが、私は読んだこともないですし、私が記憶している限り本書の企画当初からその書籍の名前があがったことすら一度もありません。
そもそも「教則本」を「ものがたり」の枠組みで構成する事は古今東西よくある形態であり、近い時代では『ソフィーの世界』にしろ、同類の手法を採用している書籍は、各種国内に存在しているものだけでも枚挙に暇がありません。なぜ常にその一つの類型である『数学ガール』だけが本書の「オリジナル」がごとく殊更持ちだされているのがよく道理がわからないのですが、要するに、本書はその他、数多くの「教則本」+「ものがたり」の書籍のひとつの類型である、とは言えます。
また、本書は学園モノであると言えますが、古今東西よくある舞台設定であり、日本では、樋口一葉の『たけくらべ』から、筒井康隆『時をかける少女』、眉村卓『ねらわれた学園』など、類似性を指摘されるのであれば、単にその類型であるということです。

Day1 それは「関数型プログラミング」という新しい世界の幕開けだった

ラブ・ストーリーは突然に

「ずいぶんとダサいコードを書いてるのね。」
不意に背後から声をかけられ振り向いて見ると、透き通るように白い首筋が目の前にあった。
「はっ、サクラ先輩!」
スラリとした長身を前かがみにしてモニターを覗きこむように見ている長い黒髪の少女の存在をセキヤが理解するまでに一瞬の間が必要だった。
放課後の電子計算機室。コンピュータ部の活動に自由に使用して良いことになっている。今日は他の部員は誰もおらず、セキヤ一人きりで黙々と作業をしていたのだが、いつのまにか部長であるサクラが様子を見に来ていたようだ。
「セキヤ君は何のプロジェクトやってるんだっけ?」同じ姿勢でモニターに表示されたコードを頭上からの冷たい目で凝視したままのサクラ。セキヤの反応を意に介する様子もない。
微かに甘い良い香りがしてくる。実際、お互いの息がかかりそうなほどの至近距離にセキヤは明らかに動揺していた。また自分の両方の耳は赤くなってしまっているのだろうな・・・先週サクラになじられた事を思い出しながらセキヤは精一杯の平静を装って答えようとする。
「えっと、今は何もやっていないです。プログラミングコンテストの地区予選に向けて過去問に挑戦しているところなんです。」
「あーそうなんだ。だけどこんなダサいコード書いてたらダメね。」
今日のサクラはセキヤの動揺をなじることよりも、セキヤが書いたコードのほうに関心があるようだ。
「えー?そんなにひどいですか。」おかげで少し余裕を取り戻しながら、セキヤは言ってみる。
「ダサい。まったくお話にならないわ。」見下すような冷淡さでバッサリと切り捨てられる。
「そうですか・・・どこがまずいのでしょうか?」
セキヤはこんな風にサクラと何気なく会話できている自分が嬉しい。内心は小躍りしたいような気分なのだが、表向きは平然と会話を続けられること自体が嬉しい。
教えて欲しい?
居直ってはじめてこちらを見たサクラの知的な目がキラリと光る。
のぼせ上がっており、もはや目の前のコードやプログラミングコンテストの地区予選のことなどはどうでもよくなっていたセキヤではあるが、ただただサクラとのこの時間を持続させたい一心で上辺の調子を合わせる。
「教えていただけると嬉しいです。」
「地区予選はいつだったっけ?」
「来月の頭くらいですね。」
少しのあいだ思案した様子で、サクラがおもむろに言う。
「まあ、ギリギリ間に合うかも。ちょっと特訓してみる?
自分の熱心さが部長のサクラに認められたのだろうか?
厳しいが美しく能力も高いサクラは、部員への面倒見も良く、絶大な人気がある。
雲の上のような存在であるサクラからの思ってもみないオファーにセキヤは心がうち震えるようだった。
この高校に入学できてよかった。コンピュータ部に入部して正解だった。
今、この瞬間、僕は青春を謳歌している!
セキヤは自分の幸運と幸福を噛み締めていた。

0から9までの数をすべて足すコードを書け

サクラは無造作に近くにあった椅子を引っ張ってきて、セキヤの隣に姿勢よく座った。「セキヤ君は、プログラミング言語は何を使いたいの?」
再びサクラと寄り添うような格好になってしまった上に、至近距離で自分の名前を呼ばれて著しく混乱してしまっているセキヤだが、なんとか振り絞るように答えた。
「JavaScriptです。」
「良い選択ね。ではまず、基本的なところから始めてみましょうか。
0から9までの数をすべて足すコードを書いてみて?」
「はい。余裕です!」
問題に向かえば、セキヤは不思議と心は落ち着く性分だ。躊躇なく書き慣れたコードをタイプしていった。
var s = 0;
for (var n = 0; n < 10; n++)
{
  s = s + n;
}

console.log(s);
45
「ほら、どうです!こたえは45になりましたよ。」
軽い達成感とともにセキヤは、サクラへ誇らしげに言う。
「動くだけで、やっぱり超ダサい。」
「え?」
「今どきこんなダサいコードを書いているようではなにかと厳しいでしょうね。」
「そうなんですか!?でもどこがダサいのかさっぱりわかりません。先輩がコード書いて、ダサくない見本を見せてくださいよー。」あえて甘えた感じでセキヤは言ってみる。
「仕方がないわね。私ならクールにこう書くわ。」
キーボード上に細長く美しい指が流れる光景に、しばしセキヤは見惚れてしまっていた。
「どうかしら。」
サクラの声に我に返ったセキヤ。コードをじっくりと見てみる。
var plus = function(a, b)
{
  return a + b;
};

var s = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
  .reduce(plus);

console.log(s);
45
「へ?なんだこれ?」
「クールでダサくないイケてるコードよ。」
「よくわからないですね。とりあえず僕のコードのほうが短くないっすか?」
「今のところはね。」
「あと、ダサいと言われ続ける今の僕のスキルじゃ、先輩のコードは意味がわからないし、ごちゃごちゃしてるようにも見えます。」
「生意気ね。ごちゃごちゃうるさいのはあなたよ。今からそれを説明してあげるんだから、ちょっと黙れ小僧。」イラッとしたサクラに叱咤されてしまった。
「申し訳ありません、サクラ先輩。大変失礼いたしました!」セキヤは半ば恍惚としてしまっていた。

フローは複雑でバグの元凶

サクラはちょっと考えてから作図アプリを立ち上げ、手際よくグラフを作成していった。
フローチャート画像
「セキヤ君、これが何かわかる?」
「もちろんです。フローチャートと呼ばれるもので、このフローチャートは僕が書いたコードの流れ、つまり僕のコードのフローをグラフ化したものです。」
「正解。」サクラは満足そうに頷いた。
「そして今回の問題はなんだったっけ?」
『0から9までの数をすべて足すコードを書け』でした。」
「そうね、では、このフローチャートをぱっと見て、
これが『0から9までの数をすべて足すコードを書け』の解法を示している
と即座に答えられる人はいったいどの程度いると思う?」
「たしかに、わかりにくいでしょうね。でも少しは居ると思いますよ。」
セキヤの若干の反抗を感じ取り、またちょっとイラついた様子のサクラではあったが会話を続ける。
「いいわ。では仮にこれが『0から9までの数をすべて足すコードを書け』という問題ぽいな!とすぐ見抜けるほど気の利いた人がいるとしましょう。でもこのフローチャートで表されるコードが、
『0から9までの数をすべて足すコードを書け』の解法として合っている
ということを確信をもって断言できる人はどのくらい居るのかしら?」
「それはまず居ないと言って良いんじゃないでしょうか。
コードにすぐバグが紛れ込む事はプログラマならば
誰でも身を削るようにしてよく理解しているはずです。
コードが正確かどうか確信をもって断言できると思ってる
プログラマが居るとしたら、そいつはモグリでしょう。」
「よくわかってるじゃない。」サクラは再び満足気に頷いた。
「つまりセキヤ君のコードはかんたんなようで実はかなり複雑なのよ。
コードの妥当性を検証するためには、頭の中でフローチャートに
従って順番に変数の値を追っかけて何度も確かめてみたり、
手っ取り早いのは実際にコンピュータでコードを走らせてみて
エラーが出るか試してみる事でしょうね。そのほうが速くて正確。
でも、エラーが出ないバグが一番やっかいね。
だから最終的には変数をウォッチするデバッグ機能なども利用して
変数の値を逐次検証していく必要はある。」
「おっしゃるとおりですね。」セキヤは同意する。
コードのフローを逐一追跡しながら隠れたバグを探し出すのは
ものすごい骨の折れる作業ですよね。よくわかります。」
「そして、これこそが多くのコードが抱える根本的な問題
バグを解決できずにプロジェクトそのものが頓挫することはままあるわね。
セキヤ君、あなたのコードがダサいと言われる理由は、そこにある。
フローは複雑でバグの元凶なのよ。

フローは不要

「先輩の言うことはもちろんよくわかるんです。
でもプログラミングって元々そういうものなんじゃないんですか?
フローがあってこそのコードですよね?」
「だから、その発想がダサいのよ。」うんざりとした調子でサクラが言う。
「そうなのかな?」
『0から9までの数をすべて足す』という問題には、繰り返しや条件判断といったフローはある?」
『0から9までの数をすべて足す』という問題自体には、繰り返しや条件判断といったフローはまったく確認できないですね。」
「では何故、セキヤ君のコードにはそんな複雑なフローの存在が確認できるのかしら?」
「それしか方法がないからですよ。この問題を解くには、繰り返しや条件判断といったフローを含むコードを書くしかない。フローは絶対に避けられないと思います。」
「ほんとうにそう?私のクールなコードはどうかしら?」
var plus = function(a, b)
{
  return a + b;
};

var s = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
  .reduce(plus);

console.log(s);
「うーん、言われてみればフローが消えてるなあ。僕のコードにあった
forループや条件判断がすべて綺麗さっぱり消えてなくなっています。
「少しは成長したわね。」サクラはまた満足気だ。
「いい?フローをもってコードを書くことは唯一の方法ではないの。
フローを書くことは複雑な仕事でバグの温床となるダサいやり方なので、
フローを書くプログラミングはもうやめなさい。
「なるほど。」
『0から9までの数をすべて足す』という問題にフローはない。
ならば、コードもそのままフローなしに書ければいいと思わない?」
「それが出来るならば言うこと無いです。コードはクールになりますね。」
「クールなコードでは、フローの設計やフローの妥当性の検証に労力を費やすようなダサい真似はしないのよ。」
「つまり、プログラミングの最大の課題であるデバッグの手間が激減するというわけですか?それはかなりクールなことになってしまう。」
「わかってきたわね。」
フローじゃなくて不要(フヨー)ですね。
「ダサいダジャレだけど、まさにそのとおりよ。」
口元をゆるませながらサクラは続ける。
「でもフローが不要という引き算だけでは、
私のコードの真価を理解しているとはとても言えないわね。」
「というと?どういうことでしょうか?」
 

フローを書かず論理をそのままコードに書き写せ

フローがない、フローの設計が必要ないということは、
問題の論理だけに集中しているってことに他ならないの。ここ重要。
セキヤ君は、プログラミングで
後々どうせ膨大な検証が必要となるフローの設計に時間を費やしたい?
それとも問題の論理だけに時間を費やしたいかしら?」
「それはもちろん、問題の論理そのものだけに集中してコードを書いていきたいです。」
「そうでしょう。私のコードのクールさの真価はそこにある。
問題の論理そのものに集中しているの。」
「もう少し説明をお願いします。」
「いいかしら?『0から9までの数をすべて足す』という問題について、
私のクールなコードでは、
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9] //0から9までの数
  .reduce(plus); 
  //をすべて 足す
と、単純に問題の論理そのものをコードへまる写しにしているだけ。」
「あ!?なんで?凄い・・・先輩、やっと見えてきました!」
「わかった?私のクールなコードでキモとなる部分はたったこれだけ。
問題の論理そのものを書き写しただけなんだから、
バグが介入する余地なんて最初からどこにもあるはずがないでしょ?」
「まったくないです。」
「ということは、つまり、私は本当に
『0から9までの数をすべて足すコードを書け』の解法として合っている
と確信をもって断言できるわけ。
プログラミングの世界で、
論理のみで構成された、
これ以上望めないほど見透しの良いクールなコードを書くことは、
ダサいコードを平気で書く常人プログラマーの想像を超えた
『コードを見透せる眼』をもつことに等しいのよ。」

『神の眼』のスキル レベル0

All-Seeing Eye of God画像
米1ドル札の『すべてを見透す神の全能の目』
(All-Seeing Eye of God)
このサクラの発言で、セキヤには少し思いあたる節があった。
「先輩、それはひょっとして『神の眼』のことでしょうか?部員がサクラ先輩は『神の眼』のスキルを持っているとかなんとか
噂しているのを聞きました。」
「あー、さあどうかしら?」
「これは『神の眼』のスキルなのですか?」
「なんとも言えないわね。」
「先輩、教えてください。噂の真相を知りたいです。」
「しつこいわね。まだレベルが低すぎるのよ。『神の眼』と呼ぶなら、
これはまだレベル0のスキルだから。」
面倒になったのか、あきらめるようにサクラは答えた。
「やはり『神の眼』のスキルは本当に存在するんですね!」
「私自身は、単に『見透しの良いクールなコード』とか
『コードを見透せる眼』と普段言っているわ。
それを彼らが大げさに誇張しているだけなんじゃないかしら?
だいたい『神の眼』と騒ぐようなたいしたことでもないの。」
「きっと先輩はIQ145あるからそう思うんですよ。部内では先輩のコーディングのスピードとコードにバグが出ないことは有名だし、僕らにしたら先輩が『神の眼』を持ってるとしか思えないんです。」
「そう呼びたければ『神の眼』でもなんでも好きにすればいいわ。」
まったく興味がなさそうに答えるサクラ。 
「先輩、僕は先輩のように『神の眼』のスキルが欲しいです。
今の僕はまるでダメですね。
これまで、問題の論理を上手にフローに変換してフローを設計する作業
こそがプログラミングだと勘違いしていたようです。
ダサい己のダサさを認めざるを得ません。」
セキヤはここぞとばかりに自分の熱心さを懸命にアピールしてみた。
「そうね、その自覚がもてればようやくスタート地点に立てたということ。
おめでとうセキヤ君、今あなたは、レベル0よ。」
「ありがとうございます。
『神の眼』のレベルがあがるように頑張ります!」

『神の眼』を得るための唯一の方法

「まったくしょうがないわね。」サクラはセキヤを見据えて宣言する。
「とにかく今後『神の眼』のレベルを上げていきたいのであれば、
問題の論理そのものをコードに単純に書き写す事を徹底的にやっていく
ということを常に肝に銘じて置いて頂戴。
これがクールなコードを書くための唯一の方法よ。」
「了解しました。」
少し間をおいて、サクラは言う。
「もういちど私のクールなコードでキモの部分を確認するわよ。
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9] //0から9までの数
  .reduce(plus); 
  //をすべて 足す
問題の論理そのものをコードに単純に書き写す事を徹底的にやっていく
まず0から9までの数という論理があるならば、
フローでごちゃごちゃやることなど考えないで、単純に
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
そのままのデータまるごと用意してしまうの。」
「わかります。」
「次に、その用意されたデータへ、
『をすべて足す』という論理操作をしてやるのね。」
.reduce(plus); //をすべて足す
という部分ですね。」
「これを合わせると、 『0から9までの数をすべて足す』
という論理をコードに書き写したことになるの。 ひたすら
問題の論理そのものをコードに単純に書き写す事を徹底的にやっていく
わかる?」

関数 / function という論理操作

「 先輩、
 .reduce(plus); //をすべて足す
ここなんですが、reduceとplusも2つともJavaScriptでいう関数ですよね?」
「ああそうね、関数について説明しておいたほうがいいわね。」
「僕はざっくりとしか理解してないので、おねがいします。」
関数というのは中学校の数学の授業でも習うとおり、もともとは数学用語なの。それがそのままプログラミング用語に転用されたものね。
数学・プログラミング用語として、英語ではfunction、それを和訳したものが関数
関数はfunctionの翻訳語として気の利いたものだとは思えないわね。
そもそものfunctionとは、機能、動作、操作、作用、という意味
関数=function=機能、動作、操作、作用とざっくりイメージして頂戴。」
サクラは、また作図アプリで手早く何か描き始めた。
関数イメージ画像
「だいたいこういう感じのイメージよ。
INPUT(インプット)とOUTPUT(アウトプット)というのはわかるわよね?」
「半ば日本語にもなっているので、それはよくわかります。
インプット=入力があってアウトプット=出力があるというやつですね。」
「これにxをINPUT(入力)してやると、
fが持ち合わせる機能により作用され変化したOUTPUT(出力)が出てくるわ。
このOUTPUT(出力)は、
fで作用して変化したという印(しるし)として
f(x)と書き表す習わしになっているわね。
x
f
f(x)
ということ。」
「工場にあるマシンみたいなものですね。」
「まあ、工場に限らないわよ。家庭にあるマシンもそう。
炊飯器、電子レンジみたいなマシンもFUNCTION・関数なの。
炊飯器という名前のFUNCTIONがあるわね。
これに米と水をINPUT(入力)してやると、
炊飯器が持ち合わせる機能によって作用され変化した
炊きたてのご飯というOUTPUT(出力)が出てくるわ。
x
f
f(x)
という表記でやると、
米と水
炊飯器
炊飯器(米と水)
ちょうどこうなるわよね。」
「あ!炊飯器(米と水)というのはちょうど
炊飯器というマシンの( 中 )に
米と水がゴッソリと投入された図式になっていますね!」
「そうね、イメージできたかしら?
そしてこの炊飯器というマシンOUTPUT(出力)である
炊飯器(米と水)とは炊きたてのご飯なので、
炊きたてのご飯 = 炊飯器(米と水)
という論理操作の関係、論理構造になっているわね。」
「関数・functionの意味を100%理解しました。」
「そうね、でももうちょっとガツンとくるイメージはないかしら?ああそうだ、セキヤ君は『大改造!!劇的ビフォーアフター』という庶民のための娯楽番組は知ってるかしら?」
育ちの良いサクラによる「庶民」という言葉遣いが少々気になったもののセキヤは答える。
「もちろん知ってますよ!
『様々な問題を抱えた家』があって、
超能力者みたいな『匠』がなんかやったら、
家が『大変身』しちゃう国民的オカルトドラマです。
Before(ビフォー)とAfter(アフター)の凄まじい変化を見たサザエさんの声の人が『なんということでしょう!!』って感激して、家族も感激して、その家庭には恒久的平和が訪れます。」
「まったくそのとおりよ。
INPUT(インプット)とOUTPUT(アウトプット)というのはこの際、
Before(ビフォー)とAfter(アフター)
とセキヤ君の脳内で変換してもらっても別に構わないわよ。」
「わかりました。」
「つまり、
Before(ビフォー)の『様々な問題を抱えた家』は
『匠』の手が加わると
After(アフター)の『なんということでしょう!!』
に『大変身』するわけ。
(Before)『様々な問題を抱えた家』 
↓『匠』
(After)『なんということでしょう!!』
『匠』はFUNCTION・関数よ。
だから、『匠』
『様々な問題を抱えた家』というBefore、言い換えると、
『様々な問題がある家』をINPUT(入力)すれば、
匠がその問題を『抱える』ことになり、
匠(様々な問題を抱えた家)となり、
その『大変身』したAfterは『なんということでしょう!!』なので、
なんということでしょう!! = 匠(様々な問題を抱えた家)
という論理操作の関係、論理構造になっているわね。」
「なるほど先輩、匠(様々な問題を抱えた家)というイメージもピンときました。
『様々な問題を抱えた家』の『様々な問題』を番組進行上、抱え込む当の人物は、家族でも番組スタッフでもサザエさんの声の人でもなく、
『匠』その人なわけで、
『匠』が『様々な問題を抱えた家』を抱え込むんですね!だから、
匠(様々な問題を抱えた家)となる。」
「そうね。あと念の為だけど、『なんてことでしょう!!』というのは、
『大変身したリフォーム後の家』のことで、ただ単にそう書くとツマラナイから象徴的に『なんてことでしょう!!』と言い表しているだけだからね?」
「先輩よくわかっています。」
「こんなのイチイチ説明させないでよ?」
「すみませんでした。」
わけもわからずセキヤは謝る。
「あと、この
炊飯器(米と水)というように、
炊飯器関数の()の中に投入した米と水のこと、
そして、
匠(様々な問題を抱えた家)というように、
『匠』関数の()の中に投入した『様々な問題を抱えた家』のことは、
引数(ひきすう、いんすう、argument、Parameter)
と呼ばれているので一応覚えておいて。」
「わかりました。そして
『関数・functionというものは、作用して変化させる、という論理操作』
であることもよくわかりました。」

関数は論理の最小単位の部品として最上の扱いを受ける

「先輩、
 .reduce(plus); //をすべて足す
で、 reduceplusという2つの関数が組みあわされて
『//をすべて足す』という関数になってしまっているのでしょうか?」
「まさにそのとおりよ。
『//をすべてxx』と『足す』という2つの関数が組み合わさっているの。」
「2つ関数が組み合わさって、
『//をすべて足す』という関数になるんですね。」
問題の論理そのものをコードに単純に書き写す事を徹底的にやっていく
ためには、あらゆるものがレゴブロックの様に組み合わされることが重要。
関数は、レゴブロックのような最小単位の部品なのよ。
論理の最小単位としての部品。
「先輩のコードをよく調べてみると、
 .reduce(plus); //をすべて足す
のうちplusという関数は、
var plus = function(a, b)
{
  return a + b;
};
という書き方で、
『足す』という論理の最小単位で部品として独立しているんですね。」
「そうね。セキヤ君、いいところに気がついたじゃない。
米と水
炊飯器
炊飯器(米と水)
の表記に対応させてやれば、ちょうど
a, b
function
function(a, b)
という形式になっているわね。
このコードのしょっぱなの
varというのは、定義するというコマンド(実行環境への命令)よ。
var plus =ということは今からplusを定義する、ということ。
plusという変数とは、
これこれこういう『足す』という論理操作の関数である!!
と定義してやってるのよ。もうちょっと日本語でひらたく言えば、
これこれこういう『足す』という論理操作の関数
にはplusって名前をつけてやりますよ、ってこと。」
「なるほど。先輩、『これこれこういう』っていうのは、
{
  return a + b;
}
の部分ですね?」
「もちろんそうよ。この{} 中括弧の中でその関数の論理操作、機能の説明、つまり論理の設計をしてやるコードを書くわけ。
 
いかにして炊きたてのご飯を出力するだけの能力がある炊飯器に仕上げるのか?きっちり設計するのよ。
『匠』ならば、『なんということでしょう!』というAfterの感動をもたらす『匠』の超能力の秘密をこの部分でクドクドとバラして、『匠』のリフォームスキルを徹底的に設計してやるの。」
「今回のこれこれこういう『足す』という論理操作という具体例でいえば、
  return a + b; 
という設計となっていますね?」
「そうね、returnっていうのもコマンドで、和訳すると「返す」みたいな意味。
abを足した値を返せ、と命令しているの。
つまり、この関数では、
  • OUTPUTとして、abを足した値を返せ、
  • abを足した値をOUTPUTとして出力せよ、
  • abを足すという操作をしろ、
まあどれでもいいわ。全部同じ意味。単に言葉の問題にすぎないわ。」
「よくわかります。」
「じゃあ、全力でまとめるわよ?
米と水
炊飯器
炊飯器(米と水)
の表記に対応させてやれば、ちょうど
a, b
function
function(a, b)
で、var plus = function(a, b)
とこのfunctionには、
炊飯器という名前と同じように、
plusという名前をつけてやったので、
a, b
plus
plus(a, b)
という流れになっているわね?」
「はいわかります。」
「このplusというfunctionの実体とはa + bという論理操作である。
そのように{} 中括弧の中で具体的にクドクドと説明され設計されてる。」
「はい、return a + b;というコマンドで、
abを足すという操作をしろ』と設計されていました。」
「そうね、これくらいでいいかしら?」
「先輩、炊きたてのご飯や『なんということでしょう!』に対応するのは何ですか?」
「だから、それはa+bという具体的な計算結果。
OUTPUT、計算のAfterの値じゃない。」
「ああそうか、なるほど。」
「こうなるわね。
米と水
炊飯器
炊きたてのご飯 = 炊飯器(米と水)
様々な問題を抱えた家 
↓匠
なんということでしょう!! = 匠(様々な問題を抱えた家)
a, b
plus
a + b = plus(a, b)
よろしいかしら?」
「よろしいです。」
「こうやって論理の最小単位をクドクドと説明して、きっちりと設計してやるの。そうやって仕上がった関数は、
レゴブロックのように自由自在に取り回せるし、
レゴブロックのように自由自在に組み合わせることができるわ。
こういう部品は、第一級オブジェクト(first-class object)ってクールに呼ばれているわね。」
「というと、JavaScriptの関数はファーストクラスのオブジェクトですか?クールですね。」
「ええ、JavaScriptの関数はゴリゴリのファーストクラスよ。
ファーストクラスな部品である関数は、
ファーストクラスなので第一級、最上級のクールな扱いを受ける
『足す』という論理操作は、それ自体が最小単位として独立しており、
きちんとファーストクラスの最上級の扱いを受ける資格があるのよ。」
「先輩、関数が論理の最小単位の部品、っていうことは、さっきの関数としての炊飯器や『匠』も最小単位の部品として最上の扱いを受けるってことですね?」
「もちろんそうよ。炊飯器や『匠』はファーストクラスで最上の扱いを受ける。ご飯がなくなったら炊飯器さえあれば、また炊けるじゃない。匠がいないと番組は成立しない。論理操作としての関数こそが重要なの。」
「よくわかりました。そういえば、CとかC++とかJavaとか、確か関数はこんな論理操作の部品となる特権など与えられていなかった気がします。」
「与えられていないわね。だからJavaScriptとは違ってこういうクールなやり方をするのはかなり難しくなるでしょうね。」
「関数がファーストクラスかどうか?っていうのはプログラミングではかなり重要なスペックなんですね。今後プログラミング言語を調べるときには注意してみます。」
FUNCTION・関数は、論理の最小単位の部品で最上の扱いを受ける。
ここはクールなコードにとって重要なところよ。」

問題の論理には結果など含まれていない

「先輩、炊飯器や『匠』はファーストクラスで最上の扱いを受ける価値があることはわかりました。では、『炊きたてのご飯』や『なんということでしょう!』はどうなんですか?」
「それらもファーストクラスの部品であり、もちろん自由に取りまわせるけど、クールなコーディングでは価値はないわね。」
「『炊きたてのご飯』や『なんということでしょう!』は重要ではないってことですか?」
「まったく重要ではないわ。」
「何故ですか?」
「それらは『OUTPUT』であり『After』であり『結果』にすぎないから。」
「でも、OUTPUTとか結果は重要なんじゃないかな・・・」
イラッとしたサクラはセキヤをキッと睨みつけながら言う。
「セキヤ君、あなたまだ何にもわかっていないのね!」
「す、すみません。」
「もういちど問題!」
「はい?」
「最初に出した問題よ。」
サクラはぶっきらぼうに言う。
「あ、『0から9までの数をすべて足すコードを書け』でした。」
慌てて答えるセキヤ。
「で、クールなコードを書く方針は?」
「えー『フローは不要。問題の論理をそのままコードに書き写せ。』でした。」
「そうね。じゃあ、問題に結果は含まれているかしら?
「え?」
「あなたは、OUTPUTという結果は重要だと思うのでしょう?で、『0から9までの数をすべて足すコードを書け』という問題の論理に結果なんてものが含まれているのかしら?」
「あ!問題の論理に、結果が含まれていることなどは絶対にありえません。
もし問題に結果(答え)が書かれてるならば、もはやそれは問題でもなんでもなく、単なる答えになってしまいます。」
「問題の論理にはけして存在しえないAfterの結果を重要視することは、
問題の論理をそのままコードに書き写す事に繋がるのかしら?」
「いえ、完全に間違った方向性ですね。」
「ではあなたは何故そんなダサい考え方をするの?」
「よくわかりません。無意識についそう考えてしまっていました。どうもすみませんでした。」
セキヤをなじることに飽きたのか、サクラは少し調子をゆるめた。
「いい?セキヤ君。これはダサいプログラマーの悪い癖なのよ。
『フローは不要』なのに、フローを書く癖が抜けないのね。」
「結果を重視する癖が、フローを書く癖と関係あるんですか?」
「大有りよ。あなたのダサいコードのフローチャート
フローチャート画像
を見てみましょう。
s+n →(結果)sであるとか
n+1 →(結果)nであるとか、
とにかくいたるところで『結果』を計算しているの。
そして次のループでその『結果』を利用して、
また次の『結果』を計算していて、
その次も・・・というループを10回繰り返すわけよね?」
「あーおっしゃるとおりです。先輩。」
「つまり、あなたのダサいコードは、
問題の論理にはありもしない『結果』を何度も何度も計算させながら
ループを回すというフローとして設計されている
念の為だけど、私のクールなやり方でも実行環境は私が感知しない、する必要もない裏で計算しているし、実行効率の問題を言ってるんじゃないわよ。
コードの書き方としてダサいと言ってるの。」
「もちろんわかります。」
「こういう、問題の論理とは一切関係もなく、
フローの中で何度も計算されて刻々と値が変化して、
フローの制御に組み込まれてしまっている
sとかnみたいな変数のことを状態変数と呼ぶの。
こんな、問題の論理とはまるで関係ない分際で、刻々と変化するような状態変数なんてものはなくしてしまいなさい。論理を設計する上で邪魔だわ。
フローがバグの元凶であるのと同様に、状態変数もバグの元凶よ。」
「たしかに、フローがあれば状態変数も必ずありますね。」

手順を分割するな、論理を分割せよ

「こういう結果を小出しにしながらフローを回すのは何故か?というと、
ダサいプログラマーは手順を分割しようとしているからよ。」
「というと、どういうことでしょうか?」
「『様々な問題を抱えた家』があるわよね?
①匠に玄関を直させる
⇒結果(プチAfter)『なんということでしょう』。
②匠に台所を直させる
⇒結果(プチAfter)『なんということでしょう』。
③匠に階段を直させる
⇒結果(プチAfter)『なんということでしょう』。
・・・
このように、手順を分割して逐一結果を小出しにしながら実行するのを
プログラミングだと思いこんでいるのね。
だいたいこんな小出し小出しにAfterを見せられる番組なんて面白くもなんとも無いわ!」
サクラは解説しながら、またイライラしはじめたらしい。
「確かに、自分のこと考えればしっくりと来ます。というか、これ以外の考え方なんてしたことがありませんでした。僕はダサくて愚かです。」
サクラのイラツキを察したセキヤは殊更に反省した素振りを従順にアピールする。
「そうでしょうね。
それに対してクールなプログラマーは論理を分割しようとしているの。
もう何度も言ってるわよね?
論理の最小単位である関数という論理操作を自在に組み合わせて論理を設計していくって。」
「はい。言っておられます。」
「『様々な問題を抱えた家』があるわよね?
『玄関の専門的スキルをもつ匠』を設計する。
『台所の専門的スキルをもつ匠』を設計する。
『階段の専門的スキルをもつ匠』を設計する。
それぞれの匠を論理的に自在に組み上げて、
最終的に『たったひとりの匠』に仕上げる。
この彼こそが『様々な問題を抱えた家』の『様々な問題』を一挙に解決する能力をもつ『万能のスーパー匠』なのよ。
ここまですべて論理操作の構成しかやっていないの。
問題の論理そのものをコードに単純に書き写す事を徹底的にやっていく
そして、『万能のスーパー匠』を組み上げることこそが問題の論理であり、
それはそのまま問題の解決になるの。
途中の過程で逐一命令する必要など皆無なのよ。
『万能のスーパー匠』はすべてやり方を知っており、その行動についてこちらはいちいち口出しない。
最後の最後に結果を一度だけみると、
Before(ビフォー)とAfter(アフター)の凄まじい変化を見たサザエさんの声の人が『なんということでしょう!!』って感激するのよ。」
「家族も感激して、その家庭には恒久的平和が訪れます。」
「それをやっているのが私のクールなコードなのよ。よく見なさい。」
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9] //0から9までの数
  .reduce(plus); 
  //をすべて 足す
reduceplusという2つの関数が組あわさって
『//をすべて足す』という関数になっているわね?
この2つの関数が、『匠』よ。
これは、それぞれ逐一実行しろ、という計算の手順書ではないわ。
2つの関数を組み合わせて、
『//をすべて足す』という『スーパー匠』を設計してやっているのよ。」
 
論理操作の組み合わせの設計だけで、Afterという結果や、フローも、途中の計算手順も、変化し続ける状態変数も何ひとつないんですね。」
「そう。
手続きを分割して結果を小出しにするループのフローを書くのではなく、
論理を分割し論理だけを構成しなさい。いいわね?」
「はい。よくわかりました。」

『まとまり』は美しい単一の論理構造


「セキヤ君、いい?
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9] //0から9までの数
というのは『まとまり』なの。
『まとまり』というのは、
まとまっているのだから極めて単純で美しい論理構造なの。
『まとまり』という単一の論理構造はこれ以上分割する余地はない
しかし、こういうせっかくの単一の『まとまり』という論理構造を、
わざわざバラバラにしてしまって、手順を分割してしまう。
結果を小出し小出しに計算していくのがあなたのダサいコードなのね。
繰り返し処理っていうのはそういうこと
論理構造を無視し、手順に溺れる、それがダサい繰り返し処理というフローなのね。
フローは不要。
 
『まとまり』は美しい単一の論理構造、ですね。わかりました。」 

『まとまり』をまるごと処理ができる関数

「この『まとまり』をまるごと処理ができる関数が、実は
.reduce(plus); //をすべて足す.reduceなの。
セキヤ君、これを見て気がついたことを言ってみて。」
「同じ関数でも.(ドット)が頭についていますね。」
「まず.(ドット)が頭についていることについて説明してあげるわ。」
「お願いします。」
「そもそも、この.(ドット)は、
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9] //0から9までの数
  .reduce(plus); //をすべて足す
というように、[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]という配列に紐付けられているわけね。
JavaScriptの配列には、reduceというファーストクラスな関数が、最初から装備されているということなの。
このreduceはJavaScriptの配列お抱えの論理操作の最小単位なのよ。
配列はぜひ、この論理で操作してください、と周到に前もって準備がなされているのね。」
「先輩、なぜそのような周到な準備がなされているのでしょうか?」
「なぜなら、配列というものが『まとまり』だからよ。
配列という『まとまり』をまるごと処理ができる関数が用意周到に準備されて提供されているの。
実際、[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]というのは、
問題の論理そのものをコードに単純に書き写す事を徹底的にやっていく
というクールなポリシーに従って、
そのままのデータまるごと用意してしまったわけね。
こういうクールなやり方では、配列という『まとまり』をまるごと処理ができる関数は必要不可欠になるのよ。」
『まとまり』は美しい単一の論理構造、それをまるごとそのまま処理できてしまう関数が必要不可欠。」
「そういうこと。他に気がついたところはある?」
「あと、plusは普通に『足す』とわかったんですが、reduceという言葉の意味が不明です。普通に訳せば減らすですよね?」
「ああこれは、むしろ数学用語なの。
通分する、約する、方程式を解くという意味で使われるわ。
今回のケースでは、
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9] //0から9までの数
をすべて足すと45というように、
10個のデータが計算されてひとつに集約されるじゃない。
だいたいそういう操作のイメージよ。」
「なるほど、そう言われてみると合点がいきますね。」

他の関数を取り扱う能力をもつ関数

「次に、 .reduce(plus); //をすべて足すというように、
plusを引数として取り入れていることについて説明。
さっきみてきた通り、 plusという関数は『足す』という論理操作。」
「はい、論理の最小単位として自由に取り回せます。」
reduceは配列という『まとまり』をまるごと操作できる関数だけど、
同時にこういう
plusみたいな他の関数を取り扱う能力をもった特別な関数なの。」
「なるほど。だから組み合わせができたんですね。」
「こういう他の関数の取り扱う能力を備えた関数のことを特に
高階関数(higher-order function)と呼ぶわ。
ほんとは名前なんてどうでもいいのだけど、他の人たちもそう呼ぶので、
話を合わせるために一応知っておいたほうがいいわね。」
「JavaScriptのreduceは高階関数である、と言われても今後凹むことはなさそうです。役立ちます。」
「プログラミング言語って世界共通語といえるけど、高階関数っていう名前は、日本語ローカルだからどうせ外国では意味が通じないの。だからといってhigher-order functionって覚えたら今度は日本国内では通じにくいし所詮その程度のものよ。」
「こういう専門用語は日本語・英語どっちで揃えるかややこしいですね。」

高階関数の柔軟性

「でも、高階関数の存在価値って何?こんなものが世の中に存在している価値ってあるのかしら?」
「もちろんです、先輩。専門的匠の集団から万能のスーパー匠を組み上げる際などには必要不可欠だと思われます。」
「まったくそのとおりね。今回のかんたんな問題でもっと具体的に論じるとどうなるかしら?」
「今回の場合で言うなら、
reduceは、『//をすべてXXする』という、
まとまりへの操作として事前準備されているんですよね?
XXというのは、この高階関数が引き受ける別の関数に応じて変化して、
今回は『足す』だったので、組み合わせで、
『//をすべて足す』でに仕上がっていたはず!」
「だから、どういう存在価値?」
まとまりへの操作っていうのは、いろんなパターンがありえます。
だからそのやりたい操作に応じて柔軟に関数を渡せばいいのでは?」
「セキヤ君もなかなかやるじゃない。じゃあこのパターンはどう?
『すべて足す』のではなく、
『すべて掛ける』パターンはどうすればいいのかしら?」
『足す』能力を備えた匠を、
『掛ける』能力を備えた匠に入れ替えたらいいんです。
だから、『掛ける』能力を備える匠をまず設計してやれいいのです。」
「では見せて頂戴。」
「多分、余裕です!」セキヤは意気込んでタイプしはじめた。
var multiply = function(a, b)
{
  return a * b;
};

var s = [1, 2, 3, 4]
  .reduce(multiply);

console.log(s);
24
「いかがでしょうか?」
「合格。」

論理の最小単位としての関数のちから

「先輩、こんな風に何でも関数は組み合わせられるのでしょうか?」
「今回、たまたま高階関数というホストの存在があったから
組み合わせられたのよ。」
「ああ、そうか。」
「なんでもかんでも関数は組み合わせたら良いはずもなくて、それは個々の関数のスペック、性格によるわ。
たとえば、私自身が設計したplus関数だけど、
var plus = function(a, b)
{
  return a + b;
};
見てのとおり、これはそもそも問題の論理部品として必要な、数値を足すという操作を想定して私は書いたの。」
「そうですね。」
「たとえば、今セキヤ君が設計したmultiply関数だけど、
var multiply = function(a, b)
{
  return a * b;
};
同じように、数値を掛けるという操作を想定して書いたんでしょ?」
「たしかにそのとおりです。」
「私達が書いた関数が引数として引き受けるのは数値を想定していて、他の関数を引き受けることまではまったく想定していない。」
「高階関数は他の関数を引き受けることを想定していますね。」
reduceという配列のお抱え高階関数にしたって、それは誰かがそういう別の関数を引き受けながら操作を実現する想定で設計して書かれたものなの。」
「一口に関数といっても、それぞれの論理を設計するときに、想定みたいなことが事前にあるんですね。」
「そこまで全部含めて、
問題の論理そのものをコードに単純に書き写す事を徹底的にやっていく
ということなの。」
「もちろん、このplus関数だって、論理を設計するときに、別のファーストクラスな関数を引き受けてなんか処理するほうがいいのならば、そのように設計して書くのは十分アリだわ。でも今回は、そういう問題ではなかったので、数値のみを扱う関数と想定してこう書いたわけ。」
「なるほどー。先輩、いろいろ全体像がつながってきました。
問題の論理そのものをコードに単純に書き写す事を徹底的にやっていく
ときには、関数はファーストクラスの部品としてバラバラに取り扱えるし、
部品としてのそれぞれの関数も、問題の論理に必要なように想定して設計していくんですね。
関数単位のコードってなんか素晴らしいなあ。」
「フローを設計するよりも、よほどクールでしょ。
これが論理を設計するということなの。」サクラは笑みを浮かべる。
「関数という論理の最小単位の部品をもってすれば、
問題の論理そのものをコードに単純に書き写す事を徹底的にやっていく
ことは容易いような感じがしてきました。」
「なんでもできるわ。これは本当にクールな方法なのよ。」
「でも『神の眼』のスキルとしてはまだレベル0なんですよね?」
「レベル0ね。でも今日セキヤ君はいちばん大事なキモの部分を学んだのよ。」
「ありがとうございます。サクラ先輩。」
「あ、ちなみに、この関数という論理の最小単位で、
問題の論理そのものをコードに単純に書き写す事を徹底的にやっていく
というクールな方法を世間では関数型プログラミングって呼んでいる。」
「名前なんてどうでもいいけど、他の人たちもそう呼ぶので、知っておけば話が合わせられるし、凹むこともないですね。僕が欲しいのはあくまで『神の眼』のスキルです!」
「まだレベル0だから頑張りなさい。
もう今日は遅いからここまでにするわ。」

これからの数日間

「サクラ先輩、今日はどうもありがとうございました!」
「はい。早くPCの電源落としなさい。さっさと帰るわよ。」
これから数日間、サクラとこんな濃密な時間が共に過ごせるのだ、
そう思うとセキヤは再びこう考えるしか無かった。
この高校に入学できてよかった。コンピュータ部に入部して正解だった。
今、この瞬間、僕は青春を謳歌している!
セキヤは自分の幸運と幸福を噛み締めていた。

本書の目次(構成)

Day1 それは「関数型プログラミング」という新しい世界の幕開けだった

ラブ・ストーリーは突然に
0から9までの数をすべて足すコードを書け
フローは複雑でバグの元凶
フローは不要
フローを書かず論理をそのままコードに書き写せ
『神の眼』のスキル レベル0
『神の眼』を得るための唯一の方法
関数 / function という論理操作
関数は論理の最小単位の部品として最上の扱いを受ける
問題の論理には結果など含まれていない
手順を分割するな、論理を分割せよ
『まとまり』は美しい単一の論理構造
『まとまり』をまるごと処理ができる関数
他の関数を取り扱う能力をもつ関数
高階関数の柔軟性
論理の最小単位としての関数のちから
これからの数日間

Day2 『論理世界』と『物質世界』の狭間を見据える 『神の眼』レベル1

カメレオンガール
『関数型プログラミング』のおさらいをする
0から9までの数をすべて足すコードを書け
0から999までの数をすべて足すコードを書け
『神の眼』のスキル レベル0の限界に到達
『神の眼』を得るための唯一の方法 もういちど
電卓(Calculator)という電子計算機=コンピュータ
計算の手順を並べるコード 命令型プログラミングのコード
命令型プログラミングのコードは『マシン操作手順書』であり『フローは不要』のフローそのもの
計算の命令ではなく論理を並べるコード
『フローのない論理の宣言書』である宣言型のコード『宣言型プログラミング』
関数型プログラミングをやっていけば自動的に宣言型プログラミングになっていく
『神の眼』のコードは宣言型のコード
論理と計算の関係への疑問 ソクラテスの『無知の知』
『論理』と『計算』は別物 『論理』は人間とは関係なくただそこにある存在、それを人間が明らかにする行為が『計算』
『計算』とは『論理』の物質化、ハードウェアモード
『論理世界』と『物質世界』を見据える 『神の眼』
『物質世界』密着型の命令型プログラミングという原始的パラダイム
『論理世界』密着型の宣言型プログラミング
命令型のコードでしか動かせないはずのハードウェアが、なぜ宣言型のコードで動くのか?
『車輪の再発明』をするな
プログラミング言語の進化
JavaScriptが関数型プログラミング言語である理由と再評価された経緯
プログラミングの未来
技術的特異点 『シンギュラリティ』
紅茶の時間
今から『車輪の再発明』をしよう Back to ハードウェアモード
0から9までの数をすべて足すコードを書け reduceの再発明
偶数10個を求めよ mapの再発明
関数を合成してみる
合成関数を生成する関数 composeの再発明
『まとまり』生成関数 rangeの再発明
0から9までの数をすべて足すコードを書け
0から999までの数をすべて足すコードを書け
『神の眼』のスキル レベル1 
『まとまり』という論理構造をまるごと操作する関数ライブラリは、『神の眼』が見透す、宣言型のコードを書くために必須の関数@ハードウェアモード大全集
大事なことなのでレベル1の内容をまとめておく
『明日』という輝く未来

Day3 論理を世界の中心に据える世界観 世界のすべてを見透す 『神の眼』レベル2

イパネマの娘
三種の神器
JavaScriptのサーバサイド技術 Node.js (io.js)
io.js
『神の眼』レベル1のおさらい
命令型のコードは『フロー』で駆動する『フロー駆動』
宣言型のコードは『イベント』で駆動する『イベント駆動』
『イベント』とは時間軸上の、ある時間における出来事(イベント)
時間のフロー(流れ)が宣言型のコードを駆動する イベント駆動は、時間フロー駆動
0から9まで1ずつ増える数をすべて表示せよ
『インクリメント』は『計算』であって『論理』ではない
宣言型のコードは問題の論理のみを扱い、計算結果は扱わない 問題の論理には結果など含まれていない
論理を破壊する代入『破壊的代入』
命令型プログラミングのコードの上下左右に、同じ変数が異なる時間をもって異なる値で存在している混乱
宣言型プログラミングは参照透過である
破壊的代入する命令は、関数にする
命令前後の時間で値を変化させていくのではなく、同時に値の複数バージョンをもつ『まとまり』の論理構造を宣言し、まとめて操作する
計算や入出力の命令というハードウェアモードのマシン操作は論理の物質化だが、関数でラッピングしてふたたび論理化せよ
関数による『副作用』とは?
『副作用』NGなのは、関数がもはや自由自在にとりまわせる独立した部品ではなくなると同時に外界を変化させ参照透過でなくすから
『参照透過』と一緒に覚えておきたいワード『イミュータブル』
『神の眼』が見透す、限りなく透明でクリアな世界 宣言型のコードはイミュータブルで見透しが良い参照透過な論理の世界
論理≠計算『必要な時に必要な分だけ計算する方法』
論理=計算『手当たり次第の計算方法』
JavaScriptの計算方法=『手当たり次第の計算方法』+『必要な時に必要な分だけ計算する方法』
JavaScript は根本では、『論理』と『計算』が一緒くたになった『手当たり次第の計算方法』
もしもJavaScriptが『必要な時に必要な分だけ計算する方法』で全部やる言語であったならば?『論理』と『計算』の完全なる分離
十分な休息と栄養が必要
今日のこれまでの復習
0から9までの数をすべて足すコードを書け
『手当たり次第の計算方法』は『必要な時に必要な分だけ計算する方法』より考え方に大きな制限がある
『神の眼』のスキル レベル1の限界に到達
『物質世界』は『論理世界』の影のような存在にすぎない
ソクラテスの弟子プラトンによる『イデア論』
ピタゴラス学派『論理』が万物の根源であり世界の中心である 『イデア』
『ない』と『無限』というイデアは特殊
『物質世界』密着型の命令型プログラミングの『手当たり次第の計算方法』では、コードにすべての『イデア』は表現できない
『論理世界』密着型の宣言型プログラミングの『必要な時に必要な分だけ計算する方法』では、コードにすべての『イデア』が表現できる
JavaScriptで『関数』のみならず、『まとまり』にも『必要な時に必要な分だけ計算する方法』を適用してやる
Facebook発の関数ライブラリ Immutable.js
AtomエディタとNode.jsでやってみる
自然数という無限数列をつくる
フィボナッチ数列という無限数列をつくる 黄金比の数列
『必要な時に必要な分だけ計算する方法』で使うメモ化
自分で自分自身を抱え込む関数 再帰関数
再帰関数をメモ化する
『神の眼』のスキル レベル2
7月のプラネタリウム
ピタゴラス学派の『地動説』
アリストテレスの『天動説』
ガリレオ・ガリレイは、アリストテレスの『天動説』をひっくり返そうとした
『美しい未来』への招待

Day4 神はあまねく存在する 『神の眼』レベル3【最終レベル】

ブレーメンの音楽隊
『神の眼』レベル2のおさらい
バウムクーヘンと『地動説』と『天動説』
ピタゴラス学派の『地動説』
アリストテレスの『天動説』
『考え方』『ものの見方』を重視した偉人、アラン・ケイとスティーブ・ジョブズ
『ユーザ』を重要視し『グラフィカルユーザインターフェース』を発明した、パーソナルコンピューティングの父 アラン・ケイ 
『Think different』 稀代のビジョナリー スティーブ・ジョブズ
『Think different』『ものの見方を変える事はIQ80ポイントに匹敵する。』
デスクトップ上のアイコンは『オブジェクト』という『物質』であり『計算機』
アラン・ケイによるオブジェクト指向『論理は物質の手足である』メッセージング
アラン・ケイの宇宙観 『自由意志』が宇宙に命令する
超合理的に疑い続けた結果、『精神世界』を発見したデカルト 『精神』『物質』『論理』の三元論
『精神』『物質』『論理』の3つを『論理』へ一元化し『自由意志』を否定したスピノザの決定論的宇宙 神はあまねく存在する『汎神論』 
自由意志と決定論的宇宙『神はサイコロを振らない』 アインシュタイン
スピノザの『汎神論』と仏教の『空の思想』
『神の眼』のスキルの『神』は『スピノザの神』
『必要な時に必要な分だけ計算する方法』で『状態を保持しない』『参照透過』な『論理が物質を支配する』『論理中心主義』の関数型プログラミング
『あらかじめ計算して物質化したまま状態を保持する方法』で『論理は物質の手足である』『物質中心主義』のオブジェクト指向
オブジェクト指向の三元論であるMVC
アラン・ケイという権威とオブジェクト指向、MVCモデルというドグマ(教条)
『神の眼』のスキル レベル2の限界に到達 最終レベル・パラダイムシフトへ
部活動は一旦休憩にしてランチ
『フロー』の分離『スレッド』
マルチスレッドと問題点
関数型プログラミング、宣言のコードはシングルスレッド
シングルスレッドのイベント駆動のサーバサイド技術 Node.js (io.js)
Node.jsサーバの『車輪の再発明』
非同期処理とは、宣言型のイベント駆動
同期処理とは、命令型のフロー駆動
関数型クラウドコンピューティング AmazonWebService Lambda 次世代クラウドコンピューティングの新しい潮流
関数型プログラミングとUI(ユーザインターフェイス)
『論理世界』に『物質世界』のUIが追随するアプリは身近にある! 表計算アプリ
『物質世界』全部まるごとひとつの『まとまり』にしてバージョンナンバーをつけたら?それは『時刻』になる
表計算アプリのA1…..B1…..は、すべて同じ『時刻』という世界のバージョンナンバーを共有しているイミュータブルなデータ
あなたもわたしも世界の一部だから『時刻』という世界のバージョンナンバーを共有している
コードを観る眼の世界観
『あなたの意識』も『時間フロー』で一緒に時間軸上で遷移していくから、時計が動いて見える
『今』という『意識』とセットの時間軸上のイミュータブルなデータ 世界のすべてはイミュータブル
時間軸上の『まとまり』についてまとめて操作する関数のほんとうの正体
『神の眼』の視点で俯瞰する、静止した『物質世界』と『精神世界』
『論理中心主義』の世界観で表計算アプリを書く
表計算アプリ index.html
表計算アプリ index.js
『神の眼』のスキル 全能レベル 関数型リアクティブ・プログラミング(FRP)
ティーポットが空
必要な時に必要な分だけ計算される『まとまり』や『部品』のことを『コンポーネント』と呼ぶ
オブジェクト=あらかじめ計算して物質化した『状態』を保持し、外部に命令するミュータブルな計算機 命令型
コンポーネント=必要な時に必要な分だけ計算されるイミュータブルな論理構造 宣言型
FRPのUI設計は、『オブジェクト』で命令するのではなく、『コンポーネント』で論理的に宣言し、合成して組み上げる
Webページのドキュメントを記述するHTMLのツリー構造
DOMというWeb世界標準のAPI これまでWebは、命令型の『オブジェクト』をUIの標準モデルとしてきた 
UI『オブジェクト』モデルの『コンポーネント』化する技術、仮想DOM(Virtual DOM)
次世代Web世界標準 Facebook-React
Why React? なんでそんなことをFacebookが試みたのか?
Facebookの技術者はMVCというオブジェクト三元論のモデルを否定し、DOMという『物質』を、コンポーネントという『論理』の影に追いやり、『論理』への一元化を試みた
5分くらいは考えろ Give It Five Minutes
Reactの方針を公式サイトで確認する
jQueryはもう使わない
Hello John A Simple Component
Reactでは、HTML/XMLタグがJavaScriptコードに混在する
複数のコンポーネントを合成(compose)して使う
時間軸上でイミュータブルなReactのタイマー
render
componentDidMount
tickのsetState 時間軸上のイミュータブルなバージョン操作
getInitialState
componentWillUnmount
FRPはGUIだけではない
『物質世界』で時間遷移する『まとまり』のバージョンナンバーは『時刻』である
Reactは、時間軸上に偏在する『コンポーネント』のあらゆるバージョンの内たったひとつのBeforeAfterの論理関係のみを宣言している
『過去』『現在』『未来』、時間軸上の『全部』のバージョンを扱う
timecomponent タイムコンポーネントで時間軸上の全部のバージョンを扱う
timecomponent タイムコンポーネントでFRP
timecomponent タイムコンポーネントで過去にアクセスし、1秒前の過去をリアルタイム再生する
timecomponent タイムコンポーネントの合成 イベントの合成 マウスドラッグのイベント
『神の眼』のスキル
メキシカン
明日は学校

Day5 『今』が大事

Sunchyme(サンシャイム)
関数型プログラミングとオブジェクト指向プログラミングの関係性
関数型プログラミングに『マルチパラダイム』みたいなものは存在しない
関数型プログラミングでオブジェクトを作る仕組み クロージャ
FRPの関数ライブラリ
Atom Shellでデスクトップアプリ
海へ行こう

4 件のコメント:

Popular Posts