dotkuwaの日記: 切り捨て 3
「駅前のーケーキ屋に。」
「あーあそこ。」
「新製品のケーキがあった。」
「へぇ。」
という会話は、世界を切り捨てています。
駅前のケーキ屋のみを持ち上げて、それ以外を
黙殺しています。
路傍の石のごとくとか、対比できる物質世界の別の
ものとしてどころでは無く、完全な無視です。
制御に関するプログラムもまさにそうです。
様々な責務のAPIを参照しつつ、特定の可能性のみを
優遇し他を捨て去ります。
全ての可能性を捨て去らない場合、考える手間は
べき乗やそれ以上の耐えられない場合の数になる
でしょう。
それに対して、プログラムの1行1行で可能性を捨て去れば、
考える手間は、対数のべき乗になったりするでしょう。
---------------------
切り捨てが功を奏するためには、
・世界が広い方が良い。多様な方が良い。
です。
その方が切り捨てた際の効率がアップします。
なので、制御に関するプログラムは関数ではダメです。
理由は、
・関数は単一の責務とか、その責務に見合うだけの比較的
少量の入出力が好まれるが、
制御に関するプログラムは、多くの責務を参照すれば
するほどお得だし、その責務に見合うだけの(形の上から
言うと)億万の相異なる入出力が必要になる。
・多くの責務をまとめ上げる為に、変更に対して開いていない
といけない。
からです。
---------------------
失敗に対する早目の切り捨ても重要です。
そのままでは致命的な結果を呼ぶ、人間の誤った入力は、
何一つ処理をする前に、切り捨てるべきです。
それをするためには、単一責務ではない、雑多な責務
(「制御」という責務と言おうとしましたが、自分は、
プログラムには上位概念も下位概念も無いと言い続けて
いるので、駄目です。責務が自然言語だったら良かった
のですが。。。)を、人間の勝手さを面倒見るという
目的だけに、雑多に並べる事になるでしょう。
早目の切り捨ての為には、例外も必要でしょうし、nulも
必要でしょう。早目の切り捨てをしないからnulに引っかかって
身動きが取れなくなるのでしょう。
関数に(少なくとも)2通り有る様な (スコア:1)
・「構文」とは言語の不可欠な一部分で、上位概念でも下位概念でも
ないとします。
・「型」も「構文」の一種とします。「型」がプログラムの一部を
肩代わりして、より見通しが良くなるという事は無いので、
妥当だと思います。
・「概念」とは、現にある有形無形の何かに理屈を付けた(つまり
有形無形のなにかそのものではない)結果とします。
・「制御」とは、切り捨てて、早く、安定させるプログラムです。
概念上の「関数」とは、単一の責務を負うものです。しかし構文上の
「関数」は違います。
Java言語など、プログラムを書ける場所はfunctionだけ(最近増えました
が大した違いはないです)なので、概念上の制御もfunctionに書かない
といけませんし、SubとFunctionがあるVisual Basicでも、絶対にSub
でなければならない箇所以外はFunctionで書くのが普通なので、
こちらも、概念上の制御を構文上の「関数」に書かないとなりません。
(F5で即実行させるには、Public Functionでないとならない。)
Re:関数に(少なくとも)2通り有る様な (スコア:1)
・構文上の関数と概念上の関数は一致している事が
望ましい。
・しかし何らかの理由で困難である。一つには、概念
上の関数が「見えにくい」為ではないか?
・「おたくの考え過ぎ」と言われていたものだが、
紛れもなく必要なものだと思う。
・「おたくの考え過ぎ」という意見を取り入れ、
それが浸透した開発拠点からは、開発能力が面白い
様に失われるからである。
・この差異こそが技術的負債である。
・テストは大変で必ず債務が生じるが、テストをして
しまったことで、構文上の関数と概念上の関数の
不一致が、その債務の大きさにより固定化される
為である。
・詳細設計とは、構文上の関数と概念上の関数の一致
を導く設計ではないか?
・自動テストは構文上の関数に対して行われるが、
プログラムを一から考える人がまず気にするのは、
概念上の関数である。
・このずれが「テストを初めに書くこと」を困難に
している。プログラムを一から考える人の最終目的で
ある、構文上の関数と概念上の関数の一致を、
はじめからやれと強要する形になるからである。
・それをやる分かりやすい手順を示してくれるなら
自分も転ぶでしょうけれど、まったく示してくれない。
・少量の利点の為に、大量の失点を呼び込むさまは、
まるで疑似科学の様である。
例えるなら、 (スコア:1)
例えるなら、
・テストや構文は整数に、
・概念は実数やそれよりすごい数に、
それぞれなぞらえる事が可能だとします。
テストは1つ1つ新たな気持ちでやります。
自分らで作った、売り物のMS Accessのアプリの
改修で、1日新旧50組のハードコピーをExcelに
張り付ける事を10日した事があります。
1組1組新たな気持ちで入力し、目的通り新旧が
違っているか、変な動きは無いかとかを一々
確認します。
これは、整数になぞらえるのが良いと思います。
#その時、外部からの手伝いの人は、DAO SQLの
#Insert Selectの癖に引っかかって、
#(標準SQLは位置で対応付けるが、DAO SQLは
#名前で対応付ける)そのまま来なくなりま
#したので自分でテストをしました。
対しまして、概念は実数やそれよりすごい数だと
思います。
ですので、初めからテストで概念を数え上げるのは
非常に難易度の高い事だと思います。
(というか不可能の代名詞だったり)
プログラムを作っていくと、自然にいろいろな箇所で
制限が加わり、ある程度以上行くと「制限の加わった
実数」になると思います。
それなら整数と対応付くと思います。
そしてそれは、世界のある部分以外を黙殺する事で、
達成されます。
何を黙殺するかを間違えると、後で「使えない」と
言われるのでしょうけれど、何らかの黙殺は絶対条件
です。
そうなるまで、テストは控えるべきです。
「ユニットテスト」と言っても(言い得て妙で)確かに
テストです。それにより構文の修正やリファクタリングが
決定的に阻害されます。
「ユニットテスト」をするとリファクタリングがやり易く
なるというのは正反対です。
#もちろんすべての修正に対して、極短い時間で正しい
#「ユニットテスト」を永久に(後継者の育成も含めて)、
#安価に、提供してくれるならそれは正しいですが、
#無理の様に思えてなりません。自分はいやです。