【モナド編】本書いたら数学愛好者の中級レベルのプログラマーからマウンティングを試みられた話

ken-okabe.hatenablog.com

 

のつづきです。多分中編

 

qiita.com

がトンデモ素材。

FunctorとMonadは二項演算か？

型と集合でnLabのどこに書いてありますか？と中級者が本・記事をろくに読まないままTwitterで聞いてきたのは呆れましたが、これも「読めよ」のレベルの話です。

 

HaskellのFunctorやMonadはそれぞれ

 
(<$>) :: Functor f => (a -> b) -> f a -> f b
(>>=) :: Monad m => m a -> (a -> m b) -> m b

という二項演算を持ちます。Monadはこのほかに単位射 return :: a -> m a を持ちます。Monadについてはこの時点で「二項演算」だけじゃないだろって感じですが。

 

 

Haskellでいうならば、悪名高いMonad laws のページに

　

wiki.haskell.org

f:id:stq2050:20211212093051p:plain

 

とありますが、

これ、

Left Identity　左単位元

Riht Identity　右単位元

Associativty　結合則

という代数的属性について、まさにその

f:id:stq2050:20211212093351p:plain

と定義されrた演算子が、左右のオペランドの間の中置記法で

二項演算子として使われている式になってるんじゃないの？っておもいますけどね。

と言うか、君、そのFunctorとかモナドの演算子とか二項演算子以外の使い方してるの？っておもう。

 

著作においては、

19. ファンクタ（Functor）すべてを包括するような代数構造

19.6. Functorをもっと厳密にTypeScriptで定義していく

において、

型定義だけを改めて抜粋すると、

type F<A> = A[]; // type constructor type map = <A, B> // function => function (f: (a: A) => B) => (Fa: F<A>) => F<B>;

このTypeScriptのコードで、かなり正確に、Functorの概念を表現できています。

 

 

(引用終わり)

 

とかさらに、そのHaskellでの定義そのものを引用している。

中級者はまたろくに読んでもいないから、書いてるものをまた、ほらね的にQiita記事に書いてる。

いや、著作でそれ引用した上で論じてるから（苦笑

 

（引用始まり）

ちなみに、Haskellでは、型定義にプレースホルダは積み増さない流儀なので、

fmap :: (a -> b) -> f a -> f b

とFunctorはよりスッキリと定義されてるのですが、全く同じ意味です。 TypeScriptではプレースホルダは逐一明示したほうが便利だ、という方針で、そのメリットは確かに大きいですが、こういう抽象度が高い概念になると、逆に見通しが悪くなるデメリットはありますね。 視覚的に表現するとこういう概念図になるでしょう。

f:id:stq2050:20211212104104p:plain

19.7. 圏論（Category theory）のFunctor そもそも、Functorとは圏論（Category theory）で定義された概念なのですが、nLabのFunctorの項目によると、

この図をみると、ちょうど、

(f: (a: A) => B) => (Fa: F<A>) => F<B>

というコードの表現がそのまま書かれていることが感じられると思います。

 

 

 

（自分の本の引用終わり）

 

さて、中級者のQiita記事では、

 

HomF(c,d):HomC(c,d)→HomC′(F(c),F(d))

だそうです。

ここで、もしもHomが（プログラミング言語における）関数型のようなものであればこれはカリー化された関数、二項演算と思えるでしょう。しかし、 HomF(c,d) の → は集合の間の関数の意味なのに対し、行き先の HomC′(F(c),F(d)) は圏 C′ の射です。（C′=Set でない限り）住んでいる世界が違うのです。

 

うん知ってる。

で、誰もそんな圏論における一般的なMonadの話なんてしていないよね。

そもそも君が、

f:id:stq2050:20211212094303p:plain

 

って、その -> っていうのは、圏論の射（Morphism）ではなくて、

HaskellのコードでHaskellのFunctorとMonadの定義である時点で、

集合の圏（Category of sets）

https://ja.wikipediaorg/wiki/%E9%9B%86%E5%90%88%E3%81%AE%E5%9C%8F

の範囲で書いたんでしょ？

つまり、この中級者は最初

集合の圏（Category of sets）

を大前提に書き出していた。

というか今は関数型プログラミングの話なんで、暗黙に集合の圏のはなしで、自分も、

f:id:stq2050:20211212094928p:plain

このなかで、最も根底となる、すべての概念の包括的な枠組みが圏論（Category theory）で、これまで永らく数学の基礎であった集合論でさえも圏論の言葉で再定義されます（集合の圏（category of sets）における射（morphism）は関数（function）になる）。

と書いたけど、圏論の話なんてこういう中級者がマウンティングしてくる素材としてしかおおよそ機能なんてしておらず、関数型の本筋ではないのでこの記述にとどめている。

 

で、その上で、中級者は、

f:id:stq2050:20211212094647p:plain

とか書いてる。これは、

集合の圏（Category of sets）でない限り

って書いてるということ。

いや今は、集合の圏だろうが？Haskellのコードをしょっぱなに出すってことはそこの暗黙の了解はあるんですよね？

何いってんの？となる。

非常に中級者の誤魔化しぽいです。

僕がここで正さなければ、こういうごまかしが通用して、自分の腐ったメンツを保つのと引き換えに、こちらの書いたものが間違いだというデマを流すのと同時に、多くの入門者をあざむくことになります。非常に悪質です。

 

