アカウント名:
パスワード:
有りもしない事を言ってお金を取るのは、学術的には合法だそうですが、道徳には反すると思います。自分らは一般人なのでなおさらです。（非合法になります） なんで別に悪意があった訳でもなさそうなのに、この様な厄介な事になったのか考えたのですが、☆上流側の設計書（自然言語で書いてある）は、『確率的表現』にしか ならない。自然言語である以上、絶対に『確率的表現』にしかならない！☆だから、「着目点は最後まで正しくても、『それが何だ』の結論が 最終的に書いてある事と真逆の結論になる」事も有り得るし、実際に 有った。ただし、『確率的表現』であるならば、それは妥当。☆自然言語で無理やり1/0の因果関係を書くと、周りから見て誤解を招く、 不当な強調として取られる表現になってしまう。☆なら自然言語でなければいいじゃんと思っても、そうして出来た表現は、 生煮えのプログラム言語もどきにしかならないのは歴史的事実。だからだと思います。 そこへ、「自然言語だけで良い」と教わったリーダーが、☆上流側の設計書こそ、全ての正しさが書いてある根源であると思い込んでしまったのは不幸でした。それは、一般人にとって合法とは言い難い考えです。＃無症候性キャリアから何かもらった様なものかも知れません。 要するに、１．上流側が『確率的表現』での設計書を書く。２．下流側が、それを1/0の因果関係として『正しさを議論出来る土台』 を作る。３．結合テスト以降をする人間が、正しさを決め、間違っていたら 差し戻す。でやっていたソフトウェア開発を、有りもしない仮定を元に、『より良く』した訳です。プログラムを書く前に正しさが解っているという仮定です。 自然言語はプログラム言語より融通が利きます、でもこの世の中に形がある以上、特典には失点が付き物だと思います。それこそが、☆自然言語である以上、絶対に『確率的表現』にしかならない！ 着目点は最後まで正しくても、結論が（最悪）真逆にも成り得る。という事だとしても、決しておかしくありません。
そうするとオブジェクト指向は中学校や高校では不要かも知れません。 中学校や高校の授業でプログラミング実習をやるとすると、 ・例題は最高に難しくても、図書館貸し出しとかその程度。・プログラムの出来に対して切実である需要家が居ない。・最高に理想的なリーダーである先生が居て、正しさに 対して完全に対処できる。異議を唱える関係者に対して 懲戒すら出来る。 となりますと、 ★実際に呼び出される個々のインターフェースであるメソッド を名とすると、姓に相当する、それらを分割統治するクラスを作り、 『確率的表現』たる設計書の不確定さを受容出来るようにする。（クラス中に「内部」表現を持たせ、不確定さはその中で吸収させる。） がこの場合は上項より不要。★設計書から「着目点」を抽出して、クラス分割統治をするが、 （書いていない「着目点」を後から付けられると激怒されるが、）少しでも書いてあれば、 調節が可能となるのがオブジェクト指向の利点であるのに対し、 この場合は「着目点」は全て書いてある上、小規模で後からの調節が不要で、 分割不要、つまり全体で1つでOK。 （「着目点」を書いてないと試験にならない上、大規模でも試験にならない為。） となり、姓に相当する部分は理解するための妨げにしかならなくなってもおかしくないからです。。小規模で、しかも正しさのオラクルが目の前にいて、不確定さを完全に０に出来るという例外的な場面なのですから。。。
そういえば、オラクル（O(1)のコストでどんな質問にも正解を返してくれる仮想的な存在）の存在を仮定すると、手法の階位が上がるとか何かの論文に書いて有った様な。。。 そんな手法をオラクルの居ない世界に持ち込んだら、鷺だと言われてもおかしくない！！！
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
根本的な原因は (スコア:1)
有りもしない事を言ってお金を取るのは、学術的には合法だそうですが、
道徳には反すると思います。自分らは一般人なのでなおさらです。
（非合法になります）
なんで別に悪意があった訳でもなさそうなのに、この様な厄介な事になった
のか考えたのですが、
☆上流側の設計書（自然言語で書いてある）は、『確率的表現』にしか
ならない。自然言語である以上、絶対に『確率的表現』にしかならない！
☆だから、「着目点は最後まで正しくても、『それが何だ』の結論が
最終的に書いてある事と真逆の結論になる」事も有り得るし、実際に
有った。ただし、『確率的表現』であるならば、それは妥当。
☆自然言語で無理やり1/0の因果関係を書くと、周りから見て誤解を招く、
不当な強調として取られる表現になってしまう。
☆なら自然言語でなければいいじゃんと思っても、そうして出来た表現は、
生煮えのプログラム言語もどきにしかならないのは歴史的事実。
だからだと思います。
そこへ、「自然言語だけで良い」と教わったリーダーが、
☆上流側の設計書こそ、全ての正しさが書いてある根源である
と思い込んでしまったのは不幸でした。
それは、一般人にとって合法とは言い難い考えです。
＃無症候性キャリアから何かもらった様なものかも知れません。
要するに、
１．上流側が『確率的表現』での設計書を書く。
２．下流側が、それを1/0の因果関係として『正しさを議論出来る土台』
を作る。
３．結合テスト以降をする人間が、正しさを決め、間違っていたら
差し戻す。
でやっていたソフトウェア開発を、有りもしない仮定を元に、
『より良く』した訳です。プログラムを書く前に正しさが解っている
という仮定です。
自然言語はプログラム言語より融通が利きます、でもこの世の中に形が
ある以上、特典には失点が付き物だと思います。
それこそが、
☆自然言語である以上、絶対に『確率的表現』にしかならない！
着目点は最後まで正しくても、結論が（最悪）真逆にも成り得る。
という事だとしても、決しておかしくありません。
そうするとオブジェクト指向は (スコア:1)
そうするとオブジェクト指向は中学校や高校では
不要かも知れません。
中学校や高校の授業でプログラミング実習をやるとすると、
・例題は最高に難しくても、図書館貸し出しとかその程度。
・プログラムの出来に対して切実である需要家が居ない。
・最高に理想的なリーダーである先生が居て、正しさに
対して完全に対処できる。異議を唱える関係者に対して
懲戒すら出来る。
となりますと、
★実際に呼び出される個々のインターフェースであるメソッド
を名とすると、姓に相当する、それらを分割統治するクラスを作り、
『確率的表現』たる設計書の不確定さを受容出来るようにする。
（クラス中に「内部」表現を持たせ、不確定さはその中で吸収させる。）
がこの場合は上項より不要。
★設計書から「着目点」を抽出して、クラス分割統治をするが、
（書いていない「着目点」を後から付けられると激怒されるが、）少しでも書いてあれば、
調節が可能となるのがオブジェクト指向の利点であるのに対し、
この場合は「着目点」は全て書いてある上、小規模で後からの調節が不要で、
分割不要、つまり全体で1つでOK。
（「着目点」を書いてないと試験にならない上、大規模でも試験にならない為。）
となり、姓に相当する部分は理解するための妨げにしかならなく
なってもおかしくないからです。。
小規模で、しかも正しさのオラクルが目の前にいて、不確定さを完全に
０に出来るという例外的な場面なのですから。。。
Re:そうするとオブジェクト指向は (スコア:1)
そういえば、オラクル（O(1)のコストでどんな質問にも正解を返してくれる
仮想的な存在）の存在を仮定すると、手法の階位が上がるとか何かの論文に
書いて有った様な。。。
そんな手法をオラクルの居ない世界に持ち込んだら、鷺だと言われても
おかしくない！！！