2015年5月10日日曜日

IQ145関数型プログラミング本の読者のご質問にお答えします① ITコンサルティング業の方へ

『関数型プログラミングに目覚めた! IQ145の女子高生の先輩から受けた特訓5日間』を大変多くの方々にお買い求めいただき、感謝します。本書の全目次を公開し、質問を受け付けます。という記事を当ブログにUPする前後から、多くの読者の方から、励ましのお言葉、著書の評価、ご質問をいただいております。どうもありがとうございます。

いただいたメールの中でも度々言及される、関数型プログラミングの古典の『計算機プログラムの構造と解釈』(Structure and Interpretation of Computer Programs。原題の略称SICPがよく使われる)の論評、本書との関連性についての記事など、その系統のお話をする、著書の副読記事シリーズを先に開始しようと思いましたが、メールのご質問の対応が追いつかなくなる前に、1エントリずつに分けて公開したいと思います。すべてのメール、また個々のメールで大変やりとりも長くなっているものもあり、全部は公開できないことはご了承ください。

またもちろん、公開してほしくない、ということであれば、その都度メールで釘をさしてください。

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

ご挨拶

はじめまして。34歳のITコンサルティング業に携わっているものです。
この度、「関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間」を購入し、ドキドキワクワクしながら、先日1周読み終えたところです。この度、「質問を受け付けます」の投稿を拝見し、メールした次第です。

この本のことは、Qiitaで話題になっている時から存じ上げていました。
2015年1月から関数型プログラミングを独学で学びはじめ、ネットを徘徊しているうちに岡部さまの記事に目がとまり
しばし(数日間)釘付けになっていました。無料なのにとんでもない記事を発見してしまった!と。
刊行されることがわかり、amazonにて即予約しました。

私は数学的背景がありません。もっと言えば文系です。さらにいうと高校生の時に数学に挫折し文系転向しています(笑)。
ですが、関数型プログラミングが私の環境に与えるかもしれない影響を考えると、是が非でも身に付けたいと思えるようなテーマであり今からでもゼロから学び始める価値があると感じました。そして、いつかの若かりし自分に喝をいれたいという気持ちも湧き上がって、勉強にはまっています。

なお質問者の取り組みレベルですが、次の書籍は勉強素材として活用し、ある程度内容を理解しているつもりです。

  • プログラミングの基礎
  • すごいHaskellたのしく学ぼう!
  • 関数プログラミング実践入門
  • なぜ関数プログラミングは重要か
  • 離散系の数学(コンピュータサイエンス大学講座)(理系の部下に勧められて勉強中)
  • 関数プログラミング 珠玉のアルゴリズムデザイン(これは途中で本をそっと閉じました)

これらのあとに関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間」を読み、感銘を受け、関数型プログラミングに関係する際の拠り所にしよう!と思っている状態です。できればキーワードはすべて暗記して、自分の言葉として定着化させたいです。

それではよろしくお願いいたします。

質問箇所

Day3
計算や入出力の命令というハードウェアモードのマシン操作は論理の物質化だが、関数でラッピングしてふたたび論理化せよ

質問事項

関数型プログラミングのスコープにおいて、計算や入出力という論理の物質化(ハードウェアのマシン操作)は、プログラマ(例えばアプリ開発者としての私)が行っても良いものなのでしょうか?

質問補足

私自身が何かの機会で勉強会の発表を務めた際に、もし尋ねられたらどうしよう、という動機で質問させていただきました。私は、関数型プログラミングの学習は Haskell を通じて行っています。この言語仕様では、いわゆる純粋な関数しか「私は」書けないので、計算や入出力は行っていないことになると思います(そして、入出力に関しては、IOモナドでのみ許されている)。

ですが、 javascprit のコード上では、セキヤはハードウェアのマシン操作をコードに落とし込んでいます。これは、本では車輪の再発明ということで説明されていて、実際はライブラリや先行事例を利用するようにあります。ただ現実の開発現場では、未知の問題として、もしくはセキヤのように敢えてハードウェアのマシン操作を「私が」書く必要性に迫られることもあるかと思います。この場合、関数型プログラミングのパラダイムで、どのように問題解決すれば良いのでしょうか。

