約束された失敗 ２

アイディア（仮説）の段階ですが、

アイディア（仮説）の段階ですが、関数型プログラミング何て「最弱」と言っていい様な、別の「約束された失敗」が有りました。
（このブログで、私が前から断片的に言っていた事ですが。。。）

それをすると、どんな大企業でもソフトウェア開発としては左前になり、それをしない人間がテコ入れをしないと、そのまま終わってしまうものです。

それは、

• ソフトウェア開発の可視化

だと思います。

普通、「可視化」とは言いましても、結局の所、

• 問題をある基準で分類し、
• 重い方から並べて、
• 重い方から順に管理する

事になると思いますが、プログラミングの問題分野では、

• それが絶対に出来ない問題構造となっている
• つまり、どんな基準で分類しても、管理に耐えられないレベル（レベル1000とか）に問題が残ってしまう為、
• 根本的に自然法則に準ずると言っても良い重みで、（前述したやり方の）ソフトウェア開発の可視化が不可能な構造になっている

のでは無いかと言うアイディア（仮説）です。

自動テストがはかばかしくない理由

自動テストもソフトウェア開発の可視化の1つだと思います。

• 問題を（プログラムを）固定された非常に厳密な基準で推しはかる

と言うやり方ですが、

自動テストが一瞬、上手く行ったとしても、それをなかなか維持出来ないのは、もしかすると、

• ソフトウェア開発の可視化は、失敗が約束されている

からかも知れませんし、それが実情に合っていると、私は強く思います。

結論

これからも「約束された失敗」でプログラミングが嫌いになる人は存在し続けることでしょう。

約束された失敗 １

どの様な話？

大抵のプログラム言語は、

• 関数（陽関数、陰関数を問わず）を基礎としている

のは動かし難い事実だと思います。

では何で、それが関数”型”となるとしょぼくなるのでしょうか？

それを手続型プログラミングをベンチマークとして、公理型、論理型、宣言型の様な、関数型と同期の新技術と比較して述べたいと思います。

結論から言いますと、

• 他は手続型と比べて、出来る事が多い建て付けになっているが、
• 関数型は次に述べる理由から出来る事が少ない

からだと思います。

• 「⚫︎ー⚪︎」をプログラミングだとして、
• ⚫︎を呼ぶ側、⚪︎を呼ばれる側だとすると、
• 関数はーだと

思います。呼ぶ側と呼ばれる側を扼す、ちょうど良い場所だとは思いますが、
大した事を代表している訳では有りません。

プログラミングの抽象でも有りません。すべきことは⚫︎か⚪︎に書いて有ります。

例えるなら、

例えるなら、交通ルールを例に取ると

• 特定の危険な場所で、
• 万人に分かりやすい（即、安全につながる）様にする為に、
• 出来る事を減らしている

のがそれだと思いますが、思いますに、交通ルールだけでは交通は成り立たず、交通の実際の肝は、

• それ以外の場所での普通の運転、給油（充電）、車のメンテ

なのです。

（ーで有る）関数も同様に、出来る事が減っている箇所なのです。
その様な「万人に分かりやすくする為に（即、安全につながる）、出来る事を減らしている」という使命を持った、それだけで表現としては能力を出し尽くしている状態の（ーで有る）関数に、さらに使命（数多の言語より格段に良いものとする）を与えるのは無理だったという事だと思います。

それを言うなら、

それを言うなら、prolog言語が論理型だ、と言うのも変です。

あれは、

• 継承のオーバーロード機能

と

• RDBのSELECT・JOIN機能

をフィーチャーしただけの、「万人に分かりやすくする為に、出来る事を減らしている」箇所（関数似の「パターン」）にさらに使命を無理に与えただけの言語だった様に思います。

AI に向いた言語と言われつつ、⚫︎ー⚪︎の「ーの部分だけ」を使った、append一発芸関数型似言語だった様に感じました。 *1（この話は後述）

結論

これからも「約束された失敗」でプログラミングが嫌いになる人は存在し続けることでしょう。

*1:prolog言語は私にとってのruby言語であり、railであり、TypeScriptであり、ReactJSでしたので、少し思い入れが有ります。

するべきだった事 ３

なんで「技術的負債」だったのか？

コストを掛けて（形而上的関数型なんてちゃちなものでは無く、金や地位や好ましく思えるパートナーやの提供で）、技術者としての背乗りに成功したとしましょう。

それだけのコストを掛けるとなると、乗っ取る先のシステムは、それなりに成功したエンタープライズ分野と言えるものだと思いますが、

