因果推論に関する教示 ７

「束構造（ラティス構造）のグラフ」

プログラミングの場合、

• 「束構造（ラティス構造）*1  のグラフ」になる

とかは、昔読んだ雑誌（bit とか？）に書いて有っただけなのですが、

「束構造（ラティス構造）のグラフ」の因果ダイアログというのは、

• 良い構造

で、

• これを破る（因果ダイアログで、「初めが１つ、終わりも１つ」で無く、「初めが無限、終わりも無限」）と、
• 哲学的な一般的正しさに直面するが（ヒュームの帰納の問題？）、
• これ（因果ダイアログで、「初めが１つ、終わりも１つ」）に徹していると、
  コンピュータシステムの良さ（一般的な正しさなど、知ったことでは無く、当システムのみの正しさのみ）と出来る

のだと思います。

リファクタリングが必要な場合

「リファクタリング 既存のコードを安全に改善する（第２版） Martin fowler他 オーム社」の”一番最初の”「はじめに」で、

• 上の階層のクラスでは、クラスの共通の．．．サブクラスで頻繁にオーバーライドされていていた．．．コードをレビューして整理する必要がある

という記述がありました。

リファクタリングというのは、

• しなければならない場合

と

• 趣味、手遊び

に過ぎない場合に分かれると思いますが、前者となるのは、

• プログラムの原因が仕様変更になった場合、
  つまり、現在のプログラム（リファクタリングが必要）の原因は、
  現在の「束構造（ラティス構造）のグラフ」から漏れてしまっている
  （上限由来では無い「原因」が1本、枝毛の様に生えている）
  ので支障が出ている（「頻繁にオーバーライドされて」の様な）

や、

• プログラムを作った人間が、勝手に原因を作っている、
  つまり、現在のプログラム（リファクタリングが必要）の原因は、
  現在の「束構造（ラティス構造）のグラフ」から漏れてしまっている
  （上限由来では無い「原因」が1本、枝毛の様に生えている）
  ので支障が出ている（「頻繁にオーバーライドされて」の様な）

といった、『原因』、『結果』の上で、開いてしまっている場合に、一般的な正しさに直面させられてしまい、
リファクタリングが必要になってしまう。

というシナリオが考えられるのでは無いか？　という考えです。

「拡張に対して開いている」？？？？？？？

拡張に対して開いている、と言われますが、

• 拡張時に、
• 閉じた（「束構造（ラティス構造）の」）因果ダイアログから、
• 別の閉じた（「束構造（ラティス構造）の」）因果ダイアログへ、
• 変更になるだけで、
• 開いている（一般的な正しさに直面する）という重大な事態にコンピュータシステムがお付き合いする必要性など皆無

では無いかと考えます。

結論

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

*1:束 (束論)　Wikipedia 日本語版

因果推論に関する教示 ６

プログラムの原因なんて一目瞭然では無いのか？

前に「常識が通じない　１」で、

「非常識」とは、

• 多数の人間が体験するさまざまな可能性の中から、起こりにくい事
• しかし全歴史の中で1回しか起きていないとかでは無く、もう少し頻度の高い事

とし、

• このプログラムで「必要な」「非常識」とは何か
• プログラム内では陰に表現されているのみ（苦労して読み解かないと見えない）

と書きましたが、本当にそうだと思います。

要求こそプログラムの原因では無いのか？

• 要求が有るからこそで、それがプログラムの原因では無いのか？

というのは部分的に正しいとは思います。ただ、

• 要求は、因果ダイアログの上限の方にあり、プログラムは下限の方にあり、
• 欲しいのは、プログラムと近い原因、かつ要求ともリンクされたもの

だと思います。

前に「テストを書いてくれない　１」で書きました通り、

状況を模式的に言うなら、

• 要件定義書とは、いくつかの必要とする点を指定したもの
• プログラミングとは、それにふさわしい滑らかな曲線を描くこと
• ふさわしい滑らかな曲線は、複数存在する
• 「無限」で無く、「複数」なのは、プログラミングの技術的制約のため

