より良く出来ない １

どの様な話？

「技術的負債」に似た、『「技術的」なんちゃら』を考えられないか？　と思い、

• 新訳　平和の経済的帰結　[電子書籍版] ジョンメイナードケインズ
  山形浩生 東洋経済新報社

という本を読みました。

そこでは、

• （特に主に戦勝国から）世界をより良くするために
• どうしたか

が書かれていて、

しかしながら、より良く出来る余地は多く無かった（金銀を使うと貨幣価値が持たなくなる為、との事）そうです。

「技術的平和の経済的帰結」

（勝手な想像で、根拠は無いのですが）ある自治体でシステムが他と異なるのは、

• 原因が有り
• 何かを良くしようとした結果である

とすると、

他の自治体でシステムが他と異なるのも、

• 原因が有り
• （別の）何かを良くしようとした結果である

と思います。

プロイセンと同様にDXでも、より良く出来る余地は、費用負担者が考えるより多く無かったならば、

• 統合は困難
• なぜなら統合とは、（少量のより良く出来る希少な余地を使い切る様な）原因の、実現の和になってしまう

からだと思います。

戦勝国の政治家の振る舞い

本から私が読み取ったのは、

• 原因（選挙区の要望）を兎に角隠したがる
• 訳が分からなくしてより多くを得ようとする
• 相手がフライコール化する

だと思います。ソフトウェア産業もフライコール化しつつ有る様に思いました。

原因を明らかにして、因果ダイアグラムを書く事が良いと思います。

結論

これからも「より良く出来ない」事でプログラミングが嫌いになる人は存在し続けることでしょう。   

テストが書き辛い ２

逆もまた真

前に「JavaScriptが大変　２」で、

・C言語は、実メモリという大データに、関数が副作用として読み書きをする
　手法ですし、  

・JavaScriptは、DOMという大データに、（無名の）関数が副作用として
　読み書きをする手法ですし、  

・SQL言語は、データベースという大データに、（部分部分が）関数的とも
　いえなくも無いSQL文が、副作用として読み書きをする手法ですが、

と書きましたが、

これら実用的な「関数型言語の代表」は全て、

• （それぞれの）大データに対する副作用上等

である事が特筆されます。はなから純粋関数を諦めているのです。

また、同じ記事で、

関数型プログラミングについて2つの思潮が有るとすると、上手くまとまります。  それは、  　

１．　何か素晴らしいとされ、しかしながら、いつまで経っても「手法固有の」事例集が作れない、形而上の“何か”を奉じて、他を排除しようとする思潮 　

２．　大データに絡みつく様に関数が実行され、大データの読み書き（副作用） を本質的な実行内容とし、同時に実行している関数間には直接的な通信手段が 無い、様な書き方のプログラミングを良しとする思潮

です。

と書きましたが、
前者は「より良い✖️より良い」を求めた結果、「＝　悪い」となったもので、
後者は、どちらかを諦めて、現実的な実際に動く解を得たものだと解釈出来ます。

テストでも同じ轍を踏んでいる可能性を疑うべきでは？

「テストが書き辛い」と言うのも、

• 何か素晴らしいとされ、しかしながら、いつまで経っても「手法固有の」事例集が作れない、形而上の“何か”を奉じて、他を排除しようとする思潮 　

が絡んでいる可能性があります。

結論

これからも「テストが書き辛い」事でプログラミングが嫌いになる人は存在し続けることでしょう。   

テストが書き辛い １

どの様な話？

往年のシャープ MZ-80C上で動いたLisp 1.5インタプリタでは、純粋関数しか使えませんでした。

それが何を意味するかと言うと、

• （関数内部で使用する）値を、
• （関数内部の処理順に）的確に、順番と種類（アトム or リスト）を違えず、
• （関数内部の）状態を全て予測し（実行時の実際の状態が現れる前に）、
• 実行前に全ての準備が完了し、実行時に過不足無く与える、

必要が有ると言う事です。

まるでユニットテストのプログラムの問題（手が止まる原因）そのものです。

