どの様な話？
オブジェクト指向では、
- 共通で使える訳でも無い、小さい（手続き1つとか）機能を関数にまとめた、
プライベートメソッド ー（１） - 公開に値する責務を具現化しているが、いかんせん混ざり物になる、
パブリックメソッド ー（２）
を織り交ぜて（どちらが優位劣位とか無しに）、理想の問題記述に近づこうとしている面が有ると思います。
その様なオブジェクト指向が出回り、
賛成派、反対派入り混じって、10年、20年と実績を重ねて来たと思いますが、
その状況下で、
- より素晴らしい関数型
が提案されたのは、誤解に基づくのでは無いか？ と言うのがこの文書の趣旨です。
要するに、
- 上記（１）でも無い、（２）でも無い、メソな問題記述方法が有り、
- もしそれが有るならば、
- それを関数としてまとめるだけで、
- 理想の問題記述になる。
と言う誤解です。
学問は、ほんの小さな萌芽であっても、いくらでも取りなしをして、重要化をして、褒め称える対象にするのが得意だと思いますが、
その様なメソな問題記述は、10年、20年経っても、全く出ません。
これは、不存在（原理的に０）の強い傍証だと思いますが、それゆえ、
- 関数型の誤解であり
- オブジェクト指向の、プライベート・パブリックを織り交ぜた記述が出来得る最善だ
と言えると思います。
責務は何か？
『特定の側のみからの「ベストプラクティス」 ７』で述べましたが、
（狭義の）ソフトウェア開発での、束構造の因果ダイアグラムは、
- 上限が「システムを作ろうとする発端」で、
- 上限方向のグラフの半分が「原因が、複数の独立・直交した部分原因に
分かれる」過程で有り、 - グラフの真ん中の一番「太った」部分に、一番小さいプログラムの
部分が置かれ、
（追記：ここがマクロレベルとミクロレベルの直接的な接点で、メソレベルはあくまで不存在） - その後、下限方向のグラフの半分にて、より大きいプログラムの部分へ集約されて行き、
- 下限が「システム完成」を表す
であり、
責務は、
- オブジェクト指向で言う、パブリックメソッドであり、
- 上定式化では、4. の「より大きなプログラムの部分への集約」
に当たると思います。
「まともな名前をつけさせてくれず、意味がわからない ５」では、筆が滑ってしまい、
- 責務とは、メソレベルの情報となり、本質的に混ざり物
と書いてしまいましたが、
- 責務とは、公開に値する情報だが、本質的に混ざり物
とすべきでした。
狭義のソフトウェア開発では、メソレベルの情報は不存在であると言う強い傍証（10年経っても、20年経っても、どんな先生の取りなしでも、完全に成果が０）が有る以上、
- 責務（歴とした狭義のソフトウェア開発の一隅）をメソレベルとする
のは、ひどい誤りとなります。
結論
これからも「関数型の誤解」でプログラミングが嫌いになる人は存在し続けることでしょう。
