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

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

因果推論による良い寿司成分の欠乏 4

くだらないという証拠にしようとする

(因果推論を含む調査分析有りの)プログラミング開発はくだらないという証拠にしようとする人間が上司だった場合、本当に困ります。

SIerだとか、多重下請けだとかは、単に、

  • そういう困った関係を正常化する為の擬制に過ぎない、
  • 上司部下だと致命的に関係が悪化するが、
  • 弊社御社だと奇跡に等しい位、関係が改善される

からだけだと私は思います。

もちろん、アメリカの様にエンジニアが一部司法にまで絡む位の公的存在となる様な風土だった場合、話は別かも知れませんが、
そうでは無いので、別の擬制が必要です。それが弊社御社の擬制だと思います。

 

もしSIerを打破出来たとすると

もしSIerを打破出来たとすると、上司となったその人は、部下に何をするでしょうか?当然、

  • 上流から疲労を助長する指示をして、 疲労困憊させ、失敗を助長し、 (因果推論を含む調査分析有りの)プログラミング開発はくだらないという証拠にしようとする

と思います。

 

因果推論を自動化する為の(形而上的)関数

ここで見方を変えて、

  • くだらなく無いものとは何を想定していたのか?

考えたいと思います。関数の発呼被呼は因果を表します。それは確かだと思います。

多分ですが、

  • 関数の発呼被呼だけでプログラミングをし、
  • 見通しをよく出来ると思った

のかも知れません。

しかし、例えば関数型プログラム言語のlispが、

  • 始原的には関数の連鎖のみで、大した事は出来なかったが、
  • Common Lispで言う所の)setq や、progn の様なスペシャルフォームが出来、そうなって初めて出来る事が増えた
  • 関数の連鎖が前で、setqやprognは大分後。

と言う故事を持ち出すまでも無く、関数の発呼被呼のみでは大した事が出来ず、

  • くだらないと言えるだけのより良さを一才出さない(出せない)
  • なぜなら始原的な初歩的なやり方を新しいと称して引っ張り出しただけ

なので、この様な事態になったのでは無いかと言うのが私の想像です。
糾える縄の如しです*1

 

結論

これからも「因果推論による良い寿司成分の欠乏」でプログラミングが絶望的に嫌いになる人は存在し続けることでしょう。

 

 

 

 

*1:この言い方だと「幸福と不幸は交互にやってくるものだ」と言う意味になり、その内、こちらに不幸が戻って来るのかも知れませんが、定年を過ぎ、どっかの経理一筋のおっさんが老境に至ってから本を出そうとするのと同じ様に、一区切りが付けば先のことは良いと思っているので、それでもしょうがないでしょうww。