モナドの数学的な定義にはHaskellの >>= に相当するものは含まれていないのです。なので、モナドのことを二項演算と呼ぶのは不適切だと考えます。

 

Haskellの>>=は集合の圏のモナドで、これは「数学的」なの。

そして、集合の圏に限らない「数学的」なモナドが、集合の圏に限る「数学的」なモナドと一致しないのはあたりまえ。

 

だからといって、集合の圏であることがデフォルトの関数型プログラミングで扱う範囲のモナドは二項演算である事実を否定する正当化にはなるわけがないでしょ。

実際さ、Haskellのモナド則においても、モナドの演算で二項演算の演算子としてしか使われてない状態で、これがモナドです、って説明されている現状があるわけだろう？

 

あれで、どこにこれは集合の圏に限る、とか、

strong monadと呼ばれる構造を持つモナドであればお馴染みの (>>=) :: m a -> (a -> m b) -> m b に相当するものが定義できます。

 

人の本にイチャモンつけたいばっかりに、自分が普段普通にやってる範囲の概念で、いや、集合の圏ではない限り、違う、とかめちゃくちゃゴネてくるじゃねーよ、って思う。

 

モナドの数学的な定義にはHaskellの >>= に相当するものは含まれていないのです。なので、モナドのことを二項演算と呼ぶのは不適切だと考えます。

 

Haskellの>>=は集合の圏のモナドで、これはもちろん「数学的」ではあるが、この中級者が考えてる概念はデタラメで、たとえば、最初、

 

f:id:stq2050:20211212101227p:plain

 

って書いたら、

 

と　

 

プログラミング言語におけるモナドはそういう二項演算を持つ

 

という事実はようやく認めた。

というよりも

モナド＝代数構造＝二項演算

となるのだから「そういう二項演算を持つ」という表現は間違いで、あんまりわかってないぽい。

そんでゴネる中級者にたたみかける。

 

f:id:stq2050:20211212101344p:plain

 

 

すると、　

 

「関数が第一級であるからこそ>>=のような演算が定義できます」

ってTweetされた。

>Haskellのやつは「プログラミング言語におけるモナド」ですね。関数が第一級であるからこそ>>=のような演算が定義できます

 

意味不明。なにこれｗ

 

 

もちろん、説明などできるわけもなく、この中級者はこの質問についてはダンマリきめこんで無視を続けています。

 

なんで、Monadの定義に、プログラミング実装の

「関数がFirstClassObjectである」というスペックが混入してくるのか、わけがわからず、ああこの中級者はトンデモなんだな、っていうことを確認しました。

 

つづき

ken-okabe.hatenablog.com

 

本書いたら数学愛好者の中級レベルのプログラマーからマウンティングを試みられた話

関数型プログラミングが『銀の弾丸』であるという非常識な常識2022

をUPしました。長編です。

 

実労働時間ではけしてないですが、トライ＆エラーを繰り返しながら足掛け２年ほどかかりました。

 

はてなブックマークで、一時期トップページに掲載されて、

f:id:stq2050:20211212032510p:plain

 

その効果もあってか大変衆目を浴びた著作なのですが、副作用もあって、

福岡IT講師殺害事件のきっかけとなったのは、まさにこの「はてな村」であり、住民（の一部）は非常に筋が悪く治安が悪いのです。

実際に、

b.hatena.ne.jp

においては、多数の誹謗中傷コメントがなされており、はてなの利用規約違反ですから、はてな運営が要求する法的に有効な正式なフォーマットをもって抗議し、照会、削除要請をしています。

 

すでに、

関数型プログラミングが『銀の弾丸』であるという非常識な常識2022

2021/12/10 に岡部氏の蔑称を使いコメントしたことで不快な思いをさせたことを謝罪します。ブコメ自体は現在は削除済みです。（後ほど謝罪文を掲載する予定, この書き込みは両者の合意のもと書き込んでいます）

2021/12/11 14:17

b.hatena.ne.jp

f:id:stq2050:20211212121950p:plain

 

 

 

とおひとりは謝罪コメントをしていて、はてなブログでもその延長線上の謝罪はなされています。

 

nantonaku-shiawase.hatenablog.com

 

こういうコメント群が、真に正当で問題ない、というのであれば実際にこういう、はてなの規約で削除されるようになったり、本人が謝罪するようなことはないはずで、基本、現在社会問題となっているネットの匿名性を悪用した誹謗中傷行為が、僕の著作についてなされているのです。

 

たとえば、 

twitter.com

関数型プログラミングが『銀の弾丸』であるという非常識な常識2022

目次ですごい熱量だと思い、本文を2,3項読んで「んん？」となり、筆者名をみて「なるほど」となった。それ以上の感想はない。

2021/12/11 22:16

b.hatena.ne.jp

 

というのは、これはまあ、あからさまな個人攻撃ですが、内容自体の論評ではありません。

内容の論評を個人攻撃をテコとして「示唆」はしますが、「なるほど」という印象操作のレベルをでることはありません。結構卑怯なやり方ではあります。

 

関数型プログラミングが『銀の弾丸』であるという非常識な常識2022

力作だが、氏の評判は既に地に落ちてる。しばらく前にQuoraで見かけたが、相変わらず熱量はすごい。小説みたいな書き物ならここまで嫌われることもないだろうに。

2021/12/10 19:56

b.hatena.ne.jp

 

要するにこれなんですね。このはてなブックマークひとつで

