どの様な話？
かなりアウトプットの間が空きましたが、言うべき事が無くなった為でした。
しかし、１つ思いつきました。
それは、
- 数学的抽象化を使う際、
- それが社会実装を伴う場合、
- 絶対的にしてはいけない事
です。それは、
- 抽象化して、何かを隠す（「本質的でない細部を削ぎ落す」）場合、
- ダメな、出来ない事を隠すのは禁忌
では無いかという事です。
- 良い、上手く行く、を隠すべきです。
例１（制御の反転）
制御の反転（Wikipedia 日本語版）では、
- 上位モジュールはただ「抽象（インターフェース）」に依存する
だけとなると思います。
制御の反転とは、インターフェース以外の依存を隠すだけ（「本質的でない細部を削ぎ落す」）の抽象化だと思いますが、隠しただけです。
隠しただけで、実際には残っている「本質的でない細部」とは、
- 抽象（インターフェース）以外の「データの作りの制約」など
で有り、消えたのでは無く、隠しただけなので、それらが原因となり、
- プログラムの変更を妨げ、
- 自動テストを不安定にする
ダメな、出来ない事に該当します。
ダメな、出来ない事を抽象で隠すのは禁忌で、
数学的には正しくても、社会実装後に、そのダメな、出来ない事が原因で、実用に耐えなくなります。
例２（圏論）
圏論などで「関数の合成」や、双方向の変換などを議論しますが、
プログラミング言語の関数は、交通ルールと同じで、
- 特定の危険な場所で、
- 万人に分かりやすい（即、安全につながる）様にする為に、
- 出来る事を減らしている（スコープにより、見える、見えないを分けている）
↑「拡張に対して開く」という美徳に全力で抗っている
ので、
- プログラムの変更を妨げ、
- 自動テストを不安定にする
ダメな、出来ない事に該当します。
しかし圏論などの議論では、そのダメな、出来ない事は
- 隠す（「本質的でない細部を削ぎ落す」）
ので、
数学的には正しくても、社会実装後に、そのダメな、出来ない事が原因で、実用に耐えなくなります。
例３（プログラム自体を仕様とする）
プログラム自体を仕様とするのは、抽象化（何かを隠し、本質的でない細部を削ぎ落す）の典型的な分野だと思いますが、
- プログラムの各手続き（関数を含む、プログラムの部分）が何の原因で、どの様な絡みで結果としてそうなったか
を示す因果ダイアグラムは、
- プログラムの変更を妨げ、
- 自動テストを不安定にする
ダメな、出来ない事に該当します。
因果ダイアグラムが必要な程、複雑なプログラム（すべての実用的なプログラム）は、その因果ダイアグラムにより、
- プログラムの変更を妨げ、
- 自動テストを不安定にする
性質を獲得します。
それを
- 隠す（「本質的でない細部を削ぎ落す」）
のは、
数学的には正しくても、社会実装後に、そのダメな、出来ない事が原因で、実用に耐えなくなります。
結論
これからも「社会実装を伴う、数学的抽象化の禁忌」でプログラミングが嫌いになる人は存在し続けることでしょう。
