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

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

因果推論に関する教示 3

フェルマーの最終定理

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

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

という代わりに、

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

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

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

 

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

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

それは、

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

です。

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

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

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

です。

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

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

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

 

結論

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