「氏の評判は既に地に落ちてる」という雰囲気を醸成することが可能なのです。ろくに内容を精査せずに個人攻撃にくっつけた内容の論評の「示唆」をするだけで可能です。

 

お手軽ですよね。

 

実際、自身の日本語ベースの技術的アウトプットとしては、特にこういう治安の悪いはてな界隈は避けたかったために、これまであえてはてなブログは選択しませんでしたが、今回、こういう紐付けがしやすいこと、そしてどうせ炎上した後なんで、進んでこのはてなブログを新規に開設した次第です。

 

目次ですごい熱量だと思い

相変わらず熱量はすごい。

 

「熱量がすごい」というのが誰かのアウトプットを揶揄するための常套句として使われているようですが、特に前者の「目次ですごい熱量」というのは、たんなる「分量」のことでしょうが、２年足掛けで書いたものをまとめてアウトプットしているので当たり前のことです。

 

そもそも、ある程度こうやって体系化して初心者にもリーチできるように書くためには原理的に分量が必要であって、やろうとして簡単にできるわけがありません。

 

かなりのたしかに「熱量」をもって時間と手間暇をかけてやってるわけで、そういう執筆行為のあり方については評価されうることは妥当とは思いますが、こういう人格攻撃のようなものとあわせて揶揄するように公表するのは、まともな論評行為ではありえません。

 

id:kirifuu

twitter.com

関数型プログラミングが『銀の弾丸』であるという非常識な常識2022

トンデモ文章書きまくってたあの毛の壁氏？／自称本人が通報の上削除とか言ってっけど、数多の投稿型コミュでトンデモ認定されてBANされたのは単なる事実で、ブクマカのせいじゃあるめぇよ。全部ご自身の責任よ。

2021/12/10 14:16

b.hatena.ne.jp

 

「トンデモ文書」というのは、あなたがたがそう思っているだけで、事実としてはせいぜい「論争がある文書」です。

 

「論争がある文書」というのを「トンデモ文書」であると歪曲するために、

数多の投稿型コミュでトンデモ認定されてBANされたのは単なる事実

と虚偽の事実を公表しているわけですが、虚偽です。

事実であるのは、

  • 数多の投稿型コミュでBANされた

という一点のみで、まあアメリカ大統領選挙やコロナや地球温暖化のような大手SNSの検閲行為ではあるまいに、

「技術文書がトンデモ」という理由でBANされることなどありえないことは常識的な観点からも虚偽、デマであることはわかることでしょう。

 

要するに、たしかに僕は、特にこういう内容の論評ではない卑怯な個人攻撃や、さらにあたかも書いてる内容がトンデモであると社会的に認定されているという虚偽デマを流すような反社会的な行為については反撃するので、トラブルとなりBANはされますが、そのBANの事実をもって、技術的内容そのものまでトンデモで誤りであるというような悪質な印象操作がなされているわけで、それがまかりとおっている現実がある。

関数型プログラミングが『銀の弾丸』であるという非常識な常識2022

毛の壁の人は今までインターネット上にひどい怪文書を大量に残し様々なサービスで BAN されてきたが、あらゆるサービスで BAN されて痕跡が抹消されてしまうのでそのヤバさを伝える方法がないという話

2021/12/10 00:48

b.hatena.ne.jp

 

これもおなじ「手口」です。

  • ある人間がBANされた、という事象
  • ある人間が書いている内容がトンデモである、という事象

は、

BANされた理由がトンデモコンテンツだったから

という事象がないかぎり独立事象なのですが、そんな事実など存在していないのです。

 

よくわからないのが、プログラマのエコって言うのは相応に理性的でありこういう独立事象で関係ない、という道理は普通にわかってあたりまえだとおもってしまうのですが、非常に愚かな人が多い、事実ではない風評に流されてしまう人が多いということでしょう。

 

関数型プログラミングが『銀の弾丸』であるという非常識な常識2022

参考情報：関数型プログラミングコミュニティにおける災害 <a href="https://togetter.com/li/773846" target="_blank" rel="noopener nofollow">https://togetter.com/li/773846 &quot;関数型プログラミングに関して、用語をでたらめに使用した記事&quot;

2021/12/10 09:19

b.hatena.ne.jp

 

関数型プログラミングに関して、用語をでたらめに使用した記事

これを実名をだして批判してきた人がいて、

qiita.com

 

ですが、まさにこういう文書こそ論争の対象になるべきものでしたが、なぜか皆右に倣えで、誰も批判的に論評しませんでした。

僕はまだQuoraでBANされる前に、ひとつこれは「正しい知見」を共有するために決着つけておく必要があるとおもい、自身でQAを立てて論評してみました。

 

jp.quora.com

もちろん当該Qiitaコメント欄にも投下しました。

時期がずれていた、という要素もあるでしょうが、それ以降、彼の記事をもちあげるようなコメントはひとつもつかなくなりました。

 

関数型プログラミングが『銀の弾丸』であるという非常識な常識2022

関数型の研究室を20年前に出た者として: 世界がQ&amp;Aの集合なら関数型言語は銀の弾丸なんだが、あいにく世界も人間もPCそれ自体もステートマシーンなんだよ・・・ だから世界の問題のごく一部にしか向いていない。

2021/12/09 22:36

b.hatena.ne.jp

 

まあ、さすが20年前の知識で、古い知識で間違っています。別に僕自身が間違っていると殊更主張するまでもなく、現代の関数型プログラマなら、FRPとかあるんで、この主張が間違っている、という知見は共有されているでしょう。

 

