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

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

最後の敵? 1

どの様な話?

お話の世界ではよく、

  • 最後の敵は人間だ
  • 一番怖いのは人間だ

とされる事があります。

しかし技術の世界では、それを言っちゃお終い、的な風潮もあります。

では、

  • 最後の敵は「複数の見方」
  • 人間はその代弁者として振る舞う為、最後の敵が人間に見える
  • (AIが発達していない現在)プログラミング自体は自分では変革せず、責任も取らないので、代弁者は必ず必要*1

としたらどうでしょうか?

 

必要悪としての流行り廃り

流行りとは、

  • 「複数の見方」の中庸となりつつ
  • 現在のハードウェア技術、ソフトウェア技術を十全に満たす事が出来る

やり方で、最後の敵に一々直面する事なく回避するやり方かも知れません。

そして、廃りとは、

  • そのやり方が十全で無くなった

時に起こる事かも知れません。

 

流行りは「中庸」であるべきである

ですので、極端に特定の見方を優先するやり方を「流行り」とするのは定義上誤りなのかも知れません。流行りは「中庸」であるべきです。

また、ある一世を風靡した見方がダメだったとしても、それを完全に廃して別の見方にするというのは矢張りダメで、前の全ての見方に今度の見方を足したものを採用するのが妥当だと思います。

 

結論

 これからも「最後の敵?」の存在でプログラミングが嫌いになる人は存在し続けることでしょう。

*1:当ブログのタイトルもここから来ています。

因果推論に関する教示 3

フェルマーの最終定理

フェルマーの最終定理 サイモン・シン 青木 薫訳 新潮社」と言う本を読んだのですが、それにあやかって、

  • 「手続き型よりも形而下関数型よりもオブジェクト指向よりも優れていて、
     しかもプログラミングの中身を見なくても良い、と言う特徴を持った」
    関数型を標榜する手法など形而上だ

という代わりに、

  • 「手続き型よりも形而下関数型よりもオブジェクト指向よりも優れていて、
     しかもプログラミングの中身を見なくても良い、と言う特徴を持った」
    関数型を標榜する手法は、技術的負債が0の手法とペアになる
  • 技術的負債が0の手法は動かない(形而上だ)

と言えば良いのでは無いかと思ったりしたのでした。

このブログで言っている「形而上関数型プログラミング」なんて蜘蛛を掴むような話ですが、そう整理するとより解り易くなるのでは、とも思いました。

 

技術的負債が0となる手法

でも、ただ直感だけで技術的負債が0となる手法は動かないのでは無いか? と思った訳では有りません。理由はあります。

それは、

  • ある共存する複数の見方の1つで技術的負債を減らすと、別の見方で技術的負債が増える傾向にある。
  • 例えば、共通機能と個別事情とか中身を見ない立場と見る立場(こちらはプログラムを実際に作る立場を想定)

です。

個別事情の負債を減らし共通機能にすると、プログラムの修正時・テスト時に、違う個別事情に関する動作まで変わってしまい、テスト範囲が広がるという負債が増えたり、

テストが簡単になる様に共通機能を極力排すると、プログラムの修正時に修正箇所が個別事情に応じて多量になったり、

中身を見ない立場の人が良い様に負債を減らすと、中身を見る立場の人から見て負債が増えるなどなど、、

です。

動くプログラムにも関わらず、

  • 複数の見方が無いか(見方は1つのみ)
  • 全ての見方が同じ様な傾向で負債が減るとか(減り方は1つのみ)

とかでしたら良いのですが、その様な虫の良い話も(どうすれば出来るか)全く見当も付きません。

 

結論

これからも「因果推論に関する教示」を周りの人にされる事でプログラミングが嫌いになる人は存在し続けることでしょう。

 

因果推論に関する教示 2

技術的負債

技術的負債とは、

  • 技術的負債(英語: technical debt)、または設計負債、コード負債とは、ソフトウェア開発における概念であり、時間がかかるより良いアプローチを使用する代わりに、今すぐ簡単な(限定的な)解決策を選択することで生じる追加の手直しの暗黙のコストを反映したものである。
    (技術的負債 Wikipedia 日本語版より、太字筆者)

