【+α+タイプコンストラクタ編】本書いたら数学愛好者の中級レベルのプログラマーからマウンティングを試みられた話

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

ken-okabe.hatenablog.com

https://ken-okabe.hatenablog.com/entry/2021/12/12/102301

ken-okabe.hatenablog.comhttps://ken-okabe.hatenablog.com/entry/2021/12/12/130747 

ken-okabe.hatenablog.com

 のつづきです。

 

マウンティングを試みているが墓穴を掘り進んだ中級レベルの人が書いた素材はこれ

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

qiita.com

 

まずはこれまでの総論というか、なんで中級レベルの彼がトンデモだと思っているのか、取り残した素材とあわせて論評。

 

本書で一貫しているのは、関数型プログラミングの力の源泉は数学そのものであり、プログラミングというのは、なるだけ簡素にその表記であれば事が足りる、ということです。

 

「なんで二項演算にこだわるのか?」というイチャモンに過ぎない雑音が多いですが、単に、モノイドでも

1+2+3

という二項演算子+があり、簡素に演算を表現できているが、少なくともJavaScriptでは他の本質的には二項演算として簡素に表現可能なものが、そのとおり表現できないので、この障壁を取り払おうとしているに過ぎません。

 

なんでJavaScriptなんだ?とか言ってる雑音集団はこういう中級者君のオレサマ今MLやってて気に言ってる最高、とか、その他何名か知ってるけど名前ひっぱってくるのは面倒くさいから容赦してやるけど、だいたい同類です。

 

基本的に、僕はJavaScriptTypeScript向けに関数型プログラミング入門を書きたいのだし、リーチできる初学者層が非常に多いのは書きごたえがあるわけです。

もうすぐRustにこの本を翻訳する予定ですが、とりあえずオレサマお気に入りのMLの啓蒙しろ、そのほうがよい

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

とか言ってくる分には、うっせーわ、人の本批判するにかこつけて、だまってろや?と口汚く罵るしかありません。一択でしょう。

MLなんぞの関数型本に巷の初学者には需要なんてほぼないでしょう。入門書書きたければてめーで頑張って書けばいいけど、ネガキャン乗じて「活動として有意義」みたいな趣味趣向のわけわからん政治的要求してくんなやド阿呆と口汚く罵る一択です。

 

まずこの辺から、この中級者に限らず文句垂れてる外野の属性っていうのはだいたい揃っていてヤバイ連中だな、と痛感しています。トンデモ臭もしますね。少なくともこういう連中は初学者の役になんて一切立ちません。関数型が難解であると思われてる元凶でもあります。

型は集合というnLabやらELMの作者やら権威を少なくとも彼らが黙り込むレベルの権威付をしてやると、行き場を失って右往左往しますが、今Twitterみたら、

 

 

もう必死に悪あがきしているようです。

仲間ももうnLabやElm作者があそこまではっきりと明言してるんだから、、と権威にはからっきし弱い、自分の頭で考えることが苦手な連中ですから、もうろくな助け舟も出ません。無理筋だとうすうす気づいてるんでしょう。

 

見るに見かねた人に

とおちょくられる始末。末期ですな。

 

なんで、同一視すれば楽に俯瞰できる、とこれだけはっきりと提示されているものに、

誰か「型って何?集合との違いは?調べてみました!」みたいな記事を書いてくれ

とか誰かに必死に頼まないといけないような差異を見つけ出すことに必死なんでしょうか?

この辺がこいつら中級者集団の浅はかなところです。

少なくとも彼らの知見から何かを学ぼうとしてる人は無駄だと思ったほうが良いでしょう。

僕は、同一視する、という概念を重視していて、それはより高い視点、メタな視点を獲得できるとおもっていて、初学者のひとらに必ず役立つ、楽に習得しやすいと、入門書を書く立場として大事なことだと思っています。

 

僕はそういう視点をもって、二項演算子の導入のメリットやら、型は集合である、と権威付もしながら紹介するわけですが、こいつら中級者はネガキャンはって妨害してきます。最終的には上のTweetでも明白でも自分のメンツだけです。

ネガキャンマウントとろうとしたがボコボコに返り討ちにされちゃって恥かいてメンツ保つことだけに必死です。

「型=集合」か?

「型」が何かというのは(私にとっては)難しい問題です。

初学者向けには「型は集合のようなものだよ」という説明で良いかもしれません。

初学者向けには、とか中級者ぶっていますが、実際こんなもん中級者君が何がわかってる、ってわけでもありません。

僕自身のことでいうと、いろいろ見ていて、ああ型は集合のことか、という直感というか同一性が自分でわかったので、そういう風に解説したいがどうせ中級者どもがわかった風に誹謗中傷してくるだろうな、と予測したので、軽くぐぐったら、nLabやらElm著者の記事やらがヒットしたのでそれをありがたく、そのとおりだよなー的に引用させてもらっているわけです。

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の引用つきで書いても、読まずにどこですか?とかマヌケなことを言ってくるし、それを読んでもまだ納得もできない。