というより、記事にはちゃんとこれを正面切って説明しているので、読んでおらずコメントし、また、とにかくアンチで貶めるネガティブコメントを発見したら脊髄反射的に★をつけてしまう、というのが、ここのはてなブックマーカーの愚かな習慣で、そんなことだから、治安も悪化して殺人事件とかにまで発展するんだよ、と毎度のように思いました。

 

さて、ちゃんと読んで論評した人についてです。

 

Image

Image

 

書評は歓迎しますが、まあみんな忙しいんでしょうが、普通はまず全部読んでから論評するものです。

おかしいというつもりはありませんが、命令型コードと関数型コードの差異について「ライブラリ使って短くみせてるだけ」というのは、結構普通レベルの知見として間違っています。それは本論を全部読めばわかってくることなのに批判的にアウトプットしてしまうというのは、行儀のよいおこないではありません。

 

同じように、別の人、こちらは結構悪質です。

数学愛好者の中級レベルのプログラマーからマウンティングを試みられた話

というタイトルに呼応する本論です。

 

基本的に、これも、上から順番に切り取って、あとから説明する、と明示されている箇所でさえ、その言及をすっとばして、おかしい、みたいに大騒ぎして、そのあとで「安心した」みたいに、一旦、あたかも著述の誤りがあると言うふうに誹謗中傷した事実をなかったことにして自分で回収するポーズはみせるが、あくまで誹謗中傷した結果の

「何か間違った事が書いてある」という印象操作は、修正もしないという悪質なスタイルです。

 

つまり現在のいわゆる「マスゴミ」と揶揄されるオールドメディアに顕著ですが、いったん大々的に誤報を広めておいて、そのあと紙面の片隅に小さく掲載、10秒くらいちょろっとアナウンサーが訂正する、というような悪質なスタイルです。

 

一例をあげると、

本文をちゃんと読んだ読者には明白なことですが、非常に気にしていますし、現代のJavaScriptにおいてプロトタイプ汚染を気にしない、という作法は通常まかりとおってなどいません。

それについて「そこに痺れる憧れる」とかドヤり顔なのかはしりませんが、ろくすっぽ読まないままに愉快犯的にいったん誹謗中傷するわけですね。

ところが直後にちゃんと言及されてるもんだから、

「認識はあるのか、良かった」みたいに書くわけです。

「良かった」じゃなくて、単に直後に説明されているような事柄について読まずに、あたかも著者の認識に「結構低レベルな次元で問題がある」ように愉快犯的に間違った指摘をしたのは己の責任であるのに、まるで著者の認識の問題のようにすりかえてしまっています。非常に悪質です。

 

根本的に、この人は論評したいのではなくて、数学愛好者の中級レベルのプログラマーなのですが、アラ探しをしてマウンティングをして他者の著作を貶めたいという目的である、悪意があるのは最初から透けて見えています。

 

非常にくだらない、おもしろくもなんともない煽りからはじめておいて、そういう自覚もないのなら、まあ色々問題を抱えているんじゃないでしょうか。あえて言いませんけど。

えんえんとくだらないことにこだわっています。

もうそろそろ書店コンビニでは2022年新春特別号とか雑誌が散見される時節ですが、日常生活でもいろいろ大変そうですね。

 

 

中級者ばりに半端な知識しかないので、ご存じなかったようですね。

 

さて、

qiita.com

 

見ていきましょう。

 

まずTwitterもそうですが、この記事は

純粋なネガキャン記事です。項目を見たらそれは明白ですね。

  1. JavaScriptで演算子オーバーロードを実現しようとするのは筋が悪い
  2. reduceにはinitialValueを指定しよう／reduceは二項演算と言えるか？
  3. 「型=集合」か？
  4. FunctorとMonadは二項演算か？
  5. 「タイプコンストラクタ」の用法

つまりこの中級者の「率直な感想」というのは、

アラ探ししてネガキャンしたい、ということなのでしょう。

つまりこの中級者が学んだはずの未知の概念が多いことは後からも論証しますが、そういうことについては一切素直に評価することはこの人物の性向的に無理なので、ネガキャンします、ということです。

JavaScriptで演算子オーバーロードを実現しようとするのは筋が悪い

氏は二項演算子に拘っておられますが、JavaScriptにはユーザー定義可能な演算子オーバーロードはないのだから、JavaScriptに適したやり方（関数・メソッド）を使うか、演算子オーバーロードに適した言語（特にStandard ML, OCaml, Haskellなどはユーザー定義の演算子を書けます）を使うべきだと思います。

 

これは、誹謗中傷犯が好む書き方なのですが、わざと論点混同して印象操作します。

すでにでてきたとおり、現代に置いて批判の多いいわゆる「マスゴミ」が大衆を騙すときに使う手法ですね。

 

１．JavaScriptで演算子オーバーロードを実現する事は難しい

２．著者＝僕がJavaScriptで演算子オーバーロードを実現するのは、著者の技術的な筋の悪い知見である

３．この入門書でJavaScriptを使うのは筋が悪い。

 

以上の３つはすべて、まったく異なる論点ですが、一緒たにして表現することで、

なんとなーーく

著者の筋が悪い、この入門書の筋が悪い、

という印象操作をしようとしています。

 

