  |
はてなキーワード:モナドとは
僕は今、いつもの座席に鎮座している。ルームメイトはリビングのソファでパズルゲームを無言で進めており、隣人はサブカル系の配信をしているらしく時折笑い声が廊下を渡ってくる。
友人たちはグループチャットで熱く同人の出来や新連載のガチャ確率について論争している。
僕の一日は厳密に区切られていて、朝は必ず8時に起床、コーヒーの抽出器具を90秒で予熱し、温度は92.3℃±0.2℃に保つという無駄に精細な儀式がある。
靴下は左足から履く。出勤前の15分は必ず抽象数学のノートを眺め、最近は圏論的位相場のホモトピー的反復と超弦モジュライのmeta-圏的安定化について自問している。
これは専門用語の羅列ではなく、僕にとっては手を洗うのと同じくらい生理的な行為であり、その行為を飛ばすと一日が微妙に狂うので飛ばすことはめったにない。
仕事が終わった今も、僕は一日の終わりに形式的整合性を取るためのルーティンを持っている。
具体的には、机上のコップは時計回りに90度ずつ回転させて元の位置に戻す、明かりのスイッチを一回押して3秒待ち、もう一度押すといった小さなチェックポイントを踏む。
これは合理的かどうかを問う人がいるだろうが、僕にとってはエラー訂正符号のようなものだ。失敗を検出すると自動的にその日のメンタル状態のトレースが始まり、友人たちの雑談に混じる気力が萎える。
超弦理論に関して今日述べることは極めて抽象化され、現実の誰が読んでも「それが何を意味するのか」を即座に把握できないように意図している。
僕は最近、モノイド対象としてのストリング世界面の圏を、圏論的対称化子（コクセター的ではなく、もっと抽象的に、位相的量子群の代数的類・モジュライ化）を用いて再定義する実験をしている。
言い換えれば、従来の共形場理論的な世界面パラメータ空間を、非可換ホモトピー論のフィルタ列で再帰的に層化し、その各層におけるファイバーの自己同型群をモナドとして扱うことで、局所的に見える弦状態の同値類を圏的に集約する。
さらに、圏の圏（2-圏）に対する新しい安定化の概念を導入して、通常のK理論的分類とは別の不変量が現れることを示唆する予備的計算結果がある（ここでは具体的数式を列挙しないが、ホモロジーの級数展開における位相的位相因子の再正規化が鍵となる）。
この構成を、最新の抽象数学的モジュール接続概念と結びつけると、我々が従来想定していたスペース-状態対応の双対性が、もっと弱い条件（例えば圏的可換性の高次緩和）で成立する可能性が開ける。
加えて、僕はこの考えをある講義資料やトークの示唆と照らして取り入れており、その資料は概念的な跳躍と直感的な図示を巧みに使っているので、僕の現在の探索にとって非常に有益だった。
僕は「誰も理解できないものを言語化する」ことに快感を覚えるタイプだが、ここで言っているのは自己満足のためではなく、圏的再構成が実際に計算上の省力化をもたらすかを検証するための試行でもある。
ある意味で、これは純粋数学者が夜中に自分だけの公理系をいじるのと同じ行為だが、僕の場合はそれを出社前の歯磨きに組み込んでしまっているので、周囲は迷惑かもしれない。
食事の配列はプレート上の分布エントロピーを最小化する向きで常に配置し、週に一度は手製のスキルツリー表を更新して趣味的投資の累積効用を整数化している。
コミックは最新巻が出ると即座にページごとのフレーム密度と作画のトーンワークを技術的に解析し、特に背景のディテールに含まれるトーンの反復パターン（いわば視覚的フーリエ成分）をスコア化する。
ゲームに関してはガチ勢的態度を崩さず、メタ的な語りを排してシステムのギミック、ドロップ率、レベリング曲線、そして対戦環境のテンプレート化された最適戦略について延々と解析する。
ただしゲームやコミックに対しては「空間」や「力学」といった語はなるべく避け、代わりに「状態遷移図」や「入力遅延とフレーム落ちの統計的扱い」など工学的・計算機的に言語化する。
たとえば今日友人が語っていた新作のギミックについては、その期待効用をELO的な評価尺度でランク付けして論争に勝とうとしたが、連中は「推し」を盾に論理を流してくるので僕はたまに脱力する。
だが脱力する暇は短く、夜の自習時間には再び圏論的比喩に戻り、各行動の符号化を試す。
日常の細部も大事にしている。玄関の鍵は4回回すのが正しいというオカルトじみたルールを持っているが、これは単なる迷信ではなく、僕の内部的なチェックサムである。
友人たちはこれを笑うが、彼らもまた各自の無意味な儀式に固執している。
コミュニティでの嗜好（推しキャラ、嫁、沼の深さ）に関しては妙に合理的で、僕はデータベースを自前で持っている。
各キャラの台詞数、出番頻度、描写の感情強度をパラメータ化し、二次創作が生成される確率空間を推定する実験をしている。
この種のオタク計量は笑われがちだが、実際にはコンテンツ開発や同人活動の動向を予測するには有用だ。
眠りに入る前に、僕は明日の論文ノートに小さな疑問を三つ書き付ける。
第一は、先に述べた圏的安定化が有限次元表現に落ちる際の可逆元の振る舞い、第二は同構クラスの計算可能性のアルゴリズム的複雑さ、第三は趣味領域における情報量の測度とその心理的飽和点の関係である。
これらを洗い出しておけば、僕は安心して眠れる。
ルームメイトがゲームのボスを討伐した歓声が聞こえ、隣人の配信が締めに入る。友人たちのチャットは未だヒートアップしている。
僕は日記を閉じ、明日のコーヒーの豆を2グラムだけ余分に計量しておく。これは単なる癖ではない。それは帰納的に我が生活を安定化するための小さな公理群だ。
フェミニズムの分類が多すぎると聞いて
記述集合論（Borel階層, Projective階層, 汎加法族）
モデル理論（型空間, o-極小, NIP, ステーブル理論）
再帰理論/計算可能性（チューリング度, 0′, 相対計算可能性）
構成主義,直観主義,ユニバース問題,ホモトピー型理論（HoTT）
体論・ガロア理論
表現論
K-理論
初等数論（合同, 既約性判定,二次剰余）
解析数論（ゼータ/ L-関数,素数定理,サークル法, 篩法）
p進数論（p進解析, Iwasawa理論, Hodge–Tate）
超越論（リンドマン–ヴァイエルシュトラス, ベーカー理論）
実解析
多変数（Hartogs現象, 凸性, severalcomplex variables）
関数解析
バナッハ/ヒルベルト空間,スペクトル理論, C*代数, von Neumann代数
フーリエ解析,Littlewood–Paley理論, 擬微分作用素
確率解析
常微分方程式（ODE）
偏微分方程式（PDE）
非線形PDE（Navier–Stokes, NLS, KdV, Allen–Cahn）
幾何解析
リッチ流, 平均曲率流,ヤン–ミルズ,モノポール・インスタントン
エルゴード理論（Birkhoff, Pesin）,カオス, シンボリック力学
点集合位相,ホモトピー・ホモロジー, 基本群,スペクトル系列
4次元トポロジー（Donaldson/Seiberg–Witten理論）
複素/ケーラー幾何（Calabi–Yau, Hodge理論）
スキーム, 層・層係数コホモロジー, 変形理論, モジュライ空間
多面体, Helly/Carathéodory,幾何的極値問題
ランダムグラフ/確率的方法（Erdős–Rényi, nibble法）
加法的組合せ論（Freiman, サムセット, Gowersノルム）
彩色,マッチング,マイナー理論（Robertson–Seymour）
列・順序・格子（部分順序集合, モビウス反転）
測度確率, 極限定理, Lévy過程, Markov過程, 大偏差
統計学
ノンパラメトリック（カーネル法, スプライン,ブーストラップ）
時系列（ARIMA,状態空間, Kalman/粒子フィルタ）
非凸最適化
離散最適化
整数計画,ネットワークフロー, マトロイド, 近似アルゴリズム
Littleの法則, 重み付き遅延, M/M/1, Jackson網
エントロピー,符号化（誤り訂正, LDPC,Polar）, レート歪み
公開鍵（RSA,楕円曲線, LWE/格子）,証明可能安全性,MPC/ゼロ知識
計算複雑性
機械学習の数理
量子場の数理
相転移, くりこみ, Ising/Potts, 大偏差
数理生物学
数理神経科学
データ解析
モナドの領域と比べると博士の愛した数式は出てくる数理概念のレベルが低すぎるんだよね？
TAIKUTSU!
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250928160549# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaNjeUgAKCRBwMdsubs4+SBUbAP0VL+tSu1Po3wrQaHIqPFMdns2XnwoEJyuHpT7sYg/LgwD8C0NH9smRhcpIEGvEuVsTmNdtTnaazvqqBpfQ7eS1SQ4==eZZp-----ENDPGP SIGNATURE-----
プログラミングの原理を抽象化するなら、実際の構文や言語の枠をすべて剥ぎ取って、最小限の計算の本質だけを残す必要がある。
状態の変換:プログラムとは、入力状態を出発点として、規則に従い別の状態へ変換する体系である。
あらゆるプログラミング言語・パラダイムは、以下の要素に還元できる。
1.表現:対象世界を「記号・データ」として写像する。数・文字列・構造体・グラフなどはすべて表現の形態にすぎない。
2. 変換:表現を別の表現に写す規則。関数呼び出し・代入・パターンマッチング・ループなどはすべて「変換」の特殊形。
3.制御: 変換の適用順序を規定する。再帰・分岐・逐次処理・並列処理・非決定性などを含む。
4.資源:時間・記憶・入出力チャネルなど。プログラムはこれら有限資源の制約下で変換を実行する。
あらゆる技術ツールの存在意義は「人間の課題を解決すること」にある。
どれほど理論的に優れていても、使われなければ社会的影響はゼロであり、開発・保守・学習のコストに対するリターンも生まれない。
ツールは道具であり、「賢い者だけが扱える道具」は、実際の現場ではほとんど役に立たない。
例えるなら、戦場において「取り扱い説明書を10回読まないと撃てない銃」は、正確でも美しくても役立たない。
瞬時に理解され、即応可能であることが、実用の第一条件である。
ここで言う「馬鹿にもわかる」とは、知識レベルが高くないユーザーでも直感的に使える・理解できるという意味である。
これはユーザビリティ、学習曲線の緩やかさ、エラー時の挙動の親切さなどに現れる。
この観点からすると、「馬鹿にもわかる」設計は、実は賢い設計である。
人間の認知限界や行動パターンを理解し、誤操作を予防し、意図を汲み取って補完できるシステムは、万人にとって有益であり、結果として普及しやすく、フィードバックループによってさらに改善される。
Haskellは、理論的には極めて美しい言語であり、型システムの厳密さ、関数型の純粋性、抽象化の高さなど、形式的な正しさにおいて群を抜いている。
つまり、Haskellは「形式的正しさを最優先した結果、人間の直感と乖離し、現実世界との接続性が弱まった」道具である。
実際のソフトウェア開発現場では、エンジニアの入れ替わり、ドキュメントの不備、締切、バグ対応など、理想とは程遠い要素が日常的に存在する。
したがって、ツールは「賢い人が完璧に使いこなせば強力」ではなく、「凡人が雑に使っても一定の成果が出る」ことが求められる。
この点で、PythonやBashは「馬鹿にもわかる」ことを最優先し、結果として世界中で圧倒的に使われている。これは単なる偶然ではなく、設計哲学の勝利である。
道具は使われて初めて価値を持つ。そして「馬鹿にもわかる」ことは、使われるための最重要条件である。
Haskellのように理論的に優れていても、「現場に届かない美しさ」は、ツールとしての有用性を損なう。
巻き込まれてる側面もあるけど、信号処理の理論を理解できないと信号処理の関係のソースコードが読めない人種というのが意外といる。
そして、信号処理の理論は簡単なものでも高校の数学をある程度理解してる前提で書かれてる。
あと、コンパイラーとかセグメント木あたりに手を出すとわかるけど、モナドとかオートマトンとか数学由来の訳の分からん単語があほみたいに出てくる。
かといってここら辺はライブラリーがライセンスの関係で使えなかったり、ライブラリーを使えたとしても、ライブラリーだとパフォーマンスを追求するうえで手がとどかないみたいなことが割とあって…
つい最近も
B+Treeのキーをバカまじめに更新してると「さくさくエディター」並みの速度を出せないなあ…
かといって色々調べても難しいなあ…
モナドって何？
みたいなことがつい最近起きたばかりだ
コーンフレークじゃなくて、Haskellだとして、全体のネタを書き直してくださいっていう指示した結果
ボケ＆ツッコミ「お願いしますーありがとうございますー」
ツッコミ「あーありがとうございますー ねっ 今Githubでスターをいただきましたけどもね」
ボケ＆ツッコミ「ありがとうございますー」
ツッコミ「ねー 有り難いですよ ほんとにね」
ボケ「入れておきましょう」
ボケ「いきなりですけどね うちのオカンがね 好きなプログラミング言語があるらしいんやけど」
ツッコミ「プログラミング言語の名前忘れてもうて どうなってんねそれ」
ツッコミ「分からへんの？ いや ほな俺がね おかんの好きなプログラミング言語 ちょっと一緒に考えてあげるから どんな特徴ゆうてたかってのを教えてみてよ」
ボケ「あのー関数型言語で、型システムが強力で、遅延評価するやつやって言うねんな」
ツッコミ「おー Haskellやないかい その特徴はもう完全にHaskellやがな」
ツッコミ「すぐ分かったやん こんなんもー」
ツッコミ「いやそうやろ？」
ボケ「オカンが言うには 将来の夢はそれで書かれたOSを使うことやって言うねんな」
ツッコミ「あー ほなHaskellと違うかぁ Haskell製のOSなんてまだ無いもんね」
ボケ「そやねん」
ツッコミ「HaskellはOSを作るのには向いてへんからなぁ」
ボケ「そやねんな」
ツッコミ「な？ Haskell側もOS開発に任命されたら荷が重いよあれ」
ボケ「そやねんそやねん」
ツッコミ「Haskellってそういうもんやから ほなHaskellちゃうがなこれ」
ボケ「そやねん」
ツッコミ「あれほなもう一度詳しく教えてくれる？」
ツッコミ「Haskellやないかい モナドは確かに難しいねんHaskellの でも俺はね あれはHaskellの良いところやと思うねん 俺の目は騙されへんよ 俺騙したら大したもんや」
ボケ「まあねー」
ツッコミ「ほんであれよー いざ使ってみたらね モナドのおかげでコードがスッキリするねん 俺は何でもお見通しやねんから Haskellのモナドなんて」
ツッコミ「そうやろ」
ボケ「オカンが言うには プロダクションで使うにはまだ早いって言うねんな」
ツッコミ「ほなHaskellちゃうやないかい プロダクションでHaskell使ったら 上司がひっくり返すもんね Haskellはねー まだ研究段階やから実務では使いにくいねん」
ボケ「そやねんそやねん」
ツッコミ「な？ Haskell使ってみたらだんだん罠が見えてくるから 最後ちょっとだけ避けてまうねんあれ」
ボケ「そやねんそやねん」
ボケ「そやねんな」
ツッコミ「Haskellちゃうがな ほな もうちょっとなんか言ってなかった？」
ボケ「学生の頃 なんでみんな憧れるんか分からんかったらしいねん」
ツッコミ「Haskellやないかい 学生の頃はHaskellとOCamlとLispに憧れるんやから あとSmalltalkも憧れたな Haskellそんなもんよ」
ツッコミ「そうやろ」
ボケ「オカンが言うには 関数型プログラミングの教科書に必ず載ってるっていうねん」
ツッコミ「ほなHaskellやないかい 教科書のサンプルコードにHaskellのコードが出てこんわけないやん」
ツッコミ「Haskellはね 関数型プログラミングの王道中の王道やねん」
ツッコミ「Haskellや絶対 ほな ほなもうちょっとなんかゆうてなかったか？」
ツッコミ「Haskellやないかい Yesodとかあるやろ な？ RubyとかPythonの次はHaskellが来るって言われてるねん 俺はそう思うよマジで Haskellや絶対」
ツッコミ「そうやて」
ボケ「オカンが言うには ジャンルでいうたら数学やっていうねん」
ツッコミ「ほなHaskellやないかい ジャンルで数学言うたらHaskellしかあらへんやん な？ Haskellは数学の理論がベースになってるんやで ラムダ計算とか圏論とかな」
ボケ「そやねんそやねん」
ツッコミ「ほなHaskellに決まりやないかい ほなもうちょっとなんかゆうてなかった？」
ツッコミ「Haskellやないかい Haskellは変数が不変やから 変数に感謝するのは当然やねん ね？ 状態変更せんと安心して使えるからな」
ボケ「そやねんそやねん」
ツッコミ「Javaとかの変数は裏切るからアカンねん Haskellの変数は一生そばにおってくれるから最高やで」
ボケ「でも分かれへんねん」
ツッコミ「分からへんことない おかんの好きなプログラミング言語はHaskell もぉ」
ボケ「でもオカンが言うには Haskellではないって言うねん」
ツッコミ「ほなHaskellちゃうやないかい オカンがHaskellではないと言うんやから Haskellちゃうがな」
ボケ「そやねん」
ツッコミ「先ゆえよ 俺がラムダ計算の説明してる時どう思っててんお前」
ツッコミ「ホンマに分からへんがなこれ どうなってんねんもう」
ボケ「んでオトンが言うにはな」
ツッコミ「オトン？」
基本情報・応用情報試験みたいなのとか、CPUの仕組み、コンパイラの実装、分散システムやデータベースとかそういうエンジニアリングガチ勢みたいなのをイメージして大学でCSを学ぶとけっこうショックを受けるぞ。
俺の知ってるCSは、チューリングマシンの表現能力とか停止性問題とかYコンビネーターとかチャーチ数とかの世界で、コンパイラといってもε-CLOSUREみたいな話をじっくりやる感じ。
具体的な話が全然出てこない数学の一ジャンルってイメージかもな。
競技プログラミングみたいなアルゴリズムもそれほど時間をかけない。ベイズ推定をギリやるかどうか。
そういう知ればすぐ身につくものよりも、めちゃくちゃ考えて濃厚なパラダイムを時間をかけて吸収するような学問だった。
で、そんなCSを学んで直接役に立つのは多くの人の場合計算量のオーダーとかくらいかも。
モナドみたいな概念に抵抗なくなるとか、ラムダ式の意味を深く理解できるというのもあるけど、それSIとかWebやスマホアプリの開発業務で必要かというとね。
賢い人は、ちゃんとSNSのユーザー同士の関係性とかレコメンデーションみたいのにもCSの知識を応用できると思うけど、一般人は賢い人が作ったライブラリを使う側だよね。
Haskellと圏論を結びつける主張には前々からずっと疑問を感じている。
およそ、その主張の根拠は「圏論の概念であるモナドを借りてきたからだ」というのだが、その言葉の意味を突っ込んで追求した人はいないのだろうか。
数学科として、ある程度圏論を学んだ身として疑問に思ってしまうのが、
つまり、総合的に、「Haskellは圏論を用いることで副作用や参照透過性などのプログラミング言語の課題を解決したのだ」というよくある主張が、全然ピンと来ない。
この辺突っ込んでちゃんと解説している専門書はないのだろうか？
第一、第二、第三の疑問いずれに対しても、満足のいく回答は得られず、ただ「モナドは圏論由来の概念だ」というだけだ。
もしかして何か、圏論という一般にはよく理解されていない概念の言葉を良いように使って、なんだか深淵で素晴らしいもの聞こえるよう、同業者を適当にだまくらかしているんじゃないのか？とすら思えてしまう。
| 対象 | 型 |
| 射 | 関数 |
単にHaskellの文法を学ぶだけで、背後にある考え方（圏論）は、まだ知らなくてもOK。
圏論は元々数学で考案された考え方なので、直接的には代数やとトポロジーの知識が必要になるが、そこまでのレベルは求めていない。
とりあえず、プログラミングで使える程度の初歩的なレベルの理解で十分。
圏論の知識を基にして、Haskellの文法や仕組みを見直してみる。
型注釈は対象を定義して、関数は射を定義していることが分かる。
最近はGoが流行っているが、それならJavaだって同様に良さそうな気がする。
- nullがたまにうざい
- なんか重厚な感じがする
- ORMとかが重厚なのが多かった
- 故に環境構築が大変だった
-strutsがしんどかった
-xml地獄からアノテーション化したりいろいろと模索していた
-ちょっと昔には「俺たちイケてるプログラマ」はみんなRailsに移っていった流れがあった？
- EffectiveJavaよいが、そもそもそういうtips意識せずにそう書けるような言語仕様になってほしかった気もする
- 非同期処理やスレッド処理がやや難しかったか、あるいは言語側でのサポートが薄かったか(?)
言語仕様的な批判と、エコシステム的な批判に分けられそうなきがするな。
関数型言語の関心はScalaやClojureに全フリしてもらって、Javaはシンプルな機能を持つGoの方向性なModanJavaになっていってくれれば良さそうな気も。
httpサーブレットとかそのへんが微妙だったかもしかして。Goみたいにnet/httpライブラリが標準であればそれをベースにすることでオレオレフレームワークの乱立を避けることができるか、と思ったけどJAX-RSとかがあるな。
Goだって冗長な記述が必要な言語だが、好かれているし、Javaも悪くない言語な気がするんだよな。
まあ何でもいいが。
ロジカルに考えているようで結局なところ雰囲気的なところに左右されているエンジニア多い気がする。
まあわいも、人気な言語に乗っておいて高単価を得られたほうがいいのでそうするが。今の所Goが肌にあっているんだよな・・。3年ぐらい使って熟練度上がってきたし、さほど悩まずにコーディングすることができる。
PHPの人が好きな、あるいはRubyのmethod_missingなど活かしたテクいコードは、書いているやつは気持ちいいかもしれないがわいは明示的にinterfaceがわかるコードが書かれていたほうが好きだ。型で振る舞いがわかったり制御されていないと分かりづらくない？複数のプロジェクトを掛け持ちするから、読むときに前提知識が少なく読めるコードがいい。
まあJavaもリフレクションでテクいことができる気がするな。
Goがいい。誰が書いてもだいたい同じコードになるから、誰かに作業を振ったとしてもレビューしやすい。
まあこれからJavaを書く気はしないが、GoでAPI書いているマンから見ると、JAX-RSとかでゴリゴリAPI書いていくの全然悪くないんじゃないかと思うのであった。
最悪別にGeneric入らなくてもいいかもな。別にそんなに困ってない。はいってくれるなら、はいってくれたほうがいいが。sliceに対してmap, each, filter, existsなどのメソッドが生えることになるイメージかな。まあそれは欲しくなるけどな・・・。
Scalaもいいんだが、たまにイキったコードを書くと分かりづらくなる時がある。イケてるコードを書こうと思ったとき、結構パワーを使う言語だ。なんかモナドってジェネリックを更に強くしたやつだとも捉えられるような気がするな。ゴリゴリ関数型で書こうと思った場合、プロジェクト全体に影響がある話なのでアーキテクチャ設計に力がいる気がする。
年をとると大事にするポイントが変わってくるな。昔はスーパープログラマになりたくて関数型言語とかやっていたが、今はいかに効率よく仕事をする＝金を稼ぎ自由を得るかを重視している。職業プログラマとなったわけだ。仕様固めたりリリースしたり不具合対応したり運用したり、フリーランスなら税金計算したり、金儲けの方法考えたり忙しいんじゃ。今は結局スーパープログラマとは何か悩ましいよ。「プログラマとして」キチガイレベルにすごい人間というのはまだ見たことがないかもしれない。コーディングが早い？バグ修正が早い？パフォーマンスのやばいコードを書ける？設計が優れている？
最近はレバレッジが効く言語とフレームワークを好きになるようになってきた。
もう言語何でもいいわ。やっぱ静的言語がいいのと十分に熟練度がついてきたのでAPI開発ではGolang使って開発するのは良い。PHP(Laravel)、Ruby(Rails)はやはり生産性が高いので良い。ScalaもMonad Transformerを使ってモナドのスタックを解決していく程度あれでやっていき、あまり悩まないような構成になっていればサクサクやっていけそう。
実はJavaが一番いいんじゃないか…。Springガッツリやったこと無いけど、トランザクションとかもいい感じに効いてくれそうだし、そこそこ生産性高そうだし。
知らんけど。
なんでもいいや。
実を言うと、普通のプログラマはオブジェクト指向以前のプログラミングも理解できないんだけど、あれらはまだ手続き的な要素を内在してるから、そっちだけを受け取ることはできる。
それまで手続き的な要素＋宣言的な要素だったプログラミングが、関数型プログラミングへと移行する時に手続き的な要素を切り捨てたのね。より純粋な手法に進化するために。
だから、それまで手続き部分だけを受け取って喜んでた普通のプログラマは急にわからなくなりヒステリーを起こした。
だけど、プログラミング上級者はオブジェクト指向以前にも宣言的な部分しか見てないから普通のプログラマが何を騒いでるのかわからない。
普通のプログラマって、部品化の凄いやつが関数型プログラミングになるとか勘違いしがちだけど(staticおじさんもその変奏)、全く質の違うもの。
部品化って、重複コードをひすたらサブルーチンに括り出すようなもの。副作用がある。
日本のSIer(日立NEC富士通とか)って教養がない極東の田舎者だから、副作用を理解できない。すぐに「部品化」を持ち上げる。怖いんだろう。自分に理解できないプログラミングが。モナドですら大多数は理解できないんだもの。あんな教科書的なものですら。
とにかくアジアってIT後進国なのね。トップの日本ですらこうなのだから。"NTT"データがHaskellでレガシーシステムを脈絡なく解析してホルホルしてるレベルだもの。
まず日本に生まれた時点で、関数型プログラミングを理解するには圧倒的に不利。こんなこと言うと、「普通のプログラマにもわかやすく説明できるのが一流ダー」みたいな恥ずかしい駄々っ子が沸いてくるけど、プログラミングって歴史上一度も大衆を相手にしてないので。
OSSの恩恵で、普通のプログラマもコンパイラを無料で使えるようにになっただけで泣いて喜ぶべき。
そしてあれは、将来のスポンサーとコミッタの入り口としてやってるの。1000人に1人、将来コミュニティに貢献する人材がいるかもしれないと信じて。
シリコンバレー住人にもOSSコミッタにもなれない普通のプログラマはまあ、おこぼれで"文化的"コスプレしてQiitaでもやればいいんだと思うよ。
Haskell を書いてるわけではないんだけどHaskell でメモ化したい関数ってどうするんだろう
という条件なので、キャッシュを取って、キャッシュになければ計算して返すクラスを作った
純粋関数型でこれをやろうとするとモナドになったりして面倒臭そう
しかしながら
と思ったのですがどうなんでしょう。