こういう連中は学問をするにあたって本当に適正がないです。頭がよろしくない。センスがない。

そして僕のアウトプットをトンデモレッテル貼りたがって、さらに評判を下げようと必死な連中っていうのは、だいたいこういう中級者の連中です。

とりまきは中級者以下なんで、そーだそーだ岡部のいうことは変だーと同調するだけで、なんかわけのわからん風評被害が醸成されていきます。ろくでもないですね、ほんとうに。

しかし、私が思うに、型は集合よりも幾分抽象化されています。ここでの抽象化というのは、できる操作が限られているという意味です。例えば、

あなたがおもう「幾分」ってどれくらい?って話になりますが、事例を出すそうなので、その「幾分」ぶりを精査してみよう。

  • 集合は自由に和集合 (union) や共通部分(交差, intersection)を取れますが、型について和や交差を取れるかどうかは型システムに依存します。
    • 例えば、今のTypeScriptにはunion typeやinteresction typeがありますが、リリース当初のTypeScriptにはどちらもありませんでした(union typeはTypeScript 1.4から、intersection typeは1.6からです)。
    • 別の例で言うと、Haskellにはそもそも部分型関係がないためunionもintersectionもありません。

なるほど。「型システムに依存する」と、その実例としてTypeScriptの実装の歴史を語っている。Haskellの実装の不備のことを不満に思っている。

