バグの出にくい言語仕様を考える２
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2006/01/16(月) 20:16:10メモリ管理にまつわるバグを出にくくした。
そのような考えを推し進めてバグの出にくい言語仕様を考えよう。
前スレ
http://pc8.2ch.net/test/read.cgi/tech/1111747980/
0153デフォルトの名無しさん
2006/01/21(土) 11:51:51やっぱりそこに落ち着くんだな
で、こんどは仕様記述言語の設計書が必要になって仕様記述言語記述言語ができると
0154デフォルトの名無しさん
2006/01/21(土) 12:40:27仕様記述言語自身で仕様記述言語を記述するから問題無いよ。
0155デフォルトの名無しさん
2006/01/21(土) 12:49:42条件に矛盾が発生したり、一意に動作が決定できないような場合は
エラーを返してくれるの。
0156デフォルトの名無しさん
2006/01/21(土) 13:22:37NP完全な問題だろそれ
0157デフォルトの名無しさん
2006/01/21(土) 15:14:25http://www.constraint.org/constraint_org.htm
0158デフォルトの名無しさん
2006/01/21(土) 20:39:33飛ばされた先で適切なルーチンを通らず、
Defaultで通過してしまうというケースから
起こったものが多かった。
一番単純なケースはエラーコードの誤り。
こういったケースでは強い型付け云々は
全く無力で、やはり仕様記述の問題だと
思う。
要求者が仕様記述言語で書いてくれる訳では
ないだろうから、やはり、日本語解釈の問題から
おんな::色=赤い 的な誤謬はさけられない。
この場合喩を含んでいるから、仕様記述としては
適切でないといえるが、多かれ少なかれこの
ような問題は発生する。>>118 -> >>115 のような
単純な写像が成立するためには、仕様記述以前の
要求段階でのモデリングはやはり重要と考えるが、
どんなものだろう。
0159デフォルトの名無しさん
2006/01/22(日) 09:38:59Javaのthrowsじゃダメなの？ Java使ったこと無いから細かい事は知らんけど。
0160デフォルトの名無しさん
2006/01/22(日) 10:46:28> こういったケースでは強い型付け云々は
> 全く無力で、
そんなことはない。
エラーコードを Enum型にすれば、間違って不正なコード
を返すケースや、コードを受け取る側で返されるはずの
コード全ての処理が入っているかのチェックができるよう
になるので、バグは "0" にならないけどバグを出しにく
くすることができる。
ただデメリットとして、エラーコードを増やしたりすると
まじめにエラーチェックしているプログラムほど修正個所
が多くなるので全体として非常に大変なことになり勝ち。
0161デフォルトの名無しさん
2006/01/22(日) 13:15:20私の対象にしたのが、10年くらい前の小型汎用機での事務計算システムで
開発言語はCOBOLというケースだから、現在と事情が違うかも知れない。
エラーコードについては私の書き方が悪かった。正しいエラーコード
たとえば、404を返さず、304を複数のケースに返してしまう、くらいの意味。
COBOLの場合、構造体は例の明示的なREC定義だがら、構造体の型の不整合に
よるエラーというのは起こり難い。エラーが起こるのは引数として
情報(ほとんどが××区分)がそもそも不足している場合。
if文の中にエラーがあるというケースよりもこちらの方が多かった。
これはすなわち、仕様かそれ以前の問題で、プログラミングではどうにも
ならない、と言うような事です。
0162デフォルトの名無しさん
2006/01/22(日) 14:25:19もちろんプログラムでどうにもならないケースがあるの
は承知しているが、このスレは「バグを出しにくくする
ための言語仕様を考えるスレ」だから。
UML とかは、ちょっとスレ違いかと。
0163デフォルトの名無しさん
2006/01/22(日) 15:47:58・強い型付とそのチェック強化でバグを減らす
・仕様段階でのバグの除去がやはり重要
という二論に分化していて、私の書いたのは後の方の立場。
仕様記述言語で仕様を書かせ(書いてもらう)、それを
可能な段階まで直接コード化する。コードが生成できる
範囲を少しづつ下方に広げていく。こういう戦略になる。
0164デフォルトの名無しさん
2006/01/22(日) 17:59:160165デフォルトの名無しさん
2006/01/22(日) 20:37:140166デフォルトの名無しさん
2006/01/22(日) 22:46:09セットされている場合は新規にクラスをつくってセットするというのがある
しかも、それが期待したオブジェクトが入ってない場合は１００％障害の場所に・・・
警告出すか、ありえないんだからそんな処理いれるなよって思ったよ
他にも変数の宣言はメソッドの入り口でまとめてしてしまうとか
スコープを意識しないロジックも満載
私は従順無能プログラマーで意図が読めないので
テスト通ったらせっせと直して再テストして出してますよ、えぇ
0167デフォルトの名無しさん
2006/01/23(月) 01:39:190168デフォルトの名無しさん
2006/01/23(月) 01:59:22ここはキミの愚痴を書くスレッドじゃないんだよ。
明らかにスレ違いだ。そんなことも分からないようでは、
キミの愚痴もどこまで信憑性があるか怪しいモノだね。
マ板にそういう愚痴スレは存在してるから
そこでグチグチ言ってろ。な。
0169デフォルトの名無しさん
2006/01/23(月) 06:34:20無責任で申し訳ないが、私は全然知らない。
15年くらい前にZの解説書の翻訳が出て、
見よう見まねで書いたことはある。元が
平らな文の記述なら、結構いける気がしたが、
やはり、Prologで直接書いた方が、たとえ
思いつきの部分が入り込んでしまったとしても、
生産性が高いので、採用しなかった。
題名を忘れたその本を探したのだが、昨日は
見つからなかった。見つかったら、サンプルを
書いて見る。
0170デフォルトの名無しさん
2006/01/23(月) 08:50:01全然知らないのに「仕様記述言語で仕様を書かせるとバグが減る」とか主張してんのか？
頭おかしーだろ。
0171デフォルトの名無しさん
2006/01/23(月) 09:22:09そこから抜本的に考えないとどうにも
ならないバグの方が多いといっているだけ。
トップダウンにシステムの開発言語を
含むシステムの再構築が必要なはずで
そのプログラムレベルのトップは
仕様記述言語と呼ばれる物がくるべき
だろうと思う。
私なら、全部Prologで済ますがね。
0172デフォルトの名無しさん
2006/01/23(月) 09:56:29呼ばれなくても良い。しかし、言語で組み立てられる仕様と
コードとの仲立ちをするのは、
述語論理と集合論以外に私は思いつかない。
現に、集合論と関係代数、関係論理を基礎とする
RDB+SQLの登場、普及によってバグは確実に減ったと思う。
この場合、仕様記述言語の部分を、データベースが吸収
したのだと思う。こういう転回は今後も起こるし、そんなに
大袈裟に考えるべき事ではない。
0173デフォルトの名無しさん
2006/01/23(月) 20:16:14ならばプログラムも…
0174デフォルトの名無しさん
2006/01/23(月) 20:39:37「バグの出にくいシステム構築を考える」スレではない
そういった精細さを欠いた人間には
仕様記述言語を与えたところで無駄であろう
0175デフォルトの名無しさん
2006/01/23(月) 20:58:55「バグの出にくい言語仕様を考える」ことに含まれないのかな？
0176デフォルトの名無しさん
2006/01/23(月) 21:20:03バグの出にくい言語を述語論理に基づく
言語と見てるわけだよ。
全部そういう言語に取っ替えようと
いうのは途方もない事だから、確実に
取り入れられて、かつ、現実にバグを
減らす事に寄与する仕様記述の部分を
強調しているだけ。
0177デフォルトの名無しさん
2006/01/23(月) 22:05:290178デフォルトの名無しさん
2006/01/23(月) 22:09:23仕様記述言語仕様記述言語言ってる奴、お前が思う仕様記述言語風に
○×ゲームの仕様きってみれ。
0179デフォルトの名無しさん
2006/01/23(月) 22:25:420180デフォルトの名無しさん
2006/01/23(月) 22:29:390181デフォルトの名無しさん
2006/01/23(月) 23:19:060182デフォルトの名無しさん
2006/01/23(月) 23:49:15いいなそれ。誰か「バグの出にくいシステム構築を考える」スレを立ててください。
>>178
仕様記述言語について語っていた人とは別人ですが、○×ゲームってどんなゲームですか？
0183デフォルトの名無しさん
2006/01/24(火) 00:15:02三目並べならわかるか？
0184デフォルトの名無しさん
2006/01/24(火) 19:57:19バグかどうかは仕様書に沿ってるかどうか
だからバグかどうかなんていうのは 言語仕様 に左右されないわけ
言語云々よりもっと高次の段階でバグが発見されて、
低次の言語云々の部分に完全に翻訳できれば何でもかまわないわけなのでね
というかそれは言語仕様でどうにかなるもんじゃない
夢見すぎ
もっと能力無いのを自覚しろよ
0185デフォルトの名無しさん
2006/01/24(火) 20:10:36だから意味無いじゃんって事で書いたんだが
その辺も仕様記述言語で書いてあった方が良いのか？
0186デフォルトの名無しさん
2006/01/24(火) 22:16:170187デフォルトの名無しさん
2006/01/24(火) 22:17:10良い。グダグタ言ってないで具体的にやれ。
0188デフォルトの名無しさん
2006/01/24(火) 22:18:41お前の能力では完璧な仕様書なんか出来ないだろ。
というかそれは人間にどうにかできるものではない。
夢見すぎ
もっと能力無いの自覚しろよ
0189デフォルトの名無しさん
2006/01/25(水) 12:41:53コンパイラ分野の長い研究の成果で、文法などの「形式」に関しては、ある程度体系化がなされているんだけど
「意味」を表すための研究というのは、「それをやるのは非常に難しい」という一定の結論が出ているんだよね…
(完全に不可能、とは言わないけど解決できていない問題があまりにも多い)
そのために、何処かで曖昧な記述しかできない自然言語で、現在でも仕様の記述が行われているんだけど
> 仕様段階でのバグの除去がやはり重要
自分なりにこの意図を汲み出してみると、これは「コンセプトの完全性」の問題を話している様に見える
コンセプトが正しくなかった＞アルゴリズムが無駄に複雑になった＞結果バグが増えた
なら相関関係がないわけじゃないけど、基本的にはバグの話とはズレている様に見えるかなぁ
0190デフォルトの名無しさん
2006/01/25(水) 23:29:27当然その「バグ」は「実装段階のバグ」であることが暗示されているわけで
それ以外のバグに関する論は基本的にスレ違いであると思われ
0191デフォルトの名無しさん
2006/01/26(木) 00:17:09バグが「出にくい」言語仕様と言った場合、
「不幸にも埋め込まれてしまったバグが顕在化しないための方策」
でもあるのだろうかという話にならなければならない。
0192デフォルトの名無しさん
2006/01/26(木) 00:18:120193デフォルトの名無しさん
2006/01/26(木) 00:45:19エラー表示の無いコンパイラとエラー表示のない製品を作ってしまえ！
0194デフォルトの名無しさん
2006/01/26(木) 00:47:19Microsoft
富士通
三菱
0195デフォルトの名無しさん
2006/01/26(木) 03:20:15ほとんどのバグは仕様→プログラミング言語への翻訳過程によって起こる。
この翻訳過程を自動化しようという試みもあるが、技術的に困難。
そこでだな、逆転の発想でプログラムから仕様を自動生成すれば
0196デフォルトの名無しさん
2006/01/26(木) 15:16:38実はこういう場合がありました、というところでバグが出る。
この辺をどうにかしる。
0197デフォルトの名無しさん
2006/01/26(木) 23:02:22実はこういう場合がありました、というところでバグが出る。
という勝手な思いこみ・決め付けをなんとかしる。
0198デフォルトの名無しさん
2006/01/26(木) 23:31:16実際にプログラムを動かしてみることかもしれない。
0199デフォルトの名無しさん
2006/01/26(木) 23:37:18んだけど、残念なことにそれでは納期に間に合わないわ
けで…。orz
0200デフォルトの名無しさん
2006/01/27(金) 00:11:37マ向け
0201デフォルトの名無しさん
2006/01/27(金) 00:21:31問題がありゃお客が怒ってくるでしょ。使いもんにならん！って。
そうすりゃしようを考えた奴のケツにも火がつくわけで、効果的だと思うけどね。
0202デフォルトの名無しさん
2006/01/27(金) 10:21:140203デフォルトの名無しさん
2006/01/27(金) 11:42:29言語にすればいいんじゃないだろうか。メモリ開放忘れとか。
但し忘れ過ぎたら意味ないのでまずプログラマーの脳の働きを向上させる
必要がある。ということでまずは任天堂DSの(以下略)
0204デフォルトの名無しさん
2006/01/27(金) 12:30:48そんなことはない。
例えば例外機構は、例外処理を強要することで、
「この関数は必ず成功する」という決めつけを排除している。
言語で出来ることは色々ありそうだ。
0205デフォルトの名無しさん
2006/01/27(金) 12:34:04それがアジャイルとかプロトタイピングでしょ。
でも、
このスレで言っている仕様上の不備って言うのは、使い勝手とかじゃなくて、
微妙に曖昧なところがあったり、微妙な考慮不足があって、
実際にコードに落すと端っこと端っこで矛盾＞バグ発生、っていうモノでしょ。
0206デフォルトの名無しさん
2006/01/27(金) 13:25:09ヤヴァイのは「ごく稀にしか起こらない重大なエラー」
0207デフォルトの名無しさん
2006/01/27(金) 20:30:43C言語で自動変数初期化忘れとか。ありますねえ。
コンパイラもそのままだと何の警告も出さなかったりして。
0208デフォルトの名無しさん
2006/01/27(金) 23:20:110209デフォルトの名無しさん
2006/01/28(土) 00:47:05エラーだけ出すなんて、怠慢だな。
0210デフォルトの名無しさん
2006/01/28(土) 01:20:14*1 仕様から考えてちょっとおかしい動作をすること
*2 システムから考えてちょっとこれは違うんじゃない？って感じ
*3 書いたとおりに動かない環境
正直、*1 *2は言語じゃどうしようもないと思う。
かといって*3について述べているわけじゃなさそうだし…
0211デフォルトの名無しさん
2006/01/28(土) 01:30:12仕様そのものがおかしいのや
実装していないものが仕様どおりに動かないのは
ここでいう「言語」には関係ないだろし
0212デフォルトの名無しさん
2006/01/28(土) 01:37:01「使いもんにならん！」ってのは「使い勝手」のことには限らんがな。
帳票と画面の矛盾とか、サブシステムをまたいだ矛盾とか、そういうのさ。
0213デフォルトの名無しさん
2006/01/28(土) 08:50:18リバースエンジニアリングということになるが、
双方向性の言語仕様ってのは無理なのかな。
0214デフォルトの名無しさん
2006/01/28(土) 09:00:47初期値が0とかとは限らないから、勝手に初期化されるよりはエラーの方がいいだろ。
0215デフォルトの名無しさん
2006/01/28(土) 10:10:070で動いちゃう方がバグになりそう。
0216デフォルトの名無しさん
2006/01/28(土) 10:25:290217デフォルトの名無しさん
2006/01/28(土) 11:16:560218デフォルトの名無しさん
2006/01/28(土) 11:55:15暗黙に初期値はゼロって事でワーニングで済ませてもらいたいもんだ。
0219デフォルトの名無しさん
2006/01/28(土) 15:05:28「変数の初期値は0で警告は無視する」というやつに対しては、
確かにバグが減っている。
決め付けの排除ではなく、決め付けの通りに動いているわけだな。
0220デフォルトの名無しさん
2006/01/29(日) 04:28:58やはり型情報にいろいろ追加する機能があると良いのでは？
C++のtemplateは裏技チックだからもうちょっと素直な奴。
0221デフォルトの名無しさん
2006/01/29(日) 12:54:360222デフォルトの名無しさん
2006/01/29(日) 14:10:24「プログラマの意図しない動作」をするのがバグなら、出来るだけ人間の思考にすり寄った形でプログラム言語を作成してしまうのが、バグ排除の究極の形の一つと言えるんじゃないかな。
型情報の強化というのは俺も賛成、色々理由はあるけど
「何より、現行技術でやりやすい」
というのが一番かな
0223デフォルトの名無しさん
2006/01/29(日) 15:56:44型情報に何かを付加する方法の一つに、インタフェイスを作ってしまうという方法があるかと
インタフェイスはデータの見方を変える手段として使えるわけで・・・
0224デフォルトの名無しさん
2006/01/29(日) 16:18:140225デフォルトの名無しさん
2006/01/29(日) 22:29:49組んでみて、動かしてみて、初めて、あ・・・ってな感じ。
0226デフォルトの名無しさん
2006/01/29(日) 22:37:53JDK5.0 にそれっぽい仕様があったような・・・？
>>224
そうそう。設計自体がそもそもバグだったりっていうのはたまにある。
0227デフォルトの名無しさん
2006/01/30(月) 00:21:230228デフォルトの名無しさん
2006/01/30(月) 00:22:550229デフォルトの名無しさん
2006/01/30(月) 00:39:56良い仕様を考えるのに必要なのは、経験と内省力。
0230デフォルトの名無しさん
2006/01/30(月) 00:42:01まぁCOBOLでもまだ重いと思うけどね。
0231デフォルトの名無しさん
2006/01/30(月) 01:26:12良いコンセプトを作る前から理解している、というのはソフトウェア以外でも、全工学分野で難しい問題で、実際の所それは作ってみないと分からないんだよね…。
プログラムの場合、プロトタイプを行うことでその正しさをかなり検証することが出来る。
実際の所、センスなんていう個々人の才能に強く依存するモノを当てにしないためには、これまでの設計を収集、分析して経験的事実を取り出していかないといけないんだけど、まだまだ時代がそれをまとめ終えるところまで進んでいないんだよね…。
0232デフォルトの名無しさん
2006/01/30(月) 01:48:230233デフォルトの名無しさん
2006/01/30(月) 03:22:32http://d.hatena.ne.jp/tanakh/20051001
0234デフォルトの名無しさん
2006/01/30(月) 03:30:00インタフェイスって？Javaのinterfaceみたいの？
それじゃあ、上の方に出てきた
null代入禁止とか、次元解析とか、そういう制約は書けなそうだけど。
0235デフォルトの名無しさん
2006/01/30(月) 09:34:50収納名人だろ
0236デフォルトの名無しさん
2006/01/30(月) 12:51:26インターフェースじゃなくてアノテーションの事言いたいんだろ
クラスというかバイナリに付加できるメタデータの事だな
たとえば、EJB3.0じゃセッションビーンになる為にはPOJOで作って
"@Session"をクラス定義に付加すればよいって感じ
アノテーションは宣言だけじゃなくて何処にでも掛けるから
後でコード挿入したい場所に書いておけば簡単にDIが実現できるとか
特定のデバッガ上で意味を持つアノテーションを実現したりも出来る
0237デフォルトの名無しさん
2006/01/30(月) 13:16:56しかしそれは動的なチェックだろ。バグが出てから調べやすいだけだなぁ。
それを静的にチェック出来てコンパイル時に排除できるというのが>>220。
0238デフォルトの名無しさん
2006/01/30(月) 13:22:47ソースに記述できるんだからやろうと思えば静的にチェックできるよ
Javaに関しちゃ静的・動的で２分しちゃう意味は無い
0239237
2006/01/30(月) 13:32:040240デフォルトの名無しさん
2006/01/30(月) 13:45:23やはり、破壊代入を排除する所まで行かないと。
0241デフォルトの名無しさん
2006/01/30(月) 15:42:57それとオブジェクト指向と相性が悪そう。
0242デフォルトの名無しさん
2006/01/30(月) 15:59:431. 文字列型は欲しい。
2. ポインタは極力隠れていた方がいい。core dump とか OS の機能をそのまま
使わずに自分でエラー出してどこが悪いかある程度出して欲しい。
3. 再帰は楽に書ける方がいい。しかしすぐなくなるスタックを使わんでくれ。
4. ていうか自動変数にスタックを使わないで欲しい。使う必要ないよね?
5. バッファオーバーフローの検知。Cのように放置して破壊や乗っ取りが
できてしまうのは嫌。
6. メモリは参照なくなったら勝手に開放されて欲しい。開放後にアクセス
しようとしたらエラー出て欲しい。
0243デフォルトの名無しさん
2006/01/30(月) 16:13:51C/C++以外の言語使ったこと無いのか？
JavaでもPHPでもいいからとりあえず使ってみろ。
バッファオーバーフローなんて文字列型がちゃんとある言語ならまず起きないだろ。
参照無くなって開放されたものに、後からどうやってアクセスするんだ？
0244デフォルトの名無しさん
2006/01/30(月) 18:00:38つうか3が意味不明。末尾再帰の最適化を言ってるのか？
0245デフォルトの名無しさん
2006/01/30(月) 18:42:24Lispなんかじゃあって当たり前の位の物だな
末尾再起をループに展開するぐらいは最新のCコンパイラでもやってくれそうだが
其処の所どう？
0246デフォルトの名無しさん
2006/01/30(月) 18:58:130247デフォルトの名無しさん
2006/01/30(月) 19:37:40http://d.hatena.ne.jp/yaneurao/20051008
http://d.hatena.ne.jp/yaneurao/20051025
0248デフォルトの名無しさん
2006/01/30(月) 19:59:02末尾再帰じゃない再帰をループ展開する必要なし。
0249デフォルトの名無しさん
2006/01/30(月) 20:15:07問題の次元を落とし込むことができるから、
メモリをふんだんに使えて再帰以外の実装があまりにも複雑なら再帰にすべき
・・といっても、再帰なんて気持悪くてあんまりしないんだけどな。
そんな複雑な問題、汎用PCでやらんし
0250デフォルトの名無しさん
2006/01/30(月) 20:20:03そういう言語仕様が望みだというならよくわかるけど、
バグの発生とは関係ない項目が多いのはなぜ。
0251デフォルトの名無しさん
2006/01/30(月) 20:37:16248では「再帰を使うな」とは主張していないんだが。
なぜそんなレスを？
0252デフォルトの名無しさん
2006/01/30(月) 22:29:57再帰は、末尾再帰しか許さない
って仕様でイインジャネ？
■ このスレッドは過去ログ倉庫に格納されています