バグの出にくい言語仕様を考える２

javaはC/C++からポインタをなくしたりGCを導入することで
メモリ管理にまつわるバグを出にくくした。
そのような考えを推し進めてバグの出にくい言語仕様を考えよう。

前スレ
http://pc8.2ch.net/test/read.cgi/tech/1111747980/

>>1は根本的なことを判っていない。
プログラムが無ければバグも出ない。
つまり、言語仕様を考える前に、
如何にしてプログラムの存在しない世界を作るか、
を考えるべきだ。

バグを出にくくするためには、

腹を出さない方法を編み出すのと同様に、

何故腹が出るのかを考えなければならない。

バグは人が生み出す知的な情報であるのだろうか？

これまた>>2に思い切った電波を仕込むアグレッシブなスレだな

>>2
>>>1は
>　ロ
>　　り
>
>　　　　　　だ。

なるほど、そーなのか。

>>5の想像力に脱帽。

>>2
> >>1は
> 　　グ
>
> 　　　　　　ロ　　　　　　　　い
> 　　　　　　　。

なるほど、そーなのか。

なんで、馬鹿が粘着してるの？

前スレの結論めいたレス

958 名前：デフォルトの名無しさん[] 投稿日：2006/01/15(日) 14:07:19
リッチな型情報を容易に使えること、というのが結論ということでよろしいか。


※リッチな型情報
nullになり得る・なり得ない、役割、次元解析できる単位、などなど

前スレの結論めいたレス

992 ：デフォルトの名無しさん ：2006/01/16(月) 17:36:58
強力な型付けがバグを減らすために重要って事が一つの結論なら

どういう文法であれば、型付けの煩雑さと、バグ削減の有用さを上手にまとめられるかとかの議論も欲しい

前スレの結論めいたレス

996 ：デフォルトの名無しさん ：2006/01/16(月) 19:54:11
暗黙のキャストが邪悪なのは常識
しかし，利便性と天秤にかけた結果敢えて残されている
利便性を捨てて避けたければTypedefで見かけ上別の型にしてしまえば良いだけの話

関連スレ

-generic- 総称的プログラミング -programming-
http://pc5.2ch.net/test/read.cgi/tech/1079460996/

型なし言語逝ってよし
http://piza.2ch.net/tech/kako/986/986355498.html

バグの無いプログラムをバグが出ないように組み合わせれば、、、

それでもバグは出る。

前スレ975の件についてですが、int型をfloat型に代入しようとしているのだから
結局978さんの言っているように、コンパイラが警告を発してくれるのが
最も簡単な解決法のような気がしました。
ちなみに、C++Builderでも警告を発してくれなかったです。

じゃあおまいらは超強力な型付け方面で議論しててくれ。
俺はスレッド絡みのバグをなくす方向で検討してみる。

行列演算向けにWikiみたく
E=| 1 0 |
　 | 0 1 |;
みたいな表現をする言語があったら面白いと思うんだが

じゃあ作ってみろ。
話はそれからだ。

型が違う変数への代入を出来なくすれば良いだけのような

>>19
PASCALとか?

2次元配列？

>>16
つ http://pc8.2ch.net/test/read.cgi/tech/1110031339/
つ http://pc8.2ch.net/test/read.cgi/tech/1047230229/

　　　　　　　　　　,′　　/／,,-‐"/／ヽ ヽ
　　　　　　　　　　l　　　 |'〆-‐／'　‐-ゞ　l
　　　　　　　 　 　| 　 　 |'　　 _ 　 　 　　l| |
　　　　　　　　　　|　　　 l ,ｒ7〒　　〒=､/ l
　　　　　　　　　　ｌ∧.,∧|',弋ノ‐､　,弋ﾉ､/l
　　　　　　　　　　 l:;､;:::;:lﾍ_　 _.ノ￣､_ _ノ:;l
.　　　　　 　 ||￣￣￣￣￣￣￣￣￣￣￣￣￣￣|
　　　　　.__　||　　　　　　　　　　　　　　　　　 　 　 |
　　　　　ヽヽ||　　　　　トイレ　　　　　　　　　　　　|
　　　　　　t==､　　　　　 　 　　　　 　　 　 　 　 　,=､
　　　　　　l　'=',　　　　行ってくるね　　　　　　　 `=3
　 　 　 　 ヽ'||'　　　　　　　　 　 　 　 　 　 　 　 　 |`′
.　　　　　 　 ||　　　　　　　　　　　　　　　　　 　 　 |
.　　　　　 　 ||　　　　　　　　　　　　　　　　　 　 　 |
. 　　　　　　 ||＿＿＿＿＿＿＿＿＿＿＿＿＿＿|

>>17
s/|\s*(\d*)\s*(\d*)\s*|/{ $1, $2 },/e

このスレ読んでると
データベース言語ってのは全体的に良くできてる言語だと思うんだが
気のせいか

>>25
今のところ「いい」プログラミング言語は、
Pascalに代表されるように、少なくとも自己記述能力がある。
と考えられている(かも)

その点どうよ？

>>19
> 型が違う変数への代入を出来なくすれば良いだけのような
一理ある。
変数に入るデータの型が変わるときには、それを明示するのはありかもしれない。
具体的には
// コードはJavaScript
var tag = ["a","em","strong"];
tag = "</?("+tag.join("|")+").*?>"; //指定したタグを消し去る正規表現
var tag_reg = new RegExp( tag, "g" );

で、２行目を
<String>tag = "</?("+tag.join("|")+").*?>";
で書くことを推奨するとか。（サンプルソースとしてはびみょいな

実際の所、動的言語でも、宣言時の型と違う型を再代入する場面って少ないから、最初の代入時に何の型が入ったかをIDEが知っていれば、あとは「多分、型は変わっていない」と類推してあげられるんだよね。

前スレ975のケース
int a = 1;
int b = 3;
float c = a / b;
についてだけれど、コンパイラがfloat c= まで読んだ時点で
=の右辺をfloatの文脈とする言語があっても良い気がする。
つまり、型を決めるのはデータの供給側でなくて需要が決めるという言語。

ｃ：＝
懐古に戻る

>>28
君言語だと、

int i = 0.9 + 0.2;

が、i == 0 になるけど、それでもいい？

>>30
俺は28とは別人だが、縮小方向への型変換になるときにはエラーを出すというはどうだろう？
その場合、それが必要なら当然キャストすれば良い。

>>25
DB言語ってSQL?　どういうのが良くできてるん？

>>26
自己記述能力ってなんだ？

(a / b)が代入側のfloatに暗黙にキャストされるからこそエラーにならないわけだが
aをfloatにしろっていうのなら無茶だ
c = a/b;
はつまり
c = divide(a,b);
なのであってaは代入から直接は見えない
関数に対し需要形を透過するか否かを毎回決めるなんてしちめんどくさい言語は御免被る
しかもメリットが邪悪なキャストだけだってんだから激しくｲﾗﾈ

> aをfloatにしろっていうのなら無茶だ
> c = a/b;
> はつまり
> c = divide(a,b);
> なのであってaは代入から直接は見えない

バカなのか釣りなのかはっきりしろよ。

>>31
そして誰もがキャストしはじめる

>>29
俺も同じ事考えたことがある。
ただ、俺なりの回答では、それは「No」だね。
理由は単純
「それは美しく、またハッキーではない」
実際、代入はあまりに頻繁に使うから、1タイプ多いだけでも割に合わないんだよね。利点の部分も認めるけど。

変数名もa〜zのひと文字で済ますような奴は、このスレで語る資格すらねえよ

c <- a+b;

int a = 1;
int b = 0;
float c = a.0 / b.0;

>>30
それでもかまわない。その例だと誤差が極端に見えるが、
int i =100.9+100.2;
なら201の代わりに200になるだけ。
精度が欲しければ明示的に宣言すればよい
double a;
double b;
int c = float(a+b);
みたいに計算資源を節約することもできる。最近のCPUならありがたみはないが。

こういうこともできる。
string s="12"+"34"; //s="1234"
int i="12"+"34"; //i=46
そもそも、計算というのは何かに利用するために計算するのであって、
元のデータから押し売りする訳じゃない。
そう考えると需要が型を決めるというのも不自然ではないと思うが。

宇宙計算に使える計算機を発達させれば宇宙開発言語が発達し計算精度が気になってくるはず
姉は設計に任せても計算精度が高いソフトが出来上がる

仕様のバグの方が多いんだから、まずはそっちを何とかしろと。
あとは、仕様からコード生成する仕組みを作ればおしまい。

かつて、FORTRANで書いてコンパイルすることを
「自動プログラミング」と言っていたのを
思い出した。

>>42
言語仕様というより、
論理プログラミングを理解できない者には
一切の資格を与えないようにすればよい。

>>42
MDAとかxUMLか？
http://ja.wikipedia.org/wiki/仕様記述言語

しかし、>>43の言うように、ホントにそれから最終的に必要な実行可能なモノが生成されるのなら
それはずばりプログラム言語だと思うんだが、どうか。

>>17
APLとかその辺じゃだめ？

>>40
なんだ？
結局型無し言語マンセーなだけか

int型じゃなくてdouble型で整数しか取らない型ってのがあれば良いんじゃないのか？

えっとね、例え64ビットの正の整数型があったとしても
扱えるはずの数の範囲は64*log10(2)だから19桁程度になるんだよね。
結局の所、とても大きな数や、とても精度の高い計算の場合、欲しい桁数の範囲までメモリを取れないといけないんだけど
これってLispやRubyの積んでいるNumber型の事…orz。
問題はNumber型って、それなりに計算資源を喰うんだよね

C言語が長さ固定の型をたくさん持っているのって
「パフォーマンスに応じて使い分けてね」
という所なのだから、型の長さと誤差は不可分の問題と理解して、必要に応じて使い分けるものというだけなんだよね…

うん、なんかそんなかんじ。板汚しゴメンナサイ。

>>40
カッコ良い。
rubyの場合、引数の型が変わるときって
s = 12.to_s + 34.to_s #s="1234"
i = "12".to_i + "34".to_i #i=46
と書かないといけないんだけど、常々これって「気持ち悪い」
と思っていたので。

>>47
> 結局型無し言語マンセーなだけか
型にこだわらない、つまりはどんな型でも入れても良いということはそんなに悪いものでもないよ。
型がめまぐるしく変わる場合なんかは、記述を大幅に簡略化できる場合が多々ある。

逆に、型に小うるさい分、もっと簡潔に書けるはずのものが、無駄に複雑になるときもある事を考えれば、型のチェックというのは毎度行うものではなくって、必要な箇所を見抜いて、関所のように配置するのが適当だと思う。
そういう意味では、良い言語というのは「基本は型無し言語＋簡潔な型チェック文法」が一つの正解に見えるんだけどなぁ…。

>>40
int i = "12" + "34";

で、i に 1234 を設定したいときはどうすればいいの？

どうでもいいよ。
小数なんて使わないから。

基本型としては数値型と文字列型だけでいいんじゃない？

数値型はいらないだろう。

>>47
型無し言語かどうかはあまり関係ないよ。それは型を決めるのが実行時かコンパイル時かという違いでしかないし。
今考えているのは演算結果の型を決める方法について、普通と違うアプローチ。

Cの文法の発想法との違いを図式化すると
c=a+b;という代入文を
ａ→＋→ｃ
　　↑
ｂ→↑
ボトムアップ・できること指向で考えるのがC流で

ｃ←＋←ａ
　　↑
　　↑←ｂ
トップダウン・欲しいもの指向で考えるのが今考えている言語流。

更に思いついた例
float c=1/2; // 割り算はfloat(float,float)型関数じゃなくてfloat(int,int)型
もう一つ
string s = "12" * 3; // s="121212";
int i = "12" * 3; // i=36;
こーゆー使い分けははC++みたいな演算子オーバーライドでは共存できない。
これはやりすぎっぽいけどね。

演算子オーバーライドが誤読の元だというのは承知しているけど、
そもそも整数演算と実数演算に同じ演算子を使うという時点で入っちゃってるんだよね。
それがそもそもの前スレ975の原因の一つなわけで。
そして、人間の発想は欲しいもの指向とできること指向の両方があって、
代入なんかは欲しいもの指向だったりするわけだ。
（できること指向なら左辺が値で右辺が書き換えられる変数という方が自然だと思う）
その辺りが975みたいなことをしたくなる心理じゃないかと思うけど、どうよ？

>>51
int i =string("12"+"34");

＞ c言語で
＞ 　　　　int a = 1;
＞ 　　　　int b = 3;
＞ 　　　　float c = a / b;
＞ で計算すると c=0 になってしまいます。
＞ 　　　　float c = 1.0 * a / b;
＞ だとちゃんと c = 0.3333 になります。
＞ これって結構バグの温床になっているような気がするけど、
なってません。

>>40
int i =100.9+100.2;
float f = 100.9 + 100.2;
printf("i = %d, f = %f\n");

で、結果が 'i = 200, f = 201.1' になるの？
ちょっと嫌だな。

string s = "123" + "456";
int i = s + "789";

「おっ、s ってここしか使ってないじゃん。」

int i = ("123" + "456") + "789";

バグが増えそうな予感...。

よく使われるデザインパターンを文法的にサポートしてくれるといいかなーと思った。
イメージとしては、例えば Java の拡張forループみたいな感じに。

自分が思いついたのは、例えばシングルトンパターンの場合、本来なら
 - コンストラクタを private で宣言する
 - private な クラス変数を用意する
 - インスタンス化メソッドを用意する
っていう手順を踏まなくちゃいけないところを、クラス宣言で
 singleton みたいなキーワードをプラスするだけで
(コード例: public singleton class Test{} )
自動的に上で書いたような実装を作ってくれる、とか。
そうすると、コードも簡単になるし、可視性の設定ミスみたいな単純なバグが
防止できていいかなーなんて。(例えばコンストラクタを private にし忘れて
インスタンスの複数生成を可能にしてしまうなど)

テストパターンを自動的に作成してくれる言語が欲しいね。
あと、コードを変えたとき影響を受ける部分を可視化できる言語。
(非常に強く影響を受ける部分は赤で、たぶん影響を受ける部分は黄色で表示するとか)

それって、言語じゃなくて開発環境じゃないの

このすれに少しでも期待した俺がバカだった、、、、

Enumをキャストしなくてもループカウンタに使えるといいな

>>63
foreach i of enum型名
みたいな感じ？

C++以外を使う人にはうざいかもしれないけど勘弁を。
>>59
完璧ではないけれど、C++のテンプレートではこれくらいまでは何とかなる。
template<typename T, typename AccessT = T>
class Singleton : boost::noncopyable
{
public:
    static AccessT& Instance() {return obj;}
protected:
    Singleton() {}
    ~Singleton() {}
private:
    static T obj;
};
template<typename T, typename InstT>
T Singleton<T, InstT>::obj;

//例
class Hoge : public Singleton<Hoge>
{
private:
    friend class Singleton<Hoge>;
    Hoge() : i(1) {}
public:
    int i; //例なので簡略化のためGetter/Setterは勘弁
};
int main()
{
    cout << Hoge::Instance().i << endl;
//  Hoge h; //エラー
}

enum型の変数名では？

というか、そもそも、enumが型ってのがおかしいだろ。
型の属性だろ。このスレの上に出てたリッチな型情報に入るべき。

言語仕様でバグ減らそうなんてのが甘いんだよ。
C++からJavaに移ったけど、全然バグは減ってない。

まあ、BUGの原因がどういう物であるかを考えれば、どんな言語を開発した所で減るわきゃないんだがな。

>>40は
＋ :: string -> string -> number とかがあれば良いだけかと。

バグを見つけやすい、まではどうにかなるかもよ。

まずは、オペレータとなる記号に複数の意味を持たせないって単純な所から始めようぜ。

現状で一番望まれるのは、>>42なんだろうな。バグの割合からして。
しかしそれをどう言語でサポートできるかというと、>>45の言うように
検証可能な言語で仕様を書く、というのは、プログラミングそのものに思えるんだが、
仕様記述言語というのを使ったことある奴に意見が聞きたい。


>>67
アセンブラで仕事してください。


>>68
プログラムを書くから。で、前スレ>>2に戻る。

アセンブラで面倒なのは、バグが起きたときどこがどうなってるのかわかりづらいこと。
慎重になるからか、バグの件数そのものはそんなに多くない。

javaは配列はいらんと思う。
配列をメソッドに渡したときにメソッド内での変更が元の配列に反映されることを知らない人を
何人か見たことがある。

じゃあ、すべてpass by valueにするか。deep-copyで。
配列の問題じゃないし。

Javaにconstがあればいいのに

なんでないんだろ。あんま、使われないのかな。const char*以外。
C++よく知らないけど、普通に使ってる？
Javaのfinalも、いわゆる定数以外あんま使わないしな。

ああでも、後からプログラムを変更しずらそうではあるな。
あと、これも上にあったリッチな型情報ってことか。

【C++】 const だけでメシが３杯食えちゃうスレ
http://pc5.2ch.net/test/read.cgi/tech/1078193971/

こんなスレがあったくらいだからなぁ

Perlが出てきてからおかしくなったんだよ

Perlで$キーの擦り減りが良くなった　今は見えない

>>72
おめぇら、形式的仕様記述について知ってる事を書け
http://pc2.2ch.net/test/read.cgi/tech/1013507313/

記号だらけの言語って言葉で伝えるときに苦労するんだがPASCALやCOBOLみたいにならないか？

Prologみたいにならないか？

ゲーデル数だけにしよう。

>>49-50
つまりメモリいっぱい積んであれば型なんか気にしなくていいよ
っていうことか。メモリいっぱい欲しいな。

>>85
CPUの速さも欲しい。

ここは理想を語るスレ。
資源は無限にあると考えてよかろうて。

文字列結合は”＋”でない方が良い

すべての入力パターンを事前に検証すればいい。
量子コンピュータなら可能だろう。

英語のスペルは省略しなくていい

Cみたいなプリプロセッサはいらない

文系にしてみれば記号が見えた時点で死ぬと思う

変数と関数名に日本語が使えると見通しがよくなりそうな気がするな。

関数や変数にコメント必須にするとか

一番問題なのは識別子にスペースやカンマが入らない点
場当たり的にクオートじゃ成り立たないんだよ文型は
全角なら通るけど半角なら通らないとかなるとまたまどろっこしくなってくるし
スペースの大きさ測るのに専念することになっていらいらする

>>93
変数名や関数名は一意の記号でも良いと思う
それと簡単に意味や内容とが一致できるようなIDEとセットじゃないと意味が無いが

>>95
Program Files ですか

>>93
-とーと一を間違えそうな予感。

>>93
できない言語ってどんなものがあるのですか。

>>99
あくまで気がするだけだ
日本語の名寄せを甘く見るなよ

できる言語ってどんなものがあるのですか。

日本語プログラミング言語ひまわりとか

COBOLも識別子は日本語でよかった
LISPもいいのかな多分
Smalltalkは発作的に日本語コードを覚えられる
あんまり重要な分野じゃないから省かれた

Rubyもつかえるはず

つか、日本語の識別子が使えること、って需要あるの？
習得度の差はあれど、日本人なら英語は必修で学ぶし
言語のポータビリティが低下してしまう

UTF通すようにすれば問題ないんじゃね？？ｗｗｗｗｗｗｗｗｗｗｗ

>>104
激しく否定。character数を1:2と考えても、
一単位あたりの漢字の表意力はAlphabetより上。

特許申請に持っていける言語を作ればいい

>>107
100年後ぐらいまでに

ごめん。ポータビリティとは関係なかった。

関数名に漢字が使えないとすると、「雪は白い」のプログラム

白い(雪).

は、どう表現すればよいのだろう。

>>110
#define 白 Shiro
#define 雪 Yuki

それだとそもそも何をする関数なのか検討もつかないんだが・・・
まあ
shiroi(yuki);
でいいよ

もっとわかりやすい名前つけろ、といいたいが

雪.色=白;

VBは4.0から出来たな
Javaも可能
C#をふくむ.NETはだいたいできる

>>112
この場合は?
電子計算機を使用して源泉徴収税額を計算する方法を定める財務省告示(_給与等,_社会保険料,_配偶者扶養親族等合計,_税額)　:-
　　_社会保険料控除後の給与等の金額　は　_給与等　-　_社会保険料,
　　別表第１(_社会保険料控除後の給与等の金額,_給与所得控除の額),
　　別表第２(_配偶者扶養親族等合計,_配偶者控除額),
　　_その月の課税給与所得金額　は　_社会保険料控除後の給与等の金額　-　_給与所得控除
の額　-　_配偶者控除額,
　　別表第３(_その月の課税給与所得金額,_税額) .