XXかとww(自粛

なんで、数学構造、数学の理論が各プログラミング言語の型システムという実装に依存する、とか言ってるのでしょうか?

逆なら真であり、実装が数学理論に依存するのです。

数学理論が実装に依存する、なんて馬鹿げた話なんてありえません。

型システムが高度化していく歴史の下敷きには、その先に型理論があるわけで、それは究極的には集合論のことだ。

「抽象化」のはなしをしているのに、なんで実装の違いの話をしているんだろう。

「できる操作が限られている」のが実装の至らなさであるのならば、それは「抽象化」の問題とは言わない。抽象概念を実装するという「具体化」の問題なんだ。

>集合は自由に和集合 (union) や共通部分(交差, intersection)を取れますが、型について和や交差を取れるかどうかは型システムに依存します。

集合論という抽象的な概念、数学があり、それをどうやって具体的な実装をしてコードに表現できるかだろう?

これで、なんで集合は型ではない、という論証になると思っているのか。そうとう頭が(自粛)ですね。なんで僕の仕事を批判できるとか思ってるんだろうか?よくわかりません。

  • 集合に対しては冪集合 (power set) という構成がありますが、型に対する類似物はあまり聞きません。ある型の部分型全てを集めた型…となるのでしょうか?
    • 【追記】「A -> Bool がそうではないか」という意見を頂きました。特性関数と部分型を同一視すればそうなりそうですが、筆者としては「部分型を集めた」感がないなあ、と思ったのでこの記事の当初の版では言及しませんでした。

うん、結局、集合のほうがより明確に抽象概念化されているんだ。これは本書ですでにまとめていて、たとえば

f:id:stq2050:20211212212948p:plain

この表ひとつとっても、集合論のほうは細分化されているけど、型は型としてしかないのはわかります。他の分野では区別があるものでも型は区別されてない。

 

という点で型と集合は違うものだと考えます。

?どういう点で?

君ひとりが混乱してます、って言ってるだけ、あるいは、型のほうは集合論みたいに十分整理されていない、あるいは整理しにくい現状だ、あるいは、TypeScriptで十分実装されてない、って言ってるだけだろう?

それをもって「型と集合は違うものだ」という論証としてなんて成立していない。

論証成立もしてないのに、してる、とおもえるならばトンデモ重症レベルだと思う。

 

繰り返しますが、私は初学者向けに「型は集合のようなものだよ」と説明することを否定はしません。

はっきり言うけど、君は「初学者向けに」みたいに豪語できるような知見がある立場になんていないよ。

しかし、Twitterで「こいつ @mod_poppo は、型が集合である事実すらしあず」と仰っているからにはKen Okabe氏は本気で「型=集合」と考えているようです

そうだね、そう考えてるよ。何か問題でも?

FunctorとMonadは二項演算か?

これについては、もう十分論評したとおもう。

Haskellのコードでゴネてたけど、Haskellモナドで全部二項演算子だし。

ゴネた挙句に、関数がファーストクラスになる実装によってモナドの二項演算になっている、とか、また、実装を数学構造の定義や差異の要因にしようとしていた。

TypeScriptの実装のバージョン違いが、型と集合の数学構造の抽象度と関係あるとか、この形式のトンデモ理論を振り回すのが好きな中級者なんだろうと思う。

はなしにならん。

「タイプコンストラクタ」の用法

詳しい人向けの解説:氏の文書では「タイプコンストラクタ」を「(モナド等の)単位射」の意味で使っています。これは間違いです。

デマ。

詳しい人向けだろうがそうでなかろうが悪質なデマ。そんな事実はない。

 

本書の範囲には含めなかったが、タイプコンストラクタは

  • 0階のタイプコンストラク
  • 1階のタイプコンストラク
  • 2階のタイプコンストラク
  • 3階のタイプコンストラク
  • ・・・・・

というように、あらゆる階層に存在する。

こういう高階のタイプコンストラクタは、高カインド型とも言われている。

 

本書でもまる一章かけて解説した高階関数

f > g あるいはg(f) というように関数をパラメータとする関数である、という同じ意味での高階(HihgerOrder)。

関数は値のコンストラクタとすると

型コンストラクタはその型レベルのはなし。

  • 1階のタイプコンストラク

では、単に

F<A>

というようになり、本文を引用すると

今は、かんたんな配列なので、[]でくくるだけで暗黙のうちにそのArray型を生み出しているわけです。きちんと明示しておくと、単純に、

const F = // type constructor a => [a];

となります。こういう何もないところから、ある特別な型(Type)を新規に構築する(生み出す)関数のことを、型構築子/タイプコンストラクタ(Type constructorといいます。オブジェクト指向でいうところの、コンストラクタConstructor)に該当します。 TypeScriptにおいてはタイプコンストラクタにも当然きちんと型(Type)がつくのですが、ジェネリックを使って、以下のようにタイプ定義します。

type F<A> = A[];const F = // type constructor <A>(a: A): F<A> => [a];

 

 

となるから、それで良い。

これはモナドの単位射に他なりません。

まあそのとおりだね。モナドはそうなるように定義されてるんだから。

 

用語に関してついでに言うと、Ken Okabe氏の文書ではMonadを返す関数のことを「Monad関数」と呼んでいるようです。Haskellで言えば a -> m b みたいなやつです。圏論の文脈的には、これにはKleisli射という名前がついています。

そのとおりだね。

そして中級君は、あんまり自分の頭で考えるのが苦手だから、用語は本の丸写しみたいな思考しかしていないのがわかるけど、君はクライスリ圏の概念の意味とかちゃんとわかって発言している?自分の言葉でちゃんと説明できるのかい?

どうせできないんだろう?せいぜい本の引用だけだろう?

クライスリ圏っていうのは結構、特異な発明であって、基本は集合の圏だ。発明者たちの特殊な思考フレームワークを特別に信奉したいという事情でもない限り、関数型プログラミングは普通に集合・関数の圏(Category of sets)で関数合成からはじまって必要な部品は揃うんだから。

 

自分で意味も理解してないような用語を振り回して、

圏論の文脈的には、これにはKleisli射という名前がついています。

とか書くことに一体なんの意味があるんだい?

 

まともに論じる能力もないのに中級者として背伸びして難しそうな用語でハッタリ効かせようと思っているだけなんだろう?

Ken Okabe氏の22.9には

基本的に、プログラミングを含む工学では、なるだけ既存の数学的な概念と用語を踏襲すべきであって、同じ意味の造語を無闇に増やすことはあまり意味がないどころか、混乱をもたらすだけだと考えます。

という記述があります。私としてはこの記述に非常に同意します。Ken Okabe氏自身がこれを徹底していればもっと良かったと思います。

 

そうだね。でも中級者君は口では「非常に同意します」とかいうだけで、使えもしない、つかってもいないクライスリ圏の射という概念を、集合の圏で十分なところに積み増してるよね。

 

実行できてないじゃない。

 

僕は徹底しているからそんな用語は無用に使わないようになりました。初学者に教えることが目的で、君のように権利を借りて背伸びしてハッタリ効かせる、てのはむしろ目的の障害になるんですね。

 

だいたい、Haskellモナド関数でも、普段いちいち射(Morphism)だ、みたいに取り扱っているのかい?クライスリの射だ!とか普段やってる?やってないだろ?

それは「関数」と呼ぶんだよ。巷をみるとたとえばStackoverflowでもMonadFunctionでこの概念はやりとりされている。クライスリの射という用語自体のQAはあるんだろうが、モナドの関数の呼称としてやってるのなんて’見たこともない。自分でも普段そんなの使ってないくせに、なんで初学者に教えるようなフェイズで、突然えらそうに大上段から、

Haskellで言えば a -> m b みたいなやつです。圏論の文脈的には、これにはKleisli射という名前がついています。

みたいなことを言う必要がある?学習者ビビらせて偉そうにしようとしてる?

あと、僕に対してマウンティング取りたいだだけだろう?閲覧者にむけて良いカッコつけてメンツ保ちたいだけだろう?

全部キミの都合じゃないw

 

最後にうまいこと言ったと思ってるんだろうけど、自分でできてないことを賛同する、僕ができてることを、彼がもっと徹底できていればもっと良かった、とか、うまいこと言ったつもりなんだろうけど、正直、鼻で笑っているよ。

いかに中級者君のような態度が初学者の学習の妨げになっているのか自覚してほしいね。そんで僕の仕事に茶々入れてくんな、迷惑だし有害だし、君にそんな知見なんてないんだからさ。

以上かな!