Quoraでの「関数型プログラミングが『銀の弾丸』であるという非常識な常識 2022」の書評
2021年末に基本フリーで誰でも読める形で関数型プログラミングの入門書をUPした。構想だけしてたりトライアンドエラーでゼロから書き直したりする時間全部ひっくるめると2年ほどかかった。かなりの長編ではある。
関数型プログラミングが『銀の弾丸』であるという非常識な常識2022
さて、
というのは、僕がQuoraでそこそこ熱心に活動していた頃に、Quora日本語版の運営からの要請を受けて、「Quoraスペース」のアルファ版の一環として僕がオーナーとしてQuora日本語版の最初の最初のプログラミングスペースとして立ち上げたものだ。
僕はもう昔から人にものを教える、伝達するという行為が好きで、QuoraというQAのSNSは性に合っていたし、そこそこの認知や評価もいただけていたとは思う。
最終的には、ウイグル人権問題が問題になりだした少なくともSNSレベルでは黎明期に、ひたすら中国共産党の代弁者みたいな中国人と揉めた結果BANされたわけだが、別にそれによって自分の政治的主張というか、単に想像を絶するレベルの人類への犯行についての批判、今、折しも北京五輪ボイコットで問題となっていることや、ましてやプログラミングの考え方が誤っていたからBANされたわけでもなんでもない。
このスペースは、なるだけわかりやすく初学者の皆さんへ向けてプログラミングの魅力を伝えられたらなという、自分が教えるのが好きというライフワークの一環として立ち上げたものでもある。
Quoraをやっていたころから多少関数型プログラミングに関するお話をしていて、僕の個人スペースなどもフォローしてくださっていた宮西さんという方が、今回の僕の著作を、この僕が立ち上げたプログラミングスペースで好意的に紹介してくださった。
すると、
まあ、毎度のパターンです。
必ずこういう輩が「電光石火」の如くネガティブなコメントを投下する。
なんでSNSってこういう人様への人身攻撃についてだけはこれだけ素早く熱心なんでしょうかね？
QuoraでアカウントBAN食らったのは、上述のとおりだし、曲がりになりにも自分で書いてもいる。
その他SNSについては、今回はてなに作ったこのブログエントリでも書いた。
2chの頃から続いているスレっていうのは、僕は刑事告訴した誹謗中傷スレッドだけど、この人物は、そのスレを半ば肯定的に紹介している時点で、まあしょせんはそういう人だ、というのはわかる。
というか、実際その刑事告訴した誹謗中傷スレに
スエナガって名前を見るんだよね。
どんな人物なんだろう？とQuoraのプロフィールを見たけど正体不明。まあ2chの誹謗中傷スレ関係者なんで当然だろう。本名かどうかも怪しい。
もちろん、自分がこの人を調べたらどうか？と訳知り顔に書き込んでるスペースが僕がアルファバージョンの頃に立ち上げたスペースだってことも知らない新参なんだろうし、書き込んでる人が僕のQuora時代からの知友ってことも知らないんだろう。
関数型プログラミングに目覚めた!IQ145の女子高校生の先輩から受けた特訓5日間
については、2015年の仕事だが、ES6以前のコードだし、なるだけ専門用語を使わずに概念だけを物語形式に埋め込んで解説しようとしたけど、用語の正確性についてはたしかに大切だし、自分自身満足した仕事か？と問われると反省点は非常に多かった。
そのためにも今回の著作があるわけである。自身の至らなかった部分も統合的に解説できるようになったし、なによりES６とTypeScriptの恩恵が非常に大きい。
それでも当該Amazon評価では、
そんなにわるくもない。そこそこの母数でそこそこの賛否両論と言える以上の評価だと思う。この人物がいうように★１レビューが目立つのは、とりもなおさず、こういう電光石火で人様の書いたものや人物を刑事告訴までした反社会的な２chスレすら肯定的に扱うような誹謗中傷好きの人間がアンチ活動に懸命だからだ。
実際に、良心的なレビューでは、
という感じ。ありがたいことである。
世の中とは、悪意に満ちた人間と、良心的な人間、前者はSNS時代の今、社会問題にもなっているが、こういう実名（かどうか怪しい）顔出し（かどうかもわからない）正体不明の人間でも恥ずかしげもなく一生懸命やっているということなのだろう。
QuoraというSNSは僕は政治案件でウイグル人権侵害を正当化する工作員みたいな中国人との喧嘩で最終的にBANされてしまったけど、誹謗中傷という点ではSNSのなかでも非常に気を配っていて安全な場所だと思う。
BNBR(BeNiceBeRespectful)というポリシーがあって、いくらBANされたユーザだろうが、こういう悪意に満ちた評判を貶めるような真似は控えるべき場所だ。
僕がまだ有効なアカウントがあれば、この、末永という正体不明の人物についてはBNBR違反として通報するだろうし、彼のこのろくでもない書き込みについては削除されることは確実である。
これに関連して、Quoraが比較的良心的なSNSであることは、そもそも僕が立ち上げたスペースに、知友が親切に紹介コメントをアップしてくれたこともそうだし、末永というろくでもない人物についてはそれなりに反論コメントが自然とつく、ということだろう。世の中悪いことばかりではない、というのが示されるのがQuoraの良心性をうかがわせる。
こちらの方は末永氏とちがって正体不明ではなく社会的属性も確認できる。
僕は実際にこういうブログエントリは書くような人間なので、人格批評はご自由に、といったところだが、大枠として、この人は反論を先人切ってやってくれた。その心意気についてはまず感謝申し上げたい。
ただし、「内容はそれなりに筋は通っており、まったくの間違いという事はないです。」
というのは、「まったくの間違い」からの否定と評価を限定的にする以上、また「それなりに筋は通っている」というのは、もし何かおかしいところがあれば、きちんと明示すべきだと考える。
「この解説から入って、さらに勉強を深めていく分には何ら問題ない教材と思いますよ。」
というのであれば、せいぜい「まったくの間違いという事はない」というような教材は甚だ不十分だと思うし、あえて反論のようなことをすると、
自分が実用性を求めて関数型プログラミングをするにあたり、このレベル以上に「更に勉強を深めていく分」というのはほぼほぼ存在しない。
やるのもちろん自由だが、せいぜい圏論がどうとかの分野で理論的基礎については、これでカバーできるように書いた自負がある。
むしろ、巷で理不尽によく引用されているモナドの説明が、IOモナド専用の説明であることがほとんどである、というかなりデタラメな状況について、ほぼ誰も何も言わないというかなり異常な状況こそが批判されるべきものであって、ここまでギリギリまで本質部分を切り込んだ文献はまず見当たらなかったので自分がはじめて書いたような感覚で、それこそが執筆のモティベーションでもあった。
正体不明の末永氏はくいさがる。
読む価値はあるよ。
というかなんで、どこの馬の骨とかもわからない数学愛好者の中級者の書きなぐりが「指摘」として「正しい」ということに自動的になっており、僕の反論が「読む価値は・・・」みたいに漠然とした印象操作で終わってるんだろうね。
しかしよくも全部ネガキャン記事３本もぱっと出してくるものである。
僕は非常に不愉快で面倒くさいけども、「いつものごとくの反論」とか揶揄してるんだけども、こういう人間が近い将来こうやってネガキャン記事を耳揃えてだしてくるだろうと事前に予測していたから、結構面倒くさい気持ちも押し切って、「読者の良識」みたいなものは、こういうネガキャンの前では無力化されるから、著者本人として最低限でも反論を紐付けようとしたんだね。今こうやってこういうQuoraのネガキャンにたいして反論するのも、内心「くだらない」とウンザリしているが、同じようなネガキャン再生産の種として近い将来悪用されるにきまっているのでこうやって年末の朝方の生産性のたかい貴重な時間を割いて書いてるわけ。
僕は、
以下、このTwitterで「ネガキャンやるぞ」と決心した人間について、いかにトンデモかということをそれなりにハッキリとした証拠に基づいて論証したわけだけど、こういう人物については真実なんてどうでもよいのだろうし、なんでこの正体不明の末永という人物がトンデモ中級者による「間違い」の「指摘」とやらが無条件に正しいものとして受け入れているのかは、一切合理的な説明はない。
おそらくこんな人間に、正しい判断なんてできる知見なんて最初から存在しないのだとおもう。
少なくともここまで僕の著作について間違いだと断定するのならば、そのTweetの指摘がトンデモではなく正しいことを追証すべきだろうとおもう。
文脈より、ここの「反論」とは、ネガキャンやってる中級者によるレビューのことらしい。実際に彼らの僕の著作への論評なんぞ「たいした内容じゃない」し「言いがかりをしたい人が重箱の隅をつついている程度」であるのはそのとおりだ。
まさに、僕がそれこそ各記事のコメント欄で地道にこういうブログエントリのような「反論」をひもづけていることもきっと役立っているだろう。
伝わっているようであれば嬉しいことではある。
これに喚起されたのがさらに良心的なコメント。
以下、それなりにしっかりとした知見のある方だとわかるし、末永氏のように正体不明でもなく、社会的属性がしっかりと確認できる。
なにより購入していただいた、と著作の価値を認めていただいたことに感謝申し上げたい。どうもありがとうございます。
>圏論に関しては結構丁寧に説明して有るのですが、私的にはモノイドについてもっと言及して欲しかったです。
モノイドについては、圏論の範囲で論証するのは大変面白いのですが、かんたんなことではないのは巷の文献からみても明らかです。
圏論におけるモノイドというのはかんたんではありませんが、実際本書ではそこそこ分量を使ってモノイドの性質についてはあくまで小学校から学ぶ＋やらの二項演算の代数学の範囲で説明していますし、それで十二分だとおもっています。
>実際モナドの連鎖は同一の型のモナド間でしか行えないのは、このモノイドの特性に由来しているのではと思っています。
これはFunctorの章で説明もしていますが、そのとおりです。
>（勉強中なので断言ができるレベルには至っていません。関数合成は受け渡しを行う関数の間で値が一致していればOK）
値ではなく型（Type）の一致です。
関数適用の演算子はパイプラインオペレータで、これはIdentityFunctor=IdentityMonad
であるので、当然型（Type）の一致が必要で、
より複雑な構造をもつ
MapFunctorでも同じように型（Type）の一致、この場合ではArray[] ですが、一致しています。
ただし、IdentityFunctor=Monadと同じレベルで自由に合成はできないので、
flatMapFunctorにすることで、= flatMapMonadで、identityMonad=パイプライン演算 と同等の自由度が獲得されます。
>、Javascriptでは自然な形でカーリー化ができないので、どうしても無理やり感が否めません。f x y = x + y に f 1 を投入して普通に y を引数とする y + 1 の関数を返す事が出来ません。コードを作成して対応は出来ますが、引数の数が変わる度にコードを書き換える必要が出てきます。それに無限配列が使えないのは意外と地味に不便で、演算開始段階で明確な終了条件が決定出来ない場合のカウンターとして使用できません。λ計算で有名なYコンビネーターも同様にそのままでは実現出来ません。実務で使う場合にはこれらが無くても問題は無いのですが、関数型プログラミングを学習しようとすると物足りない感があります。という事で、しっかりした？関数型プログラミングを学習するには、今一つ感が拭えないのが正直な所です。
これについては何が問題とされているのか対象がよくわかりません。
JavaScriptでもHaskell同様にunaryFunctonでのカリー化した扱いは同等にできるので、JavaScriptの自然なカリー化
f x y = x +y
というのは
f = x => y => x + y
となるだけですね。
おそらくHaskellでは
JavaScriptでいうところの
f(x,y) = が自然と
f x y と暗黙unaryFunctionのカリー化記法ができる、ということをおっしゃってるのでしょうが、この記法の違いはHaskellは簡潔さですぐれいるがJSのアロー記法でもさほど問題なく、本質的な違いは生まれないと思いますが。
>関数型プログラミングでは有りませんが、関数型言語の説明は以下のページが自分的には、一番しっくりきたのでアドレスを張っておきます。11. 関数型言語 - プログラミング言語論 ドキュメント
については、自分は全く評価しません。
これまでこの手の関数型プログラミングの説明を山ほど読んできましたが、それによって、自分が今回著作としてまとめたような概念は手に入らなかったし、具体的にどういうのが関数型コードか、ということがわかったことはありませんでした。
たとえば、二項演算を著作では一貫して強調していますが、Haskellのモナド則にしろ、あれはすべて二項演算で表記されています。
圏論でいえば集合の圏の範囲だけが、射は関数に、対象は集合となるので、関数型コードの範囲となるので、モナドは二項演算になるのが当たり前で、二項演算とは、二項関数のことにほかなりません。
という二項演算であるのは「誰の目にも明白な事実」なのですが、
モナドが二項演算であることは、まるで説明されていません。
なんででしょうか？僕には意味がわからないですし、誰も文句を言ってるようにも見えません。それどころか、
で引用したとおり、
FunctorとMonadは二項演算か？
誰がどう見ても、Haskellモナド則でも二項演算でしかない、Haskellのモナドについて、説明しているのを読んだ後か、読んでもいないのか知らないけれど、
Monadは二項演算か？
などと重ねて疑問を呈してきて何も感じない、平気ぽいのが、このHaskel界隈の現状で、僕はこれ病的なレベルだと思っています。
間違い
二項演算なのだから当然、二項演算子がある。
というのが正しい。
Monadについては「二項演算」だけじゃないだろって感じですが。
とか書いてるのは、この中級者による数学用語の使い方がデタラメで、この中級者は、
「二項演算」という代数構造がなんたるか全く理解できていないのは読めばわかることです。
こんなもんをもちあげる、しかも僕の著述、解説が間違いだと指摘していると公の場で発言できるということは、末永氏のことですが、同レベル以下であることが明白です。
恥ずかしくないのだろうか？というレベルです。
しかし実際にこういうトンデモが出回っているのがHaskell関数型界隈の病的な実情で、僕自身は、最初そういう言語界隈を無条件に信用していたので本当にひどい目にあいました。なんでも無いことを理解するのにとんでもない遠回りを強いられました。
同じ苦労を初学者の人々に味合わせるのは忍びないし、自分がわかったならちゃんとわかりやすく解説する義務責任があると一種の使命感をもって著作をかきあげたのです。
その行為については褒められても、
「内容はそれなりに筋は通っており、まったくの間違いという事はないです。」
「この解説から入って、さらに勉強を深めていく分には何ら問題ない教材と思いますよ。」
と書かれたとしても、君ら本当にわかってたのか？
わかってたらなんでこんな有様になっている？と疑念を呈さざるを得ません。
実際に、
に戻りますが、
参照透過性
というのは、別エントリで年内、今日にでも決着をつけるべきテーマなのですが、この概念によって関数型コードがわかるようにはなりません。
なぜならば、
１＋２＝３
とかいう小学校の頃から慣れ親しんでいる二項演算は、二項関数と等価であり、この式こそが関数型コードだ、みたいな説明こそが大事だからです。
自分が読んだ本、あるいはこういう持ち上げられている解説ページに、小学校の頃からやってる二項演算が関数型コードの式である、という単純明快な解説がなされているのをこれまで見たことがありません。
そして二項演算ってのは、数学の定義上、ここで言われる参照透過性があるわけですが、誰が、これまで二項演算やるのに、参照透過性が重要だ、みたいな教育を受けたことがあるのでしょうか？
１＋２＝３
という二項演算の式＝関数型コードのあり方を理解するためには
「参照透過性」とは完全に不要な用語です。
そしてこのページに不要に、それこそデタラメな定義というか定義もされておらず不要に使われている「その時点での状態」あるいは「変わらない」「変更してはいけない」
という言葉の使い回しこそが、本書で解説している「時間」に依存するグラフ構造、のことで、こっちのほうを、わけのわからない「参照透明性」をあたかもわかったように解説していることより、解説対象として注目すべきなのですが、解説してるつもりの張本人である書き手がおそらくそんなことは気にもとめていないので、このわけのわからない「参照透過性」という正体不明の用語が再生産されて拡散されています。ありがたがられるように。
11.4. モナド
についてもひどいものです。
モナドという二項演算の代数構造は、参照透過性という概念とは独立事象です。
たとえばパイプライン演算は、IdentityFunctor＝IdentityMonadですが、
1 |> plus(2) = 3
というのはモナドの二項演算ですが、参照透過性という概念とは関係ありません。
というより、二項演算という代数構造で参照透過じゃないものなんて存在しないのだが、そんな代物をもって、説明しよう、できると思ってる時点でかなり異常な世界なんですね。
参照透過？といわれたら、二項演算なんでそりゃ当たり前に参照透過だろう、と言い捨てるしかない、モナドという代数構造について、参照透過という概念でモナドを説明しようとしている。相当頭がおかしい世界なんですね。
で、僕がそういうことを書くと、なんか叩いてくる連中がいる。彼らには合理的な説明ができないのはご覧のとおりです。
当該ページを引用すると、
参照透過性は関数型言語の重要な性質だが、それでは困る場合もある。
-
乱数を使う場合。
randomが毎回同じ値を返しては乱数にならない。 -
入力を行う場合。例えばキーボードから一行入力する
getLineは、人間が入力した値を返すので、呼び出されるたびに違う値になる。
-
複数の出力を行う場合。例えば
putStrLn("1")とputStrLn("2")を評価すると、1と2のどちらが先に出力されるかわからない。
上のような事態に対応するため、Haskellはモナド(monad)を導入した
これらはIOで、このページの解説でもキレイにすっとばしている「時間」に依存する式のことです。
なんのことはない時間に依存するならば、時間に依存するような数学構造を定義してやればいいだけのことですが、Haskell界隈では、非常にこの辺苦労したみたいで、IOモナドという、IO専用の関数合成の仕組みを導入しましたが、大方は意味なんて理解していないので、こうやって、なぜかモナドという二項演算の解説の冒頭にIOという全く関係ない独立事象をもって紹介するのがHaskell界隈のモナド解説の非常に病的なクセです。
そして、流石にまずいと感づいてはいるのか、
などと、とってつけたようなモナド自体の説明をするのだが、こんなもんがモナドの説明になっているわけもありません。
「データに対して付加的なデータをくっつけた新しい型を作り、その型のデータを複数の関数の間で受け渡す仕組み」
JavaScriptのMapメソッドの拡張であるflatMapメソッドで確認してみましょう
[1].flatMap(a => [a +1]) // [2]
ではあるが、
「データに対して付加的なデータをくっつけた新しい型を作り、その型のデータを複数の関数の間で受け渡す仕組み」
という言葉で、なんかモナドのことがわかる、という初学者は全世界に誰一人として存在しない、と断言できます。
そして、参考資料としてあげられているのが、
ですが、これ両方とも例にもれずIOモナドのこと「だけ」を書いています。
２個めは表題からも明白ですが、１個目は、
これは表題として「モナド入門」と決め打ちしています。
関数型界隈のブログ執筆でそこそこ有名な人ですね。結構検索にひっかかります。
気まぐれと偶然となりゆきで、ここ2,3回はモナドを話題にしました。googleで「モナド」を引いてザッと眺めると、「モナドはむずかしいー」とか「モナドで挫折した」みたいな雰囲気が感じられて、説明芸人の血が少し騒ぎましたね。「なら、予備知識ゼロでモナドの説明をしてやろうじゃねーか」と。
タイトルはだいぶ煽っちゃった…… けど、ハッタリじゃないつもり…… けど、実際はどうかな？
プログラミングでモナド機構を使うと、関数、値、計算などの概念を一気に拡張することができます。うーん、ステキ。でも、モナドを採り入れているプログラミング言語の例をHaskell以外は知りません（たぶん他にもあるでしょうが）。そもそも、モナドが少しだけポピュラーになったのもHaskellの影響でしょう。
これに関しては正しい部分もあるけど誤解を招くアルアルです。
ただ少なくとも、IOだのピュアだの現実世界だのモナドそのものとは独立事象と絡めてしか説明できないアレな人々よりはかなりまともなアプローチだとは評価できます。
これ、Monadに先立って、絶対に説明しなければならないのは、本書でもMonoidの次に説明したFunctorです。
正確には、
プログラミングでファンクタ（Functor）機構を使うと、関数、値、計算などの概念を一気に拡張することができます。うーん、ステキ。
と書かなければいけません。
本書で解説していますが、Monadの良いところはせいぜいFunctorに二項演算合成してもパイプライン演算（IdentityMonad）のときのように壊れなくなる、あと構造に少しアプローチ可能になるというメリットくらいで、ここで言われている
機構を使うと、関数、値、計算などの概念を一気に拡張することができます。うーん、ステキ。
の旨味は「すべてFunctor」から来るからです。
MonadはEndoFunctorの特殊なケースです、念の為。すべてのMonadはFunctorでもある。
●こんな課題を考えてみよう：副作用付き計算
モナド概念は非常に普遍的なので、モナドの実例はとんでもなくイッパイあります。モナドの実例をいくつか出されると（例えば、リストと状態遷移と例外と入出力）、それらがモナドという単一の概念でくくれること、共通性を持つことが信じがたいでしょう。
そこで、モナドの実例を1つだけ選んで、その特定事例をシッカリ説明することにします。その実例とは副作用付き計算です。副作用とは、関数、メソッド、手続きなど（計算／処理の単位）が、外部（環境）に影響を及ぼすことです。例えば、ローカル変数以外の変数への値のセット、ファイル入出力、画面への描画などは副作用です。
副作用がなくて、純粋に計算だけを行う処理単位を純関数と呼びましょう。純関数の値（計算結果、戻り値）は、その引数値だけで決定されます。同じ引数を渡すなら、いつでもどこでも何度でも同じ値を返します。それが純関数ってもんです。
でました。さっそくIO、副作用の話です。
なんで、この人らは、Monadという二項演算の話を、Functorもすっとばして、いきなりIOという「別の概念の話」しかもプログラミングで扱うのに「時間」のグラフ構造の代数も考えるので、結構面白くもあり非常に大事な話をこうおいう「おまけ」みたいにしてモナド（Monad）の説明にしてしまうのか？
かなり異常な世界ではありますが、誰も言わない、僕ぐらいがいう、そして本書けば、こういう異常な世界になれてるのか、なんか僕の解説のほうが異端で、先にすすめば「より正確な」IOの説明がある、みたいにゆってくる。
ここで繰り返し声を大にして言いたいが、モナドというせいぜい関数型の世界では二項演算という代数構造の具体的な説明をするときに、IOなんていうそれ自体クセがある概念と絡めて説明すべきではない。
Haskellで苦労して導入されたIOモナドの歴史があろうが、そもそもあんなもんはIOファンクタであっても結果は同じです。
関数合成ならばファンクタはモナドになるんだから。
そしてその後延々とIOモナドの実装の話が続きます。
●そして、これがモナドだ
ここらで今までの経緯をまとめて、モナド概念を正式に導入しておきます。
振り返れば我々は； 関数から副作用を取り除き（汚れ作業はCountupMainに押しつけ）、代わりに戻り値に副作用の意図を詰め込み、それによって失われた関数結合の自由さを関数の拡張により取り戻しました。これらの背後には、次のような約束事／手順があります。
「モナド概念を正式に導入」と書いているので期待感をもって読むが、まだIOの話をしています。関係ないのに。
一般的なモナドも同様で、次の3つで定義されます。
- 型Tから新しい型M(T)を創り出す型構成子M
- fun:T→M(S)という関数からext(fun):M(T)→M(S)という関数を作り出す関数（高階関数）である（M用の）ext
- 型Tの値を、M(T)型のデータにする関数である（M用の）unit
なんでに二項演算だと説明しないのだろう？
Functorというベースとなる構造の拡張であると説明しないのだろう？
モナド(M, unit, ext)は、3つ組なら何でもいいわけではなくて、モナド法則という法則を満たす必要があります（今は触れません）。
いや、モナド法則とは二項演算の式だし、
「今は触れない」のは、それは、僕が本書でやったようなMonoidの説明、左右の単位元の説明をやってないのでできるわけがない。
大方、
世界で一番か二番くらいにやさしい「モナド入門」
というのは、こういう、IOという関係ない概念に依存していて、肝心の二項演算の結合性とか左右の単位元とかいう代数的性質については一切語らずに終わります。
そして、読むべき参考文献として列挙されています。
いや、こういう解説は僕の本の「先」の位置づけとしては、ないですよ？
と言っておきたい。
フェアに読み比べてみれば良いと思う。
あと、僕が読んだ世界で一番悲惨なモナド解説は、
こういうのがありました。
あとこういうの
ふたつとも「世知辛い現実世界」だとか「ピュア、純粋」だとか副作用がどうとか書いています。
たとえば、MonadのベースとなるEndoFunctorでは「一切」こんな言葉は使われずに結構正確に説明されていることがほとんどですが、ちょろっといじってMonadに拡張した途端にこういうわけのわからない現実世界と妖精みたいなファンタジーランド、IO一辺倒の世界観になるのは、本当に異常な界隈だと思います。
そういうのが普通で、普段こういう輩については黙認していたり本気で勉強になったとおもってるぽい連中が、まあ僕の本については間違っていないみたいな論調でなんか言ってくるのは本当に勘弁してほしいし、これが関数型界隈の病的なあり方である、という事実を確認しておきます。
念の為ですが、至って擁護的に長文をもって書評していただいた、そして実際に購入もしていただいた事でも明らかですが、Matsumoto Kazuhisa 氏には上記の僕の考えがあることを添えながらも、今一度感謝申し上げます。
Ohkubo Kohei氏には、まあ個人批判に便乗しながらも一応は問題ないと先陣切ったという点には感謝申し上げます。
宮西さんにはいつも有用なフィードバックもいただいている上にこのように好意的な紹介については感謝いたします。
正体不明の末永という人については、まあこういう人らには本当にうんざりしています。なんら中身がなく悪意があり、教育側面でいえば悪い効果しかもたらしていないでしょう。BNBR違反でもあります。
