ごきぶりの雌と研究者 ５ (original) (raw)

今更何が悪いのか

• 厳密で
• 分かりやすい

は、それを信奉する人が「ナンバーツー」までの間なら、それ程問題にはならないと思いますが、「ナンバーワン」になった途端、

• 周りの旧人の困るルールを作り、
• それを新しい

とする行為の問題点が、自分（と部下・配下全員）に容赦無く降りかかるのです。

小さい所ならすぐ、「ナンバーワン」にもなれるでしょうけれど、そこで問題が起きても、そこが潰れるだけで、大した社会的影響は起きないけれど、

面壁20年とかで、社会に大きい影響を与える所の「ナンバーワン」になった途端、その「弱い毒」は、自らを炎上させる原因になる訳です。

コンビニで書類を出し損なうとかも、厳密で分かりやすい（＝旧来の問題意識自体が大袈裟だ）という考えの結果かも知れません。
（ロックを単なるマイクロ秒単位のタイムスタンプだけにしてしまったとか？）

何で厳密が悪いのか、分かりやすいが悪いのか？（厳密側）

「厳密」側は、プログラミングではいじり様が無いと思います。プログラミング言語である限り無条件に「厳密」です。

名前を分かりやすくする程度は出来ますが、

• 分かりにくい部分を分かりやすくする

のは出来ても、

• さらに分かりやすくする

のは出来ません。原因が無い結果は不純です。多分これをやろうとする衝動は、「科学の宿痾」かも知れません。
原因が無いのに無理やり分かり「やすく」する事は不可能です。

COBOLシステムで、

• 項目名が変で、全く意味が通らないのに、読み替えて使っている

とかは、逆に分かりやすさを追求した結果だと解釈すべきです。

厳密な中で分かりやすさも追求すると、後の少しの変化で壊滅的に分かり難くなるのは、理屈が通った話で、事実でも有ります。

何で厳密が悪いのか、分かりやすいが悪いのか？（分かりやすい側）

逆に「分かりやすい」を厳密にする方向は、今まで無かったと思います。

誰もが心の中ではやるべきだ、と思っている事かも知れませんが、現実には今まで無かったと思います。

プログラミングの分野では、束構造の因果ダイアグラムは、これに向いていると思います。

• システムを作ろうとする発端を上限とし、
• 原因→結果を積み重ねて、詳細化され、
• プログラムの各部分に対して、（最も詳細化され、プログラミング中も更新される）原因たちからの有向グラフが付き、
• 「上限から最も詳細化されたグラフ」のどこにも無い原因を根拠にした、結果としてのプログラムは、お宅の考え過ぎとして排除・修正する根拠ともなる

からです。

どうすれば良いのか（私見）

• 厳密優勢記述

と

• 分かりやすさ優勢記述

を分けるべきだと思います。

前者は、プログラム＋テストで良いと思います。ただし分かりやすさは程々が良いです。
後者は、束構造の因果ダイアグラムが良いと思います。自然言語でかつ「半構造」より、"全"構造的に近い記述です。

ただし、後者はその実施方法に特許がかかっている可能性がある為、20年とは言わなくても、10年は先になると思います。それまでは、学術的に調べるのが良いと思います。

結論

これからも「ごきぶりの雌と研究者」の例えの通りの毒が回り、プログラミングが嫌いになる人は存在し続けることでしょう。