ですが、

ここで最高に良いアプローチ(負債0)を考えますが、

思いますに、それは、

  • 動くプログラムになるのか

疑問です。

ある程度の負債含みの「簡単な(限定的な)」解決策こそが、

  • 動くプログラムになる要因(本質)そのもの

で有り、プログラミングを学ぶとは、その、

  • 最小限の技術的負債に見える解決策

を学ぶ事では無いかと言う仮説です。

 

本当に「間抜けばかり」なので、技術的負債が出来るのか?

勿論、「より良いアプローチ」から必要以上にかけ離れて、プログラムを作るのは間抜けかも知れませんが、
そこまでの、学ばない間抜け人間がごろごろ転がっているものでしょうか?

流石にそれは行き過ぎの認識に思えます。

技術的負債0のプログラムを構成的に作れるなら、何で作らないのか、例によって、それはほぼ藁で、形而上の議論に過ぎず、

技術的負債は、動くプログラムでは必ず混入するだけでは無いか?

そしてだからこそ、プログラムを学ぶとは、

  • より良いアプローチで無い何かを学ぶという事で、
  • 試作もせずに、考えて学ぼうとしても、動かない極々極々理想的な何かになってしまう

とすると、1つの説明が付きます。

 

結論

これからも「因果推論に関する教示」を周りの人にされる事でプログラミングが嫌いになる人は存在し続けることでしょう。

 

因果推論に関する教示 1

どの様な話?

前に、「調査分析(因果推論)」について、

  • 大切だ
  • キモだ
  • 出来たら一人前だ

とか言いましたが、もしかしたらそれを「教示する」事も、

  • 専門職の似た分野に関する手抜き

かも知れないと思う様になりました。

プログラミングの実務家(私)が、似た分野であるプログラミングの教習について、手抜きをしたのでは無いか、
と言う話です。

 

バイクの教習中

そういえば、バイクの教習中、

  • バックミラーの情報だけで
  • 後ろから来る教習所の先生のバイクの
  • (多分わざとの)次のタイミングで危険となりうる速度・方向に対し
  • 双方安全な様に
  • 自車の位置どりを変えた(ぶっちゃけ後車の進路の邪魔をした)

ら、途端に「一本橋なんかもういいから次へ行け」となりました*1

どうやってその(一種の)因果推論について「教示する」かなど、言葉でくどくど言うのは、勿論悪手だと、バイクの教習だと一目瞭然だと(世の中の人全員が)思います。

 

何故か、ソフトウェア開発ではそうでは無いと思い込んでしまうものなのかも知れません。プログラミングで、

  • 実際にある情報だけで(ログとか計算結果とか)
  • 失意・故意などさまざまな要因から生じる、
  • 色々な不具合の危険箇所を
  • 現在・将来に渡り安全な様に
  • 設計を調節する

と言う事は、

  • 理詰めで教示出来る、教わる事が来る

と教師・生徒共に思い込んでしまう様ですが、
これって藁だらけでは無いでしょうか?
因果推論は総じて理詰めで教わる事は不可能かも知れません。

 

一人前のプログラマー

(上記の様な、決して高度では無い、)プログラミングでの因果推論を、100%きちんと出来る、当たり前の様に出来ると、一人前のプログラマーと言って良いと思いますが、

どうしたらそうなるかについて、

  • 言葉でくどくど言うのが
  • 悪手なのは、当然で、
  • (似たような分野の専門職である)プログラマーが、
  • 教習のつもりで、
  • それについて言葉で言う

のは似た分野に関する手抜きだったかも知れません。反省しています。
単に、どんどん試作をしましょう。

 

結論

これからも「因果推論に関する教示」を周りの人にされる事でプログラミングが嫌いになる人は存在し続けることでしょう。

 

*1:ただ、それが出来たのは、双方「ご安全に」の精神だったからで、最近のドラレコ動画なんかを見ていると、他車は***そうでは無い***と思わないと逝けない様で、もうバイクに乗るのは懲り懲りに思えます。