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

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

 

を書きました。

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

の続編です。

 

ken-okabe.hatenablog.com

 

ken-okabe.hatenablog.com

 

 

Qiitaのトンデモな記事に反論していきます。

qiita.com

 

「【追記】」の部分はTwitterでの他の人の反応や氏のはてなブログによる反論を受けて記載したものです。

 

結局の所、自分で勝手に火がついて、よし岡部の本をネガキャンするぞネガキャンするぞ、とやっておいて、結構不条理でトンデモなデマを流されているわけです。

その上で、「自分には時間が無制限にあるわけではない」というような、身勝手な被害者ヅラをした挙句、ちょっとこちらがちゃんとした反論をしたら

氏のはてなブログによる反論を受けて記載したものです、とくる。

こちらは時間も手間もかけて書いた著作を愉快犯の誹謗中傷みたいにやられて、徹底的にやると思ってるんで、時間が、、、とか言うなら足りなくなるんじゃない?

すでに書いたように、僕は君の事は中級者というよりむしろ理不尽で意味不明な攻撃してくるトンデモだと思っているし、そこを放置したら、またややこしいことになるので、徹底的に詰めます。

 

【追記】もちろんC++やRustでも演算子オーバーロードはできますが、C++やRustを含む多くの言語では演算子としてあらかじめ決まった種類のものしか使えません。「パイプライン演算子がないから |> を演算子として使おう」ということはできないのです。一方で、上の段落で挙げたML系言語では(言語が許す種類の文字からなる)任意の記号列を演算子として定義することができます。元の文書の主題からすると任意の記号列を演算子として使える方が好ましいかと考えたのでStandard ML, OCaml, Haskellを挙げました。

 

「あらかじめ決まった種類のものしか使えません」

どーでもいいですね、そんなことは。

それに、|>というシンボル自体になにか数学的な意味が関与しているわけでもなんでもありません。で、またML最高の話ですか?

自分のより好みをもって、人の著作を批判とかしなさんなよ?って話です。

僕の本の内容の正しさとあなたの好みとか、「演算子のシンボルが限られてること」なんて関係ないでしょ。

 

【追記】このセクションは特に私の「感想」色が強く、人によって意見が異なることは自然なことだと思います。なので、あまりとやかく言い争う気はありません。

「感想」というか、あたかもこちらの技術的アプローチに問題がある、というようなニュアンスで中級者君は好評したんだね。誰でもそう読み取れる。

JavaScriptにおいて二項演算子を導入するメリットは大きく、それは本書の表記に大きく関与していて、文字数が多くなっただの行儀が悪いだの、ご丁寧にサンプルコードまでつけて、ネガキャンやった。

それで「感想」で人によって意見が異なる、とか、しれっと言う。まあ論評は自由だけど、理不尽なネガキャンはバズるので、こちらとしては看過しないし、言い争いは当然する。

 

【追記】initialValueを省略した場合に「加法の場合は0となる」「乗法の場合は1となる」という説明は間違っています。だって空配列に .reduce(add) を適用しても 0 は返ってこないでしょう?氏の反論記事では空配列のことを無視しており、私の文章の書き方が悪かったかなあと反省しております。

間違ってはいない。サンプルコードにおいては実際にそういう挙動になる、と整合的に理解できて、それは二項演算のFoldの理解に大変重要です。

 

空配列、空の値、Noneその他は、まるで別の問題で、各言語のFold/reduceの実装と一緒くたに論じるような話ではありません。

空の値のはなしはTypeの話であって、TypeScriptで空配列をどう扱うかにも関係してきます。

僕が中級者君がトンデモだと思うのは、数学の代数構造の話と、言語に実装されたreduceの仕様の挙動を一緒くたにして平気だということです。文章の書き方以前の問題だと思う。

 

【追記】私は「型≠集合」という立場なので関数型プログラミングモナドが集合圏上のモナドと同じものだとは思いません。

 

あなたは勝手にすれば良いが、こちらの立場を否定するな。

それは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記事からの引用文です。

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)の関係を理解しておくことが役立つことを私は発見しました。余計なことのように聞こえますが、それは貴方のマインドセットの形成に本当に役立つのです!

 

この役に立つ視点は、初学者にとっては非常に有用。

そしてnLab原文リンクを開いてみればわかるとおり、これはそもそも初学者相手に解説されているわけでもありません。

そして中級者君の勝手な趣味的な自己満足立場をもしこちらの立場が間違っていると印象操作する形で押し付けるならば、それは学習者全てにとって有害だ。

自分の考えを表明するのは自由だが、こちらがnLabその他の文献をひっぱって明確にしてるもんを否定する形で発言しないでほしい、迷惑なんで。

こうやって反論することでようやく彼らがフェアな判断ができるようになる。

なんで、nLabの元文献とか引用しない?

Qiita記事の閲覧者に読まれたら自分の主張が揺るぐ、賢明な読者ならばどっちの立場が正しく有用なのか、判断されて自分のメンツがつぶれることを恐れているからだろう?

君のメンツでこちらの著述が否定されることが本当に腹立たしい。

行儀の悪いやりかたしか君はできないんだね。

 

【追記】私は「型≠集合」という立場なので関数型プログラミングモナドが集合圏上のモナドと同じものだとは思いません。

 

それに、二項演算のはなしだよね。

wiki.haskell.org

 

f:id:stq2050:20211212130338p:plain

 

以上のようにHaskellにおいてモナドというのは、

>>= という二項演算子をもって、

二項演算の等式としてモナド則(Monadlaws)でもなんでも書かれているんだけど、

中級者君のトンデモ主張っていうのは、この眼の前の現実と合致しない。

中級者君の勝手な立場は黙ってくれたらそれで有害ではなくなるけども、

関数型プログラミングであつかう集合の圏のモナドは、

このように間違いなく二項演算子、として掲示されている現実がある。

 

現実のコードと、君の勝手な主張が不一致ならば、

間違っているのは中級者君であるのは間違いない。

いくらゴネようとも、もう無理筋だって閲覧者にバレていることだろう。

 

今回は以上です。

 

ken-okabe.hatenablog.com