これは現代的なモナド（別名：単なる自己関手の圏におけるモノイド対象）が入力でも同じ困難となると思います。

また、関数型プログラミングで言う"高階関数*1"を持ち出そうとも、その困難の僅かでも緩和されたりしないと思います。

Lisp 1.5の事情

Lisp 1.5は複雑な純粋関数を作ろうとすると、入れ子にするより有りませんでした。

後の「より実用的な」Lispで見られる、

• 複数の関数を順番に実行し、最後の関数の結果を、その結果とする
• 変数に値を書き込み、読み出しが出来る

の様な機能が（まだ）無かったからです。

すでに関数型のプログラム言語（Lisp 1.5）が有ったのに、後から手続き型風味Lisp言語が出来たのだと思います。（関数型の方が前！！！）

そして、これが核心的事実ですが、
（複雑なものを作ろうと関数を）入れ子にした途端、
純粋関数の為に必要な入力値の作り方が、比較も愚かなほど困難になりました。

テストを書き易くするには

テストを書き易くするには、

• 純粋関数の入れ子は良く無い
• 純粋関数にしたいなら、手続き型プログラミングにするべき
  （純粋関数＋関数型プログラミングと言うのは愚の骨頂）

です。手続き型プログラミングなら、

• 純粋関数の入れ子無しに、複雑なものが作れる

からです。Lisp言語の発展の過程を見てもこの流れが本筋だと思います。

• より良い✖️より良い　＝　悪い

なのは世の常です。

結論

これからも「テストが書き辛い」事でプログラミングが嫌いになる人は存在し続けることでしょう。   

*1:射を対象とせず、射を射のまま取り扱う以上、どんな明確な定義をしようとも、関数型プログラミングで言う"高階関数"は一階関数と強い意味で同値、としか思えない

藁の混じった議論 ７

言語論的転回から自然主義へ

「哲学史入門３　現象学・分析哲学から現代思想まで【電子書籍】[ 谷徹 ]」に、

• クワインは総合的真理と分析的真理の区別は不可能だと言った

と言う一節が有りました。科学的絶対的な真理が有るとしたのが「言語論的転回」の立場だと思いますが、

例えるなら、

• 星々の眷属として、特定の星の最後を看取る事は出来ても、
• 宇宙全体の眷属では無いので、宇宙全体の最後を看取る事は出来ない
  （宇宙の法則も絶対的真理では無いのでは無いか）

のでは無いか？と言う話になり、可能世界まで考えると自然主義に戻ってしまうと言う哲学史の1ページだったと思います。

関数型的転回から自然主義へ

関数型プログラミングを褒める人は、

• あり得ないほど悪い例を手続型プログラミング（あるいはCOBOLやPHPといった、一種偏りの有る、非難に足ると標的化された言語）に割り当て、
• 😀一般的な良い例😀を関数型プログラミングに割り当てて、

良さを言いますが、それは変です。欺瞞です。

仮想DOMと言う、ごく一部（星々に相当）の中では、

• DOMの子とその親と言う風に
• 位相空間が成り立ち、
• 関数型プログラミングでより良さを実現出来ている

のかも知れませんが、全体から見ると極一部の話だと思います。極一部分を以て、全体もそうだと言うのは、歴史的に良く有る誤謬です。

オブジェクト指向の使命

オブジェクト指向の使命は、

• 位相空間の無い所に、
• （たまたま上手くいく以上の出来では無い）それもどきを、無理やりでっち上げ、
• （たまたま上手くいく以上の出来では無い）良さを作り出そうとする

事で、それゆえ、
自然に位相空間の成立する仮想DOMの扱いの場面では、邪魔になって可笑しく有りません。

逆に、バックエンド側の処理では、オブジェクト指向が好まれますが、
継承は最小限（あるいは一才使うな）が良いとされるのは、その場面で自然に位相空間が成立しないので、良さを作り出そうとするのは不自然極まりないからかも知れません。

結論

これからも「藁の混じった議論」を周りの人にされる事でプログラミングが嫌いになる人は存在し続けることでしょう。