おそらく本人がそこまで利口かどうかはわからなくて、だいたい誹謗中傷してくる人間っていうのは無意識にこういう行儀の悪い書き方をします。

日本語の書き方、技術文書の書き方を学んだほうがいいでしょう。ましてや批判するときは不条理で悪質になるのだから。

 

印象操作、というよりこの中級者は本気でそう思い込んでいて、その本心は

１　オレサマのML最高

２　JavaScriptとTypeScriptとそれ使ってるこいつの本とクソ

みたいなネガキャンでしかありません。最後にでてきます、おたのしみに。

 

逆順で行きます。

 

３．この入門書でJavaScriptを使うのは筋が悪い。

については、JavaScriptとは現状においてもっとも広範に利用されているプログラミング言語であり、著者＝僕の専門でもあります。

本書ではTypeScriptでもって書いてもいますが、合わせるとシェアは絶大で、特にJavaScirptはTypeを気にしなくて良い局面の説明で簡潔に書けるので、関数型プログラミングの概念説明として非常に良い入門に適した言語です。

Twitterでは、このQiita記事では、さすがに筋が悪いと思って意図的に隠蔽しているのかもしれませんが、この人は、AltJSの実装をしろ、とか最初言ってました。自分がコンパイラ、処理系の実装が趣味だからです。

>演算子オーバーロードに適した言語（特にStandard ML, OCaml, Haskellなどはユーザー定義の演算子を書けます）

 

Rustが抜け落ちていますが、その事は、本論でも指摘していることで、多くの人が知ってることなので、今更このひとが説明することでもないですが、ようするに自分が使ってる言語ならできます、ってことや、本書のターゲットである層を無視した無理筋をゴネてるんですね。

はなっから、

演算子オーバーロードに適した言語（特にStandard ML, OCaml, Haskellなどはユーザー定義の演算子を書けます）

における関数型プログラミング入門でもなんでもないんで、こういう使う言語が違う、みたいに言ってくるのは、そうとうアレな中級者だな、という印象を強めることでしかありません。

 

２．著者＝僕がJavaScriptで演算子オーバーロードを実現するのは、著者の技術的な筋の悪い知見である

 

総論として、読者にそう思わせる効果を発揮しています。

 

１．JavaScriptで演算子オーバーロードを実現する事は難しい

 

これはそのとおりで、本書でもとりくんでることです。

その試み自体はむしろ本書の売りとなっているのですが、そういう試み自体をネガティブに論評することで、２の著者の筋の悪さにつなげようとしています。

 

氏がそこまでJavaScriptにこだわる理由は私には分かりませんが、「アテにならない」TC39が支配するJavaScriptに無理やり二項演算子を定義するのではなくてもっと筋の良い言語の啓蒙に勤しむ方が活動として有意義だと私は考えます。

 

「筋の良い言語の啓蒙に勤しむ」

ほらね。結局はJavaScirpt/TypeScriptで関数型プログラミングを実践すること自体の全否定です。

 

要約すると、

JavaScirpt/TypeScriptで関数型プログラミングを実践

というテーマ自体の全否定であり、そうすれば本書のテーマを全否定できます。

これが世界でシェアがトップクラスのJavaScirpt/Typescriptエコにむけて正当に受け入れ可能な言い分であるかどうか？まあ考えてみるまでもありません。

 

念の為に本書で書いた大枠とは

 

>多少のハック的手法を許容するのであれば、なんとかはなります。それが本書の手法です。すべては二項演算子を活用するという根幹の目的を達成するためです。逆にこの最難関ポイントを突破することさえできれば、関数型プログラミングの見通しがクリアになり、視野は広がり、理解を深めることが容易になります。

 

この観点に照らし合わせて、同じレベルで論評するのならいいが、多分こういうのも読み飛ばしているし、気にもとめてないでしょう。

なぜか？ネガキャンする目的で本書をつまみぐいしてるだけだから。

 

さて、

例として、氏の「パイプライン演算子」を見てみましょう。氏のパイプライン演算子は

// f(x) に相当するコード
P(x)['>'](f)

という形をしています。まず、文字数が増えています。また、18.8にある定義を見ると、元の値がObjectであればそれ自身を改変するコードとなっています。

　

文字数が増えています、ということですが、本書の、

13.5. 二項演算子で式を書けばコードはシンプルになりType定義の構造と一致しやすい

 

13.6. 二項演算子（Custom operator）は見やすくて書きやすい

 

で、このテーマについては論証しています。

 

論証していることについて、一切呼応することなく、

「率直な感想です」という言い訳ひとつで、そういう本文の内容自体を無視して、おそらくろくに読んでないのでしょうが、論評の体裁をとらずにやらかしています。

まず、文字数が増えています

文字数は増えるが、問題は回避できる、

それから入れ子構造になる問題も回避している、

タイプ定義と一致する、

見通しが良くなる、

というメリットの対比については無頓着です。

こういうフェアな論評姿勢でないのはなぜか？

もちろん、ネガキャンしたいだけだからですね。

18.8にある定義を見ると、元の値がObjectであればそれ自身を改変するコードとなっています。

これも、まるでコードをみたらわかった、筆者が説明はしてない、みたいな虚偽記述、印象操作ですが、このObject拡張についてはNoneの導入とあわせて精密に議論していますが、そういうのも一切無視です。

18.8にある定義を見ると

とか書いてるんだけれども、

