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

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

第一原理計算? 1

どの様な話?

逆に、

  • 現行システムは「曲げられない」
  • どんなに理解し易くなっても!

だと思います。

  • 保守フェーズ(「曲げられない」)で、曲げ(≡分かり易さ)が通じない

のはそのせいだと思います。

そして、曲げられない場合に何をやるかというと、

  • 因果推論
  • 具体的には調査分析

だと思います。すなわち、

  • 因果推論こそが、プログラミング手法の第一原理計算

なのでは無いでしょうか? 第一原理計算は一般に、

  • 難しい

のが通例で、一般に調査分析が煩瑣なのもこの主張の傍証となるのでは無いでしょうか?

 

曲げられる(完全新規開発、既存要件無しの)場合

曲げられる場合には、(針の穴を通す様な細心の配慮の元)SOLID原則を満たす様に作ることも可能でしょう。

しかし曲げられない場合には、まず無理だと思います。

なぜならば、

  • (非常に多数から引用され、「曲げられない」原因となっている)因果の元の方が、
  • SOLID原則を満たす様になっていなかった
  • そこから直すとなると、完全新規開発、既存要件無しとなってしまう

からだと思います。SOLID原則適用の困難さも、第一原理に立ち返って見れば明白なのでは無いでしょうか?

 

技術的負債の返済の技法

技術的負債の返済の技法も、

  • 粗々でかなりの了解は取れている(と私は思う)

けれども、その第一原理計算はやはり、因果推論なのでは無いでしょうか?

第一原理が有ればこそ、粗々にせよかなりの了解が取れると言う物では無いでしょうか?

 

結論

第一原理計算は難しいので、それを持ち出さないといけない場合、
これからも「第一原理計算?」の突破の困難さにより、プログラミングが嫌いになる人が存在し続けることを、理論的に証明出来る日が来るかも知れません。  

 

プログラミングの発達過程において 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学習につながる、難易度の高いロジックとなり、テストが困難になるのだと思いますが、
はじめに自動テストを書かせる人間は、この困難さを無視する(難易度の高いロジックに関するリスクを顕在化させず、リスクを(特にプログラマー)個人に負わせる)意図が有るとしか思えません。

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

 

結論

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