何を飛ばしていたのか？ ２

科学の不在？

第一原理　Wikipedia 日本語版の、自然科学における第一原理 項に、

• 近似や経験的なパラメータ等を含まない最も根本となる基本法則をさし

と有りますが、これが無いとモダンな科学とは言えないと思います。

何で技術的飛ばしの様な、事になったかと言うと、

• 情報処理、ソフトウェア界隈では、第一原理が無い
• 情報処理、ソフトウェア界隈では、科学が無い
• その場の流行りとかで上限の原因が決まり、
• そこのみから、下位の（細分化された）原因を思いつく

のが原理原則なのに、

• 科学的（wwww）な知見を得た人間が、
• いきなりやって来て、
• 第一原理を駆使して、革新を成し遂げる

とか筋書きを立てたからだと思います。

情報処理、ソフトウェア界隈では、科学がない、全て技術のみなのかも知れません。基礎的な話は、数学とかから摘んで来れば良いと思います。

因果ダイアログだって、統計学の分野です。

それを無理して科学にしようとして、技術的な飛ばしをしただけとなったのだと思います。

「高階関数」のおかしさ

『「高階関数」のおかしさ　４』で、不変な変数は１の集合で、その型の冪乗はやっぱり１の集合ではないか？と書きましたが、

これも無理やり不在な科学を丁稚上げようとした結果だと思います。

『コンピュータサイエンスの超絶必須前提条件　１』で、

• 何かおかしい、コンピュータサイエンスの前提条件に哲学とかを加えるべきではないか？

と書きましたが、

• コンピュータサイエンスなどそもそも無かった。
• 情報処理、ソフトウエア界隈では、基礎的な話は哲学とから摘んで来れば良い

とした方がずっと自然でした。

先入観とは恐ろしいものです。

結論

これからも「何を飛ばしていたのか？」が不詳な状況でプログラミングが嫌いになる人は存在し続けることでしょう。

何を飛ばしていたのか？ １

どの様な話？

今まで、このブログで、

• 束因果ダイアログの矢印の事を「射」になぞらえていました、
• これは誤りだった

と反省しています。

射 (圏論)　Wikipedia 日本語版で、グラフの「分岐」、「合流」について、

可換図式

• 同じ事柄の別表現

を表すのに使っています。

なお、上図中の白丸は、

• 合成と呼ばれる二項演算 hom(X, Y) × hom(Y, Z) → hom(X, Z) 

を意味するそうです。

しかし、「ソフトウェア開発での束因果ダイアグラムが不明瞭　１」での、「分岐」、「合流」では、

「分岐」は、

• ある原因を、お互いに重ならない、より小さな原因に分ける

か、

• 同じ原因で、複数の結果が違う場所で出来る

様な意味で使っていました。

さらに、「合流」は、

• より大きいプログラムの部分への集約（「smallで無いテストの困難さ　１」）

の意味で使っていました。

因果ダイアログ（DAG）に立ち返ると

Copilot Proに、

• 因果ダイアログでの「矢印」はどういう意味でしょうか？

と聞いた所、

• Z → X なら「ZがXの原因」
• Z → Y もあれば、「ZはXとYの共通原因」

との回答を得ました、「分岐」について、束因果ダイアログは（当然）、

• 因果ダイアログ”寄り”だった

と気付かされました。

逆もまた真？

プログラミング”寄り”の人間からすると、「分岐」、「合流」の意味論は、後者の方が自然だと思います。

しかし数学”寄り”の人間からすると、前者の方が自然なのかも知れません。

• 可換で使いやすい合成のみがプログラムの本質だ

と思っていたのでは無いかと仮定すると、関数型プログラミングを主張していた人間の振る舞いを、かなり説明出来るからです。

そして、その仮定からすると、

• 合成のみが本質だとすると、プログラミングのかなりの部分を飛ばす

事になると思います。

すなわち、束因果ダイアログで言う、

• 「分岐」は、
• 何で思いつくのか？（設計段階）

で、

• 「合流」は、
• 何で自動で動くのか？（運用を考慮した実装段階）

を表し、それらは、関数型プログラミングを主張していた人間から漏れていた、まさにその部分を表すからです。

「合成」は何処へ行く？

プログラミング寄りの人間からすると、「合成」は、

• 合成し切ったものをもっぱら用い、
• 合成の各”部分”は等閑視（なおざりに）する

のだと思います。プログラミング寄りの人間からすると、そちらの方が感覚的に、よりしっくり来ると思います。

