嫌われプログラミングの代弁者

「何で頭ごなしに嫌う人間が居るのか」を色々考える

プログラミングの発達過程において 2

想像ですが、教育のキモかも知れない

腕の付いたバイクのアニメまで持ち出して言いたかったのは、

実務畑の人間には思い付かない「教育のキモ」かも知れない、

  • 世界情勢(プログラミング・システム開発の分野では例えば「次代に望まれる要求」など)を曲げて、*1
  • それを前提に議論し、記述をする事を求め、
  • それにより、プログラミング・システム開発での"高度な"思考の仕方を得る

と言う、やり方が有るのでは無いかと言う"思いつき"でした。

実務畑の人間がプログラミング・システム開発を教える場合、どうしても現実を踏まえてしまい、その結果、

  • 大筋が伝わらない

事になるだろう事は容易に想像出来ますが、

設定を曲げると、

  • 大筋が伝わる
  • 現実と違い、論文のネタがより多く得られる(現実を曲げた、現実からすると偽を含んだ前提となり、かなりの反事実が議論として成立する為)

と言う効果が得られるのでは無いか? と想像します。

 

良い点ばかりでは無く

もちろん設定を曲げて教育を受けた事で、不利益も有ると思います。それは、

  • 教育の為の設定(例えば「次代に望まれる要求として、必ず自動テストが必要」)を鵜呑みにして、
  • 現実と合わない(表現出来る範囲が少ない)設定こそが次世代だと言い張り、
  • なんの成果も出せない

と言う人間が出る事です。*2

現実を曲げた設定で有る以上、出来る事が減ります。大抵の場合、致命的に減ります。つまり、そう言う設定下では、本当に必要な要求は、

  • なんじの問い、愚かなり

程度にしか扱えないと言う結果になると思います。

"高度な"思考の仕方を援用しつつ、現実の問題に立ち向かってもらえると良いのですが、教育の為の設定を現実(次代の有るべき姿)と思い込んで、他人を非難するのは長い期間を考えると不利だと思います。

 

結論

これからも「プログラミングの発達過程において」その様な取り違えで他人を非難する人間が存在する事で、断然プログラミングが嫌いになる人は存在し続けることでしょう。

*1:例えば、「(40年前から自然に出来ている料金計算ロジックの自動テストなどを除いた)全ての分野で自動テストが次代に望まれる要求である」とするなど。

*2:心の底から思いますが、現実世界で、「(40年前から自然に出来ている料金計算ロジックの自動テストなどを除いた)全ての分野で自動テストが次代に望まれる要求である」とはとても思えません。多分、教育の為の設定だったと想像します。

プログラミングの発達過程において 1

どの様な話?

生徒が反事実を世に問うた場合、大抵の場合、非行となると思います。

何で非行がいけないかと言うと、

  • 非常にしくじり易い
  • しくじった場合にお金がかかる

からだと思います。

さて、プログラミングの発達過程において、

  • イヤイヤ期が有っても全く不思議では無い

と思いますが、大人が実社会でそれをやった場合、「反事実を世に問う」のと変わらないと思います。

 

非行を勧めているのか?

久しぶりに旧作のアニメを見ましたが、それは腕の付いたバイクの大学のサークルでの話でした。
そこでは作中の世界情勢の設定を恐ろしく曲げて主人公が反事実を世に問うと、丁度正義となる様になっていましたが、

要するにあの位、世界情勢の設定を曲げない限り、反事実を世に問うと、大金を取られるだけとなると思います。

 

プログラミングの発達過程において、イヤイヤ期が有っても良いとは思いますが、

  • それを全面的に肯定し、
  • 学術的真実だとし、
  • それを即、世に問う

事を推奨している教育者は、しくじった場合の大金をどう都合付ける目算なのでしょうか?

 

学校は

学校は少なくとも研究者として一人前では無い人間の、学術的非行はたしなめるべきだと思います。

 

結論

大人が発達過程をなぞり直すと言うのは、非常に格好が付かない様に見えます。たとえリスキリングとかの美名が付いていてもです。

これからも「プログラミングの発達過程において」不恰好な様となってしまう期間を経ないといけないとするならば、断然プログラミングが嫌いになる人は存在し続けることでしょう。

因果と確率 4

技術的負債返済における「イヤイヤ期」

