アカウント名:
パスワード:
たとえ内容がブラックボックスだったとしても、入力に対して想定される出力がきちんと返ってくるなら中身はどうでもいい。暗号化の初期配列作成にサイン値が必要になったとして、わざわざサイン値を計算して返さなくてもあらかじめテーブルを用意して返せばいい。
関数を具体化するということに異論は無いが、それは手続き化よりもむしろ必要な入出力を定義するということではないか。関数の仕組み上入出力は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)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
手続きはむしろどうでもいい (スコア: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.をしてくれる）
その「よかった」を実現すればするほど、
★たちの悪い部分が現れる
事になります。
もちろん、単なる「関数機能の呼び口の一覧」のみを提供して、それから
先は人間の手動や、ロボットに任せるのがベストだという考えも有るでしょう。
けれど、
それも、
★たちの悪い部分を濃縮して、他人に押し付ける
行為だと思います。
自分の懸念は一貫してこれ（濃縮された悪さを押し付けられないか）です。