であり、要求より因果ダイアログで、プログラムにより近しいはずの要件定義書であってすら、プログラムとより遠い原因となります。

昔は書いていたが、書かなくなった

昔はコボラーとして、詳細設計書は書いていました。しかしだんだん書かなくなりました。

（それらを規則として書かせなくなった）理由は、

• 不純だ

からだと思います。プログラムが全てで、それに関する説明など余計だという主張が主流になったからだと思います。*1

「因果推論の科学　「なぜ？」の問いにどう答えるか」でベイズ統計学が迫害された歴史について書いていますが、モデル（因果ダイアログ）を使うことが

• 不純だ

とされた歴史的事実と相似するのかも知れません。

結論

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

*1:もちろん、裏の理由として「書くと検証され易くなって、間違いを指摘され易くなるから」というのも有ったと思います。

因果推論に関する教示 ５

「負債」で無いもの

• 一つだけの関数の「実行」と、
• その前後に有る「準備」と「確認」

からなる「テスト」は、まさか「負債」呼ばわりはされないと思います。

「負債」呼ばわりされるコードとは、それとは様相を異にする物でなければならないと、思います。

「負債」とは？

以下、「『』」で囲われた言葉は、前出の

• 「ジューディア・パール,ダナ・マッケンジー. 因果推論の科学　「なぜ？」の問いにどう答えるか (Japanese Edition)　文藝春秋社」

に書いてある用語とします。

「負債」とは、

• 『因果ダイアグラム』*1で表現される、
• 『原因』と『結果』の連なりで、
• 『原因』から『結果』を推論するのは比較的容易だが、逆は非常に困難であるという性質から、
• 逆を強いられる人間にしてみると、正しく「負債」にしか見えない

ものだと思います。

具体的には、現時点では２種類思いつきましたので、述べます。

「負債」の例

1.  「テスト」より、より負債的な（実際の規模の）プログラムでは、
   複数の関数が、『因果ダイアグラム』の様に、「絡み合い」ながら呼び出され、しかしプログラム言語は上から下へ、並べて書くより無いので、その「絡み合い」は明記されておらず、
   解読しようとする人間が手間暇かけて、多量の誤解含みで読み解く必要が有る。
   
   
2.  プログラムを書く『原因』と、
   『結果』としてのプログラム
   に関する、『因果ダイアログ』は文書化される事が稀で、
   『結果』としてのプログラムのみから、『原因』を導き出す事が禁止的に困難。
   なので、（そこまで文書化されていない通常の）ブログラムは「負債」に他ならない！

という２種類は（少なくとも）有ると思います。

結論

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

*1:プログラムでは普通「束構造（ラティス構造）のグラフ」（束 (束論)　Wikipedia 日本語版）の様にダイアグラムに上限と下限を持つ事が多い。

因果推論に関する教示 ４

そのものズバリの記述

「単体テストの考え方/使い方」（Vladimir Khorikov (著), 須田智之 (訳)、マイナビ）という本に”そのものズバリ”の記述が有りました。

• 第4章 良い単体テストを構成する4本の柱　1本目の柱：退行(regression)に対する保護 に、
• 「悲しいことに、プログラミングにおいて、コードは資産ではなく、負債」
  （太字原文ママ）

とあります。

これは、「因果推論に関する教示　２」で述べた、

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

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

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

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

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

と付合すると思います。

また、「因果推論に関する教示　３」で述べた、

• 技術的負債が０の手法は動かない（形而上だ）

という言い方とも通底するのでは無いかとも思います。

たまたまでは無い様に思えます。

結論

因果推論はどう考えても、第一原理だとは思いますが、それを説明するのは困難で、理解し合うのに向かず、逆に、今回の説明の様に「本筋では無い」記述が大切なのかも知れず、それゆえ、
これからも「因果推論に関する教示」を周りの人にされる事でプログラミングが嫌いになる人は存在し続けることでしょう。