どの様な話？
ブログを書いていて、
- 分かりやすく書こうとするあまり、
- 分かりやすくなったは良いが、その目的を達成する代わりに、現実的な主張でなくなってしまった
と言う事も有ると思います。分かりやすさを確保するのは筆者のつとめで有るとは思いますが、あちらを立てれば、の話である事に変わりは有りません。
プログラミングのシステムでも、同様の事が起きます。
- プログラミングのシステムの分かりやすさの総量は、限度が有るのでは？
と言う事です。
まず思いつくのが、
まず思いつくのが、
- 入力（CSVファイルとか、単なるテキストとか、DBに保存されているデータも）に条件（よく「整合性」と言われます）が有ると、プログラムは簡単になり、
- 条件が減ると、プログラムは困難になる
と言う性質です。
前者では、CSVファイルの各項目に条件が付くやり方です。
数字か文字列か、とか前ゼロ有り数字（銀行コードとか）の前ゼロが意味を持つかとか、日付をスラッシュ切りしろとか、です。
後者の典型的な例として、住所が有ります。（千差万別の）住所を住所コードにするなどという企てには、ヒューリスティックが必要で、
- 何々市何々町の後に、特定の文言（大字何々とか）が有ったら、別の文言（大字無しに単に何々にするとか、別の地名に置き換えるとか）にせよ、
とかいうルールを延々と作り、変換失敗を少しずつ減らして行き、
- 状況が変わったら、またルールを更新し続ける、
とかの話で、入力の整合性が希薄な為、（入力をする人には「分かりやすい」のかも知れませんが）プログラミングの分かりやすさが、非常に減ります。
nullを排除しろなどと言うやり方も、これだと思います。nullと言うのは、COBOLでもC言語でも当然の様に行われていた、
- -1やAll 9で表していた「よくわからない」値を、
- 数字の全空間を正常値として使える様にする事を目的に、
特別な値を新たに設けたのですが、分かりやすさの為、異常値を、数字の全空間のどれかに必ずしろと言うやり方です。
どこかに（異常値を正常値に変換する為の）ヒューリスティックなルールが出来、プログラミングの分かりづらさが、どこか隅っこの方に移転されるだけです。
誰が「分かりづらい」と言うか
金次第だと思います。金を出さずに、限られた資源で有る、分かりやすさを求めるのは横暴です。DevOpsと言われなくなったのも、これが原因だと思います。
運用側がお金を出せば、完全に解決する話だったのです。
夫婦別姓も、それをすぐ欲しいと言う人が毎月10兆円位寄付してくれれば、10年以内に成立したのかも知れません。すべての書類の枠を増やす必要が有るからで、何でそれだけの事なのにしないのでしょうか？
お金の無い普通の人間は、分かりづらさを許容して、分かりやすさを金に変える必要が有るのかも知れません。
結論
これからも「分かりづらい」事でプログラミングが嫌いになる人は存在し続けることでしょう。