18. 独自の二項演算（Custom operator）、関数合成の二項演算子、パイプライン演算子の実装 18.1. 道具立てを揃える 18.2. JavaScriptで独自の二項演算子（Custom operator）を定義する 18.3. JavaScriptで独自の二項演算子（Custom operator）を定義するための関数 18.4. 関数合成の二項演算子の実装　グローバル 18.5. 関数合成の二項演算子の実装　ローカル 18.6. パイプライン演算子の実装 18.7. null問題とオプション型（OptionType）

 

これ全部そのコードのための説明です。

18.8. パイプライン演算子のコード

この中級者があたかも自分がコードをみたから発見できた、みたいに嘘のハッタリポーズをみせているコードというのは、そのこの章をまるまる全部費して詳細に説明した結果、にすぎないんですね。

なんでこんなことをやるのか？

おそらく、Qiitaの記事閲覧者が実際に該当箇所を見に行くことをしないだろう、とタカをくくっていて、ハッタリポーズであることはバレないだろうと思ってるからでしょう。つまり、ほんとうのことなど読者に通知するのが目的でもなんでもなくて、あたかも自分は隠された真実を発見した、という嘘のポーズを示して、閲覧者にむけて印象操作でもなんでもやりたい。

なんでこんなことするのか？

ネガキャンしたいだけだからですね。

 

>例えば、氏のパイプライン演算子を使うと次のコード

const x = {'>': "Hello world!"};
console.log(x['>']);
P(x)['>'](x => x);
console.log(x['>']);

は

 
Hello world!
[Function: value]

を出力します。与えられた引数を改変しており、これは汎用ライブラリーとしては非常に行儀の悪い挙動です。

良いアラ探しのための試みですが、彼の説明には、意図的な嘘が含まれていて、パイプライン関数 Pは汎用ライブラリとして提供しているのではなく、そういう意図で提供していないものを「汎用ライブラリ」として、こういう意図的に不具合をピンポイントで狙っておいて「非常に行儀の悪い挙動」と表現するのは、それこそ「行儀の悪い論評」です。

とはいえ、すでに有償版を購入された方からのサンプルコード実装では、演算子の競合という初歩的なレベルの話は出ていないわけもなく、それこそ汎用ライブラリーにするバージョンにはこの手のエラー処理については実装済みで、汎用ライブラリとしてはそのバージョンを配布していています。

書籍のサンプルコードを複雑にしたくないのですが、

">" in x
? (() => { throw "'>' is used in the target Object property"; })()

と追加すれば回避できるので、公開している本文でも、もうそちらをデフォルトで掲載するようにしています。

 

つまり、書籍のサンプルコードはこういうかなり特別な値を入力したらはじめて壊れるような「脆弱性」をふさぐためのエラー処理コードなんて含めたくはないですが、こういうコードに実際に攻撃可能みたいに喧伝されたい以上、いたしかたないので、この「サンプルコードの脆弱性」については「汎用ライブラリ」としてエラー処理もあえて埋め込んで塞いでいます。

reduceにはinitialValueを指定しよう／reduceは二項演算と言えるか？

これはすでに中級者あてには直接説明して、本人は一旦は納得したっぽいのですが、アレな中級者なんで、どうしても持論を押し通してネガキャンやりたいようですね。

本文で説明していることですが、

MonoidはFold/reduceできます。

半群（Semigroup）には必ず単位元を追加することができて（単位元の添加）Monoidにできます。

reduce/foldのinitialValueというのは、たとえば

[]　が畳み込みの演算に必要となる場合は、これはすなわちそれが追加されるべき単位元であるということになります。

しかし、一般的にプログラミング言語でfold/reduceはそんなレベルで自動的に数学上では必ず存在している単位元を探し出してinitialValueとして追加する、ということはないので、initialValueが必要な「場合もある」というだけです。

 

実際に

const add = (a, b) => a + b;const sum = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10].reduce(add);

とした場合、単位元が省略できていて、このときは暗黙に

initialValueは0として機能しているので、余計なことをすべきではりません。

そしてこの件については、

15.8. Fold（Reduce）と単位元Array.prototype.reduce()を含む各プログラミング言語のFoldの仕様には、一見不可解な仕様があり、

引数initialValue 省略可コールバックが初めて呼び出されたときの previousValue の初期値です。 initialValue が指定された場合は、 currentValue も配列の最初の値に初期化されます。 initialValue が指定されなかった場合、 previousValue は配列の最初の値で初期化され、 currentValue は配列の 2 番目の値で初期化されます。

実際、

const add = (a, b) => a + b;const sum = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10].reduce(add); //1+2+3+4+5+6+7+8+9+10console.log(sum); // 55

では、initialValueは省略されています。この場合、initialValueを省略しない場合、その値は、加法＋の単位元の0となります。

const add = (a, b) => a + b;const sum = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10].reduce(add, 0); //0+1+2+3+4+5+6+7+8+9+10console.log(sum); // 55

乗法では、