クラス名は名詞、関数／メソッド名は動詞、
双方とも形容詞は論外
って考えてるのは俺だけかなぁ

>>115
一字でも間違えたら大変な事になりそうだ。

財務省のサイトから直接取って編集するだけ。

コメントに書いた変数の右側の注釈がIDE上のエディタでポップアップで出せるようになればきれいに書けないか?

むしろ、ラインを引くほうがいい。
それを手繰っていけば宣言と使ってるところが分かるように。

>>113
>>110の「雪は白い」という仕様の中に色という情報はない。

assert(雪==白)

春は曙

>>117
今の言語だって一緒だろ？

>>124
そんなプログラム作るほうが悪い。

こうやってみると、なんか自国語でプログラムって凄い違和感有るな

或意味、英語圏なんかの人より我々の方が、よりメタ化して考えられている気もする

>>125
意味不明。

>>126
そうか、読む方としてはべたな英語もどき使われるより
わかりやすいと思うけど。

特に、メタ化なんて言う知ったか用語を使う必要のない
事務用途にはぴったりだと思う。

英語読める奴が COBOL のソースを読むとこういう感じ
なのかもな。

ただ、日本語は入力するのがちょっと辛い。インテリセ
ンスとかが利けはましになるかな。

日本語を話せ

>>128
日本語（にほんご）は、狭義の日本民族（大和民族）の言語であり、主に日本で
使用される言語である。日本の「国語」とされている。使用者は世界で約1億3千万人。
日本以外では、台湾原住民の異なる部族同士の会話に用いられることがあり、
またパラオ共和国のアンガウル州が公用語の1つに採用している (CIA - The World
Factbook -- Field Listing - Languages)。挨拶や一人称などが多種多様に及ぶ。
また、海外の日系移民や日本研究家、ビジネスマンなどによって使用・学習されている。

言語学的な特徴として、語の格を示すため語尾変化ではなく、文法上の意味を
表す機能語（助詞・助動詞）を付加することから膠着語に分類される。他言語と
大きく異なる点として、表記上の文字体系が非常に複雑であることが挙げられる。
なお近縁の言語は琉球語しか専門家に認められていない。朝鮮語とは文法構造
が類似しているが、基本語彙で共通点は少ない。また（北海道の）アイヌ民族の
言葉であるアイヌ語は孤立言語とされ、日本語とは基本的な性格が異なる。

>>128
諸外国の方なの？

必死だなｗ

>>131
あなたを、犯人です。

>>124
普通は、配偶者控除額とか給与所得控除の額とか給与等とか社会保険料控除後の給与等の金額とかは使わない。
たまにあるんだけどさ。
似たような用語が大量に定義されてて、いちいち使い分けないといけないような案件が。

>>133
>>124 の言ってるのは日本語を使っていないプログラムでも1文字間違えたら
エラーになるだろう、という意味ではないかな。
それから、>>115で使われている語彙は、源泉徴収税額表の末尾付近に
付加されているも頁の中に出てくるもので、
30年以上前からある。以前は
「大蔵大臣告示による計算機による税額計算」といった。
どんな企業でも、総務畑にいる人なら知らない人はいない。

>>113 は間違っていないし、それしかないと思う。ただし、
仕様が「おんなは赤い」だったらどうだろう。
女.色=赤;
が正しいとはいえない。私は今村昌平の「赤い殺意」を思い出してしまう。

赤い(女).
だと、少なくとも間違っているとはいえない。

>>135 仕様が「おんな」だから、「女」は「おんな」に直してください。
ごめん。

関数とかいうから話がこじれるんで
素直に述語といいなさい

>>134
その分野ではよく使われている単語だからっていうのはわかるけど、
「バグの出にくい」という目的からは真逆の方向に突っ走ってるんだよね。

>>110
is("雪","白"). かなぁ。

日本語にすると何故かPrologっぽくなってる件について。

>>138
語彙が仕様書そのままで、ロジックの表現もほぼ仕様書どおりの書けるのだから、
バグは出にくくなっていると思うよ。まじで。
わざわざ英語（というかローマ字）に直さなければならなかったり、
四則演算や配列などに置き換えなければならないほうが、バグはでやすい。

慣れた人が書けばね。

雪::色=白
だな。

日本語を記号化する事と、プログラムと、どう関係あるの？

最初から曖昧な記述の可能な言語を発端にしてるから問題があるんだと気付きなさい。

ある事柄をどうモデリングするか、どういうモデルをサポートしているかというのは重要。

ある事柄をどうモデリングするかって？　その時点でBUGの９割が住処を見つけたとほくそ笑んでる訳だな？

頭の悪い上司に興味をもたれる
↓
頭の悪いプロジェクト体制で使われる
↓
頭の悪いバグのオンパレード

結論：頭の悪い上司には好かれるな

>>146
９割のBUGがモデリングに棲むなら、やっぱり重要じゃん

型に付ける属性ってここまでどんなのが出たかな。

nullable
role,unit,
range (これは静的にチェックできないよな。リテラル数代入以外)
demension

こんなとこか。roleがいまいちピンと来ないけど。

しかし、オブジェクト指向っぽい型（クラス）に適用できそうなのってnullable位だな。

>>140
「ひまわり」とか「なでしこ」で書いたらこのスレでは
話が通りやすいと思う。

オブジェクトの属性付加問題(雪::色=白い)ではPrologだと
意味を考察することなく、ある程度形式的記述が可能なので
若干の優位性はあるかもしれない。

>>134
スモールビジネスで総務畑にいる人が直接プログラミングすれば
バグなんて、でないｗ

Small is beuatiful!

>>144
やはり、仕様記述言語ですか。この話題はそこから発した流れなのですね。

ただ、コストが問題だな。ほとんどが教育コストだが。

>>152
やっぱりそこに落ち着くんだな
で、こんどは仕様記述言語の設計書が必要になって仕様記述言語記述言語ができると

>>153
仕様記述言語自身で仕様記述言語を記述するから問題無いよ。

制約条件を記述するだけで済む言語が欲しいね。
条件に矛盾が発生したり、一意に動作が決定できないような場合は
エラーを返してくれるの。

>>155
NP完全な問題だろそれ

制約条件て、制約条件自体でプログラムを書く手法があるくらいだよ。
http://www.constraint.org/constraint_org.htm

私の知っているバグはExceptionが発生して
飛ばされた先で適切なルーチンを通らず、
Defaultで通過してしまうというケースから
起こったものが多かった。
一番単純なケースはエラーコードの誤り。
こういったケースでは強い型付け云々は
全く無力で、やはり仕様記述の問題だと
思う。
要求者が仕様記述言語で書いてくれる訳では
ないだろうから、やはり、日本語解釈の問題から

おんな::色=赤い 的な誤謬はさけられない。

この場合喩を含んでいるから、仕様記述としては
適切でないといえるが、多かれ少なかれこの
ような問題は発生する。>>118 -> >>115 のような
単純な写像が成立するためには、仕様記述以前の
要求段階でのモデリングはやはり重要と考えるが、
どんなものだろう。

>158
Javaのthrowsじゃダメなの？ Java使ったこと無いから細かい事は知らんけど。

> 一番単純なケースはエラーコードの誤り。
> こういったケースでは強い型付け云々は
> 全く無力で、

そんなことはない。
エラーコードを Enum型にすれば、間違って不正なコード
を返すケースや、コードを受け取る側で返されるはずの
コード全ての処理が入っているかのチェックができるよう
になるので、バグは "0" にならないけどバグを出しにく
くすることができる。

ただデメリットとして、エラーコードを増やしたりすると
まじめにエラーチェックしているプログラムほど修正個所
が多くなるので全体として非常に大変なことになり勝ち。

>>160
私の対象にしたのが、10年くらい前の小型汎用機での事務計算システムで
開発言語はCOBOLというケースだから、現在と事情が違うかも知れない。
エラーコードについては私の書き方が悪かった。正しいエラーコード
たとえば、404を返さず、304を複数のケースに返してしまう、くらいの意味。
COBOLの場合、構造体は例の明示的なREC定義だがら、構造体の型の不整合に
よるエラーというのは起こり難い。エラーが起こるのは引数として
情報(ほとんどが××区分)がそもそも不足している場合。
if文の中にエラーがあるというケースよりもこちらの方が多かった。
これはすなわち、仕様かそれ以前の問題で、プログラミングではどうにも
ならない、と言うような事です。

>>161
もちろんプログラムでどうにもならないケースがあるの
は承知しているが、このスレは「バグを出しにくくする
ための言語仕様を考えるスレ」だから。

UML とかは、ちょっとスレ違いかと。

ここのところこのスレの流れは
・強い型付とそのチェック強化でバグを減らす
・仕様段階でのバグの除去がやはり重要
という二論に分化していて、私の書いたのは後の方の立場。

仕様記述言語で仕様を書かせ(書いてもらう)、それを
可能な段階まで直接コード化する。コードが生成できる
範囲を少しづつ下方に広げていく。こういう戦略になる。

その仕様記述言語とやらを、ちょっと分かりやすい例として書いてくれや。

日本語プログラミングって言われると私はMindを思い出す訳だが

うちのJavaのプロジェクトの見本のコードにセッションの値にnullや期待したクラス以外が
セットされている場合は新規にクラスをつくってセットするというのがある

しかも、それが期待したオブジェクトが入ってない場合は１００％障害の場所に・・・
警告出すか、ありえないんだからそんな処理いれるなよって思ったよ

他にも変数の宣言はメソッドの入り口でまとめてしてしまうとか
スコープを意識しないロジックも満載

私は従順無能プログラマーで意図が読めないので
テスト通ったらせっせと直して再テストして出してますよ、えぇ

リファクタリングは無関係なんでしょうかね

>>166
ここはキミの愚痴を書くスレッドじゃないんだよ。
明らかにスレ違いだ。そんなことも分からないようでは、
キミの愚痴もどこまで信憑性があるか怪しいモノだね。

マ板にそういう愚痴スレは存在してるから
そこでグチグチ言ってろ。な。

>>164
無責任で申し訳ないが、私は全然知らない。
15年くらい前にZの解説書の翻訳が出て、
見よう見まねで書いたことはある。元が
平らな文の記述なら、結構いける気がしたが、
やはり、Prologで直接書いた方が、たとえ
思いつきの部分が入り込んでしまったとしても、
生産性が高いので、採用しなかった。
題名を忘れたその本を探したのだが、昨日は
見つからなかった。見つかったら、サンプルを
書いて見る。

>>169
全然知らないのに「仕様記述言語で仕様を書かせるとバグが減る」とか主張してんのか？
頭おかしーだろ。

バグが減るかどうか解らない。
そこから抜本的に考えないとどうにも
ならないバグの方が多いといっているだけ。

トップダウンにシステムの開発言語を
含むシステムの再構築が必要なはずで
そのプログラムレベルのトップは
仕様記述言語と呼ばれる物がくるべき
だろうと思う。

私なら、全部Prologで済ますがね。

IDEの中に1ツールとして組み込まれて、仕様記述言語なんて
呼ばれなくても良い。しかし、言語で組み立てられる仕様と
コードとの仲立ちをするのは、
述語論理と集合論以外に私は思いつかない。
現に、集合論と関係代数、関係論理を基礎とする
RDB+SQLの登場、普及によってバグは確実に減ったと思う。
この場合、仕様記述言語の部分を、データベースが吸収
したのだと思う。こういう転回は今後も起こるし、そんなに
大袈裟に考えるべき事ではない。

無限にあるデータ構造を、表ただひとつに縛るという制約だな。
ならばプログラムも…

ここは「バグの出にくい言語仕様を考える」スレであって
「バグの出にくいシステム構築を考える」スレではない
そういった精細さを欠いた人間には
仕様記述言語を与えたところで無駄であろう

抜本的に、「バグの出にくい言語仕様を考える」ことは
「バグの出にくい言語仕様を考える」ことに含まれないのかな？

要するに、仕様記述言語を強調するのは
バグの出にくい言語を述語論理に基づく
言語と見てるわけだよ。
全部そういう言語に取っ替えようと
いうのは途方もない事だから、確実に
取り入れられて、かつ、現実にバグを
減らす事に寄与する仕様記述の部分を
強調しているだけ。

オブジェクト指向は言語仕様ではない？

具体的に行こう。

仕様記述言語仕様記述言語言ってる奴、お前が思う仕様記述言語風に
○×ゲームの仕様きってみれ。

誰かバグの発生はある有界値までしか減らせない事を証明しろ

真の要求というのがどこかにあったとして、それは記述可能なのか？

仕様のバグと要求の漏れは区別しろよ

>>174
いいなそれ。誰か「バグの出にくいシステム構築を考える」スレを立ててください。

>>178
仕様記述言語について語っていた人とは別人ですが、○×ゲームってどんなゲームですか？

>>182
三目並べならわかるか？

もうねプログラミングなんてね最終手段なわけよ

バグかどうかは仕様書に沿ってるかどうか

だからバグかどうかなんていうのは　言語仕様　に左右されないわけ

言語云々よりもっと高次の段階でバグが発見されて、
低次の言語云々の部分に完全に翻訳できれば何でもかまわないわけなのでね

というかそれは言語仕様でどうにかなるもんじゃない

夢見すぎ

もっと能力無いのを自覚しろよ

>>178
だから意味無いじゃんって事で書いたんだが
その辺も仕様記述言語で書いてあった方が良いのか？

TicTacToeなら知ってる

>>185
良い。グダグタ言ってないで具体的にやれ。

>>184
お前の能力では完璧な仕様書なんか出来ないだろ。

というかそれは人間にどうにかできるものではない。

夢見すぎ

もっと能力無いの自覚しろよ

えっとね、仕様記述言語の話なんだけど
コンパイラ分野の長い研究の成果で、文法などの「形式」に関しては、ある程度体系化がなされているんだけど
「意味」を表すための研究というのは、「それをやるのは非常に難しい」という一定の結論が出ているんだよね…
(完全に不可能、とは言わないけど解決できていない問題があまりにも多い)
そのために、何処かで曖昧な記述しかできない自然言語で、現在でも仕様の記述が行われているんだけど

> 仕様段階でのバグの除去がやはり重要
自分なりにこの意図を汲み出してみると、これは「コンセプトの完全性」の問題を話している様に見える

コンセプトが正しくなかった＞アルゴリズムが無駄に複雑になった＞結果バグが増えた

なら相関関係がないわけじゃないけど、基本的にはバグの話とはズレている様に見えるかなぁ

「バグの出にくい言語仕様を考える」というコンテキストからは
当然その「バグ」は「実装段階のバグ」であることが暗示されているわけで
それ以外のバグに関する論は基本的にスレ違いであると思われ

通常バグは「出る」ものではなく、無意識で「埋め込まれる」もの。

バグが「出にくい」言語仕様と言った場合、
「不幸にも埋め込まれてしまったバグが顕在化しないための方策」
でもあるのだろうかという話にならなければならない。

ひとつやふたつバグがあっても正常に動き続けるような堅牢さが必要ってことだな

何言ってんだ、エラーを吐くからバグだと言われるんだ。
エラー表示の無いコンパイラとエラー表示のない製品を作ってしまえ！

>>193
Microsoft
富士通
三菱

コンパイラ（プログラミング言語→機械語への翻訳過程）が原因で起こるバグは少ない。
ほとんどのバグは仕様→プログラミング言語への翻訳過程によって起こる。
この翻訳過程を自動化しようという試みもあるが、技術的に困難。
そこでだな、逆転の発想でプログラムから仕様を自動生成すれば

バグの原因のほとんどは、勝手な思いこみ・決め付け。
実はこういう場合がありました、というところでバグが出る。
この辺をどうにかしる。

バグの原因のほとんどは、勝手な思いこみ・決め付け。
実はこういう場合がありました、というところでバグが出る。

という勝手な思いこみ・決め付けをなんとかしる。

でも鶏と卵じゃないけれど、仕様上の不具合を見つける最も効果的な方法は、
実際にプログラムを動かしてみることかもしれない。

「見つける」為の効果的な方法は、確かにそれで正しい
んだけど、残念なことにそれでは納期に間に合わないわ
けで…。orz

>>196
マ向け

「仕様」上の不具合を見つける最も効果的な方法は、実際にリリースしてみることじゃないかなぁ。
問題がありゃお客が怒ってくるでしょ。使いもんにならん！って。
そうすりゃしようを考えた奴のケツにも火がつくわけで、効果的だと思うけどね。

JavaコンパイラにCheckStyleとFindBugsを組み込めば解決じゃん

プログラムを作っている内に何かを忘れた場合にもある程度対処できる
言語にすればいいんじゃないだろうか。メモリ開放忘れとか。

但し忘れ過ぎたら意味ないのでまずプログラマーの脳の働きを向上させる
必要がある。ということでまずは任天堂DSの(以下略)

>>200

そんなことはない。

例えば例外機構は、例外処理を強要することで、
「この関数は必ず成功する」という決めつけを排除している。

言語で出来ることは色々ありそうだ。

>>201
それがアジャイルとかプロトタイピングでしょ。

でも、
このスレで言っている仕様上の不備って言うのは、使い勝手とかじゃなくて、
微妙に曖昧なところがあったり、微妙な考慮不足があって、
実際にコードに落すと端っこと端っこで矛盾＞バグ発生、っていうモノでしょ。

一日に何回も発生するエラーはたいしたことない。すぐに発見可能だから。
ヤヴァイのは「ごく稀にしか起こらない重大なエラー」

>>206
C言語で自動変数初期化忘れとか。ありますねえ。
コンパイラもそのままだと何の警告も出さなかったりして。

いまどきの言語は初期化忘れはコンパイルエラーですが。

初期化し忘れたのが検知出来るなら、いい具合に初期化してくれればいいのに。
エラーだけ出すなんて、怠慢だな。

っつーか、ココで皆が考えているバグってどれ？
*1 仕様から考えてちょっとおかしい動作をすること
*2 システムから考えてちょっとこれは違うんじゃない？って感じ
*3 書いたとおりに動かない環境

正直、*1 *2は言語じゃどうしようもないと思う。
かといって*3について述べているわけじゃなさそうだし…

実装したものが仕様どおりに動かないこと、じゃね？
仕様そのものがおかしいのや
実装していないものが仕様どおりに動かないのは
ここでいう「言語」には関係ないだろし

>>205
「使いもんにならん！」ってのは「使い勝手」のことには限らんがな。
帳票と画面の矛盾とか、サブシステムをまたいだ矛盾とか、そういうのさ。

>>195 逆転の発想でプログラムから仕様を自動生成すれば

リバースエンジニアリングということになるが、
双方向性の言語仕様ってのは無理なのかな。

>209
初期値が0とかとは限らないから、勝手に初期化されるよりはエラーの方がいいだろ。

>>214
0で動いちゃう方がバグになりそう。

どうせ初期化しなきゃいけないなら、0で初期値をとっておいた方が楽

アホかい。

どっちみちエラーなんだから、どうでもいいが、
暗黙に初期値はゼロって事でワーニングで済ませてもらいたいもんだ。

.NETは初期値0なわけだが、
「変数の初期値は0で警告は無視する」というやつに対しては、
確かにバグが減っている。
決め付けの排除ではなく、決め付けの通りに動いているわけだな。

>>196のいう勝手な決めつけを排除する為に、
やはり型情報にいろいろ追加する機能があると良いのでは？

C++のtemplateは裏技チックだからもうちょっと素直な奴。

という勝手な思いこみ・決め付けをなんとかしる。

220なんかの意見もそうだけど
「プログラマの意図しない動作」をするのがバグなら、出来るだけ人間の思考にすり寄った形でプログラム言語を作成してしまうのが、バグ排除の究極の形の一つと言えるんじゃないかな。

型情報の強化というのは俺も賛成、色々理由はあるけど
「何より、現行技術でやりやすい」
というのが一番かな

>>220
型情報に何かを付加する方法の一つに、インタフェイスを作ってしまうという方法があるかと
インタフェイスはデータの見方を変える手段として使えるわけで・・・

「人間の思考」は間違うことがあるからな

人間の思考そのものにBUGがあるんだよな実際には・・・。
組んでみて、動かしてみて、初めて、あ・・・ってな感じ。

>>223
JDK5.0 にそれっぽい仕様があったような・・・？

>>224
そうそう。設計自体がそもそもバグだったりっていうのはたまにある。

そうだね。仕様どおりに作ったのに、仕様そのものがクソだったとか。

やはり良い仕様を考えるには、センスとかって必要だと思う？

