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

dotkuwaの日記: 関数ならすべて「タチが良い」訳でもなさそう 10

日記 by dotkuwa

タチの良い関数の条件に、
・引数のみから結果が得られる。他の通信は無い。
と書きましたが、
もし、
引数に、
・入力パラメタ(少量)
・数100万対の、keyとvalueの組
でも、タチの良い関数なのでしょうか?
 
これなら、DBの様な横からの「他の通信」は無いですが、
一例として、
・keyが一意で無い(同じkeyの組が複数ある)
場合のテストを、関数を実行するたびにしないと
いけないとするならば、
かなりノロくなると思われます。
 
と言うより、タチの悪さ(一例としての、
引数のみからで無い「他の通信」)は、テスト済みの
データの再利用から生じている可能性もあります。

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

    重要なのは安全性なので。つまり事前に用意すべきリソースの量が分かること。
    これには時間的リソースも含まれる。

    そして(ここからは速度を除外)用意したリソースの量によってどの程度速度が上がるのか、
    要求にある制限時間から入力パラメータや事前に用意されるテーブルにどのような制限を加えるかなどが導き出される。

    それから近年の関数型プログラミングはマルチスレッドなどとペアで語られることが多いので、
    並列化しやすいようにKeyValuePairを事前加工するなんてことも行われるかもしれない。

    • >KeyValuePairを事前加工する
      とおっしゃいますが、その場合、事前加工するプログラミングは
      何になるのでしょうか?
      少なくとも、
      (タチの良い)関数型プログラミングにはならないと思います。
       
      さらに、外部で事前加工することに依存している関数型プログラミング
      は本当に(タチの良い)関数型プログラミングたり得るでしょうか?
      引数のみに依存している訳では無い、他のチャネルの情報(外部の善意)も
      必要としているとしたら、
      ユニットテストも非常にし辛くなると思います。
       
      さらに、関数型プログラミングが称揚されている場面で、
      だれが、外部の事前加工を担任するのでしょうか?
      褒められもしない、貶されるだけの機能です。関数型では無いから
      です。

      運用チームをDevOpsとか言っておだててやらせましょうか?
      無理です、
      運用チームというのはステートレスの権化で、その様なタチの悪い、
      手離れしない機能に手は出しません。
      では、年寄りにやらせましょうか?
      無理です。
      そんな年寄りは全員引退しました。

      兎に角、
      他(関数の外側)の善意に依存した関数型プログラミングで、
      その関数の外側が関数型プログラミングで無い場合、
      全体として、関数型プログラミングでは無いとするべきでは
      無いでしょう?
       
      もちろん、関数型の出たての頃は、
      ・ユニバーサルで、テスト不要な、関数の外側を担任するエンジンが出来る
      ことを当てにしていたのかも知れません。
      しかしそれは、
      タチの悪いプログラムを軽く見過ぎています。
      タチの悪いとは、
      ・すこし何かが変わるだけで、外側も広範囲かつ深刻に変化する
      ・テストもし難い、ユニットテストなど論外
      となるでしょう。
      間違いなくそうなります。
       
      ・ユニバーサルでテスト不要な、関数の外側エンジンが出来る
      が、(この宇宙では)絶対に作る事が出来ない、
      ゼットンの火球でこの宇宙を終わらせて、違う宇宙にでもしない
      かぎり、構成不能だと思います。
      (もし、その様なものが構成可能なら、なぜ、世に問わないのでしょうか!!)
       
      自分ももちろん、絶対的な速度はあまり気にしません。因果論的に
      関数型プログラミングの説明の仕方はおかしいと思っているだけです。
      不経済を外部に移転しいるだけです。

      親コメント
      • by Anonymous Coward

        前の日記でも思ったけれど、妥協というものを知らないのかな?
        普通にシステムを組む人は非効率になりすぎる手前で妥協するんですよ。
        概念の原則について話したいなら現実の世界は無視してください。職場の力関係とかね。

        さらに、外部で事前加工することに依存している関数型プログラミング
        は本当に(タチの良い)関数型プログラミングたり得るでしょうか?
        引数のみに依存している訳では無い、他のチャネルの情報(外部の善意)も
        必要としているとしたら、
        ユニットテストも非常にし辛くなると思います。

        パラメータに制限掛けるだけです。事前にキーがソートされていることとか重複がある場合は値を配列として保存しておくこととか。
        外部の善意ではありません。外部への制約です。
        データの格納方式や量と検索のアルゴリズムから最頻の形式で効率の良いものというのは決まるでしょう?

        さらに、関数型プログラミングが称揚されている場面で、
        だれが、外部の事前加工を担任するのでしょうか?
        褒められもしない、貶されるだけの機能です。関数型では無いから
        です。
        運用チームをDevOpsとか言っておだててやらせましょうか?
        無理です、
        運用チームというのはステートレスの権化で、その様なタチの悪い、
        手離れしない機能に手は出しません。
        では、年寄りにやらせましょうか?
        無理です。
        そんな年寄りは全員引退しました。

        上記の通り、概念について話したいなら現実は無視してください。
        現実に付いてなら、プログラマが関数型プログラミングの原則導入を諦めて妥協するでしょう。

        • >上記の通り、普通の人は概念を理解すれば使いやすいところから徐々に導入して使いにくくなる前に妥協する
          問題は「関数型」というタイトルです。
           
          プログラムを妥協すると単なる「手続き型」プログラミングに堕ちます。少しでも妥協すると
          なります。
          それも妥協して妥協されたプログラミングも(手続き型よりよい、使いやすい、分かり易いと
          見做されている)「関数型」と言ったら、全くの優良誤認になります。
           
          なんでこんなに妥協できないのでしょうか?
          それは、
          ・現実の世界では何かタイトルをつける場合、あえて一歩引いた名前にする事により、
           混乱を避けている
          はずなのに、概念の世界の流儀で、ど真ん中のタイトルをつけたからです。
          「関数型」なんてど真ん中でど直球で大名跡な名前は遠慮するのが普通です。現実の世界の
          プログラミングではそうしているはずで、そうしないと必ず困った事になります。
           
          概念の世界では良いが、現実の世界では困る名付けをしたのが、この問題の根本原因です。
          以前、/.で別の記事で、「open」ソースの件で揉めましたが、やはりど真ん中の名付けを
          現実の議論でしたのが根本原因でしょう。
           
          >テストを簡単にするために関数型の良いところ(テストしやすくなるところ)を導入したので
          >外側のエンジン(やミドルウェア)が先に存在しています。
          それらエンジンは関数型では無いと思います。なので、総体的に見ると関数型では無く、
          単なる手続き型プログラムだと思います。
          ほんの穂先のみの関数で関数型というのは、全くの優良誤認です。
           
          >>さらに、関数型プログラミングが称揚されている場面で、
          >>だれが、外部の事前加工を担任するのでしょうか?
          >>褒められもしない、貶されるだけの機能です。関数型では無いから
          >>です。
          だれが担任するのでしょうか? 関数型がほめられるプロジェクトで、関数型で無い、
          ハウスキーピング的な作業は、蔑まれ、お前のせいで関数型が成就しないと非難される
          のはファクトです(n=1ですが、厳然たる事実です。)
          もう一度伺いますが、だれが担任するのでしょうか? これは現実の問題です。
          だれが担任するのでしょうか?

          親コメント
          • 結局、
            関数型プログラミングなんて言うから悪いので、
            どのプログラミング言語にも適用可能な、一連の
            パターン(参照透過性とか)とすれば良いのでは?
             
            そうすると、プログラム開発における、権限争い
            (例えば、今まで通り生DOMを更新出来るか?
            それとも仮想DOMのみ更新可能か?)の場面(現実問題)
            で、関数型プログラミング(現実には妥協されていて、
            他のプログラミングと変わりない)を持ち出すのは不適切
            となります。
            よくプログラム開発における、権限争いで持ち出される
            事を見受けますが、不当です。

            親コメント
  • by Anonymous Coward on 2020年09月30日 14時15分 (#3897824)

    工学という目でみればソフトウェアの改造・保守のし易さといった「管理性」、速度や記憶域の使用量といった「性能」、さらに設計製造に要する「工数」は互いに影響し合いますが、それぞれ別の次元のものです。

    悪い設計より良い設計の方が「管理性」も「性能」も向上し「工数」は減ってくれますが、書いておられる例のように、ある処からは相反するようになります。美しくても遅くてメモリも沢山必要になったりします。

    工学ではこういうトレードオフはよくあることです。何処かで折衷案を選ぶ必要があります。

    十数年来の流行は、管理には高度な言語コンパイラと高度な統合開発環境的なものを活用することで人間の負担を減らして、アルゴリズム的なものを関数に分割して管理するだけでなく、データも必要な個所に分割して他所からは勝手に触れない形で管理するという形態=オブジェクト指向です。この例だと keyとvalueの表とそれを操作する関数一式をまとめたオブジェクトという単位で管理することになります。

    ただし、特定のデータと必要なメソッドといういった解り易い例でない場合、最初のオブジェクト群の設計にはかなりの技量あるいは試行錯誤といった工数が必要になることもあります。また開発環境やライブラリ群といったものが貧弱で機械的な支援が得られないと返って苦しくなります。

    学生時代の先生や新人の頃の上司にたまたま詳しい人が居て専攻でも専業でもない私にぽつりぽつりと教えて貰っただけで、ソフトウェア工学にどういう有名な教科書があるのかも実は知らないのですが・・・。

    • お隣の米に対する、自分の米の、
      #3898057をご覧くださいませ。

      親コメント
      • by Anonymous Coward

        論点を読み間違えていました。
        関数のタチの良し悪しの問題じゃないですね、全体の設計の問題でしょう、次のどれを選ぶか。

        1.関数は表を受け入れる際に、毎回、自分で表に問題が無いかをチェックしてから、処理する。

        2.関数は何かの処理の結果として表を返す時、毎回必ず自分で表に問題が無いかチェックしてから、返す。

        3.複数を関数を順に呼んでいる処理の部分が、必要に応じて適切なチェック関数を呼んでから、自分が呼び出したい関数に問題の無い表を渡す。

        機能分割の刃を何処に入れるかどう切り分けるかの問題ではないでしょうか?

        • 4.という画期的な選択肢がある。それが証拠に、
          表が全て空の場合、テストをしなくて良い。
          (その上で、表が空で無い場合も、テストをしなくて良さそうだと
           一般人に誤解させる。)
           
          という主張に対する言挙げが自分の論点です。
          口はばったい言い方をするなら、
          「関数型プログラミングは国益に反する、将来の日本に対する
           思想的な侵略だ。」とすら思えます。
           
          まともな手法はそれっこそ沢山あるだろう事は理解している
          つもりです。しかし、今回の論点はそこでは有りません。
          (もしその言挙げをしたいのでしたら、コメントで無く、
           ご自分で第一声を発するべきだと思います。)

          親コメント
          • by Anonymous Coward

            大きな問題は「画期的な選択肢」を使うと「表が全て空の場合、テストをしなくて良い。」と主張する人でしょうね。

            引数として「全て空の表」の表を渡されたら関数がどう動くかは、関数型であってもテストして置く必要があります。
            「全て空の表」の場合、関数を呼ばないという上位の制御が含まれているなら、呼ばれる関数のテストは不要ですが、本当に関数を呼ばないのか上位の制御を「全て空の表」でテストをする必要があります。さらに言うと、机上理論だと大丈夫でも、実装すると大丈夫じゃないことは多々あるのでテストを行います。それがテストというものです。

            慎重になり過ぎて新しい技術を取り入れないのも困りますが、新しい技術を過信するのも問題です。経験不足を逆手にとって敬遠していた新技術を導入して逆転する。そういう発想自体は良いのですが、上手過ぎる話に騙されて、しくじる人が(年齢に関係なく)なんだか増えているように感じます。

typodupeerror

犯人はmoriwaka -- Anonymous Coward

読み込み中...