主に2つ有ります。
これからも「関数型プログラミングである」事を知る事でプログラミングが嫌いになる人は多数増え続ける事でしょう。
私の勤めているソフトウェア会社で、評価面談があり、その際に、
と評されました。話をうかがうと、
という風に聞こえました。その頃、関数型は次世代技術として大流行りでしたし、次世代プログラミングに期成するだけの人も居た様に思います。
いくら何でもと思い、その上の管理職に文句を言うと、
と言われました。ファクトを得るため20年待ちました。
現在時点で動作するプログラミングの観点からは、関数型プログラミングと言われている物の実例が見当たりません。
関数型プログラミング言語と主張する物はありますが、それの事例集を見ても普通のプログラミングとなんら変わりの無い物です。
そこから推察される事は、
という意図だと思います。他に解釈のしようがありません。
そのような党派的な議論を技術的な場所ですべきでは無いのかもしれませんが、最高に好意的に解釈してもそうとしか思えないのです。
現在時点で純理論的なプログラミングの観点（実際に動かないとしても、理論的に良い見通しを得られるモデルが得られればヨシとする観点）からは、「制御の逆転」という主張があります。
その主張とは、
と、私は理解しています。
それは問題に対して、「横目いっぱいの視座から見て、問題が簡単になった（様に見える）」と言っているだけだと思います。
ミスリードを誘っているだけとしか私には思えません。また、当たり前の話ですが、関数を基礎としなければ、純理論的な議論が出来ない訳でも有りません。オブジェクトを基礎としたモナ何ちゃらだって成立するはずです。
もちろん今でも自分の言っている事は感想に過ぎないのかも知れません。死ぬまでにファクトにたどり着けないのかも知れません。
しかし、学術的評価を受けていた事も、のちに(訂正開始 2023/3/7 PM6) 嘘になる 解無しと分かる事はあり得ます。
嘘を 解が無いのに解の存在を証明せずに解が有るかの様に議論し 金を取る 様な振る舞いを (訂正終了)
ファクトを重んじる実業の世界に持ち込んだら契約不適合責任が生まれると思います。
(訂正)「嘘」と決め付けるのは悪い行いなので、訂正しました。なお、「解の存在証明」というのはテストの事かも知れません。
その線から一歩一歩突き詰めて行くより無いのでしょう。
これからも少なくとも約1名は「関数型プログラミングである」事でプログラミング（の一側面）が嫌いになる人は存在し続ける事でしょう。
宣言型プログラミングというものがあるそうで、オブジェクト指向プログラミングの「次世代」として、関数型と双璧を成していました。
これは、
やり方との事です。
コボラーの視点から見ると、これは、
を成立させるために、常套手段として用いていた手法でした。もちろん、
万能ではありません。
メモリは千バイト程度しか使えなかったのですが、
は出来ました。
そして、メモリではまな板よろしく、
「動作を変化させるデータ」1個分（1つ前のデータとの差分が必要な場合は2個分）だけ用意し、MTやDASDから「動作を変化させるデータ」をどんどん流し込んで、結果をまた「動作を変化させるデータ」としてMTやDASDに吐き出す、
というやり方で、何百万件、何千万件、それ以上、の処理が可能でした。
いわゆるバッチ処理です。そしてこれは宣言型プログラミングに通じると思います。
それなら、コボラー的に見ると、プルーブンな手法だと理解出来ます。
例えば、MS Accessで何百万件のデータをクエリを使ってJOINさせる事は不可能です。
多分ですが、
動作だと想像され、仮想記憶の限界の4GBのまな板を超えてしまうと、進まなくなってしまうのも納得です。
それをやれという課題が出たことが有り、テーブルをMTに見立てて、マッチング処理をやって切り抜けた事が有りました。
何万件で、Accessのクエリだとかろうじて仮想記憶の限界内だった場合に、何百万時間（途中までやった時の処理件数と、全体件数から推定）かかるはずの処理が、数分で終わったりしました。
まさに、
な手法の白眉です。皆さんもどんどんお使い下さい。
どちらにせよCOBOLの問題とは無関係で、これからも「COBOL言語である」事でプログラミングが嫌いになる人は存在し続ける事でしょう。
関数型プログラミングというものがあるそうで、変数に関数を代入出来、機能をプラガブルに変更出来るそうです。
これを私が耳にしたのは、オブジェクト指向プログラミング真っ盛りの頃で、次世代のプログラミング手法ということで、沢山の人から関心を集めていました。
オブジェクト指向真っ盛りの頃の「次世代」という事で、当然オブジェクト指向プログラミングを凌駕するものだと認識していましたが、
次世代たる実例がいくら待っても出て来ませんでした。
「変数に関数を代入出来る」と聞くと、1つ気になる事が有ります。
気です。
いくら「コボラー○ね」とか言われても、口答え出来なかったのは、COBOLの文法が変な所（ごく少量のメモリでの動作）に重点を置いていて、オブジェクト指向に対して自分の問題ににおいて、優位性を言うことが出来なかったからです。
ところで、
関数といえば、
であり、
オブジェクト指向プログラミングよりは、COBOLに近い、インターフェースの構造から言うと、焼き直しと言っても良いものです。
もちろん、陰関数に言及すれば別かも知れませんが、それだと最も普通の手続き型言語となってしまいますし、関数型プログラミングを推す方達から、陰関数の言及は知る限り皆無でした。
プログラミングの手法で、
な手法は作れると思います。関数型プログラミングもその辺を狙ったのかも知れません。
しかし年々歳々歳々年々コケにされ続け、逆転の糸口を願い続けて来たコボラーでもその様な「問題の限定」は全く見つからなかったのに、
プログラムの構造が焼き直しの関数型プログラミングにその余地がある様には、コボラーの視点から思えないのです。
オブジェクト指向言語で、『インターフェースは1つで「公開」』にしたければ、パブリックのメソッドを1つだけにすれば同等だし、
環境変数よろしく、外部とのやり取りを引数以外からしたければ、『パブリックのインスタンス変数』を作ればいいだけで、
関数型はオブジェクト型に含まれている（逆転の糸口がない）様に見えます。
どちらにせよCOBOLの問題とは無関係で、これからも「COBOL言語である」事でプログラミングが嫌いになる人は存在し続ける事でしょう。
コボラーにとっての黒船はまさにオブジェクト指向言語で、完全に飲み込まれた形となりました。適応しないと仕事が無くなりました。
私がCOBOL言語でない言語に初めてぶち当たったのが、オブジェクト指向言語としては中途半端な（クラスが作れない、後に作れる様になったが、その頃には作らない作法で固まってしまっていた）MS AccessのVBAだったので、余計感じ方が変な風に決定づけられたのかもしれませんが、
私がオブジェクト指向言語に対して、心の底から最高だと思った点は、
点でした。モデルだとか設計だとか、インターフェース分離だとか依存性だとか、その様な事は私にとって瑣末でした。（個人の感想に過ぎません。）
少なくとも私が使っていたCOBOL言語では、インターフェース（LINKAGE SECTIONの事。プログラム毎に1つ。ENTRY（呼ぶ箇所を増やす）は規約で禁止。）は全て「公開」でした。
そして「公開」した以上、それらインターフェースは「不変」でした。
「不変」が絶対条件である為に、よっぽどの必要が無い限り、分割出来ませんでした。
内部的にまとまりが良いロジックでも、別のインターフェースから呼び出すなんて贅沢は出来ませんでした。
内部的なまとまりが良いロジックは、内部的であるが故に頻繁な変更が必要ですが、「公開」したら「不変」になってしまいます。その枷はキツ過ぎました。
が、変革を余儀なくされていたコボラーたる私にとって、数少ない喜びでした。
さらに、
も喜びでした。COBOL言語ではインターフェースはプログラムに1つで「不変」でしたが、オブジェクト指向言語では少し似たインターフェースを複数個持てるのです。後から互換性を保ったまま追加も出来ます。
初めからオブジェクト指向言語から入った人には、この喜びは伝わらないと思います。
一つだけの「不変」のインターフェースで何とかするために、
涙ぐましい虚しい努力をしなくて良くなった訳です。
何処をどう考えても、これからも「COBOL言語である」事でプログラミングが嫌いになる人は存在し続ける事でしょう。
COBOL言語が人から嫌われる直接の原因は、
為だと思います。ちょっとの仕様変更もしてもらえないとなると、嫌われて当然です。じゃんじゃんモダナイズすべきだと思います。
私が小学生だった1970年代でも、食べ物など、肉はほとんどなかったものの、それ以外はかなり有り、逆にほうれん草などは現在、高い通販でしか買えない路地ものが食べられたりもして居ましたが、
根本的な違いとして、
事があります。家から5分（小学校低学年の体感で）の所に有ったお菓子屋で買ったカールを持ち帰る時に、雨粒が2､3滴付いただけで（それ位の空気の湿り気だけで）、完全に湿気り切っていました。
その時の絶望感は鮮明に記憶にあります。
その頃のカールの袋は湿気を通していたのです。そしてお菓子屋とは、密閉された何十個もの防湿庫を備えた、専門性を持った装置産業だったのです。
さて、COBOLの話ですが、COBOLはその頃のお菓子屋と同じ様に、その頃の状況に対応していました。それは、
事でした。
それに対応する為に、
していました。
と言った感じです。
今のように、文字列型を定義すれば1変数当たり10万文字分とか（漢字1文字は2バイトとは限らず、6バイトだったりもするがそれも考慮の上）もらえるのとは、訳が違いました。
柔軟性があろうはずも有りません。
千バイト程度をちまちま使う時に便利な様に、そしてそう言う風に使う時の書き方を最優先に文法が組まれていることで、それとの互換性を保ったまま、改良は出来なかった様です。
メモリジャブジャブ時代で便利な様な文法を最優先にする余地が、完全に無かったと言う事だと思います。
COBOL言語で書かれたシステムをモダナイズしたい人は、
と考えていても、
と言われるだけだったからだと思います。
言語独立の仕様は、
からだと思います。
これはCOBOLに限った話では無いと思います。柔軟性の乏しいCOBOLであっても、動かない1つの問題の解決の具としては十分で、柔軟性に乏しいとは別の話で、
（多分自然言語で書かれた）言語独立の仕様などよりも「いかにも些細な詳細な零細なレベル」で記述出来たからです。
ただ、その代表格（モダナイズしても良いと思われるだけの旧システムが有る）としてのCOBOLだからなのでしょう。
これからも「COBOL言語である」事でプログラミングが嫌いになる人は存在し続ける事でしょう。
歴史的に有る時点まで（普通に動くコンピュータが10万円以下で手に入る様になるまで）、プログラミングが主な手段であるシステム開発は、SIerの様なコンピュータの側面からのみ突き詰めるプレイヤーによってなされて来ました。
しかし、コンピュータが安くなった結果、
考えが（当然ですが）沸き起こって来ました。
しかしながら、見た限りでは上手く行っていません。もっと言うなら「常識が通じない」様に見えます。
常識のみで考えると、
のが絶対的な通常で、そうで無いのは、
では無いでしょうか？
化学反応は、多数の原子分子が体験するさまざまな可能性の中から、圧倒的に大きい確率で起こる事を、さも一直線に起こる様に表記しますが、「常識」もまた、似た様な原理で発生するものだとしますと、
「非常識」とは、
だと思います。あまりに頻度が低すぎると「非常識」とすら認識できないからだと思います。
プログラムはテスト実行をしなければいけない理由も、そこに有るのかも知れません。
要件に応じて複数の「非常識」を過不足なく表記する時、
は「やってみないと分からない」からだと思います。そしてそれらテスト表記により、
なのを陽に表現できるのかも知れません。
ただ、現時点ではテスト表記についての研究は途上だと思います。
ですので、これからも「常識が通じない」事でプログラミングが嫌いになる人は存在し続けることでしょう。