{ const multiply = (a, b) => a * b; const product = [1, 2, 3, 4].reduce(multiply); // 1 * 2 * 3 * 4 console.log(product); // 24}{ const multiply = (a, b) => a * b; const product = [1, 2, 3, 4].reduce(multiply, 1); // １ * 1 * 2 * 3 * 4 console.log(product); // 24}

と乗法の単位元である1が、initialValueとなります。多くの場合、単位元は省略できるのですが、あえて指定しなければならない局面はあります。

 

 

 

 

 

（引用終わり）

と解説していますが、ネガキャン目的でアラ探ししたいだけの中級者は読んでもいないのでしょう。

 

堅牢なプログラムを書く上では、reduceは二項演算ではなく三項演算として捉えるべきです。

 

あなたがそう思うなら、勝手にすれば良いが、Monoidの畳み込みという数学的な位置づけにおいては、単位元というのは、アプリオリに存在しているものであって、人間様がいろいろ考えた上であえて指定するような数学構造にはなっていません。

ちなみに、堅牢なプログラミング言語であるStandard MLでは、JavaScriptのreduceに相当する関数 List.foldl はきっかり3つの引数を受け取る関数となっています。

それで？

いつから、プログラミング言語の実装が数学構造を上書きして規定するようになったのですか？

ようするに、この中級者はMLの実装という一部だけを切り取って、自分の都合のよいように、主張しているだけだ、ということです。

 

「型=集合」か？

繰り返しますが、私は初学者向けに「型は集合のようなものだよ」と説明することを否定はしません。しかし、Twitterで「こいつ @mod_poppo は、型が集合である事実すらしあず」と仰っているからにはKen Okabe氏は本気で「型=集合」と考えているようです。それほどご自身の信念に自信をお持ちなら、解説文書中の「型」を全部「集合」に置き換えてはいかがでしょうか。

 

>Ken Okabe氏は本気で「型=集合」と考えているようです。

そうですね、

本書においては、

9. 型（Type）は何故そんなに役に立つのか？そもそも型（Type）とは何かとまるまる一章を割いて解説しています。

9.3. わかりやすい、型（Type）の説明

においては、

Type theory versus set theory型理論 vs 集合論

Alternately, we could change our terminology so that what we have been calling “types” are instead called “sets”.あるいは、これまで「型」と呼んでいたものを「集合」と呼ぶように用語を変更することもできます。 Thus, words like “type” and “set” and “class” are really quite fungible. This sort of level-switch is especially important when we want to study the mathematics of type theory,このように、「型」や「集合」や「クラス」などの言葉は、実はかなり代替可能です。このようなレベルの切り替えは、型理論の数学を研究するときには特に重要です。

以上は、nLab記事からの引用文です。

nLab は、数学・物理学・哲学の研究レベルの内容について扱ったウィキである。nLabはMathOverflowにおいて、質問前にチェックするべき標準的なオンラインの数学文献の1つとしてリストされている。多くの質問と解答が、nLabを背景資料として用いている。また、nLabはバイエズがアメリカ数学会（American Mathematical Society）に投稿した数学ブログのレビュー記事の中で言及されている2つのウィキのうちの1つである。

Types as Sets集合としての型

One of the most important techniques in Elm programming is to make the possible values in code exactly match the valid values in real life. This leaves no room for invalid data, and this is why I always encourage folks to focus on custom types and data structures.In pursuit of this goal, I have found it helpful to understand the relationship between types and sets. It sounds like a stretch, but it really helps develop your mindset! Elmプログラミングで最も重要なテクニックの一つは、コード内の値を実際に有効な値と正確に一致させることです。これでは無効なデータを残す余地がないので、私は常にカスタム型やデータ構造に注目することを推奨しています。この目的を追求するにあたって、型（types）と集合（sets）の関係を理解しておくことが役立つことを私は発見しました。余計なことのように聞こえますが、それは貴方のマインドセットの形成に本当に役立つのです！

 

型（Type）をこのような集合（Set）として考えることは、ある言語が人によって「簡単」「制限がある」「間違いやすい」と感じる理由を説明するのにも役立ちます。例えば Java - BoolやStringといったプリミティブな値があります。そこから、異なる型のフィールドを固定的に持つクラスを作ることができます。これはElmのレコードによく似ていて、カーディナルを掛け合わせることができます。しかし、足し算をするのはなかなか難しい。サブタイピングを使えばできますが、かなり手の込んだ作業になります。つまり、Elmでは簡単なResult Bool Colorも、Javaではかなり大変なのです。5のカーディナリティを持つ型を設計するのは非常に難しく、しばしばトラブルの価値がないように思われるため、Javaを「制限的」と感じる人もいると思います。 JavaScript - ここでも、BoolやStringといったプリミティブな値があります。ここから、動的なフィールドセットを持つオブジェクトを作成することができ、カーディナリティを増やすことができます。これはクラスを作るよりもはるかに軽量です。しかし、Javaのように、加算を行うことは特に簡単ではありません。例えば、Maybe Intをシミュレートするには、{ tag: "just", value: 42 } や { tag: "nothing" }のようなオブジェクトでMaybe Intをシミュレートすることができますが、これは実際にはカーディナリティの掛け算です。これでは、実際に有効な値のセットと正確に一致させるのはかなり困難です。このように、カーディナリティが(∞×∞×∞)の型を設計するのは非常に簡単で何でもカバーできるので、JavaScriptを「簡単」と感じる人がいる一方で、カーディナリティが5の型を設計するのは実際には不可能で、無効なデータのためのスペースがたくさんあるので、JavaScriptを「エラーが多い」と感じる人もいるのではないでしょうか。 面白いことに、いくつかの命令型言語にはカスタム型があります。Rustがその良い例です。Rustでは、CやJavaから得られる直感に基づいて、これらをenumと呼んでいます。そのため、RustではElmと同じように簡単にカーディナリティを追加することができ、同じような利点があります。 ここで言いたいのは、型の「追加」は一般的に非常に過小評価されているということです。「集合としての型」として考えることで、ある言語設計がなぜある種のフラストレーションを生むのかを明確にすることができます。

 

と、nLabとELM作者の知見を踏襲しています。

僕の考えは以上の考えと一致しておりそれ以上でもそれ以下でもありません。

 

わざわざnLab自体の説明で、

以上は、nLab記事からの引用文です。

nLab は、数学・物理学・哲学の研究レベルの内容について扱ったウィキである。nLabはMathOverflowにおいて、質問前にチェックするべき標準的なオンラインの数学文献の1つとしてリストされている。多くの質問と解答が、nLabを背景資料として用いている。また、nLabはバイエズがアメリカ数学会（American Mathematical Society）に投稿した数学ブログのレビュー記事の中で言及されている2つのウィキのうちの1つである。

 

と権威があることを示す、権威付けをしたのは、まさにこういう鬱陶しい中級者がイチャモンをつけてくるにきまっている、と事前に予想していたからです。

中級者はろくすっぽ読みもしていないのに、こうやって結構目立つようにまるまる引用して書いているのに、

とか質問してきました。ほんと読まずに文句垂れてるんだな、と呆れましたが示すと、

 

と、なんか「型」を「集合」に置き換えてはいかがですか？とか食い下がってきました。また、

とか中級者ぽい質問をしてきたので、

と親切にお答えしました。

なんで中級者が延々ネガキャンしてくるのに、教えてあげなきゃならんのだ、と思いながら。

結局の所、中級者ぽい考え方とは、

１．型理論というものがある

２．集合論というものがある

 

両者は別物だ、別物だから一致しない、まああたりまえなんですが、あとから異なる分野のより高い視点での統合というメタな視点は普通にあるわけです。

Type theory versus set theory型理論 vs 集合論

Alternately, we could change our terminology so that what we have been calling “types” are instead called “sets”.あるいは、これまで「型」と呼んでいたものを「集合」と呼ぶように用語を変更することもできます。 Thus, words like “type” and “set” and “class” are really quite fungible. This sort of level-switch is especially important when we want to study the mathematics of type theory,このように、「型」や「集合」や「クラス」などの言葉は、実はかなり代替可能です。このようなレベルの切り替えは、型理論の数学を研究するときには特に重要です。

 

それだけのことです。

繰り返しますが、私は初学者向けに「型は集合のようなものだよ」と説明することを否定はしません。しかし、Twitterで「こいつ @mod_poppo は、型が集合である事実すらしあず」と仰っているからにはKen Okabe氏は本気で「型=集合」と考えているようです。それほどご自身の信念に自信をお持ちなら、解説文書中の「型」を全部「集合」に置き換えてはいかがでしょうか。

この中級者が自分の勉強不足を覆い隠そうと背伸びしてイチャモンつけてくる中級者ぽい恥ずべき行いと、nLabでの記述のどちらを信じるのかは賢明な読者の判断におまかせします、って言っておけば良いのかな。

やれやれ。

 

 

 

いい加減、長いのでいったんわけます。

のこりはあとでUPします。

 

ここまでのまとめとしては、要するに、

 

関数型プログラミングの本質的解説で見通しの良いように採用する、二項演算表記については、JavaScriptでやるべきではない、だとか、

数学では暗黙に単位元が追加されるので、数学的には二項演算とみなされる、そして、JavaScriptそれからHaskelでも初期値を省略できる二項演算として実装されているもんを自分が好きなMLで３引数だとHaskellその他の実装については隠蔽しながら強弁したり、

型は集合っていう見通しの良くなる概念を中級者としては妨害してイチャモンつけたいとか、

 

なんら、初学者の学習にとっては建設的ではない、気に入らないなら、自分でAltJSでMLでも関数型入門の本を書けばいいが、こんな自己満足の世界の中級者に彼らにリーチするような親切な入門書が書けるとは到底思えず、生半可な知識でマウンティングして妨害するのはたいがいにしろよな？ってことかな。

 

それに関してこれを先に処理。

 

最後に、Ken Okabe氏へ

この記事について反論があるなら元の記事に追記するか、ご自身で新たに記事を書いてください。

読者にとって重要なのはTwitterでのバトルの勝者ではなく、それぞれが書いた記事のどちらに説得力を感じるか、でしょう。なのでTwitterでの見苦しいバトルは不毛です。

というわけで、Twitterで私にこれ以上絡むのはやめてください。私もあなたの相手をする時間が無制限にあるわけではないので、これ以上粘着されるようであればブロックします。言いたいことがあるなら記事に書いて、読者の判断に委ねると良いでしょう。

 

無制限にあるわけではないので、粘着がーとか書いてますが、なんか最初に僕への個人攻撃をしているのを見つけてなんかリプしたら火がついちゃって、

ネガキャンやるって一大決心したのはこの中級者自身です。

自分で徹底的にネガキャンやって僕を攻撃するって決心して、予想通りQiitaにまとめ記事をUPまでして、自分の気持はそれで一旦おさまったんでしょう。

で、閲覧者を印象操作するような行儀の悪い、作法もわるいやりかたをしておいて、反撃されたら困るので被害者ヅラ。ホント悪質ですよね。

粘着してるのはおまえだろ？というはなしで、被害者ヅラしている点については、

 

 

 

 

ってことですね。つづく。

ken-okabe.hatenablog.com