前回の洗濯機の話
前回（隔靴掻痒な議論 ３）、唐突に、洗濯機の脱水の話をしましたが、真意は、
- プログラミングは
- ユークリッド空間の様な（まともな）測度が見当たらず、
- 絡んだ洗濯物の様
だと言いたかったのです。
特に、
- 仕様書（結果たるプログラミングの原因）が自然言語で書いてあって、
- プログラミングの原因とするには、
- 複数の基本的要素がからまっている様に見え、
- プログラム作成者が、ほぐした、プログラミングに使いやすい原因としなければならず、
- それゆえ（ほぐした結果）「原因が増える」
のだと言えると思います。
プログラミングの観点から見た自然言語は、
- 確率的で、高階的で、
- （人間の限界として）高階的である以上、解像度が落ちあいまいになり
- なんで物事と物事をからめて語らないと語れないのか？
と言う物だと思います。
仕様も自然言語で無く、（ZF公理系などを用いた）形式的仕様記述言語を用いれば良いというアイディアは、
- 仕様として事前確率として提示するには、確率的で高階的で有る必要が有るが、形式的仕様記述言語は、それを満たしておらず、
- 「良い様に見えて穴だらけ」で有る事に対する耐性が無く、
- 比較的圧倒的高確率でしくじる
事が前に判明した為、無理だと思います。
ほぐした原因とその結果としてのプログラミング
もっと言葉を飾らずに言うなら、
- 関数が良い
とか
とか
- 単一の責務
とか言うのは全て、
- 直接の原因と、それをほぐした原因と、
- その結果としてのプログラミングと
- 因果ダイアグラムの上限（システム開発の発端）からの原因の連鎖と、
- 因果ダイアグラムのプログラミングから下限（完成したシステム）までの結果の連鎖
の記述の隔靴的皮層的反映に過ぎないと言えると思います。
「関数が良い」と言うのはプログラムの地平で見た、原因と結果の明確化に、たまたま使える様に見える関数を無理に使っているだけで、関数というのは、
- 特定の危険な場所で、
- 万人に分かりやすい（即、安全につながる）様にする為に、
- 出来る事を減らしている
為、隔靴的な原因と結果の皮層的記述が限界です。
「ユニットテストを残せ」と言うのも、
- 事後確率としてのふえた原因を
- プログラマーに書いてもらう
事の、隔靴的・皮層的な手段に過ぎないと思います。
「単一の責務」と言うのも、
- 分離されて増えた原因の複数を、各々のプログラムは具備してしまうが、
- どの原因か？ 因果ダイアグラムの上限以降から導き出されるものか？
- それとも（迷惑ハッカーがやる様に）自分勝手に導き出されない原因を、説明も無しに導入して、誰にも判らなくしてしまっていないか？
を議論する過程での、隔靴的・皮層的な表現だと思います。
何でこうなってしまったのか
（プログラミング側を見下した）設計側のNIH症候群（Wikipedia 日本語版）が理由だと思います。
「ここで発明したものではない」（プログラミングで増えた）原因は、滋味の有る事後確率であっても捨て去り、割りの悪い（事前確率のみの）情報のみでの結合テストをしようとする行動です。
設計側は権限が高いので、これをやる事は造作も無いと思います。
ですので、理由は間違い無く、これです。
結論
これからも「隔靴掻痒な議論」でプログラミングが嫌いになる人は存在し続けることでしょう。