少し長めの引用ですが、

  • 陰伏的な関数関係が(中略)与えられていて、陽な関数関係 y = f(x) が(中略) F(x, f(x)) = 0 を満たすなら、この陽関数 y = f(x) は D 上で関係式 F(x, y) = 0 から陰伏的に得られるという。(中略)陰関数から陰伏的に得られる陽関数は一つとは限らず、一般に一つの陰関数は(中略)複数の陽関数に分解される。
    (関数(数学)→陽表式と陰伏式 Wikipedia 日本語版)

と言う記述を見つけました。

前から、

  • 技術的負債の返済において
  • 「陰関数」を徹底的に無視する傾向が有る

と思っていたのですが、それに絡んだ検索の結果です。

  • 陰関数はテストし難いからイヤだ
  • 場合分けはイヤだ

と言う技術的負債返済における態度が、

  • 抱っこはイヤだ、
  • 地面に降ろされるのもイヤだ

という態度とそっくりな気がしたのです。

特に陰関数は、そういう人間にとっての人参やピーマンに相当するのでは無いかと言う位、嫌われていると思います。

 

陰関数

しかしながら、COBOLプログラムなどで、

  • 商品の内容から金額を出す

と言った、テストし易い課題と異なり、

  • 何々を満たす"全てのもの"から何ちゃらの処理をする

と言った、業務のキモに当たる課題では、陰関数的になるのが100%の通例でした。

軽度の線形計画法や、軽度のAI学習につながる、難易度の高いロジックとなり、テストが困難になるのだと思いますが、
はじめに自動テストを書かせる人間は、この困難さを無視する(難易度の高いロジックに関するリスクを顕在化させず、リスクを(特にプログラマー)個人に負わせる)意図が有るとしか思えません。

ただ、そう言う陰関数的、逆関数的問題は存在し、無くなることはあり得ないので、はじめに自動テストを書かせようとする人間は悪だと思います。

 

結論

これからも難敵で有る「因果と確率」の存在でプログラミングが嫌いになる人は存在し続けることでしょう。

 

因果と確率 3

仕様における確率

仕様における確率に関連して、
最近、多様性が望まれるのは自明だと思います。

しかし、みずほでも、マイナンバーでの住民票でも、全銀ネットでも(主に日経の)公開記事を見た限りでは、

  • 仕様(確率)に多様性を持たせる(手法を強く定めない)と言う
  • 望まれるやり方をしたが、
  • テスト時にその多様性について行けず(無意識の内に、特定の手法に適した確率分布で考えてしまい
  • テストが漏れた

と言う問題が発生したと、私は読み取りました。

 

React勉強中

前に述べました通り、PaaSのサーバー(コンテナ?)を借りて、Reactを勉強中です。(18.2.0でやっています。Fiber Reconcilerとか当たり前の様に利用しています。)

Google Trendsを見ても、他の手法(Angular JSやVue.js)と比べてトリプルスコア以上の関心度を得ているReactは学びも大きく、将来性も有る様に見えます。

ただ、60歳の私の心配事は、

  • 1980年終盤ごろ、
  • それまで競い合っていた、他の言語、手法を圧倒し、
  • 構造化プログラミングと言う最新の手法を盛り込み、
  • 後方互換性も高く、
  • トップレベルでのみ利用出来る画期的な状態保存方法(VSAM)も出来、
  • 学びも大きく、将来性も有る

としていた某言語のその後の動向にReactをなぞらえてしまうと言う一点に尽きます。

  • テスト時に多様性について行けなくなる事への対処として、
  • 特定の手法が他を圧するのは、
  • ある意味(特にテスト観点からは)有意義

では有るとは思いますが、

  • 仕様(確率)に多様性を持たせる(手法を強く定めない)

事もまた望まれており、このまま10年後にReactがその某言語と同じ道を歩んでしまうと、悲惨だと思います。

 

テストを最優先にするなら、

極論ですが、テストを最優先にするなら、

  • 仕様(確率)に多様性を持たせる(手法を強く定めない)事を主張する人間は、システムを脅かす、障害で有るとし、
  • みんなで寄ってたかって、
  • ダメだという(人格攻撃も含めて)

のが最善だし、例えばReactの特定のバージョンを今後20年間固定し、変えようとする人間を排斥するならば、自動テストも捗る
のでは無いかと、妄想してしまいます。

もちろんのこと、変えようとする人間への攻撃は弱く、変えるのを拒む人間への攻撃は強いのが通例で、特に歴史的に例外も思いつきませんので、これは完全な妄想に過ぎないとは思います。

 

結論

これからも難敵で有る「因果と確率」の存在でプログラミングが嫌いになる人は存在し続けることでしょう。