dotkuwaの日記： 「好ましい」負債とは 10
日記 by
dotkuwa
「好ましい」負債とは、
・全体を統計でしか見ることが出来ない場合に、個々の物件では、
全体を出し抜くことが可能。
・その出し抜くをする為に、利子を払ってもお金を借りるのが有効
なので好ましい。
で、
・全体を統計で見ることが出来ない分野では、負債に良さは現れ
ない。
プログラミングの分野はこれでは無いか？
・（チューリング賞受賞公演の本で見たのですが）ランダムを実現する
プログラムをランダムに選ぶと、ランダムさが落ちる
とかの話が有りました。
たとえ、統計を表すプログラムであっても「なぜかうまく行っている相関」
ですますのはダメで、
AIであっても、人間に説明がつく様にする為には、そのプログラムが
「なぜかうまく行っている相関」ですますのはダメではないか？
投機的実行 (スコア:1)
投機的実行が思い浮かべられますが、統計的に有効なら「好ましい」負債と呼べるのではないでしょうか？
Re:投機的実行 (スコア:1)
『統計的に有効なら』好ましいです。
ただ、
・Aという処理をやった後にBという処理をするのが100％
・Aという処理は長く、Bという処理は一瞬である可能性が99.99％
しかない場合に、Bを投機的に実行して好ましいのか？
それとも単なる衒学的議論なのか、本当に『統計的に有効』なのか
疑問です。
特にAが入力である場合、入力内容が何なのか分かる前にBを
投機的に実行しても、何も好ましく無いと思います。
自分が「全体を統計で見ることが出来ない分野」と申しましたのは、
投機が効かないという意味でもありました。
もし投機が本当に効くなら、全実用プログラム言語で、
最重要機能として位置付けられて当然のはずですが、そうなって
いません。
その事も、「全体を統計で見ることが出来ない分野」が事実である
ことの傍証になると思います。
たしかに歴史的に見て、第五世代言語（単にリレーショナルDBの
原理を「分かりやすく」書いただけのものを、AIに関する万能の
機構であると言い張り、無駄金を使わせた）以降、
他の科学に範を求めるべきだと、思われても仕方のない状況であった
のも確かですが、
だからと言って、合わない科学を合うと言い張られても困りますし、
そういう事を言った人間には等しくペナルティーが与えられる
べきです。
（合わない科学の学位のみを持っている人間に口出しはさせないなど）
Re:投機的実行 (スコア:1)
何を「全体」と定義するかによると思います。
理論的な研究をするのでもない限り、あるプログラムで投機的実行が有効かどうかそれこそ統計を取ってみればよいのでは？
「プログラミングは統計でみることはできない！」などと逃げていてはだめです。
そもそも何で？ (スコア:1)
そもそも何で、「統計はダメだ」と言っている人間に統計を
勧めるのか理解出来ません。
・不十分ながらきちんと（テストも含めて）やっている
人間を、「蒙昧な職人（第一原理を踏まえないの意？）」
として、文字通り作業している手をはたき、
「お前のやり方ではだめだ」と言っておきながら、
・その後、何の改善もせず、逃げる
・その「職人」の言っていた事に何の不備も無かった。
事柄が起きたのは、
・ソフトウェア分野にも第一原理がある
・統計で処理可能である
という信念を持つ、
・別の科学に精通した、
・そこまで人様に嘴を挟めるだけの資格を持った
人間の存在であるはずです。
そもそもが、設計者実装者一致の確立した原理と、
発注者の原理の、出来上がってからの衝突（発注者は「違う」と
しか言う能力が無い）に対応する為の、
「艦隊の機動」を実現する為の、ウオーターフォール技法に対して、
第一原理が有り、統計的に全体を出し抜けるモデルでの
「自律的な分隊」を実現する為のアジャイル技法が
より良さを発揮出来ないのは、違う信念を持ち込んだ為に
他なりません。
バグの個数の予測など、定番のジョークにしかなっていない
のに、そもそも何で、統計を勧めるのでしょう？
昨今、少子化で、出来る若者の使い捨ては、昔に倍してダメな
ので、その対応として、
・違う科学の学位を持った人間
を失格とすべきと申しました。
学位を持っていなければ、そこまでの嘴は挟めなかった
はずですし、ソフトウェア関連の学位なら、
その様な事をしたら、ブーメランが襲ってくるでしょう。
不十分ながらもきちんとやってる人間の手をはたく人間を
排除すべきなのは、もっともでは無いでしょうか？
意思ではなく、能力を恐るべきです。
Re:そもそも何で？ (スコア:1)
なんだ、よくあることで、出来上がったプログラムが発注者の意図に合わず後から修正を迫られる図に文句をいっているんですね。
大きな意味で要件定義の失敗かと。
後から修正を迫る発注者に対して、プログラム作成側の上位は理路整然と拒否してほしいということでしょうか。いや拒否ではなく追加コストの提示か。
「学位」は関係ないんじゃ？
「プログラミングの分野は全体を統計としてみることができない分野であり、好ましい負債というものは存在しない。」とのご意見のようだったので、
「好ましい負債の一例として投機的実行ってのがあるんじゃないか。」と思い、
通常のプログラムでは、入力と出力がある程度限定され、「全体」を定義できるのでは？、限定された「全体」についてはサンプルで統計的に処理して投機的実行が負債として好ましいかどうか、有効であるかどうか判断できるのでないか？と思った次第です。
分野としてではなく、個々のプログラムに関しては有効な負債はあるのではないかとの意見です。
Re:そもそも何で？ (スコア:1)
＞なんだ、よくあることで、出来上がったプログラムが発注者の意図に合わず後から修正を迫られる図に文句をいっているんですね。
＞大きな意味で要件定義の失敗かと。
略
＞「学位」は関係ないんじゃ？
失敗ではなく、意図が合わないのはそういう性質の「別の科学」で有り、失敗と感じてしまう、
第一原理を持つ、それとは違う科学に精通した人が混じるとより状況が悪化すると申し上げており、
とくに違う科学の学位のみを持つ人が混じると悪化の度合いが増えるので排除すべきとの主張です。
＞分野としてではなく、個々のプログラムに関しては有効な負債はあるのではないかとの意見です。
「プログラミングの分野は全体を統計としてみることができない分野であり、好ましい負債というものは存在しない。」
という自説に対し、非常にマイナーな機能を持ち出され（0.0000000000程度の）、それに対し、サンプルを統計処理しろ
とおっしゃいますが、統計処理では、そこまでマイナーな部分は、それが必要不可欠な部分で無い場合、
切り捨てるのが普通だと理解していましたが、何でその様な強弁をなさるのか、不思議です。
プログラミングの負債 (スコア:0)
ライブラリは負債だね。
便利にすれば複雑になるし必要リソースも増える。
使用する部分だけ抜き出すようにすればリンカの手間が増える。
ライブラリに合わせる必要もあるし最適化も限定される。
でもこの負債は好ましい負債だよね。
今さら車輪の再発明をしたり限界までチューニングしたりなんてゾッとする。
これは逆に個々の物件では出し抜けない代わりに全体を安定化させるものでは。
金融でいえばリボ払いみたいな。
Re:プログラミングの負債 (スコア:1)
「好ましい」まで言えるか？です。
ライブラリは「なぜかうまく行っている相関」を作ってしまい、相関とは確率と同義で、
何割か（何分か、何毛か、、、）の確率で（自分の預かり知らぬ所での）不具合になります。
単なる土管（入出力）で利害差引0の負債（負債では無い）で、それ以上にアプリ系に
なるとうーんですよね。（アプリ系のライブラリなんて生き残っているものないですし）
どんなライブラリも、今生き残っているものは『入出力の自然な拡張』以外無いですし。。。
もちろん、統計的に処理をして自分の論文を書きたいが為に、わざと因果関係（ロジック）を
隠して相関に持ち込み（確率に持ち込み）、かえって負債を増やしてしまうとかと
違い、ライブラリは悪くは無いでしょうけれど、後が怖いのはリボ払いと一緒かも
知れません。
Re: (スコア:0)
統計的に言いたいのであれば、サンプル数の増加による不具合の顕在化などいかがでしょう。
毎回似たようなルーチンを作成していれば不具合の混入は確率的ですが、
ライブラリ使用により使用サンプルが増えることで不具合が発生し修正されることが期待できます。
もちろんそのライブラリに新規機能追加などがないことが前提ですが。
ライブラリというと限定されてしまい
アプリ系のライブラリなんて生き残っているものない
となってしまいますが、
それらはミドルウェアと言い換えられるのではないでしょうか。
Re:プログラミングの負債 (スコア:1)
＞サンプル数の増加による不具合の顕在化
を統計的に綺麗に言えるなら、それを公表すればかなりのインパクトがあると思います。
しかし（不勉強なのかもしれませんが）自分は酔歩以上の知見を持ちません。
結論として、無いのでは無いでしょうか？
それは、
原因→結果がきちんとしていれば、自分にとっては合わないプログラムでも、不具合とは
思わず、逆に、第三、第四、第五、、、の（無駄な）媒介が有り、動作がふにゃふにゃして
いると、不具合だと感じてしまう（その感覚はサンプル数とは関連しない）だけ、
では無いか、と申しております。
あと、「アプリ系」ミドルウェアですが、VBの昔から、今に至るまで、
・作り付けのイベント間（イベントは相独立）の連携のため、
・グローバルな状態フラグが沢山作られ、
・そんな事なら、関連した複数のイベントを一手に引き受け、
IF文で分岐する方が見通しが良くなる
（状態がローカルな文脈のみで表現できる）
のは変わりなく、標準のイベントを自分で持たないミドルウェアは、
「アプリ系」とは言えず、「入出力系」に分類されると思います。