5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :デフォルトの名無しさん:2006/01/16(月) 20:16:10
javaはC/C++からポインタをなくしたりGCを導入することで
メモリ管理にまつわるバグを出にくくした。
そのような考えを推し進めてバグの出にくい言語仕様を考えよう。

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


2 :デフォルトの名無しさん:2006/01/16(月) 20:17:29
>>1は根本的なことを判っていない。
プログラムが無ければバグも出ない。
つまり、言語仕様を考える前に、
如何にしてプログラムの存在しない世界を作るか、
を考えるべきだ。

3 :デフォルトの名無しさん:2006/01/16(月) 20:26:42
バグを出にくくするためには、

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

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

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

4 :デフォルトの名無しさん:2006/01/16(月) 21:56:18
これまた>>2に思い切った電波を仕込むアグレッシブなスレだな

5 :デフォルトの名無しさん:2006/01/16(月) 23:23:28
>>2
>>>1
> ロ
>  り
>
>      だ。

なるほど、そーなのか。

6 :デフォルトの名無しさん:2006/01/16(月) 23:32:28
>>5の想像力に脱帽。


7 :デフォルトの名無しさん:2006/01/16(月) 23:59:49
>>2
> >>1
>   グ
>
>       ロ        い
>        。

なるほど、そーなのか。

8 :デフォルトの名無しさん:2006/01/17(火) 00:18:38
なんで、馬鹿が粘着してるの?

9 :デフォルトの名無しさん:2006/01/17(火) 00:21:23
前スレの結論めいたレス

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


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

10 :デフォルトの名無しさん:2006/01/17(火) 00:22:05
前スレの結論めいたレス

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

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


11 :デフォルトの名無しさん:2006/01/17(火) 00:22:55
前スレの結論めいたレス

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

12 :デフォルトの名無しさん:2006/01/17(火) 00:24:17
関連スレ

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

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

13 :デフォルトの名無しさん:2006/01/17(火) 00:45:28
バグの無いプログラムをバグが出ないように組み合わせれば、、、

14 :デフォルトの名無しさん:2006/01/17(火) 05:21:55
それでもバグは出る。

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

16 :デフォルトの名無しさん:2006/01/17(火) 08:45:39
じゃあおまいらは超強力な型付け方面で議論しててくれ。
俺はスレッド絡みのバグをなくす方向で検討してみる。

17 :デフォルトの名無しさん:2006/01/17(火) 08:46:47
行列演算向けにWikiみたく
E=| 1 0 |
  | 0 1 |;
みたいな表現をする言語があったら面白いと思うんだが

18 :デフォルトの名無しさん:2006/01/17(火) 10:11:56
じゃあ作ってみろ。
話はそれからだ。

19 :デフォルトの名無しさん:2006/01/17(火) 11:27:37
型が違う変数への代入を出来なくすれば良いだけのような

20 :デフォルトの名無しさん:2006/01/17(火) 11:40:27
>>19
PASCALとか?

21 :デフォルトの名無しさん:2006/01/17(火) 12:26:34
2次元配列?

22 :デフォルトの名無しさん:2006/01/17(火) 12:40:39
>>16
http://pc8.2ch.net/test/read.cgi/tech/1110031339/
http://pc8.2ch.net/test/read.cgi/tech/1047230229/

23 :デフォルトの名無しさん:2006/01/17(火) 21:49:27
          ,′  //,,-‐"//ヽ ヽ
          l    |'〆-‐/' ‐-ゞ l
           |     |'   _       l| |
          |    l ,r7〒  〒=、/ l
          l∧.,∧|',弋ノ‐、 ,弋ノ、/l
           l:;、;:::;:lヘ_  _.ノ ̄、_ _ノ:;l
.        || ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄|
     .__ ||                      |
     ヽヽ||     トイレ            |
      t==、                       ,=、
      l '=',    行ってくるね        `=3
        ヽ'||'                         |`′
.        ||                      |
.        ||                      |
.        ||______________|

24 :デフォルトの名無しさん:2006/01/17(火) 21:53:40
>>17
s/|\s*(\d*)\s*(\d*)\s*|/{ $1, $2 },/e

25 :デフォルトの名無しさん:2006/01/17(火) 22:04:24
このスレ読んでると
データベース言語ってのは全体的に良くできてる言語だと思うんだが
気のせいか

26 :デフォルトの名無しさん:2006/01/17(火) 23:00:10
>>25
今のところ「いい」プログラミング言語は、
Pascalに代表されるように、少なくとも自己記述能力がある。
と考えられている(かも)

その点どうよ?

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

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

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


28 :デフォルトの名無しさん:2006/01/17(火) 23:20:02
前スレ975のケース
int a = 1;
int b = 3;
float c = a / b;
についてだけれど、コンパイラがfloat c= まで読んだ時点で
=の右辺をfloatの文脈とする言語があっても良い気がする。
つまり、型を決めるのはデータの供給側でなくて需要が決めるという言語。

29 :デフォルトの名無しさん:2006/01/17(火) 23:56:29
c:=
懐古に戻る

30 :デフォルトの名無しさん:2006/01/18(水) 00:39:00
>>28
君言語だと、

int i = 0.9 + 0.2;

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

31 :デフォルトの名無しさん:2006/01/18(水) 00:41:21
>>30
俺は28とは別人だが、縮小方向への型変換になるときにはエラーを出すというはどうだろう?
その場合、それが必要なら当然キャストすれば良い。

32 :デフォルトの名無しさん:2006/01/18(水) 01:09:58
>>25
DB言語ってSQL? どういうのが良くできてるん?

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

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

34 :デフォルトの名無しさん:2006/01/18(水) 01:17:31
> aをfloatにしろっていうのなら無茶だ
> c = a/b;
> はつまり
> c = divide(a,b);
> なのであってaは代入から直接は見えない

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

35 :デフォルトの名無しさん:2006/01/18(水) 01:18:30
>>31
そして誰もがキャストしはじめる

36 :デフォルトの名無しさん:2006/01/18(水) 01:49:55
>>29
俺も同じ事考えたことがある。
ただ、俺なりの回答では、それは「No」だね。
理由は単純
「それは美しく、またハッキーではない」
実際、代入はあまりに頻繁に使うから、1タイプ多いだけでも割に合わないんだよね。利点の部分も認めるけど。

37 :デフォルトの名無しさん:2006/01/18(水) 01:58:18
変数名もa〜zのひと文字で済ますような奴は、このスレで語る資格すらねえよ

38 :デフォルトの名無しさん:2006/01/18(水) 09:03:31
c <- a+b;

39 :デフォルトの名無しさん:2006/01/18(水) 09:13:52
int a = 1;
int b = 0;
float c = a.0 / b.0;


40 :28:2006/01/18(水) 11:00:51
>>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
そもそも、計算というのは何かに利用するために計算するのであって、
元のデータから押し売りする訳じゃない。
そう考えると需要が型を決めるというのも不自然ではないと思うが。

41 :デフォルトの名無しさん:2006/01/18(水) 11:39:05
宇宙計算に使える計算機を発達させれば宇宙開発言語が発達し計算精度が気になってくるはず
姉は設計に任せても計算精度が高いソフトが出来上がる


42 :デフォルトの名無しさん:2006/01/18(水) 12:47:16
仕様のバグの方が多いんだから、まずはそっちを何とかしろと。
あとは、仕様からコード生成する仕組みを作ればおしまい。

43 :デフォルトの名無しさん:2006/01/18(水) 12:58:27
かつて、FORTRANで書いてコンパイルすることを
「自動プログラミング」と言っていたのを
思い出した。

44 :デフォルトの名無しさん:2006/01/18(水) 13:12:28
>>42
言語仕様というより、
論理プログラミングを理解できない者には
一切の資格を与えないようにすればよい。

45 :デフォルトの名無しさん:2006/01/18(水) 13:16:20
>>42
MDAとかxUMLか?
http://ja.wikipedia.org/wiki/仕様記述言語

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

46 :デフォルトの名無しさん:2006/01/18(水) 14:55:59
>>17
APLとかその辺じゃだめ?

47 :デフォルトの名無しさん:2006/01/18(水) 14:59:55
>>40
なんだ?
結局型無し言語マンセーなだけか


48 :デフォルトの名無しさん:2006/01/18(水) 15:01:39
int型じゃなくてdouble型で整数しか取らない型ってのがあれば良いんじゃないのか?

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

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

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


50 :デフォルトの名無しさん:2006/01/18(水) 16:50:34
>>40
カッコ良い。
rubyの場合、引数の型が変わるときって
s = 12.to_s + 34.to_s #s="1234"
i = "12".to_i + "34".to_i #i=46
と書かないといけないんだけど、常々これって「気持ち悪い」
と思っていたので。

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

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

51 :笹井奈琴/289:2006/01/18(水) 22:35:17
>>40
int i = "12" + "34";

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

52 :デフォルトの名無しさん:2006/01/18(水) 22:44:39
どうでもいいよ。
小数なんて使わないから。

53 :デフォルトの名無しさん:2006/01/18(水) 22:50:46
基本型としては数値型と文字列型だけでいいんじゃない?

54 :デフォルトの名無しさん:2006/01/18(水) 22:54:18
数値型はいらないだろう。

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

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

c←+←a
  ↑
  ↑←b
トップダウン・欲しいもの指向で考えるのが今考えている言語流。

更に思いついた例
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みたいなことをしたくなる心理じゃないかと思うけど、どうよ?


56 :28:2006/01/18(水) 22:59:04
>>51
int i =string("12"+"34");

57 :デフォルトの名無しさん:2006/01/18(水) 23:17:16
> c言語で
>     int a = 1;
>     int b = 3;
>     float c = a / b;
> で計算すると c=0 になってしまいます。
>     float c = 1.0 * a / b;
> だとちゃんと c = 0.3333 になります。
> これって結構バグの温床になっているような気がするけど、
なってません。

58 :デフォルトの名無しさん:2006/01/18(水) 23:27:12
>>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";

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

59 :デフォルトの名無しさん:2006/01/18(水) 23:34:19
よく使われるデザインパターンを文法的にサポートしてくれるといいかなーと思った。
イメージとしては、例えば Java の拡張forループみたいな感じに。

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

60 :デフォルトの名無しさん:2006/01/19(木) 00:02:35
テストパターンを自動的に作成してくれる言語が欲しいね。
あと、コードを変えたとき影響を受ける部分を可視化できる言語。
(非常に強く影響を受ける部分は赤で、たぶん影響を受ける部分は黄色で表示するとか)

61 :デフォルトの名無しさん:2006/01/19(木) 00:09:04
それって、言語じゃなくて開発環境じゃないの

62 :デフォルトの名無しさん:2006/01/19(木) 00:11:33
このすれに少しでも期待した俺がバカだった、、、、

63 :デフォルトの名無しさん:2006/01/19(木) 00:12:28
Enumをキャストしなくてもループカウンタに使えるといいな

64 :デフォルトの名無しさん:2006/01/19(木) 00:16:48
>>63
foreach i of enum型名
みたいな感じ?

65 :デフォルトの名無しさん:2006/01/19(木) 00:17:44
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; //エラー
}

66 :デフォルトの名無しさん:2006/01/19(木) 00:20:47
enum型の変数名では?

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

67 :デフォルトの名無しさん:2006/01/19(木) 00:21:39
言語仕様でバグ減らそうなんてのが甘いんだよ。
C++からJavaに移ったけど、全然バグは減ってない。


68 :デフォルトの名無しさん:2006/01/19(木) 00:27:21
まあ、BUGの原因がどういう物であるかを考えれば、どんな言語を開発した所で減るわきゃないんだがな。

69 :デフォルトの名無しさん:2006/01/19(木) 00:27:45
>>40
+ :: string -> string -> number とかがあれば良いだけかと。


70 :デフォルトの名無しさん:2006/01/19(木) 00:29:17
バグを見つけやすい、まではどうにかなるかもよ。

71 :デフォルトの名無しさん:2006/01/19(木) 00:34:05
まずは、オペレータとなる記号に複数の意味を持たせないって単純な所から始めようぜ。

72 :デフォルトの名無しさん:2006/01/19(木) 00:37:56
現状で一番望まれるのは、>>42なんだろうな。バグの割合からして。
しかしそれをどう言語でサポートできるかというと、>>45の言うように
検証可能な言語で仕様を書く、というのは、プログラミングそのものに思えるんだが、
仕様記述言語というのを使ったことある奴に意見が聞きたい。


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


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

73 :デフォルトの名無しさん:2006/01/19(木) 00:43:04
アセンブラで面倒なのは、バグが起きたときどこがどうなってるのかわかりづらいこと。
慎重になるからか、バグの件数そのものはそんなに多くない。

74 :デフォルトの名無しさん:2006/01/19(木) 01:09:14
javaは配列はいらんと思う。
配列をメソッドに渡したときにメソッド内での変更が元の配列に反映されることを知らない人を
何人か見たことがある。

75 :デフォルトの名無しさん:2006/01/19(木) 02:22:26
じゃあ、すべてpass by valueにするか。deep-copyで。
配列の問題じゃないし。

76 :デフォルトの名無しさん:2006/01/19(木) 02:31:37
Javaにconstがあればいいのに

77 :デフォルトの名無しさん:2006/01/19(木) 03:00:53
なんでないんだろ。あんま、使われないのかな。const char*以外。
C++よく知らないけど、普通に使ってる?
Javaのfinalも、いわゆる定数以外あんま使わないしな。

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

78 :デフォルトの名無しさん:2006/01/19(木) 03:39:24
【C++】 const だけでメシが3杯食えちゃうスレ
http://pc5.2ch.net/test/read.cgi/tech/1078193971/

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

79 :デフォルトの名無しさん:2006/01/19(木) 06:57:58
Perlが出てきてからおかしくなったんだよ

80 :デフォルトの名無しさん:2006/01/19(木) 11:09:51
Perlで$キーの擦り減りが良くなった 今は見えない

81 :デフォルトの名無しさん:2006/01/19(木) 12:53:32
>>72
おめぇら、形式的仕様記述について知ってる事を書け
http://pc2.2ch.net/test/read.cgi/tech/1013507313/


82 :デフォルトの名無しさん:2006/01/19(木) 13:40:46
記号だらけの言語って言葉で伝えるときに苦労するんだがPASCALやCOBOLみたいにならないか?

83 :デフォルトの名無しさん:2006/01/19(木) 14:20:47
Prologみたいにならないか?

84 :デフォルトの名無しさん:2006/01/19(木) 14:36:13
ゲーデル数だけにしよう。

85 :デフォルトの名無しさん:2006/01/19(木) 22:10:34
>>49-50
つまりメモリいっぱい積んであれば型なんか気にしなくていいよ
っていうことか。メモリいっぱい欲しいな。

86 :デフォルトの名無しさん:2006/01/19(木) 22:15:23
>>85
CPUの速さも欲しい。

87 :デフォルトの名無しさん:2006/01/19(木) 23:50:50
ここは理想を語るスレ。
資源は無限にあると考えてよかろうて。

88 :デフォルトの名無しさん:2006/01/20(金) 00:44:04
文字列結合は”+”でない方が良い

89 :デフォルトの名無しさん:2006/01/20(金) 00:45:57
すべての入力パターンを事前に検証すればいい。
量子コンピュータなら可能だろう。

90 :デフォルトの名無しさん:2006/01/20(金) 10:47:34
英語のスペルは省略しなくていい

91 :デフォルトの名無しさん:2006/01/20(金) 14:40:15
Cみたいなプリプロセッサはいらない

92 :デフォルトの名無しさん:2006/01/20(金) 14:43:27
文系にしてみれば記号が見えた時点で死ぬと思う

93 :デフォルトの名無しさん:2006/01/20(金) 15:58:45
変数と関数名に日本語が使えると見通しがよくなりそうな気がするな。

94 :デフォルトの名無しさん:2006/01/20(金) 16:02:52
関数や変数にコメント必須にするとか

95 :デフォルトの名無しさん:2006/01/20(金) 16:03:44
一番問題なのは識別子にスペースやカンマが入らない点
場当たり的にクオートじゃ成り立たないんだよ文型は
全角なら通るけど半角なら通らないとかなるとまたまどろっこしくなってくるし
スペースの大きさ測るのに専念することになっていらいらする

96 :デフォルトの名無しさん:2006/01/20(金) 16:22:14
>>93
変数名や関数名は一意の記号でも良いと思う
それと簡単に意味や内容とが一致できるようなIDEとセットじゃないと意味が無いが

97 :デフォルトの名無しさん:2006/01/20(金) 16:29:10
>>95
Program Files ですか

98 :デフォルトの名無しさん:2006/01/20(金) 16:29:41
>>93
-とーと一を間違えそうな予感。

99 :デフォルトの名無しさん:2006/01/20(金) 16:35:09
>>93
できない言語ってどんなものがあるのですか。

100 :デフォルトの名無しさん:2006/01/20(金) 17:05:28
>>99
あくまで気がするだけだ
日本語の名寄せを甘く見るなよ

101 :デフォルトの名無しさん:2006/01/20(金) 17:07:08
できる言語ってどんなものがあるのですか。

102 :デフォルトの名無しさん:2006/01/20(金) 17:20:16
日本語プログラミング言語ひまわりとか

103 :デフォルトの名無しさん:2006/01/20(金) 17:22:25
COBOLも識別子は日本語でよかった
LISPもいいのかな多分
Smalltalkは発作的に日本語コードを覚えられる
あんまり重要な分野じゃないから省かれた

104 :デフォルトの名無しさん:2006/01/20(金) 17:30:49
Rubyもつかえるはず

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

105 :デフォルトの名無しさん:2006/01/20(金) 17:33:53
UTF通すようにすれば問題ないんじゃね??wwwwwwwwwww

106 :デフォルトの名無しさん:2006/01/20(金) 17:44:19
>>104
激しく否定。character数を1:2と考えても、
一単位あたりの漢字の表意力はAlphabetより上。

107 :デフォルトの名無しさん:2006/01/20(金) 17:45:40
特許申請に持っていける言語を作ればいい

108 :デフォルトの名無しさん:2006/01/20(金) 17:49:16
>>107
100年後ぐらいまでに

109 :106:2006/01/20(金) 17:50:18
ごめん。ポータビリティとは関係なかった。

110 :デフォルトの名無しさん:2006/01/20(金) 17:54:56
関数名に漢字が使えないとすると、「雪は白い」のプログラム

白い(雪).

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


111 :デフォルトの名無しさん:2006/01/20(金) 18:02:12
>>110
#define 白 Shiro
#define 雪 Yuki

