パスワードを忘れた? アカウント作成
13561821 journal
日記

dotkuwaの日記: 制御を分散させるのは無理では 6

日記 by dotkuwa

関数型プログラミングは、理念はともかくとしても、
・関数(比較的実行順序の組み換えに余裕が有る)を凝集させ、
 制御(比較的実行順序の組み換えに余裕が無い)を脇扱いで
 関数の都合でバラバラに置く。
という風に見えます。
 
オブジェクト指向プログラミングでは、逆になります。
 
もし、制御を分散させる(モジュール化してテストしやすく
したり、プラガブルにしたりする)のが本質的に不可能なら
それをするのが必要になる関数型プログラミングは、
・単にオブジェクト指向プログラミングの逆であるという
 だけで本質的に不可能になる
可能性が有ります。
 
制御を分散させることで、処理時間が万万倍になったり、
脆弱性の根源的な理由になったりすることが有るのも、
「実行順序の組み換えに余裕が無い」ためだと思います。
 
関数が見通しの良い、性質の良いものなのは事実です。
ですが、なのでそれを軸としたらさらに良くなるだろうと
いうのは合成の誤謬だと思います。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2018年03月28日 9時34分 (#3383707)

    つまり

    もし、制御を分散させる(モジュール化してテストしやすく
    したり、プラガブルにしたりする)のが本質的に不可能

    になったら、それは妥協した関数型プログラミングなだけです。
    例えて言えば、オブジェクト指向プログラミングなのに静的・グローバル型の値を使いまくるとか。

    関数型プログラミングでは入力と出力のみが可変なので、
    制御を行う部分はユーザーが担ったりフレームワークで吸収したりするべきなのではないでしょうか。

    • コメント有難うございます。
       
      少し言い方が弱かったでした。(というより未整理状態?)
       
      例を挙げますと、(以下変数は全て十進18桁、内小数5桁)
      ・aとbを掛けcで割り、小数以下3桁で四捨五入(5は無条件に切り上げ)し、
       dに転記する。
      ・dをfで割り、小数点以下切り捨てし、gに転記する。
      の場合、「aとbとcが入力でgが出力の関数だ」というと、プログラマーの
      人は納得する(関数で良いと思う)けれど、業務知識を授けてくれる業務の
      人はいい顔しないと思います。(2つは順番の組み換えに余裕が全くないので
      そこの所を軽く見られると嫌がる。)
       
      関数⇔制御で対比すると、
      ・一皮むくと関数内に制御が有る
      という状況が必ず出来ます。
      #ただしこの場合は制御が分散していないので問題無いです。
       
      ちょっと未整理でした。

      親コメント
      • 少し考えてみましたが、
         
        ★制御とは、切り捨てでは無いか?!
        と思いました。
        制御には、コード(値が2値で無いフラグ)を良く使います。
        1:男、2:女、3:不明
        とかです。
        これは多様な性を切り捨て、処理を簡便に安定的にする
        働きが有ります。
        もし次世代の性別コードが策定され、3つより多い種類となった
        場合でも、いざ策定された後には、「自分だけの性なので、
        特別な性別コードを振るべきだ」と言っても、無理でしょう。
        制御とは、コードとは切り捨てだからです。
         
        制御が切り捨てだとすると、
        ・早い、正確
        ・コードを得るタイミング(コードを算定できるだけの豊富な
         情報が捨てられず残っているタイミング)以降は、
         再度コードを得る事が出来ない。
         すなわち、処理に(かなり)強い順序の強制が有る。
        ・コードを算定できるだけの豊富な情報を捨てずに残しておくと
         しても、元データから常に立ち戻って処理をするのは遅くなる。
         1分が100分になり、1時間が100時間になるに違いない。
        となるでしょう。
         
        切り捨てを一切しない、逆関数が成り立つシステムは遅いです。
        データベースにインデックスを作る事も出来ないでしょうし、
        もっと粗い分類も、コード化しないと毎回全データをなめまくり
        になるからです。
         
        早く不自由な「制御」こそ凝集されるべきで、条件の緩い「関数」
        は、便利なフットプリントを「制御」に譲るのが良いと思います。
        #電車内で、人の迷惑を一切斟酌せず、足の踏み場をわがままに
        #確保する女性の様ですが、関連が有るのかは不明です。

        親コメント
      • by Anonymous Coward

        入力パラメータの指定順に意味があり組み替えできないと理解しているからこそプログラマーは納得してくれますし、
        一方でパラメータの指定順に意味が無い世界で過ごしている業務の人は納得してくれないのだと思います。
        つまり軽く見ているのは業務の人側。
        入力パラメータが並列に見えるabcなのがいけないのかもしれませんが。
        もしかしたら(ここにはありませんが)関数名が汎用に見えるのがいけないのかもしれません。
        例えば同じような計算を行っているとしても、違う業務なら違う関数名をつけるはずです。
        そしてその中で同じ汎用関数を呼び出すでしょう。

    • >制御を行う部分はユーザーが担ったりフレームワークで吸収したりするべきなのではないでしょうか。

      そういうフレームワークを作れなかった、その位置こそチューリング完全が何の制限も無く
      完全に必要だったから、関数型プログラミングは伸びなかったのでしょうね。
      まだTDDなら「死ぬほど大変だ」という事が分かる位、実例は有りますが、フレームワークは
      そこまで至っていない(永久に至らない?)と思います。

      そもそも歴史的にも、関数が元祖で、それに環境を加えたラムダ計算とかに進み、さらに、
      名前を(姓と名の様に)2つにしたオブジェクト指向に進んだという経緯なので、
      関数型とは新しくないし、(その後の歴史で付け加えられたものが)足りない、空想に
      過ぎない様に思います。

      親コメント
typodupeerror

あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall

読み込み中...