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

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

プログラミングの発達過程において 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年間固定し、変えようとする人間を排斥するならば、自動テストも捗る
のでは無いかと、妄想してしまいます。

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

 

結論

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

 

 

因果と確率 2

変数を書き換え不能

最近の流行として、ローカル変数で、

  • 基本はconstで変数宣言をして必要な場合にのみ、letを使う

と言うのが有りますが、「因果と確率」(特に因果)の観点からは、

  • 今一歩、踏み込み不足

な様な気がしてなりません。

 

何が踏み込み不足?

昔から、他から得た値(関数の引数とか)を変更するのは、

  • 非常に良くない、禁止としていた場合も多数

でしたが、const指定をしたからと言って、全てを変更禁止に出来る訳でも無いと思います。
私としましては、他から得た値の変更禁止は完全に成し遂げて貰いたい希望が有ります。

さらに、自分がこれから他に与えようとしている最中の値の作り中で、いちいちconst指定をしなけらばならないと言うのも、気に入りません。

何故なら試行錯誤中な訳で、
もちろん「基本はconst」との主張で有り、全部をしろと言っている訳では無い建て付けなのは分かっていますが、
どの世界にも「全てだ」と言ってくる人間は居て、それらの人間に対する説明も必要になり、煩瑣です。

 

Rustの所有権は?

Rustの「所有権」は、

  • 主にメモリリーク対応(だそう)で、
  • スコープを跨いだら解除される

そうで、関数の引数の場合、自動で変更禁止にしてもらえそうに有りません。

 

結論

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