パスワードを忘れた? アカウント作成
13573487 journal
日記

dotkuwaの日記: 切り捨て 3

日記 by dotkuwa

「駅前のーケーキ屋に。」
「あーあそこ。」
「新製品のケーキがあった。」
「へぇ。」
という会話は、世界を切り捨てています。
駅前のケーキ屋のみを持ち上げて、それ以外を
黙殺しています。
路傍の石のごとくとか、対比できる物質世界の別の
ものとしてどころでは無く、完全な無視です。
 
制御に関するプログラムもまさにそうです。
様々な責務のAPIを参照しつつ、特定の可能性のみを
優遇し他を捨て去ります。
 
全ての可能性を捨て去らない場合、考える手間は
べき乗やそれ以上の耐えられない場合の数になる
でしょう。
それに対して、プログラムの1行1行で可能性を捨て去れば、
考える手間は、対数のべき乗になったりするでしょう。
 
---------------------
 
切り捨てが功を奏するためには、
・世界が広い方が良い。多様な方が良い。
です。
その方が切り捨てた際の効率がアップします。
 
なので、制御に関するプログラムは関数ではダメです。
理由は、
・関数は単一の責務とか、その責務に見合うだけの比較的
 少量の入出力が好まれるが、
 制御に関するプログラムは、多くの責務を参照すれば
 するほどお得だし、その責務に見合うだけの(形の上から
 言うと)億万の相異なる入出力が必要になる。
・多くの責務をまとめ上げる為に、変更に対して開いていない
 といけない。
からです。
 
---------------------
 
失敗に対する早目の切り捨ても重要です。
そのままでは致命的な結果を呼ぶ、人間の誤った入力は、
何一つ処理をする前に、切り捨てるべきです。
それをするためには、単一責務ではない、雑多な責務
(「制御」という責務と言おうとしましたが、自分は、
 プログラムには上位概念も下位概念も無いと言い続けて
 いるので、駄目です。責務が自然言語だったら良かった
 のですが。。。)を、人間の勝手さを面倒見るという
目的だけに、雑多に並べる事になるでしょう。
 
早目の切り捨ての為には、例外も必要でしょうし、nulも
必要でしょう。早目の切り捨てをしないからnulに引っかかって
身動きが取れなくなるのでしょう。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • ・「構文」とは言語の不可欠な一部分で、上位概念でも下位概念でも
     ないとします。
    ・「型」も「構文」の一種とします。「型」がプログラムの一部を
     肩代わりして、より見通しが良くなるという事は無いので、
     妥当だと思います。
    ・「概念」とは、現にある有形無形の何かに理屈を付けた(つまり
     有形無形のなにかそのものではない)結果とします。
    ・「制御」とは、切り捨てて、早く、安定させるプログラムです。
     
    概念上の「関数」とは、単一の責務を負うものです。しかし構文上の
    「関数」は違います。
    Java言語など、プログラムを書ける場所はfunctionだけ(最近増えました
    が大した違いはないです)なので、概念上の制御もfunctionに書かない
    といけませんし、SubとFunctionがあるVisual Basicでも、絶対にSub
    でなければならない箇所以外はFunctionで書くのが普通なので、
    こちらも、概念上の制御を構文上の「関数」に書かないとなりません。
    (F5で即実行させるには、Public Functionでないとならない。)

    • ・構文上の関数と概念上の関数は一致している事が
       望ましい。
      ・しかし何らかの理由で困難である。一つには、概念
       上の関数が「見えにくい」為ではないか?
      ・「おたくの考え過ぎ」と言われていたものだが、
       紛れもなく必要なものだと思う。
      ・「おたくの考え過ぎ」という意見を取り入れ、
       それが浸透した開発拠点からは、開発能力が面白い
       様に失われるからである。
       
      ・この差異こそが技術的負債である。
      ・テストは大変で必ず債務が生じるが、テストをして
       しまったことで、構文上の関数と概念上の関数の
       不一致が、その債務の大きさにより固定化される
       為である。
      ・詳細設計とは、構文上の関数と概念上の関数の一致
       を導く設計ではないか?
       
      ・自動テストは構文上の関数に対して行われるが、
       プログラムを一から考える人がまず気にするのは、
       概念上の関数である。
      ・このずれが「テストを初めに書くこと」を困難に
       している。プログラムを一から考える人の最終目的で
       ある、構文上の関数と概念上の関数の一致を、
       はじめからやれと強要する形になるからである。
      ・それをやる分かりやすい手順を示してくれるなら
       自分も転ぶでしょうけれど、まったく示してくれない。
      ・少量の利点の為に、大量の失点を呼び込むさまは、
       まるで疑似科学の様である。

      親コメント
      • by dotkuwa (9387) on 2018年04月18日 19時31分 (#3395289) 日記

        例えるなら、
        ・テストや構文は整数に、
        ・概念は実数やそれよりすごい数に、
        それぞれなぞらえる事が可能だとします。
         
        テストは1つ1つ新たな気持ちでやります。
        自分らで作った、売り物のMS Accessのアプリの
        改修で、1日新旧50組のハードコピーをExcelに
        張り付ける事を10日した事があります。
        1組1組新たな気持ちで入力し、目的通り新旧が
        違っているか、変な動きは無いかとかを一々
        確認します。
        これは、整数になぞらえるのが良いと思います。
        #その時、外部からの手伝いの人は、DAO SQLの
        #Insert Selectの癖に引っかかって、
        #(標準SQLは位置で対応付けるが、DAO SQLは
        #名前で対応付ける)そのまま来なくなりま
        #したので自分でテストをしました。
         
        対しまして、概念は実数やそれよりすごい数だと
        思います。
        ですので、初めからテストで概念を数え上げるのは
        非常に難易度の高い事だと思います。
        (というか不可能の代名詞だったり)
         
        プログラムを作っていくと、自然にいろいろな箇所で
        制限が加わり、ある程度以上行くと「制限の加わった
        実数」になると思います。
        それなら整数と対応付くと思います。
         
        そしてそれは、世界のある部分以外を黙殺する事で、
        達成されます。
        何を黙殺するかを間違えると、後で「使えない」と
        言われるのでしょうけれど、何らかの黙殺は絶対条件
        です。
         
        そうなるまで、テストは控えるべきです。
        「ユニットテスト」と言っても(言い得て妙で)確かに
        テストです。それにより構文の修正やリファクタリングが
        決定的に阻害されます。
        「ユニットテスト」をするとリファクタリングがやり易く
        なるというのは正反対です。
        #もちろんすべての修正に対して、極短い時間で正しい
        #「ユニットテスト」を永久に(後継者の育成も含めて)、
        #安価に、提供してくれるならそれは正しいですが、
        #無理の様に思えてなりません。自分はいやです。

        親コメント
typodupeerror

UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie

読み込み中...