  |
はてなキーワード:モナドとは
日中は実験室的な刺激は少なかったが、思考の連続性を保つために自分なりの儀式をいくつかこなした。
起床直後に室温を0.5度単位で確認し（許容範囲は20.0±0.5℃）、その後コーヒーを淹れる前にキッチンの振動スペクトルをスマートフォンで3回測定して平均を取るというのは、たぶん普通の人から見れば過剰だろう。
だが、振動の微妙な変動は頭の中でのテンポを崩す。つまり僕の「集中可能領域」は外界のノイズに対して一種の位相同調を要求するのだ。
ルームメイトはその儀式を奇癖と呼ぶが、彼は観測手順を厳密に守ることがどれほど実務効率を上げるか理解していない。
隣人はその一部を見て、冗談めかして「君はコーヒーにフレームを当ててるの？」と訊いた。
風邪の初期症状かと思われる彼の声色を僕は瞬時に周波数ドメインで解析し、4つの帯域での振幅比から一貫して風邪寄りだと判定した。
友人たちはこの種の即断をいつも笑うが、逆に言えば僕の世界は検証可能で再現可能な思考で出来ているので、笑いもまた統計的に期待値で語るべきだ。
午前は論文の読み返しに費やした。超弦理論の現代的なアプローチは、もはや単なる量子場とリーマン幾何の掛け合わせではなく、導来代数幾何、モーダルなホモトピー型理論、そしてコヒーシブなホモトピー理論のような高次の圏論的道具を用いることで新たな言語を得つつある。
これらの道具は直感的に言えば空間と物理量の振る舞いを、同値類と高次の同型で記述するための言語だ。
具体的には、ブランデッドされたDブレーンのモジュライ空間を導来圏やパーフェクト複体として扱い、さらに場の有る種の位相的・代数的変形が同値関係として圏的に表現されると、従来の場の理論的観測量が新しい不変量へと昇格する（この観点は鏡映対称性の最近のワークショップでも多く取り上げられていた）。
こうした動きは、数学側の最新手法が物理側の問題解像度を上げている好例だ。
午後には、僕が個人的に気に入っている超抽象的な思考実験をやった。位相空間の代わりにモーダルホモトピー型理論の型族をステートとして扱い、観測者の信念更新を型の変形（モナド的な操作）としてモデル化する。
つまり観測は単なる測定ではなく、型の圧縮と展開であり、観測履歴は圏論的に可逆ではないモノイド作用として蓄積される。
これを超弦理論の世界に持ち込むと、コンパクト化の自由度（カラビヤウ多様体の複素構造モジュライ）に対応する型のファミリーが、ある種の証明圏として振る舞い、復号不能な位相的変換がスワンプランド的制約になる可能性が出てくる。
スワンプランド・プログラムは、実効場の理論が量子重力に埋め込めるかどうかを判定する一連の主張であり、位相的・幾何的条件が物理的に厳しい制限を課すという見立てはここでも意味を持つ。
夕方、隣人が最近の観測結果について話題にしたので、僕は即座に「もし時空が非可換的であるならば、座標関数の交換子がプランクスケールでの有意な寄与をもたらし、その結果として宇宙加速の時間依存性に微妙な変化が現れるはずだ。DESIのデータで示唆された減速の傾向は、そのようなモデルの一つと整合する」と言ってしまった。
隣人は「え、ホント？」と目を丸くしたが、僕は論文の推論と予測可能な実験的検証手順（例えば位相干渉の複雑性を用いた観測）について簡潔に説明した。
これは新しいプレプリント群や一般向け記事でも取り上げられているテーマで、もし妥当ならば観測と理論の接続が初めて実際のデータで示唆されるかもしれない。
昼食は厳密にカロリーと糖質を計算し、その後で15分のパルス型瞑想を行う。瞑想は気分転換ではなく、思考のメタデータをリセットするための有限時間プロセスであり、呼吸のリズムをフーリエ分解して高調波成分を抑えることで瞬間集中力のフロアを上げる。
ルームメイトはこれを「大げさ」と言うが、彼は時間周波数解析の理論が日常生活にどう適用されるか想像できていない。
午後のルーティンは必ず、机上の文献を3段階でレビューする: まず抽象（定義と補題に注目）、次に変形（導来的操作や圏論的同値を追う）、最後に物理的帰結（スペクトルや散乱振幅への影響を推定）。
この三段階は僕にとって触媒のようなもので、日々の思考を整えるための外骨格だ。
夜は少し趣味の時間を取った。ゲームについては、最近のメタの変化を注意深く観察している。
具体的には、あるカードゲーム（TCG）の構築環境では統計的メタが明確に収束しており、ランダム性の寄与が低減した現在、最適戦略は確率分布の微小な歪みを利用する微分的最適化が主流になっている。
これは実際のトーナメントのデッキリストやカードプールの変遷から定量的に読み取れる。
最後に今日の哲学的なメモ。理論物理学者の仕事は、しばしば言語を発明することに帰着する。
僕が関心を持つのは、その言語がどれだけ少ない公理から多くの現象を統一的に説明できるか、そしてその言語が実験可能性とどの程度接続できるかだ。
導来的手法やホモトピー的言語は数学的な美しさを与えるが、僕は常に実験への戻り道を忘れない。
理論が美しくとも、もし検証手順が存在しないならば、それはただの魅力的な物語にすぎない。
隣人の驚き、ルームメイトの無頓着、友人たちの喧嘩腰な議論は、僕にとっては物理的現実の簡易的プロキシであり、そこから生まれる摩擦が新しい問いを生む。
さて、20:00を過ぎた。夜のルーティンとして、机の上の本を2冊半ページずつ読む（半ページは僕の集中サイクルを壊さないためのトリックだ）
あと、明日の午前に行う計算のためにノートに数個の仮定を書き込み、実行可能性を確認する。
ルームメイトは今夜も何か映画を流すだろうが、僕は既にヘッドホンを用意してある。
ヘッドホンのインピーダンス特性を毎回チェックするのは習慣だ。こうして日が終わる前に最低限の秩序を外界に押し付けておくこと、それが僕の安定性の根幹である。
以上。明日は午前に小さな計算実験を一つ走らせる予定だ。結果が出たら、その数値がどの程度「美的な単純さ」と折り合うかを眺めるのが楽しみである。
僕は今、いつもの座席に鎮座している。ルームメイトはリビングのソファでパズルゲームを無言で進めており、隣人はサブカル系の配信をしているらしく時折笑い声が廊下を渡ってくる。
友人たちはグループチャットで熱く同人の出来や新連載のガチャ確率について論争している。
僕の一日は厳密に区切られていて、朝は必ず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 でメモ化したい関数ってどうするんだろう
という条件なので、キャッシュを取って、キャッシュになければ計算して返すクラスを作った
純粋関数型でこれをやろうとするとモナドになったりして面倒臭そう
しかしながら
と思ったのですがどうなんでしょう。