112 :デフォルトの名無しさん:2006/01/20(金) 18:03:53
それだとそもそも何をする関数なのか検討もつかないんだが・・・
まあ
shiroi(yuki);
でいいよ

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

113 :デフォルトの名無しさん:2006/01/20(金) 18:08:06
雪.色=白;

114 :デフォルトの名無しさん:2006/01/20(金) 18:10:19
VBは4.0から出来たな
Javaも可能
C#をふくむ.NETはだいたいできる

115 :デフォルトの名無しさん:2006/01/20(金) 18:23:18
>>112
この場合は?
電子計算機を使用して源泉徴収税額を計算する方法を定める財務省告示(_給与等,_社会保険料,_配偶者扶養親族等合計,_税額) :-
  _社会保険料控除後の給与等の金額 は _給与等 - _社会保険料,
  別表第1(_社会保険料控除後の給与等の金額,_給与所得控除の額),
  別表第2(_配偶者扶養親族等合計,_配偶者控除額),
  _その月の課税給与所得金額 は _社会保険料控除後の給与等の金額 - _給与所得控除
の額 - _配偶者控除額,
  別表第3(_その月の課税給与所得金額,_税額) .

116 :デフォルトの名無しさん:2006/01/20(金) 18:30:04
クラス名は名詞、関数/メソッド名は動詞、
双方とも形容詞は論外
って考えてるのは俺だけかなぁ

117 :デフォルトの名無しさん:2006/01/20(金) 18:41:29
>>115
一字でも間違えたら大変な事になりそうだ。

118 :デフォルトの名無しさん:2006/01/20(金) 18:46:37
財務省のサイトから直接取って編集するだけ。

119 :デフォルトの名無しさん:2006/01/20(金) 19:42:31
コメントに書いた変数の右側の注釈がIDE上のエディタでポップアップで出せるようになればきれいに書けないか?

120 :デフォルトの名無しさん:2006/01/20(金) 19:52:27
むしろ、ラインを引くほうがいい。
それを手繰っていけば宣言と使ってるところが分かるように。

121 :デフォルトの名無しさん:2006/01/20(金) 21:55:37
>>113
>>110の「雪は白い」という仕様の中に色という情報はない。

122 :デフォルトの名無しさん:2006/01/20(金) 22:02:26
assert(雪==白)

123 :デフォルトの名無しさん:2006/01/20(金) 22:43:06
春は曙


124 :デフォルトの名無しさん:2006/01/20(金) 23:04:01
>>117
今の言語だって一緒だろ?

125 :デフォルトの名無しさん:2006/01/20(金) 23:12:16
>>124
そんなプログラム作るほうが悪い。

126 :デフォルトの名無しさん:2006/01/20(金) 23:47:10
こうやってみると、なんか自国語でプログラムって凄い違和感有るな

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

127 :デフォルトの名無しさん:2006/01/20(金) 23:53:01
>>125
意味不明。

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

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

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

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

128 :デフォルトの名無しさん:2006/01/21(土) 00:02:02
日本語を話せ

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

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

130 :デフォルトの名無しさん:2006/01/21(土) 00:45:34
>>128
諸外国の方なの?

131 :デフォルトの名無しさん:2006/01/21(土) 00:46:43
必死だなw

132 :デフォルトの名無しさん:2006/01/21(土) 00:53:12
>>131
あなたを、犯人です。

133 :デフォルトの名無しさん:2006/01/21(土) 00:54:58
>>124
普通は、配偶者控除額とか給与所得控除の額とか給与等とか社会保険料控除後の給与等の金額とかは使わない。
たまにあるんだけどさ。
似たような用語が大量に定義されてて、いちいち使い分けないといけないような案件が。


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

135 :デフォルトの名無しさん:2006/01/21(土) 01:43:57
>>113 は間違っていないし、それしかないと思う。ただし、
仕様が「おんなは赤い」だったらどうだろう。
女.色=赤;
が正しいとはいえない。私は今村昌平の「赤い殺意」を思い出してしまう。

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

136 :135:2006/01/21(土) 01:46:05
>>135 仕様が「おんな」だから、「女」は「おんな」に直してください。
ごめん。

137 :デフォルトの名無しさん:2006/01/21(土) 02:12:55
関数とかいうから話がこじれるんで
素直に述語といいなさい

138 :デフォルトの名無しさん:2006/01/21(土) 02:23:35
>>134
その分野ではよく使われている単語だからっていうのはわかるけど、
「バグの出にくい」という目的からは真逆の方向に突っ走ってるんだよね。

139 :デフォルトの名無しさん:2006/01/21(土) 02:28:19
>>110
is("雪","白"). かなぁ。

140 :デフォルトの名無しさん:2006/01/21(土) 02:39:23
日本語にすると何故かPrologっぽくなってる件について。

141 :デフォルトの名無しさん:2006/01/21(土) 02:41:42
>>138
語彙が仕様書そのままで、ロジックの表現もほぼ仕様書どおりの書けるのだから、
バグは出にくくなっていると思うよ。まじで。
わざわざ英語(というかローマ字)に直さなければならなかったり、
四則演算や配列などに置き換えなければならないほうが、バグはでやすい。

142 :デフォルトの名無しさん:2006/01/21(土) 02:44:11
慣れた人が書けばね。

143 :デフォルトの名無しさん:2006/01/21(土) 02:45:25
雪::色=白
だな。

144 :デフォルトの名無しさん:2006/01/21(土) 03:10:25
日本語を記号化する事と、プログラムと、どう関係あるの?

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

145 :デフォルトの名無しさん:2006/01/21(土) 03:14:49
ある事柄をどうモデリングするか、どういうモデルをサポートしているかというのは重要。

146 :デフォルトの名無しさん:2006/01/21(土) 03:27:10
ある事柄をどうモデリングするかって? その時点でBUGの9割が住処を見つけたとほくそ笑んでる訳だな?

147 :デフォルトの名無しさん:2006/01/21(土) 03:33:02
頭の悪い上司に興味をもたれる

頭の悪いプロジェクト体制で使われる

頭の悪いバグのオンパレード

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

148 :デフォルトの名無しさん:2006/01/21(土) 03:40:21
>>146
9割のBUGがモデリングに棲むなら、やっぱり重要じゃん

149 :デフォルトの名無しさん:2006/01/21(土) 03:46:38
型に付ける属性ってここまでどんなのが出たかな。

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

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

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



150 :デフォルトの名無しさん:2006/01/21(土) 07:51:59
>>140
「ひまわり」とか「なでしこ」で書いたらこのスレでは
話が通りやすいと思う。

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

151 :デフォルトの名無しさん:2006/01/21(土) 08:17:35
>>134
スモールビジネスで総務畑にいる人が直接プログラミングすれば
バグなんて、でないw

Small is beuatiful!


152 :デフォルトの名無しさん:2006/01/21(土) 08:25:52
>>144
やはり、仕様記述言語ですか。この話題はそこから発した流れなのですね。

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

153 :デフォルトの名無しさん:2006/01/21(土) 11:51:51
>>152
やっぱりそこに落ち着くんだな
で、こんどは仕様記述言語の設計書が必要になって仕様記述言語記述言語ができると

154 :デフォルトの名無しさん:2006/01/21(土) 12:40:27
>>153
仕様記述言語自身で仕様記述言語を記述するから問題無いよ。

155 :デフォルトの名無しさん:2006/01/21(土) 12:49:42
制約条件を記述するだけで済む言語が欲しいね。
条件に矛盾が発生したり、一意に動作が決定できないような場合は
エラーを返してくれるの。

156 :デフォルトの名無しさん:2006/01/21(土) 13:22:37
>>155
NP完全な問題だろそれ

157 :デフォルトの名無しさん:2006/01/21(土) 15:14:25
制約条件て、制約条件自体でプログラムを書く手法があるくらいだよ。
http://www.constraint.org/constraint_org.htm

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

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

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



159 :デフォルトの名無しさん:2006/01/22(日) 09:38:59
>158
Javaのthrowsじゃダメなの? Java使ったこと無いから細かい事は知らんけど。

160 :デフォルトの名無しさん:2006/01/22(日) 10:46:28
> 一番単純なケースはエラーコードの誤り。
> こういったケースでは強い型付け云々は
> 全く無力で、

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

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

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

162 :デフォルトの名無しさん:2006/01/22(日) 14:25:19
>>161
もちろんプログラムでどうにもならないケースがあるの
は承知しているが、このスレは「バグを出しにくくする
ための言語仕様を考えるスレ」だから。

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

163 :デフォルトの名無しさん:2006/01/22(日) 15:47:58
ここのところこのスレの流れは
・強い型付とそのチェック強化でバグを減らす
・仕様段階でのバグの除去がやはり重要
という二論に分化していて、私の書いたのは後の方の立場。

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

164 :デフォルトの名無しさん:2006/01/22(日) 17:59:16
その仕様記述言語とやらを、ちょっと分かりやすい例として書いてくれや。

165 :デフォルトの名無しさん:2006/01/22(日) 20:37:14
日本語プログラミングって言われると私はMindを思い出す訳だが

166 :デフォルトの名無しさん:2006/01/22(日) 22:46:09
うちのJavaのプロジェクトの見本のコードにセッションの値にnullや期待したクラス以外が
セットされている場合は新規にクラスをつくってセットするというのがある

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

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

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

167 :デフォルトの名無しさん:2006/01/23(月) 01:39:19
リファクタリングは無関係なんでしょうかね

168 :デフォルトの名無しさん:2006/01/23(月) 01:59:22
>>166
ここはキミの愚痴を書くスレッドじゃないんだよ。
明らかにスレ違いだ。そんなことも分からないようでは、
キミの愚痴もどこまで信憑性があるか怪しいモノだね。

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

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

170 :デフォルトの名無しさん:2006/01/23(月) 08:50:01
>>169
全然知らないのに「仕様記述言語で仕様を書かせるとバグが減る」とか主張してんのか?
頭おかしーだろ。

171 :デフォルトの名無しさん:2006/01/23(月) 09:22:09
バグが減るかどうか解らない。
そこから抜本的に考えないとどうにも
ならないバグの方が多いといっているだけ。

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

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

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

173 :デフォルトの名無しさん:2006/01/23(月) 20:16:14
無限にあるデータ構造を、表ただひとつに縛るという制約だな。
ならばプログラムも…

174 :デフォルトの名無しさん:2006/01/23(月) 20:39:37
ここは「バグの出にくい言語仕様を考える」スレであって
「バグの出にくいシステム構築を考える」スレではない
そういった精細さを欠いた人間には
仕様記述言語を与えたところで無駄であろう

175 :デフォルトの名無しさん:2006/01/23(月) 20:58:55
抜本的に、「バグの出にくい言語仕様を考える」ことは
「バグの出にくい言語仕様を考える」ことに含まれないのかな?

176 :デフォルトの名無しさん:2006/01/23(月) 21:20:03
要するに、仕様記述言語を強調するのは
バグの出にくい言語を述語論理に基づく
言語と見てるわけだよ。
全部そういう言語に取っ替えようと
いうのは途方もない事だから、確実に
取り入れられて、かつ、現実にバグを
減らす事に寄与する仕様記述の部分を
強調しているだけ。

177 :デフォルトの名無しさん:2006/01/23(月) 22:05:29
オブジェクト指向は言語仕様ではない?

178 :デフォルトの名無しさん:2006/01/23(月) 22:09:23
具体的に行こう。

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


179 :デフォルトの名無しさん:2006/01/23(月) 22:25:42
誰かバグの発生はある有界値までしか減らせない事を証明しろ

180 :デフォルトの名無しさん:2006/01/23(月) 22:29:39
真の要求というのがどこかにあったとして、それは記述可能なのか?



181 :デフォルトの名無しさん:2006/01/23(月) 23:19:06
仕様のバグと要求の漏れは区別しろよ

182 :デフォルトの名無しさん:2006/01/23(月) 23:49:15
>>174
いいなそれ。誰か「バグの出にくいシステム構築を考える」スレを立ててください。

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

183 :デフォルトの名無しさん:2006/01/24(火) 00:15:02
>>182
三目並べならわかるか?

184 :デフォルトの名無しさん:2006/01/24(火) 19:57:19
もうねプログラミングなんてね最終手段なわけよ

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

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

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

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

夢見すぎ

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

185 :デフォルトの名無しさん:2006/01/24(火) 20:10:36
>>178
だから意味無いじゃんって事で書いたんだが
その辺も仕様記述言語で書いてあった方が良いのか?

186 :デフォルトの名無しさん:2006/01/24(火) 22:16:17
TicTacToeなら知ってる

187 :デフォルトの名無しさん:2006/01/24(火) 22:17:10
>>185
良い。グダグタ言ってないで具体的にやれ。

188 :デフォルトの名無しさん:2006/01/24(火) 22:18:41
>>184
お前の能力では完璧な仕様書なんか出来ないだろ。

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

夢見すぎ

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

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

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

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

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


190 :デフォルトの名無しさん:2006/01/25(水) 23:29:27
「バグの出にくい言語仕様を考える」というコンテキストからは
当然その「バグ」は「実装段階のバグ」であることが暗示されているわけで
それ以外のバグに関する論は基本的にスレ違いであると思われ

191 :デフォルトの名無しさん:2006/01/26(木) 00:17:09
通常バグは「出る」ものではなく、無意識で「埋め込まれる」もの。

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

192 :デフォルトの名無しさん:2006/01/26(木) 00:18:12
ひとつやふたつバグがあっても正常に動き続けるような堅牢さが必要ってことだな

193 :デフォルトの名無しさん:2006/01/26(木) 00:45:19
何言ってんだ、エラーを吐くからバグだと言われるんだ。
エラー表示の無いコンパイラとエラー表示のない製品を作ってしまえ!

194 :デフォルトの名無しさん:2006/01/26(木) 00:47:19
>>193
Microsoft
富士通
三菱

195 :デフォルトの名無しさん:2006/01/26(木) 03:20:15
コンパイラ(プログラミング言語→機械語への翻訳過程)が原因で起こるバグは少ない。
ほとんどのバグは仕様→プログラミング言語への翻訳過程によって起こる。
この翻訳過程を自動化しようという試みもあるが、技術的に困難。
そこでだな、逆転の発想でプログラムから仕様を自動生成すれば

196 :デフォルトの名無しさん:2006/01/26(木) 15:16:38
バグの原因のほとんどは、勝手な思いこみ・決め付け。
実はこういう場合がありました、というところでバグが出る。
この辺をどうにかしる。

197 :デフォルトの名無しさん:2006/01/26(木) 23:02:22
バグの原因のほとんどは、勝手な思いこみ・決め付け。
実はこういう場合がありました、というところでバグが出る。

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

198 :デフォルトの名無しさん:2006/01/26(木) 23:31:16
でも鶏と卵じゃないけれど、仕様上の不具合を見つける最も効果的な方法は、
実際にプログラムを動かしてみることかもしれない。

199 :デフォルトの名無しさん:2006/01/26(木) 23:37:18
「見つける」為の効果的な方法は、確かにそれで正しい
んだけど、残念なことにそれでは納期に間に合わないわ
けで…。orz

200 :デフォルトの名無しさん:2006/01/27(金) 00:11:37
>>196
マ向け

201 :デフォルトの名無しさん:2006/01/27(金) 00:21:31
「仕様」上の不具合を見つける最も効果的な方法は、実際にリリースしてみることじゃないかなぁ。
問題がありゃお客が怒ってくるでしょ。使いもんにならん!って。
そうすりゃしようを考えた奴のケツにも火がつくわけで、効果的だと思うけどね。

202 :デフォルトの名無しさん:2006/01/27(金) 10:21:14
JavaコンパイラにCheckStyleとFindBugsを組み込めば解決じゃん

203 :デフォルトの名無しさん:2006/01/27(金) 11:42:29
プログラムを作っている内に何かを忘れた場合にもある程度対処できる
言語にすればいいんじゃないだろうか。メモリ開放忘れとか。

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



204 :デフォルトの名無しさん:2006/01/27(金) 12:30:48
>>200

そんなことはない。

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

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

205 :デフォルトの名無しさん:2006/01/27(金) 12:34:04
>>201
それがアジャイルとかプロトタイピングでしょ。

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


206 :デフォルトの名無しさん:2006/01/27(金) 13:25:09
一日に何回も発生するエラーはたいしたことない。すぐに発見可能だから。
ヤヴァイのは「ごく稀にしか起こらない重大なエラー」

207 :デフォルトの名無しさん:2006/01/27(金) 20:30:43
>>206
C言語で自動変数初期化忘れとか。ありますねえ。
コンパイラもそのままだと何の警告も出さなかったりして。


208 :デフォルトの名無しさん:2006/01/27(金) 23:20:11
いまどきの言語は初期化忘れはコンパイルエラーですが。

209 :デフォルトの名無しさん:2006/01/28(土) 00:47:05
初期化し忘れたのが検知出来るなら、いい具合に初期化してくれればいいのに。
エラーだけ出すなんて、怠慢だな。

210 :デフォルトの名無しさん:2006/01/28(土) 01:20:14
っつーか、ココで皆が考えているバグってどれ?
*1 仕様から考えてちょっとおかしい動作をすること
*2 システムから考えてちょっとこれは違うんじゃない?って感じ
*3 書いたとおりに動かない環境

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

211 :デフォルトの名無しさん:2006/01/28(土) 01:30:12
実装したものが仕様どおりに動かないこと、じゃね?
仕様そのものがおかしいのや
実装していないものが仕様どおりに動かないのは
ここでいう「言語」には関係ないだろし

212 :デフォルトの名無しさん:2006/01/28(土) 01:37:01
>>205
「使いもんにならん!」ってのは「使い勝手」のことには限らんがな。
帳票と画面の矛盾とか、サブシステムをまたいだ矛盾とか、そういうのさ。

213 :デフォルトの名無しさん:2006/01/28(土) 08:50:18
>>195 逆転の発想でプログラムから仕様を自動生成すれば

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

214 :デフォルトの名無しさん:2006/01/28(土) 09:00:47
>209
初期値が0とかとは限らないから、勝手に初期化されるよりはエラーの方がいいだろ。

215 :デフォルトの名無しさん:2006/01/28(土) 10:10:07
>>214
0で動いちゃう方がバグになりそう。

216 :デフォルトの名無しさん:2006/01/28(土) 10:25:29
どうせ初期化しなきゃいけないなら、0で初期値をとっておいた方が楽

217 :デフォルトの名無しさん:2006/01/28(土) 11:16:56
アホかい。

218 :デフォルトの名無しさん:2006/01/28(土) 11:55:15
どっちみちエラーなんだから、どうでもいいが、
暗黙に初期値はゼロって事でワーニングで済ませてもらいたいもんだ。