優れた仕様を考えるにはセンスが必要だが、それは凡人には難しい。
良い仕様を考えるのに必要なのは、経験と内省力。

バグをなくすには言語仕様を極力軽くすべきじゃないかなぁ−−−→COBOLになりました。

まぁCOBOLでもまだ重いと思うけどね。

う〜ん、仕様の失敗というのはこのスレの趣旨からはずれるようだから、あまり続けたくないんだけど…

良いコンセプトを作る前から理解している、というのはソフトウェア以外でも、全工学分野で難しい問題で、実際の所それは作ってみないと分からないんだよね…。

プログラムの場合、プロトタイプを行うことでその正しさをかなり検証することが出来る。

実際の所、センスなんていう個々人の才能に強く依存するモノを当てにしないためには、これまでの設計を収集、分析して経験的事実を取り出していかないといけないんだけど、まだまだ時代がそれをまとめ終えるところまで進んでいないんだよね…。

そういえば誰かが、センスとは捨てる能力だって言っていたような気がするな。

Haskellやっとけ。

http://d.hatena.ne.jp/tanakh/20051001

>>223
インタフェイスって？Javaのinterfaceみたいの？
それじゃあ、上の方に出てきた
null代入禁止とか、次元解析とか、そういう制約は書けなそうだけど。

>>232
収納名人だろ

>>234
インターフェースじゃなくてアノテーションの事言いたいんだろ
クラスというかバイナリに付加できるメタデータの事だな

たとえば、EJB3.0じゃセッションビーンになる為にはPOJOで作って
"@Session"をクラス定義に付加すればよいって感じ

アノテーションは宣言だけじゃなくて何処にでも掛けるから
後でコード挿入したい場所に書いておけば簡単にDIが実現できるとか
特定のデバッガ上で意味を持つアノテーションを実現したりも出来る

そういうことか。
しかしそれは動的なチェックだろ。バグが出てから調べやすいだけだなぁ。
それを静的にチェック出来てコンパイル時に排除できるというのが>>220。

>>237
ソースに記述できるんだからやろうと思えば静的にチェックできるよ
Javaに関しちゃ静的・動的で２分しちゃう意味は無い

おおホントだ、知らんかった。ﾊｽﾞｶｼ…。

>>230
やはり、破壊代入を排除する所まで行かないと。

破壊代入を排除したらどれくらいバグが減るの？
それとオブジェクト指向と相性が悪そう。

まずは最低限あった方がよさそうな機能を考えればいいんじゃないだろうか。

1. 文字列型は欲しい。

2. ポインタは極力隠れていた方がいい。core dump とか OS の機能をそのまま
使わずに自分でエラー出してどこが悪いかある程度出して欲しい。

3. 再帰は楽に書ける方がいい。しかしすぐなくなるスタックを使わんでくれ。

4. ていうか自動変数にスタックを使わないで欲しい。使う必要ないよね?

5. バッファオーバーフローの検知。Cのように放置して破壊や乗っ取りが
できてしまうのは嫌。

6. メモリは参照なくなったら勝手に開放されて欲しい。開放後にアクセス
しようとしたらエラー出て欲しい。

>242
C/C++以外の言語使ったこと無いのか？
JavaでもPHPでもいいからとりあえず使ってみろ。
バッファオーバーフローなんて文字列型がちゃんとある言語ならまず起きないだろ。
参照無くなって開放されたものに、後からどうやってアクセスするんだ？

最低限すぎ。今時みんな常識。
つうか3が意味不明。末尾再帰の最適化を言ってるのか？

「再起はフローの解析を行ってできる限りループに展開してくれ」って事じゃない？
Lispなんかじゃあって当たり前の位の物だな
末尾再起をループに展開するぐらいは最新のCコンパイラでもやってくれそうだが
其処の所どう？

末尾再帰じゃない再帰をどうやってループ展開すんの？

>>246
http://d.hatena.ne.jp/yaneurao/20051008
http://d.hatena.ne.jp/yaneurao/20051025

結局スタックが要るんじゃん。
末尾再帰じゃない再帰をループ展開する必要なし。

>>248
問題の次元を落とし込むことができるから、
メモリをふんだんに使えて再帰以外の実装があまりにも複雑なら再帰にすべき
・・といっても、再帰なんて気持悪くてあんまりしないんだけどな。
そんな複雑な問題、汎用PCでやらんし

>>242
そういう言語仕様が望みだというならよくわかるけど、
バグの発生とは関係ない項目が多いのはなぜ。

>>249
248では「再帰を使うな」とは主張していないんだが。
なぜそんなレスを？

なんか難しいので
再帰は、末尾再帰しか許さない
って仕様でイインジャネ？

どちらにしろ、ミニマムな機能からアプローチをかけるのはあまり良い考えではなさそうだな…

明らかに無駄な文法を刈り取るのは有効に見えるんだが…
(個人的にはperlのlocal宣言とシンタックスシュガーの多くかな)

やっぱり、バグ削減のためにはどのような文法を継ぎ足すかを考えた方が全体的に近道に見えるなぁ

>>252
スタックオーバーフローの懸念の問題は
バグとは関係ないと思う。それこそ、
仕様の問題。

>>238
嘘つき。
コンパイル時制約なんて書けない。と思ったら、
静的とは書いてるけどコンパイル時とは書いてないな…。

たしかに、コンパイル後に使うチェックツールは作れるけど、
そんなんよっぽどのスキモンしかやらんだろ。

それ以前に、このスレ的にアノテーションじゃ全然ダメ、お話にならない。

情報がその場限りで、型情報と共に伝搬して型体系チェックができないじゃないか。
これは、チェックツールじゃ無理。コンパイラじゃないと。次元解析とかできない。

メソッドの引数に、必要とする要求アノテーションを書けるようになればいいのかな？
ただし次元解析には、数値演算子を廃止してメソッドで作り直さんといかんが。

「バグは発見できるからこそバグ」だし「対処している例外はバグではない」なわけだ

例えば手続き型言語の代表例なC言語で、
double foo(double p,double q){ return p/q; }
等というCのコードがあっても、「0除算例外が発生しそうだから、これはバグの潜むコード」とみなしてはならない。
「foo()の呼び出し元で、fooの第二実引数が0に成りうるなら、これはバグの潜むコード」とみなさなければならないのだ。

つまり、呼び出し元(=親)と呼び出し先(=子)に見れる関係の時、
実行される順序に従って、例外が適切に処理されていればそれは「バグではない」といえる。
--------
さーて、ここまで書いたけど、メチャクチャなこと書いてるよな。
C++で例外機構を取り入れて
int main(){
try{
MainHogeClass p;
p.Run();
}catch(...){ std::cout << "例外発生したよー"; }
}
なんて書くと、「(標準例外に関しては)バグの無いプログラムの出来上がり」ってほざかれるわけだ。
かといって、
int main{
double p,q;
try{
p=10;
cout << "実数を入力してください：";
cin >> q;
cout << p/q;
}catch(...){ cout << "0除算か、他の例外が発生しました"; }
}
とかかれて、「バグの無いプログラムの出来上がり」て言われても。
そうだね、っていえると思う…さーて、バグって何でしょーねぇ

>>258のfooの例なら定義レベルでqが0をとらない事が定義できれば良いんじゃないのか？
そうでなければ潜在的に0割除算で例外の発生する可能性のある不安定なコードになる

>>258
それだとしても意味はデカい。
例外がなければ０を渡せないという仕様がどこにもなく、ソース見ても問題を見付けづらいが、
馬鹿な例外処理は一目で分かり、書いた奴を減給なり懲戒にすることが出来る。

GNUのライブラリの gets() のマニュアルページのバグの項目に
gets() は決して使ってはならない、と書いてある。w

まあ、思想の問題でもあるが、C言語の標準ライブラリの仕様も
なんか間抜けな感じはする。

>>261
過去の互換性

getsの芸人、今何してるんだろう？

実証重視な(科学的な)視点から見れば、「バグの出にくい言語仕様」の前提に"事実"が発見されていなければならない。

