アカウント名:
パスワード:
完成時点で土台が崩れない建築物を建てるのは技術的に可能で、実際に出来る職人も多数いる。
ところが、バグがないソフトを開発するのは現在困難でそれをやってくれる人が殆どいない。だから現在はバグ修正込みでの仕事を出さないと誰もやってくれない。
その違い。今後どうなるのかはしらん・
たとえばせいぜい計測値を記録するソフトと、複数の計測値をもとに機器を制御するソフトじゃ複雑さが違いすぎるわけで、その辺の区別もせずに「バグがないソフトを開発するのは現在困難でそれをやってくれる人が殆どいない。」などと言い切るのは乱暴に過ぎませんか？
建築物でいうなら、乗用車を入れるガレージ建てるのと、タワーマンション建てるのを同じ技術と見なしてるようなものです。そして多くの職人が関わっているタワーマンションにしたところで、コア抜きなんてひどいパッチあてが行われたり、鉄筋切って販売中止になっていたりするわけです。
要は契約範囲内なら粛々とやるし、範囲外なら別契約という当たり前の話です。
ソフトウェアの規模に依らず。最適化が掛かるコードからバグを取り除くことは不可能、オプティマイザ自体に確実にバグがあるので、アーキテクチャ毎の最適化なんて最悪、当然JITコンパイルなぞ地獄
その「バグを取り除くことは不可能」なシロモノで現実に様々な活動が営まれていることについてどうお考えなのでしょう。完璧なソフトウェアがありえないのであれば、それは誰にも必要とされていない存在でしかないのですから、ここでの議論においては全く無視して良いと言わざるを得ません。
大きなシステムは必ずどこかが故障している。それでも現実に様々な活動が止まることなく営まれている。大型旅客機がなんの故障もなく飛んでいることなどないのと同程度の問題としか。
大型旅客機が故障することがあっても飛ぶのは、故障に対処するための点検・整備方法などが確立しているからですね。そのためには、どんな故障がありうるかということが分かっている必要があります。それが分かっていれば、#2545954が言うように、現実的に実現可能な、ありえない故障の範囲を明文化して契約に盛り込むことができます。そしてそれに基づき点検・整備計画を立てることができます。それでも、ありえない故障が起こることがありますが（実際、飛行機の故障で墜落して死者が出るような事故は現実に起こっているわけですから）、そうなれば契約違反として処理されるでしょう。
ソフトウェアの場合、どんなバグがありうるかということが分かっていますか？そもそも、分かろうとする努力がされていますか？
バグを出さないようにソフトウェア工学は進んでいるんではないですか？いまさらスタックポインタ戻し忘れてとんでもないところにリターンしたなんてバグを気にする人はいないでしょう？メモリの開放忘れや未初期化、開放済みポインタの参照を気にする必要もなくなった。
ああ、ところであなたはご自身がどんなミスを犯しうるかわかってますか？ソフトウェアは物理表現ではなく思想表現なので、間違ったものを作ったら物理法則が勝手に壊してくれるなんて甘いことはないんですよ。自己がどのような誤謬を持つかを検出できる自己が存在したとして、検出された誤謬それ自体が誤謬でないという証明は可能でしょうかね？
> ソフトウェアの場合、どんなバグがありうるかということが分かっていますか？
なぜわからないと思いましたか？
> そもそも、分かろうとする努力がされていますか？
なぜ努力していないと思いましたか？
事前に予見できなかった不具合と、予見しうる不具合と、予見されるべき不具合はレベルが異なると考えます。
Windows のアプリが不具合で異常終了したとしても、データが失われることもなく再起動で作業を続行できたなら、被害は極小です。みっともないですが、実用上は許容範囲とみなせます。
許せないとおっしゃるのであれば、その完璧さにたいする対価と時間を要求されることになると思いますが、その費用やユーザとしての機会損失を考えれば妥協があってもよいのではないでしょうか？
> いまさらスタックポインタ戻し忘れてとんでもないところにリターンしたなんてバグを気にする人はいないでしょう？> メモリの開放忘れや未初期化、開放済みポインタの参照を気にする必要もなくなった。
ありがとうございます。そういう具体的な話を聞きたかったのです。
> ソフトウェアは物理表現ではなく思想表現なので、間違ったものを作ったら物理法則が勝手に壊してくれるなんて甘いことはないんですよ。
いや、間違った物を作って納品して、客の生命財産を巻き込んで壊れたら大変なことだと思いますけど。たとえば建築物がいきなり倒壊するとか
物理表現に誤りがあったら自動的に検出してくれるじゃないですか。物理法則の枠がはっきりしてるから仮想的に建築して強度を確認することもできる。自動的な誤謬検出も事前の検証もソフトウェアが持ち得ない特徴です。物理的な構造は劣化する箇所がある前提ですから100万回に1回といった定量的見積もりが可能でしょう。ソフトウェアはどこか劣化しますか。
> ソフトウェア業界の人はなぜそういう極端な話に走るんですかね。> たとえば100万回に1回の確率で起こる事故は事実上起こらないと考えていいとか、そういう考え方はできないんですかね？
えーと、ソフトウェア業界で100万回毎は頻繁に分類されます
あなたの言いたい事もわかるがその数字は微妙
>>みっともないですが、実用上は許容範囲とみなせます。
なんて甘えたこと言ってるからいつまでたっても前に進まない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
できないから (スコア:0)
完成時点で土台が崩れない建築物を建てるのは技術的に可能で、
実際に出来る職人も多数いる。
ところが、バグがないソフトを開発するのは現在困難で
それをやってくれる人が殆どいない。だから現在はバグ修正込みでの
仕事を出さないと誰もやってくれない。
その違い。今後どうなるのかはしらん・
できるとかできないとか (スコア:0)
たとえばせいぜい計測値を記録するソフトと、複数の計測値をもとに機器を制御するソフトじゃ複雑さが違いすぎるわけで、その辺の区別もせずに「バグがないソフトを開発するのは現在困難でそれをやってくれる人が殆どいない。」などと言い切るのは乱暴に過ぎませんか？
建築物でいうなら、乗用車を入れるガレージ建てるのと、タワーマンション建てるのを同じ技術と見なしてるようなものです。
そして多くの職人が関わっているタワーマンションにしたところで、コア抜きなんてひどいパッチあてが行われたり、鉄筋切って販売中止になっていたりするわけです。
要は契約範囲内なら粛々とやるし、範囲外なら別契約という当たり前の話です。
Re: (スコア:0)
ソフトウェアの規模に依らず。最適化が掛かるコードからバグを取り除くことは不可能、
オプティマイザ自体に確実にバグがあるので、
アーキテクチャ毎の最適化なんて最悪、当然JITコンパイルなぞ地獄
Re:できるとかできないとか (スコア:0)
その「バグを取り除くことは不可能」なシロモノで現実に様々な活動が営まれていることについてどうお考えなのでしょう。
完璧なソフトウェアがありえないのであれば、それは誰にも必要とされていない存在でしかないのですから、
ここでの議論においては全く無視して良いと言わざるを得ません。
Re: (スコア:0)
大きなシステムは必ずどこかが故障している。それでも現実に様々な活動が止まることなく営まれている。
大型旅客機がなんの故障もなく飛んでいることなどないのと同程度の問題としか。
Re: (スコア:0)
大型旅客機が故障することがあっても飛ぶのは、故障に対処するための点検・整備方法などが確立しているからですね。
そのためには、どんな故障がありうるかということが分かっている必要があります。
それが分かっていれば、#2545954が言うように、現実的に実現可能な、ありえない故障の範囲を
明文化して契約に盛り込むことができます。そしてそれに基づき点検・整備計画を立てることができます。
それでも、ありえない故障が起こることがありますが（実際、飛行機の故障で墜落して死者が出るような
事故は現実に起こっているわけですから）、そうなれば契約違反として処理されるでしょう。
ソフトウェアの場合、どんなバグがありうるかということが分かっていますか？
そもそも、分かろうとする努力がされていますか？
Re: (スコア:0)
バグを出さないようにソフトウェア工学は進んでいるんではないですか？
いまさらスタックポインタ戻し忘れてとんでもないところにリターンしたなんてバグを気にする人はいないでしょう？
メモリの開放忘れや未初期化、開放済みポインタの参照を気にする必要もなくなった。
ああ、ところであなたはご自身がどんなミスを犯しうるかわかってますか？
ソフトウェアは物理表現ではなく思想表現なので、間違ったものを作ったら物理法則が勝手に壊してくれるなんて甘いことはないんですよ。
自己がどのような誤謬を持つかを検出できる自己が存在したとして、検出された誤謬それ自体が誤謬でないという証明は可能でしょうかね？
Re: (スコア:0)
> ソフトウェアの場合、どんなバグがありうるかということが分かっていますか？
なぜわからないと思いましたか？
> そもそも、分かろうとする努力がされていますか？
なぜ努力していないと思いましたか？
事前に予見できなかった不具合と、予見しうる不具合と、予見されるべき不具合はレベルが異なると考えます。
Windows のアプリが不具合で異常終了したとしても、データが失われることもなく再起動で作業を続行できたなら、被害は極小です。みっともないですが、実用上は許容範囲とみなせます。
許せないとおっしゃるのであれば、その完璧さにたいする対価と時間を要求されることになると思いますが、その費用やユーザとしての機会損失を考えれば妥協があってもよいのではないでしょうか？
Re: (スコア:0)
> いまさらスタックポインタ戻し忘れてとんでもないところにリターンしたなんてバグを気にする人はいないでしょう？
> メモリの開放忘れや未初期化、開放済みポインタの参照を気にする必要もなくなった。
ありがとうございます。そういう具体的な話を聞きたかったのです。
> ソフトウェアは物理表現ではなく思想表現なので、間違ったものを作ったら物理法則が勝手に壊してくれるなんて甘いことはないんですよ。
いや、間違った物を作って納品して、客の生命財産を巻き込んで壊れたら大変なことだと思いますけど。
たとえば建築物がいきなり倒壊するとか
Re: (スコア:0)
物理表現に誤りがあったら自動的に検出してくれるじゃないですか。
物理法則の枠がはっきりしてるから仮想的に建築して強度を確認することもできる。
自動的な誤謬検出も事前の検証もソフトウェアが持ち得ない特徴です。
物理的な構造は劣化する箇所がある前提ですから100万回に1回といった定量的見積もりが可能でしょう。
ソフトウェアはどこか劣化しますか。
Re: (スコア:0)
> ソフトウェア業界の人はなぜそういう極端な話に走るんですかね。
> たとえば100万回に1回の確率で起こる事故は事実上起こらないと考えていいとか、そういう考え方はできないんですかね？
えーと、ソフトウェア業界で100万回毎は頻繁に分類されます
あなたの言いたい事もわかるがその数字は微妙
Re: (スコア:0)
>>みっともないですが、実用上は許容範囲とみなせます。
なんて甘えたこと言ってるからいつまでたっても前に進まない。