束構造の因果ダイアグラムは、
ソフトウェア開発での、束構造の因果ダイアグラムは、
- 上限が「システムを作ろうとする発端」で、
- 上限方向のグラフの半分が「原因が、複数の独立・直交した部分原因に
分かれる」過程で有り、 - グラフの真ん中の一番「太った」部分に、一番小さいプログラムの
部分が置かれ、 - その後、下限方向のグラフの半分にて、より大きいプログラムの部分へ
集約されて行き、 - 下限が「システム完成」を表す
と想定されますが、
3.の付近と、2.、4.の付近で、話が変わります。
どう変わるのか？
3.の付近では、
- 独立・直交した部分原因と、それに直接結びついたブログラムの部分
のみから成り、
前に、『特定の側のみからの「ベストプラクティス」 ３』で述べた、
- （素晴らしい）比喩のつもりだった関数
と、
- 現実のプログラム言語での関数
が一致します。
しかし、2.や4.の付近では、
- 独立・直交して”いない”部分原因
や、
- 集約されたプログラムの部分
を取り扱う事になり、
- 素晴らしい関数と現実の関数は一致せず、
- きちんとした命名は現実的に不可能
（独立・直交して”いない”から）
となります。
一番小さいプログラムの部分で、素晴らしくても、それは50年前（文を持ったプログラム言語が出来て以来）より、当たり前の様に出来ていたと思います。
何が問題か？
素晴らしい関数型プログラミングの事を言っている人間は、
- 2.や4.付近での素晴らしさを示唆しつつ、
- 3.付近での成果のみしか提示しない
のです。
3.付近でのみの成果なら、オブジェクト指向プログラミングでも、かなり達成されていると思います。
結論
これからも『特定の側のみからの「ベストプラクティス」』を無理押しされる事でプログラミングが嫌いになる人は存在し続けることでしょう。