この場合の事実、つまりバグについて私の考えを述べる
・バグとは
　・エンドユーザ側から見れば
　　・バグとは「使い勝手の悪さや、実現できるはずなのに実現できないこと」がバグとして受け止められる
　・プログラマ側から見れば
　　・バグとは「思ったとおりに動かない」がバグとして受け止められる(…orz)
　・また、エンドユーザ側とプログラマ側の隔たりを見れば
　　・バグとは「要求が実現されていないこと」である
　・これ以外のバグの種類は存在しない。
　　↑このあたりが不十分かな…まるで悪魔の証明を、証明してしまったかのような傲慢な言葉ですな　('Ａ｀)
　　　　　//ここまで同意？ <Yes・No>

　・ここで次の用語を定義する
　　<エンドユーザの使い勝手> ⇔ Spec(EU)、
　　<プログラマの思った通り> ⇔ Spec(Pgr)
　　<要求が実現されていないこと> ⇔ Gap(Spec(EU),Spec(Pgr))≠φ
　　とする(意味を定義しているのではなく、書くのが面倒なので記号に書き換えているだけ、に注意)

・バグの取り除き方について
　type1. Spec(EU)が悪い
　　→使い勝手を向上させることでこの種の「バグ」は取り除くことが出来るか？
　type2. Spec(Pgr)に動かない
　　→プログラマに「プログラムは思ったとおりに動かない」ことを認知させることでこの種の「バグ」は取り除くことが(ry？
　type3. Gap(Spec(EU),Spec(Pgr))≠φがある
　　→エンドユーザとプログラマ間で「要求と実現の差」を認知することでこの種の「バグ」は取り除(ry？
--------
でもね、「記号で議論できるほど、バグは浅い問題じゃない」って言われると思うんだ　　　(　´Д｀)・・・

というか書きすぎです、目が疲れると思うので、スル(ry

>　type2. Spec(Pgr)に動かない
>　　→プログラマに「プログラムは思ったとおりに動かない」ことを認知させることでこの種の「バグ」は取り除くことが(ry？
これはいったい、何がどう解決してますか？

>>265
まず「思ったとおりに動かないこと」＝「バグ」という認知がある。
そこで、認知を摩り替えて
「思ったとおりに動かないこと」≠「バグ」という認知にするわけだ。

ほら、土台が崩れて、バグじゃなくな(ry

>>258
ちょっと目が覚めた。いいこと言ってくれた。

>>258
それ例はちょっと気をつけろ。
俺はWindowsには詳しいけどLinuxには詳しくなくて、
俺とは逆にLinuxには詳しいけどWindowsには詳しくないってヤツと例外処理について話してて
全然話が噛み合わねぇなぁと思ってたら、どうもWindowsでは 0 除算やろうがぬるぽをやろうが
catch(...)でまとめて拾えるけど、Linuxではどうも自分で投げた例外じゃないと拾えんらしい。

道具として使うものがそんなに危ないものであるのは他には類を見ないんではないかと思う。
そして、初心者が簡単に手がでるし、実験環境も実機である場合が多い。

バグを語るなら、ロジックバグをどうにかしないといけないと思うんだけど。
そっちはあんま重要ではないのかねぇ？？

全ての関数に対して個別のunittestを強要

>>264
ココで話しているユーザーにとってのバグは
「使い勝手の悪さや、実現できるはずなのに実現できないこと」
だけど、これは「ユーザビリティが低い」であって、バグとして扱うのは異論があるなぁ

バグっていうのは、特に何もしていないのにアプリケーションが強制終了したり、Exelのセルに入れた計算で、あらぬ結果が返ってきたりだから
「プログラムが意図したとおりに動かない事」
で扱っていきたいな

ユーザビリティって相対的な評価なんだよね
所謂ある・無しで分かる障害とは違うんだとな

バグと障害は重なる所はあるがバグ＝障害だって事は何処にも定められてないな

>>268
そりゃ言語やツールによって違うのでは?

やりたいこととは直接てきに関係ない
コードを沢山書かなきゃいけない言語だと
バグが入り込みやすいし、

>>274
そんなことあるか？もう少し具体的な話というか例を

例によって遅レスだが、

　>>28はAdaでできる。(戻り値だけが異なるオーバーロードが可能)

>>276
Adaって日本にも使っている人いるのかな
ひょっとしてアメリカ国防総省の中の人ですか？

>>277
Adaスレにおいで、おいで

初めてAdaって書かれたの読んだとき、普通に「あだ」って言ったおれ・・

Adaは既に２回挫折してる
めんどくさいんじゃ

Adaってそんなにスゴいのか？
だったらなんでこんなに普及してないんだ？

D言語が普及してないのと同じでライブラリが少ない

他の言語ではよきに計らえが出来るところを厳密に定めなくちゃならないから

結局、「使える言語」になるためには、周辺環境が重要なんだな

それがAda良いところなんだけどね
バグを減らすそうと考えて、割に合わないくらい座業効率下がったら意味無いぜぇ、ってカンジで

＞＞周辺環境
個人的には周辺環境無しでは言語の評価を行えない時代なんだから
なんらかのIDEとの親和機能を、言語の文法自体に仕込んでも良いんじゃないかと常々思っている。
コンパイラにおもねるだけじゃなくって、IDEとも仲良く

ライブラリが少ないのは、その言語が普及していないからではないのか？

>>296
普及すれば開発者が増えて良いライブラリが出てくる、というこのジレンマ

基本的には、正しいコンセプトとそれを良く表した基幹部分の実装があれば、次第に人は集まる、時間はかかるけど…orz

それを加速するためには、その技術の良さを理解する先見性のあるリーダーと、それを実行できるだけの組織力のサポートが必要かと

D言語の場合アーリーアダプター層には浸透したと言えるから、ここからサポートしてくれる組織としては、IBMあたりが「○百万ドル相当のライブラリ」とかを作って投下してくれれば、一般レベルのプログラマへの切り口になると思う。

スレ違いスマソ

こういう言語って高度な安全性が求められる特殊なところに使われるわけだろうから、多少のコストは仕方ないのかも。
仕様書作成→プログラム構成、分担決定→コード作成（メイン）→宣言などを整理→デバッグ（コード作成者）
として、宣言とか面倒なところは低賃金者にやらせる。

宣言とか面倒なところはプログラムを書く

プログラミングてしないけど、初めて書く変数が出たら知らせたり、外側のスコープと同じ変数名
を書いたら知らせたり、グローバル変数に書き込もうとしたら警告したりとかはエディタで出来ますか？

>>290
ターゲット言語決まってないのに「グローバル変数」とか「外側のスコープ」とか言うなや　('Ａ｀)ﾉｼ

フレームワークや制約なんかをバリバリに規定できれば
１人が気をつけるだけでその他大勢はバグから解放される…ってのも
バグの出にくい言語に入らないかにゃ

>>292
そんな中途半端なこと言わないで、
再現なくデバッグすれば最終的にバグの無いプログラムできる、
でいいじゃん
…どっちにしろ、実現不可能だけどな。

>>290
>初めて書く変数が出たら知らせたり
これはうざい。変な使い回しをして余計にバグが出そう。
>外側のスコープと同じ変数名を書いたら知らせたり
これはまぁよし。
>グローバル変数に書き込もうとしたら警告したり
これもうざい。その上グローバル変数を定義できない言語や環境もかなりある。

書く気無かったけど294があまりにつまらなかったので…

可能不可能の問題で言うなら「可能」ですね。そりゃあコンパイラが翻訳可能なのですから。
最近はCPUパワーでゴリゴリが許される時代ですから、解析に時間かかかるもないでしょー。

で、回答なんだけど、実際それを行うエディタの実装は知らない
可能性があるとしたらemacsくらいかね

>>290
グローバル変数とローカル変数を別の色で色分けしたらいいんじゃね?

292はちょっと良いこと言ったかな
複雑なルールを徹底できているかのチェックツールは作成可能と見える。

実際の場合は、ルールが徹底されているかのチェッカを書くのは、そこまで苦労しないでも可能なハズ。

>>297
大前提の「バグとは何か？」をないがしろにして何を賛同する気なのかと(ry

>>292
まさにMozillaですな

コーディングスタイルガイド
http://www.mozilla-japan.org/hacking/mozilla-style-guide.html
規則と TIPS
http://www.mozilla-japan.org/hacking/reviewers.html#rules-and-tips
C++ 移植性ガイド
http://www.mozilla-japan.org/hacking/portable-cpp.html

>>299
じゃあ、Mozillaはバグが無くなったかというとそういうわけではないよな
規模の割には少ないとは思うが

同じ規模の市販ソフトと比べたら多くね？

同じ場所で同じ時間帯に同じレベルの人たちが作るのが、一番BUGが少ないって事だろ？

>>302
コミュニケーションの問題に起因するバグが減るだけでバグの総数が減るかどうかは定かではない

>>303
そりゃ、減ってるって事だよ。

>>303
その分ほかのバグが増えるわけではないからねぇ
減ってるとみなしていいと思うよ

>>303
小説を書くのと一緒
一人だとバグは少ないが
複数の人が勝手にエピソードを書いていくと
矛盾点が出てくるだろ

ちゃんとインターフェイス決めて構造化すれば、
とりあえず表現としてはだいじょうぶ
どんな風に動くかはチーフが・・・

普通の開発だな

作家が一人で
編集者（バグ発見）、アシスタント（言われたとおり作るプログラマ）
ならうまくいくんだよな・・・
問題は作家のレベルのものしか作れないから
こまめに話し合いが出来るなら複数作家もありなんだけどね・・・

>>301
MSと比べてるんだろうけど
仕事としてやってるんだし
作業時間ｘ人数とバグを比べたら
同じくらいだと思われ

えええっ
MSと比べちゃ可哀想だよ。
相手は、どんなバグでもある時期を超えたら全部仕様になるんだぜ？

>>309
・同じ時間でも仕事中は手抜きをして趣味は一生懸命やるのが人間だから
モジラ＞M$
・人は趣味でやってる人のレベルは幅広いが仕事人なら一定レベル以上
一定レベル以下
書いてて結論分からなくなったｗ

バカだからさ

>>307
提案者の意図は、ツールで検知しやすくする事で、コストを下げて頻繁にチェック出来る要にすることじゃないかな
機械で容易に出来ることを人間様が手法や努力でカバーするなんて、正直格好悪いし

>>313
その意見自体は正しいけど
具体的な例とかあるといいんだけど・・・

オープンソースなプロジェクトだと「無能な努力家｣を排除することが難しいんじゃないかと思った

選民して専用の掲示板やMLでやればいいじゃん
無能な人には勝手に亜種を作らせておけ

>>316
で、一般人には使いにくいアレな物が出来て商用のBuggyな物で良いやという事になる

>>316
それは選民して、そいつらを隔離するということでつね

一般人はバグとかには無頓着だからな・・・
命が関わる病院や保険ですら
よく調べず適当に選ぶし・・・

>>307,313
普通の静的言語ならインタフェースは明示化されている。名前も引数の型も返値の型も。
あとは、いろんな条件や単位のような情報をそこに埋め込めば…。

>>315
そういう人はコミッターになれないから無問題。

>>320
> いろんな条件や単位のような情報をそこに埋め込めば…。
C#やVB.NETのattribute節みたいだな

.NETの属性って、コンパイラに対する指示なり制約を書けるの？
Javaのはダメみたいだけど。

>>322
一部の属性なら考慮してくれる。ConditionalAttribute なんかは正にそれ。#if 〜 #endif の高級版みたいな。
ただ、C# でも Java でも、オリジナルの属性なり注釈なりは、自作のツール類での処理になっちゃうかな〜と。

型情報について妄想吐いてみる。

//型に付くメタデータその１
annotation NonNull applies Object;　//nullはObjectじゃないからこれだけでOK。

//メソッド（関数）定義
String@[NonNull] fuga(String hoge@[NonNull]) {
　　処理。
}

String@[NonNull] foo; 　　　　　　//コンパイルエラー（暗黙の=null挿入の検知）
String@[NonNull] bar= "All your base are ";
String baz= "belong to us.";
String qux= null;
String quux = fuga(foo);
fuga(baz);　　　　　　　　　　　　　　//コンパイルエラー
String@[NonNull] corge = fuga(([NonNull])baz);
fuga(([NonNull])qux);　　　　　　　//実行時エラー

//メタデータなしのメソッド（関数）定義
String piyo() {
　　処理。
}

String grault = piyo();
String@[NonNull] garply = piyo(); //コンパイルエラー

//型に付くメタデータその２（パラメタあり）
annotation Unit(Enum) applies Number;
public enum Time { MILLISEC, SEC, MINUTE, HOUR }

//メソッド（関数）定義
int@[Unit(Time.SEC)] fuga(long@[Unit(Time.MILLISEC)] hoge) {
　　処理。
}

long a = ([Unit(Time.SEC)])12345678L;
long@[Unit(Time.SEC)] b = 12345678L; 　　　　　　　　　　　　　　　　//コンパイルエラー
int c = fuga( 12345678L );　　　　　　　　　　　　　　　　　　　　　　　　　//コンパイルエラー
int d = fuga( ([Unit(Time.MILLISEC)])12345678L );
int@[Unit(Time.SEC)] e = fuga( ([Unit(Time.MILLISEC)])12345678L );
int@[Unit(Time.HOUR)] f = fuga( ([Unit(Time.MILLISEC)])12345678L );　//コンパイルエラー


//型に付くメタデータその３（コンパイル時計算チェック）
annotation Dim(int) applies Number;

//メソッド（関数）定義
double@[Dim(n-1)] fuga(double@[Dim(n)] hoge) {
　　処理。
}

double@[Dim(1)] a = fuga( ([Dim(2)])123.45678 );
double@[Dim(1)] b = fuga( ([Dim(1)])123.45678 ); 　//コンパイルエラー
double@[Dim(1)] c = fuga( a ); 　　　　　　　　　　　　　//コンパイルエラー
double@[Dim(1)] d = fuga( ([Dim(2)])a ); 　　　　　　 //コンパイルエラー

もひとつ電波。かなり無理矢理だけど。

annotation HasNameAndLargerThan(int i) applies Map {
　　null != this.get("name");
　　i < (int)this.get("length");
}

これはconstなメソッドという概念（この例だとMap#get()）の存在が前提で、
実チェックはほとんど実行時。だけど宣言性はある。

//メソッド（関数）定義
void configure(Map@[HasNameAndLargerThanTen] conf) {
　　処理。
}

Map@[HasNameAndLargerThan(0)] m = new HashMap();//実行時エラー（コンパイル通っちゃう…）
List@[HasNameAndLargerThan(0)] l = new LinkedList();//コンパイルエラー
Map n = new HashMap();
configure(n);　　　　　　　　　　　　　　　　//コンパイルエラー
Map o = new HashMap();
o.put("name", "puge");
o.put("length", 1);
configure(([HasNameAndLargerThan(0)])o);
Map p = new HashMap();
o.put("name", "puge");
o.put("length", 1);
Map@[HasNameAndLargerThan(0)] q = ([HasNameAndLargerThan(0)])o;
configure(q);
Map@[HasNameAndLargerThan(123)] r = ([HasNameAndLargerThan(123)])o;//実行時エラー


…キャスト可否の定義も要りそうだな…。

面白い。構文はこんなのでどうか。（英語が変だけど）

annotation HasNameAndLargerThan(int len) about Map
{
　　boolean be()
　　{//適用可否。コンパイル時と実行時両方走る。
　　　　return null != about.get("name") && len < (int)about.get("length");
　　}

　　boolean implies(HasNameAndLargerThan other)
　　{//暗黙のキャスト可否。コンパイル時に走る。
　　　　return this.len <= other.len;
　　}

　　boolean canbe(HasNameAndLargerThan other)
　　{//明示キャスト可否。コンパイル時に走る。
　　　　return true;
　　}
}

まちがえた。一部訂正

　　boolean be()
　　{//適用可否。実行時に走る。
　　　　return null != about.get("name") && len < (int)about.get("length");
　　}

さらに間違い。（汗）

　　boolean canbe(Map other)
　　{//明示キャスト可否。コンパイル時に走る。
　　　　return true;
　　}

これ、引数や返り値だけじゃなく、レシーバについてもannotateしたいな。
PythonやCLOSみたいだと引数と同列なんだが。

やはり、これもAdaにあるん？＞Adaな人

♥

>>331
知る限り、Adaの文法にはメタプログラミング系はすっぱり無いよ。
良くてコンパイル時評価のassertぐらい。
組込み用途をカバーしないといけないしね。
ただ、代用になるかは知らんけどソース上やらなんやらの構文木やら型情報やらを扱うASISってライブラリが規格で既定されてる。

>>330
pythonみたいに必須だとうざいから、第一引数に予約語引数thisを明示してもよい、って文法にすればいいじゃん。

D言語にopCastがあるけど…

>>324-329,334 ←これって、何気にスゴいと思うんだけど。これがあれば、言語機能であるはずのenumや(Java程度の？)Genericsまでも、自分で作れる。

annotation DayOfWeek() about String { //言語機能enumに相当する定義
　　boolean be() {
　　　　return "SUN".equals(about) || "MON".equals(about) || "TUE".equals(以下略;
　　}
}
これで、静的に安全なEnumの出来上がり(定数定義もないと使い勝手がイマイチだけど)。
しかもただのenumに比べて、String[DayOfWeek] hoge(); ←こんなのがあったとき、print(hoge()); みたいにいきなり表示するとか、(この場合)Stringとして色々扱える。

//言語機能Genericsに相当する定義
annotation ElementType(Class t) about Container;//単に型パラメタの定義。
annotation Type(Class t) about Object { //オブジェクトが特定の型である事の定義
　　boolean be() { return t.isAssignableFrom(about.getClass()); }
}
interface List extends Container {//"Generics"の利用
Object@[Type(t)] get(List@[ElementType(t)] this, int index);
void set(List@[ElementType(t)] this, int index, Object@[Type(t)] newVar);
}

List@[ElementType(String.class)] strList = ([ElementType(String.class)]) new LinkedList();
String s = "aaaaa";
Object o = new Object();
Object os = "bbbbb";
strList.set(0, ([Type(String.class)])s);
strList.set(1, ([Type(String.class)])o); //←コンパイルエラー
strList.set(2, ([Type(String.class)])so);

こんな普通なら言語仕様に相当するものすら自分で作れるって事は、なんか相当いろいろスゴいことができる気がする。

>>335 opCastってキャストのオーバーロード？ それって静的なルールを定義できるの？実行時の処理だけじゃなくて。

opCastはC++で言えば型キャストoperator、単に型変換する関数が暗黙で呼ばれるだけ

static assertやstatic ifならあるけどそれで静的に何とかできないかなぁ@D言語

>>336
なんでもできるってのはそれだけバグの入り込む余地が増えるって事だぞ分かってるか？
”何もしなけりゃバグも出ない”これが一番重要

値の範囲や種類に加えて、値の変化の周期とかもチェック出来るといいかも。

>>340


おまえらなんだかpascal風になってきましたね

便利にしたいと思う一方で、機能を増やして
できることを多くしすぎると、使いこなせなくて
バグが出やすくなる罠

Adaか！

お前ら、馬鹿のひとつ覚えだな。
これがバグを増やすなんてある訳がないんだが。
全然わかってねぇんじゃねぇのか？

>>344
バカ確定しました　(・∀・)

Adaってバグが出やすいの？

>>345
お前まじで理解してないだろ

>>347
バーカ

>>347
バーカ

>>347
バーカ

>>347
バーカ

>>347
バーカ

>>347
バーカ

>>347
天才

>>348-353
必死だなｗｗｗｗ
さっさと死ねよクズ(ﾌﾟ

あのね、解説すると
これでできる事はコンパイルを厳しくするだけだよ。プログラム側処理にはなんら影響は及ぼさない。
アノテーション側のコーディングを間違えても、コンパイルできるできないがおかしくなるだけ。で、これがない場合より緩くなることはないんだからそれによるバグも有り得ない。

やっぱりバカなんじゃね？

やっぱりバカだな。

追い詰められて必死なクズって見苦しいね。

>>356
お前が言ってるのはインライン展開しまくってassertを評価するだけで十分なんだよ
っといってもコンパイラ毎に差異がでる(VCのインライン化は凄いけどbccはしょぼいみたいな〜)し、そんな処理系も無いけどな

>>360
バカでも分かるように具体的に頼む。
ただ適当な事言ってるだけならいいけど

どうみたってくやし紛れの世迷事だろｗ

だったら>>360説明してみてよ。
どうせ適当に知ってるふりしてただけなんだろう？

>>360はなかなか秀逸だな。
＞インライン展開しまくってassertを評価する
情報の付加も情報へのアクセス性の変更も出来ないインライン展開を、
表明の表現可能性向上と結びつけるという、プログラム言語への完全無理解を見せ付ける。
＞といってもコンパイラ毎に差異がでる
言語で定義したものが、コンパイラごとに解釈が違うという恐怖の世界を見せ付ける。
＞そんな処理系も無いけどな
ここまで大胆な妄想を吐いておいて、最後にすべてを無に帰す虚無の境地へと落とし込む。

そろそろ春か

>>324-329,334 って、よさそうだけど、コンパイラが生成コードを実行できないとだめだな。
Javaならjavacは良いけど、gjcは脂肪じゃね？

TemplateHaskellと言ってみるテスト

>>346
バグが出やすいと言うか馬鹿にはプログラムを作れなくなる

gjc?

>>366
Haskellよう知らんけど、それって普通の型安全なマクロと違うの？
コンパイラと直に会話する口がないと、
C++みたいな裏技チックなやり方が必要になりそうな気がするけど。

gcjだろ…。

>>324-329,334で、次元解析の作り方を考えてみたけど、
そもそも値をdoubleでやるのが間違いだな。次元パラメタを持ったクラスを作るべき。
その上で、演算メソッドに>>324-329,334のアノテーションを被せる。

>>369
TemplateHaskellは、コンパイル時に実行されるコードを書いて構文木を直接弄れるらしい。使ったことないけど。
例えばprintf形式の文字列とか自力でばらして書式化関数にしてしまえるらしい。

つThe Java Modeling Language (JML)
ttp://www.cs.iastate.edu/~leavens/JML/index.shtml

>>372
ということは、コンパイラと、エラーにする・しないの会話が出来ないとしたら、
それってやっぱり高級なマクロでは…。

>>373
ちゃんと読んでないけど、これってただのDbCの記法とは違うの？
機能としては実行時評価のassertionが出来るまでじゃない？
これはこれで悪くなさそうだけど、コンパイル時チェックによる静的な保証が得られる訳じゃ無いのでは？

>>374
＞コンパイラと、エラーにする・しないの会話が出来ないとしたら、
これはちょっと違うな。
型が吐けて、その適用についてOK/NGをコンパイラに言えないと、が正しいかな。
でもHaskellってデフォで多相型（だっけ？）とか、型の扱いがよくわからん。

みんなLISPでOK

マクロ展開でエラー検出
これ最強

あ、でも>>324-329,334って、結局subtypeを作ってるわけだから、
ある意味、素のHaskellに似てる？
ただし、値の実型じゃなくて、値空間のsubsetを作ってるわけだけどHaskellで出来たりするのかな。

Haskellで出来ることはLISPで出来る
LISP最強伝説ここに爆誕

>>376
Lispに静的型って普通なの？

Lispで出来ることは全てアセンブラで出来る。
アセンブラ最強伝説ここに（ｒｙ

＞Lispで出来ることは全てアセンブラで(ry

・・いや、実はそうでもないんだが。

＞値空間のsubsetを作ってるわけ

ここの味噌は、極めて恣意的にadhocなsubsetを作れるところ。
複素数-実数-有理数-整数-自然数とかそういうんじゃなくて。

LISPのシンボルやクオートはアセンブラではどうやっても無理
LISP最強伝説に揺ぎ無し

>>381
それって、

＞Haskellで出来ることはLISPで（ｒｙ
・・いや、実はそうでもないんだが。

ってことじゃないのかい？

>>383
田原「チューリングマシンって知ってる？」

>385
このネタでチュ(略を出してくるなんてナンセンスだな
メタレベルを１つ以上跨げばそんなのいくらでも可能だけど
そんなのその言語で出来ることにはならんでしょ

やっぱりLispが最強でしたか。
噂には聞いてたけど。

だったら静的型は…。

おいおい、「同じことが出来る」のが目標じゃなくて
「どれだけバグが出ない文法か？」が問題じゃないのか？

シンタックスを抜きにしちまうと、「最終的には機械語になるんだから」となって話が進まないぞ？


まぁ、バグが表記法程度で減るとは思えんがな

巷で噂の、Ruby厨から変節したLisp厨がこのスレにも降臨か。

LISPのマクロは確かに自分で文法と意味論まで定義できるから
その意味では最強っぽいんだけど、
型がデータにくっつくのが嫌、って人はいるかと。

バクのでにくい言語仕様と言っても限界がある。何故なら
人間にはバグがあるからだ。バクの木にはバクの実しかならない。どんなに
頑張っても人間とはバグを作ってしまうものなのだ。

ならばどうするか? 答えは簡単だ。バクを発見しやすい言語仕様を考えるのだ。

＞まぁ、バグが表記法程度で減るとは思えんがな

ならば、forもwhileもブロックスコープも廃止して、ifとgotoだけにしてみるかい？

＞人間にはバグがあるからだ。バクの木にはバクの実しかならない。
＞バクを発見しやすい言語仕様を考えるのだ。

だから、>>324-329,334 は人間に頼らずコンパイラが発見してくれる仕様を書いてるんでしょ。

関数型言語は？

>>381
すげーなリスプって。
吐き出すネイティブコードがアセンブリと対応しないってことだろ？

>>396
だからそれは >>384-386。
そして彼の妄想は>>388で潰えた。

>>393
じゃぁ構造化されたプログラムをコンパイラがアセンブラに落としたらバグが増えるか？

>>396
何を言っているんだ？
最初からアセンブラでjump系を生で使いまくりでゴリゴリ書いたプログラムと、
構造化言語からコンパイルしたプログラムで、どっちがバグが少ないと思う？

>>399
知るか
じゃあ聞くが、どれくらい少ないんだ？
どれほど増減してるんだ？
データ示せクソ

Haskellな人、>>377,382ってどうなん？

>>400
>>347-364を彷彿とさせるな、君は。

>>393
それが増えるわけがないから、
ifとgotoだけの言語じゃなくて、構造化言語を使ってバグを減らすわけだが。

ここは構造化プログラミングでオナヌーするスレですか？

>>399
開発者の技量とか開発期間の方がバグの多寡に関しては大きなファクターだな
ぶっちゃけ時間がたっぷりあればどちらでも変わらない

アセンブリ言語でもきちんとリファレンスなどを作ったりすればそれなりの規模でもちゃんと開発はできる

関数型言語がバグが少ないかどうかは知らんが
関数型言語と手続型言語とオブジェクト指向言語とは使う人間が違うから
関数型言語内でバグが減ってもその他のところでは減らん

>>399
他の言語で出来ることはすべてアセンブラで可能。まさに究極言語。
というわけで、おまえはアセンブラ以外使用禁止な。

コンパイラはアセンブラレベルでバグの警告をしてくれればいいのに

>>405
> ぶっちゃけ時間がたっぷりあればどちらでも変わらない

はぁ?

自由度が高い ≡ バグが検出しにくい
ステップ数が多い ≡ (全体の) バグ件数が多い

デバッグ続けたら、バグが最終的に "0" になると思って
る人なの？

> > ぶっちゃけ時間がたっぷりあればどちらでも変わらない
>
> はぁ?
>
> 自由度が高い ≡ バグが検出しにくい
> ステップ数が多い ≡ (全体の) バグ件数が多い
//ここまで

//−−−−−−−−−−
//ここからしたバグです
> デバッグ続けたら、バグが最終的に "0" になると思って
> る人なの？

> ぶっちゃけ時間がたっぷりあればどちらでも変わらない
1. 事実に対して仮定を持ち出す

ところで、文法うんぬん依然に、どんなバグを対象にしてるのかだれか書いてる？

>>412
言い出しっぺからどうぞ。

というかそういう話は当然出てはいるんだけどね。
>>347-364が解決（支援）してるのは、インターフェースの考慮漏れとかになるのかな。

デバッグ続けたらバグは最終的に０になるぞ
ただし０になったことを確かめる術はないが

>>414
>>411

>>414
> デバッグ続けたらバグは最終的に０になるぞ

証明してみな。

>>347-364が、インターフェースの考慮漏れとかを解決（支援）してるとは、深いなぁ。

>>416
1 検査する
2 バグが見つかる
3 バグを処理して1に戻る
この仮定をデバッグとする

視点を変えれば、運用段階も一種の検査。
バグが見つかればそれを処理し、（無限の時間内に）また運用を始める。
つまり永遠とバグをつぶ(ry

>>418
> 3 バグを処理して1に戻る

この時に、新規のバグが増えないことを証明せよ。

決まった運用じゃ絶対出ない休眠バグも有るわけだが。

>>419
関係ないのであなたがやってください

観測されないバグはバグじゃねぇよ
システムの寿命は有限なんだからよ

>>421
ん？

>>419 が証明できないと、>>418 は、>>416 の証明
にはならないよ。仮に無限の時間があって、>>420 の
問題がなかったとしてもね。

それともそんなことも理解できないのか？

て言うか、実務やってる奴なら肌で知ってると思うが。

>>422
あらあら、デバッグの時間は無限なのに寿命は有限なんだな。

なかなか、勝手な仮定だな。(w

て言うか、その理論なら動かさないプログラムはバグ "0"
だよな。

バグだらけのスレですね

>>324-329,334 は、値の変化はどうするんだろう。

例えば>>326なんか、
　Map@[HasNameAndLargerThan(0)] someMethod();
　void otherMethod(Map@[HasNameAndLargerThan(0)] m);
なんてのがあったとき、

　Map@[HasNameAndLargerThan(0)] m = someMethod();
　m.put("length", -1);
　otherMethod(m)

これがコンパイル通っちゃうのでは？
それとも、非constなメソッドは呼び出し禁止？それは厳しくないか？
それにそうしたらキャストしまくりになって、型にアノテーションを付けてる意味が半減する希ガス

それに、あるメソッドがそのオブジェクトについてconstかどうかってのは安定性が低いからな。
単純なプロパティ取得メソッドならともかく、込み入ったメソッドで、
後から、フィールド書き換えが必要になる・必要だったことが判明する、
なんてことはざらにある。

>>424
>て言うか、その理論なら動かさないプログラムはバグ "0"
そんなの当然だろ？

システムはあるインプットに適切なアウトプットを出すもの
インプットは有限なのは自明であり
最後に全てのインプットに適切なアウトプットを出してから
システムが破棄されるまでの間はバグ０であることは自明

バグ０であることは証明できんぞ
しかしバグ０であったことは単なる観測事実だ

>デバッグの時間は無限
そんなクソの意見はおれはしらん

クロスプラットフォームなフレームワークで書かれた関数を
一箇所で集中管理して使用方法や目的も明確に付加して
みんなで使う、新しいの作ったらくだらないものでもアップ
して再利用するようにする
これ完璧な言語

そして整合性保てなくて崩れていくわけだな

使うユーザが検証するし、使うたびに信頼度を上げるような感じにしといて
信頼度が低いヤツは自然消滅するようにしとけばいいさｗ
いけると思うんだが

簡単に言えばプロジェクト区別のないＣＶＳの関数クラス版だ

>>429,431
CPANにバグがないと？

>>430
あるあるwwwwww
整合性が保てるように関数にバージョン管理とか

>>426はPascalの部分範囲型ではどうなんだろう。
Delphiとかオブジェクト指向のPascalなんかが気になる。

ＣＰＡＮにバグがあるのは開発者が限られてるってこととひとつひとつがでかいからな
複数開発してる人もいるしな
モジュール別に見ても重複コードが散在してる状態だからだろ
ＸＭＬなんかでＷ３Ｃの標準コードをリモートリンクする機能があるけどあんな感じで
組む時はリンクはプリコンパイラが自動でリモートからとってくる
参照登録修正はＩＤＥ上で簡単に行えるようにすればいい

>>428
まあ、そういう定義ならそうでもいいけど、とにかくさっさ
と >>419 を証明してくれよ。

それとも、バグを処理して「廃棄」するのか？
そうすれば、あんたの定義なら「バグは "0"」になったこと
にできるぞ。(w

> そんなクソの意見はおれはしらん

⇒ >>418
> バグが見つかればそれを処理し、（無限の時間内に）また
> 運用を始める。つまり永遠とバグをつぶ(ry

>>437
>>419バグが増えたら何かあるの？
増えたバグごと潰していけばいいんですよ
単純増加しているように見えたとしても、です

バグが"0"になるかどうかがバグの出にくい言語仕様を考えるのになんか影響するか？

>>439
いやさっぱり

言語スレかと思って開いたが、スレ違いか。

>>435
部分範囲型は、booleanとか整数型とかだけで、クラスを含めた構造体みたいのにはない。
範囲を外れる代入は、静的に解る部分はコンパイルエラー、ほかは実行時例外。

Pascalの文法じゃ範囲型は序数(Ordinary)で無いとダメでしょ
その系列のOOな言語の中にはOrdinaryのサブクラスになっていれば部分範囲型も実現できるのがあるんじゃない?

系列じゃないけど、Rubyにあるのは…違うなぁ。
Pythonにあるrange()はあるのは…違うなぁ、大体型じゃないし。

もうね、oopでいいよ

プリミティブな序数なら代入だけチェックすればいいけど、
オブジェクトだとメソッド呼んだだけで"値"が変わり得るし、さらに知らんうちに他のスレッドがやっちまうかも知れん。

オブジェクトにそのアノテーションを持たせて
DbCのinvariantととしてメソッド前後毎回チェックすればええ。

>>446
JavaのComparatorは明示的には書いてないが、
compareメソッドの呼び出しだけではその値が変わらないことが要求にある
スレッドセーフかどうかは関係無い

アノテーションの定義し忘れバグ
アノテーションの定義間違いバグ
アノテーションの更新し忘れバグ

まだまだいっぱいありそうですにゃ

別スレッドが、ってのはMTsafeとか関係なくて
参照型だとコードの特定部分では変更されてないようでも、他のスレッドが参照を持ってて変更しちまうかも、って事。

>>450
それは言語の問題ではないのでスルーよろです

いや、ミュータブルなオブジェクトを
簡単につくる機能を言語がサポートしたら
その手のバグは減るんじゃなかろうか。

ちがった、ｲミュータブルだ

>>451←こいつアホ？

言語仕様だけでなく開発環境をふくめて
ますます話が難しくなってきた感がある。

SQLだけで書いたらずっとバグは少ないように
思うが。

変更に弱くなるというデメリットがあるね

>>455-456
SQL で書く ⇒ 変更に弱くなる

kwsk plz.

>>449 = >>360 = 解ってないくせに難しそうな話に口を突っ込みたい１０代前半男子。
アノテーションのミスでプログラム本体がバグるのか。
もっと勉強汁、少年。

ちなみに>>458は最近オナヌー覚えたみたいです　(｀･ω･´)

だいたいコンパイル時や実行時において注釈を持たせるなんて普通の言語でできるじゃん
これだからオナヌーばっかりやってる(ry

>>448
>>446の「メソッド」は、compareメソッドに限定してないぞ。
単に、オブジェクトいじってるうちにいつの間にか範囲を超えちゃう可能性があると言うこと。
だから、代入時のチェックだけではだめと。

それに、オブジェクトも序数相当(Comparable)ならcompareメソッドで範囲チェックするだろうが、
もとは、>>327-329のbeメソッド（？）で範囲チェックするという話。

>>459
＞実行時において注釈を持たせるなんて普通の言語でできる
kwsk

ついでに、それと>>449との関連についてもkwsk

オブジェクトがいつ変わるか解らないというのは、>>447はメソッドの前後でチェックというが、
オブジェクトのメンバ自体が他から参照されてて勝手に変更される可能性もある。

まあでも、それはそれで良いのか。メソッド呼んだときにおかしいって解れば十分？
メンバに直接アクセスしなければ。

>>461
型有り言語で一々型調べたり実際のモノを調べたりするんじゃね？

>>449とは関連性あるのかわからんのでｋｗｓｋ

>>462
OOPではカプセル化された内部のものはアクセス不能という烙印を押すわけだから・・・

この点で、一枚板な言語から移行してきた人間は一種の不便さを感じるわけだ。
たとえば代入や参照というアクセスに関して、
公開メンバが呼ばれるように設計すれば良いのでいかなるときも自力で判断可能となる（デッドロックとか同時アクセス制御も可能だし）

というわけで、言語にアノテーション（アクセス限定子？）を実装するのはちょっとセンスが悪い感じがする
それらは既に実装されてる様な気がするから。

>>464
＞OOPではカプセル化された内部のものはアクセス不能という烙印を押すわけだから・・・
現実には、例えばsetterに渡したオブジェクトは（コピーされず）そのまま保持される、
というのが普通だと思うけど、渡した側がそのオブジェクトを直ぐ捨ててくれるとは限らないわけで。

＞たとえば代入や参照というアクセスに関して、公開メンバが呼ばれるように設計すれば良いのでいかなるときも自力で判断可能となる
よくわからんです…。ちなみに、
ここでアノテーションといってるのは、publicとかprivateとかじゃなくて、
>>324-329,334 の事。アクセス限定子というより値範囲限定子といったところかな。

>>324-334 が（最初の方では静的のみだったのに）
動的に値チェックする方向になってるが、重大な問題があるのでは？

ある場所でオブジェクトに特定の条件を課す（コード上はキャスト。以降値チェックがされるようになる）。
これはオブジェクトになんらかの属性を追加するってことだな。
ってことは、条件を課すこと自体が、オブジェクトを勝手にいじって変更してるって事だ。
条件を課したコードと何ら関係ないところで、条件外の内容に変更できなくなってしまう。

その属性がある種の型情報である以上、そのオブジェクトが生まれてから消えるまで
勝手に途中で変わることなく一貫してないとまずいのではないか。

条件を課したコードのその字句的スコープの中のみでチェックするのなら、
属性は要らないかも知れないが、それでいいのか？

＞現実には、例えばsetterに渡したオブジェクトは（コピーされず）そのまま保持される、
＞というのが普通だと思うけど、渡した側がそのオブジェクトを直ぐ捨ててくれるとは限らない
現実には、その当たりの原因でのバグってあんまり見ないけど、何でだろう。

>>467
基本的にプロパティとして受け渡しするような情報はシリアライズ可能なデータであることが多いからだろ

>>466
型情報が動的に変わるのはアレだな。
実行時にpublicがprivateになったりメソッドが減ったりするのと同じだな。
そう言う言語もあるけど、このスレ的にはお勧めじゃないだろ。
字句的スコープで良いんじゃない？
キャスト時と受け渡し時のチェックだけで十分じゃね？


>>468
シリアライズ可能？イミュータブルの事？
その割合は確かに多いけど、それでも半分以上はミュータブルだろ、実際。

>>454
いや、お前がアホ

>>469
>その割合は確かに多いけど、それでも半分以上はミュータブルだろ、実際。

はいはい嘘言うなや。90%以上が整数や浮動小数点数などの値型だろうが。実際。

>>471
その辺のデータを参照わたしすることは
あんまりないと思う。

>>467
参照渡しであることも理解せずに
作る→値設定→格納　とか　取得→値設定→格納　とか
冗長なコードはよくみるよ。

Container con
Object obj = con.get(3)
obj.A = 'A'
con.set(3, obj)

みたいな

>>458
アノテーションとプログラム本体の乖離はバグじゃねぇか？

>>472
だから何？

その辺のデータを参照わたしすることが多い、なんて一言も言ってないんですけど。

>>469
キャストと受け渡しがなかったら、アノテーション通りである事が保証されないってのは気持ち悪くないか？

キャストと受け渡しをアサーションと割り切ればいいのかも知らんが、そうなると型情報とは言えないな。

>>475
ああ、まさか流れを読まずに発言していたとは思わなかったよ。

並列度を上げたときに起こる制御手順の乱れを
シミュレートしながらデバッグできる言語なんてあるといいな

>>478
具体的な作業書いてないからどうでもいいが、
とりあえずOOPの目指すところそのものだな

>>477
はぁ？それはテメーだボケ。

>467の
>現実には、その当たりの原因でのバグってあんまり見ないけど、何でだろう。

というレスの流れを受けて、
setterに渡すようなオブジェクトは、
90%くらいが整数や浮動少数点数のような値型のようなオブジェクトだからだろうが

という俺のレスに、お前が>472のようなアホレスしてきたんだろうが。死ね。

良く使われるから実装されたり、
良く使わなかったら実装されない
というのなら、統計情報出さないとな。

てか、使われている／使われていない、が判断基準になるなんて何て実践向きの言語なんだろう・・・

何いってんだコイツは。
どの言語でも使われている/使われていないが大抵判断基準としてあるだろ。
使われているから特別なシンタックスシュガーが用意されたりよ。

　　￣￣￣)／￣￣￣￣￣￣￣￣
　　　　 ∧＿∧
　　　　( ´･ω･`) 　　 　∧＿∧
　　　 ／ 　　　 ＼　 　（´∀｀　） ﾊﾊﾊ
.＿＿|　|　　　 .|　|＿　/ 　　 　 ヽ
||＼　￣￣￣￣　　 ／ .|　　　|　|
||＼..∧＿∧　 　　(⌒＼|_＿./ ./
||.　 （ 　　　）　　　　 ~＼___＿_ノ|　　 ∧＿∧
　　/　　　ヽアホか 　　　　　 ＼| 　 （　´_ゝ`）　何言ってんだコイツ？
　　|　　　　　ヽ　　　 　　　　　　　＼/ 　　　 ヽ.
　　|　　　　|ヽ、二⌒) 　　　　 　　／ .|　　　|　|
　　.|　　　　ヽ　＼∧＿∧　　　 (⌒＼|_∩./　/

　　￣￣￣)／￣￣￣￣￣￣￣￣
　　　　 ∧＿∧
　　　　( ´･ω･`) 　　 　∧＿∧
　　　 ／ 　　　 ＼　 　（´∀｀　） ﾊﾊﾊ
.＿＿|　|　　　 .|　|＿　/ 　　 　 ヽ
||＼　￣￣￣￣　　 ／ .|　　　|　|
||＼..∧＿∧　 　　(⌒＼|_＿./ ./
||.　 （ 　　　）　　　　 ~＼___＿_ノ|　　 ∧＿∧
　　/　　　ヽアホか 　　　　　 ＼| 　 （　´_ゝ`）　何言ってんだコイツ？
　　|　　　　　ヽ　　　 　　　　　　　＼/ 　　　 ヽ.
　　|　　　　|ヽ、二⌒) 　　　　 　　／ .|　　　|　|
　　.|　　　　ヽ　＼∧＿∧　　　 (⌒＼|_∩./　/

世の中の馬鹿共の使用状況に言語仕様が阿ることで、
バグが出にくくなる理由を問いたい。

いや、お前は喜ぶかもしれんが。

>>485
コンパイル時にエラーが出てコンパイル不能になるならば、
それが出荷されて世に出ることもなくなるだろう。

ひらめいた! コンパイルするふりをしてエラーしか出さないようにすれば
いかなるプログラムも世に出ることはなくその損失が未然に防げるではないか。

よし。これで行こう。

#!/bin/sh
echo "$1:1: Syntax error."

>>487
そんなことするより
　プログラム作る→禁固３００年
でいいんじゃないか？

このスレ的には>>488でFA?

>>488
プログラミング免許を各言語毎に作って違反したら罰金でいいんじゃないか?
その他細かい違反も作る。たとえば無駄なアルゴリズムを使ったら1点原点とか。
負荷が高くなるアルゴリズムを使ったら2点原点とか。

そうしたらC++は何段階かほしいな。
1級 C++の全てを完全に使用できる。
2級 中程度にテンプレートを使用できる。
3級 クラスと仮想関数による多態性（ポリモーフィズム）を使用できる。
4級 ベターCとして使用できる。

姉歯みたいなのが出てきそうだね。

malloc() で NULL が返された時のエラーチェックを忘れたり
free() を忘れたら10点原点、罰金50万円で免許取消。

まあしかし原発とか、兵器とか、医療機器とか、車とか、
壊れた時の社会的影響が大きいものでも民間人が何の資格も
なく作って納品できるというのは、何か恐い感じはする。
使う人は資格が要るが、作る人には要らないという状態で
いいのか?

>>494
作るのに資格が要らなくても、製品そのものが規格をパスしないとあかんから大丈夫
・・・っていいたいところだけど、そうじゃない製品もあるんだろうねぇ。

>>494
バケツで運ぶのにも免許が必要だよな

Ｃ言語で文字列配列の初期化書いたらカンマが抜けてて文字がくっついてしまった。

char foo[][N]=
{
"hoge",
"hage"
"moge"
...
}

警告くらい出してよ、コンパイラ。

printf(
">>497\n"
"そんな警告出したら、長い文字列改行して記述できなくなるじゃん？\n"
"それでもいいのなら、俺様仕様のローカルルールでコンパイラをチューンすれば良いよ。\n"
);

>>498
俺lintで充分ｼﾞｬﾏｲｶ？

>>497
C言語とは、そういうものだ。

>497
言語の仕様なんだからコンパイラに文句言うなよ

>>501
カンマが無いと文字列がつながるのは言語仕様だけど、どんな警告だすか（ださないか）まで言語仕様なんだっけ？
文字列配列の初期化の部分だけでも判定してくれたらよいのに。
警告だからカンマなしのコードでもコンパイルは通るしね。

ちょっと気になったのだが、俺は警告＝ウォーニング＝オブジェクトできる。という認識なのだが。
もしかしてみんなは警告＝エラー＝オブジェクトできない。という認識？

>>503
警告が無くなるまで己の書いたコードは許せないという人も世の中には多い。

通常の場合に、警告あっても許せる奴は死んでイイよ。
だが、もともと設計が腐ってて仕方がない場合も。

>>503
警告と別に、ヒントを出してくれるのならそれはそれでOK。
使いたくなければ使わないだけだから。
でもそれは、恐らくコンパイラではなくlntの仕事。

lntかぁ。
コード診断のソフトっていろいろあるが、みんな仕事でどの程度使ってる？

lintでそ。
自分の書くコードはlintクリーンだけど何か？

>>508
lintのおかげでバグを摘出できたって事ある？

無い、決まりだからやってるだけ
メンドクセ

lintってバグを検出するものではなく、
バグが現象として見える前に排除するものだと思うが。

ｽｹﾞｰ
lint最強じゃん

バグをなくすにはテストが肝要。
いかにテストしやすい言語にするか、そこだろう。

>>513
なに言ってんだ、おまえ？
テストなんかしたらバグが出るじゃないか。
テストしなけりゃバグはゼロだぞ。
君はｽﾚﾀｲを１０回音読しときなさい。

納品もできないけどな

そうだ、仕様にしよう

Ｃ０Ｃ１を１００％通る入力を自動生成することって原理的に可能なんだっけ？

Ｃ０Ｃ１って何？

ヒント：カバレージ

なるほど。それって、入力の生成以前に
flag = false;
if (flag) {
　.....
}
とかそもそもダメじゃん。意図せずバグでこうなってるときも。

じゃあ、絶対通らないパスを検出してくれるチェッカと組み合わせて使うとか。
絶対通らないパスの検出が原理的に可能かどうか知らんけど。

>>521
Javaのコンパイラって内部的にそれを検出していると思うぞ。
何にも警告出ないと思うが。JavaはCみたいなプリプロセッサを
通さないからデバッグコードを埋め込みたい場合にデバッグ時は
true にしておいて終わったらfalse にするという用途で使う。
で、false になっていた場合はその内部がコンパイルされない。

class xxx {
　public final boolean DEBUG = false; // デバッグ終わったら false にする。
　public void method() {
　　if (DEBUG) {
　　　// ここは DEBUG が false だとコンパイルされない。
　　}
　}
}

>>522
そういう単純な場合は検出できるだろうけど条件式が複雑になった場合も検出できるかが問題。

複雑さというか、プログラム停止問題とか絡んで、
完全にすべて検出するってのは無理そうだな。

>>523
複雑でも解析していけばそのうち分かるんじゃないか?
但し動的にリンクするライブラリとかがあるとその部分ではできない。

>>525
確か無理なことが数学的に証明されてたと思います。

ところで、話は変わるけど、俺はついに画期的な天気予報のシステムを開発した。
何がすごいって、予報的中率が１００％なんだ。
でも一つ欠点があってね、1週間後の天気を計算するのに2週間かかることなんだ！

コンピューターの性能が4倍にでもなればいいのかあ。

ナビア・ストークス方程式を解けばいいだけだね。

ムーアの法則により 3 年くらいで解決するんじゃない

ラプラスの悪魔について
http://ja.wikipedia.org/wiki/%E3%83%A9%E3%83%97%E3%83%A9%E3%82%B9%E3%81%AE%E6%82%AA%E9%AD%94

石原良純が言う逆のことを考えれば 100% の天気予報に

>>532
株でそれを思ったことがある。
常に負けているヤツの反対の買い方をすればいいと。

株は負けの逆のことをしても勝ちとは限らないんだよね。

>>533　は真実。負けているやつと、勝っているやつの両方を知ると有益。
　

>>533
逆張り? 株じゃないけど逆のことやって大きくなった会社が北陸になかったか?
ホテル業か不動産か忘れたが。

>>525
現在のコンピューターというのは、数学的にはチューリングマシンと言われるモノを、機械的に再現したモノです
これは言語が何であれ、そこからは逃げられないモノです
そして、チューリングマシンでその問題が計算できるかどうかは、チューリングマシンの停止問題から、完全予測は不可能なことが証明されている。

で、最後なんだけど
チューリングマシンの項に関しては「知っておいた方が良い」ではなくて「知っておくべき」の次元だから

うん、なんていうか…もうちっとガンガレ

現在のコンピュータは、チューリングマシンというよりか線形拘束オートマトンかな。

チューリングマシンと別次元に量子コンピュータや、DNAコンピュータがある

量子コンピュータには確かにロマンを感じるがＤＮＡはなんか力技っぽいからなぁ。

量子コンピュータについては、一般人は高性能コンピュータというイメージを持っているが、実際には全く違うものだ。
だから、量子コンピュータの実物が普及してもPCは相変わらずノイマン型だろうと思う。

そだねー。

1+1の答えは80%の確率で3。

10^-80% 位にまからん？ せめて 2^-80%

数十回繰り返し計算した結果の中で最も出現頻度の高い値を計算結果として採用

バグの出にくい言語仕様より
バカの出にくい「なにか」が欲しい。

>>546
たとえば？

テスター

メモリ開放の自動化
テストの自動化

次は
コーディングの自動化
リファクタリングの自動化
入力値チェックの自動化
あたりかねぇ

>>549
素人だな。

それでは玄人の意見をきこうか。

巨大なプログラムをもっと理解しやすくする術は無いもんだろうか。

文字じゃなしに図をうまく利用すれば理解しやすくなるかも。

UMLとか？
図が巨大になりすぎてやっぱりわからないなんてことも起こりかねない。
まあ、それでもソースだけよりはましなんだろうが。

このスレで動作単位の粒度について話しても
どうこうなるとは思わないぞ

お前らが小手先で思いつくことはすべて考えられていると思え。

素人考えでもいいじゃない。
２ｃｈだもの。

>>549
入力値チェックの自動化というか、
値チェックの自動化なら>>324当たり以降にあるぞ。

>>552
doxygenでいいんじゃね？
結構使える。

GNU GLOBAL も。

>>559
>>560
ネタもないようなのでdoxygenとGNU GLOBALについて語ってくれんか？

バグの出にくい、ということであれば、トレンドは関数型言語でしょうな・・

関数型言語のはなしも前に出てたな…
結論はなんだったけ？

無限ループを禁止すればよくね
必ず有限の回数を実行すれば止まることにすれば 停止問題も解決するし 理論上全組み合わせを調べればバグの有無が証明可能

>>565
俺も大学で勉強する以前には、そう思ったことあるよ。
ttp://ja.wikipedia.org/wiki/%E3%83%81%E3%83%A5%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E5%AE%8C%E5%85%A8

無限ループを禁止すると一部表記不能になるだろうが、そもそも無限ループになる時点で現実では意味が無いだろ
構造化言語でループは必ず上限値をつけるとどうなるか想像してみた
……確かに無限ループがないとプログラム書くのは不可能だ

状態遷移図で書くとバグに強い気がするがなぜだろう？

>>565
ゲームも作れないし、
イベントドリブンのアプリも作れないじゃん。

ゲームは無限ループのパラパラ漫画だし、
イベントドリブンはイベントをキャッチする仕組みが無限ループのチェックしてるだろ。

無限ループになることを期待していない箇所が無限ループになってたりするとバグになるんだから、
停止条件の検証……が一番効果ありそうだけどな。

書けないプログラムがあってもよい弱い言語
→ 静的(実行せずに）停止性を判定可能

何でも書けるプログラミング言語
→ 静的に停止性を検証するのは不可能。
動的にやるななら、invariant、precondition, postconditionを使ってくれ。
（CやJavaならassertでがんがれ)

でFA？

>>565
おまいの定義ではWindowsのメッセージループはどうなるの？

>>572
一定回数起動するとアクティベーションが切れれば問題ないじゃん！
これでまた新しいビジネスモデルが出来たね

何を言ってるんだ？

プログラムが巨大化・複雑化したっていうのに、
今の言語は上位の図式モデルや設計情報との結合が弱すぎ。

言語に対して強制的に
設計情報・図式モデル←→高水準言語モデル　
の変換プロトコルを定義させる。

図式モデルでプログラミングできたり、
デザインパターン名が
予約語になってたりする言語。

UMLでよくね？

>>576
もの知らずもほどほどにな

あーもちろんツール込みでのハナシね

>設計情報・図式モデル←→高水準言語モデル　
>図式モデルでプログラミングできたり

この程度ならほんのりできてるでしょ

>>578
それなんてMDA？

つうか時間と金とあと少しユーザさんの頭脳が良くなる事と全てが許される平和な世界があれば何とかなるな

だいたい俺はループの関数ごときでバグったことなんかない。

>>581
あなたが例外だったのかもしれない。

>>582
お前よっぽど馬鹿だったんだなｗ
こんなところでバグってたらプログラム完成しないだろ？ｗ

>>581
まだプログラミングの日も浅いやつに言われたくないな。

>>584
いわれてよく考えてみたら、始めてから８年近くも経ってるなｗ

>>585
予想通りの返答です。

まだ８年か

8年間なにやってきたの？
せいぜい1000行のプログラムしか書いたことなさそう。

まぁ
while(1){}
とか書いてたんじゃないか。八年

配列とか、いわゆるCollectionを用意して、
foreachとかでグルグル回すだけにしとくのはどう？

もちろん長さが無限のCollectionも用意するんだよね？

それじゃ意味ないんじゃ。

あげ

型安全じゃなくてもバグを出にくくする方法ってあるんだろうか

>>595
型付ラムダ計算についてもっと勉強しなさい

間違えた
×型安全じゃなくても
○型付けの弱い(もしくは型が無い)

>>595
静的型・動的型って区分ならば、型推論というアプローチもある。
ちなみに俺は tRuby ってのに注目していたりするが。

これまでの議論の対極を行こう。可能な限りフラットな構造をとる。
たとえば
リレーショナルデータベース。SQLPLUSだけでプログラミングする
イメージで言語を作ったら。

>>575
はげどう。
UMLとソースとの同期を取りますとか、UMLからソースを自動生成しますとか、
そんな考え自体が間違いじゃないか。

>>600
つまりどうすれば良いわけ？

>601
>575 図式モデルでプログラミングできたり
UML→ソース　じゃなくて　ＵＭＬ(等の図)=ソース　と言いたいんじゃなかろうか
UMLを直接コンパイルするような

ソースはアスキー文字じゃないと落ち着かない俺が居る。

>>603
emacsの拡張で、AAでUML書くのがあった気がする。

>>604
そういう問題でもない。
と、釣られてみる。

既に言語仕様うんぬんの話じゃなくなってるのでここで原点回帰



やっぱ「バグ」の範囲を考えて、それを実現できない言語 NULLPO を作ればいいんじゃまいか？

先ずは「バグ」の分類しなきゃ話にならんな
・致命的
・どうでもいい

とか

・言語仕様で防げる
・マが気をつけるしかない

とかそういうのをハッキリしないと
ぬるぽ言語だろうがガッ言語だろうが無理

仕様記述言語とかどうだろう。

>>608
古すぎる。
Haskellなどはすでに仕様記述言語と同等レベルの抽象化ができるから。

バグの作りこみにくさでいくと、Haskell>javaなわけ？
もれはHaskell使ったことないが。

Haskellいいですね。
Haskellに事前、事後、不変条件をつけて評価してみたいです。

>>575
設計情報・図式モデルはある程度までしか複雑化できないのです。
今の図式モデルは肝のところしか表現されていません。

実際はプログラム時に仕様書から類推して要求されているであろう機能を
実装しているのです。

>324-329,334 が理解できない。
馬鹿な俺でもわかるように解説してくれ

コンパイル時の処理？をソースに埋め込めるということなのか？
テンプレートのさらに、メタな感じ？

>>613
今の型付言語だと構文チェック以外には型以外のオブジェクトの属性はチェックしないのが多いから配列の次元数やNull代入不可とかのチェックをしようって事
すでにそういう言語は無い事はない

余計わかんなくなったｗ

次元解析ってどういうこと？
配列の次元って、コンパイル時に普通にチェックしてくれるような？

Null代入不可は、コンパイル時にチェックできるの？
定数でnullは大丈夫だと思うけど、実行時にnull代入は、実行時にチェックするしかなくね？
可能性？をチェックするの？

次元数じゃなくて、要素数の制約だ
最大10個と決めてるところに最大15個の配列を入れるとオーバーするとか必ず3つと決めてるところに1つしか入れないと数が足りないとかそんな感じ

Null値は確実にNullにならない項目にNullを入れれる項目から値を代入するとNullが入れられる可能性が出てくるからエラーにするって感じ
そういう場合はNullを入れられる項目がNullかどうか判断して、Nullが入れられない項目は必ず別の値を入れるロジックを作る必要が出てくる。

そこまで来ると今度は、「暗黙の初期値とかを決めて〜」とか言い出す奴がきっと出てくると思う

>>616
お、Nullは大体わかた

次元の方は、
配列のインデックスの範囲チェックのことか？
いや、違うな？
配列のサイズが異なる配列の相互代入に制限つけるということ？
配列のサイズがことなるも何も、もともとできないような・・・って、俺が使ってるDelphiだけかもしれんが

>>17

MATLAB みたい

>>617
次元て言ってるのは、配列とは関係ない。物理単位の指数のこと。
速度の次元は、例えばm/sec、つまり距離が１次元、時間が−１次元、という事。

例えば、速度を引数に取る関数があったとすると、
引数が単なるdoubleだと間違って距離を渡してもコンパイルが通ってバグになる。

でも、>>324-329なら、単なるdoubleじゃなくて型に次元情報を組み込む事で、
速度の引数に間違って距離を渡すと、コンパイルエラーにできる。


…だと思う。

>>325は１パラメタだけど、
距離、質量、時間の３パラメタにすれば、

//型に付くメタデータその３（コンパイル時チェック）
annotation Dim(int m, int k, int s) applies Number;

//メソッド（関数）定義
double@[Dim(1, 0, -1)] speed(double@[Dim(1,0,0)] distance, double@[Dim(0,0,1)] time) {
　　return distance/time;
}

double@[Dim(1,0,-1)] a = speed( ([Dim(1,0,0)])123.45678, ([Dim(0,0,1)])123.45678 ); //OK
double@[Dim(1,0,1)] b = speed( ([Dim(1,0,0)])123.45678, ([Dim(0,0,1)])123.45678 ); //コンパイルエラー
double@[Dim(1,0,-1)] c = speed( 123.45678, 123.45678 ); //コンパイルエラー

>>619
＞次元て言ってるのは、配列とは関係ない。

配列と関係はないが、配列の長さにも使えるな。

annotation Length(int) applies Array;//これの書き方があれだけど

//メソッド（関数）定義
long[]@[Length(n)] zipWithMax(long[]@[Length(n)] a, long[]@[Length(n)] b) {
　　long[]@[Length(n)] ret = long[]@[Length(n)] ret[a.length];
　　for (int i=0; i<a.length; i++) {
　　　　ret[i] = Math.max(a,b);
　　}
　　return ret;
}
long[]@[Length(10)] a = zipWithMax(long[]@[Length(10)] l, long[]@[Length(10)] r);//OK
long[]@[Length(10)] b = zipWithMax(l, long[]@[Length(10)] r); //コンパイルエラー
long c = zipWithMax(long[]@[Length(10)] l, long[]@[Length(10)] r); //OK (自動キャスト)
long[]@[Length(10)] a = zipWithMax(long[]@[Length(10)] l, long[]@[Length(5)] r);//コンパイルエラー

仕様書をそのままｺﾋﾟﾍﾟするだけで動いちゃう

long[]@$::zipWithMax( #length[ @ ] | #length[ int $n ] );

「バグが出にくい言語仕様」というスレだからそういうのでもいいんだろうけど、
間違いを抑制するという効果しか生まないんじゃ、そのコストはあまり払われない。
間違いを抑制しつつ、求められる機能の実現手段にもならないと。

>>619
なるほど。単位のことか。
物理的な話で、速度がx^2、距離がx^1って話かな。

んーでも、それだけのことなら、単位を型(クラスでもいいけど)で扱ったら、駄目なんか？
次元にしちゃうと、応用性があるのか？

type TVelocity < double;
type TDistance < double;
type TTime < doble;

function Velocity(distance TDistance; time: TTime): TVelocity;
begin
　Result := TVeloicty(distance / time)
end


ついでに、

Velocity velocity = 1234km
Time time = 100min

みたいなリテラル記述もできると面白そうだが

>>625
それだと、加速度も運動量も運動エネルギーもいちいち型定義が必要になるじゃん。

>>626
それのどこに不都合が？

つうか、そんなことより、こんな風に演算も汎用的に定義できるのがデカい希ガス

double@[Dim(m, k, t-1)] divByTime(double@[Dim(m, k, t)] quantity, double@[Dim(0,0,1)] time)

>>627
その程度の数、と思ってるかもしれんが、
定数や計算途中で、特に名前の付いてない単位がいろいろ有り得る。
その組み合わせ数分の演算をいちいち別個に定義するのは無駄すぎる。

それを勝手にチェックしてくれてこそ、次元解析ってもんだろ。

>>629
オペレータオーバーロードじゃだめなの？

演算子オーバーロードは、関数の名前が記号になるだけだろ？
色んな次元と色んな次元の単位の組み合わせ分の演算を定義しなくてはならんのは、なんら変わらん。

>>631
そんなことないと思うよ？
継承と組み合わせれば、そのほとんどが省略できるんじゃない？

オーバーロードとオーバーライドをごっちゃにしてないか？
次元が違う型をどうやってオーバーライド（継承）するんだ？
言っとくが、処理内容の問題じゃないぞ。
演算の型定義の話だからな？

演算の型定義ってのは、どういう型の引数を取ってどういう型の返値を返すか、ね。

>>633
処理内容が継承できれば十分なんじゃないの？

処理内容が同じで、引数の型が違う演算ってどうやって継承で作るんだよ？
引数・返値の型をなんでも良いことにするのか？
それじゃそもそも型の意味がねぇｗ

>>636
暗黙の型変換。

なんでコンパイラがそんな暗黙の型変換が出来るんだよ。
すくなくとも>>625のコードにはそんな判断が出来る情報はない。
できるとすれば、単に型がdoubleであれば何でもよい、という無意味な結論になる。

>>638
単位すべてについて型定義する。
これで解決。

すまん、酔っぱらってるんで無駄に攻撃的なレスになっていたようだ。
その、「すべてについて」定義するのが無駄じゃん、て話だよ。

無駄というか、色んな次元の単位は無限にあるわけで、そもそもムリ。
>>628みたいのを演算×次元要素（上の例ではm,k,sの３つ）分用意すれば全てまかなえる。

さらに、定数も、例えばdouble@[Dim(2,1,-1,-1)]（最後は温度。ボルツマン定数）みたいに、
わざわざそのためだけの型を定義しなくても、さっくり書けて、使われてる所の型チェックも出来るわけよ。

http://ja.wikipedia.org/wiki/次元解析
に、「式の間違いをチェックする場合にも使える。」てあるじゃん。
まさにこれをコンパイル時に自動的に出来るようにするって事だよ。

>次元解析
利点がわからん。
型で定義すりゃいいやん。

しかも、すんごい限定的すぎない？
速度とか時間くらいのために、こんなの実装すんの？
無限にある次元の単位を使う機会ってあるのかな？物理屋さんなのかな？

あー、wikipediaみたら、わかった
http://ja.wikipedia.org/wiki/%E6%AC%A1%E5%85%83

そんなの普通のプログラミングに使わんｗ

>>642
だよね。

役に立つ場面が限られるのは確かだけど、業務システムでも場面は十分あるよ。
オンラインのトランザクション毎の処理ではほとんどないだろうけど、
バッチとかで統計を出すとか、計算系処理では、
MKSの物理量じゃなくても、単位の次元が存在するのは普通。

まあ、それ間違ってたらとんでもない結果になるから、普通はテストで判るはずだけど。

でも、テストまで行かずにコンパイル時にチェックされた方が速いし、
まれにしか走らないロジックではテスト漏れの危険があるが、
コンパイルでチェックされれれば必ず発見される。

C++ならテンプレートで出来そうな気がする



…気がするだけかも

こんなの？

template <int M, int L, int T>
struct dvalue {
  // いろいろ略
};
namespace phys {
  typedef dvalue<1,0,0> weight;
  typedef dvalue<0,1,0> length;
  typedef dvalue<0,0,1> time;
  typedef dvalue<1,2,2> energy;
  typedef dvalue<1,1,1> moment;
}
int main() {
  phys::weight m(1.0);
  phys::length x(1.0);
  phys::time   t(1.0);
  phys::energy E(1.0);
  phys::moment p(1.0);
  if (m*x*x*t*t == E) std::cout << "ok" << std::endl;
  if (m*x*x*t*t == p) std::cout << "ng" << std::endl;
}

面倒だから * しか実装しなかったので物理的にめちゃくちゃなのは許して．
ちなみに発生するコンパイルエラーはこんなかんじ．

main.cc:43: error: no match for 'operator==' in 'operator* [with int M1 = 1, int
L1 = 2, int T1 = 1, int M2 = 0, int L2 = 0, int T2 = 1](((const dvalue<1, 2, 1>
&)((const dvalue<1, 2, 1>*)(&operator* [with int M1 = 1, int L1 = 2, int T1 = 0,
int M2 = 0, int L2 = 0, int T2 = 1](((const dvalue<1, 2, 0>&)((const dvalue<1,
2, 0>*)(&operator* [with int M1 = 1, int L1 = 1, int T1 = 0, int M2 = 0, int L2
= 1, int T2 = 0](((const dvalue<1, 1, 0>&)((const dvalue<1, 1, 0>*)(&operator* [
with int M1 = 1, int L1 = 0, int T1 = 0, int M2 = 0, int L2 = 1, int T2 = 0](((c
onst dvalue<1, 0, 0>&)((const dvalue<1, 0, 0>*)(&m))), ((const dvalue<0, 1, 0>&)
((const dvalue<0, 1, 0>*)(&x))))))), ((const dvalue<0, 1, 0>&)((const dvalue<0,
1, 0>*)(&x))))))), ((const dvalue<0, 0, 1>&)((const dvalue<0, 0, 1>*)(&t))))))),
((const dvalue<0, 0, 1>&)((const dvalue<0, 0, 1>*)(&t)))) == p'

おーすげーすげー、さすがC++。
エラーメッセージは全然わかんないけど。
*の定義はどんなん？

書いてからこれ略すのは自分でもどうかと思った．すまんかった．

template <int M1, int L1, int T1, int M2, int L2, int T2>
dvalue<M1+M2,L1+L2,T1+T2> operator * (const dvalue<M1,L1,T1> &a, const dvalue<M2,L2,T2> &b) {
  return dvalue<M1+M2,L1+L2,T1+T2>(a.value * b.value);
}
template <int M, int L, int T>
bool operator == (const dvalue<M,L,T> &a, const dvalue<M,L,T> &b) {
  return a.value == b.value;
}

つうか、型推論入れればそこまで定義しなくて良いよね

型推論でこんなのいけるのかな？

>>652 ここら辺はいろいろ研究されてるみたい。dependent type とか。
http://www.cs.bu.edu/~hwxi/DML/DML.html

バグって、見つけた瞬間からバグなんじゃなかったっけ
見てみぬフリをすれば…

いや、ｽﾏｿ

> 単位の次元が存在するのは普通。
いや、普通じゃないと思うｗ

>>655
MKSの物理量だけが次元を持つ単位じゃないんだよ？
例えば、「１人当たりの金額」なら、 単位は、円/人。
つまり　円が＋１次元で、人数が−１次元だ。

こういうのは自然に誰でも判ると思ったんだけど、現実は厳しいのかなぁ…。

>>656
物理学の世界をかじらないと難しいと思うよ

「次元」というから難しいのか？「何乗」と言えばいいのか？
X/Y = X^1 ×　Y^(-1)。　さすがに、これなら誰でも高校か中学でやってるだろ。

掛け算を習った後に交換法則を覚えるが、それは次元の交換までは保証していないって所は高等数学に行かないと教えてもらえない

大学で無次元化ならったお

どっちにしろ必要ないな。

工業高校だと微分をちょっと触って終わりだ。しかも覚えてねえ。
今じゃもう因数分解すら出来ないぜ…

次元解析はあくまで、>>324-329,334 の応用の一例。
>>324-329,334 は、
単に変数（定数）名だけじゃなくて値も使えるType SafeなEnumとか、
Genericsの仕組み自体とか、いろいろ作れる、みたい。

しかし、問題はバグを減らす事には役立つが、
機能を実現することに役立たないと言うことではないだろうか。

>>656
大学で、MKSが次元ということはならったが、
それが一般に当てはまるところまではいかなかったなー。

まあ、応用利かない、俺も俺だがｗ

>>664
大学まで来て数学をならったなら
その応用で金利計算とか人口統計とかの次元はなんだろな？と思ってくれよ

単位か…こういうことが出来ると便利そう

typedef unit<double> metre;
typedef unit<double> second;
typedef unit<double> kilogram;
typedef metere/second speed;
typedef speed/second acceleration;
typedef acceleration*klogram newton;

metre L = 1000;
second T = 10;
kilogram W = 10;
speed V = 100 + L / T; //OK
newton N1 = W * V; //NG コンパイルエラー
newton N2 = W * (V / T); //OK

まあ、妄想なんだけどね

流石に変数名が安直だったか…

AppleScriptでは単位つかえるよな

typedef unit<double> metre;
typedef unit<double> second;
を異なる型として認識させるのは厳しいなあ．それ以外ならまあなんとか．

template <int M, int L, int T>
template <int M, int L, int T> 
struct unit { 
  double value; 
  unit(double value) : value(value) { }
};
template <int M, int L, int T> 
unit<M,L,T> operator + (const unit<M,L,T> &a, const unit<M,L,T> &b) {
  return unit<M,L,T>(a.value + b.value);
}
template <int M1, int L1, int T1, int M2, int L2, int T2> 
unit<M1+M2,L1+L2,T1+T2> operator * (const unit<M1,L1,T1> &a, const unit<M2,L2,T2> &b) {
  return unit<M1+M2,L1+L2,T1+T2>(a.value * b.value);
}
template <int M1, int L1, int T1, int M2, int L2, int T2> 
unit<M1-M2,L1-L2,T1-T2> operator / (const unit<M1,L1,T1> &a, const unit<M2,L2,T2> &b) {
  return unit<M1-M2,L1-L2,T1-T2>(a.value / b.value);
}

続き

template <class Type1, class Type2>
struct unitMul;
template <int M1, int L1, int T1, int M2, int L2, int T2>
struct unitMul< unit<M1,L1,T1>, unit<M2,L2,T2> > {
  typedef unit<M1+M2,L1+L2,T1+T2> result;
};
template <class Type1, class Type2>
struct unitDiv;
template <int M1, int L1, int T1, int M2, int L2, int T2>
struct unitDiv< unit<M1,L1,T1>, unit<M2,L2,T2> > {
  typedef unit<M1-M2,L1-L2,T1-T2> result;
};
typedef unit<1,0,0> metre;
typedef unit<0,1,0> kilogram;
typedef unit<0,0,1> second;
typedef unitDiv<metre,second>::result speed;
typedef unitDiv<speed,second>::result acceleration;
typedef unitMul<acceleration,kilogram>::result newton;
int main() {
  metre L = metre(1000);
  second T = second(10);
  kilogram W = kilogram(10);
  speed V = speed(100) + L / T;
  // newton N1 = W * V; // compile error
  newton N2 = W * V / T;
}

ほうほう

物理計算だけとか一分野限定ならそれで充分いけそうやね
SI基本単位は７つだけだし
規格がない場合もそうそう増えないだろうし

だけど、他分野も考慮しようとすると辛そうだ
まあ、滅多に無さそうだけど

D言語の強いtypedefならもう一歩いけるのかな

物理に限定する理由がわからない。

671 は一分野限定と言っているだけで、物理に限定してはいない。きっと

天体計算していたらふと人が住めそうな星が見つかったので
何人住めるか計算するために新次元 [人] を追加したくなった

とかいうケースを考慮してるんだと思うよ。
669 の実装では次元が増えたときの対処が結構めどい。

結局型の強弱レベルの話題しかないんだな。

>674
それは、今更ポインタ＆メモリ管理絡みの話をしろと言う事かい？

ソフトウェアの検証とかの方向に進まないかしら

型を強くすることで、コンパイルがソフトの検証になるんじゃん。

>>677
検証の一部は肩代わりできるが、検証にはならない

どういう検証を言っている？

concept_checkで事前事後条件例外仕様もチェックだぜ

何年後になるやら

それって、>>324-329,334 でできないの？

JSR 308ってのが出来たらしいけど、
これって、>>324-329,334 のパクリ？

http://jcp.org/en/jsr/detail?id=308

>>682
そこまで行くとさすがにJavaの小汚さが際立つな・・・。
C#みたいに[]にしとけば良いのに。

>>683
言語仕様を変えずにアノテで実現がこの場合の肝だから

Curl だとどこまで出来るんだっけ？＜単位計算
　{let height:any = 16px} || heightは16ピクセルである事を表す
とか
　{let width:any = 12cm} || widthは12cmである事を表す
とか
　{let area:any = height * width} || 16px * 12cm
とか出来たよね。

>>324-329,334 は、JSR308も含むけどJSR305の方が近いんじゃない？

http://www.popjisyo.com/WebHint/AddHint.aspx?d=1&r=j&u=http://jcp.org/en/jsr/detail?id=305

JSR305って、特定のアノテーションが追加されるだけで、
>>324-329,334 みたいに、やりたいアノテーションを自分で作ることは出来ないのでは？

誰か>>324-329,334を一レスくらいにまとめてくれ

↓よろしく

くしゃみ

↓み

みかん＞＜

・＜Java5のアノテーション＞
→ ＜>>324-329,334の拡張＞　の形式で。

・修飾子が付くモノにしか付けられない
→ 変数の型宣言すべてに付けれる。メソッドのレシーバにも。
・コンパイル時、単発の「印」でしかない
→ アノテーションが付いた型は、付けた型の子型になる。さらに属性の値毎に別の子型になる。
→ キャストの可否（明示、暗黙）、実行時キャストチェックを定義できる。
・「どこ(メソッド、フィールド、パッケージ等)に付けられるか」しか指定できない
→ 「どの型に付けられるか」を指定できる
・アノテーションの属性には定数しか指定できない
→ 変数ＯＫ。演算もＯＫ。演算はコンパイル時に行える。


これで、
型に保障された単位付き計算や、Generics機能そのもの、型安全Enumなど、
型機能によってコンパイル時に安全性を保障できる様々なバグ防止機能が作れる。

さらに、実行時キャストチェック定義によって、
Pascalの範囲型みたいの＋強制DbCが、任意のクラスについて行える。

乙

ところでマルチスレッド関係のバグを減らす仕様ってあるのかな
デッドロックとか

同期機構の扱いになるんだろうけど

全てのオブジェクトをイミュータブルにすれば良いんじゃね？

パフォーマンス悪いもバグ

ところで、型に起因するバグってそんなに多い？
実体とポインタの代入間違いぐらいじゃない？

どっちかっていうと
実体がどっから参照されているかわからない場合の
方がバグりやすいんだけど・・・
これってロジック的にはスパゲッティと同じだから
言語で乗り越えていくべきものかと思うけど
なんかいい方法ないかね？

参照透明にすれば。

>>697
不勉強で悪いのだけど、
それって初期化されたら変更できないってことだっけ？

>>698
大雑把に言うとそう。

>>696
根本的に勘違いしてるみたいだけど、
「型に起因するバグ」ってのは、そもそもありえない。
例えば、キャスト誤りは型がなくても元々バグ。
型は、バグを「検出」するだけだよ。型のせいでバグるってのはない。


それはそれとして、
実体がどっから参照されているかわからない場合のバグってのはどんなのを言ってる？

>>700
連結リストで先頭をいじっても
他からの参照が変化しないから
ひとつ変化しない先頭をかませておくみたいなこと。

このあたりの整合性をソースのどっかでいじられると探すのが大変だったりしない？

先頭をいじるってのは、値じゃなくて先頭を他のオブジェクトに取り替えるって事か？
そもそも、そんな事しないだろｗ

オブジェクトの値を更新したら、実は更新されては困る奴がそれを参照していた、
なんて事はまれにあるけど、それはそのオブジェクト（インスタンス）の位置づけが
曖昧だった、というのが問題。

まあ、安全なのは>>694だな。

大半のバグの原因は、部分の仕様が曖昧か不完全って事だろ。

「□□である場合は」の□□の具体的な条件が決まってないとか。

「返値は○○」という事になっていても、△△という条件の場合は○○じゃない、とか。


つまり、条件も含めた仕様が強制的に明確になる言語仕様が必要。

>>702
え？しない？
設計間違えたかな・・・

リストのノードは入れモンだろ、常識的に考えて…。
なんで入れモンごと取り替えるんだよ。

>>705
順序を変えたかったからなんだが・・・

Java1.4 のコレクションは
キャストミス誘発しやすいな

関数型言語の時代がそろそろやってきますよ

もう来た。そして去った。

>>709
まだ去ってないw

確かに去ってはいないが。
「○○の時代」と呼ぶ事が出来るようになるためには。
○○が少なくとも過半数の人間に容易に理解出来るようでなくてはならない。
○○が「関数型言語」であっても「オブジェクト指向」であっても同様だね。

> 過半数の人間
> 過半数の人間
> 過半数の人間
> 過半数の人間
> 過半数の人間
> 過半数の人間
> 過半数の人間

>>711
「理解」って、それが便利だと認めるってことだよね？？

>>713
俺って彼女にそう理解されているんだろうか・・・

ワロタ

>711
プログラマは全て人間である。
しかし人間は全てプログラマではない。

日本語はバグの出やすい言語でつね

日本語を使う奴にバグが多いんだよ

ハングルの時代がそろそろやってきますよ

>719
ハングルは文字であって言語ではないぞ

韓流ブーム再来ですね

自プロセス内の他スレッドへの切り替えを抑制する機構が言語記述レベル
で欲しいなあ。（他プロセスへＯＳがタスクスイッチするのは構わない）

>>722
そういう言語は既に在る

それでバグが出にくくなるのか？逆にバグのるつぼになりそうだが。

「何故そうするのか」を記述しなきゃならない言語

>725
それを書けない人間が居るんだよなぁ…

バグバグ

>>723
教えて

誰か、>>692をJSRに提案しろよ。

JSRって？

Java Specification Request
http://jcp.org/en/jsr/all

(1)バクの出にくい言語処理系がバグだらけ
↓
(2)バクの出にくいバグだらけの言語
↓
(3)バクの出にくい言語処理系をバクの出にくい言語で書き直す
↓(バグが混入)
(4)(1)に戻る

↑凡才現る

JAVAは使ってないからよく分からん

【ブログ】プログラマーを目指して日本を縦断
1 名前：23歳高卒ニート 2006/11/26(日) 00:58:53
http://d.hatena.ne.jp/nonomachon2nd/
23歳高卒ニート童貞がプログラマーになりたい一心で旅をします。
現在、神奈川を移動中。
もし見かけたら、
雇ってください、本をください、技術を教えてください、飯をおごってください。

>>684
言語仕様は変わると思うけど。今は 型名[@annotation] とかできんでしょ。

JSR308ってのは、
型アノテーションを型システムに取り込むところまでやるのか？
そうでないと、>>324-329,334 並の機能は無理だろ。

>324のNonNullって、つまりnullは絶対ダメっていうannotation？
実用性がちょっと想像できない。。。
絶対にnulｌを許せないっつー場面って、そんなにあるかなあ？

>>738
おまえは、すべてのメソッド呼び出しで必ずnullチェックをしてるのか？
そうでなければ、そのすべてが「絶対にnulｌを許せないっつー場面」だろうが。

すべての関数の実行に役員の３分の２以上の承認を得なければならない。

認証を行う関数の実行はどうするんだ？

再帰

>739
うーん、分かる気もするし、分からない気もするなあ。

そもそも、コンパイル時にnull可否がチェックできるようなアイデアなら
既になんかの言語に実装されててもよさそうなんだけど
そんな機能を搭載してる言語って、無いよね？
(有るんだっけ？有ったら恥ずかしいなあ。。。)

C丼のnullableも、なんかニュアンス違うっぽいし。
このスレで発明されたアイデアなの？
それとも、実装できない理由があるっつー可能性とかは？

つ SQL
あとHaskellとかはデフォルトでnull不可だろ。
基本的に型パラメタだから型パラメタがない言語では難しいだろう。
null禁止自体については前スレにあったはず。

というか、>>324-334は、null禁止は一番単純な応用にすぎなくて、
そういうのやもっと高度なのを作れる強力な型パラメタ機能が主題なんだが。

SQLは使われ方からして、コンパイルで検出できても、
プログラム的には実行時エラーにしかならんだろう。

っていうか、オブジェクトは常にNullになる可能性があるからだろ・・・

ぬるぽ対策(っつーか型パラメタ)って前スレの423から考えられてんのな。
もう1年以上だ。
そろそろなんか実際に触ってみたいな。
Haskellやってみようか・・・

Haskellはnull不可はnull不可だが、それ以前に参照型自体が不可だろ。
まあMayBeをnull可能としてそれ以外をnull不可と言うことはできるかもしれんが。

>747
正確には、前スレの407からな。
既にCurlにはその機能が備わってるらしい。
Curlは最近、個人用のライセンスがゆるくなったはずだから
遊んでみるかな。

宣伝乙。心配しなくても誰もcurlなんてマイナー言語使わないよ。

>>750
日本語でおｋ

ヌル不可型を作ると、コンパイル時にヌル不可型の循環参照のチェックが必要になるんだよな?

ヌル不可型の循環参照ってどんなだ？

null不可型は、
・null直接代入禁止
　Object@NonNull obj = null;×
・null不可でない型からの代入禁止
　Object maybeNull = someMethod();
　Object@NonNull obj = maybeNull;×
というだけの話だと思うが。


それより、>>336みたいにEnumやGenerics機構とかを自由に作れる
っつー話の方がそそられるな。

よくわからんけど、型Aが型Aのメンバフィールドを含んでるときに、
型Aがヌル許容型ならどこかでnullにして初期化を止められるけど、
ヌル非許容型なら延々と型Aのインスタンスを初期化し続けなければならないから、
コンパイラはフィールドの定義を辿っていってヌル非許容型の循環を検知したら
エラーを吐かなければならない、ということじゃなかろうか。

お前らまだやってんの？
いい加減バカばっか

型の話してたのか？
「代入時に実体参照しているものしか参照を代入できない」みたいな制限の話してるのかとおもた

>>754
@NonNullは型定義
例class A@NonNull {}
ではなく型適用（その型の変数やその型を使う関数）
例 A@NonNull var; A@NonNull func();
に現れるのでは？

っていうか、NonNull関係なく
class A {
　A membr;
}
みたいな型って、null以外にどういう値があり得るんだ？

>>755=>>348-353？

メンバひとつだと意味はないが、
ほかにメンバがあれば普通にリスト。つーかconsセル。

>>1
＞javaはC/C++からポインタをなくしたりGCを導入することで
＞メモリ管理にまつわるバグを出にくくした

メモリ管理を意識しなくていいアプリ分野ならありがたいが
メモリ管理をやる必要がある組み込みではいい迷惑でしかなかったり。

>>757
class A {
　A@NonNull membr = init(); // <- コンパイルエラー
}

ってことじゃないか

class A {
　A@NonNull membr = init(); // <- コンパイルエラー
　A@NonNull init(){return this;}
}
じゃだめなの？

>759
Javaを使わなきゃいいじゃん

>>759
そもそも、メモリを意識しなくちゃいけないのは、代入型言語ゆえの宿命だよ。

>>763
じゃ、どうすれば良い訳？

そこで関数型言語　Haskellマンセー！！！！！

NonNull を引数に持つメソッド doSomething(A@NonNull a) が与えられているとして

----------------------------------------------------------------------
A something;
if (isTrue()) { // 場合によって、生成方法が異なる
　something = new A(foo);
} else {
　something = new A(bar);
}

// この間に something をいっぱい使う

doSomething(something); // コンパイルエラー
----------------------------------------------------------------------

こんな感じで、どうしても null かもしれないオブジェクトを
NonNull の変数に入れたくなる事があるはず。
　→ コーディング規約で、@NonNull の使用禁止令が出る
　　　→ ('A`)なんだただの java じゃん

>>766
A something = isTrue() ? new A(foo) : new A(bar);

条件演算子の山になるな

A something = function() : A{
　if (isTrue()) { // 場合によって、生成方法が異なる
　　return new A(foo);
　} else {
　　return new A(bar);
　}
}();

A@NonNull something = function() : A@NonNull {
　if (isTrue()) { // 場合によって、生成方法が異なる
　　return new A(foo);
　} else {
　　return new A(bar);
　}
}();

いや、こうか。

>>766
例外含めてすべての経路でヌル以外が代入されてるなら@NonNullへのキャストを許せばいいんじゃね

うん。キャストみたいなもんで事足りる。
>749でも書いてるけど、実際にCurlではヌル可／ヌル不可の機構が搭載されてるから
この機構 (ていうか、型annot.全般) が実用たり得るかどうか心配な人は
Curlを触ってみるといいよ。

|| letは宣言を行う。
{let something1: A = {A}}　 || something1はヌル不可の変数。明示的にインスタンスを生成しないとコンパイルエラー。
{let something2: #A}　|| something2はヌル可の変数。nullで初期化される。

|| setは代入を行う。でもこれはコンパイルエラー。
{set something1 = something2}

|| これはおｋ。キャストみたいなもんだよね。
|| もしsomething2がnullならば、この場でNullReferenceExceptionが発生してくれる。
|| 後でsomething1を使おうとした時に例外が出るよりは、かなりデバッグしやすい。
{set something1 = {non-null something2}}

|| ちなみに、こんな構文糖も用意されてる。
{if-non-null something2 then
　　|| これは {if something2 != null then 〜 } と同じ。
}

バグが出にくいとは関係ないけど、

C++の
include
include
include
include
:

D言語の
import
import
import
import
import
:

とかみててすげー腹立つんだけど、俺だけ？
なんで、近代言語なのに、
uses hoge, mage moge;
みたいにしないんだ？

たしかDのimportは列挙できるけどな
C/C++の癖が抜けてないんだろう

個人的には、uses で横に並べるより include で縦に並べたほうが見やすい。
もうね、横スクロールバー出るくらいまで長く伸びたり、無駄に改行するんだったら最初から縦に並べろよ、って。

なぜ横スクロールは嫌われるのか

縦に比べて妙にスクロール速度が遅い環境が多いからじゃないか？

>>774
横スクロールバーでるまで、長くのばさねーよ、普通ｗ
縦に並べるのは、無駄に改行じゃないのかよｗｗｗ
あおるなら、もう少し、頭つかえ

>775
マウスのホイールは大抵縦向きにしか使えないから。
ちなみにWindowsでは垂直方向のスクロールバーが無ければ、ホイールの回転を水平方向のスクロールに使える。

行指向のエディタを使う限り下に伸びた方が楽
列指向なら横だな

１０個のsymbolを横に書いておくのと縦に書いておくのでは、行指向エディタでは雲泥の差がある

DRY原則の面からいくと、
include
include
include
なんかは、もう目もあてらんねえ

>>777
uses HogeHoge01, HogeHoge02, HogeHoge03, HogeHoge04,
        HogeHoge05, HogeHoge06, HogeHoge07, HogeHoge08;

こういうのが嫌い。

>>780
”いつからインクルードファイルを省略できるようになった？”

>>781
俺は、

#include "HogeHoge01"
#include "HogeHoge02"
#include "HogeHoge03"
#include "HogeHoge04"
#include "HogeHoge05"
#include "HogeHoge06"
#include "HogeHoge07"
#include "HogeHoge08"

こういうのが嫌い
いちいちスクロールするのが面倒だし、
第一なんで、#includeをいくつもかかなくちゃならんのだ？

>>783
uses {
    HogeHoge01;
    HogeHoge02;
    HogeHoge03;
    HogeHoge04;
    HogeHoge05;
    HogeHoge06;
    HogeHoge07;
    HogeHoge08;
}

これなら俺は許せる

縦長にする意味がわかんない。
も前は、配列リテラルも、縦長で書くんか？

a = [
"hoge",
"mage",
"moge",
"sage"]

と思ったけど、enumとかは、縦長で書くこともあることに気づいた・・・。
ケースバイケースか・・・

all.hを作っておいてそこに
#include "HogeHoge01"
#include "HogeHoge02"
#include "HogeHoge03"
#include "HogeHoge04"
#include "HogeHoge05"
#include "HogeHoge06"
#include "HogeHoge07"
#include "HogeHoge08"

んでメインの方では
#include "all.h"

これ基本アルネ

以下C言語におけるincludeプリプロセス文に関するバグの出にくい言語使用が考え続けられます






















（；＾ω＾）

バグも仕様ですと言い張る

>>785
なんかluaのデータ定義っぽい

最近どこかのスレで

class A{
    private int
        countor,
        index;
    private String
        ...
}
見たいに掻いたコード見たんだが
行数増えすぎだろ、これ・・・

>>786
Visual C++だとstdafx.hが正にその役。

>>772
みんな折りたたみ機能持った近代のIDEとかエディタ使ってるから、
そんなに腹立たないんだよ。

>>792
最近のfolding機能は、includeまで面倒見てくるんですかそーですか

少なくともimportは面倒見てくれるけどな
includeは知らん

というか自動的に必要なのを集めるよーなのが言語機能に無いのが悪い

>>795
そんなのバグの元だ。

作らないのが一番いい、氏ね

>797
C++厨乙

null値廃絶と、全ての変数をimutableに。これで単純バグは半減する。
問題は、仕様の解釈ズレによるバグと、仕様の想定漏れによるバグだな。

仕様書のフォーマットを決めるのが先決かも。

NULLはバグを初期の段階で発見するための物じゃないの？
NULLじゃなくて変な値を使うようにしたら見かけ上は動いてるけど中身はおかしいって言う
余計にややこしい状態が起こると思うんだけどどうかな？

＞ NULLじゃなくて変な値を使うようにしたら

いくら言語仕様で頑張っても、底辺はその斜め上をいくって事か…。

そこはほらtypoとか睡眠不足とか人間はミスをするという原則とかそういう関係で

>>799
> 全ての変数をimutableに
構造が複雑になって余計にミスが入り込みそうなんだが。

LISPerが喜びそうだな

>>804
複雑にはならんよ。ただ、考え方の転換が矯正されるだけで。


nullとか型とかも良いが、まずどんなバグがあるのかサーベイしたがよいネタが生まれるのではないだろうか。
http://issues.apache.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__closed__&product=Tomcat+6&content=
この辺りを分析してみるとか。

35880　配布パッケージ作成スクリプトとその実行環境のミスマッチ
39355　オブジェクトプーリングでプールに戻すときのフィールドクリア漏れ
39409　設定ファイルのフォーマット誤り
39803　仕様実装漏れ（コミット漏れ）
40279　バージョンアップに伴う必要な定数更新のし忘れ
40820　設定依存の内部構成状態の考慮漏れ

修正内容が分かる奴を上からいくつかまとめてみた。
こうしてみると、言語で救えそうなのは少なそうだなぁ。

ただし、修正箇所不明の奴が２〜３割くらいあってそれは↑に含んでないので、
それらがどうか分からんけど。

>>1 最近だと、正規表現が使えない! 必要があるのではないか。

>>808
Delphiはバグが少ないのかと個一時間・・・

多いの？

delphiという文字を見るのが超久しぶりな今日この頃です

>>809
Delphiはバグの出にくい言語だと思うが。

現在の平均的なプログラマの技量から言って、単なるプログラムエラーが
最も起こりやすい箇所は正規表現。
ただ、それがバグとして残るかは別問題。
というところか。

久々にみたらハゲの出にくい〜に見えた。
ほぼ同義だから問題ないな

あ

い

途中まで読んで気が付いたけど、糞スレだね。
タイトル読んだ時点で気付くべきだよな。

割とまじめな議論がされていたと思うが。

型とかはコンピューターの物理的制限が表面化したためだろ。
もういいかげん数は数でいいだ、整数も少数も浮動少数もいらない。

理想の数値変数
　変数の定義　SETＳＣＯＰＥの意味（始まりの数、終わりの数、ステップ数）

NO a1 SETSCOPE（0 , 100 , 1）； 　　　　 // 0から100まで1おきの数、それ以外はエラー
NO a1 SETSCOPE（0 , 100 , 1 , ステップ以下切り捨て）； // 0から100まで1おきの数
　　//ステップ以下の数は自動で切り捨て
NO b1 SETSCOPE（0,0000000000 , 10000000000 , 0.0000000001）；

変数の定義に外れたものを入れる場合総てエラーとなる。
変数の定義が違うものを代入する場合は、総て定義変換関数を通す。
a1 = b1．変換メソッド（）；
a1 = b1．変換メソッド（色々な変換パラメータ）；

字も総て字でいい、ASCIIも日本語も中国語も　総て1文字、長さも自由。
ハードの呪縛から開放。

整数と小数は区別したい時もあるな。
例えば文字数とかそういう個数みたいのを扱うなら必要なのは符号無し整数だけ。
でも、そこはライブラリに任せても良いのかも知れないな。
小数や負数を代入しようとしたら例外…いや、切り捨てか？

型はコンパイルタイムの整合性チェック機構だろう。
可能なら出来る仕組みがあった方が方がいい。
型推論や型の強制をするかどうかは用途によるだろうけど、
選択出来るようにするならあって困るものでもない。
実行時にエラー吐いて止まるより、ソース読ませた瞬間にエラーが見つかる方がいいだろう。

>>818の言ってる意味が解らない。型と物理制限？？
Cのintとか限定の話？

> 実行時にエラー吐いて止まるより、ソース読ませた瞬間にエラーが見つかる方がいいだろう。
同意。
動的言語は便利なのだが、特にRuby(Pythonもか？)は、ちょっとした実行時エラーが多すぎる

できるだけ静的型で、かつダックタイピング的なのって可能？
関数型の型推論でできるとは思えんし

＞静的型で、かつダックタイピング
それって、「＋で、かつー」とか「北で、かつ南」とか「蕎麦で、かつうどん」とか言ってるのと同じじゃないの？

C++のtemplateのような総称型がまさにそれじゃないか

>>823
静的型で、動的型と言っているようなものか
いや、確かにそうなのだがｗ

なんていうか、いいところどり？できないものかな、と。
なるたけ、コンパイル時に解決できるところは、コンパイル時に解決して、
バグ減らしたい。

って、それは型推論か

動的言語だと、メソッドのスペルミスひとつで、
コードがそこを通るまで、エラーがわからないなんてのは、どうよ？と思うんですよ
まあ、実践では、テスト主体で開発するだろうが・・・

ただ、ガチガチにすると、method missing的なことができないわけで、
メタプログラミングのうまみもかける

うまく解決する方法はないのだろうか？

>>824 Generic？

C++だとコンパイル時にtemplateのインスタンス化をするから
コンパイル時のダックタイピングができる。
スクリプト言語の実行時のダックタイピングとは、ちと違うような気もするけど。

バグの出にくい言語仕様を語るならまず仕様記述が出来ることは
大前提じゃないか？

>>825
dukc typingでぐぐればC++とかDとかの例が出てくるだろ。

「ユーザーの意図しない動作をしてもよい」と書けばいいんじゃね

それは逆転の発想だな。
ついでに、利用者に損害を与えても良いってのを加えておくと完璧

>>824
現状、C++コンパイル時はある意味
型無し（typenameしかない）なので動的型。

例えばイテレータを引数に取るところにintを渡しても
実行（実体化）を開始してしまう。
結果として、例えばintに単項*演算子が使えないというようなエラーになるが、
これは言わば実行時エラー。

WEB開発ではNULLは天敵。
実行環境が馬鹿すぎて意味不明のエラーが出るから。

フォームを薄くラップしてデフォ値に置き換えてくれるクラスがあればいいのに
フレームワークが提供するクラスはゴテゴテしたものばかり・・・。

>>831
イテレーターにint渡すと、コンパイル時にエラーになるだろ。

（　＾ω＾）？

たとえば、
std::list<int>::iterator it = 10;
は、コンパイル時にエラー。

>>835
その通りのことが>>831にも書いてあるわけだが。

「言わば実行時エラー」ってのは何すか？
どうみてもエラー出てるのはコンパイル時だけど。

>>832
バグが見付け辛くなって涙目

>>837
コンパイル時にテンプレートのインスタンス化がされることを指して、
「言わば実行時エラー」っていってるんじゃなかろうか。

そんなに難解ではないと思うが

テンプレートは実行時に解釈されてるって理解してるってことかな? 381は。
テンプレート使っていてエラー出したことがあれば、そういう勘違いって、しようがないと思うけど。

templateのinstantiation後のエラーを実行時エラーと呼ぶのか・・すげぇ違和感

templateにとってはコンパイルそのものこそが実行だからな。バイナリの実行とは別の話。

関数の戻り値をコンパイル時に定数に畳み込んだりするような場合に発生したエラーは、
広い意味で実行時エラーと呼んでも差し支えないのではなかろうか。

>>843
「実行時」という言葉を定義した意味がなくなるまで「実行時」の意味を広げてどーするんだ……

もう無茶苦茶だな。そんなわけの分からない用語定義はこのスレの中だけに留めて貰いたい

>>839
普通、「実行時エラー」と言えばコンパイル後、バイナリの実行時のことだろ。
何が「いわば」だ

いわゆる文学的な表現という奴か。

コメント書かないとわからないコードを書くヤツは馬鹿です。
コメント書いてもらわないとコードが読めないヤツも馬鹿です。

対象がテンプレートであることは明白なのだから、>>831の
>実行（実体化）を開始してしまう。
で意味がわからないほうがアフォ

>>822
> 動的言語は便利なのだが、特にRuby(Pythonもか？)は、ちょっとした実行時エラーが多すぎる

動的言語を使う以上はpycheckerのようなlint系ツールは必須だと思うが。

>>849
俺の言う事がわからない奴はアフォ、ってか？

>>851
俺は>>831じゃないが、>>826からの流れが読めてれば常識でわかるだろ、初心者さん。

常識でわかる、と>>831も考えてるなら「言わば実行時エラー」みたいな曖昧な表現はしないだろ。
常識ではわからないだろう、と考えてるから「言わば」とか「実行（実体化）」なんて但し書きが必要になるんだよ。

飽きないなお前ら。
>831 なんざ、斜に構えて気取ったこと言ってるつもりになってるだけだし、こんなことを言い出したのは >831 が最初じゃないどころか飽きるほど見たし、言及する価値はない。
>831 が何を言いたいかを理解できない奴には、それこそ構う価値はない。

>>853
その但し書きがあるからわかるだろって言ってんの、おバカさん。

>>855が>849なら：
じゃあ別に>>826からの流れが読めたのが理由ではないんだな

>>855
但し書きがあっても非常識だが。

>>854
>831 が何を言いたいかを理解できない奴には、それこそ構う価値はない。

たぶん、テンプレートがコンパイル時に評価されることを最近知ったボクチャンなんだろうね。

バグの出やすそうな流れだなｗ

もう int 型はアドレスの任意の場所を指して書き換えて実行できる型ってことでいいよ。
ぜんぶ int。

いや、byte型のほうが優れている。
ぜんぶbyte。

いや、全部オブジェクトで

メモリ全体で1つのオブジェクト。
これならGCも不要。

型がどうこうはもうわかりきってるだろ。静的型付けで型推論がいいに決まってる。
ほかに必要なのはS式な。

バグが出ない言語仕様には２種類の方向性がある。

・プログラマが誤解する余地が入らないようにする。
　例） 静的な型、コンパイル時の警告など

・誤解するようなプログラマには利用できないようにする。
　例） S式を導入する。
　　　　FuzzBuzz問題を解かせる。
　　　　4桁の数字と四則演算と括弧で10を作らせる。

> ・誤解するようなプログラマには利用できないようにする。
ワロタ

バグの出にくい言語使用の言語を作れる知識
を習得するまでパソコンの前で正座。

＞FuzzBuzz問題を解かせる。

ハンガリアン記法を強制する言語

バグをあらかじめ定義しとけばいいじゃない

プログラムをプログラム本体とlintの署名の組として定義する。
lintはプログラム本体を入力として、末尾に暗号を用いた電子署名をappendする。
コンパイラはlintの署名のないプログラムは拒否する。

これだけで世の中のバグのかなりは防げるヨ

バグの無いプログラムは存在しないが
デバッグの不可能なプログラムも存在しない

って、アニメで言ってたよ

>>870
代わりにバグの定義から漏れる不具合、が出てくるだけ。
それをバグと言えなくするだけなら単なる言葉狩り。

>>871
なんでそんな回りくどいことを？？
役所でででもプログラム組んでるの？

lintをコンパイラに内蔵して、通らないとエラーにしちまえばいい話。
warningsもエラーにしろ、とかそういう話。

>>874
lintが出すwarningとコンパイラが出すerrorの違い、わかってる？

lintが出すwarningとコンパイラが出すerrorの違いが分からない奴が
プログラムを組むからバグが出るんじゃないか

どんな言語仕様でもタコは思いも付かないようなことをしでかす
個人的には現状で最もバグが出にくいシステムを作りたいなら
馬鹿をシステム開発に参画させないことだ

今のシステム開発はメスも握ったことの無い素人に
盲腸の手術をさせているようなもの
手術ミスが少なくなる道具は必要だが、
まずは素人に手術をさせるという愚挙を行わせないことから手をつけるべきだと思う

>>875
ぜひ解説してくれ

俺は、コンパイラのwarning（最大出力）もエラーと見なす派

>>877　875ではないが
コンパイラの警告とlintの警告は別物だ
例えばC言語でコンパイラの警告を最大にしても
#include <stdio.h>
int main(void) {
printf("hoge");
return 0; }
は正常にコンパイルできるが、lintでは
#include <stdio.h>
int main(void) {
(void)printf("hoge");
return 0; }
としないと．．．
# あれ？Linuxのsplintだと警告が出ると思ったんだが．．．オプションが必要か？
警告が出るlintもある

また、printf("hoge");はprintf("hoge\n");と書きたかったバグかもしれないが
この類のバグはどんな言語仕様やツールを使っても検出できない

言語仕様に合致しないプログラムに対して合致しない旨を告げるのがコンパイラが出すエラー
言語仕様に合致しているが、その意味がプログラマの意図と合致していない可能性が比較的高いものに対してい
警告をするのがlintが出すwarning。
どんな言語でもその仕様に関心を払わないバカにかかれば
バグを出さずにはいられない。

>>878
逆に言えば上のコードに警告出すコンパイラがあったっていいよな。
見たことないけどさ。

コンパイラのwarningは言語仕様から見た危険な可能性のあるコードに対して出される。
lintのwarningが出る基準は、その言語を使用した経験から得られたノウハウ。

pylint features
http://www.logilab.org/card/pylintfeatures

Python の文法チェックには何を使う？ lint はないの？ - 傀儡師の館.Python - 楽天ブログ（Blog）
http://plaza.rakuten.co.jp/kugutsushi/diary/200711240000/

なるほどなー。
コンパイル時にチェックできないエラーとなりそうなものや、
変数の名付け方まで見てくれるのか。

int main(void) {
return main(); }

Haskellみたいに
・馬鹿には開発できない
・代入が存在しない
言語を使えばいいと思うが、そもそも上の利点はそのままバグになるからな。
世の中天才だけじゃないんだよ。

それは全然バグじゃないだろ

Haskellはメモリ喰いまくるバグが(ry

>>886
それは仕様であってバグではありません。

醗酵＝人が計画的に管理して大切に大切に腐らせること
腐敗＝なんだかよくわかんない内になんだかよくわかんないものに腐っちゃうこと

この速さなら言える！
実は、俺はまだ >>874 に対して >>875 以降のようなレスがついた理由を理解していない。

>>871 みたいに開発を厳格にしたいなら、
コンパイラとlintを一つのソフトウェアにまとめちゃえば手っ取り早いよな、というのは
特におかしくない意見だと思った。
# まー俺なら、出来合いのコンパイラやlintをいじるスキルなんてないから
# バッチファイルやシェルスクリプトで解決するだろうけど

んで、俺考えたんだけど、>>875 以降のレスの要点はつまり
「その一つにまとめたソフトウェアは『コンパイラ』とは呼べないよな」って事？
つまり >>874 が用いた「lintをコンパイラに内蔵」という表現は、言葉の定義上あり得ない事だと。
ならば納得だけど。

>>889
lintの警告は正しいプログラムでも起こりうる、
そして、lintのエラーはgccならほぼ網羅している為、
gccもlintがエラーだったらエラーにしている
# gcc以外のコンパイラは良く分からん

lintの警告が正しいのか正しくないかを判断できるのは人間だ

> 「その一つにまとめたソフトウェアは『コンパイラ』とは呼べないよな」って事？
違う、それはもう既に実装されているし、今だってプリプロセッサ〜リンカまでの
一連の操作を「コンパイル」と呼んでいる。
そして、>>874が叩かれているのは
lintの警告とlintのエラーの区別が付かない馬鹿だからだ

ま、>>871の署名をしたとしても、せっかくlintが診断してくれた警告を無視して
本来はバグなのに、コンパイラに通すことは起こりうる
が、それはプログラマのモラルの問題であり、
それは言語仕様ではどうすることもできない。

>>890
そういう場合は、コンパイル結果に「このコードはXXX個の警告を無視してコンパイルされました。
自己責任で実行してください」というダイアログを出す機能を追加すればよい。

>>891
exe配布したりrpmやyumで実行環境作ってる初心者向けには
そういうシステムは必要かもしれないが

インストール時に必ずソースからコンパイルさせる習慣があれば
そんな心配はしなくて済むな

>>891
lintの警告の数を数えても無駄だよ。
問題は内容だから。
で、>>890の言う通り、警告の妥当性は人間にしか判断できない。
それがlintのlintたる所以。

いい加減、lint を擬人化すべきだと思うんだ。

lintは空気

山口勝平 出演作品
カウボーイビバップ（リント）
ttp://ja.wikipedia.org/wiki/%E5%B1%B1%E5%8F%A3%E5%8B%9D%E5%B9%B3

女を庇って金貸しを殺してしまい賞金首になってしまった哀れなキャラです
最後は賞金稼ぎである主人公らの活躍によって捕まり警察に引き渡されます

短いコードのほうが、バグが入りにくい。

関数型はあんまりデバッグしないな
Pugsとかそういう規模のは知らんけど

>>898
デバッグというか型整合が取れるまでのデバッグが長い。

関数型言語はボトムアップでコーディングするほうがあってるのかな？

方針ならともかく、合うかどうかなんてあるのかね。
好きなように書いたらいいんじゃね。

出にくく出来ても出なくはならない。
どっちかっつーと、バグを見つけやすい言語仕様（ライブラリ？開発環境？デバッグ環境？）の方を望む。

ここ最近はログ追っかけでのデバッグしかしてねーorz

どっちもじゃね？
バグを埋め込みにくい環境（変数型とか）
埋め込んだとしても発見しやすい環境（assertとか）

いや、ま、たしかに、そうなんだけど、さ....

プログラムが動けない仕様にする。
そもそも、どうやったって動かないのだから、バグは出なくなる。
意味は無さそうだが。

強力なトレース機能がほしい。
理想としては自分でトレース用コードを埋め込んだりする必要が全然無くて
それでいて、欲しい情報を的確に吐いてくれるやつ。

デバッガでもいいんだけど、あれはあれで結構面倒くさいしね。

python の cgitb とか良いよ

>>906のような低能が欲しがる情報なんて予想できるわけがない

> それでいて、欲しい情報を的確に吐いてくれるやつ。

プログラマなんだから、もう少し具体的に仕様定義しようよｗ

>欲しい情報を的確に吐いてくれるやつ

あなたはこの作業に向いていません

っつーメッセージ出しときゃいい罠

型の上限以外に、Upperbound、Lowerboundのある組み込み整数型が欲しい。

このスレで出たアイディアをサッと実装してみんなで感触を確かめてみる
つーのができると、もうちょっとこのスレも盛り上がると思うんだ。

>>911
PASCALとか、整数の範囲指定あったような気がする。
Modula-2だったかもしれん。

>>911
pascal / delphi

範囲型って、演算に閉じてないと静的保証にはならんだろ。
範囲外れたら実行時例外、なんてのは、数値型をサブクラス化できれば済む話。

誰が静的保証しろと言ったんだろ・・・
こんなの実行時検査しかしようがないと思うが、
>>915は何を期待しているんだろう・・・

値の制限に達しているかを確認可能なメモリを持ったハードウェア？

>>917 それも実行時チェックだろ。

>>917
どこのJVM

普通の整数型も範囲型の一種と考えられなくもない
char = -128...127
short = -32768...32767
int = -2147483648...2147483647

>>920
残念ながら規格の範囲は-127〜127だ。

>>920
おまいが挙げた範囲は特定の処理系での話な。

まあ、Cとも書いてないし、環境依存の話だろう。

Cだとunsignedの可能性もあるし

Cだとしてもintのビット幅は処理系依存だし

整数型がキャリーオーバーしたら例外になる言語？

>>916
静的保証がないならライブラリで実現できるから、言語仕様と言うほどのモノじゃないと言うことだろう。

いや、有る無し以前に、静的保証しようがないだろ。

演算を全てコンパイルエラーにすればいいんじゃね？

定数同士の演算もか？

>>926
言語とライブラリが結びついてるなんてザラってかどっかにエンジンとのグルーコードかかないと何も出来ないだろ

実行時検査だって厳密にやろうとすればコンパイラ等に手を入れなければ話にならんだろ…

Ｃ＋＋なら、クラスを定義すればモーマンタイ。

>>931
だから、実行時検査ならコンパイラなんていじらずにクラス定義で十分だって話だろ。

>>933
そんなこといちいちオブジェクトでやってたら無駄以外の何者でもないがな。

ほうほう、ではコンパイラだったら、どんな凄いことをしてくれるんだ？

やっと>>911に帰結したか。
>>935
クラスだとオーバーヘッドが大きいけど、現在の組み込み型では不足するような機能を新たな組み込み型として定義できるということだよ。
例えばC++0xのenumクラスとか。

おいおい、結局サブクラスで演算子をオーバーロードすれば良いだけだろ。
コンパイラがやったところで変らんだろ。
組込みだろうがライブラリだろうが、実行時にチェックするんだから変らん。

暗黙的にC++に流れが進んでいるのにﾜﾛﾀ
お前ら少しは他のパラダイムの言語を勉強しろよｐｇｒ

Haskellだって、Lisp(CLOSS)だって、演算子をオーバーロードできるぞ。

>>937 はクラスと組み込み型の違いがわかっていない

>>940
へぇ。じゃあ、賢い君が説明してよ。
範囲チェックの仕組みをライブラリでやるのとコンパイラがやるのとで、
何がどんだけ違うのか。++限定の話は++限定と明示してお願いね。

演算子をオーバーロードして値の範囲を限定する時には、
当然だが演算結果の範囲を指定することになる。

コンパイラが整数型の変数の値の範囲を限定する時には
演算結果ではなく、その変数への代入される値の範囲を指定することになる。

この違い、わかるよな？

そろそろ低レベルの話はやめようぜ

>>942
代入演算子のオーバーロードとの違いを教えてくれないか？

>>944
具体的にどの言語の話だ？

>>945
任せるよ。あんま突飛な例でなければ。

>>942
マシン語レベルで差がでるって言ってるのか？

代入演算子のオーバーロードができる言語なんてごく一部だろうに

もしかして
a=b+c+d+e+f;
てな式があったときに＋演算子オーバーロードなら4回、値の範囲の判定が必要だけど組み込み型なら1回ですむ。
という主張なのかなぁ

特殊な範囲の場合などにCPUのフラグや例外やその他特殊命令等を活用できる可能性のある組み込み型のほうが有利というなら理解できる

>>950 （= >>940 = >>942 = >>945）は、説明になってない、というよりただの空想。

ところで、XML Schemaには、型の拡張(extension)と、型の制限(restriction)がある。
プログラミング言語でもこれを取り入れるのはいい気がする。

そもそも、このスレは空想をするスレ。

実装する気はないという意味では空想だが、
意味を成さないデタラメという意味の空想は対象外。

>>951
D言語(MSのじゃなくて)

値域のチェックに、代入演算子のオーバーロードって話が出てたけど、
型の属性やアノテーションに特別な種類を用意して、
元の型からはダウンキャスト必須にして、
キャストの演算子オーバーロードを用意させる、って方が良い気がする。

int@odd o = (odd)13;
int n = o;//OK
int@odd p = n;//コンパイルエラー
int@odd q = (odd)n;//OK
int@odd r = (odd)24;//実行時エラー


annotation odd restricts int {
　　operator int(n) {
　　　　if (n%2==0) {
　　　　　　throw TypeCastError("%d is not odd number.", n);
　　　　}
　　　　return n;
　　}
}