嫌われプログラミングの代弁者

「何で頭ごなしに嫌う人間が居るのか」を色々考える

テストが書き辛い 2

逆もまた真

前に「JavaScriptが大変 2」で、

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

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

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

と書きましたが、

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

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

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

また、同じ記事で、

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

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

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

です。

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

 

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

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

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

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

 

結論

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

テストが書き辛い 1

どの様な話?

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

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

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

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

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

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

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

 

 

Lisp 1.5の事情

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

なのは世の常です。

 

 

結論

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

 

 

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

藁の混じった議論 7

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

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

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

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

例えるなら、

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

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

 

 

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

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

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

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

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

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

 

 

オブジェクト指向の使命

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

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

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

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

 

 

結論

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

藁の混じった議論 6

典型的な藁

私は、「サピエンス全史 上下合本版 文明の構造と人類の幸福 [電子書籍版] ユヴァル・ノア・ハラリ, 柴田裕之」で初めて見たのですが、

  • 貨幣経済なんて(古代であっても)サピエンスなら自然に発生する

そうです。

「依存性逆転の原則(dependency inversion principle)」もそれと同じ可能性は無いでしょうか?

誰も教えないのに自然に発生しないでしょうか?

自分でプログラムを作り、寝る間際に、

  • 抽象に依存すべきなんじゃね!

とか思い付き、翌日試したりしないでしょうか?

 

 

その場合の悪意

その場合、「依存性逆転の原則(dependency inversion principle)」と言う名前には、悪意が存在すると思います。

  • 自然に発生した(良い方向である)抽象への依存

に対し、

  • 逆転しないとならない

と言う誤解が生まれると言う事です。

逆転するとかえって悪くなると言う事です。

これは明らかに悪意が含まれていると思います。(私の実体験です。)

 

結論

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