• その様な、常時稼働を要求されるシステムは、常に、全ての部分で、因果を仕切り切る事が必須

だと思います。しかしコストを掛けて背乗りした人間にしてみれば、

• 毎回の調査分析（因果推論）など、負債では無いか

と見えても不思議では有りません。

また、技術的負債がなかなか消えない（永久に消えない）とするなら、それを毎回の調査分析（因果推論）の必要性が原因と出来るのでは無いでしょうか？

そしてそれはたとえgo言語で書いてあったとしても、kotlin言語で書いてあったとしても、もっと凄い（未知の）言語で書いてあったとしても、全く変わりは無いと思います。（形而上的関数型言語がこの世に顕現した場合は、別です。）

時期的考察

技術的負債という言葉が流行り出したのは、10年前より古いという事は無いと思います。もちろん、技術的な源流がそれより前から有ったなら、そうなのかも知れませんが、ジャーゴンとしては10年前程度で良い様に思います。

そして背乗りを企図して来る人間が、20年前程度からだったとするなら、背乗り後、そのシステムの完全掌握に10年掛かったとすると、辻褄が合います。

コストを掛けて乗っ取った人間にしてみれば、「こんなはずでは無かった」との感想を抱いても不思議では無く、
その思いが「負債」というネーミングになったとしてもうなずける所です。

本当に負債？

もしソフトウェアシステムが、外部の変化に対応すべきとするならば、その「負債」は永久に消えないでしょう。

それが本当に負債ならば、ですが。。。

特に現に動いているシステムだったとすると、その上での「こんなはずでは無かった」という感想は、負債では無く、調査分析（因果推論）の余地で有り、
進歩出来、外部の変化に対応出来る根拠となるべき余白で有る、と考える方が妥当に思えて、なりません。

結論

これからも「するべきだった事（調査分析（因果推論））」をしなかった事でプログラミングが嫌いになる人は存在し続けることでしょう。

するべきだった事 ２

なんで「背乗り」だったのか？

＞（時効とかも有り）金銭は望めなくとも、
＞そういう事を言って、やっている人間の価値を具体的に落とした人の名誉は
＞（没後でも構わない）剥奪すべきでは無いでしょうか？

とか書いた後、ふと思ったのです。

• 向こうが馬鹿でも無く、馬鹿のふりをしているのでも無い場合、
• 何で、そこまで初源的で初歩的なネタを”新しい”としたのか？

です。

要するに、

• 新しいものを広めたい

のでは全く無く、

• 自分が言いたい、背乗りをしてでも

だけだったのでは？　と言う問題意識からでした。

その頃の（今も？）状況

その頃の状況として、

• 専門学校の方が高度で、大学は理論に基づきと自称していたが劣っていた。

のは紛れもない事実だったと思います。

子供の指を切り落とす先生の話（倶胝竪指）も有る通り、大学ではそれをしないでだらだら勤め上げていても雇い止めになるしかない、逆に指を切り落としてでも、自分が言うのこそが大学の先生の本分だ、とも思います。

それを大学外に持ち出して来たのが実相だった、と言うのが見立てです。*1

それゆえの

それゆえの、

• 論文を、先生を、学会を、示してくれ

と言う言い分です。

そもそも逆なのです。

「学術的根拠が有る」と素人に言う時点で、腹を晒して参ったをしている状態だったはずで、正着で立ち回れば、こちらに有益な方向で決着が付いたはずなのです。

大体

大体、コボラーだって、それなりの「学術的根拠が有る」やり方をしていたはずです。
ただ、やっている当人（私も含む）らは、それを墨守しているだけで、説明してみろと言われても出来なかっただけなのでした。

コボラーが根拠にしている学術的根拠を除外しさえすれば（技報だから学術的文書では無いとか）、自分らの業績が増えるという助平心を出したのかも知れません。

立場の違いかも知れず、解決策は無いのかも知れませんが、ただやられるばかりと言うのも社会人として正しく無いのかも知れません。

結論

これからも「するべきだった事」をしなかった事でプログラミングが嫌いになる人は存在し続けることでしょう。

*1:別の所で、その話を書いたら（その時は大学だとは言っていませんでしたが。。。）、「絶対に有り得ない」と言い切られました。
初等中等教育では、そうなのかも知れませんが、高等教育では違うのかも知れません。（そうすると、高専の位置付けが不安定に思えても来ます。）

だから飛び級で子供が大学に入るとダメなのかも知れません。