言い換えると、関数型プログラミングをしているが、ハードウェアのマシン操作をすることもある(つまり命令する) 、というような言い回しは存在するのでしょうか。
もしかすると、本では(またはこのリンクhttp://kenokabe-techwriting.blogspot.jp/2015/04/amazon_28.html)、「そうである」と示してくれているのかもしれません。しかし、これまでの独学で、関数型プログラミングの枠組みではいかなる場合も命令型のコードを記述してはならない、と私が解釈していることもあり、どうにも自信がなく、ついにメールで直接質問してしまいました。

追伸

もいただきましたが、私の文章力、道理の示し方、論理構成、肉付け方、アウトプットについて、あまりにも過分な評価のお言葉をいただき、面映いので、さすがに割愛させてください。
申し訳ございません。本当にありがとうございます。

回答いたします(岡部)

はじめまして、著者の岡部 健です。
この度は、著書をご購入いただき、また、ドキドキワクワクしながら一生懸命読んでいただいて本当に嬉しいです。どうもありがとうございます。先日1周読み終えたところです、というとのことでまた何度か精読していただけるのでしょうから、なおありがたく存じます。

本書は、類書というものがひとつも存在せず、どのプログラミング本でも書いていない、本当に大事なことを書いたつもりです。僭越なものいいとなりますが、大変勉強しておられる延長で、なお本書を読解する大きな価値を見出していただけたことは、本書の解説内容が伝わったと実感でき、執筆した甲斐があります。プログラミングの勉強のために離散系の数学まで勉強しておられるってすごいですね。

また、私の及ばない文章について、過分なお褒めのお言葉もいただきまして嬉しいです。
どうもありがとうございます。
追伸にあった読み物についてですが、まずは無料の私のまた長い文章である、量子コンピュータ記事は面白いと思います。
本書を気に入られたのであれば、私の書き方や、哲学面も抵抗なく、参考になるのではないでしょうか?重複する内容も書いておりますし、読み応えはあるはずです。
http://kenokabe-techwriting.blogspot.jp/2015/01/blog-post_28.html
http://kenokabe-techwriting.blogspot.jp/2015/01/2.html

書籍ですが、率直に申し上げて、少なくとも、私自身が感銘を受けるほどに参考になった関数型プログラミング本はございません(苦笑)
関数型プログラミングは、「異なる考え方」が必要だ、とさんざん喧伝されるわりには、その「異なる考え方」がいかなるものか?心底実感ができてパラダイムシフトである、と理解できた文献はどこにも存在しなかったのです。
「異なる考え方」については、あらゆる書籍でも冒頭部分に申し訳程度に「さわり」があるだけで、その部分を本気で読者に伝えたいと思っている著者はあまりおられないようでした。そしてそれはおそらく、そこに踏み込むとまさに本書のように「関係ない哲学が延々と書かれている」「技術書としての体をなしていない」批判が容易に予想ができますから、執筆者としての防御本能も働いていることは想像できます。また、今となって読み返すと、その著者ご自身がどの程度その「異なる考え方」に踏み込んで理解しているのか?疑問もあります。

このような状況に結構、私は不満でしたので、本書の執筆の機会をいただいて、不明であったときの自分に是非読ませたいと思った内容そのままの本を今回全力で書きました。

あと、なんで人から薦められる技術系の本ってあんなにおもしろくないんでしょうね(笑)
薦められるくらいなのでよほど面白い、役立つのだろう、と期待値があがるせいでもあるのでしょうが、個人的には読んでよかった!という経験がこれまで一度もないもので、私のほうからはプログラミング本でオススメできるものはないです。
そのような状況の中、XX様のこのメールもそうですが、これまで、それなりの数の読者の方々から、本当に感銘を受けていただいた、喜んでもらったことがわかるフィードバックをいただいております。
これは多分他の書籍が提供できなかった紛れもない価値を創出した、と著者として自信が持てました。
本書は読み手を選ぶ本ではありますが(著者の意図としては残念です、念の為)、価値と良さを理解できる方は、本当にプログラミングスキルが他の人より向上すると思います。
ですから、おめでとうございます(笑)

その他私の記事では、おそらくご存知でしょうが、当ブログのReact解説2編です。
これは、本書ではまずまずいろんな事情で私の力が及ばず、私が考える品質基準としては解説が最後まで行き届いておらず、不十分で申し訳ないな、と思ったので、出版後にUPした記事です。
本書の延長として読んでいただけるとありがたいです。
FRPで実用的にアプリケーションを組むにあたり、今後必ず参考になるように書いてあります。

関数型プログラミングの「異なる考え方」について解説してある書籍について、フェアに補足しておく必要があります。
関数型プログラミング本の古典として、しばしば参照されるのは、SICPです。私がブログ記事にも書いているからか、読者の方々からも言及があります。
素晴らしいことに上記Wikipedia記事の外部リンクに、無料でHTML,PDF版が閲覧できます。
MITのCSコースの教科書として用いられ、関数型プログラミングの聖典とまで一部ではいわれているようなので、それこそ権威としてありがたく時間をかけて読む方は多いようです。

私個人が楽しめた楽しめなかったかは別として、SICPは高く評価します。
SICPを高く評価する理由は、この返信とも関係があるのですが、
また更に長くなるので、SICPについては、なぜ聖典と言われるのか?
考察とともに、続く記事に分離して論じます。

関数型プログラミングのスコープにおいて、計算や入出力という論理の物質化(ハードウェアのマシン操作)は、プログラマ(例えばアプリ開発者としての私)が行っても良いものなのでしょうか?

本書で解説しておりますとおり、ハードウェアモードの命令型の上層で宣言的なコードとして存在するのが、「関数型プログラミングのレイヤ」なのですが、
必要に応じて、ハードウェアモードの層を関数型プログラミングのひとつのパーツとして、
プログラマ自身が設計して用意する必要があります。
すなわち、関数として設計して用意するということです。
あとその関数を、設計した自分自身で、関数型プログラミングの部品として利用するわけですね。

そして、命令型、入出力っていうのは、やったらやりっぱなしですが、
関数でラッピングする=関数として設計して用意する
ということは、やったらやりっぱなしでなく、必ずその論理部品としての関数の返り値があるわけです。
これもそのハードウェアモードの作業との兼ね合いにおいて、どういう返り値にしたら、
論理的に整合性がでるか?考えながら設計します。

私自身が何かの機会で勉強会の発表を務めた際に、もし尋ねられたらどうしよう、という動機で質問させていただきました。私は、関数型プログラミングの学習は Haskell を通じて行っています。この言語仕様では、いわゆる純粋な関数しか「私は」書けないので、計算や入出力は行っていないことになると思います(そして、入出力に関しては、IOモナドでのみ許されている)。
ですが、 javascprit のコード上では、セキヤはハードウェアのマシン操作をコードに落とし込んでいます。これは、本では車輪の再発明ということで説明されていて、実際はライブラリや先行事例を利用するようにあります。ただ現実の開発現場では、未知の問題として、もしくはセキヤのように敢えてハードウェアのマシン操作を「私が」書く必要性に迫られることもあるかと思います。この場合、関数型プログラミングのパラダイムで、どのように問題解決すれば良いのでしょうか。
言い換えると、関数型プログラミングをしているが、ハードウェアモードのマシン操作をすることもある(つまり命令する) 、というような言い回しは存在するのでしょうか。
もしかすると、本では(またはこのリンクhttp://kenokabe-techwriting.blogspot.jp/2015/04/amazon_28.html)、「そうである」と示してくれているのかもしれません。しかし、これまでの独学で、関数型プログラミングの枠組みではいかなる場合も命令型のコードを記述してはならない、と私が解釈していることもあり、どうにも自信がなく、ついにメールで直接質問してしまいました。

素晴らしい質問ですね。
IOモナドについては、私自身今回の著作との関連を見極めて、おいおい記事をあげようと思っています。

これまでの独学で、関数型プログラミングの枠組みではいかなる場合も命令型のコードを記述してはならない

これは、基本、「神の眼」が見透す、時間に伴う状態変化を扱わない、
論理破綻がない、参照透過な、宣言型で書くべきだ、っていうことなんですが、
あくまで、水面より上の見えるところでその世界を構築したらそれでいいのですよ。

部品として、ここはハードウェアモードだ、ちゃんと返り値もある関数だ、ってやれば、
全体としては何の問題もないですよね??
これを、いずれにせよハードウェアモードを書くんだったら「関数型」だけのコードなんて書けない、
だから、関数型はプログラミングは銀の弾じゃない!
マルチパラダイムだ!とかいう人もいてQiitaでも論争になったわけですが、
そもそもパラダイムっていうのは、世界観、枠組みの話であるわけです。

あくまで、世界観、枠組みの階層のトップに、水面上で、参照透過な世界を構築するという、
その枠組みにおける至上命題がある。

それはシングルパラダイムなんですね。
そのシングルパラダイムの枠組みの下層で、ハードウェアモードの作業をすれば良いです。

もっというと、たとえば、LoDashや、Underscore、Reactという外部の関数型ライブラリが存在します。
これは「関数型ライブラリ」であるわけで、
当然関数型パラダイムを実現するためのライブラリであるわけです。

でも、その「関数型ライブラリ」自体は、多分ふんだんに命令型のソースコードをもって設計されている。
それら関数型ライブラリの中ではハードウェアモードの命令型のマシン操作をやっているでしょう。
その結果、いろんな便利な関数が提供されています。そして関数型プログラミングが実現できる。
これはマルチパラダイムとは言わない。
Undersocre,Reactで組むのは、関数型プログラミングじゃないマルチパラダイムなのか?
そんなことはなくって、単なるシングルパラダイムの関数型プログラミングです。

自分で「足りない」と思ったら、
たとえば、MY関数型ライブラリを外部に切り出して作ったらどうでしょう?
それ適用してやったら、おんなじように、単なるシングルパラダイムの関数型プログラミングだと言えますよね?

時間変化を扱うには、IOモナドなら解決というのは、結構な思考というか、理路の欺瞞があって、
まさに本書のDay3,4あたりでみっちり書いている世界観の話があります。
FRPですね。
たとえば、Reactは、IOモナドとは関係ないですが、まさにIO、UIの関数型ライブラリとして機能します。

いただいた返信

水面より上の見えるところでその世界を構築したらそれでいいのですよ。

なるほどですね。とてもすっきりとしました。関数型プログラミングを学ぶ際、入り口からOOPとの違いとして明確に述べられている世界だったので、プログラマは常にその世界にいなければならないものなのだという考えに自然と縛られていました。
何か、自由になった気分です(笑)

また、昨日のメールに含ませるのを失念したことがあるので、この返信に添えさせてください。

岡部さまの大事にしておられる、読者に対する関数型プログラミングの世界観の形成というのは、私の仕事である、「事業会社の情報システム部・業務部門に対する企画提案と推進」でも非常に重要な成功要因です。この感覚を持っていない人は意外と多く、そういう人は、のっけから「なぜやるかよりどうやるかを考えろ」などと周囲に言ってしまう有様です。

必ずしもその分野のプロではないステークホルダーに対して、やろうとすることの世界観を共有できるかできないか。これは例えばサービス開発のプロジェクトにおいて、一丸となって最後までやり切る原動力、苦しいときの拠り所、つまりぶれない信念の共有になると信じています。

その意味でこの本は、私がやろうとしている関数型プログラミングについて、私のぶれない信念を形成するために非常に価値がありましたし、それは著者がそのような意図で制作されているからなのだと思っています。

曲解しているようでしたら、生暖かく見過ごしてやってください。
以上、重ねて御礼申し上げます。どうもありがとうございました。


岡部の回答

この感覚を持っていない人は意外と多く、そういう人は、のっけから「なぜやるかよりどうやるかを考えろ」などと周囲に言ってしまう有様です。
必ずしもその分野のプロではないステークホルダーに対して、やろうとすることの世界観を共有できるかできないか。これは例えばサービス開発のプロジェクトにおいて、一丸となって最後までやり切る原動力、苦しいときの拠り所、つまりぶれない信念の共有になると信じています。

「やろうとすることの世界観を共有できるかできないか」

これは、特に最近アメリカではかなり広く共有されている考えかたですね。秀逸な知見であると同意します。

TEDカンファレンスの著名なスピーチ
サイモン シネック: 優れたリーダーはどうやって行動を促すか
http://u-note.me/note/1075

どうしてアップルはあれほど革新的なのか?

スティーブ・ジョブズ、キング牧師、ライト兄弟は何故成功したのだろう?アップルも他社と同じような広告代理店 ・コンサルティング会社を利用し、同じような人材が集まっている。なのにアップルだけが革新的な商品を世に送り続けている。

偉大な人間の考え方〜『WHY』から考えよう〜

「What」→「How」→「Why」ではなく、
「Why」→「How」→「What」ということですね。

人は「何を」ではなく、「なぜ」に動かされる
という知見です。

欧米のITブログや、ソフトウェア開発プロジェクトの冒頭紹介文は、以前は、
What is xx? であったのが、最近では、
WHY xx ? から始められることが大変多くなっています。

たとえば、FacebookのReactですが、
GUIDSの最初は、
https://facebook.github.io/react/docs/why-react.html
What is React? ではなく、
Why React?となっています。

https://angularjs.org/
でも、
Why AngularJS?
What is AngularJS?ではありません。

その意味でこの本は、私がやろうとしている関数型プログラミングについて、私のぶれない信念を形成するために非常に価値がありましたし、それは著者がそのような意図で制作されているからなのだと思っています。
曲解しているようでしたら、生暖かく見過ごしてやってください。

曲解はされておりません。まさにその通りなんですよね。
ご覧の通り、本書のDay1は無料公開もしておりますが、まさに、
Why Functional Programming?
「やろうとすることの世界観を共有できるかできないか」
この一番大事なことについて、かなり意図的に書いております。

なぜ、関数型プログラミングが魅力的でパラダイムシフトする価値があるのか?
それが最も大事で、読者が知りたい、求めている情報です。

そもそも私の知見ややり方一切合切含めて全否定された方による、その経緯における解説、
「関数型言語」に関するFAQ形式の一般的説明
http://qiita.com/esumii/items/ec589d138e72e22ea97e
というものがあります。

この解説記事は、初心者対象、らしいですが、
Why Functional Programming?に相当するっぽい唯一の具体的部分は、

関数型プログラミング・関数型言語の何がうれしいの?
例えば、上のsum関数であれば、sum(s,i)の戻り値がs + i + (i+1) + (i+2) + … + 10に等しいので、sum(0,1)が0 + 1 + 2 + 3 + … + 10に等しい、ということを数学的に検証(証明)することも比較的容易です! 後述の高階関数を用いれば、関数を部品に分けたり組み合わせたりすることが容易になるので、さらに独立性や検証可能性を高めることができます。

ということですが、はたして、関数型プログラミング・関数型言語の何がうれしいの?と知りたい初心者の方が、上記をみて「うれしい」と思えるかどうか甚だ疑問です。
だいたい、ほとんどの人は「数学的に検証(証明)」したいがためにプログラミングに取り組んでいるわけではありませんよね?この時点で世界に大きなズレがある。いったい誰のための解説なのか?

そして、この記事の他のすべての部分は、WHYでなく、WHATです。
何?何?何?で書かれています。
それが何?であるかどうかを列挙されても、けっしてWHY?世界観を共有することはできません。
考え方の違いを理解することはできません。

オブジェクト指向と関数型は対立していますか?
いいえ、データとそれに対する操作(メソッド)のまとまり(オブジェクト)を基本にシステムを構築するオブジェクト指向と、「副作用を用いない」関数型プログラミングとは、直交(独立)な概念です。

本書でも解説しております通り、そもそも「オブジェクト指向」いう言葉を使い出したのは、
パーソナル・コンピューティングの父と言われるアラン・ケイです。
「オブジェクト指向」とは、パーソナル・コンピューティング黎明期における、アラン・ケイやその他のビジョナリーによるアイデアであり、思想であり、その世界観を、新しい概念として彼らがまとめたものです。
「指向」という日本語の言葉でもわかりますが、それは方向性です。

この記事の解説者の一連の主張は、「オブジェクト指向」の理解がまず間違っているし、
関数型プログラミングの「パラダイム」「世界観」としての対比の解説としても間違いです。

「イミュータブルなオブジェクト」だとか、もはや「オブジェクト指向」のパラダイムではないわけですね。
この記事はそもそも、私の主張への対抗言論としてUPされたものであり、特にこの

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

の項目はそうです。

しかし、最初は、「同じ研究者(自分も含めて)が研究している」「どこそこの権威ある基調講演があった」というものごとの説明、理路ではない権威主義の言葉があるだけで、反論としても成立していないことを、私は批判しました。それを受けて、この項目に追記されたのが現バージョンなのですが、

もちろん、どんな言語(というかどんな技術や概念)でもあるように、関数型言語のファンでオブジェクト指向が嫌いという人も一定数はいますし:-)それは思想・信条の自由です。上の記述はあくまで理論の話です。

とさらに、言い訳がましい言及が追加されただけです。
オブジェクト指向とは「パラダイムの話」であり「思想」「世界観」であり、「あくまで理論の話」ではありません。

なんでこんな珍妙な氏の説明になるのか?というと、この解説者は、技術、ものごとの背景に存在する、アイデア、思想、哲学、世界観、パラダイムというものをまったくリスペクトしていない、まったく気に留めない、少なくとも、その解説では重視するどころか、ご丁寧にも、

関数型言語は哲学や宗教と関係がありますか?
ありません。いやひょっとしたらいつか何らかの関係が見出されるかもしれませんが、これまでのところ、まっとうな言説は寡聞にして知りません。
参考リンク:ソーカル事件
(詳しい方へ:ライプニッツのモナドが…とか、カリーハワード対応する数理論理学の起源は哲学だから…とかは、ここでは「関係がある」に含めません。哲学科出身の計算機科学研究者の先生方もいらっしゃいますが、一部で見られるようなトンデモ議論は伺ったことがありません。

とまで書いておられます。
まず、これは学問の素養として説明しておかなければなりませんが、
古来から、哲学と宗教の境目はありませんでした。それは現代においてもそうです。
ガリレオ・ガリレイの時代に、
哲学の一部は自然科学となり、
哲学の一部は宗教となり、実際に自然科学者であるガリレオ・ガリレイが宗教により有罪とされた、と反目することになっていくのですが、本来は、哲学と宗教は同じものです。
特に、我が国日本においては、宗教といえば胡散臭い、と思う人が多いのですが、
もともと仏教が大陸から伝来した聖徳太子の時代では、それは進んだ文明の学問として伝来しました。
聖徳太子はインテリという「逸話」「伝説」が有名ですが、
土着宗教である神道と戦争してまでも、聖徳太子と蘇我馬子が仏教を広めたのは、それが学問であったからです。
http://www.shoto9taishi.com/buddhism/
など、今適当に検索してみましたが、他の豊富なWeb記事からも、
以上の説明が結構な「基礎知識」であることは、誰でも追認可能でしょう。

哲学の素養がある方の本書の書評を引用したこともありますが、

私の知識的背景としては、本書で素材とされる言語JavaScriptに相当長期間の馴染みがあり、
西洋哲学史や宗教哲学にある程度の素養を持ちます。また言語やシステムを創案する立場に
共感しやすく、そうした設計の背景となる哲学や思想を聞くのが好きな傾向にあります。
逆に、関数型プログラミング自体には何も予備知識がなく、本書で初めて触れた状態です。
プログラミングを哲学の投影のように扱い、背景思想を語ることに、多くの方が批判的な
ようですが、逆に、私はその点を、この著作最大の美点として推します。類書はたしかに
これまで存在せず、異色の試みですが、私はこういうスタイル・切り口の著作があれば、
他の著者や言語の本であっても喜んで読むでしょう。
哲学は歴史的に見て、あらゆる学問の源泉・母体となった学問ですが、現在においても、
その中核にあって、しかも内部の各分野が緊密に連携しています。プログラミングに
関係する論理学や数理哲学だけでなく、言語哲学・科学哲学周辺まで背景知識として
持つことが、言語設計の理解の助けになるだけでなく、面白いことだと私は思います。

オブジェクト指向の誕生経緯についても本書で解説していますが、
それはアラン・ケイをはじめとするソフトウェア開発の先駆者による哲学です。
偉大なソフトウェア開発の背景には
「UNIX哲学」
https://www.google.co.jp/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8&client=ubuntu#q=UNIX%E5%93%B2%E5%AD%A6
でもなんでもそうですが、哲学が存在します。

関数型言語は哲学や宗教と関係がありますか?
ありません
まっとうな言説は寡聞にして知りません。
一部で見られるようなトンデモ議論は伺ったことがありません。

などとまで言い切るのは、「無知」によるものである、と断言できます。
いい加減に取り返しのつかないことになる前に軌道修正されたほうが良いと思います。

ちなみに「ソーカル事件」というのは、
Wikiepediaでもどこでも書いているとおり、

数学・科学用語を権威付けとしてでたらめに使用した人文評論家を批判するために、同じように、科学用語と数式をちりばめた無意味な内容の疑似哲学論文を作成し、これを著名な評論誌に送ったところ、雑誌の編集者のチェックを経て掲載されたできごとを指す。

という「権威主義」への批判のための社会実験でした。
まさに、この解説者のように、本当の背景思想を解説せず、言葉を、権威を持ってでしか物事の解説の土台としない作法を批判した事件です。反論になっているどころか、ご自身の解説の仕方にそっくり当てはまるような事件であり、同時にまた「ソーカル事件」という意味、背景というのを理解もせず「権威主義的解説」として乱用しているのか?とただただ残念です。

私はこの指摘をこれまで何度かしており、彼はいい加減に訂正撤回すればいいのに、と思っているわけですが、ずっと掲示し続けています。
私はトンデモ議論をしているのではありません。この侮辱的言及も撤回していただきたいと思います。
私にあてつけとして掲示し続けたいだけで、読者に正しい知識を与える、という本文はもうどうでも良いのでしょう。間違っていることがわかったら訂正する、それ以上間違った知識を学習者に拡散しない、それが学者の学徒の、言論人のあり方ではないでしょうか?

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

なぜこれを書いているか

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

という記事がMay 09, 2015、QiitaにUpされました。

この本については、邪な連中が多く、私もずいぶん不愉快かつ理不尽な思いをしてきましたので、この文責を伴わない「捨てアカウント」のレビュアが表明する前提の真実性を性善説をもってナイーブに信用することも当然難しいです。Qiitaにおいて、こういうことはこれまで何度も繰り返されてきました。特にこの記事に引用されている @camloeba というこの辺の輩のTweetをわざわざひっぱってきているあたり、ああまたやっているのか、と思わないこともありません。

実際、このレビューが着目する論旨は、私が、直近の記事、
『関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間 』の著者として、『数学ガール』の著者である結城 浩氏に申し上げます。本書のたいせつな潜在的読者の読書機会を奪わないでください。

の冒頭の章で、(嘘を書いているのでない限り)Amazonレビューで嘘を書かないこと、それが技術的議論のための最低限の要件であると批判した、レビューの着目点と同一です。
たとえば、Amazonレビューの

タダでも読む必要のない(というより読むべきではない)書籍
本書の技術的内容は質的にも量的にもその7割が「0から9までの数をすべて足すコードを書け」ということに尽きています。

とりもなおさず関数型プログラミングの説明を本書のようにJavaScriptでしようとすることが最初から不適切な選択であることを示しています。

と、この記事の、

「0〜9までの数をすべて足すコードを書け」について
このテーマはDay3の終わりまでほぼ200ページ(つまり本書の半分)を占めています。
素人としては深入りを避けたいと思いますが、そうだとすればそもそもJavaScript選んじゃったのが関数プログラミングへの無理解を象徴的に示すものなのだということになるような気がします。)

とか、まったく同じことを書いています。

@camloebaのごくごく最近のツイートを全面的に援用して、

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

などと、「大学生の教育用に検討した本の書評」ではなく「筆者の選択眼と、無理解」をいきなり批判するあたり、ああまたか、という印象を後押しします。

今後Day2、Day3のレビューもされるそうですから、この着目点の類似性、同一性は今後さらに明らかになってくるでしょうし、この記事を書いている人の背景説明の真実性もより検証しやすくなるとは思います。

しかし、本当である可能性ももちろんあり、そうであるならば、プログラミング教育の対象として本書に関心を持ちながら購入いただいたことに感謝いたします。このように、性善説により感謝するという行為自体もしがたい状況、実際にそう感謝すれば、嘲笑を伴う裏切り行為が繰り返されたことを許しがたく思います。

この人物の背景説明を信用するにしても、しないにしても、以下、事実のみを著者として論評します。
いちいち反応するな、という意見もあるでしょうが、著者自身による記録として有用であるはずです。
この人物が書いているように、

否定的評価にせよその理由を記録しておくことは、一定の社会的効用を有しうるのではないかと思ってこれを書いています

という同じレベルの話です。
その否定的評価にせよ理由が間違っている、もしくはそのような誤解を招いたことの説明は著者として可能であるからです。

もちろん、先入観のない読者の誤解を招いたのであれば、そえは、書き手の責任であるのは言うまでもありません。

Amazonレビューで同じ論旨のものを見た「前回」よりも、あからさまな「嘘」は書いていないことは、まずまず評価できます。

Day1については無料公開しているのだから、リンクを貼れば良いと思う

このレビュー記事は現行、本書Day1のみですが、ほんとうによくわからないのは、当ブログで無料公開していることはご存知でしょうから、まずは閲覧者の知性と感性を尊重して、信用して、現物を見せれば良いのに、と思います。
Day1はたいして長い章ではありません。

なんでこういうことを書くかというと、

続くかどうか

本書で最もreadableなDay1ですら、改めて読み返したところひどく疲れてしまいました。Day2について、すぐに続きを書くことは難しいでしょう。

と「主観」をもってこのDay1レビューは締められているわけですが、他の否定的レビューもそうなのですが、それは本当に、あなたは潜在的読者のためになる、この人物も言うように、

否定的評価にせよその理由を記録しておくことは、一定の社会的効用を有しうるのではないかと思ってこれを書いています

と思って書いているのか?と疑義があるからです。

最終的に「何かを得られるか」「役に立ったか」そうではないか、というのは読者自身が決めることです。レビュアの主観ではありません。

あなたは、残念ながらひどく疲れてしまったのかもしれないが、本書Day1は公開後、SNSでは、関数型プログラミングの魅力に初めて触れられた、本が出たら買う、と価値を認められた読者が非常に多かった、それ故に、出版社でも企画がすんなり通ったという実績があります。

実際にその試みは現在よりもまだずいぶんマシな状況であった、Day1をはじめて公開した直後のSNSの反応では成功しており、それは今現在も公開されているのだから、それを読んだ後、はたして関数型プログラミングの概要と魅力がつかめるか、つかめないかは、読者が一読した判断です。

こんなレビューはまったく必要もない、ってことになります。

Day1の存在意義

Day1は、フックです。

まとめ
Day1に出てくる「問題の論理」「論理操作」「論理構造」といったキーターム(らしきもの)の内実はさっぱりわかりません。特にどれも「論理」という語を含んでいる辺りが問題で、いったいこの3つに何か共通する要素としての「論理」なる何事かがあるのでしょうか?

そのような「論理」なるものの説明が与えられないままに、「問題の論理」「論理操作」「論理構造」といった表現を並べられても、関数プログラミングを関数プログラミングよりも不明瞭な何事かで説明しようという無益な試みになるしかない、というのがDay1についての率直な感想です。

「論理」についてもDay2で説明します。

これも、例のAmazonレビューでは

本書の過半を占める、その意味が定義されたり説明されることの決してない著者の独自の「論理」や「計算」という語の用法とそれに基づいた大量の思弁は、おそらく殆どの読者にとって(技術的意義はもとより)そもそも意味をなさないナンセンスですし、

と異口同音にこっぴどく否定されているわけですが、Day2でちゃんと説明しています。

別のところでも批判的に論じている、今後数日以内にUPする予定の記事でも書くのですが、読者が一番知りたいのは、
WHATではありません。
言葉の定義がはっきりしないと抵抗があって読み進められない、と感じる読者はむしろ少数派であり、
大多数の入門者が求めるのは、
WHY Functional Programmingです。

Day1で、WHATは書かないという判断の結果は、読者が無料公開記事を読んでわかるか、わからないか、で是非が問われることです。

[0,1,2,…,9]はダサいか?

何度も繰り返されるコード例[0,1,2,3,4,5,6,7,8,9].reduce(plus)のダサさは本書にとって本質的なものではありません。

「ダサさは本書にとって本質的なものではない」
のではなくて、
Day1では、Day2で導入するrange関数へ据え置きながら、
段階をわけて書いたにすぎません。

「ダサさは本書にとって本質的なものではない」
という物言いには悪意が見えます。

ただ、容易に予想できる反応でもあるので、最初に「配列として与えられたデータ[13, 5, -6, 34, 9, -17, 8, 21, 7]の和を求めるコードを書け」というような例にしておけばよかったのに、とは思います。

当然の疑問が生じ、当然の疑問について取り組む。
「容易に予想できる反応」があるということは、
それだけすべての読者が、内容に追随できている、ということに他なりません。

いつも言うのですが、誰に何のために説明しているのですか?

読者の容易に予想出来る反応によって、著者が「バカにされないため」に、わざわざ先回りして、別の例題にして、誰の得になるんでしょうか?

フロー(チャート)に対する批判

これは命令型に慣れた人からは不適切な藁人形論法に見えるでしょう。

だから、誰に何のために説明しているのですか?
「命令型に慣れた人からは不適切な藁人形論法」と、論戦をはっているわけではありません。

そのフローチャートを見てそれが0〜9までの数を足せ、という問題の正しい解になっていることを確信できる人間は殆どいない、という主張がなされています(p. 9)。そのことに異論はありません。

異論がない、解説としての機能が満たされている、ということです。
宣言型の対比こそが「第一義」であって、「命令型に慣れた人からは不適切な藁人形論法」とかどうでもいいわけです。

(あと、そもそもの問題としてJavaScriptで「フローは不要」なんて不可能事そのものなんではという疑問はさておき。5)
もっとも単純な例を挙げれば、JavaScriptでコードを並べる順番や位置を迂闊に変えるとマズいことが色々と起きますよね(たとえば前方参照だのシャドウイングだの)。そしてそれはJavaScriptが実行される際の制御フローそのものから生じている問題です。 ↩

これについては、Day3で、
もしJavaScriptが遅延評価言語であったならば(意訳)という節でしっかりと説明しています。
この疑問が出るってことは、そこまできちんと読んでいない証拠です。

「問題の論理」?

p. 12で初出のこの「問題の論理」というタームはその後に繰り返し出てきます。が、その意味するところは良くわかりません。既出の関数型コードは「単純に問題の論理そのものをコードへまる写しているだけ」&「そしてそれがクールなコードを書く唯一の方法だ」ということなのですが、それは「0〜9までの数をすべて足せ」という要求をそのままコードで表現すればいいのだ(そこにはループや途中の計算結果の受け渡しなんか出てこない)&そうしたコードのみがクールなんだ、ということのようです。

繰り返しますが、このDay1フックが語るところは、出版前の「わかりやすい」というフィードバックより、おそらくほとんどの読者には伝わっていると観察します。

フックの部分で、WHYの部分で、言葉の定義の意味がわからない、WHATに延々という論者の批判については、こちらこそ疑義があり、ここは改善余地がある、とは同意しません。

しかし、たとえば「与えられた配列sをソートせよ」という問題を与えられたらどうするんでしょうか。

それは別の、次の話です。
概要、フックで、WHYで、
すべての詳細要素を網羅するのは原理的に不可能です。

逆に、すべての詳細要素を網羅するのは、
概要でもフックでもWHYでもありません。

とすると、「神の目」はどうやら役立たずだということになるでしょう。

ずいぶんこの記事を読み進めてきましたが、もうだいたい感じがつかめてきました。
概要部分で、詳細が網羅されない、WHYの部分でWHATがないとないものねだりをする、原理的に両立しない要素をもって、辛辣なものいいで全否定をしたいだけですね。

「大学生への教育目的で教材として検討している人間」の関心ある評価の仕方ではありません。

このレビュー記事の前提、

私は社会科学分野を専門にしていますが、教育的理由を含む様々な理由から学部1年生から2年生向けの基礎教育で関数プログラミングの基礎を教えることを考えています(計算機科学の専門家ではありませんからできることは限られていますが)。私自身の能力的限界から使用する言語はHasekllかOCamlになると思いますが、そもそもの関数プログラミングについて1年生に教える際に適切な教材に関心を持っています。つい最近(2015年4月)刊行された岡部健『関数型プログラミングに目覚めた! IQ145の女子高生の先輩から受けた特訓5日間』も、そうした関心を以って購読しました。

というのも、おそらく虚偽です。

なぜこれを書いているか

しかし、否定的評価にせよその理由を記録しておくことは、一定の社会的効用を有しうるのではないかと思ってこれを書いています。

というのも嘘でしょう。

直近の記事で、自分のレビューがまた参照されたものだから、「嘘」でない形でまた仕返ししたかったというところでしょう。

「関数という論理操作」?

「炊飯器(米と水) = 炊きたてのご飯」という関係が「論理操作の関係」なんだそうです。「関数というものは作用して変化させる、という論理操作」なんだとか (p. 19)。正直なところ私はもう既について行きかねているのですが7、しかし、重大な問題がここには潜んでいるように思います。
まず、炊飯器が米と水をご飯に変化させるのは「因果的作用」です。更に、米と水に炊飯器を因果的に作用させると、米と水はご飯に変化し、もとの米と水はなくなってしまいます。他に例として挙げられているのが家の改造(Before After)であるところからして、著者のいう「作用して変化させる」が因果的な作用による物理的変化のそれであるということは一貫しており、そこでは、outputが得られた時にはinputは消滅しています。
しかしながら、ということは、これが関数プログラミングでいう「関数」に対応するものではないことは明らかです。x = 1; y = foo(x);はxにfooを作用させてoutputであるyを得ていますが、xはfooによってもちろん消滅したり変化したりはしません(もし変化してしまうならばそのfooは副作用を持っており、関数プログラミングが基本的構成要素とするところの意味での「関数」にはなりません)。
このことは、著者の「関数」のイメージが、関数プログラミングでの「関数」と食い違っていることを示しています。関数プログラミングでいう「関数」は数学的意味での関数、つまり、「写像 f:A→B」であって、あくまでも始域 A の元と終域 B の元との 対応関係 のことであり、そこには(始域の元が終域の元に「なる」というような)「変化」などというものはありません。

..

関数プログラミングでいう「関数」は数学的意味での関数、つまり、「写像 f:A→B」

そのとおりです。
本書は、数学的意味での関数について説明してます。
http://en.wikipedia.org/wiki/Function_(mathematics)

http://upload.wikimedia.org/wikipedia/commons/thumb/3/3b/Function_machine2.svg/330px-Function_machine2.svg.png

という、図にしても、Function_(mathematics)という極めて一般的な英語版(日本語版)Wikipediaの数学的な関数の概念図をそのまま踏襲しています。

上記概念図、あるいは、INPUT、OUTPUT、関数の入力出力という言葉自体が
時間の概念を感じさせるもので、実際に私はBeforeAfterと書いています。

これは、数学の論理として、正確なものいいではないのは百も承知です。

著者の「関数」のイメージが、関数プログラミングでの「関数」と食い違っていることを示しています

事実と異なります。
英語版(日本語版)Wikipedia
http://en.wikipedia.org/wiki/Function_(mathematics)
の数学的な関数の概念図による説明が、イメージが、食い違っている、
と批判するのは「可能」でしょう。
この図も「変化」を感じさせます。

しかし、こんな「揚げ足取り」をしていたらキリがないんですね。
我々は物理世界の住人であり、我々の理解はそもそも抽象的な世界を土台としません。
抽象的概念を理解するには、まず時間が流れる物理世界のアナロジーとしてはじめるしか方法はないんですよ。

概説するところに、そういう理解の一連の作業がすでに終わっているもの(たとば貴方や同類)
が、いやその説明の仕方は正確ではない、と指摘するのは極めて愚かです。

概念導入説明について、概念導入後の読者の脳内時間を超越した揚げ足取りの文句を並べているだけです。

xにfooを作用させてoutputであるyを得ていますが

「作用させて」
「得ている」
これは【動詞】です。対応関係は対応関係であって、
作用、得るという【動詞】、つまり人間という主体が介入する余地はありません。
作用も、得るも何もないのです。ただの関係なのだから。
数学の世界には時間の流れなど存在しないので、本来【動詞】が介入する余地など一ミリもないのですが、こういう言葉遣いをするしか方法はないですよね?
「作用させて」
「得ている」
こういう言葉遣いをするあなたも厳密にいえば、
あなたの「関数」のイメージが、関数プログラミングでの「関数」と食い違っていることを示しています。

いや!その「作用」も「得る」も時間の流れ、時間の前後の話ではなくて、
論理的な話なんだ!

そうですね。ならば、

http://upload.wikimedia.org/wikipedia/commons/thumb/3/3b/Function_machine2.svg/330px-Function_machine2.svg.png

本書も引用しているこのWikipediaの関数(数学)の概念図にしたって同じことです。

INPUTもOUTPUTも時間の前後の話ではないので、
別にINPUTが消えてなくなることはない。

「炊飯器(米と水) = 炊きたてのご飯」

にしても同じこと。

それは論理的な関係としてある。時間を超越して、きちんと双方存在する。

「因果的な作用」ってなんですか?

「因果」をいったいどういう意味で使っていますか?

「因果的な作用」と「物理的作用」の双方の言葉の関係はどうなっていますか?

「因果的な作用による物理的変化」、って一体どういうことですか?
「因果的な作用【によらない】物理的変化」、なんてものはこの世に存在するんですか?
そんなものは存在しない。

「物理的変化」とはひとつの例外もなく、すべて、
「因果的な作用」によるものです。

なんで、こういう不注意な言葉遣いをするのですか?
それはあなたが、その辺りをきちんと考えたこともないからです。

「炊飯器(米と水) = 炊きたてのご飯」

これは因果として正しい。これは時間の流れを超越した、因果として正しい表現です。

米と水に炊飯器を因果的に作用させると、米と水はご飯に変化し、もとの米と水はなくなってしまいます

間違いです。

「因果的に作用させると」っていう言葉遣いについて、この人自身、その意味を理解しているとはとても思えませんが、とにかく、とりあえず間違いです。

因果とは?

もとは仏教用語です。知っている人も多いと思いますが。

仏教とはもちろん宗教であり、宗教とは哲学です。とくに仏教は哲学です。
だから、私はさんざん哲学のことを説明しているわけですが、
この人のようにこうやって無自覚に「因果」という言葉を不用意に使う人がほとんどで、
その結果、この人のように自分でおかしなことを言っていることに気がつけない。
哲学は重要なのです。

そして、念の為ですが、フックのDay1ではそんな深淵なことを語るのは本末転倒なので、書いていません。書いているのはDay2以降です。

因果という仏教用語は、より詳しく調べると、
因果性
http://ja.wikipedia.org/wiki/%E5%9B%A0%E6%9E%9C%E6%80%A7
というWikipediaの項目があります。
英語で言うと、causalityです。
http://en.wikipedia.org/wiki/Causality

この項目をみると、「アリストテレス」やら「デカルト」やら、
まさに本書で詳しく、すくなくとも詳しく勉強してもらう導入として書いた哲学者の名前がでてきます。

現代でもっとも、定義が進んでいるのは、もちろん物理学であり、

因果律
となります。

因果律の定義は時間の定義とも密接に関係している。また、「時間」や「因果」はそれを認識する人間の主観によっても左右される。いずれにせよ、我々の感覚における「時間」に相当する性質を一部でも持つものを時間として定義し、そうして定義された時間の下で因果と因果律の概念は定義される。

これがまさに、本書の核心部分としてあります。

「時間」や「因果」はそれを認識する人間の主観によっても左右される。いずれにせよ、我々の感覚における「時間」に相当する性質を一部でも持つものを時間として定義し、そうして定義された時間の下で因果と因果律の概念は定義される。

「時間」「因果」「人間の主観」、まさに私は著書でそういうことを書いたわけですが、
「関数型プログラミングと関係ない」と理解を拒む先入観が強く固定観念に縛られている人があとをたちません。

めがねをかけるんだ
レビューポエム “関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間” を読んで

などでは、

親密さが増すにつれ、サクラさんの言動が少しずつおかしくなってきます。
アラン・ケイやスティーブ・ジョブズを引き合いに出すくらいはまだ良かったのですが、プラトンのイデアとか汎神論、精神世界と物質世界、大日如来の真言(マントラ)、果てはスピノザの神とか言い始めたときには、ほんとマジ超ヤバいと思いました。
ここまで来ると完璧に宗教の勧誘です。

と、浅い理解しかできない人が多いです。

私は、哲学の重要性の説明からはじめ、そのような浅い理解はしてはいけない、と本書で注意しながら、解説をすすめたのですが、そもそも私の話なんてまともに聞くつもりのない人は、そんな「注意」なんて気にもしません。案の定の結果です。愚かなだなあって思いますが。

よろしいですか?まさに、今あなたが「因果」なる言葉を不用意に使ったのが証拠です。
それは重要な概念なのです。関数型プログラミングの関数という超基本的な要素を理解するにあたっても。
そうやって、それなりに知的なツッコミを入れようとすればするほど、そのへんが露呈してくる。
そして、自身のいい加減な言葉遣い、処理しないと本来先には進めない重要な根底な概念を何も理解していないことに気づく。

物理学における因果律においては、

米と水に炊飯器を因果的に作用させると、米と水はご飯に変化し、もとの米と水はなくなってしまいます

というのはもちろん間違いです。

時間軸において、別の時間に
米と水
炊きたてのご飯
は両方存在します。なくなりません。

別の時間に存在する!そんなわけのわからない話をしているのではない??
じゃあ「因果的」なんて言葉を使わなければ宜しい。
でも使わないと話できないでしょ?そういうことです。
わけのわからない話こそが本質であり、そこは本来避けて通れない議論なのです。

「時間」や「因果」はそれを認識する人間の主観によっても左右される。いずれにせよ、我々の感覚における「時間」に相当する性質を一部でも持つものを時間として定義し、そうして定義された時間の下で因果と因果律の概念は定義される。

「時間」と「精神」の関係、
それにあなたが実際に、
「写像 f:A→B」数学的な関数と、
「物理的変化のそれ」
が異なると言っているように、

「精神」
「論理」
「物質」
と考えないと、「因果」なんてもんは語れるはずもないのですよ。

因果は仏教用語であり、大日如来の真言(マントラ)の話が出てきて当たり前でしょう?
そしてその仏教用語の因果と、西洋哲学のスピノザの神は、等価の話なんで、
話して当たり前でしょう?

親密さが増すにつれ、サクラさんの言動が少しずつおかしくなってきます。
アラン・ケイやスティーブ・ジョブズを引き合いに出すくらいはまだ良かったのですが、プラトンのイデアとか汎神論、精神世界と物質世界、大日如来の真言(マントラ)、果てはスピノザの神とか言い始めたときには、ほんとマジ超ヤバいと思いました。
ここまで来ると完璧に宗教の勧誘です。

私は逆に、結構懇切丁寧に、そのへん解説したつもりなんですが、それを
「超やばい」
「宗教の勧誘」

Amazonレビューでは、

本書の過半を占める、その意味が定義されたり説明されることの決してない著者の独自の「論理」や「計算」という語の用法とそれに基づいた大量の思弁は、おそらく殆どの読者にとって(技術的意義はもとより)そもそも意味をなさないナンセンスですし、たとえばp.238以降展開されるような哲学者や自由意志論への言及は単純に思想史上の問題としても誤解に基づいたものに過ぎません(そのついでにアラン・ケイやガリレオやデカルトを気取られたりするとどういう顔をして読めばいいのかもわかりませんが)。

あるいは、

著者本人ですら、自らの書こうとしている内容を理解していないのでしょう。
蒙昧主義的で曖昧な言葉で不理解を誤魔化そうとするため、結果としてとても他人が読める文章にはなっていません。
このため、間違いを指摘しようにもこの駄文を理解するのが面倒で、まともな人なら黙殺するということになります。
何も知らない初心者や、自分に理解できないものを有り難がる愚かな人が、煙に巻かれて本書の内容を信じないことを祈ります。
こんなオカルトが出版まで至ってしまったとは、編集者や出版社の罪は深いなと思います。

オカルトだの、書いていますが、
とりあえず、そういう人たちは今後も「因果」なる言葉を、説明的に使用する資格などないのだし、
自分で自分が使っている言葉のことを何も理解していないという自覚と謙虚さがほしいところです。

ソクラテスの「無知の知」で注意申し上げたのですがね。
先入観が強いって、知的に罪であると痛感する次第です。

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

関数型プログラミングの要素「集合」の概念導入をしたにすぎません。

またこの人物は、概念導入説明について、概念導入後の読者の脳内時間を超越した揚げ足取りの文句を並べているだけです。

知らない人に、ある考えを提示することと、
すでに知っている人に、詳細知識を共有することは、
まるで方法論が異なるのですよ。

WHAT WHATで羅列するのが読みたいのであれば、関数型プログラミング用語集でも自分で書けば良い。

こんな、また同じようQiitaでステアカウントをこさえて、手の混んだ嘘設定までして、本書を毀損することに労力を費やすよりかは、よほど世のため人のためとなるでしょう。
今後同じことを繰り返してもすぐバレると理解してください。
しょうもないことを繰り返すのはいい加減にしたらどうか?

案の定、この章も、

みたいな関数プログラミングのイディオムみたいなものも曰く「ダサい」コードとなってしまうのであって、およそ関数プログラミングをどうやって遂行したものか途方に暮れるしかありません。

と辛辣な煽り文句で終わっています。要するににこれがしたいだけだろうと。

続くかどうか

どうぞご自由に。しかし、Day2、Day3の批判ネタは、どうせ、
Amazonレビューで嘘を書かないこと、それが技術的議論のための最低限の要件であるで「嘘」だと言われたAmazonレビューの内容の焼き直しでしょう。

何度も何度もQiitaの捨てアカウントこさえて、こんなくだらない事を繰り返している労力があるのならば、本当に自分で気に入る「OCaml」本を書けば良いと思いますし、少なくともWHAT WHATの気に入る記事書けば良いと思う。

関数型プログラミング用語集で、命令型、オブジェクト指向とのパラダイムの違いが体感できる読者入るとは思えないし、感動する人も居ないと思います。初心者の方々には間違いなく役立たないし、本書が提供している価値も創出できないとは思いますが。

2015年5月8日金曜日

『関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間 』の著者として、『数学ガール』の著者である結城 浩氏に申し上げます。本書のたいせつな潜在的読者の読書機会を奪わないでください。

『数学ガール』の著者である結城 浩氏に申し上げます。

関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間』の著者として、『数学ガール』の著者である結城 浩氏に申し上げます。

私は、『数学ガール』を拝読したこともございませんし、貴殿のことも良く存じ上げません。そして貴殿による一方的なTwitterをはじめとする言動に甚だ迷惑しております。

責任ある執筆者、言論人として、書評行為はご自由になさってください。
そして、その場合は責任ある執筆者、言論人として最低水準の矜持、作法を期待します。
書評行為は、対象書籍を読了のもと、書籍名、著者名を明示して、きちんと行ってください。今更私がここで言うまでもない至極当たり前のことです。

本書は、IQなんとかの本、ではありません。
『関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間 』という書籍名です。もちろん、長いタイトルですが、少なくとも、「岡部」という著者名を出されて特定的に言及するのであれば、IQなんとかの本、という物言いはあまりにも無礼なのではありませんか?
もちろん、そのように書き捨てることで、ご自分は読んだこともない、と示唆、軽視していることを示威されたかったのでしょう。軽視しているわりには延々と書かれておられますが。
内容の是非が判断できない事はともかくとして、読んでもおられない。
ならば、それはまっとうな書評行為ではありえないですし、私の大切な著書と、大切な読者を足蹴にするような「無責任な論評」はされないでください。

貴方の勝手な都合で、本書のたいせつな潜在的読者の読書機会を奪わないでください。
一定の期間に渡り長々と本書を「論評」されておられますが、書評でもない、読んでも居ない、関数型プログラミングに詳しくもない、と繰り返しながらも、明らかに当方や本書を毀損する内容の言説を展開されておられますね?非常に不快ですし迷惑に感じています。
もちろん、私も執筆者の端くれであり、まっとうな「書評」なら、それがなんであれ(嘘を書いているのでない限り)、有り難く頂戴することも出来るでしょう。しかし、貴方がやっておられることは、「書評」行為では断じてありません。延々とネガティブキャンペーンに乗じて、この機に乗じようとばかりに、ご自身のブランディング、ご自分の著書の宣伝に、ただただ利用しようというか悪用されるのは、当事者であると同時に、一言論者として、貴方の言動、やり方に憤りも感じています。

なぜ今書くのか?

結城氏の言動がピークであったのは、今から一週間以上も前のことだと思います。私はもちろん知っていました。

まず第一に「ネガティブキャンペーン」を繰り広げる連中がここぞとばかりに、Twitterでリツイートしたり、そこら中で、これは利用できる、自分たちの「ネガティブキャンペーン」に著名な著者からお墨付きをもらったとばかりに、方方に貼り付けてアピールしており、良識ある読者の方々より、この現象を教えていただいたからです。

結城氏による、本書そして著者である私に対する言動は、ネットでは結構な程度をもって流布されており、この事象は当然のごとく、本書の担当編集者はじめ、出版社の方々にも認識されていました。著者の私の耳に入らないわけもありません。

最初は完全無視しようと思いました。そもそも私は結城氏のことをよく存じ上げないし、こういう一方的な行為についていちいち反応、論評するのもキリがない、と思っていたからです。

このブログにしても、技術ブログです。
冒頭に一部抜粋した技術記事を列挙していますが、このような「炎上案件」の記事にばかりアクセスが集中して、技術記事はまるで読まれていません。
時折、このブログは否定ばかりだ、という人も居ますが、そうではなく、地道な普段の技術記事についてはまったく興味を示さない人ばかりで、「炎上案件」の記事にはアクセスが集まるのです。

直近の、
React (.js Facebook)解説 関数型プログラミングに目覚めた! IQ145の女子高生の先輩から受けた特訓5日間 サポート記事 静的HTML編
そして、
React 解説【動的HTML-FRP編】
など、本書の延長の副読記事など、地道な普段の技術記事で、ほんとうに役立つものがあると自負していますが、そのような地道な作業がまっとうに評価されることはまずありません。

今後も、真摯に読んでいている読者サポート、副読記事のシリーズを企画していた矢先、またこういう人について論評を重ねることに自身それなりの抵抗がありました。結城氏の仕事が出版業界で一定の評価を得ている、人望もある、ということも見聞きしましたが、今となっては、前者はともかく、後者はもちあげられすぎではないか?と率直に思っています。

実際、本件についてメール等でやりとりしながら、何か結城氏が特別な存在のように、彼のひとことひとことをまるで「聖句」のように、解釈論争をするような持ち上げ方には、大きな疑義がありましたし、私自身はもちろん、相手のお時間もいただいて議論すること自体もどうか?と正直、疑問におもっていました。

「いくらなんでも、これはちょっとな」
「さすがに当事者として見解を示しておくべきだ」と、最終的に思ったのは、
「結城さんの影響力を考えるべきである」という意見があったこともあります。

そもそも私は相手の「影響力」によって、態度を変えたり、自分の意見を封じ込めたりすることはすべきではない、という考えで、それは実践しています。
また、本書にもしつこく書いてもおりますが、私はあらゆる「権威」の匂いがするものをリスペクトしません。
だからこそ敵を作りやすい、ということもあるのでしょうが、いくら周囲を敵に回して自分が「損」をするかもしれない、と見通せたとしても、そういうことはすべきではないと思っています。
昨今の不幸な事象が多くを語るとおり、権威主義、事なかれ主義こそが、我が国で不幸を生む大きな要因であり、私はその風潮に与したくはありません。

また、「結城さんの発言はすべて、岡部さんの味方であることを表現しており、著述者として同じ仲間であると考えているはずだ」
と、よりによって、彼の言動が私へ味方するものであり、その良識を評価する意見を確認したからです。

「いくらなんでも、これはちょっとな」そう思いました。

最初は完全無視しようと思ったのも、良識の土台となる常識的判断が平均的にくだされるだろう、私がまた表でなんか言わなくても、世間の判断は信頼できるだろう、そう思っていたからでした。
一方的に社会的評価を自身毀損しているのは彼なのだから、と楽観していたのですが、どうもそうではないようです。

背景事象

本書のDay1ドラフトをQiitaで公開したところ、一部の人から『数学ガール』のパクリだ、との中傷がありました。指摘ではなく、事実と異なる中傷です。

こういう事実と異なるネットの中傷は、良識による自律的修正が残念ながら期待ができず、それどころか延々と増幅するという非常に面倒なことになるので、私はすぐに、『数学ガール』とは企画構想段階でも執筆段階でも念頭にもなく、無関係であることを説明し、書籍の存在は存じあげているが読んだこともない、ことを説明しました。

そして、ものがたりで解説する手法は古今東西、広く用いられる手法であり、よく言えば王道、悪く言えば有りふれた手法であることを説明しました。
たとえば、説話を通じて道徳、教訓を語るような文学は広く馴染みのあるものですし、聖書なんていう世界的ベストセラー#1の書籍にしてもそうです。

『ソフィーの世界』という哲学解説書にしても、
『もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら』にしても、その他列挙したら枚挙に暇がありません。

本書はその偉大なる潮流の末席に位置する類型であることがは確かであるが、同様にその一類型である『数学ガール』のみがことさら本書の先行書籍かつオリジナルである、と考えられているのは道理が理解しかねる、ということを、以前も最近も説明しました。

そもそもの着想としては、受け入れられにくい「関数型プログラミング」の魅力とメリットが読者に伝わるように、導入前後、発想の転換が明確になるように、BeforeとAfterを対比するような手法をもって説明したい、と企画段階で著者の意向として、編集部と相談していたことからはじまります。その過程で、編集部より、本書を「ペア・プログラミング」形式で進めるのはどうか?と提案がありました。単に、BeforeとAfterの対比ではなく、開発過程で、関数型プログラミングを用いる先輩と、経験の浅い後輩がおり、そのやりとりでやると面白い、という提案です。私はこのアイデアは面白いと賛同しました。企画を出版社社内で通すために、目次の構成が必要であると打診されたこともあり、先輩後輩のやりとりをイメージしたかったので、編集部が稼働していない週末の2日ほどで、Day1の素案を書き上げました。

書き始めた当初、舞台が会社だったのですが、どうも設定に無理があると感じて試行錯誤の末に、舞台を学校の部活に勝手に変更しました。どうやったら自然に話を前に進められるのか?と最適解を探しているうちに、それは自律的に立ち上がってきたのです。舞台の変更については、週明けに担当編集者に見せて事後承諾もらえば良いと考え、書き上げました。

学園モノは、常にライトノベルやTV/映画、コミックで安定の人気の舞台設定です。
国内文学では、古くは樋口一葉の『たけくらべ』から、筒井康隆『時をかける少女』、眉村卓『ねらわれた学園』など、いろいろありますし、ラノベの多くが学園ものであるのは、この流れを汲んでいます。TV/映画では、『ビバリーヒルズ高校白書』『ハリー・ポッター』、コミックでは『デスノート』『スラムダンク』とにかく、国内外メガヒット級の舞台の多くが学校、学園であるというのは、いまさら私が列挙するまでもなくわかることでしょう。
創作者にとっては舞台装置を選定する際、安全牌のパターンであるとも言えます。

本書が誕生した経緯として、以上のような偉大なる潮流があり、本書はそのひとつの類型であると言えます。最初からそこを意図していたわけではありませんが学園設定が最適解であったのは、それなりの道理があり、自然とそこに落ち着きました。

こういう本が出てきたら、『数学ガール』のパクリだと言われるのは、その筋では確かに著名なのかもしれないが、創作活動というものを非常に矮小化していると感じました。俯瞰してみると、『数学ガール』にしても、この潮流の一端に存在しているに過ぎません。

ここで、私による事実の説明として、『数学ガール』という書籍について、というより、その著者の結城氏にとって、あまり愉快でない要素がある、と「想像はでき」ます。

1.『数学ガール』を私は読んだことがない、
2.『数学ガール』は何らこの分野においてオリジナルであるというわけではない

もちろん「パクリ」というのは、以上の2つの事実関係をまったく無視して、決めつける言いがかりですから、私としては事実は事実であると、明示したにすぎません。単に言いがかりの上、今後ほうっておいたらまたかなり面倒なデマとして、嘘を100回書けば事実になる、という事象を、たいせつな書籍の著者として事実関係を明確にしながら風評被害を予防したにすぎません。とても面倒なことですが、実際にこれまで、嘘を100回書かれて事実だと思っていることはたくさんありますから。

私は事実関係のみを淡々と書きました。

話を聞くところによると「立派な人」らしいので、『数学ガール』にしても、偉大な、「ものがたり+解説」「学園モノ」の潮流の一端に過ぎないんですよ、と今後、著者ご本人から優れた知見を提示されることもあるだろう、と期待もできました。そういう期待をしたのは間違いだった、と結果的に痛感しましたが。

そして、なにより、よもやこんなくだらないこと、小さなこと、つまり、「御」著書を読んでいない、ということをもって、無視された、尊重されていない、リスペクトされていない、と気分を害して、なんか変なことをする人ではないだろう、とは勝手に想像しておりました。

もちろん、このタイミングで、私がよく存じ上げない結城氏にたいして、へりくだった形で、「たいへん評価も高いご著書ですが、勉強不足なもので、拝読しておりません、申し訳ありません」などと書いても良かったのでしょう。

しかし、偉大なる潮流を説明している場で、自身の創作活動についてパクリだの矮小化のそしりを受けた説明の場で、なんでよく知らない本について、よく知らない著者にむけて、思っても居ない、へりくだったお世辞を書く必要があるのか?そういうことはすべきではない、と考えました。

私は、意外に思う人は多いかもしれませんが、日常生活では、人を褒めることは大好きです。率直に良いと思ったことについては手放しで褒めます。それだけに、心ないお世辞は苦手です。特に今回は、先行書籍として一定の周知度を有するものを上段より振りかざされたという理不尽さも感じていましたので、その理不尽さにむしろ加担するつもりもまったくありませんでした。

私は少なくとも、『数学ガール』ときちんと書籍名を書きました。
当然のリスペクトです。
淡々と事実関係を表明にするに際しても、誰かの著作に言及する際の最低限の作法と礼節は維持しています。

IQなんとかの本、などと無礼なものいいはしておりませんし、
読んでもいない本を、わけのわからない連中と一緒になって同調し、「毛の壁」だの書いてるTweetをリツイートをして彼らを喜ばせながら、一緒になって侮辱するような真似はしていません。

結城氏の言動を知った時、私は最初にこう思いました。
「ああ、怒っちゃったんだ」と。
「こんな、しょうもないことで怒るような人なんだ」と。
「怒る、ということは、偉大なる文学の潮流の末席にいると謙虚に俯瞰して、他の作品も同等に考える人ではなく、自分が国内でこの分野を確立したと考えながら縄張り意識でもあるのだろう」と。

私は結城氏にたいして、媚を売るような真似はしませんでしたが、いかなる礼節を損じたこともないと信じています。
そして、『数学ガール』の著者である結城 浩氏による極めて一方的な行為により、非常な不快と迷惑を感じている、ということははっきり明言しておきたいと思います。

本書のたいせつな潜在的読者の読書機会を奪わないでください。

現象の検証への動機

「結城さんの発言はすべて、岡部さんの味方であることを表現しており、著述者として同じ仲間であると考えているはずだ」
という発言を受けて、
「いくらなんでも、これはちょっとな」
そう思いましたが、そういう超好意的に結城氏をもちあげるような見解のほうが実は正しくて、私がとんでもない勘違いをしている、という可能性を考慮しました。

実際、これまで私は結城氏の発言をろくに精査していませんでした。
前述のように、そもそもそんなものに時間を割いて検証するような価値があるのか?何か彼の言葉が特別な存在のように、彼のひとことひとことをまるで「聖句」のように、解釈論争をするような真似に自身加担したくなかったのです。

でも、実際、なんか妙なことが起こっているな、と観察したので、こういう手間のかかる記事を書き始めているわけです。たいせつな著書と、著書を本当に評価していただいている、たいせつな読者、そして担当編集者、出版社もひっくるめて不当な思惑によって毀損されている、とも考えておりますので、後世の記録として残します。いつも言うことですが、短期的な雰囲気に影響を受けない中長期のフェアな評価が下ると信じています。

結城氏が、ご自身の著作と読者をたいせつに思われるのと同様に、私も自身の著作と読者をたいせつに考えています。
正当な書評行為でもなんでもない、ご自身の本の宣伝のために、読んでもいない本について、著者について、その場の雰囲気に乗っかって一緒になって毀損する。結城氏にはそういうことをする道理も権利もないはずです。非常に迷惑しております。

これまでの観察より、私は結城氏の良識や行動の修正にまるで期待などしていないのですが、少なくとも多少なりとも反省されたら良いとは思っています。良いとは思いますが、期待はしていません。

後は世間が判断することでしょう。結城氏にも、著作を通じて、きっと多くの愛読者、ファンがおられることでしょう。そして私は彼らの良識を期待しています。

現象の検証

検証範囲ですが、漏れ無く検証すると分量も多いので範囲をかなりしぼって、
私と著書への具体的言及が存在する、2015年4月30日の結城氏のTwitterのタイムラインだけを本稿では検証し、論じます。

サードパーティのTwilogというTwitterログサイトから、
同日のTweetを引用します。
http://twilog.org/hyuki/date-150430

この24時間だけでも、199 tweetsもあります。かなりの量です。

今回、私が結城氏のTwitterのタイムラインを観察して、まず驚いたのは、氏がかなりの「エゴサーチャー」タイプである、ということです。
そして、ご自身や著作を褒め称えるTweetをこれはもう、おそらく、もれなくすべてRTして掲示しています。

なるほど、少なくとも、この方は世間でもちあげられているほど「おくゆかしい」「謙虚な人」ではないな、というのが私の率直な第一印象です。

こういう挙動はむしろ「マーケティングする人」の挙動であり、その意味では、私とタイプが似ています。

私の「問題の」書籍、関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間でも、明々白々ですが、私は「マーケティングする人」です。と言っても、純粋に社会実験としてのマーケティングに知的興味がある「マーケティングが好きな人」であり、同時にできれば謙虚ではありたいとは思っています。信じられないかもしれませんが。アンフェアな事象には了とせず行動するだけです。

彼は「自身を売り込むことにやっきになっている書き手」であり、
自分の「ブランディング」にご執心で、
「人気商売である自覚」を強く持っているタイプの言論者です。

TVのコメンテーター稼業の人々がおられますが、その路線です。
慎み深い言葉を「聖句」が如く、弟子や第三者が拾って解釈するような言葉を発するタイプの言論者ではありません。

それが別に悪い、って言っているのではありません。その実利的な有効性を理解し、十二分に共感もします。

今回申し上げたいのは、そういう自己顕示と本の宣伝、とご自身の商売のために、人のたいせつな著作、そして、たいせつな愛読者を踏み台にして、善人ぶるようなアンフェアな真似はしてくれるな、甚だ不快で迷惑である、ということです。

私は、一言論者として、貴方の言動、やり方に憤りを感じています。

そして、いくらなんでも世間はこういう人をちょっと持ち上げ過ぎなんじゃないか?大丈夫ですか?少々人が良すぎるんじゃないのかい?ということです。

もちろん、誰のどういう行動であっても、岡部を攻撃するに利用できればそれで良い、兵力にカウントできれば事足りると考える層は大人数存在するので、その層は論外です。この層には何を言っても通じません。連中は邪な自身のアイデンティティを正当化したいだけの損得勘定だけで動いているので。

さて、宣伝要素ですが、以下のようなツイートがちりばめられています。

結城浩@hyuki
連休の読書に「数学ガールの秘密ノート」の最新刊はいかがですか。「微分を追いかけて」この巻から読み始めても大丈夫!
http://note5.textfile.org
posted at 11:47:00

と宣伝し、その他新作の執筆活動の宣伝、の他、好意的なRTの連続です。
思慮深い、「聖句」として読みとくべき言葉、ではなく、
彼のTweetは基本、自己顕示、マーケティング、宣伝としての性格が色濃いと私はすぐに判断できました。この性向は圧倒的です。
繰り返し、念の為ですが、それが別に悪い、って言っているのではありません。私はその実利的な有効性を理解し、十二分に共感もします。

今回の本書にまつわる騒動で「結城氏自身が迷惑におもっている」との見立てとして、ご意見を頂戴もしましたが、とんでもない勘違いでしょうね。

氏は今回の騒動を
「この機に乗じて自分の存在を、さらに広く世に示し、ブランド力を高め、
著書を宣伝するたいへん良い機会だ」と思ったはずです。

私がこれまで聞かされた好意的解釈として言われるように、騒動をたしなめるのであれば、正しい道筋を示すのであれば、彼は表現者として一流ですから、そんなことは簡単にできるはずです。

実際何をやったか?「一緒になって煽った」のですよ。
「騒いでいる」連中に歩み寄り、理解を示し、自分が同じグループに属すると示しました。

炎上に自分も加担している、と示すことで、彼らにリツイートさせ、自身の露出度を高め、自分の名前を書籍を宣伝されました。こんなものはこの24時間のタイムラインに限って見てもすぐにわかることです。

でも、ブランド力を高めるためには、一応、騒動をたしなめるフリもしなければなりません。極めて巧妙にそれは成し遂げられています。それを説明します。

より具体的言及の検証

結城浩@hyuki
ほんとうに詳しい方が、正確でわかりやすい関数型プログラミング(言語)の本を書くのが、最も大きな反論です。また、業界全体にとっても入門者にとっても意味のあることだと思います。私は「あなた」にお願いしているのです。よろしくお願いいたします。
http://twitter.com/hyuki/status/593711772944629760

「ほんとうに詳しい方」が本を書くのが「最も大きな反論」
「業界全体にとっても入門者にとっても意味のあることだと思います。」

反論対象の私の本は、
「私」という
「ほんとうは詳しくない方」によって書かれているってことでしょう。

「正確でわかりやすい」ことで、「反論」として成立するのであれば、
反論対象の本書はすなわち、
「正確でもない、わかりやすくもない」
っていうことです。論理的にそうなりますよね?
そしてそのニュアンスは誰でも汲み取れるでしょう。

もちろんこのツイートには、後半部分に建設的な提案が「添えられている」のは間違いありません。
しかし、それは彼にとっての主題ではありません。一番言いたいことは最初に書いているのです。

「IQなんとかの本の反論となる本を書いてみせてください、お願いします。」
これが彼が一番言いたいことであり、
その要素の後に、

また、業界全体にとっても入門者にとっても意味のあることだと思います。

「また、」と続く副次的な要素として、「意味のあること」は添えられています。

結城氏が、「あなた」にお願いしたいのは、
IQなんとかの本の反論
であり、「意味のあること」でもあることは、おまけです。

ということで、結城は言いたいことは言った。2015年か2016年か知らないけど、関数型プログラミング(言語)の良い本が出てくるといいなあ。いいと思うよね、みなさん。私もそう思う。私の(2016年に出るはずの)『数学ガール6』との競争だなあ。どっちが早く出るかなあ(にやり)。
http://twitter.com/hyuki/status/593714560852307968

「いいなぁ」と「言いたいこと」です。
一番「言いたいこと」とは、もちろん、
「また、」と続く副次的な要素として添えられている「意味のあること」ではなく、
「IQなんとかの本の反論となる本を書いてみせてください、お願いします。」
です。

そして、基本『数学ガール6』の宣伝です(にやり)。

繰り返しますが、人の本のネガキャンに乗じて、自分の本の宣伝をするような、アンフェアな真似はしてくれるな、と思います。
ブランディング、本の宣伝は、人を不当に貶めながらやるものではない。
迷惑です。しかも、ご自分が不当で恥ずべき真似をしている自覚もないようです。ここが信じられない。

2015年か2016年か知らないけど、関数型プログラミング(言語)の良い本が出てくるといいなあ。いいと思うよね、みなさん。私もそう思う。

IQなんとかの本の反論が、彼にとって一番「言いたいこと」であることを考えると、この文意もはっきりします。

逆に「意味のあること」が副次的なおまけであることを軽視し、それが彼にとって一番「言いたいこと」と好意的な誤読をすると、それはこの文章も好意的に誤読できるでしょう。

彼がこう「憂う」私の著書が出た2015年の現時点では、まだ
「関数型プログラミング(言語)の良い本」は出ていない、

2015年か2016年か知らないけど、これから出てくるとよい、

つまり、本書は
「関数型プログラミング(言語)の良い本」ではない、
と言ってるのと同じでしょう?

いいと思うよね、みなさん。私もそう思う。

「みなさん」って一体だれだろう?
貴方は一体だれと「対話」しているのですか??

もちろん、彼自身のツイートを大注目している、大騒ぎしている連中、
リツイートしてくれている、ネガキャンしてる連中のことですよね?

エゴサーチに熱心な方なので、そのへんの事情はすべて把握されています。
どういう文脈で自身のツイートが拡散しているのか?
どういうコメントが畳み掛けられるのか?この人は全部理解してやっています。
だからこそ、

いいと思うよね、みなさん。私もそう思う。

と「対話」しているのですね。

ネガキャンしてる連中に「みなさん」と擦り寄り、
「私もそう思う」、って同調しているではないですか。

これはたしなめているのでしょうかね?
同調してネチネチDisって、最後は自分の本を宣伝する。

読んでもいない本にあてつけて、良い本だのなんだの対比的に論じ、
「みなさん」と「そうだそうだ」と囃し立てて、
最終的には自分の本を宣伝する。

そういう最悪な書き方です。まともな論者の作法ではありません。

しかも、好意的に捉えようとすれば、
「結城氏は岡部の味方をしている」
と実際好意的に勘違いする人も出るような書き方です。
単に、人を踏み台にしながらの宣伝活動なのに。
ろくでもないと思います、ほんとうに。

以下、蛇足。
岡部さんの本へのアンチテーゼとして書くべきではない(と私は思う)。そうではなくて、《読者のことを考える》という原則で、「あなた」の読者さんに向けて、関数型プログラミング(言語)の良い本を読みたいと願う読者さんに向けて、書くべきである(と私は思う)。
以上、蛇足。
http://twitter.com/hyuki/status/593716486914478080

直後のこのツイートによって、完全に一連の言及が個別具体的に私、岡部と私の著書へのあてつけであることが明示されています。

「岡部さんの本へのアンチテーゼ」っていうものを、著者として是非見てみたい、それは面白いことになる、何故ならば私の著書の内容は正しいから、と思うわけですが、それはともかく、この人は、
「岡部さんの本へのアンチテーゼ」っていうのを念頭にもおきながら、書いていたわけです。

その上で、まるでその前提を共有するような勢力に阿り、同調していたくせに、それをたしなめるような態度を示している。根底は、もちろん人を踏み台にする自己顕示とご自分の著書の宣伝活動なわけですが。

本当に、読んでいて、「偽善だな」と思うわけですね。
背中に結城氏の土足があたっているものとしては。

その直後に続く彼のタイムラインのRT

ちゅーん@its_out_of_tune
こう考えると、数学ガールを書いてる結城先生ってその辺のスキルがすごい高いんだけど、その人に「毛の壁いじりはもういいから、はよ正しい入門文章書けよ」と言われれば「あ、はい。」としか言いようがないジレンマみたいのはあるよね(´・ω・`)言い訳してないで書けっつぅ話なんだが。
Retweeted by 結城浩
retweeted at 19:02:19

ちゅーん@its_out_of_tune、よく見ますね。
ネチネチずっと、粘着して当方に「毛の壁いじり」などと、
愉快犯的動機を露骨に表明しながら、私を誹謗中傷し続けているメンバーです。

結城氏は、こんな人のTweetをリツイートしている。
そりゃ、大騒ぎしている連中、リツイートしてくれている、ネガキャンしてる連中に、

いいと思うよね、みなさん。私もそう思う。

と阿りながら、なかよく「対話」していたら、こういう、
ろくでもない人間からの「お返事」も来るわけです。
もちろん、結城氏はエゴサーチャー的に、状況を逐一漏らさず把握していますから、こうやって「お返事」も漏らさず掲示するわけです。
「毛の壁」と、私が兵庫県警に刑事告訴までした案件の侮辱呼称でも、なんでもお構いなしです。

数学ガールを書いてる結城先生ってその辺のスキルがすごい高い

って自分のブランド力を高めて、自分が「得」をすれば、
私が当然不快に思うだろう「毛の壁いじり」だとの罵倒、
もちろん、これはエゴサーチャーとしての結城氏が状況を知らないわけもないわけですが、そういう他者の「損」なんかどうでも良いのでしょう。

自分のブランドを高めるための「得」 >> 踏み台に利用する相手の「損」

という構図がここでもわかりやすいです。
ほんとうにろくでもないと思います。

「まるでその前提を共有するような勢力に阿り、同調していたくせに、それをたしなめるような態度を示している」
という偽善的文書にまんまと騙された著名ネガキャン者、
知らないわけでもないでしょう。
「毛の壁いじり」だとか、RTして「追認してやる」ことで、
連中どれだけ喜んでいるか?
うまいこと、騙せてよかったですね、ということです。

これが、騒いでいるものたちをたしなめる態度ですか?
その直後には、

@MasutaniHCU
数学ガール6鋭意執筆中らしい
Retweeted by 結城浩
retweeted at 19:02:24

20分も立たないうちに、宣伝に利用できる次のTweetを見つけられました。
宣伝に余念がありません。

繰り返します。宣伝するのは結構。あなたがマーケターであるのも結構。
何も悪いことはない。
ただし、人を毀損する活動に乗じて、それを展開するような真似をしてくれるな、甚だ迷惑である、ということだけです。

Eijiro Sumii ‏@esumii 4月30日
@hyuki (私も含め皆さんが何度も言っていてすみませんが)http://www.amazon.co.jp/dp/4781911609 じゃだめですか?

結城浩@hyuki
@esumii いや、私にそう言われましても…この本は、岡部さんをdisる人たちが、IQなんとかの本の代わりに推薦なさる本なのかしら。それならばそれで、まったく(私は)異論ありません。私は単に「本のdisり」より「本のオススメ」のツイートやブログ記事を見たいだけなんです…
https://twitter.com/hyuki/status/593756035547926529

これまでの論証で明らかですが、結城さん、あなたも十二分に岡部をDisっている。人の本を踏み台にして宣伝活動に余念のない人が、自分は違う、

私は単に「本のdisり」より「本のオススメ」のツイートやブログ記事を見たいだけなんです

とか、偽善ですね。

「IQなんとかの本」。まっとうな論者の作法ではないです。
なぜ、読んでもない本を腐す連中に加担しているのですか?
連中が腐しているから?
正当な議論はどこにあるのですか?
@esumiiさんが、以前から私の主張を有害だとかトンデモだとか、そう言っているから?
というか、またOCamlのオススメ本ですか。OCaml好きですね。

こうやって仲良くやってる、対抗勢力が、なんか、あまり一般読者の需要が強くなさそうな言語の別の本を薦めたり、相変わらず権威主義で、お茶を濁すばかりで、
まるで、本書の解説や主張に間違いがあるかのごとき印象操作はするが、何一つ、反論できていないことについて、言論者として問いただしたらどうか?と思うわけです。

たしなめる風である巧妙な思惑、そして宣伝活動も成功されているわけですが、「IQなんとかの本」とか、読んでもいないのに、Disられている風潮だけで、なんか論じている、関数型プログラミングはわからないと繰り返し、読んでも居ないのに、なんとなーくDisっている自分たちの味方だ!と思わせることには成功し、同時に、大人のたしなめという建設的提言もしているように見せかけることにも成功している、ご自身と著書の宣伝活動、ブランディングには成功されているようです。

あなたの勝手な都合で、本書のたいせつな潜在的読者の読書機会を奪わないでください。

なんでしょう。この百戦錬磨の老獪な政治家が、
「いやいや、私は中立なのですよ、私はむしろたしなめているわけです。」
というような偽善をこうも堂々と目の前に展開されているのを目撃する気持ちは。
なんでしょう、ではなくて、まさにそういうことなのですが。

考えてみると、結城は関数型プログラミング(言語)に詳しくもなんともないのに、なぜこんなにあーだこーだ言ってるんだろう。たぶん、「本を書く」とか「本を出す」あたりに反応してるのかな。disる、disられる、とかね。一周りしてみると、やはり最初のツイートに思いは集約されてるかも。
posted at 22:06:59
http://twitter.com/hyuki/status/593763479632285697

さすがに「詳しくもなんともないのに、なぜこんなにあーだこーだ言ってるんだろう」と自省されはじめたようです。

なぜこんなにあーだこーだ言ってるんだろう。

機会に乗じて、ご自身のブランディングと著書の宣伝のためでしょう。

たぶん、「本を書く」とか「本を出す」あたりに反応してるのかな。

そのとおり。「自分のほうが先にものがたり風の解説本をやった」という縄張り意識からでしょう。
『数学ガール』も、大いなる潮流のひとつにすぎない、オリジナルではない、と私が言及したこと、
個別の数学ガールシリーズとしての本は、読んでは居ない、パクリではない、と「リスペクト」しなかった、無視してしまった、憤りからでしょう。
意趣返しの「IQなんとかの本」という物言いに集約されています。
「小さいな」って思います。
なんでこの人はもちあげられているのだろう?と率直に思います。
私は迷惑な人だな、と思っています。

少なくとも、「自分の反応」の原因について、自覚的でなく自身なんでだろう?というのは、感情的要素によるものである、ということです。
「やれやれ、酷い状況だ。こういう岡部を叩いている卑劣な連中をたしなめてやろう」
という、思慮深い考えと動機から、この一連の言及が開始されていたのでは「ない」ことがよくわかります。

人の言葉、というのは、「語るに落ちる」というものいいも存在しますが、必ず「尻尾」というものがあります。

なぜこんなにあーだこーだ言ってるんだろう。

IQなんとかの本

毛の壁いじり

不愉快なリツイートへの追認もふくめて、こういうの全部「ことばのしっぽ」です。

「それくらいのこと」と好意的に無意識に見落としてやるのが、バイアスであるということ。
ことばのしっぽ」「それくらいのこと」こそが、発言者の正直なスタンスが透けて見える手がかりであり、本当に、結城氏が「岡部の味方」で「変な連中をたしなめたい」のであれば、
こんな「ことばのしっぽ」「それくらいのこと」は出てこないのです。

本当に建設的な提案「意味のあること」が主題としてあるのならば、
「なぜこんなにあーだこーだ言ってるんだろう。」と自身の発言の意図に迷うこともないでしょう。
本当に建設的な提案「意味のあること」を訴えたいのであれば、
「IQなんとかの本」という意趣返しなどしないでしょう。

根底には感情的なものしかないから、自身の発言がコントロールされていないように思い、そのような言葉遣いをしてしまうのです。副次的に添えられた、とってつけられた「意味のあること」は、あなたが一番いいたいことではない。

今でも、このブログ記事に反応して、好意的解釈をゴリ押しすることで、結果的に、それはまた「私の間違ったおこない」を示すことにつながり、足をひっぱることが出来るという「損得勘定」で、そうしているわかりやすい連中が後をたちませんが、まずまず彼らのバイアスの効いた「読解力」なんてものは評価に値しませんし、私自身ももちろんバイアスの効いた論者ではあるでしょうが、少なくともこのように自身、相手の主張のほうが正しいのでは?自分が間違っているのでは?というところから、懐疑的に検証はします。連中は、最初からもう誰の肩をもつのか決めており、結果ありきの適当な立論をしますから、相手する価値もありません。

まさに書籍を読んでもいない人が、判断する指標とするのが書評ですが、「書評っぽい」が断じて書評でもなく、なんとなーく、

あの『数学ガール』の著者でさえ良くは言っていない

という巧妙な印象操作だけが世間に流布されていることに成功し、同時に自身は好意的な人には「むしろあれは味方しているのだ」と勘違いさせることにも成功し、対比的に自身をブランディングすることで、ご自身の本の宣伝に勤しんでおられる、結城氏です。

結城氏が

いいと思うよね、みなさん。私もそう思う。

と「対話」したり、「返信」がきたら「毛の壁いじり」という内容も含めてリツイートしながら、その言い草を承認している「相手」連中がやっていることについてかなり怒っている本書の読者もおられます。それは「テロ行為」であると。

自由な書評を封じ、読者の読書機会を暴力によって奪う「テロ行為」であるとの指摘があります

もちろん良識ある人がみれば、こういう連中による一連の行為は、読者の読書機会を暴力によって奪う「テロ行為」であると考えて当然でしょう。

そして、書評という正当な行為から逸脱し、なんとなーく、

あの『数学ガール』の著者でさえ良くは言っていない

と印象操作だけをして、本の宣伝だけをしたい結城氏は、この読者が憤られたような、当然の良識は期待できません。

「テロ行為」やっている連中は、結城氏に「みなさん」と言われて喜んでお返事したら、
「毛の壁いじり」とその愉快犯的犯行のスタンスを明示しても、
リツイートもしてくれる、承認されている状態なのですから。

氏の一連の言動がこの「テロ行為」へのお墨付きを与え助長しているのは間違いありません。
本書のたいせつな潜在的読者の読書機会を奪わないでください。

読者の方より、こんなメールをいただいております。
私のたいせつな読者の方から、いただいたこの勇気ある意見と行動に感謝します。

アマゾンのレビューについて

岡部様

こんにちは、【実名】(*伏せます)です。
昨日は、本当に丁寧にご対応下さり感謝申し上げます。
量子コンピュータにも興味がありますので、わくわくしています。
SICP の無料 PDF もありがとうございます。
(実は後で読むつもりで iPhone に取り込み済みでした(笑))

さて、さきほどアマゾンのレビューを投稿しようと思い、
手順などを調べていたのですが、色々分かってくるうちに、
なぜフェアなレビューが投稿されないのかよく理解できました。
(レビュー投稿は初めての事なので今それを認識した次第です。)

前提として、アマゾン商品購入が条件なので、捨てアカウントはできません。
そして、レビューの「参考になった」、「ならない」がレビュアーの実績として
加算されていきます(至極当然な仕組みです。)

仮に、ごく普通のアマゾン利用者がいて、普通に商品を購入し、
特に気に入った商品についてはレビューし、いくつかの「参考になった」をもらって
ささやかなアマゾンライフを楽しんでいたとします。(これが圧倒的多数の姿だと思います)

そんな人は、かような状況で絶対にレビュー投稿できません。
圧倒的な確率で不条理な量のマイナスポイントが“刻印”されるからです。
ささやかな活動の「参考になった」が 3 に対し、
悪意によって「参考にならない」が 100 つく感じですね。
これはもう、人によってはそのアカウントを捨て去る覚悟を要求されます。

せいぜい自由なのは、不条理なレビューに対して反対票を投じるぐらいで、
20~30ほどそうした票が見て取れます。20~30あるいはその半分でも、
通常のレビュー投稿を試み、この事態から挫折したかもしれません。
そうした方々が自身のふがいなさを思ったであろうことは、想像に難くありません。
彼らが悪いのか、とんでもない。ひどい話です。

つまり、アマゾン利用者として『事実上自由なレビューを制限されている』状況です。
状況解釈などではなく、一アマゾンユーザーとしてそのような縛りを感じると、
はっきり断定します。

私のレビューに、みんなもレビュー投稿しようぜ!ってな要素を含ませようと
考えていたのですが、それが出来そうにないと知ったわけですね。
(私が特攻レビューしてもなんら失うものはないのですが・・・)

まったくもって、恐怖心をたのんだ「テロ行為」そのものです。
利用者の自由な意見の表明場として正常に機能しているとは思えません。

そこで、対抗レビューの前にまずアマゾンへ抗議しようと思います。


  • アマゾン レビューガイドライン
    「投稿したレビューやガイドラインに関するお問い合わせは、カスタマーサービスまでお願いします。」

私の立場としては、

「おいおい、明らかにレビュー場が正常なパターンから逸脱してるだろっ!
安心してレビューできる状態へモデレートしてくれ!」

ということになりますが、

(すでにアマゾンへの抗議はされているとも思いますが、)
ご著者のお立場としては、今後の売り上げへの影響も懸念されることですので、
アマゾンという世界的巨大サイトを悪用したあまりにも強大な風評被害という点で
抗議なさってみてはいかがでしょう。
ご自身の利害意識からの抗議ではなく、不肖私、一読者からの進言があったわけですから。

あるいは、メールを頂いた他の善意ある読者様に、
直接アマゾンへの抗議を呼びかけられてみるのも手かもしれませんね。
こういう意見は数が多い事に意味がありますから。

一部のやかましい小集団による恣意や悪意によって、
アマゾンはコントロールされるべきでない、テロ行為も許容すべきでない、
というのがアマゾンの当然な立場だと思います。

岡部様

【実名】です。
今、まさに抗議文を送信したところです。

☆5つの方、いらっしゃいますね。すごく勇気のある方です。
そして、その方、これまでのアマゾンのレビュー実績が多く、きわめて頼もしいですね!
異常な不支持票をものともしない強い味方です。流れが変わるかもしれません。
おめでとうございます。

ちなみに、抗議文はこんな感じです。


レビュー機能が悪意によりハイジャックされている事をご報告します。

書名『関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間』
http://www.amazon.co.jp/dp/4798043761/ref=pdp_new_dp_review

こちらの書籍を御サービスで予約したところ人気商品につき到着が遅く、あきらめて近場の書店で購入しました。

一読者として、著書から得るところが大きく、とても有用との意見を持ちましたので、
著者への応援、感謝の意味も含め御サービスでレビューを投稿しようと思い立ちました。

しかし、この惨状となっており、驚きました。
http://www.amazon.co.jp/product-reviews/4798043761/ref=cm_cr_dp_see_all_btm?ie=UTF8&showViewpoints=1&sortBy=bySubmissionDateDescending

レビューの内容はともかく、その支持・不支持のフォローの様子をご覧ください。
見たこともないような数の票が否定的なレビューを支持しています。
さらにひどいのは、同様の数の票が肯定的なレビューを不支持しています。

こんなものが、書籍レビューの正常なパターンといえるでしょうか。
私には異常と見えます。そして、この状況からごく容易に想像できることは、
私が肯定的なレビューをすれば異常な数の不支持が投票されるだろうということです。

一読者から見て、その通りだと納得できる肯定的なレビューがありましたが、こうしたフォロー状況のため、
このレビュアーは総評として「10%役に立つ」という極めて不名誉な評価が刻印されてしまっています。
http://www.amazon.co.jp/gp/pdp/profile/A5JW5097RF5VF/ref=cm_cr_pr_pdp

私は率直な意見を投稿しようとしましたが、この状況から非常に強い抵抗を感じています。
他にも、同じ理由で肯定的なレビューを思いとどまった方がいらっしゃるはずです。
結果として、御サービスは本書籍を「買うに値しない」と強烈なメッセージを発しています。

御サービスの規模、影響力を考えた時、巨大な風評被害をもたらすことが容易に想像でき、
放置すべきでないと思いますが、いかがでしょうか。


長くなりましたので、簡単に問題をまとめます。

・肯定的なレビュアーへの風評被害
・書籍への風評被害
・恣意的な小集団による御サービス機能へのハイジャック


レビュー機能が自由な意見の表明の場であるのなら、きちんとこれをモデレートしてください。
安心して、素直に気に入った商品をレビューできる状況を作ってください。
見ていて不快であり、素直な意見の表明を邪魔されて非常に残念です。

フェアな状態へ持っていけるよう、お手伝いできることはしたいと思います。
私のレビューも、人の興味を引けるような形に工夫して作り込みますよ!
気苦労も多いかと存じますが、仕方なしと笑い飛ばして参りましょう(笑)
また、何か動きがあったらご報告しますね。

本書に書いている私の知見は、「トンデモ」「低質なワードサラダ」なのか?「読んでも害しかない」のか?

「誰かの知見」に対して「有害」と論じた時点で、その論者の知見が疑われます。
あるいは「現代人」としての素養が問われることでしょう。
ここは「天動説」「地動説」でガリレオ・ガリレイが有罪になった中世ヨーロッパですか?

関数型言語は哲学や宗教と関係がありますか?

ありません。いやひょっとしたらいつか何らかの関係が見出されるかもしれませんが、これまでのところ、まっとうな言説は寡聞にして知りません。
参考リンク:ソーカル事件
(詳しい方へ:ライプニッツのモナドが…とか、カリーハワード対応する数理論理学の起源は哲学だから…とかは、ここでは「関係がある」に含めません。哲学科出身の計算機科学研究者の先生方もいらっしゃいますが、一部で見られるようなトンデモ議論は伺ったことがありません。
「関数型言語」に関するFAQ形式の一般的説明

また、

Eijiro Sumii‏@esumii
Quita on @Qiita http://qiita.com/camlspotter@github/items/6b69f16e925564a16734 … 「関数型言語系情報に関して、Qiita は、もはや情報共有サービスではありません。読んでも害しかない低質なワードサラダに占領されつつあります。
https://twitter.com/esumii/status/558530062576652289

というように、本書にも書いている私の一連の知見について、
「トンデモ」「低質なワードサラダ」「読んでも害しかない」、こう侮辱したのは、

蛇足:あなたは誰ですか?
東北大学 大学院 情報科学研究科の教授(ソフトウェア基礎科学分野)です1。情報処理国際連合(IFIP)関数型プログラミング ワーキンググループ(WG2.8)の正メンバーや、米計算機学会(ACM)関数型プログラミングに関する国際会議(ICFP)の委員・委員長などを務めさせていただいています。それ以前にも同国際会議主催のICFPプログラミングコンテストでは2000年(ペンシルバニア大学チーム)と2002年(東京大学チーム)の2回ほど優勝させていただきました!:-)
「関数型言語」に関するFAQ形式の一般的説明

ご自身によるご説明によると、東北大学 大学院 情報科学研究科の教授の、 住井 英二郎氏です。

以上の「蛇足」というか、「権威の誇示」は、私が当ブログにて、

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

を論じた直後に、即座に追加UPされました。
おそらく、私が、住井氏は、OCamlという、オブジェクト指向・関数型のマルチパラダイム言語の愛用者であり、論者のスタンスとして中立公平性を欠く、私への批判というか罵倒は「色付き」である、と批判したことから、「権威の誇示」をされたのでしょう。

何度も申し上げますが、「権威の誇示」「権威主義」は、特に科学分野においても自明ですが、「道理の説明」としては成立しません。

それは「無条件の信頼」と「思考の放棄」を読者に強いる態度であり、
「理性」ではなく「信仰」で「わからせよう」とする宗教的行為に等しいのです。
学問の作法では断じてありません。学徒として、教師として、むしろ恥ずべき行為です。

住井さん、私はこれまで貴方の「説明」の仕方を拝読していて、これは何度も感じました。
「あれ読め、これ読め」と。貴方はこれまで何も説明しておられない。ただただ自分そして他者の権威を借りる説明の仕方に終始されてきました。

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

オブジェクト指向も関数型言語も、基礎理論はほとんど同じ分野の人たちが研究しています(紹介記事)。オブジェクトと第一級関数やデータ抽象の考え方(第2章・第3章)など、強い類似も少なくありません。Schemeの第一人者による「オブジェクト指向プログラミングに関する欧州会議」(ECOOP)における基調講演スライド(特に22ページ目)や、Haskellの主要設計者の一人による「オブジェクト指向プログラミング・システム・言語・アプリケーションに関する国際会議」(OOPSLA)における基調講演スライド(およびGoogle TechTalksにおける同内容の講演動画)でも議論されているので参照してみてください。
「関数型言語」に関するFAQ形式の一般的説明

どこそこの権威ある誰々が、どういう権威ある場所で、どんな権威ある主張をしているか?だとか、なにかの権威ある本の部分的参照は、読者への理路の説明ではありません。

フェアに申し上げると、私がひとしきり批判した(本書でも批判しています)後に、上記項目は「改善」はされたようです。

私の著書を批判するにあたっても、前述の通り、しきりに愛用のOCamlの解説本を出されていますが、結城氏もとってつけたような宣伝とネガキャンの自己正当化としても言われたように、それ自体は褒められることです。

しかし、「代替案」を示すことは「反論」や「説明」ではありません。
「代替案」や「あれ読め、これ読め」というのは、むしろ考えて反論する手間が省けますから、楽な作業であり、「代替案」を示すだけで、なんとなーく、この相手の言うことは「代替案」より劣っている、と閲覧者に感じさせる「印象操作」だけは上手く出来るでしょう。

「権威主義」や「代替案」は、思考の放棄、議論の放棄です。

哲学的行為 自分の頭で考える作法

「権威主義」や「代替案」は、思考の放棄、議論の放棄です。
では、どうすればよいのか?
自分の頭で考えてください。学校でも世に出てからも、こうアドバイスを受けることは多いでしょう。
しかし、現状を鑑みると、それを「わかったつもり」で、なんら実践できていないどころか、
よりによって実践しようとする、たとえば私のような論者を、以上のように侮辱する人が多いことに驚きます。

哲学的行為を愚弄するものたちです。

昨今の国内IT世界では、「ポエム」なる珍妙な「呪い」が流行しているようです。
ガラパゴス・ネットスラング=「関数型ポエム」という呪詛、先入観的読書と、フェアなレビューの登場

関数型言語は哲学や宗教と関係がありますか?

ありません。いやひょっとしたらいつか何らかの関係が見出されるかもしれませんが、これまでのところ、まっとうな言説は寡聞にして知りません。哲学科出身の計算機科学研究者の先生方もいらっしゃいますが、一部で見られるようなトンデモ議論は伺ったことがありません。

という、住井 英二郎氏の「一般的説明ではない」「私見」について、
「一部で見られるようなトンデモ議論」とまで侮辱されている当事者として、
以下論評いたします。

「このご時世に読むなとか仰るレビュアー様があるようですが」「分かったつもりになるなってことですよ。」「自分で検証し判断する脳みそがありますので、ご心配なく。大きなお世話なんだよ。」

まず、上述の「テロ行為」についてもそうですが、

http://www.amazon.co.jp/review/R2LRHD6OIFCBXU/ref=cm_cr_pr_perm?ie=UTF8&ASIN=4798043761

に素晴らしい「書評」をいただいております。
結城氏が読んでもおられない本を「Disる」「印象操作」し露出し自書の宣伝に勤しまれるのとは、対照的に、逆に身銭を切ってお買い上げいただいて、ちゃんと読んでいただいた方々による「書評」です。

結城氏が阿る集団による「テロ行為」に屈せず、このような状況の中、レビューを投稿するのは、気後れする、結城、でなく勇気ある行動だったと拝察します。

おひとりおひとりのその勇気を心よりリスペクトします。

最後部分で「一体何ロ行為っていうんでしょうね。」と指摘されていることから、前述の私へメールをいただいて、Amazonに抗議文を送ってくれた方と同一人物なのかもしれませんが、よくわかりません。

このご時世に読むなとか仰るレビュアー様があるようですが
こんな面白そうな事になっている本、読まない手は無いでしょうが(笑)

もとい、読者層は知的活動のエキスパートたらんとする人達で、機会を他人の判断に委ねる愚か者ではない。
スティーブ・ジョブズが残してくれた言葉 Stay fool って分かったつもりになるなってことですよ。
自分で検証し判断する脳みそがありますので、ご心配なく。大きなお世話なんだよ。

..
私は、ここは「天動説」「地動説」でガリレオ・ガリレイが有罪になった中世ヨーロッパですか?
と書きましたが、この人はもっと辛辣に

おやおや、ここは猿の惑星ですか?

と「テロ行為」のレベルで一連の状況を批判された上で、本書の哲学的性格を高く評価していただいております。

97 人中、11人の方が、「このレビューが参考になった」と投票しています。
5つ星のうち 5.0

これはサクラ先輩に加勢せざるを得ない!, 2015/5/5

投稿者 fine!
レビュー対象商品: 関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間 (単行本)

おやおや、ここは猿の惑星ですか?

この状況を見ると、客観的に確実に言える事が1つあります。
本書は怪物のしっぽをグリグリ踏んづけているらしいということ。
この類まれな特徴ひとつ見ても一読の価値アリと言わざるを得ない。
リスクはたったの1404円!

このご時世に読むなとか仰るレビュアー様があるようですが、
こんな面白そうな事になっている本、読まない手は無いでしょうが(笑)

もとい、読者層は知的活動のエキスパートたらんとする人達で、機会を他人の判断に委ねる愚か者ではない。
スティーブ・ジョブズが残してくれた言葉 Stay fool って分かったつもりになるなってことですよ。
自分で検証し判断する脳みそがありますので、ご心配なく。大きなお世話なんだよ。

余談はさておき、本書の感想ですが、
書名が示唆する通り、本書を買い求めた私は関数型プログラミングの初学者で、
命令型パラダイムから関数型へ切り替えようともがいているところです。

結論を言えば、切り替えのための手がかりが得られました。
本書にくり返し出てくる「コード内における時間の感覚」です。

命令型の典型コードである、

n = n + 1;

には、確かに「論理的な時間のずれがある」と“解釈”できます。
関数型は論理の宣言なので、このような「ずれ」へのセンスがポイントだったわけです。
目からウロコ、パラダイムシフトの要点です。

そんな事、偉い人は誰も言ってのいじょのいこ!ですって?
それって、まっさらな筆者のオリジナルって事でしょうか?
(なら脱帽モノの、画期的な仕事じょのいこ・・・!)

一通り読んだ時点では、ご多聞に漏れず要領を得ませんでした。
ただ、モノの見方を変えようって時に舐めてかかる道理は無いので、そこはこらえつつ、
Facebook React サイトのチュートリアルや解説記事にも取り組みました。

React は関数型ライブラリのくせに setState なる不穏物を抱えており、
初学者としては、状態変数?なんで???となるところでした。

だがしかし!

「コード内における時間の感覚」という“新しい”概念のおかげで、
React の設計がとても自然に理解できたのです。ブラボー!
(親コンポーネントの状態変化が子コンポーネントに即座に反映される仕掛けで、
状態矛盾は見事に解消されます。まさに論理的な時間の一致。)

そう気づいてから、哲学を含む本書の様々なフレーズが、
この点に導いて気づかせるためのピースであった事が見えてきます(ここ鳥肌もの)。
これは、他のレビュアー様も書いている通り。

それらピースは、もう頭が下がる程に、涙が出るほどに、丁寧に、周到に、
一つの無駄もなく配置されていたのです。それはまるで、

人が
猿に
言葉を教えるように・・・

猿ちゃうわ!!
だが確かに進化した、と認めざるを得ない。

意欲的な指南書を出版された秀和システムには筆者ともども拍手を送りたいです。
今後さまざまな良書にあたり研鑽を積んでいく上で、この手がかりは大いに助けとなりそうです。

最後に、不気味な数の支持票や不支持票をぶちこんで一般ユーザーに恐怖心を抱かせ、
公正なレビューを抑え込むような事って、一体何ロ行為っていうんでしょうね。
こんなことナチュラルにやらかしてたら「ダサい」って言われちゃいますよね。

関数型プログラミングの思想啓蒙書

また、「関数型プログラミングの思想啓蒙書」と書いていただき、高い評価をいただくレビューもあります。

http://www.amazon.co.jp/review/R1PX8PB22DHNMZ/ref=cm_cr_pr_perm?ie=UTF8&ASIN=4798043761

104 人中、12人の方が、「このレビューが参考になった」と投票しています。
5つ星のうち 5.0

関数型プログラミングの思想啓蒙書です, 2015/5/3

投稿者 y93
レビュー対象商品: 関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間 (単行本)

一言で言えば、
関数型プログラミングの思想啓蒙書です。

過去の哲学者たちの思想解説を含めた
筆者の思想・哲学的なバックボーンも
かなりのページを割いて書かれていることから、
そういう部分に感心のない人には
理解されづらいところもあるかも
しれません。

しかし、筆者の思想・思考は
デタラメなものではなく
筋が通されていますし、
その思想背景の元で
宣言的にプログラムを作る
意義・メリットが
キッチリと説明されています。

私自身、
関数型プログラム言語を使用して
開発をしたことがあり、
当時は基本的な考え方や注意点を
充分理解せずに作っていましたが、
本書により
宣言的にプログラミングすることの
理解を深められたと思います。

単純なサンプルプログラムだけではなく、
シンプルではありますが
React.jsを用いたWebプログラムの
サンプルプログラムと
綿密な解説も書かれており、
今後JavaScriptで関数型を活かした
Webアプリ開発を行うための
入り口になる書籍だと思います。

ライトノベル風という
技術書にしては少々風変わりな本ですが、
そのおかげで読みやすくなっている
ところもありますし、
よく書かれた本だと評価いたします


異口同音に「テロ行為」について厳しく批判しておられます。
勇気あるレビューに感謝したします。
そして、同様に、本書の哲学的側面について高く評価していただいています。

http://www.amazon.co.jp/review/R336LE9KJ6RG8/ref=cm_cr_pr_perm?ie=UTF8&ASIN=4798043761

354 人中、36人の方が、「このレビューが参考になった」と投票しています。
5つ星のうち 5.0

ネガキャンに騙されるな。大丈夫。この本は良書です。, 2015/4/27

投稿者 yukiema - レビューをすべて見る
Amazonで購入(詳細)
レビュー対象商品: 関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間 (単行本)

Qiitaに関数プログラミングの記事を投稿されていた頃から、この著者の方の才覚に感嘆していました。

オブジェクト指向こそが現代のプログラミングにおける現実解。関数型プログラミングは未だ研究レベルの代物。という私の固定観念を見事に打ち砕いてくれた方です。

Qiitaの記事とそのコメント欄での議論の応酬を見てわかったのですが、
この著者の方は、その強靭な信条と、論理を欠く批判者に対する徹底した反撃ぶりゆえに、あまりに敵を作りすぎてしまいました。

それゆえ、このAmazonレビュー欄にまで、著者を攻撃すること自体が目的化した者達による「論理性の微塵もない」ネガティブキャンペーンが展開されているのです。
(それも、『xxx 人中、xxx人の方が、「このレビューが参考になった」と投票しています。』という投票システムにまで不正なネガティブ投票をしている徹底ぶりです)

よって、レビューの星は低い状態になってしまっていますが、心配することはありません。
この本は、良書だと思います(もちろん、人によって印象は変わると思いますのでそうでないと判断する人もいるかもしれませんが、少なくともネガキャンレビューに見られるような、『読む価値もないかのような悪書』では決してありません)

この本には、関数型プログラミングだけでなく、その背景となる、様々な著名な哲学者たちの思想についても触れられています。

Qiitaの記事でそれを読んだときは、「いやいやプログラミングなのに、なんで哲学の世界にまで入っちゃうのよ・・・」と正直引いてしまった事があったのですが、この本では、サクラというIQ145を誇る美少女がわかりやすく噛み砕いて会話形式で説明してくれるので、Qiita記事よりも遥かに理解の敷居が下がりました。

そして、全体を読むに連れ、その哲学の説明が、決して著者の自己満足でなく、関数型プログラミングの確立までに至る連綿とした思考過程であったことが分かるのです。

著者は関数型プログラミングこそ最高のプログラミングであると確信している点が、本書の随所に現れており、それが、他の考えを支持する方にとって受け入れがたい、読むのが辛いと感じる部分かもしれません。
しかし、それはそれで良いではないですか。他のパラダイムを支持していて、この本を読んで批評することは全然かまわないのです。
(むしろ、著者は批判も歓迎しておられるようです。あくまで、論理性を欠いた印象論・感情論・人格攻撃する人間に対して容赦がないだけです。)

この本の内容を受け入れるにせよ、否定するにせよ、得るものがあるといえる本ではないでしょうか。

関数型プログラミングの本はどうしても難解になってしまうものが多いですが、ラノベ形式でここまでかみ砕いた説明で、関数型プログラミングの世界に誘ってくれる日本語の本はそうそうありません。

程度の低い感情的なネガキャンに惑わされて、こんな良書を見逃すなんて、もったいないと思いますよ。

最後に、☆4の評価です。

「刺激的で読みやすい、新ジャンルを切り拓くかもしれない意欲作」
http://www.amazon.co.jp/review/R4MQ12S6X2FU/ref=cm_cr_pr_perm?ie=UTF8&ASIN=4798043761
このレビュアはどなたであるかは、存じております。
哲学のバックグラウンドがある方です。

「本書は、私にとっては、読み進めやすく」
と「珍しい」レビューをはじめられるのは、
この方はとりもなおさず、私、岡部がなにを語っているのか?
最初から理解できる、知見の土壌があるからです。

75 人中、8人の方が、「このレビューが参考になった」と投票しています。
5つ星のうち 4.0

刺激的で読みやすい、新ジャンルを切り拓くかもしれない意欲作, 2015/5/5

投稿者 Phullapadma
Amazonで購入(詳細)
レビュー対象商品: 関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間 (単行本)

本書は、私にとっては、読み進めやすく、かつ内容的に面白く、思考を刺激されるものでした。

私の知識的背景としては、本書で素材とされる言語JavaScriptに相当長期間の馴染みがあり、
西洋哲学史や宗教哲学にある程度の素養を持ちます。また言語やシステムを創案する立場に
共感しやすく、そうした設計の背景となる哲学や思想を聞くのが好きな傾向にあります。
逆に、関数型プログラミング自体には何も予備知識がなく、本書で初めて触れた状態です。

そうした背景のもとで読みますと、まるで私に合わせて書かれたかのように読みやすく、
著者の一貫した著作意図や工夫のあとがよく理解できるように感じられたので、この評価に
しました。
もし科学哲学や認識論の文章を読むのに日頃から抵抗がなく、コードの実例を目いっぱい
得られなくてもイライラしないタイプの方であれば、この著作の読者として最適ではないかと
思います。

プログラミングを哲学の投影のように扱い、背景思想を語ることに、多くの方が批判的な
ようですが、逆に、私はその点を、この著作最大の美点として推します。類書はたしかに
これまで存在せず、異色の試みですが、私はこういうスタイル・切り口の著作があれば、
他の著者や言語の本であっても喜んで読むでしょう。
哲学は歴史的に見て、あらゆる学問の源泉・母体となった学問ですが、現在においても、
その中核にあって、しかも内部の各分野が緊密に連携しています。プログラミングに
関係する論理学や数理哲学だけでなく、言語哲学・科学哲学周辺まで背景知識として
持つことが、言語設計の理解の助けになるだけでなく、面白いことだと私は思います。

ただ残念ながら、本書での意欲的な試みは、完全には成功していません。
理解のために工夫した表現・言葉の選び方が裏目に出ていたり、副作用が大きかったり
しています。
ライトノベルの形態による物語進行は、時々興ざめのアラがあったり、これは個人的好み
でしょうがキャラ設定が魅力的でなかったり、ストーリーの盛り上がりに欠けたりして、
十分な吸引力を発揮していません。

ですから★5つにはできないのですが、私には近年稀にみるツボに入った著作であり、
私に近い背景や価値観をお持ちの方であれば、大いに気に入るはずであると思います。

[追記]

この著作は、「技術書はこうあるべき」と一般に考えられるスタイルを大きく逸脱
しています。読者の期待するスタイルと違うので、期待に反して「失望した」と感じる
読者も多いでしょうし、真価が理解されにくいのだと思います。

普通、プログラミングの本といえば、なんらかの仕様・要件に沿ったコードを、
なるべく速く効率よく書くための方法を、なるべく多く、具体的に示すことを目指します。
あるいは、書き方が分からなくなったときのリファレンスを提供します。
それが、通常求められるプログラミングの本の価値です。
実際に、業務上求められることと直結しているので、学習する誰もが喜びます。

しかし、この本は、私の解釈では、その普通とは、主な目的が異なります。
オブジェクト指向と関数型プログラミングとのパラダイムの違いがどこにあるかを、
より抽象的な思想として、しっかりと分かってもらうことが主な目的です。
動くコードを書くことを最低限の前提の上で、あらゆる工夫が、パラダイムの違いが
どこにあるかの説明に向いています。
普通の本ならば言語の特徴の説明として冒頭数ページで済まされるかもしれないような
ことの伝達に、本全体が向けられているのです。

対象とする読者は、命令型・オブジェクト指向である程度以上のプログラミングができるが、
関数型プログラミングに移行する時に考え方をどう捉えていいか分からない人です。

プログラミング、特に説明材料にされているJavaScriptのよく分からない人は、
いくら短いコードが中心といっても、この本を読んでも結局何も分からないでしょう。
コマンドライン(ターミナル/プロンプト)を打ったことのない人、なんかが読むと、
この本の実践をするのに困り果てるかもしれません。
その逆に、既に関数型プログラミングを感覚的に掴んでいる人にとっては、何の利益にも
ならないばかりか、他の方のレビューを見る限り混乱を招くだけになる可能性が高いです。

同時に、プログラミング以外の教養がある程度必要とされています。
西洋哲学史の知識を中心に、日本語の語彙、そしてある程度の英語力もあった方がいい
でしょう。
平均的にイメージして、小中学生が読んで歯が立つとは思えず、登場人物と同じ高校生が
最低ラインかなと想像します。
多くの人が批判している通り、そうした教養があった上に、日常的な用法とは違う用法で
使われた単語の定義を自分で修正しながら読んでいく柔軟性と忍耐力もある程度必要です。

その上で、
過去に書いたことの参照が必要な時には、ほぼ必ず再掲されています。
ページを戻って該当箇所を探す必要がないので、一直線に読み進めることができます。
逆に言うと、物語的に、一直線に読み進めることを想定した著作です。必要なポイントを
拾い読みする本ではありません。
併せて、しばしば重要事項のまとめが現れます。多くの特徴的・個性的な表現が繰り返されます。
これは、一冊を通じて、一つの主張を組織的に説明し、確実に記憶に残そうとしている
ためです。「重要なことを読み落としたかも」「忘れてしまったかも」と不安になることなく、
終盤まで読み通すことができます。

必要なポイントを読書の流れの中で確実に覚えてもらうスタイルのため、「何ページに戻る」と
いうことが生じることが想定されていません。従って、細かい目次が付いていません。
個性的な表現で冗長なまでに同じ内容・同じパターンの説明を繰り返すのは、記憶への
定着を確実にするためです。その手法は、お経と似ています。

以上の「書評」を書いていた方々に、改めて、この場を借りてお礼申し上げます。
どうもありがとうございます。
正直ここまで事細かに著者としての意図が伝わっている書評をいただいたのは、驚きました。
著者冥利につきます。

私は全力で本書を書きましたが、伊達や酔狂で哲学のことを書いたのではありません。
関数型プログラミングは、「時間」を抽象的に論理化する手法であり、
そんなこと考えたことがない人がほとんどなので、どうしても、そこから始める必要がありました。

ただ、ざっくり話してもどうせまた色物扱いして終わらせようとするのが、
哲学を愚弄するものたちですから、歴史上のビジョナリーの方々の力をお借りして、
私の考えかたというのは、人類の長い知見の結晶である、と示したのです。

これは、伝わる人には伝わりました。本書は試みは紛れもなく成功した、と著者として報われました。
それ故、私はこの美点として評価していただく行為も含めて、封じ込めようとする行為、毀損する行為については、著者としての全責任において、このようなブログ記事で記録して、後世に残します。

「読んでも害しかない」と言うのは、上記「書評」より明白ですが、事実と異なります。
また、「タダでも読む必要のない(というより読むべきではない)書籍」というのも事実と異なります。

「テロ行為」は技術的正確性にも及んでいます。しかし私以外誰も咎めず、Amazonで、102 人中、93人の方が、「このレビューが参考になった」らしい

結城浩‏@hyuki
偏差値40のJCの関数型ガールも執筆してください — たぶん結城は書きません。2015年の春に憤っている関係者の中から、そのうちに良い本が出てくることを期待しています。まっとうな方が、まっとうな本を出すことを期待しています。 http://ask.fm/a/c3p98kne

「まっとうな方」であるかはともかくとして、読んでもおらない本について「まっとうな本」だのどうだの論じるのは、本当にいい加減にしていただきたいと思っています。

Amazonで、102 人中、93人の方が、「このレビューが参考になった」と投票されている、著書の「クロージャ」の説明が誤っているとの指摘が、誤っていることについて

Amazonレビューで嘘を書かないこと、それが技術的議論のための最低限の要件である

技術的に正確でない、と本書の出版について「2015年の春に憤っている関係者」は、まるで、こういう技術的正確性まで毀損する「テロ行為」の修正には関心がないようです。
何故ならば、「2015年の春に憤っている関係者」こそが「テロ行為」の当事者であったり、支援する層なのですから。

「2015年の春に憤っている関係者」を追認し、彼らに期待し、承認しているのが結城氏です。

「2015年の春に憤っている関係者」は一体全体、何に「憤っている」のですか??
著者としての私による「哲学的言及」についてでしょうか?

「2015年の春に憤っている関係者」は一体全体、何に「憤っている」のですか??
技術的正確性についてでしょうか?

じゃあなんで、Amazonで、102 人中、93人の方が、「このレビューが参考になった」
ということになっているのですか?

彼ら、「2015年の春に憤っている関係者」によるテロ行為であり、
本書を毀損することこそが「第一目的」であって、ほんとうのところ、
「技術的正確性」だの「初心者の誤解なきような理解」なんてことは、関心なんてないからですね。

デマでも嘘でも、流布されたら、本書が毀損されたらそれでいい。
広い読者に認められなければそれでいい、読書機会を奪えればそれで世のため人のためになる、
と本気で考えているのでしょうか?

読者の方が言われていたように、「余計なお世話」です。
彼らはご自身で考える力がある。
その機会を、きわめて巧妙に、横暴をもって奪おうとするのがあなた達です。
「テロ行為」と言われて妥当だと思います。

執筆とは、出版とは元来、自由な表現活動である

ボトムラインとしては、私は単に、「考え方」を提示しただけです。
自分が考える、また書籍を通じても、伝わる人には伝わり高い評価もいただいた、「考え方」「世界観」です。

本当にこの「考え方」を一部でも共有することにより、それはきっとプログラミングの世界の見方が変わる一助になると信じて全力で執筆しました。

執筆とは、出版とは元来、自由な表現活動であり、自身のスタイルも貫きました。
秀和システム社には、著者としての意向を最大限に尊重していただき、前代未聞でこのような批判があることも予知しながら、英断して形にしていただきました。本当にありがとうございます。

ここで、名前を上げた方々は、基本私は存じ上げない方ばかりですが、かような私と秀和システム社による、誇りをもって形にした出版行為について、「2015年の春に憤っている関係者」なるものが、出現し、あるものは自身の出版行為に利用するために、対象書籍を読むこともなく、「2015年の春に憤っている関係者」を無条件に承認し、彼らと一緒にその出版行為を貶め、あるものは、哲学的行為自体を貶めました。

執筆とは、出版とは元来、自由な表現活動です。それには文責が伴いますし、それ相応の批判を受ける覚悟は当然必要です。私もそれは受け入れる覚悟は当然持っています。

「書評」は歓迎します。
言論の世界の作法として、対象書籍を明確にしてください。
本書は、IQなんとかの本、ではありません。

言論の世界の作法として、論評するなら読んでください。
通読してください。できれば精読してください。

「含むものがある」著者に反発したいお気持ちはお察しいたしますが、
「2015年の春に憤っている関係者」なるものを無条件に承認し迎合するのは、
その極めて歪曲された一方的な「Disり」があなたの都合と合致するからに他なりません。

本当は、

『数学ガール』は読んでいない、と「縄張り」における「当然のリスペクト」が得られない、無視されたことに立腹して、機会に乗じた自身のブランディング行為、著書の宣伝なのではないですか?
違うのなら、なんでこんなくだらない恥ずべき真似を彼らと「対話」し、承認しながら一緒になって展開されているのでしょうか?是非説明してください。
念の為ですが、結城氏のTwitterは今回特別に部分的に精査しただけです。Twitterで「エアリプライ」を頂いてもこちらには届かないので、もしなにかあるのならばメールでおねがいします。

住井氏の関数型プログラミングとオブジェクト指向に関する主張、そして遅延評価についての主張は国際的には極めて特異な私見にとどまっており、
関数型プログラミングとオブジェクト指向のパラダイムとしての対立 国内の【自称】関数型コミュニティと海外の論調の違い
一般的説明ではなく、私見を学習者に権威を利用して押し付けるのみならず、見解が異なる相手の哲学的行為を「トンデモ」「低質なワードサラダ」「有害」と侮辱している、と批判した、私の著書が世の中で認められるとご自身の立場がなくなるのでしょうか。
住井氏におかれましては、すでに当ブログ記事を読まれたことを確認しましたが、すでにご反論があるのならば、直接メールをいただくようにも書きました。何かの権威であったり、代替案を示すことは、説明でも反論でもない、ことはすでに説明いたしました。もちろん、住井氏の一連の当方へのあからさまな侮辱行為について、代替案を示すことで、謝罪になるわけもありません。ほうったらかしです。

執筆とは、出版とは元来、自由な表現活動です。
あなた方の言論活動は自由ですが、私は今回、言論の作法を大きく逸する、極めて理不尽で、一方的な毀損行為が行われたと観察しています。故にこうやって批判しています。

本書のたいせつな潜在的読者の読書機会を奪わないでください。

あなた方には、今後ご自身の行動の修正機会が開かれているわけですが、正直私は何も期待していません。その是非については、今後長い期間、世の良識が判断すると信じます。

追記:大人のイジメ

*ある信頼できる方と本件についてメールをやりとしたときの私の返信に基づきます。

今回、XX少年のつらい経験を伺い、XX様の温和な人格形成の一端を垣間見ることができました。
私は本当に「イジメ」というのが嫌いです。

子供であっても「イジメ」は許されることではないですが、
よりによって、それを諭す立場の大人になってからも、
連中のように、ヘラヘラ笑いながら「いじめ」をやっている連中が絶対に許せません。
今回の事象でいうと、
2ちゃんねるスレッドの連中、
Hatenaブックマークの連中はもちろん、
【自称】関数型プログラミングコミュニティの連中、
「2015年の春に憤っている関係者」の連中のことです。

私がネットの誹謗中傷に人並み以上の嫌悪感を表明するのは、
それが「大人のイジメ」であるからに他なりません。
そして他ならぬ自分自身がその「イジメ」の対象となることを絶対に了としません。
多くの「大人のイジメ」に加担している連中は自覚もありません。
私が相手を名指しして批判するのは、少なくとも私が、その相手を
「イジメに加担している当事者である」と自覚してもらうことが第一義としてあります。
自分が「イジメ」に加担していて、良心が傷まないのか?と問います。

たぶん、XX様が私に好意的でおられるのは、
私達のこの「イジメ」に対する価値観が一致しているからだと思います。

これは大げさでもなんでもなく、私が「友人」として選ぶ、
というより自然と仲良くなる人の自然な選別基準は、
そのひとりの人間が「イジメ」を心より忌み嫌う人間であるかどうか、ということです。

私の友人には大人として「イジメ」に加担する人物はひとりもいません。
そもそも「イジメ」に加担する人物は、
イジメに加担するようyな歪んだ自身の人格の正当性を維持したいので、
自然と「ネットの誹謗中傷」に歴然とやり返す私のような人間を「叩く」ほうにまわります。
それがその人間の本性であり、そこが「踏み絵」です。
私と仲良くなることはまずありません。
逆に私に接近して声をかけ、仲良くしてくれるのは、
その「踏み絵」を踏んで、こちら側に来る人たちです。
「類は友を呼ぶ」。
私はこのように至らない人間ではありますが、
根底のその部分の価値観が一致する同類の人とだけ仲良くなります。

逆に言うと、私を叩く側にまわるような人間とは、
仲良くなる価値など最初からないので、
とても良いフィルターとして機能しています。

ちょっとまともに見える人が連中とともに私をバッシングしはじめたら、
私が名指しして批判するのは、今回の結城氏がそうですが、
さて、あなたはどっち側の人ですか?と衆人環視のもと「踏み絵」を差し出すためでもあります。

私の観察では、彼は「踏み絵」を踏むこと自体を巧妙にさけながら、
「あちらがわ」と連携しました。
正確に言うと、「踏み絵」を上手にまたいで、
「こちらがわ」に足が乗っているようにも見せています。
私はそれ自体が非常に胡散臭く感じて仕方がありませんでした。

私は幸いなことに、子供の頃イジメにあった経験はないですが、
XX少年の心を想像すると、いかほどに辛かっただろうと胸が痛みます。

自分が自分の子供の頃に戻れるわけもない、今の考えが岡部少年の行動ではありえない、
と思いながらも、もし自分がXX少年の立場になったならば、
担任に事情を説明し、学級会で、取り上げると思います。
その場で、教師を巻き込んで、多分いじめのメンバーを糾弾すると思います。
で、嫌われるんでしょうね(笑)
「あちら側」のろくでもない教師であったならば、教師にも厭われることでしょう。

そう考えると、XX少年っていうのは、すごいなあと心より尊敬するわけです。
岡部少年は。ひっくりかえっても多分そんな真似はできない。
多分イジメるやつを殴ると思うんですね。
そもそも、イジメるような連中に、なんの非もないこちらが努力してまで
仲良くなりたいとは思わないわけです。
たとえ、それによってクラス全員の嫌われものになったとしても、
イジメの対象になり続けるよりはマシだと考える。

大人になってからは、暴力に訴える必要はありません。
でも私は多分、XX 少年にはなれないでしょうし、これからも踏み絵を差し出すと思います。
建設的なメッセージは「踏み絵」を差し出す以上に、発信していきます。
しかし、私は多分、「大人のイジメ」について黙っていられるとは思えません。

2015年5月2日土曜日

React 解説【動的HTML-FRP編】

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

の続き、【動的HTML-FRP編】となります。

前回、【静的HTML編】では、

原始のWebページ、
静的ドキュメントを記述するための
HTML(宣言型コード)

enter image description here

を、

enter image description here

へと移行させました。

今回の【動的HTML-FRP編】では、

原始のWebページの進化系の、
動的なWebアプリケーション=ユーザ・インタフェース
を記述するための
HTML+JavaScript (命令形コード)

enter image description here

を、また、

enter image description here

に移行させます。
 

React-JSXでは、Elementがファーストクラス・オブジェクト

Reactでは、
物理的なUIに相当するDOM要素を仮想化し、
VirtualDOM(仮想DOM)という論理的存在になったElementが、
JavaScript(JSX)上で、ファーストクラス・オブジェクトとして、
縦横無尽、自由自在に論理操作して、合成もできてしまいます。

Elementを返り値として返す、関数型プログラミングの関数に相当するComponent

Elementは、別のElementを返り値として返す
関数型プログラミングの関数に相当するComponentとして設計されます。

設計定義された、Componentは、HTMLの従来のタグ表記とすることで、
Elementとして、「インスタンス化」されます。

関数型プログラミングのコンポーネント指向

Elementは、別のElementを返り値として返す
関数型プログラミングの関数に相当するComponentとして設計されます。

ということでも、すぐにわかるとおり、
これは延々と入れ子の論理構造となっており、
Reactではこの論理操作を繰り返して宣言していきます。

このように、
あるファーストクラス・オブジェクトを(必ず)返すような、
自身ファーストクラス・オブジェクトになるコンポーネントを設計する、
というコンポーネント単位の設計、
コンポーネントの多重構造の設計で、コーディングすることを、コンポーネント指向と言います。

コンポーネント単位の設計のコンポーネント指向は、原理的に宣言型のコードになります。

前回、その様子を実際に、簡単なHTMLをJSXに移行させることで、具体的にデモンストレーションしたわけですが、このコンポーネント指向の設計で、
さらに、時間変化まで取り扱う、というのは、また別の話になってきます。

Reactコンポーネントは、時間変化、ユーザの入出力にたいしてどうあるべきか?

Reactはコンポーネント指向であり、
すべての物理的なUIは、
コンポーネントとして、論理的に延々と入れ子構造で合成されて設計されています。

繰り返しますが、コンポーネント指向は宣言型のコーディングです。

ここを土台として、さて、これからどうしていくか?
各コンポーネントは、時間変化、ユーザの入出力にたいしてどうあるべきか?

いくつかのアプローチが考えられるでしょう。

【解法1】従来の命令型、あるいはオブジェクト指向のアプローチ

実際この解法は可能です。
Facebookは、Reactを全体の設計を規定するフレームワークとしてではなく、ミニマルなライブラリという位置づけとして提供しているので、このアプローチは可能です。
もちろん、Reactを設計、開発したFacebookの技術者の意図、設計思想の延長にはないでしょうし、推奨もされていないでしょうが、別に制限はかけられてはいないので、可能は可能です。

例題として、
毎秒、数字を0から1ずつカウントアップしていくUIを実装します。

var Timer = React.createClass(
{
  render: function()
  {
    return (
      <div>Seconds Elapsed: {time}</div>
    );
  }
});

var time = 0;

var f = function()
{
  time++;
  React.render(<Timer/>, document.body);
};
setInterval(f, 1000);

React.renderを、マウントする宣言、とするのではなく、
毎秒、文字通り「レンダーし直せ」という命令にします。

time をグローバル変数とし、グローバルで変更、管理し、
Timerコンポーネント内部から、その値を直接読みだしてエレメントに反映させています。

非常に直感的で、わかりやすいコードですが、
これは、もはやコンポーネント指向の設計思想ではありません。
これは、命令型のコードです。
この調子で進めていくと、命令型のパラダイムで全体が構築されるので、もちろん、あとあと宜しくないです。なぜ、命令型だと後々よろしくないのか?よくわからない人は、このブログのヘッダー部分にある著書の立ち読み記事を読んでください。

そこで、せめて、
React.renderは、あくまでマウントする宣言であり、
Timerコンポーネントのプロパティ(関数型プログラミングの引数に該当する)のみが変更されて、再描画させる、という思想でやります。

var TopComponent = React.render(<Timer secondsElapsed={time} />, document.body);
と宣言した、TopComponentについて、毎秒、
TopComponent.setProps({ secondsElapsed: time++ });
setPropsとプロパティ変更を通知して、再描画させます。

var Timer = React.createClass(
{
  render: function()
  {
    return (
      <div>Seconds Elapsed: {this.props.secondsElapsed}</div>
    );
  }
});

var TopComponent = React.render(<Timer secondsElapsed={time} />, document.body);

var time = 0;

var f = function()
{
  TopComponent.setProps({ secondsElapsed: time++ });
};
setInterval(f, 1000);

でも、まあこれも、
「ある対象に向けて」「通知する」という、命令型パラダイムなんですね。
宣言型のコンポーネント指向ではない。

【解法2】宣言型、Reactの純粋コンポーネント指向のアプローチ

そこで、宣言型、Reactの純粋コンポーネント指向のアプローチです。
Reactの公式サイトのサンプルコードがこれです。

https://facebook.github.io/react/index.html

A Stateful Component

var Timer = React.createClass({
  getInitialState: function() {
    return {secondsElapsed: 0};
  },
  tick: function() {
    this.setState({secondsElapsed: this.state.secondsElapsed + 1});
  },
  componentDidMount: function() {
    this.interval = setInterval(this.tick, 1000);
  },
  componentWillUnmount: function() {
    clearInterval(this.interval);
  },
  render: function() {
    return (
      <div>Seconds Elapsed: {this.state.secondsElapsed}</div>
    );
  }
});

var TopComponent = React.render(<Timer/>, document.body);

繰り返します。
Reactの純粋コンポーネント指向のアプローチです。

var Timer = React.createClass({....});
var TopComponent = React.render(<Timer/>, document.body);

と2つのReactの宣言文しか存在しません。

基本、Timerコンポーネントが内部で、すべてを一手に引き受けており、
時間変化について自発的に自らの返り値としてのエレメントを更新し、
それは自動的に、全体、つまりマウントされた宣言部分を再描画します。

これは完全かつ純粋なコンポーネント指向となっています。

ただし!ですね。そうは問屋がおろさない。世の中はそう単純でもないのです。

Reactのコンポーネントとは、あくまで、物理的なUIの部品単位を論理化したものです。
これは、あえてオブジェクト指向のMVCアーキテクチャでいうならば、
VのViewで、物理要素に相当します。
そして、MVCのM、Modelの部分は、「ビジネスロジック」などと言われる、
物理要素のViewと分離された正味の論理部分ですが、
そんな単純に、ModelとViewが1:1に結びついているわけもありません。

上のReact公式のサンプルコードでは、MとVが1:1に結びついた、
極めて単純化されたケースとして、
Timerコンポーネントが内部で、すべてを一手に引き受けており、
Reactの純粋コンポーネント指向のアプローチとなっているのですが、
実際、複数のコンポーネント=View、
そして、複数の「ビジネスロジック」=Modelがある場合、
このアプローチは脆くも破綻してしまいます。
つまり、このやり方を単純に模倣していっても、使い物にはならない。

あと、
this.setState({secondsElapsed: this.state.secondsElapsed + 1});
とか、回りくどくて、長くて、面倒くさい、ということもあります。

【解法3】”BestPractice”= ReactのStateは一箇所(トップ・ルート)に集中させ、トップ・ルートから再レンダリングさせるアプローチ

これは、Reactコミュニティでも、自サイトをReactで再構築しようとした技術者が、
試行錯誤を重ねていますが、一定のコンセンサスには到達しているようです。

その結果、ReactのBestPracticeを導出した、という記事が複数、公開されています。

REACT TIPS AND BEST PRACTICES
では、

CENTRALIZE STATE

enter image description here

ReactのStateは一箇所、具体的には、トップ・ルートコンポーネントか、あるいはグローバルに集中させて、再度、render()をトリガーする、という方法が推奨されています。
このアプローチがもっともシンプルであると。

しかし、この”BestPractice”はいくつか問題があります。
少なくとも2つ問題がある。

  1. これは根本的に、【解法1】の2つ目と同じアプローチであり、命令型である。
  2. コンポーネントの階層(Component Hierarchy)において、トップ・ルートコンポーネントから、末端のコンポーネントに至るまで、すべてのコンポーネントで、逐一、もれなくpropsを流さなければならない。つまり、各部品たるコンポーネントが、常に全体の情報を扱っていることになり、これは関心が分離されているべき部品、コンポーネントのあり方として本末転倒である。

実際、このアプローチでやると、コードはかなり面倒なことになります。

では、なんでこんな問題が起こっているのか?
根本の問題とはいったい何なのか?

その答えは、すでに書いたとおり。
ModelとViewが1:1に結びついているわけがない、からです。

Reactのコンポーネントとは、あくまでViewを「仮想DOM」として論理化した部品であり、
「ビジネスロジック」たるModelとは対応させるべきものでは本来ありません。

Reactのコンポーネントモデルは、あくまでViewという末端を取り回すことに特化した設計であり、それだけで、すべてを構築するのは無理があるんですね。

【解法4】関数型・リアクティブ・プログラミング(Functional Reactive Programming/FRP)のコンポーネントをReactに別途適用する、宣言型

真の”BestPractice”へのヒントは、実は公式サイトに書かれていたりします。

Communicate Between Components
https://facebook.github.io/react/tips/communicate-between-components.html

For communication between two components that don’t have a parent-child relationship, you can set up your own global event system. Subscribe to events in componentDidMount(), unsubscribe in componentWillUnmount(), and call setState() when you receive an event.

親子関係にない、2つのコンポーネントを連携させる場合は、
自前のグローバルのイベントシステムをセットアップしたら良い。
各イベントをcomponentDidMount()で、Subscribeし、
componentWillUnmount()で、unsubscribeし、
イベント通知があれば、 setState()を呼び出すようにする。

これ何を書いているか?っていうと、もちろん、
関数型・リアクティブ・プログラミング(Functional Reactive Programming/FRP)
を自前で実装して、ReactのFRP機構と接続させろ、ってことです。

多くの技術者が”BestPractice”として【解法3】を示唆している中、
なぜ私が、この【解法4】のほうが真の”BestPractice”であると「気がつく」「わかる」のか?というと、それは、ソフトウェア開発における「パラダイム」の違い、もっと言えば、プログラミングの「設計思想」「考え方」「哲学」を常に重視しているからです。著書では、そこが長期的には必ずそこが重要になってくる、と信じるのでそう強調しながら解説しましたが、残念ながら多くの人たちは全く興味も理解も示さなかったようです。
また、おそらく、流れから私の著書が世に広く認められることになってしまうと、批判した自分たちが相対的に間違っていたと評価が下ることと等価であるので、それだけは絶対に阻止したかった思惑もあったのでしょう。これは「自分の立場による手前勝手な都合」であり、「他人の都合のため」の行動ではありません。もちろん、その他人とは、広い入門者のことですが、実際、先入観のない入門者のほうが、著書を受け入れやすいようです。私はメールでの直接のやりとりを通じてそれは実感できたので、著書は成功した、と考えています。「この世代」による反発という短期的な現象(ブーム)は予想通り起こったが、「次の世代」では、その現象は過去のものとなる。単なる短期的な現象(ブーム)ですからね。短期的な現象(ブーム)とは、中長期の評価ではありません。

閑話休題。

your own global event system、つまり自前のFRPで実装しろ、という公式サイトのTIPSによる示唆ですし、実際、私はReactとはFRPの末端部分に過ぎない、という考えとともに、実用に耐えるFRPライブラリを自前で実装する作業をしていたので、それを活用することにします。

worldcomponent The tiny FRPです。

The tiny FRP、このライブラリ(コンポーネント)の実装はかなり単純でコードは短いです。

ソースコード

var worldcomponent = function(initialVal)
{
  var computingF = [];
  var value = {};
  var state;
  Object.defineProperties(value,
  {
    val: //value.val
    {
      get: function()
      {
        return state;
      },
      set: function(x)
      {
        state = x;
        computingF.map(
          function(f)
          {
            f(x);
          });
        return;
      }
    }
  });
  var o = {
    compute: function(f)
    {
      var f1 = function()
      {
        computingF[computingF.length] = f; //push  f
        value.val = initialVal;
      };
      return f1;
    },
    appear: function(a)
    {
      var f1 = function(){value.val = a;};
      return f1;
    },
    now: function()
    {
      return value.val;
    }
  };

  return o;
};

Object.defineProperties(worldcomponent,
{
  world: //our physical world
  {
    set: function(f)
    {
      return f();
    }
  }
});

worldcomponent.log = function(a)
{
  var f = console.log.bind(console, a);
  return f;
};

module.exports = worldcomponent;

著書のメインキャラであるsakurafunctionalの名前で、npmライブラリとして公開
https://www.npmjs.com/package/worldcomponent/
していますが、特にReactを実装するWebアプリから、npmライブラリを利用するには、
browserifyや、webpackで、コードを再パッケージした上でブラウザ上で動作させる必要があります。
CDNで公開してもいいのですが、コードが短いので、上記のコードをコピペして使えば良い、と思っていて、今回もその方針でいきます。Simple is bestです。

npm testにあるとおり、nodeから使う際は、requireもつけて、

テストコード

var ___ = require('./worldcomponent');

var ___a = ___(0);
var ___b = ___(0);

___.world = ___a.compute(___.log('a:'));
___.world = ___b.compute(___.log('b:'));

___.world = ___a.compute(function(x)
{
  ___.world = ___b.appear(x * 5);
});

var f = function()
{
  ___.world = ___a.appear(___a.now() + 1);
};
var timer = setInterval(f, 1000);

実行結果

a: 0
b: 0
a: 0
b: 0
a: 1
b: 5
a: 2
b: 10
a: 3
b: 15
a: 4
b: 20
a: 5
b: 25
a: 6
b: 30
a: 7
b: 35

というように使うのですが、この、
___.world = ___a.compute(___.log('a:'));
とか、どういう意味なのか?
これは、命令型パラダイムを排除し、純粋に宣言型のコードにする超絶工夫なのですが、
この表記の思想背景については、
Lispデータ構造の問題点の指摘と抜本的解法としての新プログラミング言語の策定/純粋関数型言語「Spinoza」に書いており、そのまま援用しています。

また、このappearとかいう用語については、著書でこの前段になる概念実証のためのライブラリの解説としても書いています。
FRPとは、時間軸上のイベントを数学的な集合として取り扱うので、必然的にこういう言葉遣いになるわけですが、本稿では長くなるので余裕で省略。著書を読み返してみてください。

___.world = ___a.compute(function(x)
{
//.............
});

という部分が、ReactのTIPSで示唆されていた、

各イベントをSubscribeし、
イベント通知があれば、
setState()を呼び出すようにする。

に該当する要点となります。

さて、コードまるまるコピペにせよ、webpacknpmパッケージングにせよ、
いずれにせよ、
worldcomponentを適用してやり、
すでに、すっかり忘れかかっていた例題

毎秒、数字を0から1ずつカウントアップしていくUI実装

Reactの公式サイトのサンプルコード
https://facebook.github.io/react/index.html
A Stateful Component
を置き換える、代替アプローチのコードは以下です。

//worldcomponent the tiny FRP
//copy-pasted here, available in npm-------------
//-----------------------------------------

の箇所に実際は、上記worldcomponentのソースコードがコピペされています。

//worldcomponent the tiny FRP
//copy-pasted here, available in npm-------------
//-----------------------------------------

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

var ___time = ___(0);

var f = function()
{
  ___.world = ___time.appear(___time.now() + 1);
};
var timer = setInterval(f, 1000);

var Timer = React.createClass(
{
  getInitialState: function()
  {
    return {secondsElapsed: null};
  },
  componentDidMount: function()
  {
    var com = this;
    ___.world = ___time.compute(function(x)
    {
      com.setState({secondsElapsed: x});
    });
  },
  render: function()
  {
    var el = (<div>Seconds Elapsed: {this.state.secondsElapsed}</div>);
    return el;
  }
});

var TopComponent = React.render(<Timer/>, document.body);

Communicate Between Components
https://facebook.github.io/react/tips/communicate-between-components.html

For communication between two components that don’t have a parent-child relationship, you can set up your own global event system. Subscribe to events in componentDidMount(), unsubscribe in componentWillUnmount(), and call setState() when you receive an event.

親子関係にない、2つのコンポーネントを連携させる場合は、
自前のグローバルのイベントシステムをセットアップしたら良い。
各イベントをcomponentDidMount()で、Subscribeし、
componentWillUnmount()で、unsubscribeし、
イベント通知があれば、 setState()を呼び出すようにする。

という、TIPSをその通りに(結果的に)やっています。
別に、このTIPSの指示どおりなぞった、ということではなく、論理的にこうなります。
componentDidMount(), unsubscribeについては別に必須ではないので省略しています。

このコードは、Timerコンポーネントがひとつしかないので、
このFRPアプローチのメリットが今ひとつ明白ではないかもしれませんが、

親子関係にない、2つのコンポーネントを連携させる場合

あるいは、それ以上の複数のコンポーネントが複雑に絡み合う場合であっても、
極めて見通しのよい宣言型のコードがかけます。

【解法3】が抱える問題、

  1. これは根本的に、【解法1】の2つ目と同じアプローチであり、命令型である。
  2. コンポーネントの階層(Component Hierarchy)において、トップ・ルートコンポーネントから、末端のコンポーネントに至るまで、すべてのコンポーネントで、逐一、もれなくpropsを流さなければならない。つまり、各部品たるコンポーネントが、常に全体の情報を扱っていることになり、これは関心が分離されているべき部品、コンポーネントのあり方として本末転倒である。

が解決されています。

【解法5】関数型・リアクティブ・プログラミング(Functional Reactive Programming/FRP)のコンポーネントをReactに別途適用する、宣言型 setState不要メソッド

ここまで,
Communicate Between Components
https://facebook.github.io/react/tips/communicate-between-components.html

For communication between two components that don’t have a parent-child relationship, you can set up your own global event system. Subscribe to events in componentDidMount(), unsubscribe in componentWillUnmount(), and call setState() when you receive an event.

親子関係にない、2つのコンポーネントを連携させる場合は、
自前のグローバルのイベントシステムをセットアップしたら良い。
各イベントをcomponentDidMount()で、Subscribeし、
componentWillUnmount()で、unsubscribeし、
イベント通知があれば、 setState()を呼び出すようにする。

という、TIPSをその通りに(結果的に)論理的にやった、わけですが、
なんとも、気持ちが悪い、納得がいかないのが、

 getInitialState: function()
  {
    return {secondsElapsed: null};
  },

と初期化されて用意されている、Reactコンポーネントのstate変数の存在です。
これは、worldcomponentのFRPの値とは、別途存在しています。

これは本当に必要なのか?

そもそも、Reactコンポーネントのstate
というより、FRPの理論的には変化しないイミュータブルな定数なのですが、
これ自体がReactのイベントシステムであって。
Reactコンポーネントの再描画renderをトリガーする仕組みです。

しかし、今や、自前のグローバルのイベントシステムである、
worldcomponentがあるので、React内部で、イベント通知の仕事をまたやってもらう必要はありません。
二度手間ですし、コードもその分無駄に書かなければいけません。
自明的に、再描画renderをトリガーすればよいです。

実際そのためのforceUpdateという、APIは用意されています。
https://facebook.github.io/react/docs/component-api.html

forceUpdate

forceUpdate([function callback])

If your render() method reads from something other than this.props or this.state, you’ll need to tell React when it needs to re-run render() by calling forceUpdate(). You’ll also need to call forceUpdate() if you mutate this.state directly.

Calling forceUpdate() will cause render() to be called on the component, skipping shouldComponentUpdate(). This will trigger the normal lifecycle methods for child components, including the shouldComponentUpdate() method of each child. React will still only update the DOM if the markup changes.

Normally you should try to avoid all uses of forceUpdate() and only read from this.props and this.state in render(). This makes your application much simpler and more efficient.

自前のこのようなFRPを適用しない場合は、
ReactコンポーネントのstateのFRP機構に依存しており、それで事足りるわけで、
その場合、このAPIは使う必要性はまったくありませんし、使うべきではないでしょう。

しかし、上述のとおり、自前のFRPを適用した場合、
ReactコンポーネントのstateのFRP機構はもはやまったく必要なくなるので、
forceUpdateを使ったほうがコンポーネントの設計がかなり簡潔になります。

これは、要するにどういうことか?
もうReactコンポーネントのstateの出る幕はなくなった、ということです。

上記、APIドキュメントでも、normal lifecycleがトリガーされる、ということが説明されており、パフォーマンスもなんでも一緒です。
Reactのメリットは一切失われることなく、ただ設計の重複した要素の冗長さが排除され、
コードが簡潔に見通しが良くなります。

もちろん、propsstateの「使い分け」ということを考える必要もなくなりました。

worldcomponentが司るFRP機構によってModelをイミュータブルに管理し、
reactでは、ただpropsだけを使って、物理的なUI=Viewをイミュータブルに構成する。

それが筆者のReactの”Best Practice”です。

Reactの公式サイトのサンプルコード
https://facebook.github.io/react/index.html
A Stateful Component
を筆者のReactの”Best Practice”で置き換えるコードは以下です。

//worldcomponent the tiny FRP
//copy-pasted here, available in npm-------------
//-----------------------------------------
var ___ = worldcomponent;
___.world = ___.log('start!'); //debug log

var ___time = ___(0);

var f = function()
{
  ___.world = ___time.appear(___time.now() + 1);
};
var timer = setInterval(f, 1000);

var Timer = React.createClass(
{
  componentDidMount: function()
  {
    var com = this;
    ___.world = ___time.compute(function(x)
    {
        com.forceUpdate();
    });
  },
  render: function()
  {
    var el = (<div>Seconds Elapsed: {___time.now()}</div>);
    return el;
  }
});

var TopComponent = React.render(<Timer/>, document.body);

Click Counter

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

ライブデモ

 ↑ このブログ上で実際に動作します。

各グレーの「カード」をクリックすると、
Localのクリック数、Totalしたクリック数がカウントアップされます。

そして、前回の
【静的HTML編】の一番最後のコードが、ベースになっています。
ChildrenComponentなど、よく見比べてみてください。

コンポーネントの意味として、ChildrenComponentは、
前回、【静的HTML編】の一番最後のコードと同様に、
単に、物理的なUIのコンテナの意味しかありません。

【解法3】のアプローチでやると、
最上層から最下層(末端のカードのコンポーネント)に至るまで、
すべての階層のコンポーネントで、
すべてのprop引数をリレーしてやらなければ、
グローバルで管理しているデータが届かないので、
単に、物理的なUIのコンテナの意味しかない、ChildrenComponentにも、
すべてのprop引数を渡して、その子コンポーネントである、
ChildComponentにさらに、prop引数を渡す、という設計とせねばなりません。

しかし、この【解法5】(【解法4】もそう)では、直接グローバルで管理している、
worldcomponentの値にFRPでSubscribe=computeしているので、その必要はありません。

各UIの物理的な階層関係と、各UIデータの結びつきの構造は、別構造なので、
FRPをもってして、このように分離して設計すべきです。

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:"150px",height:"150px",
                    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.body);

GitHubレポジトリ

【静的HTML編】から通して、
すべてのソースコードは以下にあります。

https://github.com/kenokabe/react-abc

Powered by Blogger.

Popular Posts