何て呼べばいい？

射 (圏論)　Wikipedia 日本語版で、

• 圏論における射はこのような概念を一般化したものである。考える数学的対象は集合である必要はないし、それらの間の関係性である射は写像よりももっと一般の何ものかでありうる。
  （緑太字筆者）

と有るのですし、射の概念のこの部分は、束因果ダイアログでも合致するので、

• 矢印の事は、
• 射改め、関係

と呼びたいと思います。

結論

これからも「何を飛ばしていたのか？」が不詳な状況でプログラミングが嫌いになる人は存在し続けることでしょう。

圏論の無駄遣い ４

「負債」と「飛ばし」の違い

「負債」は、

• 自分たちの為にそれを甘受し、
• 自分たちがいつかは解消する意思を持つ

もので、「飛ばし」は、

• 自分たちの為にそれを組成し、
• 被害を被るのは他人

というものだと思います。つまり、「自分たち」かどうかがどちらの基準でも大きな判断基準となっています。

アカデミアの分野で、「自分たち」に入れてもらえるか？

それは大変だと思います。だから、アカデミアの分野で、ソフトウェア開発について、新しい手法を伝授されようとするのは、困難で、得られるものは、すべて「飛ばし」になると思います。

関数型プログラミングはアカデミア由来で、テスト駆動もアカデミア由来で、それ故、一般人にとって、それらは技術的飛ばしとして観測されるのだと思います。

商用の分野ではどうか？

商用の分野では、アカデミアの分野よりは入れてもらえ易くなると思います。ただ、未来に渡る業績として歴史に名を刻むのは無理です。テスト要員になったりするかも知れません。

新しい科学は、

新しい科学は、いろいろ定まっていないが故に、

• 良いものを悪いと言い、悪いものを良いと言う

事も有ります。それは（例えばガリレオ・ガリレイの様に）広く世に知らしめようとした際に起こると思います。「自分たち」かどうかがその基準となると思います。

このブログはどうなのだ？

このブログは、

• より悪い方（ソフトウェアを表す圏は、局所的にも小さく無い（大きい））

を主張しています。どうやっても新規性が得られない主張です。Qiitaとかで書くと非難轟々になり、ポエム扱いされかねない主張です。

だから、まだ大丈夫なのかも知れません。新しい科学での主張には韜晦も必要なのかも知れません。

結論

これからも「圏論の無駄遣い」でプログラミングが嫌いになる人は存在し続けることでしょう。

圏論の無駄遣い ３

技術的飛ばし

技術的負債は、時には、或いは短期間なら、悪くない場合も有りましょうけれど、確実に不味いものとして、技術的飛ばしが有ると思います。

「飛ばし」という用語は、どこにも包括的な意味が書いていませんでしたが、

• 複雑なスキームを絡めて
• 訳が分からない様にして、
• 損を先送りにする

と、私は理解しました。

 

「対象や射」のレベルと「モナド」のレベルの間

「対象や射」のレベルと「モナド」のレベルの間には、「関手」という数学的な対象が有る様ですが、

この辺で、

• 数学的により良い

という見方が出てくる様です。例えば、

• 圏 (数学) （Wikipedia 日本語版）　→　圏の大きさ

の欄に、

• 数学における重要な圏の多くは、小さくないとしても、少なくとも局所的に小さい。

という記述が有りますが、「重要な圏」というのは、「数学的により良い」方向だと思います。

どこで「飛ばし」をしているか？

• ソフトウェアを表す圏は、
• 局所的にも小さく無い（大きい）

という可能性が有りますが、それを複雑なスキームを絡めて、

• 局所的に小さいとするなら

と強弁し、いつの間にか、

• 局所的に小さいというのが真である

としてしまうやり方こそが、技術的飛ばしでは無いでしょうか？

その飛ばしと引き換えに、

• ずっと使える自動テストが簡単に作れる

議論が成立してしまうのです。

結果、

• 損を先送りにされ、
• 後の人間が保守不能になる

という、新規開発者からすると夢の様な枠組み（保守担当者にとっての悪夢）になる訳です。

「技術的負債」では善悪に踏み込めない

「技術的負債」は、良い面（さっさと収益を得て、先に繋げる）も有り、非難の対象としづらい面が有ります。

しかし「技術的飛ばし」なら、

• 訳が分からない様にして、

という悪意が前提となり、より純粋に善悪に踏み込めると思います。

結論

これからも「圏論の無駄遣い」でプログラミングが嫌いになる人は存在し続けることでしょう。