219 :デフォルトの名無しさん:2006/01/28(土) 15:05:28
.NETは初期値0なわけだが、
「変数の初期値は0で警告は無視する」というやつに対しては、
確かにバグが減っている。
決め付けの排除ではなく、決め付けの通りに動いているわけだな。

220 :デフォルトの名無しさん:2006/01/29(日) 04:28:58
>>196のいう勝手な決めつけを排除する為に、
やはり型情報にいろいろ追加する機能があると良いのでは?

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


221 :デフォルトの名無しさん:2006/01/29(日) 12:54:36
という勝手な思いこみ・決め付けをなんとかしる。


222 :デフォルトの名無しさん:2006/01/29(日) 14:10:24
220なんかの意見もそうだけど
「プログラマの意図しない動作」をするのがバグなら、出来るだけ人間の思考にすり寄った形でプログラム言語を作成してしまうのが、バグ排除の究極の形の一つと言えるんじゃないかな。

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

223 :デフォルトの名無しさん:2006/01/29(日) 15:56:44
>>220
型情報に何かを付加する方法の一つに、インタフェイスを作ってしまうという方法があるかと
インタフェイスはデータの見方を変える手段として使えるわけで・・・

224 :デフォルトの名無しさん:2006/01/29(日) 16:18:14
「人間の思考」は間違うことがあるからな

225 :デフォルトの名無しさん:2006/01/29(日) 22:29:49
人間の思考そのものにBUGがあるんだよな実際には・・・。
組んでみて、動かしてみて、初めて、あ・・・ってな感じ。

226 :デフォルトの名無しさん:2006/01/29(日) 22:37:53
>>223
JDK5.0 にそれっぽい仕様があったような・・・?

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

227 :デフォルトの名無しさん:2006/01/30(月) 00:21:23
そうだね。仕様どおりに作ったのに、仕様そのものがクソだったとか。

228 :デフォルトの名無しさん:2006/01/30(月) 00:22:55
やはり良い仕様を考えるには、センスとかって必要だと思う?

229 :デフォルトの名無しさん:2006/01/30(月) 00:39:56
優れた仕様を考えるにはセンスが必要だが、それは凡人には難しい。
良い仕様を考えるのに必要なのは、経験と内省力。

230 :デフォルトの名無しさん:2006/01/30(月) 00:42:01
バグをなくすには言語仕様を極力軽くすべきじゃないかなぁ−−−→COBOLになりました。

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

231 :デフォルトの名無しさん:2006/01/30(月) 01:26:12
う〜ん、仕様の失敗というのはこのスレの趣旨からはずれるようだから、あまり続けたくないんだけど…

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

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

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


232 :デフォルトの名無しさん:2006/01/30(月) 01:48:23
そういえば誰かが、センスとは捨てる能力だって言っていたような気がするな。

233 :デフォルトの名無しさん:2006/01/30(月) 03:22:32
Haskellやっとけ。

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

234 :デフォルトの名無しさん:2006/01/30(月) 03:30:00
>>223
インタフェイスって?Javaのinterfaceみたいの?
それじゃあ、上の方に出てきた
null代入禁止とか、次元解析とか、そういう制約は書けなそうだけど。



235 :デフォルトの名無しさん:2006/01/30(月) 09:34:50
>>232
収納名人だろ

236 :デフォルトの名無しさん:2006/01/30(月) 12:51:26
>>234
インターフェースじゃなくてアノテーションの事言いたいんだろ
クラスというかバイナリに付加できるメタデータの事だな

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

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


237 :デフォルトの名無しさん:2006/01/30(月) 13:16:56
そういうことか。
しかしそれは動的なチェックだろ。バグが出てから調べやすいだけだなぁ。
それを静的にチェック出来てコンパイル時に排除できるというのが>>220


238 :デフォルトの名無しさん:2006/01/30(月) 13:22:47
>>237
ソースに記述できるんだからやろうと思えば静的にチェックできるよ
Javaに関しちゃ静的・動的で2分しちゃう意味は無い

239 :237:2006/01/30(月) 13:32:04
おおホントだ、知らんかった。ハズカシ…。

240 :デフォルトの名無しさん:2006/01/30(月) 13:45:23
>>230
やはり、破壊代入を排除する所まで行かないと。

241 :デフォルトの名無しさん:2006/01/30(月) 15:42:57
破壊代入を排除したらどれくらいバグが減るの?
それとオブジェクト指向と相性が悪そう。

242 :デフォルトの名無しさん:2006/01/30(月) 15:59:43
まずは最低限あった方がよさそうな機能を考えればいいんじゃないだろうか。

1. 文字列型は欲しい。

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

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

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

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

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


243 :デフォルトの名無しさん:2006/01/30(月) 16:13:51
>242
C/C++以外の言語使ったこと無いのか?
JavaでもPHPでもいいからとりあえず使ってみろ。
バッファオーバーフローなんて文字列型がちゃんとある言語ならまず起きないだろ。
参照無くなって開放されたものに、後からどうやってアクセスするんだ?

244 :デフォルトの名無しさん:2006/01/30(月) 18:00:38
最低限すぎ。今時みんな常識。
つうか3が意味不明。末尾再帰の最適化を言ってるのか?

245 :デフォルトの名無しさん:2006/01/30(月) 18:42:24
「再起はフローの解析を行ってできる限りループに展開してくれ」って事じゃない?
Lispなんかじゃあって当たり前の位の物だな
末尾再起をループに展開するぐらいは最新のCコンパイラでもやってくれそうだが
其処の所どう?

246 :デフォルトの名無しさん:2006/01/30(月) 18:58:13
末尾再帰じゃない再帰をどうやってループ展開すんの?

247 :デフォルトの名無しさん:2006/01/30(月) 19:37:40
>>246
http://d.hatena.ne.jp/yaneurao/20051008
http://d.hatena.ne.jp/yaneurao/20051025

248 :デフォルトの名無しさん:2006/01/30(月) 19:59:02
結局スタックが要るんじゃん。
末尾再帰じゃない再帰をループ展開する必要なし。

249 :デフォルトの名無しさん:2006/01/30(月) 20:15:07
>>248
問題の次元を落とし込むことができるから、
メモリをふんだんに使えて再帰以外の実装があまりにも複雑なら再帰にすべき
・・といっても、再帰なんて気持悪くてあんまりしないんだけどな。
そんな複雑な問題、汎用PCでやらんし

250 :デフォルトの名無しさん:2006/01/30(月) 20:20:03
>>242
そういう言語仕様が望みだというならよくわかるけど、
バグの発生とは関係ない項目が多いのはなぜ。

251 :デフォルトの名無しさん:2006/01/30(月) 20:37:16
>>249
248では「再帰を使うな」とは主張していないんだが。
なぜそんなレスを?

252 :デフォルトの名無しさん:2006/01/30(月) 22:29:57
なんか難しいので
再帰は、末尾再帰しか許さない
って仕様でイインジャネ?

253 :デフォルトの名無しさん:2006/01/31(火) 00:18:59
どちらにしろ、ミニマムな機能からアプローチをかけるのはあまり良い考えではなさそうだな…

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

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

254 :デフォルトの名無しさん:2006/01/31(火) 01:34:26
>>252
スタックオーバーフローの懸念の問題は
バグとは関係ないと思う。それこそ、
仕様の問題。

255 :デフォルトの名無しさん:2006/01/31(火) 03:15:13
>>238
嘘つき。
コンパイル時制約なんて書けない。と思ったら、
静的とは書いてるけどコンパイル時とは書いてないな…。

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

256 :デフォルトの名無しさん:2006/01/31(火) 14:40:18
それ以前に、このスレ的にアノテーションじゃ全然ダメ、お話にならない。

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

257 :デフォルトの名無しさん:2006/01/31(火) 14:53:03
メソッドの引数に、必要とする要求アノテーションを書けるようになればいいのかな?
ただし次元解析には、数値演算子を廃止してメソッドで作り直さんといかんが。

258 :デフォルトの名無しさん:2006/01/31(火) 17:22:19
「バグは発見できるからこそバグ」だし「対処している例外はバグではない」なわけだ

例えば手続き型言語の代表例な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除算か、他の例外が発生しました"; }
}
とかかれて、「バグの無いプログラムの出来上がり」て言われても。
そうだね、っていえると思う…さーて、バグって何でしょーねぇ

259 :デフォルトの名無しさん:2006/01/31(火) 17:51:19
>>258のfooの例なら定義レベルでqが0をとらない事が定義できれば良いんじゃないのか?
そうでなければ潜在的に0割除算で例外の発生する可能性のある不安定なコードになる


260 :デフォルトの名無しさん:2006/01/31(火) 18:17:48
>>258
それだとしても意味はデカい。
例外がなければ0を渡せないという仕様がどこにもなく、ソース見ても問題を見付けづらいが、
馬鹿な例外処理は一目で分かり、書いた奴を減給なり懲戒にすることが出来る。

261 :デフォルトの名無しさん:2006/01/31(火) 19:45:55
GNUのライブラリの gets() のマニュアルページのバグの項目に
gets() は決して使ってはならない、と書いてある。w

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


262 :デフォルトの名無しさん:2006/01/31(火) 20:40:29
>>261
過去の互換性

263 :デフォルトの名無しさん:2006/01/31(火) 22:37:39
getsの芸人、今何してるんだろう?

264 :デフォルトの名無しさん:2006/02/01(水) 00:06:45
実証重視な(科学的な)視点から見れば、「バグの出にくい言語仕様」の前提に"事実"が発見されていなければならない。

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

265 :デフォルトの名無しさん:2006/02/01(水) 00:11:38
> type2. Spec(Pgr)に動かない
>  →プログラマに「プログラムは思ったとおりに動かない」ことを認知させることでこの種の「バグ」は取り除くことが(ry?
これはいったい、何がどう解決してますか?

266 :デフォルトの名無しさん:2006/02/01(水) 00:49:32
>>265
まず「思ったとおりに動かないこと」=「バグ」という認知がある。
そこで、認知を摩り替えて
「思ったとおりに動かないこと」≠「バグ」という認知にするわけだ。

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

267 :デフォルトの名無しさん:2006/02/01(水) 01:24:14
>>258
ちょっと目が覚めた。いいこと言ってくれた。

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

269 :デフォルトの名無しさん:2006/02/01(水) 01:40:04
道具として使うものがそんなに危ないものであるのは他には類を見ないんではないかと思う。
そして、初心者が簡単に手がでるし、実験環境も実機である場合が多い。

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

270 :デフォルトの名無しさん:2006/02/01(水) 01:40:45
全ての関数に対して個別のunittestを強要

271 :デフォルトの名無しさん:2006/02/01(水) 10:57:47
>>264
ココで話しているユーザーにとってのバグは
「使い勝手の悪さや、実現できるはずなのに実現できないこと」
だけど、これは「ユーザビリティが低い」であって、バグとして扱うのは異論があるなぁ

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


272 :デフォルトの名無しさん:2006/02/01(水) 11:24:41
ユーザビリティって相対的な評価なんだよね
所謂ある・無しで分かる障害とは違うんだとな

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

273 :デフォルトの名無しさん:2006/02/01(水) 12:18:50
>>268
そりゃ言語やツールによって違うのでは?

274 :デフォルトの名無しさん:2006/02/01(水) 14:48:21
やりたいこととは直接てきに関係ない
コードを沢山書かなきゃいけない言語だと
バグが入り込みやすいし、



275 :デフォルトの名無しさん:2006/02/01(水) 14:53:05
>>274
そんなことあるか?もう少し具体的な話というか例を

276 :デフォルトの名無しさん:2006/02/01(水) 19:13:57
例によって遅レスだが、

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


277 :デフォルトの名無しさん:2006/02/01(水) 23:36:10
>>276
Adaって日本にも使っている人いるのかな
ひょっとしてアメリカ国防総省の中の人ですか?

278 :デフォルトの名無しさん:2006/02/01(水) 23:39:27
>>277
Adaスレにおいで、おいで

279 :デフォルトの名無しさん:2006/02/01(水) 23:48:48
初めてAdaって書かれたの読んだとき、普通に「あだ」って言ったおれ・・

280 :デフォルトの名無しさん:2006/02/02(木) 02:09:41
Adaは既に2回挫折してる
めんどくさいんじゃ

281 :デフォルトの名無しさん:2006/02/02(木) 16:09:24
Adaってそんなにスゴいのか?
だったらなんでこんなに普及してないんだ?

282 :デフォルトの名無しさん:2006/02/02(木) 16:33:22
D言語が普及してないのと同じでライブラリが少ない

283 :デフォルトの名無しさん:2006/02/02(木) 19:46:51
他の言語ではよきに計らえが出来るところを厳密に定めなくちゃならないから

284 :デフォルトの名無しさん:2006/02/02(木) 19:49:28
結局、「使える言語」になるためには、周辺環境が重要なんだな

285 :デフォルトの名無しさん:2006/02/02(木) 22:11:25
それがAda良いところなんだけどね
バグを減らすそうと考えて、割に合わないくらい座業効率下がったら意味無いぜぇ、ってカンジで

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


286 :デフォルトの名無しさん:2006/02/03(金) 00:24:00
ライブラリが少ないのは、その言語が普及していないからではないのか?

287 :デフォルトの名無しさん:2006/02/03(金) 06:55:58
>>296
普及すれば開発者が増えて良いライブラリが出てくる、というこのジレンマ

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

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

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

スレ違いスマソ

288 :デフォルトの名無しさん:2006/02/03(金) 12:36:44
こういう言語って高度な安全性が求められる特殊なところに使われるわけだろうから、多少のコストは仕方ないのかも。
仕様書作成→プログラム構成、分担決定→コード作成(メイン)→宣言などを整理→デバッグ(コード作成者)
として、宣言とか面倒なところは低賃金者にやらせる。

289 :デフォルトの名無しさん:2006/02/03(金) 12:51:46
宣言とか面倒なところはプログラムを書く

290 :デフォルトの名無しさん:2006/02/03(金) 14:26:34
プログラミングてしないけど、初めて書く変数が出たら知らせたり、外側のスコープと同じ変数名
を書いたら知らせたり、グローバル変数に書き込もうとしたら警告したりとかはエディタで出来ますか?

291 :デフォルトの名無しさん:2006/02/03(金) 23:35:01
>>290
ターゲット言語決まってないのに「グローバル変数」とか「外側のスコープ」とか言うなや ('A`)ノシ

292 :デフォルトの名無しさん:2006/02/03(金) 23:37:22
フレームワークや制約なんかをバリバリに規定できれば
1人が気をつけるだけでその他大勢はバグから解放される…ってのも
バグの出にくい言語に入らないかにゃ

293 :デフォルトの名無しさん:2006/02/03(金) 23:42:37
>>292
そんな中途半端なこと言わないで、
再現なくデバッグすれば最終的にバグの無いプログラムできる、
でいいじゃん
…どっちにしろ、実現不可能だけどな。

294 :デフォルトの名無しさん:2006/02/04(土) 00:24:35
>>290
>初めて書く変数が出たら知らせたり
これはうざい。変な使い回しをして余計にバグが出そう。
>外側のスコープと同じ変数名を書いたら知らせたり
これはまぁよし。
>グローバル変数に書き込もうとしたら警告したり
これもうざい。その上グローバル変数を定義できない言語や環境もかなりある。

295 :デフォルトの名無しさん:2006/02/04(土) 01:56:47
書く気無かったけど294があまりにつまらなかったので…

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

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

296 :デフォルトの名無しさん:2006/02/04(土) 01:59:42
>>290
グローバル変数とローカル変数を別の色で色分けしたらいいんじゃね?

297 :デフォルトの名無しさん:2006/02/04(土) 01:59:49
292はちょっと良いこと言ったかな
複雑なルールを徹底できているかのチェックツールは作成可能と見える。

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


298 :デフォルトの名無しさん:2006/02/04(土) 02:01:52
>>297
大前提の「バグとは何か?」をないがしろにして何を賛同する気なのかと(ry

299 :デフォルトの名無しさん:2006/02/04(土) 02:03:47
>>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

300 :デフォルトの名無しさん:2006/02/06(月) 11:29:30
>>299
じゃあ、Mozillaはバグが無くなったかというとそういうわけではないよな
規模の割には少ないとは思うが

301 :デフォルトの名無しさん:2006/02/06(月) 15:14:08
同じ規模の市販ソフトと比べたら多くね?

302 :デフォルトの名無しさん:2006/02/06(月) 18:16:03
同じ場所で同じ時間帯に同じレベルの人たちが作るのが、一番BUGが少ないって事だろ?

303 :デフォルトの名無しさん:2006/02/06(月) 18:25:33
>>302
コミュニケーションの問題に起因するバグが減るだけでバグの総数が減るかどうかは定かではない

304 :デフォルトの名無しさん:2006/02/06(月) 18:30:01
>>303
そりゃ、減ってるって事だよ。

305 :デフォルトの名無しさん:2006/02/06(月) 19:08:49
>>303
その分ほかのバグが増えるわけではないからねぇ
減ってるとみなしていいと思うよ

306 :デフォルトの名無しさん:2006/02/06(月) 20:04:40
>>303
小説を書くのと一緒
一人だとバグは少ないが
複数の人が勝手にエピソードを書いていくと
矛盾点が出てくるだろ


307 :デフォルトの名無しさん:2006/02/06(月) 20:08:13
ちゃんとインターフェイス決めて構造化すれば、
とりあえず表現としてはだいじょうぶ
どんな風に動くかはチーフが・・・

普通の開発だな

308 :デフォルトの名無しさん:2006/02/06(月) 20:12:34
作家が一人で
編集者(バグ発見)、アシスタント(言われたとおり作るプログラマ)
ならうまくいくんだよな・・・
問題は作家のレベルのものしか作れないから
こまめに話し合いが出来るなら複数作家もありなんだけどね・・・


309 :デフォルトの名無しさん:2006/02/06(月) 20:15:10
>>301
MSと比べてるんだろうけど
仕事としてやってるんだし
作業時間x人数とバグを比べたら
同じくらいだと思われ


310 :デフォルトの名無しさん:2006/02/06(月) 20:18:28
えええっ
MSと比べちゃ可哀想だよ。
相手は、どんなバグでもある時期を超えたら全部仕様になるんだぜ?

311 :デフォルトの名無しさん:2006/02/06(月) 20:47:24
>>309
・同じ時間でも仕事中は手抜きをして趣味は一生懸命やるのが人間だから
モジラ>M$
・人は趣味でやってる人のレベルは幅広いが仕事人なら一定レベル以上
一定レベル以下
書いてて結論分からなくなったw

312 :デフォルトの名無しさん:2006/02/06(月) 22:09:27
バカだからさ

313 :デフォルトの名無しさん:2006/02/07(火) 00:44:53
>>307
提案者の意図は、ツールで検知しやすくする事で、コストを下げて頻繁にチェック出来る要にすることじゃないかな
機械で容易に出来ることを人間様が手法や努力でカバーするなんて、正直格好悪いし

314 :デフォルトの名無しさん:2006/02/07(火) 01:23:40
>>313
その意見自体は正しいけど
具体的な例とかあるといいんだけど・・・


315 :デフォルトの名無しさん:2006/02/07(火) 07:23:14
オープンソースなプロジェクトだと「無能な努力家」を排除することが難しいんじゃないかと思った

316 :デフォルトの名無しさん:2006/02/07(火) 12:50:21
選民して専用の掲示板やMLでやればいいじゃん
無能な人には勝手に亜種を作らせておけ

317 :デフォルトの名無しさん:2006/02/07(火) 12:53:54
>>316
で、一般人には使いにくいアレな物が出来て商用のBuggyな物で良いやという事になる

318 :デフォルトの名無しさん:2006/02/07(火) 12:54:48
>>316
それは選民して、そいつらを隔離するということでつね

319 :デフォルトの名無しさん:2006/02/07(火) 14:19:21
一般人はバグとかには無頓着だからな・・・
命が関わる病院や保険ですら
よく調べず適当に選ぶし・・・

320 :デフォルトの名無しさん:2006/02/07(火) 15:31:21
>>307,313
普通の静的言語ならインタフェースは明示化されている。名前も引数の型も返値の型も。
あとは、いろんな条件や単位のような情報をそこに埋め込めば…。

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

321 :デフォルトの名無しさん:2006/02/07(火) 15:38:52
>>320
> いろんな条件や単位のような情報をそこに埋め込めば…。
C#やVB.NETのattribute節みたいだな

322 :デフォルトの名無しさん:2006/02/07(火) 16:41:02
.NETの属性って、コンパイラに対する指示なり制約を書けるの?
Javaのはダメみたいだけど。

323 :デフォルトの名無しさん:2006/02/07(火) 18:31:34
>>322
一部の属性なら考慮してくれる。ConditionalAttribute なんかは正にそれ。#if 〜 #endif の高級版みたいな。
ただ、C# でも Java でも、オリジナルの属性なり注釈なりは、自作のツール類での処理になっちゃうかな〜と。

324 :デフォルトの名無しさん:2006/02/08(水) 03:49:30
型情報について妄想吐いてみる。

//型に付くメタデータその1
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(); //コンパイルエラー




325 :矛盾が残ってる気がするが、まあいいや。:2006/02/08(水) 03:51:05
//型に付くメタデータその2(パラメタあり)
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 ); //コンパイルエラー


//型に付くメタデータその3(コンパイル時計算チェック)
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 );        //コンパイルエラー

326 :デフォルトの名無しさん:2006/02/08(水) 04:35:32
もひとつ電波。かなり無理矢理だけど。

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;//実行時エラー


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

327 :デフォルトの名無しさん:2006/02/08(水) 18:37:18
面白い。構文はこんなのでどうか。(英語が変だけど)

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;
  }
}

