まず、多くの方に本書をお買い上げいただきましてお礼申し上げます。
このブログエントリで、反応して「戒める」と、ちょっとはネガキャン勢力も「反省」するのか、少しずつですが、著書のAmazonレビューが「マシ」になってきているようです。
ただし、現状☆１をつけているレビューは、以下に取り上げる直近のものを含めすべて「不正なノイズ」であり、賛否の「否」にカウントできるものはひとつもありません。
ここで書けば徐々にですが「マシ」になってくるようなので、あくまで
「どうしたらまともな技術論になり、
広い技術者、読者、初心者の役にたつレベルにまで達するのか？」
簡単な要件を筆者として示したいと思います。
要件はたった２つ。
１．技術論に色を付けない
２．嘘を書かない
たったこれだけです。
１．技術論に色を付けない
というのは、前回も書いたとおり、くだらないヘイト、誹謗中傷、個人攻撃、人格攻撃と、書籍の技術的内容をごっちゃまぜにして論じないこと。
そして、以前書いたとおり、自分が使用するプログラミング言語、あるいはオブジェクト指向的マルチパラダイムの嗜好をもって、いい加減な権威主義による宗教的より好みをあたかも一般的説明、あるいは絶対的真理がごとくみせかけない、こと。
関数型プログラミングとQiita界隈の騒動について
関数型プログラミングとオブジェクト指向のパラダイムとしての対立 国内の【自称】関数型コミュニティと海外の論調の違い
２．嘘を書かない
という要件を満たしてない以下の具体的なレビューで説明します。
以下のレビューは、嘘まみれなので、「不正なノイズ」と分類されます。
114 人中、112人の方が、｢このレビューが参考になった｣と投票しています。
5つ星のうち 1.0
タダでも読む必要のない（というより読むべきではない）書籍, 2015/4/28
投稿者 Kamuichikap本書の技術的内容は質的にも量的にもその7割が「0から9までの数をすべて足すコードを書け」ということに尽きています。後はFacebook-ReactライブラリのサンプルコードとFRPの拙劣な説明です。3～4行を超えるコード片は殆ど出てきません（そしてその多くが繰り返しです）。したがって、関数型プログラミング自体に興味のある読者にとって本書の内容はほぼ
[0,1,2,3,4,5,6,7,8,9]
.reduce(plus); //をすべて足すというものに尽きています。しかし、この説明は整数の加法がたまたま交換法則・結合法則を満たしているから成り立つように見えるにすぎません。reduce(f)を適用する際に、配列の最初の要素は関数fの第一引数の型を持たねばならず残りの要素は第二引数の型を持たなければなりませんからこの配列は本質的にヘテロジニアスなものですし、左畳込(いわゆるfoldl)と右畳込(foldr)の違いを考えれば、結局は関数fの適用順と蓄積の経過を理解しなければfoldを理解したことにはなりません。本書の説明は一見わかりやすく見えるのですが、結局は本質的な理解を妨げるものであると思います。また著者はreduce関数やrange関数やmap関数を命令型のループでしか書けないとしていますが（たとえばpp. 88,96,106）、これは明らかに誤りですし本書の目的からすれば関数型で書いてみせるべきものです。それでは効率が悪いように見えるかもしれませんが、それが本来の関数型のプログラミングスタイルですし、それが非効率になるのは関数型プログラミングを支援するように設計されていないJavaScriptという言語の問題であって、とりもなおさず関数型プログラミングの説明を本書のようにJavaScriptでしようとすることが最初から不適切な選択であることを示しています。
FRPの説明もごく拙劣です。状態を持った手続きは引数で状態を持ち回すようにすることによって純粋な関数にできる、という関数型プログラミングの基本的な技法を、その最も基本的な原理を説明せずに（或いはことによると理解せずに）、特殊事例について述べているに過ぎません。根本的には、時間による値の変化は時間から値への関数として表現でき、イベントによる値の変化は、値とイベントから値への関数として表現できる、というだけのことですが（簡単ですが重要な点ではあります）、そうした本質的な説明はなされずに、ひたすら著者の不明瞭な思弁が垂れ流されるだけです。また著者が、参照透過性や遅延評価やその他の関数型プログラミングにまつわる様々な概念を混同し或いは不当に同一視しているために、それらの記述を鵜呑みにしてしまえば読者は誤ったないし混乱した理解を得てしまうように思います。
また、著者は命令型言語での「n=n+1」のようなステートメントを「論理破綻」だと主張しています（pp.144-5）。また右辺と左辺で変数nが違う時間に属しているとしていますが、この珍妙な主張は著者が左辺値と右辺値という基本的な概念を理解していないことから生じています。そもそも「n=n+1」は数式ではなく各言語がそれぞれに意味を与えているものなので、数式として論理破綻していると言われても困るでしょう。問題は、著者が命令型プログラミングの基本を（そして恐らく関数型プログラミングの基本も）理解しないままに、それを口を極めて非難していることにあります。
本書の過半を占める、その意味が定義されたり説明されることの決してない著者の独自の「論理」や「計算」という語の用法とそれに基づいた大量の思弁は、おそらく殆どの読者にとって（技術的意義はもとより）そもそも意味をなさないナンセンスですし、たとえばp.238以降展開されるような哲学者や自由意志論への言及は単純に思想史上の問題としても誤解に基づいたものに過ぎません（そのついでにアラン・ケイやガリレオやデカルトを気取られたりするとどういう顔をして読めばいいのかもわかりませんが）。
最後に、もし本書を（ネタではなく）本当に読もうと思った人がいれば、本書ではなく浅井健一『プログラミングの基礎』サイエンス社(2007)と大川徳之『関数プログラミング実践入門』技術評論社(2014)などを読めば、金と時間をムダにせずに済みます
まず前提ですが、
最初の
114 人中、112人の方が、｢このレビューが参考になった｣と投票しています。
というのは、「嘘」です。
別の、☆５のレビュアも指摘していますが、ごくごく短時間に、
評価が高いレビューは「参考にならなかった」
評価が低いレビューは「参考になった」
とボタンを押しまくる「キャンペーン」か何かやっているのでしょう。
それは事前に想定されていた彼らの行動パターンでした。
まずまず内輪ではこのような「不正行為」を「世直しだ」などと言いながら、
対外的には「被害妄想だ」というのがこういう、先のエントリでも説明した連中の行動パターンです。
次に、この投稿者のkamuichikap氏ですが、
もちろん、私は知っています。
Qiitaで、
関数、値、圏論、モナド、評価戦略、純粋関数型、その辺りの「数学的基礎」について書いた記事で、私になんか書いてきた人です。
よくわからないですが、こういう人は「一方的に私に恨みのようなものを持っている」らしく、そういう腹いせを、嘘までついて、こういう著書をこき下ろすレビューでするのはアンフェアだと思うわけですが、いずれにせよ、何がなんでも機会をみてその恨みを晴らそうとするみたいです。
Kamuichikap氏は、私がこのブログで「技術的反論など何一つ見受けられない」とあしらったことを受けて、「ようしそれなら自分が」とでも思ったのでしょうか？
上記引用したAmazonレビューをされました。
読ませていただきましたが、怨恨から嘘をついてこき下ろすことしかやっていないわけで、論外です。
繰り返します。現状、「技術的反論など何一つ見受けられない」。
嘘まみれなので、「不正なノイズ」と分類されます。
本書の技術的内容は質的にも量的にもその7割が「0から9までの数をすべて足すコードを書け」ということに尽きています。後はFacebook-ReactライブラリのサンプルコードとFRPの拙劣な説明です。3～4行を超えるコード片は殆ど出てきません（そしてその多くが繰り返しです）。したがって、関数型プログラミング自体に興味のある読者にとって本書の内容はほぼ
[0,1,2,3,4,5,6,7,8,9]
.reduce(plus); //をすべて足すというものに尽きています。
嘘です。
本書を読めば、これが嘘であると誰でもわかるでしょう。
まず、私は、フックのDay1、
そして、関数型ライブラリの概念を導入する、Day２、
そして、遅延評価の概念を導入する、Day３、
で、
「0から9までの数をすべて足すコードを書け」
という例題を繰り返しました。
それは、この極めてシンプルな例題をもって、違う角度から、別の技術的概念を解説するためです。
普通、別の技術的概念を解説するときには、別の例題に切り替えたくなりますが、
私はあえて、この極めてシンプルな例題をもって、同じ例題であっても、別の技術的な切り口で、それはこれこれこのようになる、と示すように構築しました。
同じ例題なので、違う技術を対比的に考えることができます。
これはひとつの芸当であり、非常に熟慮と工夫と手間と時間の要する作業でした。
後はFacebook-ReactライブラリのサンプルコードとFRPの拙劣な説明です。3～4行を超えるコード片は殆ど出てきません（そしてその多くが繰り返しです）。
嘘です。これも本書が手元にあれば誰でも、この記述が嘘であることは用意に確認できることでしょう。
パラパラめくっただけで、「3～4行を超えるコード片は殆ど出てこない」というのが虚偽が真実かくらい、数秒で判別できます。
買った人には、嘘はバレても仕方がない、関係ないが、とにかくこれから買う人には嘘でもなんでもネガキャンしてやろう、っていうことなんでしょうか？正直なんでこんな誰でも確認できる嘘をつくのか意味がわかりません。
3-4行以内で、Node.jsや、Reactのコードが説明できるわけがありません。
それは、このブログの著書サポートページ、
React (.js Facebook)解説 関数型プログラミングに目覚めた！ IQ145の女子高生の先輩から受けた特訓５日間 サポート記事 静的HTML編についても、どなたでも閲覧して確認することができるでしょう。
私は、3～4行を超えるコード片は殆ど出てこない、拙劣な説明でお茶を濁すような仕事はしていません。
しかし、この説明は整数の加法がたまたま交換法則・結合法則を満たしているから成り立つように見えるにすぎません。reduce(f)を適用する際に、配列の最初の要素は関数fの第一引数の型を持たねばならず残りの要素は第二引数の型を持たなければなりませんからこの配列は本質的にヘテロジニアスなものですし、左畳込(いわゆるfoldl)と右畳込(foldr)の違いを考えれば、結局は関数fの適用順と蓄積の経過を理解しなければfoldを理解したことにはなりません。本書の説明は一見わかりやすく見えるのですが、結局は本質的な理解を妨げるものであると思います。
一見、難しいことを書いており、まるで正しい技術的な批判をしているように、みえるでしょう。
このブログでは、まさにこのDay1の章で、「本質的理解」を促す解説を無料公開しているので、広い読者は読み比べてみれば良い、それで明らかだ、と思いますが、上記の文章で、
「よし！関数型プログラミングの本質的な理解が促進された！」
「関数型プログラミングって便利そうだ！魅力的なのでやってみよう！」
と思う読者が果たしてどのくらいいるでしょうか？
「ヘテロジニアス」？もちろんググったら誰でも意味はわかるでしょう。
しかし、こういう無意味に難解な言葉をもってくるのは、
ただ単に自分を賢く見せようとしているだけで、相手に理解させようとする気持ちなんてない、
「本質的な理解」なんてこれっぽっちも気にしていない証拠です。
本当にこういう真似をする人は多いです。
相手の理解のための言葉遣い＜＜＜＜自分を賢く見せる言葉遣い
なんですね。
「ものごとを説明すること」「解説すること」には説明者、解説者にとってリスクがあります。
間違いを指摘されて馬鹿にされるリスク、馬鹿に見えるリスク、それをだいたいすべての人は怖れます。どう防御するか？っていうと、「ヘテロジニアス」みたいな初心者がわからなくて当然の言葉で、理解のハードルをあげちゃうんですね。相手が理解できない限り、自分は少なくとも馬鹿にはみえないから。
それで、種明かしをすると、私は、Day1では、関数型プログラミングの概略を凝縮して解説したのです。読者に一番最初に、ざっくりとした、まとまり（集合）、論理操作の話をしているところに、個別具体的な関数である、reduce(f)の「具体的特性」について、交換法則・結合法則だの「ヘテロジニアス」だの解説するのは、愚かな説明な仕方です。なぜならば、それは関数型プログラミングの概略の「本質」ではありえないからです。「具体的特性」とは「具体的」であり「本質」ではありません。誰でもすぐにわかることですね。
そういう愚かな解説本は私は書かなかった、一方でこの人は、そういう愚かな解説の仕方が良い、そういう本のほうが良いと言っているのですね。
そして私は実際に、このreduce(f)の「具体的特性」については、Qiitaでの貴重なフィードバックから重要性を認識していました。その結果どうしたか？というと、Day2で事細かく説明したのです。
それはフックのDay1で詳細に踏み込んで書くべき内容ではなく、きちんとレベルを分けて書くという手法をとっています。
以上の事実は、Day2読めば、わかることなんですね。購入していただいた人は確認できることでしょう。この人は「嘘」を書いているわけです。
また著者はreduce関数やrange関数やmap関数を命令型のループでしか書けないとしていますが（たとえばpp. 88,96,106）、これは明らかに誤りですし本書の目的からすれば関数型で書いてみせるべきものです。それでは効率が悪いように見えるかもしれませんが、それが本来の関数型のプログラミングスタイルですし、それが非効率になるのは関数型プログラミングを支援するように設計されていないJavaScriptという言語の問題であって、とりもなおさず関数型プログラミングの説明を本書のようにJavaScriptでしようとすることが最初から不適切な選択であることを示しています。
当たり前のことで、繰り返しますが、
reduce関数やrange関数やmap関数は、命令型のループでしか書けません。
なぜならば、ノイマン型コンピュータというハードウェアは究極的には命令型でしか動作しないからです。関数型の機械語なんて存在しません。
関数型プログラミングを支援するように設計されていないJavaScriptという言語の問題であって、とりもなおさず関数型プログラミングの説明を本書のようにJavaScriptでしようとすることが最初から不適切な選択であることを示しています。
あのですね。JavaScriptであっても、関数ライブラリを使えば、それは「関数型プログラミングを支援するように設計された」レイヤを整えることができます。
Day2(pp. 88,96,106）では、上記のreduce含め、この人の言葉を流用すると「関数fの適用順と蓄積の経過を理解」してもらうために、命令型のループをもって「車輪の再発明」の作業をやっているのです。
そして、「関数型プログラミングを支援するように設計」ってのは、ネイティブな言語仕様レベルで、その関数ライブラリが最初から、根本では命令型のコードをもって実装されているってことに過ぎないでしょう？
ただそれだけの違いです。
言ってることが、デタラメというか嘘だらけです。
FRPの説明もごく拙劣です。状態を持った手続きは引数で状態を持ち回すようにすることによって純粋な関数にできる、という関数型プログラミングの基本的な技法を、その最も基本的な原理を説明せずに（或いはことによると理解せずに）、特殊事例について述べているに過ぎません。根本的には、時間による値の変化は時間から値への関数として表現でき、イベントによる値の変化は、値とイベントから値への関数として表現できる、というだけのことですが（簡単ですが重要な点ではあります）、そうした本質的な説明はなされずに、ひたすら著者の不明瞭な思弁が垂れ流されるだけです。また著者が、参照透過性や遅延評価やその他の関数型プログラミングにまつわる様々な概念を混同し或いは不当に同一視しているために、それらの記述を鵜呑みにしてしまえば読者は誤ったないし混乱した理解を得てしまうように思います。
嘘です。
「拙劣」「拙劣」と繰り返したいだけなのか知りませんが、内容は嘘です。
本書では、他の日本語で出回っているどの書籍よりも、根本から関数型プログラミングとFRPの関係性について踏み込んで解説しています。
根本的には、時間による値の変化は時間から値への関数として表現でき、イベントによる値の変化は、値とイベントから値への関数として表現できる、というだけのことですが（簡単ですが重要な点ではあります）、そうした本質的な説明はなされず
この「根本」のところを、いかにして、しつこいくらいに解説しているのか？本書が手元にある読者は誰でも容易に確認できるでしょう。
また著者が、参照透過性や遅延評価やその他の関数型プログラミングにまつわる様々な概念を混同し或いは不当に同一視しているために、それらの記述を鵜呑みにしてしまえば読者は誤ったないし混乱した理解を得てしまうように思います。
「不当に同一視」。違います。
様々な概念の根底で共通する概念を見通しよく整理する作業を「不当に同一視」という表現はしません。この人自身が、どのように学習されたのかは存じ上げないし、その世界観を維持して、本書の解説を拒否するのも構わない。しかし、まるで自分の見方が、唯一無比のように絶対視して、
「不当に同一視」だの、
「鵜呑みにしてしまえば読者は誤ったないし混乱した理解を得てしまう」
だの侮辱していただきたくはない。これはこのブログで以前も書いたことです。
また、著者は命令型言語での「n=n+1」のようなステートメントを「論理破綻」だと主張しています（pp.144-5）。また右辺と左辺で変数nが違う時間に属しているとしていますが、この珍妙な主張は著者が左辺値と右辺値という基本的な概念を理解していないことから生じています。そもそも「n=n+1」は数式ではなく各言語がそれぞれに意味を与えているものなので、数式として論理破綻していると言われても困るでしょう。問題は、著者が命令型プログラミングの基本を（そして恐らく関数型プログラミングの基本も）理解しないままに、それを口を極めて非難していることにあります。
嘘です。
この珍妙な主張は著者が左辺値と右辺値という基本的な概念を理解していないことから生じています。
そもそも「n=n+1」は数式ではなく各言語がそれぞれに意味を与えているものなので、数式として論理破綻していると言われても困るでしょう。
これは「破壊的代入」という「意味」を解説、導入する際の枕の部分です。
あくまで、「破壊的代入」とはその名のとおり、論理を破壊する代入であると明示するために、
「n=n+1」のようなステートメントを「論理破綻」だと主張、ではなく、「正しく解説」したのです。
問題は、著者が命令型プログラミングの基本を（そして恐らく関数型プログラミングの基本も）理解しないままに、それを口を極めて非難していることにあります。
命令形プログラミングと関数型プログラミングの対比は、Day2でみっちりと説明しており、著者であり解説者である私自身が、理解しているのか？していないのか？それは読めば、「こういう人以外は」誰でもわかることでしょう。
本書の過半を占める、その意味が定義されたり説明されることの決してない著者の独自の「論理」や「計算」という語の用法とそれに基づいた大量の思弁は、おそらく殆どの読者にとって（技術的意義はもとより）そもそも意味をなさないナンセンスですし、たとえばp.238以降展開されるような哲学者や自由意志論への言及は単純に思想史上の問題としても誤解に基づいたものに過ぎません（そのついでにアラン・ケイやガリレオやデカルトを気取られたりするとどういう顔をして読めばいいのかもわかりませんが）。
問題はここですね。
「論理」や「計算」という語の用法とそれに基づいた大量の思弁。
これが本書のエッセンスです。
エッセンスをナンセンスだと感じるのであれば、たしかにどうしようもないでしょう。
そして、この「論理」や「計算」の関係性については、
私は誰よりもわかりやすく本書で解説している自負があります。
あと、哲学ですが、「誤解に基づいたものに過ぎません」とか、もう
「拙劣」「不当に同一視」「ナンセンス」「誤解」「理解していない」ととにかく、侮辱するための、まさに「ワードサラダ」（こういうときに使うのが適切）の最後のピースを揃えただけに見えます。
最後に、もし本書を（ネタではなく）本当に読もうと思った人がいれば、本書ではなく浅井健一『プログラミングの基礎』サイエンス社(2007)と大川徳之『関数プログラミング実践入門』技術評論社(2014)などを読めば、金と時間をムダにせずに済みます
ああまだワードサラダの最後のピースが残っていました。
「ネタ」「金と時間をムダにせずに済みます」ですね。
この一連の侮辱行為の原動力はただひとつ、
「事実に基づかない」「誰でも本みたらすぐバレる」「嘘」です。
最後に、唯一、嘘でない建設的な提案が提示されました。
ある本を推奨する、という行為です。
いつかどこかで、またよく見る光景ですが、これ自体は唯一褒められる行為です。
もちろん、その根底には、恨みつらみかなんか知りませんが、
嘘まで並べ立てて本書をこき下ろすためのろくでもない意図があるわけですが。
さて、いったいいつになったら、私は「不正なノイズ」ではない、まともな「批判」レビューを見ることができて、建設的な技術的論議ができるのでしょうか？
0 コメント:
コメントを投稿