アカウント名:
パスワード:
たとえ内容がブラックボックスだったとしても、入力に対して想定される出力がきちんと返ってくるなら中身はどうでもいい。暗号化の初期配列作成にサイン値が必要になったとして、わざわざサイン値を計算して返さなくてもあらかじめテーブルを用意して返せばいい。
関数を具体化するということに異論は無いが、それは手続き化よりもむしろ必要な入出力を定義するということではないか。関数の仕組み上入出力は1対1であり、n対1でも1対nでもn対nでもない。複数のパラメータ(n)が存在するように見えても、それは1セットであり一つのパラメータである。
>入力に対して想定される出力がきちんと返ってくるなら中身はどうでもいい。 がはかばかしくない（実例が全く表面化しない。これは「誰かが隠し持っている」か「誰も持っていない（言っているだけ）」のどちらかになる）から、別案を言っているだけです。中身はどうでもいいというのは、言い過ぎだと思います。 ここで説明の為、"関数"という言い方を、・「関数表現」と・『本当の関数』（状態を持たない）に分けたいと思います。前者は後者を含みます。
自分は、入力と出力以外隠す「関数表現」というのは、プログラミング言語では、・同時性を表す以上の意味付けは無いと思います。ましてや、・入
言い過ぎではありません。その代表例がモックプログラミングです。指定された値に対して想定された値が返ってくればOK。では何故本番リリースでモックが使われないかというと、出力が不足しているからです。データベースだったりファイルだったり。あるいは入力パラメータの範囲が広くなるから。テスト用パラメータだけではなく本番パラメータやエラーパラメータ、あるいは想定外手順など。
実例が全く表面化しない。これは「誰かが隠し持っている」か「誰も持っていない（言っているだけ）」のどちらかになる
は、影響が表面化する場合は出力が正しくない、表面化しない場合は問題ないという立場です。例えば外部変数をキャプチャしているせいでメモリリークが起きている場合は、テスト内容にメモリ使用量などが入ってくるのではないでしょうか。
おそらく
中身を見ないといけない
ということ自体は共通認識だと思うのですが、私としてはそれは「関数を複数の関数に分割する」ということだと思ってます。
自分が、●関数（コボルではPROGRAM）は、 内部と外部に分けられ囲われた、プログラムの単位で、その内部とは、 ・特に同時に動く事が宿命づけられている訳でもない、いくつかの ロジックが同時に動く 性格のものだと、（ぼんやりと）思いついたのは、★COBOL74のプログラムで、★（例として）Aという製品とBという製品が有り、★製品の量と料金はすべてテーブルを検索すれば出る （『本当の関数』（状態を持たない）に当たる部分はここのみ）★「Aという主商品とBという副商品」を扱う（1単位の）処理と、 「Bという主商品」を扱う（1単位の）処理が有り、前者と後者のBという 商品の処理は同じはずで、ロジックは同じだが、書き方が微妙に違う★規定改正の度、2つのBという商品の処理をきちんと修正しないと いけないシステムの面倒を見ている時でした。 思ったのは2つです。①何でBを1つにしないんだというのと、②AとBは何の関係もない（独立して計算できる）が、PROGRAMは それを結び付けているというのでした。 ＃上記システム以降は、主商品、副商品などと分けず、全部単位商品と＃する様になりましたが、なにせCOBOL74で、PERFORM UNTIL 終わるまで＃すら無い、古いシステムだったので仕方有りません。 －－－－－－－－－－－－－－ ①の事を思うと、「関数を（PROGRAMを）複数の関数に分割する」というのは、全くその通りです。喉から手が出るほどその通りです。肯んじ得ないのは、★分割したからと言って、「たちの良い、テストしやすい断面が現れるか？」 また、（上記システム例の様に）その様なたちの良い断面は、すでに 開拓されていて、テーブルで定式化されていて、自動テストもなされていて、 いまから提案しても遅すぎるのでは無いか？（簒奪に過ぎないのでは無いか？）★分割し、たちの良い断面を見つけても、その外側には（それを呼ぶ側には） さらに濃縮されたたちの悪い部分が残るのでは無いか？ （「濃縮されたたちの悪い」とは、いままで自分の内部で有ったのが、 良い部分だけ関数に被覆され、いつその内部が変化するかを恐れつつ、 見えないものを呼ばないとならなくなる。 これは、いうなら、単純系だったのが複雑系になる≡悪い部分が濃縮 されることにほかなりません。）★たちの良い部分を見つける事で成果と出来る人に対して、たちの悪い部分を 押し付けられた人はどうなってしまうのか？です。 ②の事を思うと、人間がお金を出して、よかったと思われるシステムは、単なる「関数機能の呼び口の一覧」では無く、それらの呼び口を複合して、人間が一番大変だと思う大域的な探し物を代わりにやってくれる事だと思います。（主商品と副商品を結び付けて計算し、合算しetc.etc.をしてくれる）その「よかった」を実現すればするほど、★たちの悪い部分が現れる事になります。もちろん、単なる「関数機能の呼び口の一覧」のみを提供して、それから先は人間の手動や、ロボットに任せるのがベストだという考えも有るでしょう。けれど、それも、★たちの悪い部分を濃縮して、他人に押し付ける行為だと思います。 自分の懸念は一貫してこれ（濃縮された悪さを押し付けられないか）です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
手続きはむしろどうでもいい (スコア:0)
たとえ内容がブラックボックスだったとしても、
入力に対して想定される出力がきちんと返ってくるなら中身はどうでもいい。
暗号化の初期配列作成にサイン値が必要になったとして、
わざわざサイン値を計算して返さなくてもあらかじめテーブルを用意して返せばいい。
関数を具体化するということに異論は無いが、
それは手続き化よりもむしろ必要な入出力を定義するということではないか。
関数の仕組み上入出力は1対1であり、n対1でも1対nでもn対nでもない。
複数のパラメータ(n)が存在するように見えても、それは1セットであり一つのパラメータである。
Re: (スコア:1)
>入力に対して想定される出力がきちんと返ってくるなら中身はどうでもいい。
がはかばかしくない（実例が全く表面化しない。これは「誰かが隠し持っている」
か「誰も持っていない（言っているだけ）」のどちらかになる）から、
別案を言っているだけです。
中身はどうでもいいというのは、言い過ぎだと思います。
ここで説明の為、"関数"という言い方を、
・「関数表現」
と
・『本当の関数』（状態を持たない）
に分けたいと思います。
前者は後者を含みます。
自分は、
入力と出力以外隠す「関数表現」というのは、プログラミング言語では、
・同時性を表す
以上の意味付けは無いと思います。
ましてや、
・入
Re:手続きはむしろどうでもいい (スコア:0)
言い過ぎではありません。その代表例がモックプログラミングです。
指定された値に対して想定された値が返ってくればOK。
では何故本番リリースでモックが使われないかというと、出力が不足しているからです。
データベースだったりファイルだったり。
あるいは入力パラメータの範囲が広くなるから。
テスト用パラメータだけではなく本番パラメータやエラーパラメータ、
あるいは想定外手順など。
実例が全く表面化しない。これは「誰かが隠し持っている」
か「誰も持っていない（言っているだけ）」のどちらかになる
は、影響が表面化する場合は出力が正しくない、表面化しない場合は問題ないという立場です。
例えば外部変数をキャプチャしているせいでメモリリークが起きている場合は、
テスト内容にメモリ使用量などが入ってくるのではないでしょうか。
おそらく
中身を見ないといけない
ということ自体は共通認識だと思うのですが、
私としてはそれは「関数を複数の関数に分割する」ということだと思ってます。
Re:手続きはむしろどうでもいい (スコア:1)
自分が、
●関数（コボルではPROGRAM）は、
内部と外部に分けられ囲われた、プログラムの単位で、その内部とは、
・特に同時に動く事が宿命づけられている訳でもない、いくつかの
ロジックが同時に動く
性格のものだ
と、（ぼんやりと）思いついたのは、
★COBOL74のプログラムで、
★（例として）Aという製品とBという製品が有り、
★製品の量と料金はすべてテーブルを検索すれば出る
（『本当の関数』（状態を持たない）に当たる部分はここのみ）
★「Aという主商品とBという副商品」を扱う（1単位の）処理と、
「Bという主商品」を扱う（1単位の）処理が有り、前者と後者のBという
商品の処理は同じはずで、ロジックは同じだが、書き方が微妙に違う
★規定改正の度、2つのBという商品の処理をきちんと修正しないと
いけない
システムの面倒を見ている時でした。
思ったのは2つです。
①何でBを1つにしないんだ
というのと、
②AとBは何の関係もない（独立して計算できる）が、PROGRAMは
それを結び付けている
というのでした。
＃上記システム以降は、主商品、副商品などと分けず、全部単位商品と
＃する様になりましたが、なにせCOBOL74で、PERFORM UNTIL 終わるまで
＃すら無い、古いシステムだったので仕方有りません。
－－－－－－－－－－－－－－
①の事を思うと、「関数を（PROGRAMを）複数の関数に分割する」というのは、
全くその通りです。喉から手が出るほどその通りです。
肯んじ得ないのは、
★分割したからと言って、「たちの良い、テストしやすい断面が現れるか？」
また、（上記システム例の様に）その様なたちの良い断面は、すでに
開拓されていて、テーブルで定式化されていて、自動テストもなされていて、
いまから提案しても遅すぎるのでは無いか？（簒奪に過ぎないのでは無いか？）
★分割し、たちの良い断面を見つけても、その外側には（それを呼ぶ側には）
さらに濃縮されたたちの悪い部分が残るのでは無いか？
（「濃縮されたたちの悪い」とは、いままで自分の内部で有ったのが、
良い部分だけ関数に被覆され、いつその内部が変化するかを恐れつつ、
見えないものを呼ばないとならなくなる。
これは、いうなら、単純系だったのが複雑系になる≡悪い部分が濃縮
されることにほかなりません。）
★たちの良い部分を見つける事で成果と出来る人に対して、たちの悪い部分を
押し付けられた人はどうなってしまうのか？
です。
②の事を思うと、人間がお金を出して、よかったと思われるシステムは、
単なる「関数機能の呼び口の一覧」では無く、
それらの呼び口を複合して、人間が一番大変だと思う大域的な探し物を
代わりにやってくれる事だと思います。
（主商品と副商品を結び付けて計算し、合算しetc.etc.をしてくれる）
その「よかった」を実現すればするほど、
★たちの悪い部分が現れる
事になります。
もちろん、単なる「関数機能の呼び口の一覧」のみを提供して、それから
先は人間の手動や、ロボットに任せるのがベストだという考えも有るでしょう。
けれど、
それも、
★たちの悪い部分を濃縮して、他人に押し付ける
行為だと思います。
自分の懸念は一貫してこれ（濃縮された悪さを押し付けられないか）です。