328 :デフォルトの名無しさん:2006/02/08(水) 18:41:16
まちがえた。一部訂正

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


329 :デフォルトの名無しさん:2006/02/08(水) 18:56:39
さらに間違い。(汗)

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

330 :デフォルトの名無しさん:2006/02/08(水) 23:44:25
これ、引数や返り値だけじゃなく、レシーバについてもannotateしたいな。
PythonやCLOSみたいだと引数と同列なんだが。

331 :デフォルトの名無しさん:2006/02/08(水) 23:58:18
やはり、これもAdaにあるん?>Adaな人

332 :デフォルトの名無しさん:2006/02/09(木) 00:00:47


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

334 :デフォルトの名無しさん:2006/02/09(木) 04:31:12
>>330
pythonみたいに必須だとうざいから、第一引数に予約語引数thisを明示してもよい、って文法にすればいいじゃん。

335 :デフォルトの名無しさん:2006/02/09(木) 15:37:29
D言語にopCastがあるけど…

336 :デフォルトの名無しさん:2006/02/10(金) 01:08:53
>>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ってキャストのオーバーロード? それって静的なルールを定義できるの?実行時の処理だけじゃなくて。

337 :デフォルトの名無しさん:2006/02/10(金) 01:16:02
opCastはC++で言えば型キャストoperator、単に型変換する関数が暗黙で呼ばれるだけ

338 :デフォルトの名無しさん:2006/02/10(金) 01:46:14
static assertやstatic ifならあるけどそれで静的に何とかできないかなぁ@D言語

339 :デフォルトの名無しさん:2006/02/10(金) 12:45:47
>>336
なんでもできるってのはそれだけバグの入り込む余地が増えるって事だぞ分かってるか?
”何もしなけりゃバグも出ない”これが一番重要

340 :デフォルトの名無しさん:2006/02/10(金) 18:15:37
値の範囲や種類に加えて、値の変化の周期とかもチェック出来るといいかも。

341 :デフォルトの名無しさん:2006/02/10(金) 18:20:34
>>340


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

342 :デフォルトの名無しさん:2006/02/10(金) 18:23:22
便利にしたいと思う一方で、機能を増やして
できることを多くしすぎると、使いこなせなくて
バグが出やすくなる罠

343 :デフォルトの名無しさん:2006/02/10(金) 18:34:46
Adaか!

344 :デフォルトの名無しさん:2006/02/10(金) 19:29:51
お前ら、馬鹿のひとつ覚えだな。
これがバグを増やすなんてある訳がないんだが。
全然わかってねぇんじゃねぇのか?


345 :デフォルトの名無しさん:2006/02/10(金) 19:30:56
>>344
バカ確定しました (・∀・)

346 :デフォルトの名無しさん:2006/02/10(金) 19:35:26
Adaってバグが出やすいの?

347 :デフォルトの名無しさん:2006/02/10(金) 19:38:41
>>345
お前まじで理解してないだろ

348 :デフォルトの名無しさん:2006/02/10(金) 19:39:29
>>347
バーカ

349 :デフォルトの名無しさん:2006/02/10(金) 19:40:19
>>347
バーカ

350 :デフォルトの名無しさん:2006/02/10(金) 19:42:04
>>347
バーカ

351 :デフォルトの名無しさん:2006/02/10(金) 19:42:51
>>347
バーカ

352 :デフォルトの名無しさん:2006/02/10(金) 19:45:14
>>347
バーカ

353 :デフォルトの名無しさん:2006/02/10(金) 19:49:00
>>347
バーカ

354 :デフォルトの名無しさん:2006/02/10(金) 19:49:49
>>347
天才

