同じレベルだからだと思います。統計の知識で啓蒙してやろうとやって来ても、争いしか起きません。
統計の知識で目にみえる成果が出るのは、
場合だと思います。プログラミングも、
ので、目にみえる成果が出る場合には、問題に対して「引いた」視座となっているのに対し、統計はプログラミングという問題に対し引いていない、争いしか起きない位置にあるのだと思います。
これからも「より簡単な手法にさせてもらえない」事でプログラミングが嫌いになる人は存在し続けることでしょう。
私はコボラーとしてはかなり後になったと思います。
のでなったのですが、
それには理由が有りました。今後、その様な陥穽に陥る事が無い事を願い、以下に書きます。
大学に入ってから、MZ-80CのSP-4010（シャープPascal）言語ばかりいじっていました。この言語はかなりTinyで、
と言う縛りが有り、
と言うパターンを忠実に守る以外に、実用的なプログラムを書く手段が完全に有りませんでした。
ビルドの単位（javaで言うプロジェクト）など無く、1つのプログラム（前処理→主処理（繰り返し）→後処理）それぞれを1つ1つ独立してコンパイル出来る事が必須条件でした。
さらに、同じ意味のハズの変数でも、別のプログラムでは別の操作的意味になる事も、稀では無く、一々調査が必要でした。
また、私が就職した頃にはCOBOLシステムでは「構造化プログラミング（Wikipedia 日本語版）」が流行っていて、
それら諸々が、TinyなシャープPascalと符合してしまったのです。
（repeat until 終わるまで、では無く、PERFORM UNTIL 終わるまで、ですが、、）
逆に言うとCOBOLというのは、その程度だった、という事が言えます。（私の感想です。）
現在では、SQL言語を埋め込む事で、COBOLの1つのプログラム相当の機能を、javaなどのプログラムの内部機能として活用出来ているので、COBOLはお役御免だと思います。
これからも「COBOL言語である」事でプログラミングが嫌いになる人は存在し続ける事でしょう。
私は昔からプログラミングについて、因果推論により「確率から因果に」変換すると言う理論が役に立つのでは無いかと思っていました。*1
確率とは要求であり、因果とはプログラミングです。
もちろんプログラミングと統計学は、恐ろしく相性が悪いので、（統計的因果推論の様に）因果推論の際に統計学の力を借りて大局的に調査をするのはしずらいと思いますが、非巡回有向グラフ(DAG)と言う因果推論の1つの道具は、非常に有効だと思います。
何十年も前から「ペトリネット（Wikipedia 日本語版）」と言う表記方法も有りました。これは離散分散システムの記述だと言う触れ込みですが、
そもそもDBを使ったWeb画面による入力システム自体が、複数の場所（ブラウザー）から合い互いに示し合わせたりせずに入力する訳ですから、これだけでも離散分散システムです。
からだと思います。
それをややこしく表現するとペトリネットの様な、因果推論の様な世界になると言う訳です。
プログラミング開始時点では計算結果が50だろうと100だろうと50歩100歩であり、計算に必要な値を揃えるのこそが大変で、大変さの克服の結果、プログラムに人間が自然だと思う「意味」とのズレが生じるのです。
javaのパッケージやjavascriptのパッケージャは、1カタマリの機能を読み込む単位です。それに対し、UMLのパッケージは、
です。これはクラス数が少ない、お試しで作った様なシステムでは完全な役立たずに見えますが、クラス数が50を超える様な実用的なシステムでは必須の位置付けになります。
極論するなら、
訳ですし
訳です。
UMLのパッケージはクラス（など）に対して、
視座にあると言う位置付けだと思います。プログラム内部の事情から離れて、人間が付けたい名前に寄せたいと思うなら、値を手にいれると言うレベルからは遠ざかるしかないのだと思います。
否だと思います。万能な、値を即時に手に入れてくれる何かがあるとは思えません。
値を手に入れる手間もプログラミングの内です。
がUMLのパッケージだと思います。
UMLのパッケージは後知恵となり、かなりクラス等が出来上がってからの話になると思います。「（せめて）名前をつけたい」と願う素人の出番は有りません。
ですので、これからも「まともな名前をつけさせてくれず、意味がわからない」事でプログラミングが嫌いになる人は存在し続けることでしょう。
名前の付け方や、第一級の括りの意味を知る事は、オブジェクト志向だからどうだと言う、独自の考えは無いと思います。
逆に、名前の付け方や、第一級の括りの意味について「虫が良すぎる」（長期間の真剣な研究開発でも解が無い）仮説が有ったとしても、それによってオブジェクト志向の価値が下がってはならないと思います。
その様なこだわりはオブジェクト志向とは分けて考えるべきだと思います。
名前は点だと思います。そして実装（意味）はそれに相応しい滑らかな曲線となり、プログラミングの技術的制約によって、実装は人間が欲しい意味との乖離が発生します。
それが発生したからと言って、即負債だとするのは短兵急が過ぎます。
単一責任の原則（「変更するための理由が、一つのクラスに対して一つ以上あってはならない」 SOLID Wikipedia日本語版より）と言う原則が有り、
なかなかに実現するのに困難だと思います。
理由の方をコンピュータの技術的な都合に近づける（名前をまともでは無くし、説明的でわざとらしい名前にする、意味は分かり難くなる。）と実現しやすくなると思います。
に対してなら、「人間の理解し易い理由版」単一責任の原則も成立する様に思います。
「クラスがダメだから関数」とかの単純に向く方向性で無く、UMLのパッケージの様な、複雑に向く方向性の方がまだ芽が有る様に思います。
これからも「まともな名前をつけさせてくれず、意味がわからない」事でプログラミングが嫌いになる人は存在し続けることでしょう。
