同じレベルだからだと思います。統計の知識で啓蒙してやろうとやって来ても、争いしか起きません。
統計の知識で目にみえる成果が出るのは、
場合だと思います。プログラミングも、
ので、目にみえる成果が出る場合には、問題に対して「引いた」視座となっているのに対し、統計はプログラミングという問題に対し引いていない、争いしか起きない位置にあるのだと思います。
これからも「より簡単な手法にさせてもらえない」事でプログラミングが嫌いになる人は存在し続けることでしょう。
私はコボラーとしてはかなり後になったと思います。
のでなったのですが、
それには理由が有りました。今後、その様な陥穽に陥る事が無い事を願い、以下に書きます。
大学に入ってから、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のパッケージの様な、複雑に向く方向性の方がまだ芽が有る様に思います。
これからも「まともな名前をつけさせてくれず、意味がわからない」事でプログラミングが嫌いになる人は存在し続けることでしょう。
コボラーに対する悪口は、人権をつかさどる機関でも、プラットフォーマーでも野放しだと思います。これはファクトだと思います。
何処もいっさい咎めないのです。
します。
（100文字以内の単発のコメントのみの、はてなブログと異なり、）コメントをどんどん付けて議論していく様なプラットフォームでも、コボラーに対する故無い悪口を咎め立てするのを見た事は1度たりとも有りませんでした。
さらに、悪口の対象は（COBOLに関してブイブイ言わせていた）先生筋では無く、（自分の様な）弟子筋でした。これは明瞭なファクトです。
もちろんCOBOL陣営も悪口に値する事はやっていて、
とかして、迷惑をかけたと聞いております。その様な「解無し」の事で金を取っていたとするなら、それは後に悪口を言われて当然です。
私の父親は大学の先生で、（今の私の半分程度の）若い父親が初めての子供に、自分の仕事について色々教える訳ですが、子供は吸収する訳です。（ネグレクトの母親の技術者の義理の父親程では無いにせよ。）
後から（その時、言っていた事が）どうだったか考えた結果ですが、
と言われていた様に思います。
さて、
と言われた時、「あぁ、これなんだな」と思いました。「ビジネスはファクトが」とも言われて確定的だと思いました。
ただ、そこで我慢しなければ全部を押し付けられて、過労で自○するSEの仲間入りをしていたでしょうから、親の言う事はありがたい、と言う事でも有ると思います。
しかしその後、
その"素晴らしい"着想が「解無し」で（長期と言える期間後にも事例が０）、
解を得たと言ったと思えば、見たい（我々が望む）問題に対して「横目いっぱいの解法」のみとなるとすると、
その手法を報じた先生の弟子筋に対して、任意の人間が任意のタイミングで任意の強度で悪口を言うのを許容すると言う趣向も一考に値する様に思います。一般化とは科学の常套手段だと思います。
IT分野で特定の条件の場合、その様な悪口は人権問題とならない様に見えるからです。
何にせよ、悪口に戸を建てる事は出来ないと思います。これからも「悪口を言われる」事でプログラミングが嫌いになる人は存在し続けることでしょう。
もしかすると、プログラミングとは、
と言う側面を持っているのでは無いでしょうか？
人造なので、（特に困る問題に対してのロバスト性を担保する為の）
だとかを備えていますが、そこは（機械学習では無い）人造のAIと言う事で、個性なのかも知れません。
AIの中身を見て、その部分部分を（人間に都合の良い意味で）解釈しようとはしないですよね？
そして、その部分部分が刻々と変化しても文句は言わないですよね？
するのは、その側面からは「疑問が付く」、「解無しが疑われる」と思われても不思議では無い様に思えます。
やっぱり「わかる」方向の言い方は出来ませんでした。
ですので、これからも「意味がわからない」事でプログラミングが嫌いになる人は存在し続けることでしょう。
プログラマーは家で勉強しないといけないのか否か、と言う議論はよく有り、結論も出ません。しかしよく考えてみると、私の場合、家で勉強すると言うのは、
事だと思います。
自分の仕事の範囲内で、新趣向を試す程度の裁量はありますが、解の存在証明の時間までは取れない（出来ないなら旧来のやり方でやれば良いので、酷な話という訳では無い）のが普通なので、
家でやるより無いと思います。*1
それをしないのは、
行いです。それを是とする立場か否かで、議論に対し結論が出ないのは納得です。
業務としてプログラミングをやる場合は、これからも「家で勉強しないといけない」事でプログラミングが嫌いになる人は存在し続けることでしょう。
*1:もっとも、仕事として解の存在証明からやれと言われた事も1度だけ有りました。.NETでコレクションのキーワード検索の速度を上げろと言うものでしたが、これは本当に例外でした。