355 :デフォルトの名無しさん:2006/02/10(金) 19:50:53
>>348-353
必死だなwwww
さっさと死ねよクズ(プ

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

357 :デフォルトの名無しさん:2006/02/10(金) 20:06:11
やっぱりバカなんじゃね?

358 :デフォルトの名無しさん:2006/02/10(金) 20:07:42
やっぱりバカだな。

359 :デフォルトの名無しさん:2006/02/10(金) 20:15:58
追い詰められて必死なクズって見苦しいね。

360 :デフォルトの名無しさん:2006/02/10(金) 20:19:15
>>356
お前が言ってるのはインライン展開しまくってassertを評価するだけで十分なんだよ
っといってもコンパイラ毎に差異がでる(VCのインライン化は凄いけどbccはしょぼいみたいな〜)し、そんな処理系も無いけどな

361 :デフォルトの名無しさん:2006/02/10(金) 20:28:55
>>360
バカでも分かるように具体的に頼む。
ただ適当な事言ってるだけならいいけど

362 :デフォルトの名無しさん:2006/02/10(金) 21:11:43
どうみたってくやし紛れの世迷事だろw

363 :デフォルトの名無しさん:2006/02/10(金) 21:14:15
だったら>>360説明してみてよ。
どうせ適当に知ってるふりしてただけなんだろう?

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

そろそろ春か

365 :デフォルトの名無しさん:2006/02/11(土) 01:21:26
>>324-329,334 って、よさそうだけど、コンパイラが生成コードを実行できないとだめだな。
Javaならjavacは良いけど、gjcは脂肪じゃね?

366 :デフォルトの名無しさん:2006/02/11(土) 01:24:11
TemplateHaskellと言ってみるテスト

367 :デフォルトの名無しさん:2006/02/11(土) 01:55:58
>>346
バグが出やすいと言うか馬鹿にはプログラムを作れなくなる

368 :デフォルトの名無しさん:2006/02/11(土) 22:19:36
gjc?

369 :デフォルトの名無しさん:2006/02/12(日) 05:44:11
>>366
Haskellよう知らんけど、それって普通の型安全なマクロと違うの?
コンパイラと直に会話する口がないと、
C++みたいな裏技チックなやり方が必要になりそうな気がするけど。

370 :デフォルトの名無しさん:2006/02/12(日) 06:27:31
gcjだろ…。

371 :デフォルトの名無しさん:2006/02/12(日) 06:34:40
>>324-329,334で、次元解析の作り方を考えてみたけど、
そもそも値をdoubleでやるのが間違いだな。次元パラメタを持ったクラスを作るべき。
その上で、演算メソッドに>>324-329,334のアノテーションを被せる。


372 :デフォルトの名無しさん:2006/02/12(日) 06:43:10
>>369
TemplateHaskellは、コンパイル時に実行されるコードを書いて構文木を直接弄れるらしい。使ったことないけど。
例えばprintf形式の文字列とか自力でばらして書式化関数にしてしまえるらしい。

373 :デフォルトの名無しさん:2006/02/12(日) 07:40:09
つThe Java Modeling Language (JML)
ttp://www.cs.iastate.edu/~leavens/JML/index.shtml


374 :デフォルトの名無しさん:2006/02/12(日) 14:47:58
>>372
ということは、コンパイラと、エラーにする・しないの会話が出来ないとしたら、
それってやっぱり高級なマクロでは…。

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

375 :自己レス:2006/02/12(日) 14:57:02
>>374
>コンパイラと、エラーにする・しないの会話が出来ないとしたら、
これはちょっと違うな。
型が吐けて、その適用についてOK/NGをコンパイラに言えないと、が正しいかな。
でもHaskellってデフォで多相型(だっけ?)とか、型の扱いがよくわからん。

376 :デフォルトの名無しさん:2006/02/12(日) 14:59:47
みんなLISPでOK

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

377 :デフォルトの名無しさん:2006/02/12(日) 15:09:25
あ、でも>>324-329,334って、結局subtypeを作ってるわけだから、
ある意味、素のHaskellに似てる?
ただし、値の実型じゃなくて、値空間のsubsetを作ってるわけだけどHaskellで出来たりするのかな。

378 :デフォルトの名無しさん:2006/02/12(日) 15:13:43
Haskellで出来ることはLISPで出来る
LISP最強伝説ここに爆誕

379 :デフォルトの名無しさん:2006/02/12(日) 15:13:57
>>376
Lispに静的型って普通なの?

380 :デフォルトの名無しさん:2006/02/12(日) 15:15:12
Lispで出来ることは全てアセンブラで出来る。
アセンブラ最強伝説ここに(ry

381 :デフォルトの名無しさん:2006/02/12(日) 15:18:03
>Lispで出来ることは全てアセンブラで(ry

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


382 :補足:2006/02/12(日) 15:18:54
>値空間のsubsetを作ってるわけ

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

383 :デフォルトの名無しさん:2006/02/12(日) 15:18:56
LISPのシンボルやクオートはアセンブラではどうやっても無理
LISP最強伝説に揺ぎ無し

384 :デフォルトの名無しさん:2006/02/12(日) 15:20:25
>>381
それって、

>Haskellで出来ることはLISPで(ry
・・いや、実はそうでもないんだが。

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


385 :デフォルトの名無しさん:2006/02/12(日) 15:22:11
>>383
田原「チューリングマシンって知ってる?」

386 :デフォルトの名無しさん:2006/02/12(日) 15:25:33
>385
このネタでチュ(略を出してくるなんてナンセンスだな
メタレベルを1つ以上跨げばそんなのいくらでも可能だけど
そんなのその言語で出来ることにはならんでしょ

387 :デフォルトの名無しさん:2006/02/12(日) 15:26:39
やっぱりLispが最強でしたか。
噂には聞いてたけど。

388 :デフォルトの名無しさん:2006/02/12(日) 15:26:54
だったら静的型は…。

389 :デフォルトの名無しさん:2006/02/12(日) 15:28:30
おいおい、「同じことが出来る」のが目標じゃなくて
「どれだけバグが出ない文法か?」が問題じゃないのか?

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


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

390 :デフォルトの名無しさん:2006/02/12(日) 15:29:20
巷で噂の、Ruby厨から変節したLisp厨がこのスレにも降臨か。

391 :デフォルトの名無しさん:2006/02/12(日) 15:30:20
LISPのマクロは確かに自分で文法と意味論まで定義できるから
その意味では最強っぽいんだけど、
型がデータにくっつくのが嫌、って人はいるかと。

392 :デフォルトの名無しさん:2006/02/12(日) 15:30:33
バクのでにくい言語仕様と言っても限界がある。何故なら
人間にはバグがあるからだ。バクの木にはバクの実しかならない。どんなに
頑張っても人間とはバグを作ってしまうものなのだ。

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

393 :デフォルトの名無しさん:2006/02/12(日) 15:30:46
>まぁ、バグが表記法程度で減るとは思えんがな

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

394 :デフォルトの名無しさん:2006/02/12(日) 15:32:52
>人間にはバグがあるからだ。バクの木にはバクの実しかならない。
>バクを発見しやすい言語仕様を考えるのだ。

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

395 :デフォルトの名無しさん:2006/02/12(日) 15:36:44
関数型言語は?

396 :デフォルトの名無しさん:2006/02/12(日) 15:39:23
>>381
すげーなリスプって。
吐き出すネイティブコードがアセンブリと対応しないってことだろ?

397 :デフォルトの名無しさん:2006/02/12(日) 15:41:55
>>396
だからそれは >>384-386
そして彼の妄想は>>388で潰えた。

398 :デフォルトの名無しさん:2006/02/12(日) 15:42:57
>>393
じゃぁ構造化されたプログラムをコンパイラがアセンブラに落としたらバグが増えるか?

399 :デフォルトの名無しさん:2006/02/12(日) 15:46:37
>>396
何を言っているんだ?
最初からアセンブラでjump系を生で使いまくりでゴリゴリ書いたプログラムと、
構造化言語からコンパイルしたプログラムで、どっちがバグが少ないと思う?



400 :デフォルトの名無しさん:2006/02/12(日) 15:52:11
>>399
知るか
じゃあ聞くが、どれくらい少ないんだ?
どれほど増減してるんだ?
データ示せクソ

401 :デフォルトの名無しさん:2006/02/12(日) 15:53:31
Haskellな人、>>377,382ってどうなん?

402 :デフォルトの名無しさん:2006/02/12(日) 15:56:10
>>400
>>347-364を彷彿とさせるな、君は。

403 :デフォルトの名無しさん:2006/02/12(日) 15:58:23
>>393
それが増えるわけがないから、
ifとgotoだけの言語じゃなくて、構造化言語を使ってバグを減らすわけだが。

404 :デフォルトの名無しさん:2006/02/12(日) 16:10:05
ここは構造化プログラミングでオナヌーするスレですか?

405 :デフォルトの名無しさん:2006/02/12(日) 22:04:12
>>399
開発者の技量とか開発期間の方がバグの多寡に関しては大きなファクターだな
ぶっちゃけ時間がたっぷりあればどちらでも変わらない

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


406 :デフォルトの名無しさん:2006/02/12(日) 22:26:39
関数型言語がバグが少ないかどうかは知らんが
関数型言語と手続型言語とオブジェクト指向言語とは使う人間が違うから
関数型言語内でバグが減ってもその他のところでは減らん

407 :デフォルトの名無しさん:2006/02/12(日) 22:49:09
>>399
他の言語で出来ることはすべてアセンブラで可能。まさに究極言語。
というわけで、おまえはアセンブラ以外使用禁止な。

408 :デフォルトの名無しさん:2006/02/12(日) 22:51:44
コンパイラはアセンブラレベルでバグの警告をしてくれればいいのに

409 :デフォルトの名無しさん:2006/02/12(日) 23:22:59
>>405
> ぶっちゃけ時間がたっぷりあればどちらでも変わらない

はぁ?

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

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

410 :デフォルトの名無しさん:2006/02/12(日) 23:33:53
> > ぶっちゃけ時間がたっぷりあればどちらでも変わらない
>
> はぁ?
>
> 自由度が高い ≡ バグが検出しにくい
> ステップ数が多い ≡ (全体の) バグ件数が多い
//ここまで

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


411 :デフォルトの名無しさん:2006/02/13(月) 01:03:27
> ぶっちゃけ時間がたっぷりあればどちらでも変わらない
1. 事実に対して仮定を持ち出す

412 :デフォルトの名無しさん:2006/02/13(月) 01:04:38
ところで、文法うんぬん依然に、どんなバグを対象にしてるのかだれか書いてる?

413 :デフォルトの名無しさん:2006/02/13(月) 01:21:11
>>412
言い出しっぺからどうぞ。

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

414 :デフォルトの名無しさん:2006/02/13(月) 01:28:22
デバッグ続けたらバグは最終的に0になるぞ
ただし0になったことを確かめる術はないが

415 :デフォルトの名無しさん:2006/02/13(月) 01:30:14
>>414
>>411

416 :デフォルトの名無しさん:2006/02/13(月) 01:41:33
>>414
> デバッグ続けたらバグは最終的に0になるぞ

証明してみな。

417 :デフォルトの名無しさん:2006/02/13(月) 01:41:57
>>347-364が、インターフェースの考慮漏れとかを解決(支援)してるとは、深いなぁ。

418 :デフォルトの名無しさん:2006/02/13(月) 01:45:05
>>416
1 検査する
2 バグが見つかる
3 バグを処理して1に戻る
この仮定をデバッグとする

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

419 :デフォルトの名無しさん:2006/02/13(月) 01:46:41
>>418
> 3 バグを処理して1に戻る

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

420 :デフォルトの名無しさん:2006/02/13(月) 01:47:23
決まった運用じゃ絶対出ない休眠バグも有るわけだが。

421 :デフォルトの名無しさん:2006/02/13(月) 01:48:48
>>419
関係ないのであなたがやってください

422 :デフォルトの名無しさん:2006/02/13(月) 01:58:46
観測されないバグはバグじゃねぇよ
システムの寿命は有限なんだからよ

423 :デフォルトの名無しさん:2006/02/13(月) 02:02:14
>>421
ん?

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

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

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

424 :デフォルトの名無しさん:2006/02/13(月) 02:04:43
>>422
あらあら、デバッグの時間は無限なのに寿命は有限なんだな。

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

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

425 :デフォルトの名無しさん:2006/02/13(月) 02:39:34
バグだらけのスレですね

426 :デフォルトの名無しさん:2006/02/13(月) 03:18:18
>>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なメソッドは呼び出し禁止?それは厳しくないか?
それにそうしたらキャストしまくりになって、型にアノテーションを付けてる意味が半減する希ガス

427 :デフォルトの名無しさん:2006/02/13(月) 04:22:09
それに、あるメソッドがそのオブジェクトについてconstかどうかってのは安定性が低いからな。
単純なプロパティ取得メソッドならともかく、込み入ったメソッドで、
後から、フィールド書き換えが必要になる・必要だったことが判明する、
なんてことはざらにある。

428 :デフォルトの名無しさん:2006/02/13(月) 07:10:36
>>424
>て言うか、その理論なら動かさないプログラムはバグ "0"
そんなの当然だろ?

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

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

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

429 :デフォルトの名無しさん:2006/02/13(月) 07:55:50
クロスプラットフォームなフレームワークで書かれた関数を
一箇所で集中管理して使用方法や目的も明確に付加して
みんなで使う、新しいの作ったらくだらないものでもアップ
して再利用するようにする
これ完璧な言語

430 :デフォルトの名無しさん:2006/02/13(月) 07:57:03
そして整合性保てなくて崩れていくわけだな

431 :デフォルトの名無しさん:2006/02/13(月) 08:06:46
使うユーザが検証するし、使うたびに信頼度を上げるような感じにしといて
信頼度が低いヤツは自然消滅するようにしとけばいいさw
いけると思うんだが

432 :デフォルトの名無しさん:2006/02/13(月) 08:08:57
簡単に言えばプロジェクト区別のないCVSの関数クラス版だ

433 :デフォルトの名無しさん:2006/02/13(月) 11:44:11
>>429,431
CPANにバグがないと?

434 :デフォルトの名無しさん:2006/02/13(月) 16:06:25
>>430
あるあるwwwwww
整合性が保てるように関数にバージョン管理とか

435 :デフォルトの名無しさん:2006/02/13(月) 18:11:42
>>426はPascalの部分範囲型ではどうなんだろう。
Delphiとかオブジェクト指向のPascalなんかが気になる。

436 :デフォルトの名無しさん:2006/02/13(月) 22:28:11
CPANにバグがあるのは開発者が限られてるってこととひとつひとつがでかいからな
複数開発してる人もいるしな
モジュール別に見ても重複コードが散在してる状態だからだろ
XMLなんかでW3Cの標準コードをリモートリンクする機能があるけどあんな感じで
組む時はリンクはプリコンパイラが自動でリモートからとってくる
参照登録修正はIDE上で簡単に行えるようにすればいい

437 :デフォルトの名無しさん:2006/02/13(月) 23:55:44
>>428
まあ、そういう定義ならそうでもいいけど、とにかくさっさ
>>419 を証明してくれよ。

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

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

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

438 :デフォルトの名無しさん:2006/02/14(火) 00:07:12
>>437
>>419バグが増えたら何かあるの?
増えたバグごと潰していけばいいんですよ
単純増加しているように見えたとしても、です

439 :デフォルトの名無しさん:2006/02/14(火) 00:39:54
バグが"0"になるかどうかがバグの出にくい言語仕様を考えるのになんか影響するか?

440 :デフォルトの名無しさん:2006/02/14(火) 00:43:52
>>439
いやさっぱり

441 :デフォルトの名無しさん:2006/02/14(火) 00:53:48
言語スレかと思って開いたが、スレ違いか。

442 :デフォルトの名無しさん:2006/02/14(火) 01:22:34
>>435
部分範囲型は、booleanとか整数型とかだけで、クラスを含めた構造体みたいのにはない。
範囲を外れる代入は、静的に解る部分はコンパイルエラー、ほかは実行時例外。

443 :デフォルトの名無しさん:2006/02/14(火) 10:58:02
Pascalの文法じゃ範囲型は序数(Ordinary)で無いとダメでしょ
その系列のOOな言語の中にはOrdinaryのサブクラスになっていれば部分範囲型も実現できるのがあるんじゃない?

444 :デフォルトの名無しさん:2006/02/14(火) 11:51:32
系列じゃないけど、Rubyにあるのは…違うなぁ。
Pythonにあるrange()はあるのは…違うなぁ、大体型じゃないし。

445 :デフォルトの名無しさん:2006/02/14(火) 11:53:25
もうね、oopでいいよ

446 :デフォルトの名無しさん:2006/02/14(火) 14:49:10
プリミティブな序数なら代入だけチェックすればいいけど、
オブジェクトだとメソッド呼んだだけで"値"が変わり得るし、さらに知らんうちに他のスレッドがやっちまうかも知れん。

447 :デフォルトの名無しさん:2006/02/14(火) 16:28:51
オブジェクトにそのアノテーションを持たせて
DbCのinvariantととしてメソッド前後毎回チェックすればええ。

448 :デフォルトの名無しさん:2006/02/14(火) 17:35:26
>>446
JavaのComparatorは明示的には書いてないが、
compareメソッドの呼び出しだけではその値が変わらないことが要求にある
スレッドセーフかどうかは関係無い

449 :デフォルトの名無しさん:2006/02/14(火) 19:02:52
アノテーションの定義し忘れバグ
アノテーションの定義間違いバグ
アノテーションの更新し忘れバグ

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

450 :デフォルトの名無しさん:2006/02/14(火) 21:37:18
別スレッドが、ってのはMTsafeとか関係なくて
参照型だとコードの特定部分では変更されてないようでも、他のスレッドが参照を持ってて変更しちまうかも、って事。

451 :デフォルトの名無しさん:2006/02/14(火) 21:38:33
>>450
それは言語の問題ではないのでスルーよろです

452 :デフォルトの名無しさん:2006/02/14(火) 22:50:52
いや、ミュータブルなオブジェクトを
簡単につくる機能を言語がサポートしたら
その手のバグは減るんじゃなかろうか。

453 :デフォルトの名無しさん:2006/02/14(火) 22:55:11
ちがった、イミュータブルだ

454 :デフォルトの名無しさん:2006/02/14(火) 23:04:50
>>451←こいつアホ?

455 :デフォルトの名無しさん:2006/02/14(火) 23:53:29
言語仕様だけでなく開発環境をふくめて
ますます話が難しくなってきた感がある。

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

456 :デフォルトの名無しさん:2006/02/15(水) 00:01:14
変更に弱くなるというデメリットがあるね

457 :デフォルトの名無しさん:2006/02/15(水) 00:07:30
>>455-456
SQL で書く ⇒ 変更に弱くなる

kwsk plz.

458 :デフォルトの名無しさん:2006/02/15(水) 01:39:35
>>449 = >>360 = 解ってないくせに難しそうな話に口を突っ込みたい10代前半男子。
アノテーションのミスでプログラム本体がバグるのか。
もっと勉強汁、少年。

459 :デフォルトの名無しさん:2006/02/15(水) 01:42:00
ちなみに>>458は最近オナヌー覚えたみたいです (`・ω・´)

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

460 :デフォルトの名無しさん:2006/02/15(水) 01:48:40
>>448
>>446の「メソッド」は、compareメソッドに限定してないぞ。
単に、オブジェクトいじってるうちにいつの間にか範囲を超えちゃう可能性があると言うこと。
だから、代入時のチェックだけではだめと。

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

461 :デフォルトの名無しさん:2006/02/15(水) 01:50:48
>>459
>実行時において注釈を持たせるなんて普通の言語でできる
kwsk

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

462 :デフォルトの名無しさん:2006/02/15(水) 01:59:09
オブジェクトがいつ変わるか解らないというのは、>>447はメソッドの前後でチェックというが、
オブジェクトのメンバ自体が他から参照されてて勝手に変更される可能性もある。

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

463 :デフォルトの名無しさん:2006/02/15(水) 01:59:18
>>461
型有り言語で一々型調べたり実際のモノを調べたりするんじゃね?

>>449とは関連性あるのかわからんのでkwsk

464 :デフォルトの名無しさん:2006/02/15(水) 02:05:15
>>462
OOPではカプセル化された内部のものはアクセス不能という烙印を押すわけだから・・・

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

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

465 :デフォルトの名無しさん:2006/02/15(水) 02:18:54
>>464
>OOPではカプセル化された内部のものはアクセス不能という烙印を押すわけだから・・・
現実には、例えばsetterに渡したオブジェクトは(コピーされず)そのまま保持される、
というのが普通だと思うけど、渡した側がそのオブジェクトを直ぐ捨ててくれるとは限らないわけで。

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

466 :デフォルトの名無しさん:2006/02/15(水) 02:21:57
>>324-334 が(最初の方では静的のみだったのに)
動的に値チェックする方向になってるが、重大な問題があるのでは?

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

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

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


467 :デフォルトの名無しさん:2006/02/15(水) 02:25:25
>現実には、例えばsetterに渡したオブジェクトは(コピーされず)そのまま保持される、
>というのが普通だと思うけど、渡した側がそのオブジェクトを直ぐ捨ててくれるとは限らない
現実には、その当たりの原因でのバグってあんまり見ないけど、何でだろう。

468 :デフォルトの名無しさん:2006/02/15(水) 02:55:30
>>467
基本的にプロパティとして受け渡しするような情報はシリアライズ可能なデータであることが多いからだろ

469 :デフォルトの名無しさん:2006/02/15(水) 03:06:58
>>466
型情報が動的に変わるのはアレだな。
実行時にpublicがprivateになったりメソッドが減ったりするのと同じだな。
そう言う言語もあるけど、このスレ的にはお勧めじゃないだろ。
字句的スコープで良いんじゃない?
キャスト時と受け渡し時のチェックだけで十分じゃね?


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

470 :デフォルトの名無しさん:2006/02/15(水) 08:38:11
>>454
いや、お前がアホ

471 :デフォルトの名無しさん:2006/02/15(水) 08:47:39
>>469
>その割合は確かに多いけど、それでも半分以上はミュータブルだろ、実際。

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

472 :デフォルトの名無しさん:2006/02/15(水) 09:40:23
>>471
その辺のデータを参照わたしすることは
あんまりないと思う。

473 :デフォルトの名無しさん:2006/02/15(水) 22:16:43
>>467
参照渡しであることも理解せずに
作る→値設定→格納 とか 取得→値設定→格納 とか
冗長なコードはよくみるよ。

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

みたいな

474 :デフォルトの名無しさん:2006/02/15(水) 22:18:21
>>458
アノテーションとプログラム本体の乖離はバグじゃねぇか?

475 :デフォルトの名無しさん:2006/02/15(水) 23:24:00
>>472
だから何?

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

476 :デフォルトの名無しさん:2006/02/16(木) 02:04:38
>>469
キャストと受け渡しがなかったら、アノテーション通りである事が保証されないってのは気持ち悪くないか?

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

477 :デフォルトの名無しさん:2006/02/16(木) 09:16:33
>>475
ああ、まさか流れを読まずに発言していたとは思わなかったよ。

478 :デフォルトの名無しさん:2006/02/16(木) 19:22:45
並列度を上げたときに起こる制御手順の乱れを
シミュレートしながらデバッグできる言語なんてあるといいな

479 :デフォルトの名無しさん:2006/02/16(木) 19:26:19
>>478
具体的な作業書いてないからどうでもいいが、
とりあえずOOPの目指すところそのものだな

480 :デフォルトの名無しさん:2006/02/16(木) 21:15:39
>>477
はぁ?それはテメーだボケ。

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

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

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

481 :デフォルトの名無しさん:2006/02/16(木) 21:27:18
良く使われるから実装されたり、
良く使わなかったら実装されない
というのなら、統計情報出さないとな。

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

482 :デフォルトの名無しさん:2006/02/17(金) 00:37:21
何いってんだコイツは。
どの言語でも使われている/使われていないが大抵判断基準としてあるだろ。
使われているから特別なシンタックスシュガーが用意されたりよ。

483 :|                             |:2006/02/17(金) 00:42:24
   ̄ ̄ ̄)/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
     ∧_∧
    ( ´・ω・`)     ∧_∧
    /     \   (´∀` ) ハハハ
.__| |    .| |_ /      ヽ
||\  ̄ ̄ ̄ ̄   / .|   | |
||\..∧_∧    (⌒\|__./ ./
||.  (    )     ~\_____ノ|   ∧_∧
  /   ヽアホか       \|   ( ´_ゝ`) 何言ってんだコイツ?
  |     ヽ           \/     ヽ.
  |    |ヽ、二⌒)        / .|   | |
  .|    ヽ \∧_∧    (⌒\|_∩./ /

484 :|                             |[:2006/02/17(金) 08:43:56
   ̄ ̄ ̄)/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
     ∧_∧
    ( ´・ω・`)     ∧_∧
    /     \   (´∀` ) ハハハ
.__| |    .| |_ /      ヽ
||\  ̄ ̄ ̄ ̄   / .|   | |
||\..∧_∧    (⌒\|__./ ./
||.  (    )     ~\_____ノ|   ∧_∧
  /   ヽアホか       \|   ( ´_ゝ`) 何言ってんだコイツ?
  |     ヽ           \/     ヽ.
  |    |ヽ、二⌒)        / .|   | |
  .|    ヽ \∧_∧    (⌒\|_∩./ /


485 :デフォルトの名無しさん:2006/02/17(金) 12:50:40
世の中の馬鹿共の使用状況に言語仕様が阿ることで、
バグが出にくくなる理由を問いたい。

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

486 :デフォルトの名無しさん:2006/02/17(金) 13:02:46
>>485
コンパイル時にエラーが出てコンパイル不能になるならば、
それが出荷されて世に出ることもなくなるだろう。


487 :デフォルトの名無しさん:2006/02/17(金) 13:05:01
ひらめいた! コンパイルするふりをしてエラーしか出さないようにすれば
いかなるプログラムも世に出ることはなくその損失が未然に防げるではないか。

よし。これで行こう。

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


488 :デフォルトの名無しさん:2006/02/17(金) 13:07:38
>>487
そんなことするより
 プログラム作る→禁固300年
でいいんじゃないか?

489 :デフォルトの名無しさん:2006/02/28(火) 23:59:41
このスレ的には>>488でFA?

490 :デフォルトの名無しさん:2006/03/01(水) 14:00:27
>>488
プログラミング免許を各言語毎に作って違反したら罰金でいいんじゃないか?
その他細かい違反も作る。たとえば無駄なアルゴリズムを使ったら1点原点とか。
負荷が高くなるアルゴリズムを使ったら2点原点とか。


491 :デフォルトの名無しさん:2006/03/01(水) 14:48:27
そうしたらC++は何段階かほしいな。
1級 C++の全てを完全に使用できる。
2級 中程度にテンプレートを使用できる。
3級 クラスと仮想関数による多態性(ポリモーフィズム)を使用できる。
4級 ベターCとして使用できる。

492 :デフォルトの名無しさん:2006/03/01(水) 15:33:46
姉歯みたいなのが出てきそうだね。

493 :デフォルトの名無しさん:2006/03/01(水) 15:48:24
malloc() で NULL が返された時のエラーチェックを忘れたり
free() を忘れたら10点原点、罰金50万円で免許取消。


494 :デフォルトの名無しさん:2006/03/01(水) 15:56:02
まあしかし原発とか、兵器とか、医療機器とか、車とか、
壊れた時の社会的影響が大きいものでも民間人が何の資格も
なく作って納品できるというのは、何か恐い感じはする。
使う人は資格が要るが、作る人には要らないという状態で
いいのか?


495 :デフォルトの名無しさん:2006/03/01(水) 19:42:21
>>494
作るのに資格が要らなくても、製品そのものが規格をパスしないとあかんから大丈夫
・・・っていいたいところだけど、そうじゃない製品もあるんだろうねぇ。

496 :デフォルトの名無しさん:2006/03/01(水) 20:35:31
>>494
バケツで運ぶのにも免許が必要だよな

497 :デフォルトの名無しさん:2006/03/17(金) 00:04:08
C言語で文字列配列の初期化書いたらカンマが抜けてて文字がくっついてしまった。

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

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


498 :デフォルトの名無しさん:2006/03/17(金) 00:35:20
printf(
">>497\n"
"そんな警告出したら、長い文字列改行して記述できなくなるじゃん?\n"
"それでもいいのなら、俺様仕様のローカルルールでコンパイラをチューンすれば良いよ。\n"
);

499 :デフォルトの名無しさん:2006/03/17(金) 00:39:12
>>498
俺lintで充分ジャマイカ?

500 :デフォルトの名無しさん:2006/03/17(金) 11:10:27
>>497
C言語とは、そういうものだ。


501 :デフォルトの名無しさん:2006/03/17(金) 11:54:57
>497
言語の仕様なんだからコンパイラに文句言うなよ

502 :デフォルトの名無しさん:2006/03/18(土) 11:37:38
>>501
カンマが無いと文字列がつながるのは言語仕様だけど、どんな警告だすか(ださないか)まで言語仕様なんだっけ?
文字列配列の初期化の部分だけでも判定してくれたらよいのに。
警告だからカンマなしのコードでもコンパイルは通るしね。



503 :502:2006/03/18(土) 11:42:03
ちょっと気になったのだが、俺は警告=ウォーニング=オブジェクトできる。という認識なのだが。
もしかしてみんなは警告=エラー=オブジェクトできない。という認識?


504 :デフォルトの名無しさん:2006/03/18(土) 12:08:19
>>503
警告が無くなるまで己の書いたコードは許せないという人も世の中には多い。

505 :デフォルトの名無しさん:2006/03/18(土) 12:35:34
通常の場合に、警告あっても許せる奴は死んでイイよ。
だが、もともと設計が腐ってて仕方がない場合も。

506 :デフォルトの名無しさん:2006/03/18(土) 12:40:47
>>503
警告と別に、ヒントを出してくれるのならそれはそれでOK。
使いたくなければ使わないだけだから。
でもそれは、恐らくコンパイラではなくlntの仕事。

507 :502:2006/03/18(土) 12:59:36
lntかぁ。
コード診断のソフトっていろいろあるが、みんな仕事でどの程度使ってる?


508 :デフォルトの名無しさん:2006/03/21(火) 12:16:05
lintでそ。
自分の書くコードはlintクリーンだけど何か?

509 :デフォルトの名無しさん:2006/03/21(火) 14:01:29
>>508
lintのおかげでバグを摘出できたって事ある?


510 :デフォルトの名無しさん:2006/03/23(木) 21:50:26
無い、決まりだからやってるだけ
メンドクセ

511 :デフォルトの名無しさん:2006/03/24(金) 23:59:50
lintってバグを検出するものではなく、
バグが現象として見える前に排除するものだと思うが。

512 :デフォルトの名無しさん:2006/03/25(土) 10:30:08
スゲー
lint最強じゃん

513 :デフォルトの名無しさん:2006/04/04(火) 22:46:07
バグをなくすにはテストが肝要。
いかにテストしやすい言語にするか、そこだろう。


514 :デフォルトの名無しさん:2006/04/04(火) 23:29:56
>>513
なに言ってんだ、おまえ?
テストなんかしたらバグが出るじゃないか。
テストしなけりゃバグはゼロだぞ。
君はスレタイを10回音読しときなさい。

515 :デフォルトの名無しさん:2006/04/05(水) 01:10:24
納品もできないけどな

516 :デフォルトの名無しさん:2006/04/05(水) 13:58:11
そうだ、仕様にしよう

517 :デフォルトの名無しさん:2006/04/05(水) 23:20:23
C0C1を100%通る入力を自動生成することって原理的に可能なんだっけ?


518 :デフォルトの名無しさん:2006/04/06(木) 00:40:32
C0C1って何?

519 :デフォルトの名無しさん:2006/04/06(木) 08:14:27
ヒント:カバレージ


520 :デフォルトの名無しさん:2006/04/06(木) 09:01:23
なるほど。それって、入力の生成以前に
flag = false;
if (flag) {
 .....
}
とかそもそもダメじゃん。意図せずバグでこうなってるときも。

521 :デフォルトの名無しさん:2006/04/06(木) 10:29:07
じゃあ、絶対通らないパスを検出してくれるチェッカと組み合わせて使うとか。
絶対通らないパスの検出が原理的に可能かどうか知らんけど。

522 :デフォルトの名無しさん:2006/04/06(木) 14:49:40
>>521
Javaのコンパイラって内部的にそれを検出していると思うぞ。
何にも警告出ないと思うが。JavaはCみたいなプリプロセッサを
通さないからデバッグコードを埋め込みたい場合にデバッグ時は
true にしておいて終わったらfalse にするという用途で使う。
で、false になっていた場合はその内部がコンパイルされない。

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


523 :デフォルトの名無しさん:2006/04/06(木) 19:19:46
>>522
そういう単純な場合は検出できるだろうけど条件式が複雑になった場合も検出できるかが問題。


524 :デフォルトの名無しさん:2006/04/07(金) 01:33:59
複雑さというか、プログラム停止問題とか絡んで、
完全にすべて検出するってのは無理そうだな。






525 :デフォルトの名無しさん:2006/04/07(金) 20:05:23
>>523
複雑でも解析していけばそのうち分かるんじゃないか?
但し動的にリンクするライブラリとかがあるとその部分ではできない。

526 :デフォルトの名無しさん:2006/04/08(土) 23:55:43
>>525
確か無理なことが数学的に証明されてたと思います。


527 :デフォルトの名無しさん:2006/04/09(日) 00:08:56
ところで、話は変わるけど、俺はついに画期的な天気予報のシステムを開発した。
何がすごいって、予報的中率が100%なんだ。
でも一つ欠点があってね、1週間後の天気を計算するのに2週間かかることなんだ!

528 :デフォルトの名無しさん:2006/04/09(日) 00:21:04
コンピューターの性能が4倍にでもなればいいのかあ。

529 :デフォルトの名無しさん:2006/04/09(日) 12:22:59
ナビア・ストークス方程式を解けばいいだけだね。

530 :デフォルトの名無しさん:2006/04/09(日) 13:59:02
ムーアの法則により 3 年くらいで解決するんじゃない

531 :デフォルトの名無しさん:2006/04/09(日) 18:50:22
ラプラスの悪魔について
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

532 :デフォルトの名無しさん:2006/04/09(日) 20:14:54
石原良純が言う逆のことを考えれば 100% の天気予報に

533 :デフォルトの名無しさん:2006/04/09(日) 20:52:59
>>532
株でそれを思ったことがある。
常に負けているヤツの反対の買い方をすればいいと。

534 :デフォルトの名無しさん:2006/04/09(日) 22:31:38
株は負けの逆のことをしても勝ちとは限らないんだよね。

535 :デフォルトの名無しさん:2006/04/09(日) 23:40:19
>>533 は真実。負けているやつと、勝っているやつの両方を知ると有益。
 

536 :デフォルトの名無しさん:2006/04/10(月) 14:46:48
>>533
逆張り? 株じゃないけど逆のことやって大きくなった会社が北陸になかったか?
ホテル業か不動産か忘れたが。


537 :デフォルトの名無しさん:2006/04/11(火) 00:38:08
>>525
現在のコンピューターというのは、数学的にはチューリングマシンと言われるモノを、機械的に再現したモノです
これは言語が何であれ、そこからは逃げられないモノです
そして、チューリングマシンでその問題が計算できるかどうかは、チューリングマシンの停止問題から、完全予測は不可能なことが証明されている。

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

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


538 :デフォルトの名無しさん:2006/04/11(火) 00:53:22
現在のコンピュータは、チューリングマシンというよりか線形拘束オートマトンかな。

539 :デフォルトの名無しさん:2006/04/11(火) 02:12:15
チューリングマシンと別次元に量子コンピュータや、DNAコンピュータがある

540 :デフォルトの名無しさん:2006/04/11(火) 19:19:47
量子コンピュータには確かにロマンを感じるがDNAはなんか力技っぽいからなぁ。


541 :デフォルトの名無しさん:2006/04/11(火) 21:28:46
量子コンピュータについては、一般人は高性能コンピュータというイメージを持っているが、実際には全く違うものだ。
だから、量子コンピュータの実物が普及してもPCは相変わらずノイマン型だろうと思う。

542 :デフォルトの名無しさん:2006/04/11(火) 21:47:17
そだねー。

543 :デフォルトの名無しさん:2006/04/11(火) 22:46:11
1+1の答えは80%の確率で3。



544 :デフォルトの名無しさん:2006/04/12(水) 02:21:15
10^-80% 位にまからん? せめて 2^-80%

545 :デフォルトの名無しさん:2006/04/23(日) 14:51:23
数十回繰り返し計算した結果の中で最も出現頻度の高い値を計算結果として採用

546 :デフォルトの名無しさん:2006/04/24(月) 03:14:34
バグの出にくい言語仕様より
バカの出にくい「なにか」が欲しい。

547 :デフォルトの名無しさん:2006/04/25(火) 22:36:43
>>546
たとえば?


548 :デフォルトの名無しさん:2006/04/26(水) 22:47:39
テスター

549 :デフォルトの名無しさん:2006/04/27(木) 21:03:40
メモリ開放の自動化
テストの自動化

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

550 :デフォルトの名無しさん:2006/04/27(木) 21:24:52
>>549
素人だな。

551 :デフォルトの名無しさん:2006/04/27(木) 21:43:38
それでは玄人の意見をきこうか。


552 :デフォルトの名無しさん:2006/04/27(木) 23:54:30
巨大なプログラムをもっと理解しやすくする術は無いもんだろうか。


553 :デフォルトの名無しさん:2006/04/28(金) 09:05:19
文字じゃなしに図をうまく利用すれば理解しやすくなるかも。

554 :デフォルトの名無しさん:2006/04/28(金) 09:24:23
UMLとか?
図が巨大になりすぎてやっぱりわからないなんてことも起こりかねない。
まあ、それでもソースだけよりはましなんだろうが。



555 :デフォルトの名無しさん:2006/04/28(金) 18:05:20
このスレで動作単位の粒度について話しても
どうこうなるとは思わないぞ

556 :デフォルトの名無しさん:2006/04/28(金) 18:19:31
お前らが小手先で思いつくことはすべて考えられていると思え。

557 :デフォルトの名無しさん:2006/04/28(金) 21:57:32
素人考えでもいいじゃない。
2chだもの。


558 :デフォルトの名無しさん:2006/04/29(土) 01:17:35
>>549
入力値チェックの自動化というか、
値チェックの自動化なら>>324当たり以降にあるぞ。

559 :デフォルトの名無しさん:2006/04/30(日) 08:07:31
>>552
doxygenでいいんじゃね?
結構使える。


560 :デフォルトの名無しさん:2006/04/30(日) 10:58:04
GNU GLOBAL も。

561 :デフォルトの名無しさん:2006/05/09(火) 21:23:37
>>559
>>560
ネタもないようなのでdoxygenとGNU GLOBALについて語ってくれんか?


562 :デフォルトの名無しさん:2006/05/09(火) 21:49:15
バグの出にくい、ということであれば、トレンドは関数型言語でしょうな・・

563 :デフォルトの名無しさん:2006/05/18(木) 20:40:48
関数型言語のはなしも前に出てたな…
結論はなんだったけ?


564 :デフォルトの名無しさん:2006/06/06(火) 22:37:30


565 :デフォルトの名無しさん:2006/06/10(土) 23:46:13
無限ループを禁止すればよくね
必ず有限の回数を実行すれば止まることにすれば 停止問題も解決するし 理論上全組み合わせを調べればバグの有無が証明可能

566 :デフォルトの名無しさん:2006/06/11(日) 02:11:28
>>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



567 :デフォルトの名無しさん:2006/06/11(日) 08:43:27
無限ループを禁止すると一部表記不能になるだろうが、そもそも無限ループになる時点で現実では意味が無いだろ
構造化言語でループは必ず上限値をつけるとどうなるか想像してみた
……確かに無限ループがないとプログラム書くのは不可能だ

568 :デフォルトの名無しさん:2006/06/11(日) 08:48:08
状態遷移図で書くとバグに強い気がするがなぜだろう?

569 :デフォルトの名無しさん:2006/06/11(日) 11:34:20
>>565
ゲームも作れないし、
イベントドリブンのアプリも作れないじゃん。

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

570 :デフォルトの名無しさん:2006/06/11(日) 11:42:27
無限ループになることを期待していない箇所が無限ループになってたりするとバグになるんだから、
停止条件の検証……が一番効果ありそうだけどな。

571 :デフォルトの名無しさん:2006/06/11(日) 12:55:22
書けないプログラムがあってもよい弱い言語
→ 静的(実行せずに)停止性を判定可能

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

でFA?

572 :デフォルトの名無しさん:2006/06/11(日) 13:17:31
>>565
おまいの定義ではWindowsのメッセージループはどうなるの?

573 :デフォルトの名無しさん:2006/06/11(日) 14:38:35
>>572
一定回数起動するとアクティベーションが切れれば問題ないじゃん!
これでまた新しいビジネスモデルが出来たね

574 :デフォルトの名無しさん:2006/06/11(日) 21:04:51
何を言ってるんだ?

575 :デフォルトの名無しさん:2006/06/11(日) 21:43:45
プログラムが巨大化・複雑化したっていうのに、
今の言語は上位の図式モデルや設計情報との結合が弱すぎ。

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

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

576 :デフォルトの名無しさん:2006/06/11(日) 21:45:42
UMLでよくね?

577 :デフォルトの名無しさん:2006/06/11(日) 22:12:20
>>576
もの知らずもほどほどにな

578 :576:2006/06/11(日) 22:21:13
あーもちろんツール込みでのハナシね

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

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

579 :デフォルトの名無しさん:2006/06/11(日) 22:32:05
>>578
それなんてMDA?

580 :デフォルトの名無しさん:2006/06/11(日) 23:29:59
つうか時間と金とあと少しユーザさんの頭脳が良くなる事と全てが許される平和な世界があれば何とかなるな

581 :デフォルトの名無しさん:2006/06/12(月) 00:22:38
だいたい俺はループの関数ごときでバグったことなんかない。

582 :デフォルトの名無しさん:2006/06/12(月) 00:31:27
>>581
あなたが例外だったのかもしれない。

583 :デフォルトの名無しさん:2006/06/12(月) 00:52:07
>>582
お前よっぽど馬鹿だったんだなw
こんなところでバグってたらプログラム完成しないだろ?w

584 :デフォルトの名無しさん:2006/06/12(月) 01:05:10
>>581
まだプログラミングの日も浅いやつに言われたくないな。

585 :デフォルトの名無しさん:2006/06/12(月) 01:36:03
>>584
いわれてよく考えてみたら、始めてから8年近くも経ってるなw

586 :デフォルトの名無しさん:2006/06/12(月) 01:38:22
>>585
予想通りの返答です。

587 :デフォルトの名無しさん:2006/06/12(月) 01:42:02
まだ8年か

588 :デフォルトの名無しさん:2006/06/12(月) 01:43:00
8年間なにやってきたの?
せいぜい1000行のプログラムしか書いたことなさそう。

589 :デフォルトの名無しさん:2006/06/12(月) 21:10:46
まぁ
while(1){}
とか書いてたんじゃないか。八年

590 :デフォルトの名無しさん:2006/06/13(火) 23:48:42
配列とか、いわゆるCollectionを用意して、
foreachとかでグルグル回すだけにしとくのはどう?


591 :デフォルトの名無しさん:2006/06/15(木) 00:27:46
もちろん長さが無限のCollectionも用意するんだよね?

592 :デフォルトの名無しさん:2006/06/15(木) 20:41:30
それじゃ意味ないんじゃ。

593 :デフォルトの名無しさん:2006/07/06(木) 17:40:19
あげ

594 :デフォルトの名無しさん:2006/07/09(日) 02:30:42


595 :デフォルトの名無しさん:2006/07/09(日) 12:28:25
型安全じゃなくてもバグを出にくくする方法ってあるんだろうか


596 :デフォルトの名無しさん:2006/07/09(日) 12:42:35
>>595
型付ラムダ計算についてもっと勉強しなさい

597 :デフォルトの名無しさん:2006/07/09(日) 12:47:34
間違えた
×型安全じゃなくても
○型付けの弱い(もしくは型が無い)

598 :デフォルトの名無しさん:2006/07/09(日) 19:03:01
>>595
静的型・動的型って区分ならば、型推論というアプローチもある。
ちなみに俺は tRuby ってのに注目していたりするが。

599 :デフォルトの名無しさん:2006/07/13(木) 16:40:32
これまでの議論の対極を行こう。可能な限りフラットな構造をとる。
たとえば
リレーショナルデータベース。SQLPLUSだけでプログラミングする
イメージで言語を作ったら。

600 :デフォルトの名無しさん:2006/08/15(火) 21:35:47
>>575
はげどう。
UMLとソースとの同期を取りますとか、UMLからソースを自動生成しますとか、
そんな考え自体が間違いじゃないか。


601 :デフォルトの名無しさん:2006/08/22(火) 20:13:43
>>600
つまりどうすれば良いわけ?


602 :デフォルトの名無しさん:2006/08/23(水) 09:54:23
>601
>575 図式モデルでプログラミングできたり
UML→ソース じゃなくて UML(等の図)=ソース と言いたいんじゃなかろうか
UMLを直接コンパイルするような

603 :デフォルトの名無しさん:2006/08/23(水) 18:24:21
ソースはアスキー文字じゃないと落ち着かない俺が居る。


604 :デフォルトの名無しさん:2006/08/23(水) 23:54:38
>>603
emacsの拡張で、AAでUML書くのがあった気がする。

605 :デフォルトの名無しさん:2006/08/25(金) 03:45:18
>>604
そういう問題でもない。
と、釣られてみる。


606 :デフォルトの名無しさん:2006/08/26(土) 18:44:16
既に言語仕様うんぬんの話じゃなくなってるのでここで原点回帰



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

607 :デフォルトの名無しさん:2006/08/26(土) 18:48:35
先ずは「バグ」の分類しなきゃ話にならんな
・致命的
・どうでもいい

とか

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

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

608 :デフォルトの名無しさん:2006/09/15(金) 23:34:22
仕様記述言語とかどうだろう。

609 :デフォルトの名無しさん:2006/09/16(土) 02:19:31
>>608
古すぎる。
Haskellなどはすでに仕様記述言語と同等レベルの抽象化ができるから。

610 :デフォルトの名無しさん:2006/09/16(土) 10:06:13
バグの作りこみにくさでいくと、Haskell>javaなわけ?
もれはHaskell使ったことないが。

611 :デフォルトの名無しさん:2006/09/21(木) 00:36:23
Haskellいいですね。
Haskellに事前、事後、不変条件をつけて評価してみたいです。


612 :デフォルトの名無しさん:2006/09/21(木) 01:16:07
>>575
設計情報・図式モデルはある程度までしか複雑化できないのです。
今の図式モデルは肝のところしか表現されていません。

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

613 :デフォルトの名無しさん:2006/10/08(日) 11:31:29
>324-329,334 が理解できない。
馬鹿な俺でもわかるように解説してくれ

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

614 :デフォルトの名無しさん:2006/10/08(日) 12:06:02
>>613
今の型付言語だと構文チェック以外には型以外のオブジェクトの属性はチェックしないのが多いから配列の次元数やNull代入不可とかのチェックをしようって事
すでにそういう言語は無い事はない

615 :デフォルトの名無しさん:2006/10/08(日) 13:56:51
余計わかんなくなったw

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

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

616 :デフォルトの名無しさん:2006/10/08(日) 14:12:23
次元数じゃなくて、要素数の制約だ
最大10個と決めてるところに最大15個の配列を入れるとオーバーするとか必ず3つと決めてるところに1つしか入れないと数が足りないとかそんな感じ

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

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

617 :デフォルトの名無しさん:2006/10/08(日) 14:38:11
>>616
お、Nullは大体わかた

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

618 :デフォルトの名無しさん:2006/10/08(日) 18:51:09
>>17

MATLAB みたい

619 :デフォルトの名無しさん:2006/10/08(日) 21:26:11
>>617
次元て言ってるのは、配列とは関係ない。物理単位の指数のこと。
速度の次元は、例えばm/sec、つまり距離が1次元、時間が−1次元、という事。

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

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


…だと思う。

620 :デフォルトの名無しさん:2006/10/08(日) 21:39:05
>>325は1パラメタだけど、
距離、質量、時間の3パラメタにすれば、

//型に付くメタデータその3(コンパイル時チェック)
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 ); //コンパイルエラー

621 :デフォルトの名無しさん:2006/10/08(日) 22:31:10
>>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);//コンパイルエラー

622 :デフォルトの名無しさん:2006/10/09(月) 02:00:26
仕様書をそのままコピペするだけで動いちゃう

623 :デフォルトの名無しさん:2006/10/09(月) 02:33:28
long[]@$::zipWithMax( #length[ @ ] | #length[ int $n ] );

624 :デフォルトの名無しさん:2006/10/09(月) 02:41:20
「バグが出にくい言語仕様」というスレだからそういうのでもいいんだろうけど、
間違いを抑制するという効果しか生まないんじゃ、そのコストはあまり払われない。
間違いを抑制しつつ、求められる機能の実現手段にもならないと。

625 :デフォルトの名無しさん:2006/10/09(月) 03:33:08
>>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

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

626 :デフォルトの名無しさん:2006/10/09(月) 04:37:44
>>625
それだと、加速度も運動量も運動エネルギーもいちいち型定義が必要になるじゃん。

627 :デフォルトの名無しさん:2006/10/09(月) 04:44:18
>>626
それのどこに不都合が?

628 :デフォルトの名無しさん:2006/10/09(月) 04:46:25
つうか、そんなことより、こんな風に演算も汎用的に定義できるのがデカい希ガス

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

629 :デフォルトの名無しさん:2006/10/09(月) 04:50:02
>>627
その程度の数、と思ってるかもしれんが、
定数や計算途中で、特に名前の付いてない単位がいろいろ有り得る。
その組み合わせ数分の演算をいちいち別個に定義するのは無駄すぎる。

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

630 :デフォルトの名無しさん:2006/10/09(月) 04:51:58
>>629
オペレータオーバーロードじゃだめなの?

631 :デフォルトの名無しさん:2006/10/09(月) 04:54:29
演算子オーバーロードは、関数の名前が記号になるだけだろ?
色んな次元と色んな次元の単位の組み合わせ分の演算を定義しなくてはならんのは、なんら変わらん。

632 :デフォルトの名無しさん:2006/10/09(月) 04:58:16
>>631
そんなことないと思うよ?
継承と組み合わせれば、そのほとんどが省略できるんじゃない?

633 :デフォルトの名無しさん:2006/10/09(月) 04:59:59
オーバーロードとオーバーライドをごっちゃにしてないか?
次元が違う型をどうやってオーバーライド(継承)するんだ?
言っとくが、処理内容の問題じゃないぞ。
演算の型定義の話だからな?

634 :デフォルトの名無しさん:2006/10/09(月) 05:02:22
演算の型定義ってのは、どういう型の引数を取ってどういう型の返値を返すか、ね。

635 :デフォルトの名無しさん:2006/10/09(月) 05:02:49
>>633
処理内容が継承できれば十分なんじゃないの?

636 :デフォルトの名無しさん:2006/10/09(月) 05:05:29
処理内容が同じで、引数の型が違う演算ってどうやって継承で作るんだよ?
引数・返値の型をなんでも良いことにするのか?
それじゃそもそも型の意味がねぇw

637 :デフォルトの名無しさん:2006/10/09(月) 05:06:54
>>636
暗黙の型変換。

638 :デフォルトの名無しさん:2006/10/09(月) 05:11:57
なんでコンパイラがそんな暗黙の型変換が出来るんだよ。
すくなくとも>>625のコードにはそんな判断が出来る情報はない。
できるとすれば、単に型がdoubleであれば何でもよい、という無意味な結論になる。

639 :デフォルトの名無しさん:2006/10/09(月) 05:18:59
>>638
単位すべてについて型定義する。
これで解決。

640 :デフォルトの名無しさん:2006/10/09(月) 05:35:24
すまん、酔っぱらってるんで無駄に攻撃的なレスになっていたようだ。
その、「すべてについて」定義するのが無駄じゃん、て話だよ。

無駄というか、色んな次元の単位は無限にあるわけで、そもそもムリ。
>>628みたいのを演算×次元要素(上の例ではm,k,sの3つ)分用意すれば全てまかなえる。

さらに、定数も、例えばdouble@[Dim(2,1,-1,-1)](最後は温度。ボルツマン定数)みたいに、
わざわざそのためだけの型を定義しなくても、さっくり書けて、使われてる所の型チェックも出来るわけよ。

641 :デフォルトの名無しさん:2006/10/09(月) 05:38:28
http://ja.wikipedia.org/wiki/次元解析
に、「式の間違いをチェックする場合にも使える。」てあるじゃん。
まさにこれをコンパイル時に自動的に出来るようにするって事だよ。

642 :デフォルトの名無しさん:2006/10/09(月) 05:46:28
>次元解析
利点がわからん。
型で定義すりゃいいやん。

しかも、すんごい限定的すぎない?
速度とか時間くらいのために、こんなの実装すんの?
無限にある次元の単位を使う機会ってあるのかな?物理屋さんなのかな?

643 :デフォルトの名無しさん:2006/10/09(月) 05:48:51
あー、wikipediaみたら、わかった
http://ja.wikipedia.org/wiki/%E6%AC%A1%E5%85%83

そんなの普通のプログラミングに使わんw


644 :デフォルトの名無しさん:2006/10/09(月) 05:50:44
>>642
だよね。

645 :物理屋じゃないよ:2006/10/09(月) 06:03:57
役に立つ場面が限られるのは確かだけど、業務システムでも場面は十分あるよ。
オンラインのトランザクション毎の処理ではほとんどないだろうけど、
バッチとかで統計を出すとか、計算系処理では、
MKSの物理量じゃなくても、単位の次元が存在するのは普通。

まあ、それ間違ってたらとんでもない結果になるから、普通はテストで判るはずだけど。

でも、テストまで行かずにコンパイル時にチェックされた方が速いし、
まれにしか走らないロジックではテスト漏れの危険があるが、
コンパイルでチェックされれれば必ず発見される。

646 :デフォルトの名無しさん:2006/10/09(月) 06:19:47
C++ならテンプレートで出来そうな気がする



…気がするだけかも

647 :デフォルトの名無しさん:2006/10/09(月) 11:43:02
こんなの?

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;
}

648 :デフォルトの名無しさん:2006/10/09(月) 11:49:11
面倒だから * しか実装しなかったので物理的にめちゃくちゃなのは許して.
ちなみに発生するコンパイルエラーはこんなかんじ.

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'

649 :デフォルトの名無しさん:2006/10/09(月) 13:46:48
おーすげーすげー、さすがC++。
エラーメッセージは全然わかんないけど。
*の定義はどんなん?

650 :デフォルトの名無しさん:2006/10/09(月) 18:47:09
書いてからこれ略すのは自分でもどうかと思った.すまんかった.

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;
}

651 :デフォルトの名無しさん:2006/10/09(月) 21:25:45
つうか、型推論入れればそこまで定義しなくて良いよね

652 :デフォルトの名無しさん:2006/10/09(月) 22:00:33
型推論でこんなのいけるのかな?

653 :デフォルトの名無しさん:2006/10/09(月) 22:21:42
>>652 ここら辺はいろいろ研究されてるみたい。dependent type とか。
http://www.cs.bu.edu/~hwxi/DML/DML.html

654 :デフォルトの名無しさん:2006/10/10(火) 06:49:59
バグって、見つけた瞬間からバグなんじゃなかったっけ
見てみぬフリをすれば…

いや、スマソ

655 :デフォルトの名無しさん:2006/10/10(火) 11:30:00
> 単位の次元が存在するのは普通。
いや、普通じゃないと思うw


656 :デフォルトの名無しさん:2006/10/10(火) 12:29:25
>>655
MKSの物理量だけが次元を持つ単位じゃないんだよ?
例えば、「1人当たりの金額」なら、 単位は、円/人。
つまり 円が+1次元で、人数が−1次元だ。

こういうのは自然に誰でも判ると思ったんだけど、現実は厳しいのかなぁ…。

657 :デフォルトの名無しさん:2006/10/10(火) 12:44:19
>>656
物理学の世界をかじらないと難しいと思うよ


658 :デフォルトの名無しさん:2006/10/10(火) 12:58:21
「次元」というから難しいのか?「何乗」と言えばいいのか?
X/Y = X^1 × Y^(-1)。 さすがに、これなら誰でも高校か中学でやってるだろ。

659 :デフォルトの名無しさん:2006/10/10(火) 13:20:20
掛け算を習った後に交換法則を覚えるが、それは次元の交換までは保証していないって所は高等数学に行かないと教えてもらえない


660 :デフォルトの名無しさん:2006/10/10(火) 15:34:26
大学で無次元化ならったお

661 :デフォルトの名無しさん:2006/10/10(火) 16:05:40
どっちにしろ必要ないな。

662 :デフォルトの名無しさん:2006/10/10(火) 16:29:48
工業高校だと微分をちょっと触って終わりだ。しかも覚えてねえ。
今じゃもう因数分解すら出来ないぜ…

663 :デフォルトの名無しさん:2006/10/10(火) 23:55:01
次元解析はあくまで、>>324-329,334 の応用の一例。
>>324-329,334 は、
単に変数(定数)名だけじゃなくて値も使えるType SafeなEnumとか、
Genericsの仕組み自体とか、いろいろ作れる、みたい。

しかし、問題はバグを減らす事には役立つが、
機能を実現することに役立たないと言うことではないだろうか。

664 :デフォルトの名無しさん:2006/10/11(水) 09:46:04
>>656
大学で、MKSが次元ということはならったが、
それが一般に当てはまるところまではいかなかったなー。

まあ、応用利かない、俺も俺だがw

665 :デフォルトの名無しさん:2006/10/11(水) 13:37:41
>>664
大学まで来て数学をならったなら
その応用で金利計算とか人口統計とかの次元はなんだろな?と思ってくれよ

666 :デフォルトの名無しさん:2006/10/12(木) 20:36:23
単位か…こういうことが出来ると便利そう

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

まあ、妄想なんだけどね

667 :デフォルトの名無しさん:2006/10/12(木) 20:41:04
流石に変数名が安直だったか…

668 :デフォルトの名無しさん:2006/10/12(木) 20:46:23
AppleScriptでは単位つかえるよな

669 :デフォルトの名無しさん:2006/10/12(木) 22:43:54
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);
}

670 :669:2006/10/12(木) 22:45:15
続き

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;
}


671 :デフォルトの名無しさん:2006/10/13(金) 09:11:12
ほうほう

物理計算だけとか一分野限定ならそれで充分いけそうやね
SI基本単位は7つだけだし
規格がない場合もそうそう増えないだろうし

だけど、他分野も考慮しようとすると辛そうだ
まあ、滅多に無さそうだけど

D言語の強いtypedefならもう一歩いけるのかな

672 :デフォルトの名無しさん:2006/10/13(金) 13:32:54
物理に限定する理由がわからない。

673 :デフォルトの名無しさん:2006/10/13(金) 20:18:19
671 は一分野限定と言っているだけで、物理に限定してはいない。きっと

天体計算していたらふと人が住めそうな星が見つかったので
何人住めるか計算するために新次元 [人] を追加したくなった

とかいうケースを考慮してるんだと思うよ。
669 の実装では次元が増えたときの対処が結構めどい。

674 :デフォルトの名無しさん:2006/10/14(土) 21:27:29
結局型の強弱レベルの話題しかないんだな。

675 :デフォルトの名無しさん:2006/10/14(土) 23:47:21
>674
それは、今更ポインタ&メモリ管理絡みの話をしろと言う事かい?

676 :デフォルトの名無しさん:2006/10/14(土) 23:50:13
ソフトウェアの検証とかの方向に進まないかしら

677 :デフォルトの名無しさん:2006/10/15(日) 00:07:32
型を強くすることで、コンパイルがソフトの検証になるんじゃん。

678 :デフォルトの名無しさん:2006/10/15(日) 01:43:54
>>677
検証の一部は肩代わりできるが、検証にはならない

679 :デフォルトの名無しさん:2006/10/15(日) 04:00:16
どういう検証を言っている?

680 :デフォルトの名無しさん:2006/10/15(日) 12:18:20
concept_checkで事前事後条件例外仕様もチェックだぜ

何年後になるやら

681 :デフォルトの名無しさん:2006/10/15(日) 14:13:21
それって、>>324-329,334 でできないの?

682 :デフォルトの名無しさん:2006/11/02(木) 01:24:18
JSR 308ってのが出来たらしいけど、
これって、>>324-329,334 のパクリ?

http://jcp.org/en/jsr/detail?id=308

683 :デフォルトの名無しさん:2006/11/02(木) 13:37:34
>>682
そこまで行くとさすがにJavaの小汚さが際立つな・・・。
C#みたいに[]にしとけば良いのに。

684 :デフォルトの名無しさん:2006/11/03(金) 13:15:41
>>683
言語仕様を変えずにアノテで実現がこの場合の肝だから

685 :デフォルトの名無しさん:2006/11/04(土) 22:12:15
Curl だとどこまで出来るんだっけ?<単位計算
 {let height:any = 16px} || heightは16ピクセルである事を表す
とか
 {let width:any = 12cm} || widthは12cmである事を表す
とか
 {let area:any = height * width} || 16px * 12cm
とか出来たよね。

686 :デフォルトの名無しさん:2006/11/07(火) 00:04:29
>>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

687 :デフォルトの名無しさん:2006/11/07(火) 12:35:23
JSR305って、特定のアノテーションが追加されるだけで、
>>324-329,334 みたいに、やりたいアノテーションを自分で作ることは出来ないのでは?

688 :デフォルトの名無しさん:2006/11/07(火) 19:27:03
誰か>>324-329,334を一レスくらいにまとめてくれ

689 :デフォルトの名無しさん:2006/11/07(火) 23:02:56
↓よろしく

690 :デフォルトの名無しさん:2006/11/07(火) 23:55:21
くしゃみ

↓み

691 :デフォルトの名無しさん:2006/11/08(水) 00:12:10
みかん><

692 :こんな感じ?:2006/11/08(水) 02:26:23
・<Java5のアノテーション>
→ <>>324-329,334の拡張> の形式で。

・修飾子が付くモノにしか付けられない
→ 変数の型宣言すべてに付けれる。メソッドのレシーバにも。
・コンパイル時、単発の「印」でしかない
→ アノテーションが付いた型は、付けた型の子型になる。さらに属性の値毎に別の子型になる。
→ キャストの可否(明示、暗黙)、実行時キャストチェックを定義できる。
・「どこ(メソッド、フィールド、パッケージ等)に付けられるか」しか指定できない
→ 「どの型に付けられるか」を指定できる
・アノテーションの属性には定数しか指定できない
→ 変数OK。演算もOK。演算はコンパイル時に行える。


これで、
型に保障された単位付き計算や、Generics機能そのもの、型安全Enumなど、
型機能によってコンパイル時に安全性を保障できる様々なバグ防止機能が作れる。

さらに、実行時キャストチェック定義によって、
Pascalの範囲型みたいの+強制DbCが、任意のクラスについて行える。

693 :デフォルトの名無しさん:2006/11/08(水) 14:12:18


ところでマルチスレッド関係のバグを減らす仕様ってあるのかな
デッドロックとか

同期機構の扱いになるんだろうけど

694 :デフォルトの名無しさん:2006/11/08(水) 14:20:19
全てのオブジェクトをイミュータブルにすれば良いんじゃね?

695 :デフォルトの名無しさん:2006/11/08(水) 16:18:56
パフォーマンス悪いもバグ

696 :デフォルトの名無しさん:2006/11/08(水) 22:10:12
ところで、型に起因するバグってそんなに多い?
実体とポインタの代入間違いぐらいじゃない?

どっちかっていうと
実体がどっから参照されているかわからない場合の
方がバグりやすいんだけど・・・
これってロジック的にはスパゲッティと同じだから
言語で乗り越えていくべきものかと思うけど
なんかいい方法ないかね?

697 :デフォルトの名無しさん:2006/11/08(水) 22:18:08
参照透明にすれば。

698 :デフォルトの名無しさん:2006/11/08(水) 22:38:06
>>697
不勉強で悪いのだけど、
それって初期化されたら変更できないってことだっけ?

699 :デフォルトの名無しさん:2006/11/08(水) 23:04:51
>>698
大雑把に言うとそう。

700 :デフォルトの名無しさん:2006/11/08(水) 23:52:25
>>696
根本的に勘違いしてるみたいだけど、
「型に起因するバグ」ってのは、そもそもありえない。
例えば、キャスト誤りは型がなくても元々バグ。
型は、バグを「検出」するだけだよ。型のせいでバグるってのはない。


それはそれとして、
実体がどっから参照されているかわからない場合のバグってのはどんなのを言ってる?

701 :デフォルトの名無しさん:2006/11/09(木) 00:11:25
>>700
連結リストで先頭をいじっても
他からの参照が変化しないから
ひとつ変化しない先頭をかませておくみたいなこと。

このあたりの整合性をソースのどっかでいじられると探すのが大変だったりしない?

702 :デフォルトの名無しさん:2006/11/09(木) 02:00:31
先頭をいじるってのは、値じゃなくて先頭を他のオブジェクトに取り替えるって事か?
そもそも、そんな事しないだろw

オブジェクトの値を更新したら、実は更新されては困る奴がそれを参照していた、
なんて事はまれにあるけど、それはそのオブジェクト(インスタンス)の位置づけが
曖昧だった、というのが問題。

まあ、安全なのは>>694だな。

703 :デフォルトの名無しさん:2006/11/09(木) 02:57:13
大半のバグの原因は、部分の仕様が曖昧か不完全って事だろ。

「□□である場合は」の□□の具体的な条件が決まってないとか。

「返値は○○」という事になっていても、△△という条件の場合は○○じゃない、とか。


つまり、条件も含めた仕様が強制的に明確になる言語仕様が必要。

704 :デフォルトの名無しさん:2006/11/09(木) 06:26:19
>>702
え?しない?
設計間違えたかな・・・

705 :デフォルトの名無しさん:2006/11/09(木) 20:08:18
リストのノードは入れモンだろ、常識的に考えて…。
なんで入れモンごと取り替えるんだよ。

706 :デフォルトの名無しさん:2006/11/10(金) 09:03:31
>>705
順序を変えたかったからなんだが・・・

707 :デフォルトの名無しさん:2006/11/12(日) 14:04:37
Java1.4 のコレクションは
キャストミス誘発しやすいな

708 :デフォルトの名無しさん:2006/11/12(日) 14:34:27
関数型言語の時代がそろそろやってきますよ

709 :デフォルトの名無しさん:2006/11/12(日) 14:46:32
もう来た。そして去った。

710 :デフォルトの名無しさん:2006/11/12(日) 15:37:54
>>709
まだ去ってないw

711 :デフォルトの名無しさん:2006/11/12(日) 16:21:38
確かに去ってはいないが。
「○○の時代」と呼ぶ事が出来るようになるためには。
○○が少なくとも過半数の人間に容易に理解出来るようでなくてはならない。
○○が「関数型言語」であっても「オブジェクト指向」であっても同様だね。

712 :デフォルトの名無しさん:2006/11/12(日) 16:27:43
> 過半数の人間
> 過半数の人間
> 過半数の人間
> 過半数の人間
> 過半数の人間
> 過半数の人間
> 過半数の人間

713 :デフォルトの名無しさん:2006/11/12(日) 16:33:35
>>711
「理解」って、それが便利だと認めるってことだよね??

714 :デフォルトの名無しさん:2006/11/12(日) 19:52:34
>>713
俺って彼女にそう理解されているんだろうか・・・

715 :デフォルトの名無しさん:2006/11/12(日) 23:47:52
ワロタ

716 :デフォルトの名無しさん:2006/11/13(月) 18:12:28
>711
プログラマは全て人間である。
しかし人間は全てプログラマではない。

717 :デフォルトの名無しさん:2006/11/13(月) 18:13:10
日本語はバグの出やすい言語でつね

718 :デフォルトの名無しさん:2006/11/13(月) 22:31:14
日本語を使う奴にバグが多いんだよ

719 :デフォルトの名無しさん:2006/11/14(火) 08:59:37
ハングルの時代がそろそろやってきますよ

720 :デフォルトの名無しさん:2006/11/14(火) 15:49:52
>719
ハングルは文字であって言語ではないぞ

721 :デフォルトの名無しさん:2006/11/14(火) 15:57:31
韓流ブーム再来ですね

722 :デフォルトの名無しさん:2006/11/17(金) 17:08:31
自プロセス内の他スレッドへの切り替えを抑制する機構が言語記述レベル
で欲しいなあ。(他プロセスへOSがタスクスイッチするのは構わない)


723 :デフォルトの名無しさん:2006/11/17(金) 22:48:26
>>722
そういう言語は既に在る

724 :デフォルトの名無しさん:2006/11/18(土) 16:38:35
それでバグが出にくくなるのか?逆にバグのるつぼになりそうだが。

725 :デフォルトの名無しさん:2006/11/18(土) 19:58:56
「何故そうするのか」を記述しなきゃならない言語

726 :デフォルトの名無しさん:2006/11/18(土) 21:08:29
>725
それを書けない人間が居るんだよなぁ…

727 :デフォルトの名無しさん:2006/11/19(日) 18:22:43
バグバグ

728 :デフォルトの名無しさん:2006/11/19(日) 18:44:34
>>723
教えて

729 :デフォルトの名無しさん:2006/11/23(木) 03:29:30
誰か、>>692をJSRに提案しろよ。

730 :デフォルトの名無しさん:2006/11/25(土) 01:39:00
JSRって?

731 :デフォルトの名無しさん:2006/11/25(土) 02:25:29
Java Specification Request
http://jcp.org/en/jsr/all

732 :デフォルトの名無しさん:2006/11/25(土) 11:47:53
(1)バクの出にくい言語処理系がバグだらけ

(2)バクの出にくいバグだらけの言語

(3)バクの出にくい言語処理系をバクの出にくい言語で書き直す
↓(バグが混入)
(4)(1)に戻る

733 :デフォルトの名無しさん:2006/11/25(土) 12:28:13
↑凡才現る

734 :デフォルトの名無しさん:2006/11/25(土) 20:49:15
JAVAは使ってないからよく分からん

735 :23歳高卒ニート:2006/11/26(日) 01:45:46
【ブログ】プログラマーを目指して日本を縦断
1 名前:23歳高卒ニート 2006/11/26(日) 00:58:53
http://d.hatena.ne.jp/nonomachon2nd/
23歳高卒ニート童貞がプログラマーになりたい一心で旅をします。
現在、神奈川を移動中。
もし見かけたら、
雇ってください、本をください、技術を教えてください、飯をおごってください。

736 :デフォルトの名無しさん:2006/12/14(木) 23:13:44
>>684
言語仕様は変わると思うけど。今は 型名[@annotation] とかできんでしょ。

737 :デフォルトの名無しさん:2006/12/15(金) 19:14:32
JSR308ってのは、
型アノテーションを型システムに取り込むところまでやるのか?
そうでないと、>>324-329,334 並の機能は無理だろ。

738 :デフォルトの名無しさん:2006/12/20(水) 01:02:21
>324のNonNullって、つまりnullは絶対ダメっていうannotation?
実用性がちょっと想像できない。。。
絶対にnullを許せないっつー場面って、そんなにあるかなあ?

739 :デフォルトの名無しさん:2006/12/22(金) 18:31:06
>>738
おまえは、すべてのメソッド呼び出しで必ずnullチェックをしてるのか?
そうでなければ、そのすべてが「絶対にnullを許せないっつー場面」だろうが。

740 :デフォルトの名無しさん:2006/12/22(金) 18:57:02
すべての関数の実行に役員の3分の2以上の承認を得なければならない。

741 :デフォルトの名無しさん:2006/12/22(金) 20:31:29
認証を行う関数の実行はどうするんだ?

742 :デフォルトの名無しさん:2006/12/22(金) 22:55:33
再帰

743 :デフォルトの名無しさん:2006/12/23(土) 00:43:06
>739
うーん、分かる気もするし、分からない気もするなあ。

そもそも、コンパイル時にnull可否がチェックできるようなアイデアなら
既になんかの言語に実装されててもよさそうなんだけど
そんな機能を搭載してる言語って、無いよね?
(有るんだっけ?有ったら恥ずかしいなあ。。。)

C丼のnullableも、なんかニュアンス違うっぽいし。
このスレで発明されたアイデアなの?
それとも、実装できない理由があるっつー可能性とかは?

744 :デフォルトの名無しさん:2006/12/23(土) 01:20:46
つ SQL
あとHaskellとかはデフォルトでnull不可だろ。
基本的に型パラメタだから型パラメタがない言語では難しいだろう。
null禁止自体については前スレにあったはず。

というか、>>324-334は、null禁止は一番単純な応用にすぎなくて、
そういうのやもっと高度なのを作れる強力な型パラメタ機能が主題なんだが。

745 :デフォルトの名無しさん:2006/12/23(土) 02:44:01
SQLは使われ方からして、コンパイルで検出できても、
プログラム的には実行時エラーにしかならんだろう。

746 :デフォルトの名無しさん:2006/12/23(土) 08:56:06
っていうか、オブジェクトは常にNullになる可能性があるからだろ・・・

747 :デフォルトの名無しさん:2006/12/23(土) 11:27:13
ぬるぽ対策(っつーか型パラメタ)って前スレの423から考えられてんのな。
もう1年以上だ。
そろそろなんか実際に触ってみたいな。
Haskellやってみようか・・・

748 :デフォルトの名無しさん:2006/12/23(土) 12:43:11
Haskellはnull不可はnull不可だが、それ以前に参照型自体が不可だろ。
まあMayBeをnull可能としてそれ以外をnull不可と言うことはできるかもしれんが。

749 :デフォルトの名無しさん:2006/12/23(土) 15:02:30
>747
正確には、前スレの407からな。
既にCurlにはその機能が備わってるらしい。
Curlは最近、個人用のライセンスがゆるくなったはずだから
遊んでみるかな。

750 :デフォルトの名無しさん:2006/12/23(土) 20:18:16
宣伝乙。心配しなくても誰もcurlなんてマイナー言語使わないよ。

751 :デフォルトの名無しさん:2006/12/24(日) 01:34:50
>>750
日本語でおk

752 :デフォルトの名無しさん:2006/12/26(火) 12:35:54
ヌル不可型を作ると、コンパイル時にヌル不可型の循環参照のチェックが必要になるんだよな?

753 :デフォルトの名無しさん:2006/12/27(水) 00:30:21
ヌル不可型の循環参照ってどんなだ?

null不可型は、
・null直接代入禁止
 Object@NonNull obj = null;×
・null不可でない型からの代入禁止
 Object maybeNull = someMethod();
 Object@NonNull obj = maybeNull;×
というだけの話だと思うが。


それより、>>336みたいにEnumやGenerics機構とかを自由に作れる
っつー話の方がそそられるな。

754 :デフォルトの名無しさん:2006/12/27(水) 00:52:45
よくわからんけど、型Aが型Aのメンバフィールドを含んでるときに、
型Aがヌル許容型ならどこかでnullにして初期化を止められるけど、
ヌル非許容型なら延々と型Aのインスタンスを初期化し続けなければならないから、
コンパイラはフィールドの定義を辿っていってヌル非許容型の循環を検知したら
エラーを吐かなければならない、ということじゃなかろうか。

755 :デフォルトの名無しさん:2006/12/27(水) 00:56:02
お前らまだやってんの?
いい加減バカばっか

756 :デフォルトの名無しさん:2006/12/27(水) 01:10:53
型の話してたのか?
「代入時に実体参照しているものしか参照を代入できない」みたいな制限の話してるのかとおもた

757 :デフォルトの名無しさん:2006/12/27(水) 01:20:43
>>754
@NonNullは型定義
例class A@NonNull {}
ではなく型適用(その型の変数やその型を使う関数)
例 A@NonNull var; A@NonNull func();
に現れるのでは?

っていうか、NonNull関係なく
class A {
 A membr;
}
みたいな型って、null以外にどういう値があり得るんだ?

>>755=>>348-353

758 :デフォルトの名無しさん:2006/12/27(水) 01:26:01
メンバひとつだと意味はないが、
ほかにメンバがあれば普通にリスト。つーかconsセル。

759 :デフォルトの名無しさん:2006/12/27(水) 01:32:17
>>1
>javaはC/C++からポインタをなくしたりGCを導入することで
>メモリ管理にまつわるバグを出にくくした

メモリ管理を意識しなくていいアプリ分野ならありがたいが
メモリ管理をやる必要がある組み込みではいい迷惑でしかなかったり。

760 :デフォルトの名無しさん:2006/12/27(水) 01:55:14
>>757
class A {
 A@NonNull membr = init(); // <- コンパイルエラー
}

ってことじゃないか

761 :デフォルトの名無しさん:2006/12/27(水) 03:02:49
class A {
 A@NonNull membr = init(); // <- コンパイルエラー
 A@NonNull init(){return this;}
}
じゃだめなの?


762 :デフォルトの名無しさん:2006/12/27(水) 13:56:00
>759
Javaを使わなきゃいいじゃん

763 :デフォルトの名無しさん:2006/12/27(水) 15:43:14
>>759
そもそも、メモリを意識しなくちゃいけないのは、代入型言語ゆえの宿命だよ。

764 :デフォルトの名無しさん:2006/12/28(木) 18:13:54
>>763
じゃ、どうすれば良い訳?

765 :デフォルトの名無しさん:2006/12/28(木) 18:19:16
そこで関数型言語 Haskellマンセー!!!!!

766 :デフォルトの名無しさん:2007/01/01(月) 22:23:28
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 じゃん

767 :デフォルトの名無しさん:2007/01/02(火) 01:31:43
>>766
A something = isTrue() ? new A(foo) : new A(bar);

条件演算子の山になるな

768 :デフォルトの名無しさん:2007/01/02(火) 01:42:29
A something = function() : A{
 if (isTrue()) { // 場合によって、生成方法が異なる
  return new A(foo);
 } else {
  return new A(bar);
 }
}();

769 :デフォルトの名無しさん:2007/01/02(火) 01:43:37
A@NonNull something = function() : A@NonNull {
 if (isTrue()) { // 場合によって、生成方法が異なる
  return new A(foo);
 } else {
  return new A(bar);
 }
}();

いや、こうか。

770 :デフォルトの名無しさん:2007/01/02(火) 01:51:41
>>766
例外含めてすべての経路でヌル以外が代入されてるなら@NonNullへのキャストを許せばいいんじゃね

771 :デフォルトの名無しさん:2007/01/02(火) 16:22:19
うん。キャストみたいなもんで事足りる。
>749でも書いてるけど、実際にCurlではヌル可/ヌル不可の機構が搭載されてるから
この機構 (ていうか、型annot.全般) が実用たり得るかどうか心配な人は
Curlを触ってみるといいよ。

|| letは宣言を行う。
{let something1: A = {A}}  || something1はヌル不可の変数。明示的にインスタンスを生成しないとコンパイルエラー。
{let something2: #A} || something2はヌル可の変数。nullで初期化される。

|| setは代入を行う。でもこれはコンパイルエラー。
{set something1 = something2}

|| これはおk。キャストみたいなもんだよね。
|| もしsomething2がnullならば、この場でNullReferenceExceptionが発生してくれる。
|| 後でsomething1を使おうとした時に例外が出るよりは、かなりデバッグしやすい。
{set something1 = {non-null something2}}

|| ちなみに、こんな構文糖も用意されてる。
{if-non-null something2 then
  || これは {if something2 != null then 〜 } と同じ。
}

772 :デフォルトの名無しさん:2007/01/10(水) 06:28:03
バグが出にくいとは関係ないけど、

C++の
include
include
include
include
:

D言語の
import
import
import
import
import
:

とかみててすげー腹立つんだけど、俺だけ?
なんで、近代言語なのに、
uses hoge, mage moge;
みたいにしないんだ?

773 :デフォルトの名無しさん:2007/01/10(水) 10:05:52
たしかDのimportは列挙できるけどな
C/C++の癖が抜けてないんだろう

774 :デフォルトの名無しさん:2007/01/10(水) 14:22:01
個人的には、uses で横に並べるより include で縦に並べたほうが見やすい。
もうね、横スクロールバー出るくらいまで長く伸びたり、無駄に改行するんだったら最初から縦に並べろよ、って。

775 :デフォルトの名無しさん:2007/01/10(水) 14:44:09
なぜ横スクロールは嫌われるのか

776 :デフォルトの名無しさん:2007/01/10(水) 17:23:22
縦に比べて妙にスクロール速度が遅い環境が多いからじゃないか?

777 :デフォルトの名無しさん:2007/01/10(水) 22:32:17
>>774
横スクロールバーでるまで、長くのばさねーよ、普通w
縦に並べるのは、無駄に改行じゃないのかよwww
あおるなら、もう少し、頭つかえ

778 :デフォルトの名無しさん:2007/01/10(水) 22:38:56
>775
マウスのホイールは大抵縦向きにしか使えないから。
ちなみにWindowsでは垂直方向のスクロールバーが無ければ、ホイールの回転を水平方向のスクロールに使える。

779 :デフォルトの名無しさん:2007/01/10(水) 22:40:07
行指向のエディタを使う限り下に伸びた方が楽
列指向なら横だな

10個のsymbolを横に書いておくのと縦に書いておくのでは、行指向エディタでは雲泥の差がある

780 :デフォルトの名無しさん:2007/01/10(水) 22:46:51
DRY原則の面からいくと、
include
include
include
なんかは、もう目もあてらんねえ

781 :デフォルトの名無しさん:2007/01/10(水) 23:13:12
>>777
uses HogeHoge01, HogeHoge02, HogeHoge03, HogeHoge04,
        HogeHoge05, HogeHoge06, HogeHoge07, HogeHoge08;

こういうのが嫌い。

782 :デフォルトの名無しさん:2007/01/10(水) 23:45:30
>>780
”いつからインクルードファイルを省略できるようになった?”

783 :デフォルトの名無しさん:2007/01/11(木) 03:32:11
>>781
俺は、

#include "HogeHoge01"
#include "HogeHoge02"
#include "HogeHoge03"
#include "HogeHoge04"
#include "HogeHoge05"
#include "HogeHoge06"
#include "HogeHoge07"
#include "HogeHoge08"

こういうのが嫌い
いちいちスクロールするのが面倒だし、
第一なんで、#includeをいくつもかかなくちゃならんのだ?

784 :デフォルトの名無しさん:2007/01/11(木) 03:34:36
>>783
uses {
    HogeHoge01;
    HogeHoge02;
    HogeHoge03;
    HogeHoge04;
    HogeHoge05;
    HogeHoge06;
    HogeHoge07;
    HogeHoge08;
}

これなら俺は許せる

785 :デフォルトの名無しさん:2007/01/11(木) 03:37:40
縦長にする意味がわかんない。
も前は、配列リテラルも、縦長で書くんか?

a = [
"hoge",
"mage",
"moge",
"sage"]

と思ったけど、enumとかは、縦長で書くこともあることに気づいた・・・。
ケースバイケースか・・・

786 :デフォルトの名無しさん:2007/01/11(木) 03:37:44
all.hを作っておいてそこに
#include "HogeHoge01"
#include "HogeHoge02"
#include "HogeHoge03"
#include "HogeHoge04"
#include "HogeHoge05"
#include "HogeHoge06"
#include "HogeHoge07"
#include "HogeHoge08"

んでメインの方では
#include "all.h"

これ基本アルネ


787 :デフォルトの名無しさん:2007/01/11(木) 03:40:13
以下C言語におけるincludeプリプロセス文に関するバグの出にくい言語使用が考え続けられます






















(;^ω^)

788 :デフォルトの名無しさん:2007/01/14(日) 16:58:30
バグも仕様ですと言い張る

789 :デフォルトの名無しさん:2007/01/19(金) 17:01:00
>>785
なんかluaのデータ定義っぽい

790 :デフォルトの名無しさん:2007/01/20(土) 00:55:39
最近どこかのスレで

class A{
    private int
        countor,
        index;
    private String
        ...
}
見たいに掻いたコード見たんだが
行数増えすぎだろ、これ・・・

791 :デフォルトの名無しさん:2007/01/22(月) 21:39:36
>>786
Visual C++だとstdafx.hが正にその役。

792 :デフォルトの名無しさん:2007/01/23(火) 09:44:48
>>772
みんな折りたたみ機能持った近代のIDEとかエディタ使ってるから、
そんなに腹立たないんだよ。

793 :デフォルトの名無しさん:2007/01/23(火) 12:09:45
>>792
最近のfolding機能は、includeまで面倒見てくるんですかそーですか

794 :デフォルトの名無しさん:2007/01/23(火) 15:53:23
少なくともimportは面倒見てくれるけどな
includeは知らん

795 :デフォルトの名無しさん:2007/01/26(金) 04:31:24
というか自動的に必要なのを集めるよーなのが言語機能に無いのが悪い

796 :デフォルトの名無しさん:2007/01/26(金) 08:45:47
>>795
そんなのバグの元だ。

797 :デフォルトの名無しさん:2007/01/26(金) 15:28:03
作らないのが一番いい、氏ね

798 :デフォルトの名無しさん:2007/02/10(土) 23:17:27
>797
C++厨乙

201 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)