荒すぎるのでは？
「何指向でもダメな時はダメ ３」で述べましたが、
- 関数は、その性質の良さ故に、プログラムの最小単位たり得ません。
- 最小単位は、もっと混沌とした、単なるプログラムの一部分としか言いようの
無いものです。
とし、
- このブログでは、仕様からの（訂正開始 2026/5/12 AM2)射 関係*1（訂正終了）を受け取る単位を、
- 「手続き」と呼ぶ事にしています。必然的に、最小単位となります。
としました。
関数が小さければもしかすると、プログラムの最小単位になるかも知れませんが、大抵は違います。
要するに、
- 1つの（複数の最小単位を含んだ）関数呼び出しに、
- 複数の（最小単位のプログラムを結果とする）原因が有り、
- 型駆動開発では、その内、1つの原因のみを取り上げ、他を無視する
のです。
それで何が悪くなるか？
- 人件費か経費かの分類（仕分け）
も確かに、結果として出来る、手続き（プログラムの部分）の原因ですが、
- 入力者にとっての、入力の自然さ
もまた、手続き（プログラムの部分）の原因です。
- IF文レス（システム内に場合分けが無い）
で有る事をいい事に、別の原因（入力者にとっての、入力の自然さ）を無視して、
- それぞれの型ごとに、全く違う形式のCSV
を要求する様に設計するというのは、型駆動開発の問題点です。
どんなに、
- IF文レス（システム内に場合分けが無い）
が「良くなった」と言われても、
- 1つの（複数の最小単位を含んだ）関数呼び出しに、
- 複数の（最小単位のプログラムを結果とする）原因が有り、
- 型駆動開発では、その内、1つの原因のみを取り上げ、他を無視する
ので、
- 別れた、各場合のプログラムに統一を取る理由が無くなってしまう。
という弱点で困ってしまう事になるのです。
結論
これからも「型駆動開発の問題点」でプログラミングが嫌いになる人は存在し続けることでしょう。
*1:「射」は、同格の物の間の反射的、推移的関係だが、「原因→結果」の両者はとても同格と言えないので、「射」では有り得ない。
このブログでは、その原因と結果の間の矢印の事は「関係」と言う。（「何を飛ばしていたのか？ １」参照）
