Javaプログラマーのための圏論（はじめに）
Bartosz Milewskiによって書かれた「Category Theory for Programmers」と言う書籍の内容が以下で公開されている。
https://github.com/hmemcpy/milewski-ctfp-pdf
この書籍では、多くの具体的な説明はHaskellであり、一部C++で説明されている。 今回はこの書籍の内容を基にJavaで説明を試みた。数学の説明や論旨の展開はなるべき原書に沿っており、翻訳に近い形とした。 不十分なところも多々あると認識しているが、まず公開したいと思う。
現在は5章の積と余積までしかないが、今後順次増やしていく予定にしている。
はじめに
数節でこの本で書かれていること、「豊富な余暇」で数学の最も抽象的な一分野を学ばなければならないのかと言う異論が完全に事実無根であることについて説明しよう。
このような楽観論は幾つかの観察に基づいている。最初に、圏論は極めて有用なプログラミングのアイデアの埋蔵物である。Haskellプログラマーは長い間この資源を叩いてきており、そのアイデアはゆっくりと他の言語へ徐々に広がっているが、この過程は非常に遅い。もっとスピードを上げる必要がある。
二つ目に、多くの異なる種類の数学があり、それらは異なる読者にアピールしている。微積分、または代数にアレルギーがあるかもしれないが、それによって圏論が楽しめないと言うことはない。圏論はプログラマーの精神に特に合う数学の種類であるとまで主張する。それは圏論が、特別なものを扱うより寧ろ構造を扱うからである。それが扱うのは、プログラムを合成可能とするような種類の構造である。
合成は圏論の最も根本である。そして、それは圏自身の定義の一部でもある。合成はプログラミングの本質であると強く主張する。偉大なエンジニアはサブルーチンのアイデアを思いつくより前に我々は絶えず、長い間合成をしてきた。少し前に構造的プログラミングの原則がプログラミングに革命を起こした。なぜならそれがコードのブロックを合成可能にしたからである。その後、オブジェクト指向プログラミングが現れた。これは対象を合成することがすべてである。関数型プログラミングは関数と代数データ構造を合成するだけでなく、それは並行処理を合成可能としたが、他のプログラミングで事実上不可能な何かである。
三番目に、秘密兵器、肉切り包丁がある。それを使って、数学を食肉処理して、プログラマーにとってもっと口に合うようにする。専門的な数学者の立場であれば、非常に注意して、すべての仮定は正しく得られるように、すべての発言は正確に制限するように、証明は厳密に構成するようにする必要がある。このようにして、数学の論文や書籍は外部の者にとって極めて読むのが困難にしている。物理学では形式ばらない論法を使って驚くべき進歩を生み出してきた。数学者はディラックのデルタ関数を笑ったが、それは偉大な物理学者P.A.M.ディラックがいくつかの微分方程式を解くために即興で生み出したものである。ディラックの洞察を形式化した分布理論と呼ばれる微積分の完全に新しい分野を発見されると、彼らは笑うのをやめた。
もちろんごまかしの主張を使って明らかに誤ったことを述べるリスクを犯す時には、形式ばらない議論の背後にある厳密な数学的な理論が存在することを確かめるつもりである。ソーンダース・マックレーンの圏論の基礎 の使い古したコピーが寝室用のランプの上に置いてある。
プログラマーのための圏論なので、コンピュータ・コードを使って主要な概念の説明をする。関数型言語がより好まれている命令型言語と比べて数学に近いことに気が付くであろう。それはまたより抽象化する力を提供する。だから、自然な衝動で、圏論の報奨金が得られる前にHaskellを学ぶべきと言いたくなる。しかし、それは圏論が関数型言語の外側では適用できないことを暗示しているのではなく、単純に真実ではない。だから、多くのJavaの例を提供している。確かに醜い構文を乗り越えなければならず、パターンは冗長の背景より際立っていないかもしれないし、より高次な抽象化の代わりにコピー＆ペーストを強いられるかもしれないが、Javaプログラマーのすべてである。
経験豊富なプログラマーであれば、圏論や関数的なメソッドについて気に掛けることなくコードを書いてきた。何が変わるかと、尋ねるかもしれない。確かに、新たな関数型の特徴の厳密な傾向が命令型言語に広がっていくことに気付くだけかもしれない。オブジェクト指向プログラミングの要塞、Javaにさえ、ラムダ式が取り入れられた。大きな変化を駆動する強制力の一つがマルチコアの革命である。広く行き渡っているプログラミング・パラダイム、即ちオブジェクト指向プログラミングは並行処理の領域では何ももたらさず、その代わりに危険でバグを生みやすい設計を奨励する。データの隠蔽化、オブジェクト指向の基本的な前提は、共有とミューテーションと組み合わさった時、データレースの処方箋となる。データの持つミューテックスを組み合わせると言うアイデアはデータを保護するには便利であるが、不幸にも、ロックは合成しないし、ロックによる隠蔽はデッドロックを起こしやすくなるし、デバッグもより困難となる。
しかし、たとえ並行処理がなかったとしても、ソフトウェアが益々複雑になっていくことで、命令型パラダイムのスケーラビリティの限界を試されている。短く言えば、副作用は手に負えなくなってきている。確かに、副作用を持つ関数はよく重宝されていて、書きやすい。原則としてそれらの高価は名前とコメントでエンコードすることができる。SetPasswordやWriteFileと呼ばれる関数は明らかに何らかの状態を変化させるし、副作用を生み出し、それを扱ってきている。副作用のある関数を直ぐに他の副作用のある関数と合成し、次々と合成していくだけで、身の毛もよだつことが始まる。副作用は本質的に悪いのではないが、それらが隠蔽されることで、大規模で管理できないようになることも事実である。副作用はスケールしないし、命令型プログラミングは副作用がすべてである。
ハードウェアの変化とソフトウェアの複雑性の増大により、プログラミングの基礎を再考することに迫られている。ヨーロッパのゴシック教会の建築家のように、材料と構造の限界に対する技術を磨いてきた。フランス、ボーベの終わりのないゴシック教会がある。それは人類の限界への深い闘争の証人である。高さと明るさの以前の記録を乗り越えようとしたが、一連の崩落に苦しめられた。鉄棒と木製素材のような場当たり的な対策で、それを崩壊から防いでいるが、明らかに多くの物が間違った方向に進んでいる。現代的な視点でみると、現在の材料科学、コンピュータ・モデリング、有限要素分析、及び一般的な数学と物理学の助けを借りずに、これほど多くのゴシック構造物が成功裏に完成されてきたことは奇跡である。将来の世代が。複雑なオペレーティングシステム、ウェブサーバ、インターネット・インフラストラクチャを構築することを誇示するようなプログラミング技術を称賛するようになることを期待する。率直に言えば、非常にもろい理論的な基礎に基づてすべてのことを行おうとしている。もし前に進みたいのであれば、それらの基礎を確固としたものにしなければならない。
