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

1 ：デフォルトの名無しさん：2005/03/25(金) 19:53:00

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

2 ：デフォルトの名無しさん：2005/03/25(金) 19:59:12

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

3 ：デフォルトの名無しさん：2005/03/25(金) 20:02:13

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

4 ：デフォルトの名無しさん：2005/03/25(金) 20:39:19

俺はこんなバグを出したという情報募集。
それを回避できる言語仕様を考えていこう。

5 ：デフォルトの名無しさん：2005/03/25(金) 20:53:07

文字を組み合わせて意味を成すからいけない
コンピュータでなぜ文字→単語→文という粒度が必要になるのか？

6 ：デフォルトの名無しさん：2005/03/25(金) 21:10:33

>>1

もうプログラミング言語は進化し終わった
あとは手法の問題

7 ：デフォルトの名無しさん：2005/03/25(金) 21:29:44

バグの出にくい言語仕様を考えるより、バグの影響を最低限に抑える環境を考えた方が建設的な気がする。

8 ：デフォルトの名無しさん：2005/03/25(金) 21:46:17

>>2はMDAのことを言っているようにとれなくもない。

9 ：デフォルトの名無しさん：2005/03/25(金) 23:29:39

UIのバグはどうにかならんものか

10 ：デフォルトの名無しさん：2005/03/26(土) 07:12:26

誰かが作ったものを買う。

11 ：デフォルトの名無しさん：2005/03/26(土) 11:27:23

Javaに残っている「バグが出やすいところ」を解析するのが
一番の近道かと

12 ：デフォルトの名無しさん：2005/03/26(土) 11:32:33

言語仕様だけでバグの出にくさとか狙っても防げるのは瑣末なミスばかりで
testabilityが落ちるために却ってトータルの生産性は落ちる罠。

13 ：デフォルトの名無しさん：2005/03/26(土) 13:19:19

>>6
おとといは馬をみたの。きのうは鹿、きょうはあなた。

14 ：デフォルトの名無しさん：2005/03/26(土) 13:20:39

言語の進化ってなんだろう…

15 ：デフォルトの名無しさん：2005/03/26(土) 14:26:14

というか、作り方を簡単にするのではなく、作り手を教育した方がいいと思う。
駄目な奴は何を使っても失敗する。

16 ：デフォルトの名無しさん：2005/03/26(土) 14:29:14

>>15
はい？？？

17 ：デフォルトの名無しさん：2005/03/26(土) 14:40:12

作り方を簡単にする、ねぇ・・・（ﾆｶﾞﾜﾗ

18 ：デフォルトの名無しさん：2005/03/26(土) 14:46:20

JAVAやVBよりもバグになる要素が多い、Cやアセンブラだって、まともな奴が作ればバグは出ない
Cやアセンブラよりもバグになる要素が少ない、JAVAやVBだって、アホが作ればバグは出る

バグが出にくくすると言うことは、できることも少なくなると言うことで
制限のあるような言語を完璧に作っても意味ないと思うよ

俺も、教育を何とかした方がいいと思う
高度なことをやるためには、やはりCやアセンブラのような、
ハードを気にする言語が必要だって

コンピュータのことが解らないプログラマを大量生産しても、先細りになるだけ

Cやアセンブラレベルの事ができて、バグが出づらい言語をと言うのなら理解できるが、
JAVAの焼き直しとか、そう言うのはあまり意味がない

19 ：1：2005/03/26(土) 17:30:05

私としては実用性がどうこうという議論はひとまず置いといて
学術的な興味としてどのような言語がバグが出にくいか考えたい。
そのためにはかなり強い制限をかけてもよいと思う。
実行性能も気にするな。
意味は後からついて来る！

20 ：デフォルトの名無しさん：2005/03/26(土) 18:05:42

文系でもできるもん！
VBOracleASP

21 ：デフォルトの名無しさん：2005/03/26(土) 18:22:38

まずは「バグ」の定義からだな。
よろしく>>1

22 ：デフォルトの名無しさん：2005/03/26(土) 18:23:18

>>20
文系ってダメ人間の集まりでしょ？

23 ：1：2005/03/26(土) 18:23:38

>>12
テストのし易さは重要なファクターだと思う。
それも言語仕様に含められないだろうか。

24 ：デフォルトの名無しさん：2005/03/26(土) 18:25:44

そもそも関数型言語ではコンパイルさえ通れば論理的なバグは発生しない訳だが…
発生するとすればコンパイラにバグがあるってことになる。
Cなどでは論理的なバグに悩まされることも結構あるんだよね。

25 ：デフォルトの名無しさん：2005/03/26(土) 18:26:37

それでいて、どうして生産性が高いと言われ続けているのか結構疑問かもかも。

26 ：デフォルトの名無しさん：2005/03/26(土) 18:28:42

>どうして生産性が高いと言われ続けているのか

馬鹿には使えないようになってるから

27 ：デフォルトの名無しさん：2005/03/26(土) 18:31:28

C系のプログラム言語はリソースが豊富だしな
言語仕様そのものが生産性を上げるわけではないと思う

28 ：デフォルトの名無しさん：2005/03/26(土) 19:15:59

バグの出にくい言語仕様なんてもんは無いと思う。
バグが埋もれにくい（＝発見しやすい）言語仕様はあるだろうが。

29 ：デフォルトの名無しさん：2005/03/26(土) 19:17:00

Design By Contractとかだね

30 ：デフォルトの名無しさん：2005/03/26(土) 19:21:33

>>29
いや、俺が考えてたのはそういう事じゃない。それは、結局検出する機構を用意しているに過ぎない。

31 ：デフォルトの名無しさん：2005/03/26(土) 19:25:50

> バグが埋もれにくい（＝発見しやすい）
> 検出する機構を用意している
おなじじゃんｗ

32 ：デフォルトの名無しさん：2005/03/26(土) 20:01:28

>>31
日本語バグﾊｹﾝ

33 ：デフォルトの名無しさん：2005/03/26(土) 20:05:55

人間は多少のバグは脳内訂正できるから問題なし。

34 ：デフォルトの名無しさん：2005/03/26(土) 21:42:34

>>31
おなじじゃない

35 ：デフォルトの名無しさん：2005/03/27(日) 02:24:43

どっかで誰かが言ってたが、
プログラムを作るのにも資格が必要なんじゃないかと。
たとえば命にかかわるプログラムの場合
なんちゃら資格が必要だとか。

36 ：デフォルトの名無しさん：2005/03/27(日) 03:58:54

typedef で型名を定義した場合、再定義ではなくまったく
新しい型として扱われる。たとえば、 size_t と int では別の型となる。

enum 型で列挙された値以外の定数を enum変数に代入するとコンパイル
エラーになる。

37 ：デフォルトの名無しさん：2005/03/27(日) 12:29:46

そんなのいまどき当たり前

38 ：デフォルトの名無しさん：2005/03/27(日) 12:31:18

>>36
だからなに？

39 ：デフォルトの名無しさん：2005/03/27(日) 12:43:36

たとえばさ、

BaseClass class {
省略
void Method1(void);
省略
};

DerivedClass class {
省略
void Method1(void);
省略
};

なんていう記述があったときに、言語仕様としてMethod1の呼び出しで
明示的にクラス指定をしなければならないとするか、
実装者に任せてコンパイラの警告に任せるとするかってするのは
全然違うよな。言語仕様として曖昧性を許さないというのは重要なことだと思うよ。

ほかにも多重継承を言語の仕様からはずしてしまうなんていうのも
言語仕様としてバグが出にくくしているといえると思う。

>>1はそういうこと言ってるんじゃないの？

40 ：デフォルトの名無しさん：2005/03/27(日) 13:43:34

で、具体的なネタも振らずに逃げたわけだが。

41 ：デフォルトの名無しさん：2005/03/27(日) 16:14:38

>>39 Wow 継承を指定するのを忘れてる（笑

42 ：デフォルトの名無しさん：2005/03/27(日) 16:43:25

CPUからX87FPUをとっぱらって
有理数をサポートするX88RPUを開発してくっつける

43 ：デフォルトの名無しさん：2005/03/27(日) 17:51:37

それは、バグの発生と関係あるのか ?

まさか、誤差とバグを混同してるなんてことないよな。

44 ：デフォルトの名無しさん：2005/03/27(日) 18:19:19

まぁまぁ、おまいら。とりあえず要求定義しようではないか。

45 ：デフォルトの名無しさん：2005/03/27(日) 18:20:37

型推論入れろー！

46 ：デフォルトの名無しさん：2005/03/27(日) 18:22:35

Javaで十分バグが出にくいと思うんだけど・・・
そもそもバグって最適化にミスった時にしか起きないよね？
普通に組めばまず起きない

47 ：デフォルトの名無しさん：2005/03/27(日) 19:01:21

>>45 型推論って余計にバグの温床になりそうな気がする。

48 ：デフォルトの名無しさん：2005/03/27(日) 19:03:03

>>47
例えば、どんな時？
型推論だとテンプレートも要らないし、論理的なバグが激減すると思うんだけど…

49 ：♥：2005/03/27(日) 19:52:14

　分析結果⇔外部設計⇔詳細設計⇔実装

を統合できる開発環境があればいいのではないかな。

１．前工程の成果物を作成した時点ですでに次工程の成果物がある程度できてる。
２．後工程の成果物に変更を加えれば前工程の成果物にも自動で変更が加えられる。

メリットは
１．下位工程への落としこみ、上位工程の修正時の人的ミスの減少
２．各工程のドキュメントが同時に変更されるので、検証が容易。

でも言語仕様とはちがうかな。。

50 ：デフォルトの名無しさん：2005/03/27(日) 20:18:50

不完全性定理によると
「その論理の無矛盾性はその論理が無矛盾である限り証明できない」。
よって完全な言語仕様を定義することさえできないのだっ！のだっ！のだっ！
反論は受け付けません。

51 ：デフォルトの名無しさん：2005/03/27(日) 20:30:24

数学の無矛盾性の証明不能を数学的に証明したわけね

52 ：デフォルトの名無しさん：2005/03/27(日) 20:32:59

ああ、相対性理論の話ね。あるあるｗ

53 ：デフォルトの名無しさん：2005/03/27(日) 20:40:06

>>50
それの証明はされているけど、論文には載せられないよね。量が多すぎて。

54 ：デフォルトの名無しさん：2005/03/27(日) 20:56:18

>>52 おいおい、ゲーデルのだろ。

55 ：デフォルトの名無しさん：2005/03/27(日) 23:52:09

ロジックの複雑さを常に一定に保てる仕様とか

56 ：デフォルトの名無しさん：2005/03/28(月) 00:08:33

関数型言語で解決？

57 ：デフォルトの名無しさん：2005/03/28(月) 00:19:21

>>56 関数言語のことを言っている？

58 ：デフォルトの名無しさん：2005/03/28(月) 00:25:31

誤差がもしないとしたら
そもそも誤差によって起こる矛盾を回避する為の
例外的コードを書く必要がなくなり
結果その部分で虫を含む可能性はなくなる
虫というのは自然発生する訳でもなし
その原因をみないで何がわかるか？
虫を排するもっとも優れた方法は
そもそもプログラムを書かないこと
これもひとつの真理だろ

59 ：デフォルトの名無しさん：2005/03/28(月) 09:18:18

>>58
つまらん事言ってるから、お前は今後は無視

60 ：デフォルトの名無しさん：2005/03/28(月) 09:22:44

>>50
その公理系の内側からは証明できないって話じゃなかったか？

61 ：デフォルトの名無しさん：2005/03/28(月) 09:23:37

最近は大概の機能がコンポーネントとして抜き出されてる
>>58を好意的に受け止めるとそういう理屈でバグを回避してることになる

62 ：デフォルトの名無しさん：2005/03/28(月) 09:35:06

てことは「バグの出にくい言語」＝「コンポーネントの多い言語」か

63 ：デフォルトの名無しさん：2005/03/28(月) 09:58:35

「バグの出にくい」じゃなくて、「バグの入りにくい」だろ!

64 ：デフォルトの名無しさん：2005/03/28(月) 10:14:10

より多くの規格品をかき集めることが大切なんだろうね。
gotoとかも定型化された使い方なら安全・綺麗・効果的となる。
細かいパズルより大きなパズルの方がバグが出ないのは当然のこと。

65 ：デフォルトの名無しさん：2005/03/28(月) 12:32:53

んで、客先でレビューして、あんな事もできない、こんな事もできないと叩かれるわけだ（鬱

66 ：デフォルトの名無しさん：2005/03/28(月) 12:46:54

>>1
Javaにポインタはある。
それを意識しなくてもいいというだけだ。
仕様書を見てみろ

67 ：デフォルトの名無しさん：2005/03/28(月) 12:53:11

　　　　　　　　　　＿
　　　　　　　　 '´　　　ヽ
　　　　　　　　!　j ﾘﾉ）)））　ﾍﾍｪ♪
　　　　　＿　l　ll*ﾟヮﾟﾉ∫＿
〔ﾉ二二,＿＿_　ﾘ　　　ﾘ＿＿,二二ヽ〕
　|:::::::::::::::::::::::::::ヽ　゜　゜/::::::::::::::::::::::::::/
　　〉:::::::::　:::::::::::::〉　・　〈::::::::::::::　::::::::〈　　　　ﾊﾞｯ
　|:::::::::::::::::::::::::／　■　ヽ::::::::::::::::::::::/
　〔:::::::::::::::::::::/　　ノ~ヽ　　ヽ::::::::::::::::::|
　ヽ:::::::::::::::::/　／::::::::::::＼　):::::::::::::::::::ゝ
　ﾉ:::::::::::::::::::|　|_～─～-|　|～～～/

68 ：デフォルトの名無しさん：2005/03/28(月) 14:35:20

>>66 そりゃVMレベルの、つーか、バイトコードレベルの話じゃね？

69 ：デフォルトの名無しさん：2005/03/28(月) 16:09:39

プリミティブ型以外は事実上ポインタじゃねーの？

70 ：デフォルトの名無しさん：2005/03/28(月) 16:10:38

>>69
　　　　　　　　　　＿
　　　　　　　　 '´　　　ヽ
　　　　　　　　!　j ﾘﾉ）)））　ﾍﾍｪ♪
　　　　　＿　l　ll*ﾟヮﾟﾉ∫＿
〔ﾉ二二,＿＿_　ﾘ　　　ﾘ＿＿,二二ヽ〕
　|:::::::::::::::::::::::::::ヽ　゜　゜/::::::::::::::::::::::::::/
　　〉:::::::::　:::::::::::::〉　・　〈::::::::::::::　::::::::〈　　　　ﾊﾞｯ
　|:::::::::::::::::::::::::／　■　ヽ::::::::::::::::::::::/
　〔:::::::::::::::::::::/　　ノ~ヽ　　ヽ::::::::::::::::::|
　ヽ:::::::::::::::::/　／::::::::::::＼　):::::::::::::::::::ゝ
　ﾉ:::::::::::::::::::|　|_～─～-|　|～～～/

71 ：デフォルトの名無しさん：2005/03/28(月) 16:55:15

>>69 まぁそうなんだがちゃんとリファレンスカウントされてる
って点が違うとおもわれ。

72 ：デフォルトの名無しさん：2005/03/28(月) 18:33:16

GCマンセーってことだな

73 ：デフォルトの名無しさん：2005/03/28(月) 19:04:16

バグのないプログラムはないが、デバッグできないバグはない。

と言うわけで日本語で充分じゃん。

74 ：デフォルトの名無しさん：2005/03/28(月) 20:00:40

誰も表明ベースについて言ってないけどあれが良いと思う。
型をさらに限定した感じ。

75 ：デフォルトの名無しさん：2005/03/28(月) 20:44:58

配列てバグの温床じゃね？
配列のない言語ってできないもんかね。

76 ：デフォルトの名無しさん：2005/03/28(月) 20:57:00

>>75
配列はリストの特殊形。そしてリストはデータ構造の唯一の基本形。
無理ですね

77 ：デフォルトの名無しさん：2005/03/28(月) 21:00:56

>75
Pure Lispなんてどう？

78 ：デフォルトの名無しさん：2005/03/28(月) 21:42:17

for文を無くしてforeachだけでプログラム組めないもんだろか。
とかいってみるテスト。

79 ：デフォルトの名無しさん：2005/03/28(月) 22:34:46

アフォ発見
といってみるテスト。

80 ：デフォルトの名無しさん：2005/03/28(月) 23:54:01

>>74
表明ベースってナニー？
ぐぐっても出てこないよぅ。

81 ：デフォルトの名無しさん：2005/03/29(火) 00:30:50

Prolog

82 ：デフォルトの名無しさん：2005/03/29(火) 01:00:31

>>80
表明契約でぐぐれ

83 ：デフォルトの名無しさん：2005/03/29(火) 02:45:10

http://www.google.co.jp/search?q=%22%E8%A1%A8%E6%98%8E%E5%A5%91%E7%B4%84%22&num=30&hl=ja&lr=lang_ja&newwindow=1&c2coff=1&filter=0

D言語ぐらいしかないじゃん

84 ：デフォルトの名無しさん：2005/03/29(火) 03:03:23

パクリ元はEiffelだが

85 ：デフォルトの名無しさん：2005/03/29(火) 21:17:43

今日もバグを出してしまった。
はやくバグの出ない言語を作ってくれ。

86 ：デフォルトの名無しさん：2005/03/29(火) 22:43:53

仕様が変わったときに影響範囲を自動で検出できるといいんだけど。

87 ：デフォルトの名無しさん：2005/03/29(火) 23:14:40

仕様変更ってのは機能追加の場合も多いだろ。今までにない機能を追加するのに、それの影響範囲を自動で検出するなんて理論的に無理。あらかじめ想定内(豚社長っぽいいいまわしだﾜﾗ)の仕様変更なら可能かもしれんが。

88 ：デフォルトの名無しさん：2005/03/29(火) 23:19:35

そもそもコード書かなければいいんじゃないかな
ＧＵＩでボタンを置いていくかのように必要な機能を組み合わせるだけ
って出てるね。でもそれくらいしか・・・

89 ：デフォルトの名無しさん：2005/03/29(火) 23:47:05

ソースコードの有無の問題じゃねーだろ。そもそもがソフトウェアは何を持ってバグとするかが微
妙だから「仕様です」なんて他では考えられないセリフが生まれた。仕様は、必ずしも論理的なも
とは限らないことに注意を払うべき。バグを作りこまないスーパー言語は、カオスを含むビジネス
ロジックなどはコンパイルエラーが出て実装できませんなんて冗談ができあがりそうだ。

90 ：デフォルトの名無しさん：2005/03/30(水) 00:44:22

>>87
仕様変更の情報を何らかの形で与えてやれば
まったくの無理でもないような気がするけど。
まあ非常に難しいのは認めるが。

91 ：デフォルトの名無しさん：2005/03/30(水) 01:02:54

仕様のバグはどうすればいいですか？

92 ：デフォルトの名無しさん：2005/03/30(水) 01:25:50

「ＧＵＩでボタンを置いていくかのように必要な機能を組み合わせるだけ」でも
バグ出す香具師はゴマンといる・・・

93 ：デフォルトの名無しさん：2005/03/30(水) 01:56:46

ナマスモノニリック理論を使えばいいんじゃない？

94 ：デフォルトの名無しさん：2005/03/30(水) 14:18:15

一方、ソ連は鉛筆を使った。

95 ：デフォルトの名無しさん：2005/03/30(水) 15:46:51

想定できるバグ(*1)を起こしうる記述を徹底的に制限して、
その類は全部コンパイルエラーにさせる。
アルゴリズムや記述方法(インデントの有無など)も
バグの引き金になるようなものは一切認めない。

*1 仕様との不一致は無視

ウザそうだ

96 ：デフォルトの名無しさん：2005/03/30(水) 19:36:01

>>95
次第にそれが快感になってくる。

97 ：デフォルトの名無しさん：2005/03/30(水) 19:42:40

よっしゃぁぁぁぁああああ、やっとコンパイル通ったぞぉぉおぉぉぉ！

って感じに喜べそうだ

98 ：デフォルトの名無しさん：2005/03/30(水) 19:56:06

>>95
想定の範囲内というのが、堀江の脳内並みに広大になりそうだ。

99 ：デフォルトの名無しさん：2005/03/30(水) 21:08:05

lintとかってバグをつぶすのに役に立ってるのかね。
あんまり役に立ってないイメージがあるんだが。

100 ：デフォルトの名無しさん：2005/03/30(水) 21:11:40

使いこなせないのと便利じゃないのは同意じゃないわけで

101 ：デフォルトの名無しさん：2005/03/30(水) 21:12:08

Adaなんかが確かバグを出しにくい（≒コーディングメンドクサイ）
あれこれの機能を持っていたような・・・

102 ：デフォルトの名無しさん：2005/03/30(水) 21:13:08

int a;
int len;
len = GetFileSize("～.bmp");

Error(line: 1) - 分かりにくい名前をつけることはできません。
Error(line: 2) - インデントに問題があります。
Error(line: 2) - 変数名と用途があっていません。
　　　　：
　　　　：

103 ：デフォルトの名無しさん：2005/03/31(木) 01:05:48

インデントはともかく、裏を返せばコンパイラの辞書にない変数名は付けられないと。

104 ：デフォルトの名無しさん：2005/03/31(木) 01:07:31

>>103
その辺は動的に。

105 ：デフォルトの名無しさん：2005/03/31(木) 01:28:06

>>99
eclipse のようにリアルタイムで通知してくれればまた別だろうね。

106 ：デフォルトの名無しさん：2005/03/31(木) 16:12:51

全ての変数はボラタイル

107 ：デフォルトの名無しさん：2005/03/31(木) 19:12:33

強い型付け＆型推論

108 ：デフォルトの名無しさん：2005/03/31(木) 19:31:09

１関数８０行超えるとコンパイルエラー

109 ：デフォルトの名無しさん：2005/03/31(木) 20:10:51

ネストが５以上はコンパイルエラー

110 ：デフォルトの名無しさん：2005/03/31(木) 21:02:01

ソースコードにおけるコメントの比率が５～１０％に収まっていないとコンパイルエラー。

111 ：デフォルトの名無しさん：2005/03/31(木) 21:04:23

個人的に#if 0 ～#endifの箇所はいっそのこと削除してほしい
漏れはバリバリ残してるがな

112 ：デフォルトの名無しさん：2005/03/31(木) 21:06:50

>>109
え、なんで～ lispとかネストしまくりやん！！！

113 ：デフォルトの名無しさん：2005/03/31(木) 21:12:08

MISRA-Cとかどうなの？

114 ：デフォルトの名無しさん：2005/03/31(木) 21:18:43

依存関係のある関数どうしで重複ロジックがあるとコンパイルエラー

115 ：デフォルトの名無しさん：2005/03/31(木) 21:22:38

え～　関数の多重定義できないの～　最低

116 ：デフォルトの名無しさん：2005/03/31(木) 21:33:30

インデントをもっと進化させられないだろうか。
ネストが深くなるとちゃんとインデントしてあっても
わけわからんくなる。

117 ：デフォルトの名無しさん：2005/03/31(木) 21:33:40

朝ごはん食べてないとコンパイルエラー

118 ：デフォルトの名無しさん：2005/03/31(木) 21:40:13

スレッドや子プロセスは非サポート

119 ：デフォルトの名無しさん：2005/03/31(木) 22:30:04

ユニットテストが完備していないとコンパイルエラー

120 ：デフォルトの名無しさん：2005/03/31(木) 22:36:04

名前規則に反しているとコンパイルエラー

121 ：デフォルトの名無しさん：2005/03/31(木) 23:06:56

マジックナンバーはコンパイルエラー

122 ：デフォルトの名無しさん：皇紀2665/04/01(金) 00:48:39

ねーねー、2次元構文(レイアウト)を採用することでどんな利点があるの？

123 ：デフォルトの名無しさん：皇紀2665/04/01(金) 01:34:24

2次元構文て何

124 ：デフォルトの名無しさん：皇紀2665/04/01(金) 01:58:16

>>123
ブロックをインデントで表したりする構文。

125 ：デフォルトの名無しさん：皇紀2665/04/01(金) 05:09:28

>>94
かなりﾜﾛﾀｗ

以下知らない人用のコピペ

アメリカのNASAは、宇宙飛行士を最初に宇宙に送り込んだとき、
無重力状態ではボールペンが書けないことを発見した。

これではボールペンを持って行っても役に立たない。

NASAの科学者たちはこの問題に立ち向かうべく、10年の歳月と120億ドルの開発費をかけて研究を重ねた。

その結果ついに、無重力でも上下逆にしても水の中でも氷点下でも摂氏300度でも、
どんな状況下でもどんな表面にでも書けるボールペンを開発した！！

一方ソ連は鉛筆を使った。

126 ：デフォルトの名無しさん：皇紀2665/04/01(金) 07:48:00

error: 平日18:00から9:00までおよび土日はコンパイルサービスを休止しております。

127 ：デフォルトの名無しさん：int 2ch ＝05/04/01(金) 23:00:16

>>125
それってNASAはアホってこと？

128 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 00:17:15

>>85
例えば、ある返り値を持つ関数(関数は必ず返り値を持つものだけど)を定義しても、
プログラムが停止するかどうかを判定できない。
返すべき値があるはずなのに停止しないというのはバグだけど、それがバグかどうか見付ける
プログラムは書けない。
つまり、バグを完全に見つけ出すコンパイラは書けない。
よって、バグのでない言語はない。

129 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 01:49:42

なんかかなり好意的に読まないとわけわかんない文章なんだけど。

130 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 02:07:07

だったら好意を持ってくれ。

131 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 02:17:58

>>129
ところで、どのあたりがわけわかんないの？書き直すから。

132 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 03:03:45

>>131
129ではないが、128だけでは日本語としてかなり足りない部分があると思う。
単に言葉を並べただけで、論理展開を説明する文章になってない。

133 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 03:27:33

>>132
論文風に書けばいいのかい？

134 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 03:38:56

停止って何よ

135 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 03:39:48

それ以前に前提が間違っている。

136 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 03:55:48

>>135
どの前提よ

137 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 04:10:56

>>135
プログラムが停止するかどうかを判定できない、の部分なら証明済みだよ

138 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 09:38:02

＞(関数は必ず返り値を持つものだけど)

139 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 10:53:04

とりあえずバグを消すのには、エディタを作るべきだと思う。

言語に求められているのはただひとつ。
代入記号と同値記号を全く別物にすること。

あと>>125サンクス。

140 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 11:25:30

>>138
必ず持たなければならないよ。voidであっても返り値は持つ。

141 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 11:28:24

>139
Algol, Pascal

142 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 11:50:35

なぜあの言語がでてこない？

143 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 11:52:05

あのってなんだ

144 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 11:52:58

Haskellをモデルにしてさらなる拡張をしようじゃないか。
いまのところHaskellが最先端でしょ？

145 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 11:56:19

>>128
それはメモリを無限に使って良い場合だよね。
メモリの上限が決まっていれば停止性は極めて簡単に判定できる。

146 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 12:01:42

>>145
原理的に可能というだけで、簡単に判定できるとは思えないのだけど。

147 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 12:01:55

>>145
それはメモリの上限を越えたら停止しないってことにするわけ？
それは実行してみないと解からないことだからコンパイラでは実質不可能だよね

148 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 12:21:07

メモリに上限があるときには、理論的には全ての組み合わせを検証できるわけ。
そうすると無限ループとかもわかる。

149 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 12:25:44

>>148
どういう場合のことを言っているのかよくわかんない。
例を出してみてくれる？？

150 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 12:26:19

そして、全ての場合に成り立つの？

151 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 12:26:41

リファレンスぶっ飛んで自分のプログラム領域を破壊していてもわかるの？

152 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 12:29:36

>>151
明示的なポインタを禁止すればそういうこともなくなる。

153 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 13:06:51

メモリ上にプログラムとデータを置いて、
いつでもメモリの状態を記録したり、値を設定できるようなエミュレータを考える。
メモリのサイズは有限とする。
(レジスタやHDDも値を保存するものなのでメモリに含める)

メモリのサイズが有限なので、全ての状態について
次のステップでメモリがどうなるかを調べることができる。
(プログラム領域を壊すことも含まれる)

現実的なサイズのメモリに対して、全てを調べるというのは不可能だと思うけど、
理論的にはできる、という話。

要は有限オートマトンです。

154 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 13:10:14

>>153
それは実際に実行するよりも時間がかかるので…あまり…意味なかったり^^;
まぁ、メモリは無限ってことで考えようよ。

155 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 13:35:04

無限ループから自ら脱出しない関数は想定しなくていいの?
関数から脱出しない(当然返り値もない)のに正しいわけだが。

156 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 13:38:14

>>155
全ての場合ではなく、ある制約上では判定できそうだね

誰か証明して～

157 ：デフォルトの名無しさん：int 2ch ＝05/04/02(土) 14:24:18

>>155
プログラムで使用される全ての変数を監視し、同じ組み合わせが過去に1回以上現れたら
無限ループと判定出来る。何故なら、全ての変数は高々有限通りの値しか取らないから。

整数同士の割り算をしたときに無限小数になるけど、途中で出てくる「余り」が有限の値しか取らないため、
有限時間で無限小数か否かを判別できるのと同じこと。
但し、余程小さなプログラムで無い限り、プログラム内の全ての変数の組み合わせは天文学的な数になるので、
現実的ではない。

それでも、while の終了条件が現れるかどうかを検証したり（3n+1問題のような未解決問題を含む場合は無理）、

for (i=start; i<goal; i--)/* start < goal */

のようなコードに対して警告を出すようにすれば、ある程度バグを抑えることが出来る。

再帰関数の場合も、終了条件が書かれていなければエラーとする方法がある。

余程高度な（巨大という意味ではなくて、数学的に）プログラムでない限り、
停止条件の判別はそれほど難しくないはず。

158 ：デフォルトの名無しさん：int 2ch ＝5,2005/04/02(土) 15:00:43

でも、こんなめんどくさくメモリをモジュール領域と分離して常時監視するようなスタックもなく
とろそうな言語（と言うより環境つーか、Smalltalk?）を作るのは、きっとC++かCなんだよね？

159 ：デフォルトの名無しさん：2005/04/02(土) 22:15:07

>158
理論と実装の違いがわかってないアホ発見！

160 ：デフォルトの名無しさん：2005/04/02(土) 22:18:03

「メモリの管理が完璧に行える＝バグがでない」という認識のもとで議論が進んでるようなの
ですが、そもそもそーゆーもんなんですか？あんまり低次元の言語使ったことないからわか
らんのよ。やっぱメモリうんぬん言ってる人はCやアッセンブラの使い手なのかしら。

161 ：デフォルトの名無しさん：2005/04/02(土) 23:28:18

>>160
理論だからメモリと言ってるのだけど、
本当はレジスタとか補助記憶とかネットワークとかも含まれるわけ。
そんでありとあらゆる状態を把握して、こういうときにはこうなる
ということがわかっていればバグは出ない、という直感的には当たり前な話。
もちろん現実には全ての状態を把握することはできないし、
理論上でもメモリが無限にあったら状態は把握できない。

162 ：デフォルトの名無しさん：2005/04/03(日) 07:42:59

いきなり低レベルな話だが、
m_memberとかmember_とか_memberとかややこしいので言語仕様として命名規約を定めてほしい。

163 ：デフォルトの名無しさん：2005/04/03(日) 10:54:43

>>162
あなたはfortranの悪夢を再現したいのですか?

164 ：デフォルトの名無しさん：2005/04/03(日) 11:53:28

Cが「ﾊﾞｸﾞの出やすい言語仕様」である事を（しぶしぶながら）認める。
#だってCにはそんな設計思想ないもん

165 ：デフォルトの名無しさん：2005/04/03(日) 11:57:23 BE:42530562-##

VBは？？

166 ：デフォルトの名無しさん：2005/04/03(日) 13:02:28

C系の言語(C,C++,Javaなど)やFortranなどしか扱った事がない人は一度StandardMLなどの言語を扱ってみることを奨めてみるテスト。

167 ：デフォルトの名無しさん：2005/04/03(日) 13:19:40

どの言語でも、アホが書けばバグが出る。
まともな奴が書けばバグは出ない。

168 ：デフォルトの名無しさん：2005/04/03(日) 13:41:29

「プログラミング言語なんて，一つ知っていれば十分だ」
と考えている人がいるかもしれないが，それは大きな間違いだ．
確かに，どのようなプログラミング言語を使ったとしても，その記述能力はチューリングマシンと同じである．
しかし，「プログラムを記述することができる」ということと「プログラムを自然な形で，容易に記述することができる」
ということには大きな隔たりがある．
プログラミング言語というものは，ある特定の目的を想定して設計されているから，与えられた問題に対して適切な
プログラミング言語を選択することは，そのプロジェクトの成否を左右する重要なことだ．

169 ：デフォルトの名無しさん：2005/04/03(日) 14:09:33

>>168
そうでもなかったりするんだよな

Cかアセンブラができれば、まず間違いなく殆どのことができる。
（まー、アセンブラは別の意味でダメだろうけど）

Cもライブラリを作って、あとはロジックだけ入れれば動くような
資産を作っておけば、他の言語とあまり開発効率も変わらない。
ただし、習得までに時間が掛かるので、使われていないだけ。
特に大規模な場合、技術者が集まらない。

そんな俺も今メインの仕事はJAVAだがな。

170 ：デフォルトの名無しさん：2005/04/03(日) 16:02:38

ぽかーん

171 ：デフォルトの名無しさん：2005/04/03(日) 18:08:34

１つの言語という概念を捨てる。どこの国の言語や方便でも対応できる。
「B747で羽田から伊丹まで運行するフライトシミュレータ」と打つだけで開発できる。
コンピュータは隅々まで完璧なものを作ろうとするのでそこを制限する。
人間が可能性を作り上げるのではなくコンピューターが作ろうとする無限を
人間がここまで開発するというゴールを決めるだけ。
これぞ誰もが求める最高の言語だ。

172 ：デフォルトの名無しさん：2005/04/03(日) 18:21:33

そして人間が、B74はどういう物かという情報を入力し間違えて事故になる

結局、どんなに簡単にしても駄目な奴は駄目

173 ：デフォルトの名無しさん：2005/04/03(日) 18:43:26

プログラミング言語はJAVAが最期のメジャー言語。
もう、終わったんだっ！終わったんだよっ！！！！！！！！
チクショウっ！

174 ：デフォルトの名無しさん：2005/04/03(日) 18:45:47

そうだね、>172のように飛行機の機種を間違えるようじゃ危なくて仕方ないよな。

175 ：デフォルトの名無しさん：2005/04/03(日) 18:57:54

>>171
名指しで人を殺せと命令したらネット伝ってどこかの政府機関にアクセスして
その人の家に向けてミサイル発射させたりするんだろ？

176 ：デフォルトの名無しさん：2005/04/03(日) 19:01:07

＞B74はどういう物
Bカップ74cmじゃなかったのか。。。

177 ：デフォルトの名無しさん：2005/04/03(日) 19:47:46

>>169
お前もしかしてアホ？

178 ：デフォルトの名無しさん：2005/04/03(日) 19:50:02

この前からナンセンスなことばかり言っていたやつかい？
まぁ、いいか、と思ってスルーしていたけど、いい加減考えてから書き込んでくれ。

179 ：デフォルトの名無しさん：2005/04/03(日) 20:07:33

自作自演のにおいを感じる

180 ：デフォルトの名無しさん：2005/04/03(日) 20:15:02

>>179
>>177と>>178は続きね。

181 ：デフォルトの名無しさん：2005/04/04(月) 13:13:09

非正格な方が定義の順番を気にしないでいいからバグが減ると思うんだけど、どうだろう。

182 ：デフォルトの名無しさん：2005/04/04(月) 13:40:56

結局関数型言語が最強ってことか

183 ：デフォルトの名無しさん：2005/04/04(月) 14:22:33

でもhaskellまでいくと理解できる人がほとんどいなくなっちゃんだよね。

184 ：デフォルトの名無しさん：2005/04/04(月) 14:27:43

バグの出やすい言語から出にくい言語を推測してみるのはどうだ？

185 ：デフォルトの名無しさん：2005/04/04(月) 20:01:39

あれだ、再帰と束縛だけ定義した言語ってのはどうだ？制御構造は再帰だけでできるし。

186 ：デフォルトの名無しさん：2005/04/04(月) 20:04:58

意外と再帰でループ書くのって面倒だよ
SchemeやMLみたいにnamed-letやlet recみたいな特殊構文ないと

187 ：デフォルトの名無しさん：2005/04/04(月) 20:06:35

実はif文も入らないから非常にシンプル。
再帰でループって別に慣れたらむずかしくないと思うけど…

188 ：デフォルトの名無しさん：2005/04/04(月) 20:07:19

あとcdeclだと末尾コールのフレーム縮小できないんだよね
全部stdcallにするか、根本を変えるしかない

189 ：デフォルトの名無しさん：2005/04/04(月) 20:07:43

>>187
無知が適当こくなよ

190 ：デフォルトの名無しさん：2005/04/04(月) 20:08:42

>>189
？？えと、どこか間違ってる？？？

191 ：デフォルトの名無しさん：2005/04/04(月) 20:10:29

>実はif文も入らないから非常にシンプル。
無知が

>再帰でループって別に慣れたらむずかしくないと思うけど…
>>186
適当こくなよ

192 ：デフォルトの名無しさん：2005/04/04(月) 20:17:22

factorial 0 = 1
factorial n = n * factorial (n-1)

193 ：デフォルトの名無しさん：2005/04/04(月) 20:21:56

>>186
let recって束縛でしょ？これがなんで特殊なの？？？

194 ：デフォルトの名無しさん：2005/04/04(月) 20:22:45

あのなあ、それでif文消えても、なんか増えてるだろ、おい

195 ：デフォルトの名無しさん：2005/04/04(月) 20:23:12

>>194
何が増えてるの？
多重定義しただけじゃん。

196 ：デフォルトの名無しさん：2005/04/04(月) 20:24:23

>>193
let recなしでループ書こうとか思ってんのか

197 ：デフォルトの名無しさん：2005/04/04(月) 20:24:47

多重定義じゃないと思うなあ・・

198 ：デフォルトの名無しさん：2005/04/04(月) 20:27:36

>>196
MLだとletの代わりにlet recって書かないとダメだけど、その言語だとそうだというだけで、束縛は束縛。同じ意味やもん。

199 ：デフォルトの名無しさん：2005/04/04(月) 20:28:31

無知というより、頭悪いだけか

200 ：デフォルトの名無しさん：2005/04/04(月) 20:29:30

>>199
なんだと！！！じゃ＞＞192はなんなんだよ！！！！

201 ：デフォルトの名無しさん：2005/04/04(月) 20:30:57

多重定義じゃなかったらなんて呼ぶんだよ！！！

202 ：デフォルトの名無しさん：2005/04/04(月) 20:31:27

条件式の数だけ関数を定義してくのか
おめでたい頭だな

203 ：デフォルトの名無しさん：2005/04/04(月) 20:35:00

多相定義っていうのかな？

204 ：デフォルトの名無しさん：2005/04/04(月) 20:37:07

>>203
おお、きっとそうだありがとう

>>202
めでたいかな…えへへ^^

205 ：デフォルトの名無しさん：2005/04/04(月) 20:41:47

まあ関数型にはif文の他にもパターンマッチによる分岐があると言いたかった、と

206 ：デフォルトの名無しさん：2005/04/04(月) 20:43:53

>>205
いいや、再帰と束縛で全部かけるっていいたかったんだ！！！

207 ：デフォルトの名無しさん：2005/04/04(月) 20:50:00

オトコって都合良いこと言うわよね

208 ：デフォルトの名無しさん：2005/04/04(月) 20:53:24

>>207
惚れ直したかい？奥さん。ってキモいってキモすぎるお前もキモいんだよ！！！！糞ネカマにまで馬鹿にされちまった。

209 ：デフォルトの名無しさん：2005/04/05(火) 12:30:41

>>192 (if 文からは話それるけど)

factorial (-1) だと無限loopになるよね。

この点はadaだと、ループの終了条件をコンパイル時に検出できるけど。
Haskellでは、これをチェックする仕組みとかあるのかな?

>>193
束縛される名前の有効範囲が違う。

210 ：デフォルトの名無しさん：2005/04/05(火) 12:45:43

>>209
adaは知らないのだけど、haskellでは停止性判定なんてできないよー。そもそも停止性って判定できないでしょ？

211 ：デフォルトの名無しさん：2005/04/05(火) 12:51:43

>>209
それに、ループの終了条件はプログラムを組む時点で書いてやらなくちゃいけないもん。

212 ：デフォルトの名無しさん：2005/04/09(土) 14:08:24

まぢれす。BrainF**kにしたまえ。この板のどこかにあるから。

213 ：デフォルトの名無しさん：2005/04/09(土) 14:09:24

>>212
なにをBrainfuckにするの？

214 ：デフォルトの名無しさん：2005/04/09(土) 19:37:55

ｽﾚタイトル間違ったな。
あまりにも漠然だ。
だからー王道としては「バグとは？」っていうところからハイらなきゃならんでしょ。
制約を大量につける方向の意見がたくさん出てたけど、DBの設計とかでも
主キーさえ設定されていないシステムとかあるからなぁぁぁぁ。。ホント良くうごいてると思うよ。

215 ：デフォルトの名無しさん：2005/04/10(日) 02:26:21

絶対に欲しい言語仕様
・一つの関数 (って概念が無ければロジックの塊) が50行を超えることはできない

216 ：デフォルトの名無しさん：2005/04/10(日) 02:40:56

普通にswitch文入ると50行超えそうだよ

217 ：デフォルトの名無しさん：2005/04/10(日) 03:06:09

http://www.rubyist.net/~matz/20050402.html#p02

空白の使い方に自由度がありすぎる、
TOOWTDI (There's Only One Way To Do It) 原則から言えば望ましくない。
よって、

* インデントは厳密に空白4つ。タブ問題もこれで解決。
* 冗長な括弧は禁止(例: return (1) は駄目、return 1が有効だから)。
* 左括弧直後および右括弧直前の空白は禁止。
* 引数括弧およびインデックス参照のブラケット直前の空白は禁止。
* コンマやセミコロンの前の空白は禁止。
* コンマやセミコロンには厳密に一つだけの空白(行末を除く)。
* 行末のセミコロンは禁止(冗長だから)
* 式の中で二つ以上の連続する空白は禁止。
* 代入および比較演算子の前後には必ず空白が必要。
* 演算子の左右の空白の量は等しくなければならない。
* 式の中の空白の数に変化がある場合には
演算子の優先順位を反映していなければならない。
つまり、"1*2 + 3*4" は大丈夫だが、 "1*2 + 3 * 4" は駄目。
しかし、推奨されるのは"1*2+3*4" である。
* コロンの前の空白は禁止。
* ディクショナリリテラルではコロンの直後に厳密に一つだけの空白。
スライスのコロンの直後の空白は禁止。
* ブロックの短縮形式 ("if x: y") は廃止。改行とインデントを使うこと。

というルールを導入する。

218 ：デフォルトの名無しさん：2005/04/10(日) 03:12:18

>>216
switchで50行超えてる時点でダメ

219 ：デフォルトの名無しさん：2005/04/10(日) 05:26:01

一ブロック30行以内。ブロック内に更にブロックを含む場合は、その行数を除いて30行以内。
Ex.
any func
{
...; // a
{
...; // b
}
...; // c
}
// b < 30, a + c < 30
更にネストの制限があればそこそこに抑えられるんジャマイカ。

220 ：デフォルトの名無しさん：2005/04/10(日) 07:43:57

>>218
長すぎる関数はダメだと俺も思うが、どうしても長くなってしまう、
かつ長くなっても問題ない代表例がswitchだろう。
バイトコードインタプリタとか、オートマトンとか、長～いswitch caseになり、
かつそれがさして問題にならないケースは多い。

目安だけど、case間で共用する変数が少なければいいんじゃないかね。

関数は何があっても××行以下でなきゃいかん!! という意見の方がよっぽど
バカだと思うんだがどうよ。

参考リンク：
http://www.st.rim.or.jp/~phinloda/cprog.html
http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.1.3.html

221 ：デフォルトの名無しさん：2005/04/10(日) 07:58:45

>>220
その手のものを知ってれば218みたいなことを言いださないのは自明じゃない。
つまり218には全く情報工学的な知識がないってのは明らかなんだから
そのレベルに合わせてやんなよ。

30行とかいうアホみたいな制限つけても、
foo() {
...
return foo_2();
}
foo_2() {
...
return foo_3();
}
のようにtail callでカスケードして回避されたら本末転倒だね。

222 ：デフォルトの名無しさん：2005/04/10(日) 09:47:49

>>218みたいな素人は口出すなよ。
ここで発言して良いのは少なくともコンピュータサイエンスの初歩を学んだ事がある人間だけだ。

223 ：デフォルトの名無しさん：2005/04/10(日) 11:18:55

コンピュータサイエンスとswitchの行数がなんで関係があるのかｗ

224 ：デフォルトの名無しさん：2005/04/10(日) 11:19:49

>>223
口出すなよ、素人。

225 ：デフォルトの名無しさん：2005/04/10(日) 15:07:32

コンピュータサイエンスの初歩ってなにかな？
大学で情報処理関連の学科を修めること？

226 ：デフォルトの名無しさん：2005/04/10(日) 15:21:14

>>225
自分で考えて判断しろ。未熟だと思うなら来るな。

227 ：デフォルトの名無しさん：2005/04/10(日) 15:40:18

コンピュータサイエンス未修者どころか既知概がいるな

228 ：デフォルトの名無しさん：2005/04/10(日) 15:48:54

他人に押しつける最低条件を提示しておいて、自分で考えろって（ｗ

229 ：デフォルトの名無しさん：2005/04/10(日) 15:57:39

コンピュータサイエンス関連の査読つき論文を一本でも書いたやつは素人では無いと判断しよう。

230 ：デフォルトの名無しさん：2005/04/10(日) 16:33:35

最近switch文なんか使わないな
つうか普通分岐が多くなったら保守性を考えて
ジャンプテーブルとか多態を使うとかするだろ
そういう意味じゃ>>218のいう事はわかるけど

コンピュータサイエンスの初歩ってなんだろうな

231 ：220：2005/04/11(月) 02:28:07

>>230
たとえばバイトコードインタプリタだと、

case I_ADD:
　stack[sp-2] = stack[sp-2] + stack[sp-1];
　sp--;
　break;

程度のcaseがずらずら並ぶことが多いわけよ。
こんなもん、ジャンプテーブル(関数ポインタのテーブル?)や多態を使って
書いたとして、何かいいことあるか?

Plaugerの「プログラミングの壺」でも、switch caseはサブルーチンが長くなっても
しょうがないケースとして挙げられていたと思う。

232 ：デフォルトの名無しさん：2005/04/11(月) 12:25:29

古い表現だが。
「情報的強度を持つ」と表現されるモジュール/関数かな

233 ：デフォルトの名無しさん：2005/04/24(日) 15:41:57

トレンドマイクロのウィルスバスターが原因のシステム障害。
これ、絶対に「バグが出にくい言語仕様」とかいうレベルで解決できるバグじゃないっしょ。

真相はわからないけど、
Windows SP2 のあるファイルをウィルスと誤検出して何度もアタックしてCPU使用率１００％
になってしまってるそうです。いつもは、「隔離に失敗しました」とか出るけどね。今回はなんでかね。

まともにテストやってれば絶対防げるたぐいの障害だったと思うんだが、
テストしてないとかってもう問題外だよね。（　´,_ゝ`）ﾌﾟｯ

234 ：デフォルトの名無しさん：2005/04/24(日) 16:34:11

しかし代替しようにも物が某ノートンしかない現実

235 ：デフォルトの名無しさん：2005/04/25(月) 10:30:02

avast! や AVG でいいんじゃない。
ClamAV はマクロウィルスが弱いなぁ。

236 ：デフォルトの名無しさん：2005/04/29(金) 00:53:19

関数型言語はHowではなくWhatを書くというがまだまだHowを書いてるように思う。
ソートとかでも
sort(array)
{
return x,x in permutation(array),all i in 0..array.length-2,x[i]<=x[i+1];
}
みたいに書けないもんだろうか。もしこれでいけたらバグも減ると思うんだが。

237 ：デフォルトの名無しさん：2005/04/29(金) 00:55:37

＞length-2
一目でバグの予感のするコードだな

238 ：デフォルトの名無しさん：2005/04/29(金) 00:56:14

>>236
同じのをHaskellで書いてみな

239 ：デフォルトの名無しさん：2005/04/29(金) 09:01:26

バグが出にくくするには、一文字入力する毎にすべてをチェックする、強力なプロセッサがあればいいのでは

240 ：デフォルトの名無しさん：2005/04/29(金) 09:04:55

eclipseはそれに近くねーか。

241 ：デフォルトの名無しさん：2005/04/29(金) 09:37:13

>>236
ソートにO(n!)かかりそう。

242 ：デフォルトの名無しさん：2005/04/29(金) 10:00:18

ランダムに置き換えてソートされていたら終了するていうアルゴリズムどうかな
運がよければ一発でソートできるかも

243 ：デフォルトの名無しさん：2005/04/29(金) 10:52:45

バブルソートでも、運がよければソートする前にもうソートされてるかも

244 ：デフォルトの名無しさん：2005/04/29(金) 10:58:10

それは入力データに依存してるじゃない
ランダムソート法では入力データには依存しないことが証明されている
「運」という概念をプログラミングに持ち込むというわけ
勝ち組のためのプログラミング手法ね

245 ：デフォルトの名無しさん：2005/04/29(金) 12:14:19

ﾜﾗﾀ

246 ：デフォルトの名無しさん：2005/04/29(金) 18:57:19

意外と笑い話でないかも
実用範囲で実現するはずはないが
並列にすべての入れ替えをやらせてみて
失敗したものは殺すという具合に

247 ：デフォルトの名無しさん：2005/04/29(金) 20:10:32

Prolog みたいな言語だと、そういうのが普通だったり。
実際に並列処理できるかどうかは別として。
だからパズルなんかに強い。

248 ：デフォルトの名無しさん：2005/04/29(金) 23:13:09

>>246-247
そんなことは、ちょっと考えれば誰でも思いつくと思うんだけど...。

http://www.google.co.jp/search?hl=ja&q=%E3%82%B2%E3%83%BC%E3%83%A0+%E4%B8%A6%E5%88%97%E6%8E%A2%E7%B4%A2&lr=

249 ：デフォルトの名無しさん：2005/04/30(土) 21:24:30

誰でも思いつくからといって
特許にならないというわけではない

250 ：デフォルトの名無しさん：2005/04/30(土) 22:47:07

誰も特許の話なんかしてないわけだが...。

251 ：デフォルトの名無しさん：2005/05/11(水) 15:37:16

>>242
発想が１０年遅い
まあこれからは君もシャッフルソートの普及につとめるのだ

252 ：デフォルトの名無しさん：2005/05/20(金) 18:47:12

236のコードでコンパイラがソートだと認識できれば
最適化でクイックソートのコードを吐けるんじゃないかな。

253 ：デフォルトの名無しさん：2005/06/03(金) 22:59:50

ソートとか懐かしいな。クイックソートのアルゴリズムを、友人とあーでもないこーでもないと
言いながら考えてた頃が一番楽しかった。今では苦痛でしかないが。

んで、>>242の言うランダムソートって早い？速さの期待値ではバブルソートと同じに思うんだが。

254 ：デフォルトの名無しさん：2005/06/03(金) 23:34:41

そこまで速いわけねーし、つまらん。

255 ：デフォルトの名無しさん：2005/06/04(土) 02:53:57

>>248
＞この世の果てて恋を唄う少女ＹＵ－ＮＯ
＞このゲーム、並列世界を探索しているときは、２で書いたとおり高いストーリー性と
＞ゲーム性を有した作りになっているのですが、目的の場所であるデラグランドではそう
＞でもなくなります。ルート分岐はないですし、アイテムを使ってゲームを進展させていく ...
＞homepage3.nifty.com/konbatto/yu-no.htm - 18k - キャッシュ - 関連ページ

何が言いたいのかわからん・・

256 ：デフォルトの名無しさん：2005/06/04(土) 18:56:35

エロゲヲタの普及活動はｷﾆｼﾅｲ

257 ：デフォルトの名無しさん：2005/06/07(火) 22:18:46

236のまね。
だれか解読してくれ。

u(sequence<vertex> x)
{
return all i,j in x.index , i!=j
　{
　　x[i]!=x[j];
　}
}

l(graph g)
{
return { x in g.vertex.subsequence |
　　　　　　　u(x);
　　　　　　　x.length>=3;
　　　　　　　all i,i+1 in x.index
　　　　　　　{
　　　　　　　　　{x[i],x[i+1]} in g.edge;
　　　　　　　}
　　　　　　　{x[0],x[x.length-1]} in g.edge;
　　　　　　}
}

is_t(graph g)
{
　　return l(g).length==0;
}

258 ：257：2005/06/07(火) 22:24:58

しまった。
一箇所プログラム間違ってた。
まあ、いいや。大筋はあってるし。

259 ：デフォルトの名無しさん：2005/06/07(火) 23:10:50

>>236 とか >>257 みたいなのは、 Prolog 辺りでなら素直に書けると思うけど。

>>236 なんかは

ascending([]).
ascending([_|[]]).
ascending([H|T]) :- [S|_] = T, H =< S, ascending(T).

sort(List, Result) :-
permutation(List, Result), ascending(Result).

だいたいこんな感じで、ちゃんと動くし。

260 ：デフォルトの名無しさん：2005/06/08(水) 22:03:55

Prologのことは知らんがそれはO(nlogn)で動くわけ？

261 ：デフォルトの名無しさん：2005/06/09(木) 01:24:26

もちろん動かない。
順列作って一つずつチェックするんだから、 O(n!) とかじゃないかな。

262 ：デフォルトの名無しさん：2005/06/12(日) 03:16:58

ランダムソート法の話が出てるが量子コンピュータ使えば実現の可能性は無くも無いな
まあ、要素４つまでですとか、激しく実装制限付きそうだが

263 ：デフォルトの名無しさん：2005/07/07(木) 09:11:57

バグ低減に関係あるかわからないけど
ちょっと思ったことをチラシの裏。

ある float i は0.0～∞までの値域を持ち、
1.0以上の値を入力されるとループして
必ず0.0～1.0の間に収まるように処理される。
そしてこの float i を受け取る関数 void f( float i ) があるとする。
皆さんが f を設計する場合 i に大して何らかのチェックを設けるだろうか？
もし自分なら、i が値域に収まるよう加工すると思う。

void f( float i　){
i = upper_loop( i, 1.0 );
・・・

しかし、これだと f を呼び出す側がちゃんと値域に収めていた場合、
同じ処理を2度行うことになり無駄になってしまう。

i = upper_loop( i, 1.0 );
f( i );

この例以外にも、たとえばNULLチェックなど
当てはまるケースは少なくないように思う。
これを静的に回避出来るような仕様をもった言語は今存在するだろうか？
回避することは可能だろうか？

264 ：デフォルトの名無しさん：2005/07/07(木) 10:27:17

負けずにチラシの裏
「もし自分なら」のほうが正しい
0.0～1.0の値域をもつ変数型を定義可能に
回避する事に意味があるとは思わない。
仕様明示すれば無駄なことする奴はいないだろうし、いたとしても呼ぶ側の問題

265 ：デフォルトの名無しさん：2005/07/07(木) 10:52:03

>>263の言いたいことは判らんではないのだが、>>264はいっちょん判らん。
#まぁ、チラシの裏だからな。

266 ：デフォルトの名無しさん：2005/07/13(水) 23:29:18

>>262
4つまでじゃバブルソートでもよさげだな

267 ：デフォルトの名無しさん：2005/07/14(木) 11:54:25

現場からの声っぽく書いてみる。

Java の言語仕様はメモリーリーク系のバグが出にくいよ。
変に気を使ってメモリー管理するプレッシャーから開放された。

いま、変に気を使っているのはスレッド。
スレッド関係のバグ多いよ。めちゃくちゃ気を使う。
言語仕様のレベルでスレッド絡みのバグが出にくいものなんて
できると嬉しいねぇ。

268 ：デフォルトの名無しさん：2005/07/14(木) 16:15:11

現場じゃなくたってみんな感じてることだよそれは。

269 ：デフォルトの名無しさん：2005/07/17(日) 22:49:59

スレッドを使ったプログラムを書いたことのないへたれなおれに
どの辺が気を使うのか教えてクレ。

270 ：デフォルトの名無しさん：2005/07/19(火) 13:27:05

>>269
如何にまともな人間に書いてもらうかが、一番気を遣うと思われ。
#まさかへたれを自認しているのに自分で書く気を起こすわけじゃないよな?

271 ：デフォルトの名無しさん：2005/07/19(火) 20:11:49

最初はみんなへたくそ（≠へたれ）。

272 ：デフォルトの名無しさん：2005/07/20(水) 00:45:43

>>269
デッドロック

273 ：269：2005/07/20(水) 21:02:43

デットロックて食事する哲学者とか？
そんなのもう解決した問題かとおもてた。
現実はもっと複雑になるのかな？

274 ：デフォルトの名無しさん：2005/07/21(木) 17:33:15

>>273
スレッドを使ってプログラミングしてみると良い

275 ：デフォルトの名無しさん：2005/07/21(木) 20:34:25

って言うか、解決してる。

276 ：デフォルトの名無しさん：2005/07/23(土) 01:32:54

>>275
まずはお前の言う「解決してる」の定義を説明してみろ。

277 ：デフォルトの名無しさん：2005/07/23(土) 03:47:42

1.5使ってみればよい話なんじゃないの？

278 ：デフォルトの名無しさん：2005/07/23(土) 16:43:28

1.5とはなんじゃらほい

279 ：デフォルトの名無しさん：2005/07/23(土) 17:26:53

話の始まり(>>267)がJavaだからSDKのバージョンのことじゃない?
1.5でスレッドの何が改善されてデッドロックが起きなくなったのかは知らないけど

280 ：デフォルトの名無しさん：2005/07/23(土) 19:21:11

次期C++では
const句,throw句の他に
cpp句でcスタイルのプログラムを出来なくして欲しいね。

281 ：デフォルトの名無しさん：2005/07/23(土) 19:44:30

別に JDK5.0 (1.5) でも、スレッド周りの言語仕様は何も変わってないよ。
>>275 はいい加減なこと書いて釣りしてるだけじゃないのか？

282 ：デフォルトの名無しさん：2005/07/23(土) 21:50:01

>>267
Cωにそんなのなかったっけ

283 ：デフォルトの名無しさん：2005/07/23(土) 21:52:56

>>263
性的に回避したいのなら、
f( float i ) {
assert( 0 <= i && i <= 1.0 );
}
でよいような。。。

284 ：デフォルトの名無しさん：2005/07/23(土) 23:16:48

>>283
assertではリリースビルドでは消えてしまうし
結局関数fに範囲外の値が渡されてしまう可能性が残ってしまう。
そういった「もし○○でなかったら～」という受身の姿勢ではなく
「○○である保障をつける」というアプローチが出来れば、
より安全になるし、余計な処理も減るし、最適化も効きやすくなるんではないかと。

例えば、楕円体の物体と点との衝突判定する関数がある。

bool detect_collision_of_point_and_ellipsoid( const vector3& point, float_t radiusR, float_t radiusS, float_t radiusT)
{
assert( radiusR != 0.0f && radiusS != 0.0f && radiusT != 0.0f);

const float_t m = radiusR / radiusS;
const float_t n = radiusR / radiusT;
return point.x * point.x + m * m * point.y * point.y + n * n * point.z * point.z <= radiusR * radiusR;
}

radiusSとradiusTは除数になるのでゼロであってはならない。
半径がゼロでは楕円体として存在できないから、この制限は当然と言える。
だったら最初からradiusSとradiusTは、ゼロには絶対にならないという保障を付けてしまえばいいとか。
XMLってこれと似たような仕様を持っていたような・・

285 ：デフォルトの名無しさん：2005/07/23(土) 23:26:09

計算の度に0になって無いかチェック入れないとダメじゃん。

286 ：デフォルトの名無しさん：2005/07/23(土) 23:29:07

なんでいきなりXML。DbCを知らんのだろうか?

287 ：デフォルトの名無しさん：2005/07/24(日) 00:19:28

デバッガ上とかで、デッドロックそのものって検知できる？
「今こことここでデッドロックしてますねざまーみろ」と言ってくれるような
デバッガってありますか？

288 ：デフォルトの名無しさん：2005/07/24(日) 02:25:48

COBOLでの話@JavaWorldだが、変数名を漢字に書くようにしたらしたらバグが1/3減ったらしい。
たしかに、ケアレスミスは減りそう。

案外日本語プログラムでまともなのがでたらいいのかも。

289 ：デフォルトの名無しさん：2005/07/24(日) 03:02:11

日本語で文章を書いても>>288のようなごくごく短い文ですらケアレスミスを含む
ようでは、その効果はあまり期待できなさそう。

290 ：デフォルトの名無しさん：2005/07/24(日) 08:13:02

ＰＨＰをはくホームページビルダーみたいなソフトが、オープンソースで開発されて、
大量のプラグインが供給されれば、最強じゃない？プログラムを書かなくていいんだし
みんなプログラムをしなくていい、ＳＥになろうぜ
デスマからも開放で最強

291 ：デフォルトの名無しさん：2005/07/24(日) 08:23:16

>>289
連番を振っただけの変数名よりは遥かにマシだと思う。

292 ：デフォルトの名無しさん：2005/07/24(日) 10:20:12

一バイトかなだらけの糞ソースが誤変換だらけの糞ソースになるだけだろ。

293 ：デフォルトの名無しさん：2005/07/24(日) 10:56:18

>>291
連番を振るような人は日本語にしても連番振るんでない？

294 ：デフォルトの名無しさん：2005/07/24(日) 12:24:19

壱弐参四五六七八九拾

295 ：デフォルトの名無しさん：2005/07/24(日) 13:28:12

最終的にはリファクタリングするとして、最初のクラス図を書いてソースコードを
生成する部分には日本語が使えると便利だと思う。

296 ：デフォルトの名無しさん：2005/07/24(日) 13:35:06

普通に日本語も使えると思うのだが。
好むかどうかは兎も角、kaisuuなどとローマ字綴りをしてもいいし、
変換するスクリプトを一つ書いておくだけでもいいと思うぞ。

297 ：デフォルトの名無しさん：2005/07/24(日) 14:09:20

>>296
ん～、て言うか、ぶっちゃけ、>>295を満たす様なEclipse用のプラグインが
欲しいんだよな。とか思ってたら普通に使えるし！＞日本語

public class テストクラス {
　private Vector メッセージリスト;
　public テストクラス() {
　　メッセージリスト = new Vector();
　}
}

こんなのを普通にコンパイルして実行可能だった（ﾟдﾟ）ﾎﾟｶｰﾝ
普通に無理だと(Eclipseが文句言うだろうと)思って試してみた事もなかっ
たのが敗因か・・・・・・・・にしても、キモ！ｗ
でも、やっぱ日本語は読みやすい。setメッセージ等というメソッドを見て
ると、やっぱ珍妙には感じるが・・・・・・

298 ：デフォルトの名無しさん：2005/07/24(日) 16:16:23

>>297
日本語、結構便利だぞ。
学生の頃、フルアセンブリ言語のソース書いたときは
全てラベルをＳ－ＪＩＳ全角で記したよ。
マクロはアルファベットで書いて住み分けして。

299 ：デフォルトの名無しさん：2005/07/25(月) 00:37:53

英語だと先頭だけ大文字とか全部大文字とかして種類を区別できるけど
日本語シンボルだと難しいよね。何か妙案はあるかね。

300 ：デフォルトの名無しさん：2005/07/25(月) 04:45:10

>>285
先の例の目的はあくまで静的にゼロチェックすることだ。動的にやっては意味がない。
たとえば「( A - ( B / C ) ) * D」という式があるとする。この解がゼロになる条件は自明的に得ることができる。
・A と ( B / C )が同じ値
・Dがゼロ
以上の条件をいずれも満たさない場合、この式の解は非ゼロであると保障することができる。

しかし、全ての値が静的に決まる訳ではない。人間による入力やファイルからの読み込み、時間や乱数など
動的にしかわからないものもある。
しかしその場合も上のように方程式を解くことによって、「動的に入力される値がこの値ならばゼロになる」のような
例えるなら「危険な値」を特定することが出来る。

301 ：デフォルトの名無しさん：2005/07/25(月) 04:54:22

>>287
スレッドというのは手続き型言語の範疇を超えている。
その例は不適切だ。

自分的には、そもそもデットロックが起こる可能性のある手法を
なんとかデットロックが起こらないように組む、これがそもそも間違っているのではないかと思う。
例えば、今流行のGPUのShader言語は複数の処理が並列に実行されるがデットロックが起こることは
決してない。これが正しい並列プログラムのやり方だと思う。

302 ：デフォルトの名無しさん：2005/07/25(月) 05:19:58

>>300

それを行うにはすべての関数で逆関数を求める必要があるから
事実上不可能だな。
まぁ言語仕様自体をそれが可能な範囲に制約してしまうという
アプローチもあるが、機能的にかなり限定された言語になって
しまうだろう。

303 ：デフォルトの名無しさん：2005/07/25(月) 09:58:13

>>300
どうでもいいけどその例の場合、Cが0かどうかのチェックが先に来なくては意味がないね。

304 ：デフォルトの名無しさん：2005/07/25(月) 10:18:07

>>2
的を射てるな。
システムを構成するコードが減れば減るほど保守性は向上する。
これには無理矢理トリッキーな手法でソースコードを短くする行為は含めない。

究極は彼の言うようにコードを一行も書かずにシステムを構築することだ。
それで客の要求を満たせるのであればそれはすべての人が幸せになる解決策だ。

305 ：デフォルトの名無しさん：2005/07/25(月) 11:29:08

>>304
実務においてSEがその方針をとると、製作工数が発生しないので会社もSE自身も嬉しくない罠。
#更に市販ソフトのインストール作業と顧客へのチュートリアルをさせられる罠。

306 ：デフォルトの名無しさん：2005/07/25(月) 14:00:34

>>305
なるべくコードを書かずしてカスタマイズする方法を確立すればいい。
エンジニアリングに工数も発生するが低級な面倒なバグは減る。
高レベルなバグは比較的取りやすいわけで。

だからフレームワークや○○ツクール的なアプリケーションの開発というのは有用だと思う。

307 ：デフォルトの名無しさん：2005/07/29(金) 19:39:02

ttp://moech.net/imgboard777/src/1122461424251.jpg

308 ：デフォルトの名無しさん：2005/07/29(金) 19:42:32

俺のクラスにも307みたいなのいるよ。

309 ：デフォルトの名無しさん：2005/07/29(金) 20:13:05

なんだこれは

310 ：770：2005/07/29(金) 20:47:04

おれならＭＬでスマートに書くけどねｗ

311 ：デフォルトの名無しさん：2005/07/29(金) 22:49:23

おれならﾊｽｷﾙﾙでエレガントに書くけれどね

312 ：デフォルトの名無しさん：2005/07/30(土) 03:17:34

>>307
ぱんちゅ

313 ：デフォルトの名無しさん：2005/07/30(土) 08:46:51

>>307
これだから絵かける奴は裏山しい

314 ：デフォルトの名無しさん：2005/10/05(水) 00:13:54

１００人でペアプロしよう！

もしくは、

１つの関数に３とおりの処理を記述し、すべてが一致しないと先に進めない処理系を作ろう。

315 ：デフォルトの名無しさん：2005/10/08(土) 22:55:36

>>1
ポインタを使いこなせない「自称『C』使い」を排斥するだけで
解決するのでは？

316 ：デフォルトの名無しさん：2005/10/10(月) 12:26:31

バグ出す奴＝ポインタを使いこなせない奴
という考えが短絡的で愚か

317 ：デフォルトの名無しさん：2005/10/10(月) 23:22:51

>>316
誰もそんな事言ってないようですが。
何か受信しちゃいましたか？

318 ：デフォルトの名無しさん：2005/10/12(水) 11:59:26

悪い電波さ

319 ：デフォルトの名無しさん：2005/10/13(木) 19:50:50

は？

320 ：デフォルトの名無しさん：2005/10/13(木) 20:08:28

アルゴリズム単位で記述する言語

321 ：デフォルトの名無しさん：2005/10/13(木) 20:23:13

それって関数型言語・・

322 ：デフォルトの名無しさん：2005/10/13(木) 20:36:17

#私はいま、「車輪の再発明」を目撃したのだろうか？

323 ：デフォルトの名無しさん：2005/10/13(木) 21:39:13

標準出力に文字列しか出力することができない言語
子息演算や関数やクラスという概念も無い。

これでバグはでない！

324 ：デフォルトの名無しさん：2005/10/13(木) 21:51:56

仕様：「0l」を出力せよ。
実装：「O|」を出力。

ハイ、バグの出来上がり。

325 ：デフォルトの名無しさん：2005/10/13(木) 22:44:51

OCRで読み込めばOK

326 ：デフォルトの名無しさん：2005/10/14(金) 10:49:19

変数の値によって処理が分岐したり、繰り返しがあったり、いろんなことが出来るような
言語仕様だからバグがでるんだよ。その言語で出来ることを減らせばバグも経る。

例えば：
入力されたソースプログラムのバイト列のどこかに、一つでもビットが立っていれば、
68 65 6c 6c 6f 2c 20 77 6f 72 6c 64 0a という１３バイトを出力し、
ビットが立っていなければ何もしない。という言語仕様。

これならバグは出にくい。

327 ：デフォルトの名無しさん：2005/10/15(土) 03:50:16

最近、「継承」に懐疑的で、インターフェースだけでなんとかならないだろうか、と考えてます。
少なくとも「再利用できるから継承する」とか、「親クラスの機能を置き換えるために継承する」
というのは動機として不純だと思う。

どのオブジェクト指向言語も Object を頂点とした系統樹を育ててきたけれど、
言語によってそれは全然バラバラ。Java,MFC,C#しかり。SmallTalkも全然違う。
それって、考えてみれば変な気がする。
どれもオブジェクト指向なのに、そのとっても大事な系統樹が全然違うなんて。
そもそも、オブジェクトを系統立てること自体が間違いじゃないだろうか？

まず「クラス」よりも「インターフェース」が大事、と言うのは同意が得られるよね。
基本的にはインターフェースを中心に置いた設計がいいと思う。
継承の動機って何だろう？
その動機を他の形で置き換えられれば、継承は必要なくなるはず。
util的な実装に置き換えられないだろうか？
アスペクトの織り込みでできないだろうか？

328 ：デフォルトの名無しさん：2005/10/15(土) 05:02:14

>>327
なんとなく同意。

329 ：デフォルトの名無しさん：2005/10/15(土) 05:42:03

>>2
には割合同意。ただプログラムが皆無になるということはなくて、
プログラムはできるだけコンパクトにして、できるだけデータに追い出すってのは
正しい方向性だと思う。

ただあれね。文字ベースのコードってのは「書いてあること以外は何もないよ」っていう
安心感はあるから、細かい仕様を気にする以上そういった特質は必要なものだと思う。

>>327
も通った道だなぁ。
依存関係を減らすことがプログラムの独立性を上げて、再利用しやすくする道なのに、
継承ってのは非常に密接な依存性を導入してしまう。

327が言うように、あまり「継承が基本」みたいな言語仕様はよろしくない気はする。
リスクの少ない包含(has a)＋インタフェース継承なんかを簡単に書けるほうが良いかもしれない。

interface I {
hoge();
fuga();
};
class A : implements I {
hoge();
fuga();
};
class B : implements I {
A a : hoge, fuga for I; // インタフェースIのhoge,fugaはaに対応させる
};

アスペクト志向はまだ勉強してないなぁ。

330 ：デフォルトの名無しさん：2005/10/15(土) 13:08:32

>>327
だから継承とかインターフェースとかの技法は
「オブジェクト指向」とは何の関係もないんだよカスが

331 ：デフォルトの名無しさん：2005/10/15(土) 13:37:26

ま、オブジェクト指向はアセンブラでもできる作法論であって、継承とかはただの言語仕様だからな。

332 ：デフォルトの名無しさん：2005/10/16(日) 10:34:16

template じゃダメ?

333 ：329：2005/10/16(日) 18:35:25

>>332
C++のだとすれば・・・
templateはもう１段階の複雑性を導入してる感じで、
バグが出にくい・・・とは相反する気がする。

うまく使えばバグ抑止に貢献するとはいえ、
ちょっと敷居（うまく使うために必要な知識レベル）が高すぎないか？
言語仕様的にバグが出にくいというからには、敷居は低めに設定する必要があると思うし。

334 ：デフォルトの名無しさん：2005/10/16(日) 19:49:43

敷居が高いかねぇ……

335 ：デフォルトの名無しさん：2005/10/17(月) 01:04:25

>>334
発想力のすばらしい人のコードを見るとたぶんそんな事は言わなくなると思う

336 ：デフォルトの名無しさん：2005/10/17(月) 01:09:36

言語かライブラリか？
Javaはスレッドとかシリアライズとかを言語に取り入れていますよね？
synchronizedとか、transientとかがJava構文にあるのが何よりの証拠です。
今までの言語では、それらはライブラリ側の仕事をでした。
一方、C#ではeventやdelegateも言語仕様に含まれています。
どちらがいいんでしょうね？

337 ：デフォルトの名無しさん：2005/10/17(月) 01:14:47

>>335
それはテンプレートに限らないと思うが。

338 ：デフォルトの名無しさん：2005/10/17(月) 02:02:39

a-zより記号が多いからキライ。>template

339 ：デフォルトの名無しさん：2005/10/17(月) 02:30:04

templateはエラーが意味不明ですさまじくデバッグしにくそうなんだが

340 ：デフォルトの名無しさん：2005/10/17(月) 05:26:20

templateベースの頭の逝かれたライブラリは
バグ以前にコンパイルが通らねーからなぁ。
バグ防止にはそりゃいいかもな。

341 ：デフォルトの名無しさん：2005/10/17(月) 11:53:27

>>336
プログラムを書く上で基本的な構造に大きく影響する機能は
言語に取り込んでしまったほうがいいんじゃないかな。
文法上わかりやすく記述できる可能性が高まるし。

342 ：デフォルトの名無しさん：2005/10/17(月) 12:22:33

Schemeがいいよ
記述も簡単でバグで困ったことない

343 ：デフォルトの名無しさん：2005/10/17(月) 12:50:06

>>342
かっこつけてるんじゃないよ

344 ：デフォルトの名無しさん：2005/10/17(月) 12:51:48

>>338
lispとか存在自体が我慢ならないでしょ？ｗ

345 ：デフォルトの名無しさん：2005/10/17(月) 19:57:51

>>344
３３８じゃないが、正直LISPには我慢ならない。
再帰が人間に理解しやすいわけないじゃんか、と。

346 ：デフォルトの名無しさん：2005/10/17(月) 20:34:11

>>345
人間に、ではなくて、お前に、だろ。

347 ：345：2005/10/17(月) 21:27:04

>>346
もちろん再帰をやたら使ってあるコードは、俺にも理解しにくいよ。手続き的な書き方と比べるとね。
LISPのソースって、手続き的に書けるロジックでやたら再帰を使う傾向があるから、
そういう場面を指して言ってる。
とはいえ再帰が必要な場面も当然ある。

・・・とマジレスしてみた。

348 ：デフォルトの名無しさん：2005/10/17(月) 21:29:10

まあ、使う人間の頭の中がバグだらけならどんな言語で作ってもバグだらけになるな

349 ：デフォルトの名無しさん：2005/10/17(月) 21:51:10

LISPは演算子がない故に処理が手に取るようにわかるからなあ。
括弧に目をつぶれば全て同列に扱えるのは利点だな。
しかもC++テンプレート以上の記述能力を備えた超強力なマクロの存在がある。
まさに言語単体としては最強の開発ツールだろうな。

350 ：デフォルトの名無しさん：2005/10/17(月) 22:08:18

Perlで@{${$hashname}{${$keyname}}}とかするのが最凶

351 ：デフォルトの名無しさん：2005/10/17(月) 22:51:21

話はまずヴァルゲイン殿を作ってからだ。

352 ：デフォルトの名無しさん：2005/10/17(月) 22:52:08

ヴァルゲインは作る側の頭にバグがあっても自動的に訂正してくれる。

353 ：デフォルトの名無しさん：2005/10/19(水) 01:47:29

意味不明な単語を出して流れを止めないように・・・　どっかの小説かなんかのようだが

354 ：デフォルトの名無しさん：2005/10/19(水) 01:53:08

そりゃ、メフィストフェレスだって、ロボットだって、小説の中の話だよ。
ライトノベルだからってなめてんじゃねーぞ。

355 ：デフォルトの名無しさん：2005/10/19(水) 02:09:12

>>354
レスはぇぇよ

なめてないから、そんでどうすればバグの出にくい言語仕様になるんですか

356 ：デフォルトの名無しさん：2005/10/19(水) 02:11:47

つまり、どんな頭の悪い人間でも思った通りのことをできるようにしようと思ったら、
人工知能チックになっちゃうね、っていうありきたりの話だよ。

357 ：デフォルトの名無しさん：2005/10/19(水) 02:41:19

で、その人工知能の仕様は？

358 ：デフォルトの名無しさん：2005/10/19(水) 02:43:40

それを含めて、まだ研究途上だろうよ。

359 ：デフォルトの名無しさん：2005/10/19(水) 03:00:19

>>358
だから考えてくれよ。そういうスレなんだから。

人工知能って要はコンパイラ＋インタプリタなんだろ？多少インテリジェントな。

360 ：デフォルトの名無しさん：2005/10/19(水) 21:07:52

人工知能は作るのが難しいからもう人力で良いよ

361 ：デフォルトの名無しさん：2005/10/20(木) 00:21:11

ゆとり教育弊害にあった職に就けないニート達を薄給でバイトとしてこき使えば
人工知能の代わりを果たしてくれるよ。

362 ：デフォルトの名無しさん：2005/10/20(木) 00:23:28

>>361
いや、まじでゆとり教育初期の失敗世代は使えないから無理

363 ：デフォルトの名無しさん：2005/10/20(木) 00:40:27

>>361
天然無能なんて、どこで使えるんだよ

364 ：デフォルトの名無しさん：2005/10/21(金) 23:14:51

範囲チェックを文法に入れてしまうのはどうだろうか？
例えばこんな感じ。
var month: int(1..12);
その変数にアクセスするたびに、範囲チェックが走る。
相当遅くなりそうだけれど、コンパイルオプションで無効にもできる。

365 ：デフォルトの名無しさん：2005/10/21(金) 23:22:15

ちなみに範囲外になると、java.lang.OutOfRangeExceptionが投げられます。
Javaではキャストやポインタチェック、配列の添え字のチェックをしているので、
範囲チェックをするのも悪くないかもしれない。

366 ：デフォルトの名無しさん：2005/10/21(金) 23:28:30

エクセル使えばいいんじゃね？

367 ：デフォルトの名無しさん：2005/10/21(金) 23:35:36

>>365
setter使えばいいんじゃないの？

368 ：デフォルトの名無しさん：2005/10/21(金) 23:41:53

>>364-365
Pascal とかも知らないで、言語仕様を語ってるの？

>>367
ヒント: とかく、プログラマーはさぼりたがる。

369 ：デフォルトの名無しさん：2005/10/21(金) 23:46:24

言語を知ってる知らないレベルの人間は、このスレではしばらくROMれ。

370 ：デフォルトの名無しさん：2005/10/21(金) 23:59:58

ん？
車輪の再発明を指摘しただけだが、なんか気に障ったか？

371 ：デフォルトの名無しさん：2005/10/22(土) 00:29:22

車輪の再発明というか、最近再注目され始めたDBCだろ。
このスレでもがいしゅつ。

372 ：デフォルトの名無しさん：2005/10/22(土) 00:50:21

Javaのアノテーションみたく制約条件を書ける様にすれば良いんじゃね？
テストケースなんかもソースにぶち込めちゃうと良くない？

373 ：デフォルトの名無しさん：2005/10/22(土) 02:50:08

何このスレ
>>1程度の脳味噌はすらばしいな

374 ：デフォルトの名無しさん：2005/10/22(土) 13:37:45

オブジェクト指向とか、エージェント指向とか言って、新たなＢＵＧが目立って来たな。

375 ：デフォルトの名無しさん：2005/10/22(土) 20:52:34

覚えたつもり君たちが使ってますからね

376 ：デフォルトの名無しさん：2005/10/24(月) 09:53:48

>>371
> 車輪の再発明というか、最近再注目され始めたDBCだろ。

遥か昔からPascalに備わっている機能だと何度いｔ（ｒｙ

377 ：デフォルトの名無しさん：2005/10/24(月) 20:24:19

Del厨うざい

378 ：UCLA とか書くなよ。：2005/10/24(月) 21:46:08

>>377
ばか、UCSD に決まってるだろ。

379 ：デフォルトの名無しさん：2005/10/24(月) 21:47:05

だから、範囲チェックじゃなくて制約条件がいいってば

380 ：デフォルトの名無しさん：2005/10/26(水) 14:12:11

UnitTest　メソッドかクラスを付けないとコンパイル通っても実行できない

381 ：デフォルトの名無しさん：2005/10/26(水) 18:57:41

バグを生む主な原因
必要以上に分岐が多く複雑化し、作者の知能のレベルを超えた場合。
だれてもやりがちな例として、n要素nのm状態について場合分けして
n行m列の行列で表される連立方程式並みに複雑化。
俺の解決策
状態をそれぞれクラス化し状態の視点から事象を考えると
プログラムが簡素化する。
なおn,mが小さいときは無意味。

382 ：381：2005/10/26(水) 20:34:48

Syntax Error wwww
n要素n-->n要素

俺の実例として、通信とゲームが別スレッドで動作してるプログラムで、
サーバー通信関係を全て１つのクラスで処理していたの(10万行)を改修し、
ゲーム状態別にクラスを作ってそれぞれに通信イベント処理機能をもたせたところ
異常に簡素化した。(2万行)

383 ：デフォルトの名無しさん：2005/10/26(水) 21:02:31

３８１の知能レベルまで読んだ

384 ：デフォルトの名無しさん：2005/10/26(水) 21:09:17

設計方法論と言語仕様を混同している方がいますね

385 ：デフォルトの名無しさん：2005/10/26(水) 22:30:45

最長不倒関数　って言葉を思い出した

386 ：デフォルトの名無しさん：2005/10/26(水) 22:31:44

アンチパターン　って言葉も思い出した

387 ：デフォルトの名無しさん：2005/10/27(木) 03:14:53

そもそも通信サーバプログラムに対して状態遷移を考慮した作りにしてない時点で糞

388 ：デフォルトの名無しさん：2005/10/27(木) 10:28:36

悪い習慣のプログラミングをしてると、「あ～ま～え～は↑～あ↓～ほ↑～か↓～」って
言ってくれる言語がいいかもしれない

389 ：デフォルトの名無しさん：2005/10/27(木) 16:34:06

おじさま、もうおやすみになって…

390 ：UCLA とか書くなよ。：2005/10/28(金) 00:03:32

>>388
それは、処理系の仕事。

こちらへどうぞ
http://pc8.2ch.net/test/read.cgi/tech/1111363360/1-

391 ：デフォルトの名無しさん：2005/10/28(金) 10:45:05

>>381
そういう考え方の言語なかったけ？

392 ：デフォルトの名無しさん：2005/10/28(金) 11:53:05

プログラミング言語でバグが出易いのは、言語がとても繊細すぎるからだよ。
ほんの1文字間違えてもバグが出る。

もっと冗長でロバストな言語ならバグは少なくなるだろう。
実現したい仕様について、目的から書き始め、
目的については大目標から詳細項目まで、網羅しなければならない。

目的が記載し終わってから、方法　の記述に入るが

393 ：デフォルトの名無しさん：2005/10/29(土) 18:20:20

テキストで書くから綴りミスやらが出るんであって、図形を組み合わせてプログラムすれば良いじゃん

394 ：デフォルトの名無しさん：2005/10/29(土) 20:54:13

>>393
１５角形を書くつもりが１６角形を書いてしまうミスをするかもしれない。

395 ：デフォルトの名無しさん：2005/10/29(土) 23:00:28

>>394
じゃあ色で

396 ：デフォルトの名無しさん：2005/10/29(土) 23:21:17

RGB(0, 0, 0)とRGB(1, 1, 1)の区別ができません。

397 ：デフォルトの名無しさん：2005/10/29(土) 23:52:29

じゃあ匂いで

398 ：デフォルトの名無しさん：2005/10/30(日) 03:08:12

>>397
女の子の香りと秋葉系の臭いの区別は何とか付きます

399 ：デフォルトの名無しさん：2005/10/30(日) 03:44:09

鼻が詰まったらバグに気付かない罠。

400 ：デフォルトの名無しさん：2005/10/30(日) 05:41:19

そして華麗に400

401 ：デフォルトの名無しさん：2005/10/30(日) 06:56:22

バグ捜査犬を育成しよう

402 ：デフォルトの名無しさん：2005/10/30(日) 06:58:49

犬って目がいいの

403 ：デフォルトの名無しさん：2005/10/30(日) 08:00:09

直ぐに無臭のバグが開発されて元の木阿弥

404 ：デフォルトの名無しさん：2005/10/30(日) 08:43:11

prologでちゃんと動くコード書ければバグ率圧倒的に少なくなる気がする

405 ：デフォルトの名無しさん：2005/10/31(月) 00:12:13

>>403
無臭と言う事は、NOPですね？

406 ：デフォルトの名無しさん：2005/10/31(月) 19:43:00

>>404
波平とフネは夫婦、と書き忘れるかもしれない。

・・・Prolog＝磯野家、というイメージが離れない・・・

407 ：デフォルトの名無しさん：2005/11/12(土) 10:00:11

従来：
　// someFunction()はnullを返すかもしれない関数
　SomeClass instance = someFunction();
　// nullかどうかをチェックする必要あり
　if (instance == null)
　　　throw new NullPointerException();

新仕様：null を許すか，許さないかを区別する「null 拒絶識別子」

　// クラス名に ! がついている場合，そのままではコンパイルエラー
　SomeClass! instance = someFunction();

　// "(!null)" キャストの必要がある。
　// 自動で null チェックをし，null が返ってくれば例外発生
　SomeClass! instance = (!null) someFunction();

#　(以上は「Curl」に備わっている機能です)

　// null を許さないので，自動でオブジェクトを生成
　SomeClass! instance;
　SomeClass! instance(10, "string");

408 ：407続き：2005/11/12(土) 10:04:10

　// 「消極的 null 拒絶修飾子」は，言語側で NullObject パターンをサポート
　class SomeClass extends BaseClass {
　　　/** NullObject コンストラクタ */
　　　null() {
　　　　　super(); // BaseClass の NullObject コンストラクタ
　　　　　member_ = "(null)";
　　　　　mayBeNull = null; // メンバは null を許容する
　　　}
　}

　// null が返ってきたら NullObject を得る
　SomeClass? instance = someFunction();
　// キャストは不要だが，とりあえず推奨
　SomeClass? instance = (?null) someFunction();

　// 明示的な NullObject 取得
　SomeClass? instance;
　SomeClass? instance = null;
　BaseClass? base = (SomeClass?) null;

　// NullObject は null と等しい
　if (instance == null) put("I'm a NullObject. " + instance.toString());

　// "!" のクラスへは，キャスト不要
　SomeClass! notNull = mayBeNullObject;
　// こんな事も可能
　SomeClass! notNull = (?null) someFunction();
　SomeClass! notNull = (?null) null; // 明示的に NullObject 取得
　// null と比較するなら，こうする？
　if (notNull == (?null) null) put("I'm a NullObject.");

409 ：デフォルトの名無しさん：2005/11/12(土) 10:18:46

どうしたの？

410 ：デフォルトの名無しさん：2005/11/12(土) 11:11:34

いやー，javaとかにこんな機能があったらいいなーと思って。。。

411 ：デフォルトの名無しさん：2005/11/12(土) 11:47:20

でも、それってNullPo例外出れば初期化忘れだって一発で解る事が、
勝手に初期化される事で想定外の初期化が行われ複雑性が増さない？
こういう機能をつけるならパラメータ付コンストラクタは排除すべきだと思うけど

412 ：デフォルトの名無しさん：2005/11/12(土) 12:53:46

なるほどー。なら new で明示的な初期化は必須ですかの。

　SomeClass! instance; // コンパイルエラー
　SomeClass! instance = new SomeClass();

NullObject のヤシも，null 単体で初期化できるのはバグの元？

　SomeClass! instance = new null SomeClass();
　BaseClass? base = new null SomeClass();

↓これくらいは許せるかな。。。

　SomeClass? instance = new null;

最近，仕事で NullObject パターンに出くわしたり Curl 使ったりで
いろいろ考えさせられてます。
いっそ，こういう事を言語側の方で強制してくれればもっと楽なのかな，とか。。。

413 ：デフォルトの名無しさん：2005/11/12(土) 13:10:57

初期化以外の代入は書かないってことかな。
関数型言語方面だとNullとObjectのいずれか２値もしくは１つを強制できたりするけど。

414 ：デフォルトの名無しさん：2005/11/15(火) 22:56:15

バグの出にくい言語仕様といったらBASICでは？

415 ：デフォルトの名無しさん：2005/11/15(火) 23:13:30

>>414
根拠は？？

416 ：デフォルトの名無しさん：2005/11/15(火) 23:47:53

まあ、インタプリタは支離滅裂な動作はしても、暴走まではしないからなw

417 ：デフォルトの名無しさん：2005/11/16(水) 00:20:32

>>416
ム板からさようなら。もう来なくていいです。

418 ：デフォルトの名無しさん：2005/11/16(水) 02:38:15

この前WinXPが暴走して、カラフルモザイクチカチカ画面が出現。
うあ、BASIC/DOS時代みたい、なつかｽｲー　と、
しばらく見とれてしまたよ。

419 ：デフォルトの名無しさん：2005/11/17(木) 11:43:35

>>418
ウィルスにでも入られたのでは？

420 ：デフォルトの名無しさん：2005/11/17(木) 15:10:34

>>418
そういうのってハード側の問題って気がする

421 ：デフォルトの名無しさん：2005/11/18(金) 01:25:17

こんな言語ならバグ０。

Program ::= Expresstion*
Expresstion ::= Program*

422 ：デフォルトの名無しさん：2005/11/18(金) 01:58:45

Expresstion……

423 ：デフォルトの名無しさん：2005/11/18(金) 02:43:29

ぬるぽを無くすには、静的にnull汚染を閉じこめる。

当然、初期化なしはコンパイルエラー。
nullを返し得る関数は他と区別して、その返値を受ける変数も他と区別。
nullチェックしてからでないと使えなくする。

clean( Object o, map.get#("hoge")) {
//返値がnullでない場合。oに(非null)返値が入る。
} null {
　//返値がnullの場合。ここでoを使うとコンパイルエラー
}

Object o = map.get#("hoge")　//clean文以外でnullが帰り得る関数を使うとコンパイルエラー

424 ：デフォルトの名無しさん：2005/11/18(金) 03:01:48

３０行（文）以上のメソッド、３０メソッド以上のクラスは、コンパルが通らない言語。

425 ：デフォルトの名無しさん：2005/11/18(金) 12:58:10

>>423
あんまりガチガチにするとそれを抜けようと訳ワカメのコード書く奴が出るから
変な実装なら素直にぬるぽが出たほうが良いと思うぞ

426 ：デフォルトの名無しさん：2005/11/18(金) 13:06:10

訳ワカメのコードをコンパイルすると、コンパイラが、
画面から殺人光線を出してコーダーを殺す言語。

427 ：デフォルトの名無しさん：2005/11/18(金) 13:13:37

とにかくコーダーを殺す言語。

428 ：デフォルトの名無しさん：2005/11/18(金) 13:27:32

Haskellつかえばだいたいおｋ。

429 ：デフォルトの名無しさん：2005/11/18(金) 15:20:13

>>428
Haskellだと糞コーダーを半殺しに出来たりするんですか？？？

430 ：デフォルトの名無しさん：2005/11/18(金) 15:58:18

糞コーダーが雲散霧消する

431 ：UCLA とか書くなよ。：2005/11/18(金) 22:16:54

>>423
そんなメンドイことすると処理の流れが追えなくなるぞ。

null ポインタを経由したアクセスは確かにバグの温床
だけど、それを避けるために他のバグが増えるようでは
意味がない。

まだ、null を返そうとしたら例外発生することを強要
した方がましだと思う。

432 ：デフォルトの名無しさん：2005/11/19(土) 01:15:24

なぜ追えなくなる？
nullが返り得るなら対処するのは当たり前だろ。
さらに、NullObjectパターンを支援する仕組みがあればばっちり。

＞まだ、null を返そうとしたら例外発生することを強要
＞した方がましだと思う。

そんなのどうやんだよ。
そもそも、動的じゃ大して意味ねぇだろ。

433 ：デフォルトの名無しさん：2005/11/19(土) 05:40:47

>>432
431じゃないけど
例外は、エラー状態を認知させ、プログラムの死という罰則を用いて
その状態を改めようとします。
すなわち、例外を捕捉しなければアプリケーションの停止という動作が
単純に保障されるわけですよ。
これは大して意味のないことですか？

434 ：デフォルトの名無しさん：2005/11/19(土) 07:18:42

動的にNullバグを捕まえることはtry catch使えば
今の言語仕様でも可能だから大して意味無いって言ってるんでしょ
実行前にNullバグを捕まえときたいって言ってるんじゃねーの？

435 ：デフォルトの名無しさん：2005/11/19(土) 07:31:40

Javaの仕様的にムリ
そういった強制はhaskellとかの関数型言語が得意

436 ：デフォルトの名無しさん：2005/11/19(土) 09:46:43

nullを許すかどうか，てな言語仕様はとても重宝するですよ。
C++の例。
ttp://www.tietew.jp/cppll/archive/819

437 ：デフォルトの名無しさん：2005/11/19(土) 10:30:17

全ての処理は結果を疑え。全ての処理は結果を返せ。
って事で、void 型の返り値の関数定義を抹殺！

438 ：デフォルトの名無しさん：2005/11/19(土) 10:48:11

結果のいらないvoid型はバグの原因にはならないでしょ

戻り値を使う必要無し=NULLポインタが発生しない
なので、むしろバグ抑制に繋がる

439 ：デフォルトの名無しさん：2005/11/19(土) 11:28:44

void* 型の返り値を抹殺というなら話は分かる

440 ：デフォルトの名無しさん：2005/11/19(土) 12:10:37

>>438
戻り値をvoidにして、参照型引数で結果を貰うタイプの場合は？

441 ：UCLA とか書くなよ。：2005/11/19(土) 13:02:07

>>432
From:
Mail: sage
----------------
>>432
> なぜ追えなくなる？

だから実際にコード書いてみなよ。

clean( Object o1, map.get#("hoge1")){
　...
　clean( Object o2, map.get#("hoge2")){
　　...
　　clean( Obejct o3, map.get#("hoge3")){
　　　...
　　} null {
　　　...
　　}
　} null {
　　...
　}
} null {
　...
}

みやすいか？
特に問題なのは、null が帰ってくる時の多くはエラーの場
合だから、o1, o2, o3 で null が帰ってきた場合でもほ
とんど同じエラー処理書いたりすることがあるけど、対応し
にくいだろ？

442 ：>>432 続き：2005/11/19(土) 13:04:42

>>432
> そんなのどうやんだよ。

コンパイラにポインタを返す関数の時は null チェックを
入れるように組み込めばいいだけの話。

> そもそも、動的じゃ大して意味ねぇだろ。

馬鹿かおまえ。
おまえのやつだって、所詮は動的に分岐するかないだろ？
要は、null の時を処理を必ず書くことを強要しているだ
けに過ぎない。
例外版で null に対する処理をきちんと書かせるなら、
catch() 節を書くのを強要すればいいだけの話。

443 ：デフォルトの名無しさん：2005/11/20(日) 01:47:16

それって、ぬるぽが出るのがちょっと早くなるだけじゃん。
バグの解決はちょっと早くなる事はあるかも知れないけど、
バグが出にくくはならない。

>>423は、nullを返して良いメソッドでnullが返った場合の対処が強制される。
nullを返して良いメソッドはどうするんだ？null全面禁止か？
返すべき物がないという状況はどうしても存在すると思うが。
それに対して無理にNullObjectみたいのを返しても無駄だろ。

444 ：デフォルトの名無しさん：2005/11/20(日) 01:48:15

>>423
nullを許すかどうかを明示的に分けるのはいいアイディアですね。
ただ、文法的にはもう少し工夫がいるかも。
多分、constとかと同じようにmodifierみたいにするといいのでは？
例えば以下のような感じです。nullable が新しいキーワードです。
nullable File findFile(File path, String pattern) {
for (File f : path.listFiles()) {
if (match(f, pattern)) return f; // 見つかった
}
return null; // 見つからなかった
}
引数 path, patternはnull不可です。
戻り値はnull可です。だから return null も可能です。
また、nullableな変数をそうでない変数に代入することは可能だけれど、
その逆は不可になります。

445 ：デフォルトの名無しさん：2005/11/20(日) 01:51:15

>javaはC/C++からポインタをなくしたりGCを導入することで
>メモリ管理にまつわるバグを出にくくした。

しかし、一方で参照が残っていつまでもFreeされないオブジェクトによる
メモリ溢れという新たな問題が発生した。

446 ：デフォルトの名無しさん：2005/11/20(日) 01:54:24

あっ、最後のは逆ですね。

447 ：デフォルトの名無しさん：2005/11/20(日) 02:06:41

>>423は、aif else みたいなもんだな。Lispよう知らんけど。
http://community.schemewiki.org/?anaphoric-if

schemeのand-let* みたいにすれば、ネストの問題も収まるんじゃね？

448 ：デフォルトの名無しさん：2005/11/20(日) 02:16:48

構文はこんな感じ？

clean ｛
　receive( Object o1, map.get#("hoge1") ) {
　　...
　}
　　...
receive( Object o2, map.get#("hoge2") : Obejct o3, map.get#("hoge3")){
　　...
　}
} null {
　...
}

449 ：デフォルトの名無しさん：2005/11/20(日) 10:25:17

>>444
その関数の戻り値を代入する型もnullableでなければならないわけだが、
そうするといつまで経ってもnullableでない変数に引き渡せないということにならないか?

450 ：デフォルトの名無しさん：2005/11/20(日) 12:14:04

nullable T を T にキャスト　とかそんな感じのことができればいいんじゃね
キャストできなければキャストエラーで

451 ：デフォルトの名無しさん：2005/11/20(日) 12:20:56

>>444
すでにC#2.0に同じような文法がありました。
書き方は File? のようにハテナがつきます。文法的にはmodifier。
nullableでない変数に入れるときにはキャストが必要のようですね。
http://msdn.microsoft.com/vcsharp/programming/language/

452 ：デフォルトの名無しさん：2005/11/20(日) 12:22:31

null完全廃止でいいべ。’null’つうリテラルも廃止。
返すモンがないことがあるメソッドは、
nullを返す代わりにNoReturnValue extends Throwabｌeを投げる。

453 ：デフォルトの名無しさん：2005/11/20(日) 14:32:38

if (hoge == null) hoge = "hoge";

を

hoge _= "hoge";

って書けるようにするといいと思う。

454 ：デフォルトの名無しさん：2005/11/20(日) 15:03:35

何の意味があるのか意味が分からん。

455 ：デフォルトの名無しさん：2005/11/20(日) 18:48:54

NPE防止のためにとりあえずなんか入れとくって事か？
うわ、超危険人物発見、直ちに抹消せよ

456 ：デフォルトの名無しさん：2005/11/20(日) 18:56:53

NullPointerException
略してんぺ

457 ：デフォルトの名無しさん：2005/11/20(日) 20:32:55

まあ、零番地操作で例外処理を起こすハードウェアにしておけば問題無いだろ。

458 ：デフォルトの名無しさん：2005/11/20(日) 20:39:31

457は素人

459 ：デフォルトの名無しさん：2005/11/20(日) 20:58:18

assertion をサポートすりゃ平気のような気がするんだけどなぁ。
null 返すとか返さないとかも。

…… assert を書き忘れるとバグに繋がるが。

460 ：デフォルトの名無しさん：2005/11/21(月) 01:58:05

静的と動的の違いも解らんのか。
というかそれ以前に、強制と任意の区別も付かんのか。
ネタだと思いたい。

461 ：デフォルトの名無しさん：2005/11/21(月) 09:37:32

>>459
事前表明は実行時でしか機能しません。
ここではそういったことではなく、
どこかでnullを返すよう仕向けられるという時点で設計意図と反するわけで
値型やC++の参照のように原理上、実体＝nullの状態がありえない保障が欲しい、
という話をしているように感じます。
言語仕様的な制約によって実行前に事前にエラーを検出する機構ということです。
そういったサポートを受けたい場合、現状としては高度な型機構を持つ関数型言語を使うか、
表現力が格段に貧弱ですが全てを値渡しで書くしかないでしょう。

462 ：デフォルトの名無しさん：2005/11/21(月) 10:59:05

>>461
nullブロックとnullableどっちの話をしてる？
nullableならまあありかな？と思うけど、nullブロックはちょっとって気がする
それならもっとブロックへnull代入チェックだけじゃない一般化された制約条件みたいなのを記述できる方が良い

463 ：デフォルトの名無しさん：2005/11/21(月) 11:34:40

>>462
たぶんどっちの話でもない気がする・・。

464 ：デフォルトの名無しさん：2005/11/21(月) 12:53:28

だから一般化したら、>>452みたいに非実行時例外だろ。
静的にチェックできる制約はそんなに浮かばないが。

465 ：デフォルトの名無しさん：2005/11/21(月) 13:14:52

452みたいな考え方はありだと思うけど
例外処理はオーバーヘッドが大きくなるからあまり使いたくない
if文でNULLかNotNULLかの場合分けで済むなら例外を投げるまでも無く
コンパイラが自動的に場合分けをすれば済む話だし

466 ：デフォルトの名無しさん：2005/11/21(月) 15:50:54

↓以下、静的にチェックできる制約を考えて列挙

467 ：459：2005/11/21(月) 20:34:24

ぶっちゃけさ、静的にチェックできる『データ型の制約』って、つまり『型』なんだよな。
今ある assertion は動的チェックが多いけど、静的チェックに昇華する気になれば昇華できるのではないかと。

思った。思っただけ。

468 ：デフォルトの名無しさん：2005/11/22(火) 13:45:22

>>467
言ってることはまったくその通り。
どんなことができるのかは型を定義できる言語をひとつふたつ学んでみれば分かる。

例） Haskell, OCaml, SML

469 ：デフォルトの名無しさん：2005/11/23(水) 00:30:18

１文目はそうだが、２文目はただの妄想じゃないのか？
静的チェックに置き換えられるassertなんてどんだけあるんだよ。

470 ：デフォルトの名無しさん：2005/11/23(水) 01:23:11

>444のアイデアは面白いなーと思ったが
Java のような言語に加えるのは大変だろうなと思った。
既存のコードが使えなくなるからね。。。

Java に加わるとすれば、nullable じゃなくて
notnull みたいな逆の意味のキーワードになるじゃろか？

471 ：デフォルトの名無しさん：2005/11/23(水) 01:28:34

わざわざコンパイルが厳しくなる新しいキーワード用意しても
そういうのがまさに必要なPG共が使うわけがねぇ。assert文すら使われてねぇだろ。

472 ：デフォルトの名無しさん：2005/11/23(水) 08:49:48

静的チェックに置き換えられるassertはけっこうあると思うぞ。
超がんがる処理系があったらだけど。
つかプログラマが脳内で静的チェックするからこそassertを書けるんだし。

473 ：デフォルトの名無しさん：2005/11/23(水) 09:41:47

つか実際に使われてんのは>451で出てるC#2.0だけなのか？
# 他の関数型言語は自前でなんとでもできる、てか・・・
ちょと触ってみてぇ。
実際に触ってみれば、利点とか欠点とかも分かりそうなもんだ。

474 ：デフォルトの名無しさん：2005/11/23(水) 11:41:06

>>471
コンパイル条件を厳しくするキーワードを導入しても、だれも使わないというオチになりそうだから、
なにも修飾子をつけないと最も厳しいコンパイル条件となって、修飾子をつけていくことで制限を
外す、という設計思想じゃなきゃだめだな。

そうすると、制約だらけでウザいだけの言語になって、さらに既存の言語の拡張という形はとれなくなるが。

475 ：デフォルトの名無しさん：2005/11/23(水) 11:49:07

>>472　← こいつは、動的・静的を全く解っていない。
現場のPGってやっぱこんなんばっかりか？
それとも、常識を覆すアイデアがあるなら披露汁

>>474
それをいったら、ただの静的型だってウザい。
LispとかJavaScriptとかPythonとか書いてると実感する。

476 ：デフォルトの名無しさん：2005/11/23(水) 14:47:57

コンピュータ側に指示を出す言語じゃなくてPGに指示を出す際にバグの出ない言語が欲しい

477 ：デフォルトの名無しさん：2005/11/23(水) 16:43:06

そういう言語があったとして、理解できる奴は読む側に回らないと思うぞ。

478 ：デフォルトの名無しさん：2005/11/23(水) 16:52:26

仕様書記述言語でもつくるか。

そうすると、仕様書記述言語からプログラミング言語へのトランスレータが開発されて、PG全員解雇。

しかし、仕様書ライタなる新たな職業が誕生し、仕様書デバッグなる工程が必要となる。

479 ：デフォルトの名無しさん：2005/11/23(水) 16:53:35

>>476
言語の問題ではなく、コンパイラのソフトウェアとしての問題。スレ違い

480 ：デフォルトの名無しさん：2005/11/23(水) 17:04:42

形式的仕様記述言語の検索結果約 22,800 件中 1 - 10 件目 (0.20 秒)

481 ：デフォルトの名無しさん：2005/11/23(水) 17:57:57

バグがあるからこそPGの飯の種が尽きない。

482 ：デフォルトの名無しさん：2005/11/23(水) 18:00:06

バグがでなくなったら別の仕事すればいいじゃん。バカ？

483 ：デフォルトの名無しさん：2005/11/23(水) 19:03:28

>>478
そうなったらその仕様書はソースと呼ばれる

484 ：デフォルトの名無しさん：2005/11/23(水) 19:24:51

静的なチェックの方が動的なチェックよりも好ましい
というのはいまいち納得がいかない。
どうやら定説のようだがなんで？

485 ：デフォルトの名無しさん：2005/11/23(水) 19:28:20

静的チェックはコンパイル時に暴かれる。
動的チェックはそのチェックする箇所が実行されないとチェックされない。

たとえばコンパイルと実行で別のコンピュータを使うという事態が考えられる。

486 ：デフォルトの名無しさん：2005/11/23(水) 20:10:42

>>484
> 静的なチェックの方が動的なチェックよりも好ましい

どこの定説だ？

普通に考えて、静的チェックで全部チェックできればそ
れが一番だと思うが。
できねーから、併用するしかないんだろ。

487 ：デフォルトの名無しさん：2005/11/23(水) 20:55:05

>>483
そもそも、仕様書・コード・ドキュメント、この３種は含まれる情報量は本来過不足なく等しいはずで、
単にどの工程で誰が何の目的で作成するかの違いしかない。
要するに三重の無駄。
どれか1個にすべし。

488 ：デフォルトの名無しさん：2005/11/23(水) 20:57:36

わざわざ言われなくても、うちにはコードしかありません＞＜

489 ：デフォルトの名無しさん：2005/11/23(水) 20:59:00

職業プログラマは大変ですねぇ。
僕は趣味でフリーウェア公開してる程度だからとても気軽ですよｗｗ

490 ：デフォルトの名無しさん：2005/11/24(木) 06:20:17

全ての型に文法的に範囲を指定できれば、数値がらみのバグはかなり減ると思うんだが。
型の宣言に値の範囲を強制するというのはどうだろう。
例えば０から１００までの整数を型として定義したら内部で自動的に範囲チェックを掛けてくれる。

int(0-100) val;
val=100; // これはOK
val+=2; // これはNG

もちろん、既存の言語（JavaやC++）でもこういうクラスを作ることは可能だが、手間や実行速度の関係で実際にやるところは少ない。
だが、言語仕様でそうなってれば抵抗無く使えると思うんだが。

491 ：デフォルトの名無しさん：2005/11/24(木) 07:19:17

>>490
pascal系なら、範囲型というのがあるよ。

492 ：デフォルトの名無しさん：2005/11/24(木) 07:31:15

部分範囲型の間違いだ　　Delphiだと　こんな感じ

var x,y:0..99; <----部分範囲型の変数を定義
begin
x:=100; <----------コンパイル時エラー
for x:=low(x) to High(x) do begin
　 {$R+} <-------実行時範囲チェックを有効にすると
　 y:=x+1; <------- 実行させるとこの行で例外が発生
　 Caption:=format('%d',[y]);
end;
end;

493 ：デフォルトの名無しさん：2005/11/24(木) 11:13:51

しかし、大抵は直値代入じゃなくて変数を介した処理中におかしくなるだろ。
結局実行時チェック。バグが出にくい、と言う意味じゃあんま意味なし。
バグったときの原因調査は早くなるだろうけど。

494 ：デフォルトの名無しさん：2005/11/24(木) 17:25:19

>>489
あー・・Vecterとかに登録してある10分で作れるようなプログラムね。いい加減うざいんだよね～検索して引っかかると。

495 ：489：2005/11/24(木) 18:05:11

>>494
趣味とはいえ、さすがにそんな簡単なのは公開してませんよｗ
こないだ作ったのはリバースコネクションに対応した遠隔操作ソフトと、プロセスマネージャから
隠蔽できるキーロガーです。もちろん、どっちも健全な利用しかできないようにしてありますｗ

496 ：デフォルトの名無しさん：2005/11/24(木) 18:05:25

その１０分で出来るプログラムに、１ヶ月掛けて丁寧にバグをたっぷり仕込んで
客から金取るのがおまえね。

497 ：デフォルトの名無しさん：2005/11/24(木) 21:52:23

趣味と職業の違いは、プログラムとしての難易度じゃなくて、職業の場合、
自分が一生使わないプログラムを作るケースが多いってとこだな

498 ：デフォルトの名無しさん：2005/11/25(金) 00:29:57

趣味でPDA用のプログラムを作ったら、
自分が一生使う気の無い機能を要求されたり
入手困難な派生機対応要求されたり。
付き合いがあるし進んで実機デバッグしてくれたから作ったけど、
寧ろ仕事なら拒否もできたかせめて吹っかけることくらいできたのに……

499 ：デフォルトの名無しさん：2005/11/25(金) 01:10:10

>>498
オプソにして、自分で機能追加させれば解決。

500 ：デフォルトの名無しさん：2005/11/25(金) 02:50:31

ひょっとして500

501 ：デフォルトの名無しさん：2005/11/25(金) 18:02:47

>>493
でもたとえば、ＭＡＸ100同士の掛け算なら左辺はＭＡＸ1万じゃないと
おかしいとか、オーバーフローの可能性があるとか、そういう警告は
だせたりしない？

502 ：デフォルトの名無しさん：2005/11/25(金) 18:15:03

それは言語仕様の問題ではなくなってしまうのだよ

503 ：デフォルトの名無しさん：2005/11/25(金) 19:55:57

神はこう言われた
バグあれ
するとバグがうまれた

まで読んだ

504 ：デフォルトの名無しさん：2005/11/25(金) 19:59:01

それなら私は悪魔と共に歩もう。

505 ：デフォルトの名無しさん：2005/11/25(金) 22:25:21

>>502
そんなことはないだろ。
部分範囲型をもってる言語のちょっと賢い処理系なら、
そういうことをやることはたいして難しくない。
逆に、そういう型をもたない言語でやるのは基本的に無理。

ただ、そういう警告が有効かと言うと、かなりウザイと
思われて Off されるのがオチだと思う。

506 ：デフォルトの名無しさん：2005/11/26(土) 00:24:11

>>501
だからそれがコンパイル時に判定できるのは、実質直値同士の場合だけ。
あんま意味なし。

507 ：デフォルトの名無しさん：2005/11/26(土) 00:49:08

>>506
演算子に範囲型を適用すれば実行しないで値を保障できるよ。

int(0..100) operator *(int(0..100) left, int(0..100) right);

例えばこの演算子はかならずint(0..100)の値を返すことが保障される。
内部的に値をクリップするか、例外を投げるのかはその定義次第。

508 ：デフォルトの名無しさん：2005/11/26(土) 00:54:15

例外投げるってそりゃつまり動的チェックじゃん。
バグが出にくいんではなく、バグが分かりやすいだけじゃん。

509 ：デフォルトの名無しさん：2005/11/26(土) 00:55:24

つまり実行時にどうあれ、演算子*の返却型について引き続き int(0..100)という
範囲型が適用され、より限定的に型判定を続行できる。

510 ：デフォルトの名無しさん：2005/11/26(土) 00:57:34

それは解るけど、バグが出にくくなる訳じゃない。
俺は知らないけどPascalにあるの？
で、他の言語が真似しないって事は、やっぱ…。

511 ：デフォルトの名無しさん：2005/11/26(土) 00:57:36

>>508
このメリットがわからなければそれでいいんじゃないの。
不要だって人は不要なんだろうし、別にわからないからって
今のところ馬鹿にされたりしないだろうしね。

512 ：デフォルトの名無しさん：2005/11/26(土) 01:01:14

>>510
Cみたいないい加減な言語に慣れてるから
部分型が扱えるとどういう利点があるかって事が、たぶん想像できないんだろうね。
関数型言語とか一部の強い型付け言語でしか使えないし。

513 ：デフォルトの名無しさん：2005/11/26(土) 01:01:39

型がきちんと一貫してチェックができる事に意味があるんじゃなくて、
ソフトのバグが減ることに意味がある。型は手段。

バグが早期に例外が出て分かりやすくなると言うメリットは認めるよ。
しかし、スレタイにはマッチしないだろ。

514 ：デフォルトの名無しさん：2005/11/26(土) 01:06:31

例えばクラスの継承ツリーも一種の部分型制御なんだけど、
一般的に広まってる言語ではそういう大雑把な視点でしか見えないから
いきなり範囲型といわれても利点がぼやけてくるんだろう。

515 ：デフォルトの名無しさん：2005/11/26(土) 01:08:35

そんなに利点があるならもったいぶらず教えてくれよ。こっちは土方なんだから。
範囲内が保障されてるってのは、現実的な意味ではうそで、範囲外になったら例外になるだけでしょ。
「実行が継続されている場合は」という隠れた前提条件がある。
その前提条件を満たす事こそがバグを出さないということで、
それ自体をサポートしてくれないと意味がない。

解ってないけど、保障、というには、型が演算で本当に閉じていないといけないんじゃないか。
もちろん、整数に範囲を付けるというのじゃ、もともと無理な話。

516 ：デフォルトの名無しさん：2005/11/26(土) 01:18:10

>>515
LISP辺りで「見なす」という訓練をした後に強型付きのMLとかを学習すると
その辺が見えてくるんじゃないかと。
範囲というより集合という言い方の方が近い。

517 ：デフォルトの名無しさん：2005/11/26(土) 01:23:54

部分型と範囲外なら例外、の関係が解らん。
具体例キボン
schemeをほんのちょっとだけやってるし、
Haskellのほんのほんのさわりだけなぞった事はある。

518 ：デフォルトの名無しさん：2005/11/26(土) 01:31:47

もしかして、
int も int(1...100)も同じコードで処理できる事自体が嬉しいと言うことか。
バグが出にくいというのとは関係ないように思うが。

519 ：デフォルトの名無しさん：2005/11/26(土) 01:32:07

例えばintも広い意味では範囲型、集合型の１つと言える。
インテルのIA32に対応したC言語処理系のint型が32bitなのはプロセッサのレジスタの
大きさなどの制限という現実からの反映というだけであり、
「intは32bitで表現できる値の集合を表現した型」と言い換えることができる。
shortなら16bit、charなら8bitの範囲。
これはプロセッサが「たまたま」これらの型を直接表現できるだけで、
もしもintの計算でオーバーフローしたら、ハードウェアがそれを
検出してくれたりするだけのこと。
これ以外の範囲の型があったとしても別に驚くことではないと考えられると思う。

520 ：デフォルトの名無しさん：2005/11/26(土) 01:35:25

>517
schemeわかるならSICPでも読んでみなよ

521 ：デフォルトの名無しさん：2005/11/26(土) 01:36:25

それはそうだね。
ただ、範囲を狭くしてオーバーフローしやすくして嬉しいとは思えない。
intじゃなくてchar使うのは、基本的に単にメモリ節約でしょ。

522 ：デフォルトの名無しさん：2005/11/26(土) 01:39:12

>>518
違うお。
型を限定できて嬉しい、ということだお。

523 ：デフォルトの名無しさん：2005/11/26(土) 01:39:33

和田先生の糞訳本を買うだけ買って読んでない…。
どの辺？
気合い入れてやっぱ読んでみるかな。

524 ：デフォルトの名無しさん：2005/11/26(土) 01:43:25

>>522
それは>>515 >>521で実利を否定してるんだけど…。
どう考えてもオーバーフローしやすくして嬉しいとは思えない。
schemeじゃ逆に32bit制限を外す方向だと思ってるけど。

525 ：デフォルトの名無しさん：2005/11/26(土) 01:43:42

だから数字というまとまりじゃなくて、それ１っこ１っこをみなきゃわからないお
範囲とかじゃなくて、奇数だけ集めた型とか欲しくなったときとか考えるお^^

526 ：デフォルトの名無しさん：2005/11/26(土) 01:56:42

>>523
日本語訳の第２版なら2章だよ。

527 ：デフォルトの名無しさん：2005/11/26(土) 01:57:37

なるほど。
（奇数に閉じてない）割り算を静的に禁止できれば嬉しいかも。
ただ現実には、奇数のような、演算の大半が閉じてるようなのが欲しい場面はほとんど無くて、
欲しいのは、演算で閉じようがない、業務やシステムの都合による制約が保障されてる物。
というのは、単にそれは手続きベースだからなのか？
制約はコードの外部に存在する以上、あまり関係ない気がする。

528 ：デフォルトの名無しさん：2005/11/26(土) 02:09:14

>>526
㌧楠。読んでみるっすよ。
…SICP見つからない。どこいったんだ。サイトで英語読むか…orz

529 ：デフォルトの名無しさん：2005/11/26(土) 02:29:16

まだこのスレに出てきてないみたいなので書いておくと、
バグを減少させる方法としては副作用をなくし、参照透過性を保つというやり方が既にある。
現実的には副作用を一切起こさないということはできないので、
副作用を別の概念としてモデル化し、そのコンテキスト上では
論理的に存在しないものと「見なす」技法が関数型言語で発達している。

530 ：デフォルトの名無しさん：2005/11/26(土) 03:01:01

>>529
それは多分メンドクサイのと実装時に無駄なコードが増えるような気が(直感で)する
その辺はどうなんだい？

531 ：デフォルトの名無しさん：2005/11/26(土) 03:07:11

ノイマン型思考をやめればいいんじゃないかな。
慣れだと思う。

532 ：デフォルトの名無しさん：2005/11/26(土) 11:23:55

もうnullについては

File file = getFile() || new NullFile();

でいいよ。

533 ：デフォルトの名無しさん：2005/11/26(土) 12:52:37

そうするとNullObjectパターンは万能かという話になる。
そして、ダメな場合はどうするのか。

534 ：デフォルトの名無しさん：2005/11/26(土) 15:36:37

バグの出にくいことと
abortしにくいこととは
全く違う概念だからなぁ

535 ：デフォルトの名無しさん：2005/11/26(土) 20:52:43

>>534
同意。その二つを混同しているレスがあったので念の為に同意しておく

536 ：デフォルトの名無しさん：2005/11/26(土) 21:17:43

つうか、ヒューマンエラーを無くすには、人以外がプログラミングに従事すれば良いと思うよ。

537 ：デフォルトの名無しさん：2005/11/26(土) 21:22:28

そりゃ人以外がやればいくらエラー出てもヒューマンエラーじゃないけどなｗ

538 ：デフォルトの名無しさん：2005/11/27(日) 22:01:42

バグをなくすには徹底したテストあるのみ。
レビューなんぞは糞の役にも立たないですよ。

（言語仕様と関係ないか）

539 ：デフォルトの名無しさん：2005/11/27(日) 22:40:20

>>538
そうか？

540 ：デフォルトの名無しさん：2005/11/27(日) 22:47:57

構造上のBUGはテストなんか何万回繰り返しても無駄だったりするんだがな。

541 ：デフォルトの名無しさん：2005/11/27(日) 22:53:28

レビューで８～９割のバグを摘出できるとか言うデータもあるようだがどうにも納得がいかん。
プログラムなんぞ眺めててもバグなんぞ一向に見えてこん。
プログラムなんぞ動かしてなんぼだろ。
みんなレビューやってる？

542 ：デフォルトの名無しさん：2005/11/27(日) 23:05:22

>レビューで８～９割のバグを摘出できるとか言うデータもあるようだが
確か国際事務機会社の調査だったかな
>みんなレビューやってる？
そのような調査結果の有無とは無関係に、
そんな事を工数かけてやって、バグの発見が遅れたら誰も責任取れないからｗ
やっているところは少数派では

543 ：デフォルトの名無しさん：2005/11/28(月) 00:00:35

やってるよ～。
理解の足りてないコーダや詰めの甘いプログラマは自分のコードを説明させると
それだけでぼろぼろバグ(及びその予備軍)を出してくれるし、
その間にそいつの書いたコードを読んでいると潜在的なバグが見えてきたりするし。
尤も、バグを潰すことより保守性を上げることの方が主たる目的なんだけどね。

544 ：デフォルトの名無しさん：2005/11/28(月) 00:45:23

レビューが意味ないなんて言う奴が居るなんて、マジで信じられん。
馬鹿が馬鹿なレビューしてたらそうなのかもしらんが、
レビューしないなんてあり得ない。

545 ：デフォルトの名無しさん：2005/11/28(月) 00:47:34

逆に天才ハッカーばかりでバグなんて元々ほとんどあり得ない、
という夢の世界もあるかもしれんが。

546 ：デフォルトの名無しさん：2005/11/28(月) 00:53:03

テストで出にくいバグ（＝調査が大変なバグ）も見つけられるし、
テストだけだと、ただ「大体動く」だけで、
保守も拡張も出来ないゴミコードがリリースされうる。

547 ：デフォルトの名無しさん：2005/11/28(月) 01:50:00

少なくとも自己レビュー位はやるんじゃないのか？
テストで見直しをちゃんとやりましょうとか小学校で言われただろ

548 ：デフォルトの名無しさん：2005/11/28(月) 01:51:33

引数自体は書き換え不可で
戻値をいっぱい返せるとか

bool foo(int a, string & result)

↓

bool, string foo(int a)

凡ミスが結構減りそう

549 ：デフォルトの名無しさん：2005/11/28(月) 01:54:08

>>548
>>529

でもって、今どきの言語ならそれは常識。

550 ：デフォルトの名無しさん：2005/11/28(月) 02:02:13

単純にリスト返すだけならPerlやRubyでもサポートしてるような。

Cだって構造体返す手があるしね。スタックに巨大オブジェクト作るのは感心しないが。

551 ：デフォルトの名無しさん：2005/11/28(月) 02:06:57

>>549
わかった風な口叩けばいいってもんじゃないよ。
参照透過性を維持するには重大な欠陥を同時に抱えることになる。
それに気づいてない馬鹿なんだろうけど、
今どきの言語のどこにそんな常識があるの？

552 ：デフォルトの名無しさん：2005/11/28(月) 03:03:15

>>550
単純データならどうとでもなるんだけどね。
構造的なデータを副作用なしで効率良く扱うのは先端の関数型言語でも
まだ課題の１つになっている。
関数型言語では特殊化や、修正が起こる部分について結合を弱くすること
によってコストを減らすなど、ある程度の言語のサポートが得られるが、
何の根拠も持たない言語では修正が発生するたび、適切に自力で
コンストラクトするしかない。配列みたいな特性のコンテナデータを修正する
場合は悪夢が待っている。

553 ：デフォルトの名無しさん：2005/11/28(月) 04:07:05

仕様そのものがバグでした・

554 ：デフォルトの名無しさん：2005/11/28(月) 11:43:38

顔を見ればどれくらいバグを出す奴かは推測がつく。

555 ：デフォルトの名無しさん：2005/11/28(月) 17:27:46

御自分よりもバグが少ない人もですか？

556 ：デフォルトの名無しさん：2005/11/29(火) 23:27:20

顔のバグが多い奴ほど、バグは出さない法則

557 ：549：2005/11/30(水) 00:59:26

>>551
常識と書いたのは、参照透過がじゃなくて、
単なる多値返却ならという事なんだが。
…どうやってもそうは読めんな orz

558 ：デフォルトの名無しさん：2005/11/30(水) 02:14:53

プログラマ採用面接で顔だけで判断する香具師はありえんだろ

559 ：デフォルトの名無しさん：2005/11/30(水) 10:09:39

しかし、顔はあらゆる面接の類で重要視される。

560 ：デフォルトの名無しさん：2005/11/30(水) 11:00:35

顔というより話を聞いて日本語の会話が成立しない場合は採用しないな

561 ：デフォルトの名無しさん：2005/11/30(水) 12:29:26

話よりなにより顔だ。

562 ：デフォルトの名無しさん：2005/11/30(水) 12:30:15

顔より味だ

563 ：デフォルトの名無しさん：2005/11/30(水) 13:06:26

>>558
落とす理由が見た目だけで、誰が納得すると思う？

564 ：デフォルトの名無しさん：2005/11/30(水) 13:08:39

>>563
つまりありえんのだからお前の言ってることと同じだと思うが？

565 ：デフォルトの名無しさん：2005/11/30(水) 13:33:37

落とした理由をわざわざ説明する会社があるかボケ。納得も糞もない。

面接は顔が一番重要。これは常識。

566 ：デフォルトの名無しさん：2005/11/30(水) 15:49:44

ブサイクは性格悪いからな。
顔が歪むと心も歪む。

567 ：デフォルトの名無しさん：2005/12/01(木) 00:35:53

顔と言うより、顔つきや態度だな

568 ：デフォルトの名無しさん：2005/12/01(木) 11:13:58

>顔が歪むと心も歪む
逆

569 ：デフォルトの名無しさん：2005/12/01(木) 11:37:00

技術スレが、こういう下らんネタになると伸びるというのが、
ム板のレベルの低さを物語っているな。

570 ：デフォルトの名無しさん：2005/12/01(木) 19:20:54

>>569
みんなもう手持ちのネタが尽きたんだよ。
レベル低いっていうならおまいがネタ振れ。

571 ：デフォルトの名無しさん：2005/12/01(木) 21:09:36

整形するとバグが減るのか

572 ：デフォルトの名無しさん：2005/12/02(金) 01:43:46

確かにインデント整形するのは良いですね

573 ：デフォルトの名無しさん：2005/12/02(金) 12:43:18

>>569
ム板に技術ｽﾚ勃てる奴が阿呆、という事で。

>>572
ｗ

574 ：573：2005/12/02(金) 12:48:28

>>573
>ム板に技術ｽﾚ勃てる奴
…いや合ってるよ！阿呆は俺だろ！

575 ：デフォルトの名無しさん：2005/12/02(金) 13:13:11

逆、裏、対偶が判ってないやつ多すぎ

576 ：デフォルトの名無しさん：2005/12/02(金) 13:28:57

ド・モルガンの法則知らん香具師も大杉

577 ：デフォルトの名無しさん：2005/12/02(金) 15:47:28

久美子も大杉

578 ：デフォルトの名無しさん：2005/12/02(金) 18:29:02

大杉とレスする奴も(ry

579 ：デフォルトの名無しさん：2005/12/02(金) 18:44:55

>>576
お前の脳内にたくさんいそうだね。

580 ：デフォルトの名無しさん：2005/12/02(金) 20:21:41

ド
　モリガン (Morrigan)

【分類】

　ケルト神話（Celtic mythology）

【解説】

　カンムリ烏の姿で血を求め戦場を飛び回る、戦いの女神。
クー・フーリンに惚れるが、相手にされなかったことに腹を立て、
事ある毎に彼の戦いの邪魔をする。その後、命を助けられてからは
彼の味方をし、生き絶えたクー・フーリンの肩にとまった鳥も、彼女だったのだ。

581 ：デフォルトの名無しさん：2005/12/02(金) 20:22:52

相　手　に　さ　れ　な　か　っ　た　こ　と　に　腹　を　立　て、

事　あ　る　毎　に　彼　の　戦　い　の　邪　魔　を　す　る　。

まるでおまえらにそっくりだな

582 ：デフォルトの名無しさん：2005/12/02(金) 21:10:24

神話レベルのツンデレか
すげーなモリガン

583 ：デフォルトの名無しさん：2005/12/02(金) 22:36:11

ちょい、スレの進行も鈍っているようなので初カキコ
ウチは機械化上がりだったんだけど、講義で品質管理についてこうならった

1.目的に合い、実行可能な使用の決定
2.使用目的に合うかの確認
3.製造中はいりうる不良要因の排除
4.安定不変の作業
5.製造から発送までの全行程の全員検査
6.納入後の情報収集とサービス

正直な話、コッチの業界ではみんな話が「1」の段階で止まっている。
頭の中で「動けばコード」みたいなところがあって
現場の中に品質って言うのは1～6でまとまって作る者だって言う意識がない
・IT業界自体ゼンゼン若のはわかるし
・ソフトウェア開発も技術的に若い
・ソフトウェア自体は複雑だっていうのも分かる
でも、ここのスレも思考の対象が「言語仕様」で話が止まっている節がある…
正直、良い品質を作ろうって意味では何処の行程であれ、効果があればよいのだから
少し発想を広げてみたらどうかな？

584 ：デフォルトの名無しさん：2005/12/02(金) 22:53:37

このスレで扱ってるバグは……『３』だけじゃないか？
とくに１と２はバグじゃなくて仕様設計のミスだろう。

585 ：583：2005/12/03(土) 00:04:12

うにゅ、適切な非難だと思う。
個人的には、バグについて広く話せたらその方がありがたいのもあるので、話の枕としては必要なものだと思ったのだ

あと、少し具体的な話なんだけど、バグを上手に排除するには
・バグの入りにくい言語
・注入してしまったバグを事前に発見しやすい言語
・出てきたバグの原因を特定しやすい言語
は消せる者さえ消せれば基本的に等価なので考えるとき狭まらないで欲しい
釈迦に説法だった人も多数なんだろうけど

個人的には、現代の良いところは開発現場ではIDEもセットにして言語を考えるのが当たり前になりつつことなので
IDEと仲良しになる事に糸口がありそうな気がするけど…。

586 ：デフォルトの名無しさん：2005/12/03(土) 01:37:14

少なくとも、自分の書いた日本語の間違いを放置するような香具師が書いたコードは信用ならんと言うことさね。

587 ：デフォルトの名無しさん：2005/12/03(土) 02:14:03

コードレビューはしてますか？

588 ：デフォルトの名無しさん：2005/12/03(土) 10:29:02

コードレビューしやすい言語はバグが発見しやすいか否か

589 ：デフォルトの名無しさん：2005/12/03(土) 10:45:13

>>583
スレタイ嫁アホ

590 ：デフォルトの名無しさん：2005/12/03(土) 12:39:38

>>853
まあ、結局のところ営業がいくらで握ってきたかで品質なんて物は決まるからな
本質的に作る事が出来ない金額で物を作れと言われる場合が殆どだから、
どこを端折るかというと顧客への納品時にばれない品質から端折る

591 ：デフォルトの名無しさん：2005/12/03(土) 14:37:44

>>853の中の人は大変だな

592 ：デフォルトの名無しさん：2005/12/03(土) 16:19:20

>>591
お前今時中の人とか言ってんじゃねぇ。ズレてんだよ。

593 ：デフォルトの名無しさん：2005/12/03(土) 18:06:00

>>592はツンデレ

594 ：デフォルトの名無しさん：2005/12/03(土) 18:34:49

ツンデレももう古いっての。

595 ：デフォルトの名無しさん：2005/12/03(土) 19:40:08

そんじゃデレツン
交際中はデレデレなんだけど結婚した途端ツンツン

596 ：デフォルトの名無しさん：2005/12/03(土) 20:49:06

夫に言えない結婚してから機嫌を損ねる理由ベスト３

１．トイレで用を足すときに便器を汚す(特に小便)
２．紙がなくなっても自分で交換しない
３．ゴミを溜める

597 ：デフォルトの名無しさん：2005/12/04(日) 00:27:22

>>596
俺はそのすべての問題をクリアしているからいい男

598 ：デフォルトの名無しさん：2005/12/10(土) 13:39:54

コードレビューのコストを減らして、コードレビューを支援すると言う意味で、
可読性を残した上で、コード（ステップ数）が短くて済む言語というのは、
重要なのでは。
保守コストも下がるし。

いまだにLOCで仕事を計る馬鹿な会社が敵だが。（うちだ…orz）

599 ：デフォルトの名無しさん：2005/12/10(土) 22:52:47

ステップ数が短くてすむというのはライブラリを充実させるということ？

600 ：デフォルトの名無しさん：2005/12/10(土) 23:42:09

ライブラリに動作実績がなければ意味ない

601 ：デフォルトの名無しさん：2005/12/11(日) 00:03:31

>>599
LISPやPrologだとCOBOLの五分の一くらいの
ステップ数になるといった意味では。

602 ：デフォルトの名無しさん：2005/12/11(日) 04:08:27

ただライブラリを増やすだけじゃなくて
テンプレートやMix-Inのようなパラメタライズ。

603 ：デフォルトの名無しさん：2005/12/11(日) 07:40:48

仕様にバグが無い様にするのが重要

604 ：デフォルトの名無しさん：2005/12/11(日) 10:34:51

○Perl5.8.7（OS依存除くルートにあった.cと.hだけ）
$ wc *.h|grep total
37441 149383 1244389 total
$ wc *.c|grep total
103778 339711 2659553 total
計約140Kstep

○Pugs6.2.10(src以下すべて)
$ find src -type f -exec cat {} >> /tmp/all \;
$ wc /tmp/all
71040 315200 2213460 /tmp/all
計　約71Kstep

■ 結論
　Haskell ＞＞＞＞＞＞＞＞＞＞＞＞＞＞ C

605 ：デフォルトの名無しさん：2005/12/12(月) 06:03:56

>>601
バグの出にくい言語仕様という観点からいえば
LISPやPrologのライブラリを育ててこなかったのは
ソフトウェア界の怠慢。

606 ：デフォルトの名無しさん：2005/12/12(月) 07:58:58

東証のシステムは結局何で書かれていたんでしょうか
COBOLで書かれていたのを最近Javaでリプレースしたとか

607 ：601：2005/12/12(月) 09:13:45

>>605
言語もシステムのライフサイクル通しての総コストの
少ないものが選択されていると考えるべき。
画像処理が必須のWINDOW環境ではこれらの言語が選択
されなかったのも仕方がない。
再び、人工知能技術の応用という方向に焦点が移れば、
変わってくるのでは。

608 ：デフォルトの名無しさん：2005/12/12(月) 09:37:31

画像処理……俺の知っている画像処理とは違うようだ。

609 ：デフォルトの名無しさん：2005/12/12(月) 10:08:31

>>608
すみません。GUIですね。

610 ：デフォルトの名無しさん：2005/12/12(月) 11:35:40

あなたの知ってる画像処理も困難だと思いますが

611 ：デフォルトの名無しさん：2005/12/12(月) 13:17:15

>>606
COBOL＋Cに決まってる
UIに関しては一部Java(Web)も混じってるかも試練

612 ：デフォルトの名無しさん：2005/12/12(月) 13:25:06

>>606
あそこはシステム一本でマッコウ勝負してる
世界でも特有のドケチ取引所と聞いたが
言語の問題じゃない。

613 ：デフォルトの名無しさん：2005/12/12(月) 21:36:52

Prologの場合、オブジェクト指向との相性が
どうなんだろうね。そういう枠組み全くなしでは
今後やっていかれないと思うが。

614 ：デフォルトの名無しさん：2005/12/13(火) 01:49:13

Prolog にバグという概念は成立しない

615 ：デフォルトの名無しさん：2005/12/13(火) 07:37:28

ビットマップを操作するようなプログラムでは
一々TrailStackにpush,popするPrologはとても
採用できない。そういう意味で汎用言語ではない。
ただ、バグの寡多という点では優位であることは
間違いない。言語仕様という観点からはこれ以上の
ものを想定することは難しいと言ってもよい。
やはり、上位層にProlog、下位層にC++というような
切り分けで業務プログラムは開発されるべきだった。

現在のPrologが>>613の問題も含めて、こういう期待に
応えられるかどうかかなり疑問だが・・・。

616 ：デフォルトの名無しさん：2005/12/13(火) 10:23:56

そこでProlog++

617 ：デフォルトの名無しさん：2005/12/13(火) 11:14:03

いやObjective-Prolog

618 ：デフォルトの名無しさん：2005/12/13(火) 13:07:53

>>615
> 言語仕様という観点からはこれ以上の
> ものを想定することは難しいと言ってもよい。

Prologは頭部にたかだか１つの述語しか書けない。
しかし複数の述語が書ける言語が研究レベルでは存在している。
実用化したらPrologは過去の遺物になる。

619 ：デフォルトの名無しさん：2005/12/13(火) 13:33:30

>>618
完全性は・・・。

620 ：デフォルトの名無しさん：2005/12/14(水) 06:58:18

もっと国家ぐるみでＭＬにちからいれればいいじゃん。
国に収めるソフトはすべてＭＬでかかせりゃいいんだよ。

621 ：デフォルトの名無しさん：2005/12/14(水) 09:22:57

>>618
20年以上前に、東北大の野口教授の下でそういう研究が
されていた。計算量が膨大になるんじゃないかってことで
あまり相手にしなかったのだが、何か、画期的な転回でも
あったのだろうか。

622 ：デフォルトの名無しさん：2005/12/14(水) 12:52:06

623 ：デフォルトの名無しさん：2005/12/15(木) 23:46:40

いまさらPrologかよ。メニーコアに向けてKL1だろ

624 ：デフォルトの名無しさん：2005/12/16(金) 00:29:34

メニーコアか。
シングルスレッドでもバグが絶えないというのに
厄介な時代になったものだ。

625 ：デフォルトの名無しさん：2005/12/16(金) 04:16:36

言語で作るからおかしくなるのではないか? これからは
絵で作った方が直感的に分かっていいのではないか?

626 ：デフォルトの名無しさん：2005/12/16(金) 06:03:51

>>625
お約束だけど一応紹介しとく
http://pc8.2ch.net/test/read.cgi/tech/1131442510/

627 ：デフォルトの名無しさん：2005/12/16(金) 06:29:33

>>623
「バグの出にくい」だけに拘ればの話です。

628 ：デフォルトの名無しさん：2005/12/16(金) 16:46:21

>>625
ＮＴＴのオープンハウスだっけ・・あれで図形言語がどうのこうのっていうポスター発表しているやつがいて、
質問に答えられないでオドオドしていたのを思い出した。

629 ：デフォルトの名無しさん：2005/12/16(金) 18:48:13

多分、ビジュアルプログラミングだと思う
日本は結構研究盛んな国らしいけど、本とかいっこうに見かけないんだよね
以前どこかの本で「ビジュアルプログラミングの本を書いてくれないか」
と依頼されたんだけど「使い物になるか専門家の間でもはっきりしていない」ということで、ユーザーインターフェイス全般の話をしていた本があった。

図形化すると全体が良く見渡せるって言うのは大賛成なんだけど
数万行のコードをフローチャートに書き換えた場合、どんな恐ろしいことになるかなんて言うのは、火を見るより明らかなわけで
図形にするならするで、後々コードが巨大化しても見やすいようにする工夫は必要だよね

630 ：デフォルトの名無しさん：2005/12/17(土) 00:15:39

ヴィジュアルだとなんでバグが減るん？
つか、MDAとか関係あるん？

631 ：デフォルトの名無しさん：2005/12/17(土) 00:45:58

つまり図形や色などの視覚的要素を追加することで
幼稚園児並の知能があればレゴブロックで何かをこしらえるように
プログラミングできる。
あるいはPCのパーツをかき集めて自作パソコンを組み立てる様なもの。
規格化された部品を組み合わせるだけでプログラムが完成する。
CUIに対するGUI、すなわちコマンドを叩くよりアイコンをダブルクリックする
ことが好まれるように、名前だけでなくイメージ化することで、
より直感的に脳へ働きかける。

632 ：デフォルトの名無しさん：2005/12/17(土) 03:07:55

まぢで図形化がよくみわたせるとおもってるんでつか？

その前に、#define文使うのやめてくれ。

633 ：デフォルトの名無しさん：2005/12/17(土) 03:52:01

たしかにCUIよりGUIの方がよくみわたせるね。
UNIX文化はさっさと滅んでください。

634 ：デフォルトの名無しさん：2005/12/17(土) 08:13:55

>>633
単位時間にキーボードから入力できる情報量と
用意されたICONの包含する情報量の比較だが、
どんなものか。

635 ：デフォルトの名無しさん：2005/12/17(土) 09:46:58

バッチファイルなら実用的な範囲でGUI化できそう

636 ：デフォルトの名無しさん：2005/12/17(土) 10:17:24

iconが姉歯化していないかの検証も必要。

637 ：デフォルトの名無しさん：2005/12/17(土) 11:23:03

この流れだと、LabViewできる香具師は神?
ドキュメント性が悪いし保守を考えると紙屑なんだけど。

638 ：218：2005/12/17(土) 22:36:14

>ヴィジュアルだとなんでバグが減るん？
だね、基本的に「保守性が高いコードを期待できる」の方の話になってしまう
スレの主旨とズレている気がするね。
まぁ、話題が停滞しているので話を広げるのも悪いとは思わないが…

>まぢで図形化がよくみわたせるとおもってるんでつか？
君がUMLは全く役に立たないと思っているなら、図形化は無意味と言うことなんだろうね

>単位時間にキーボードから入力できる情報量と、用意されたICONの包含する情報量の比較
俺はもう、文字を表示するのに「system.put.println」とか仰々しく18タイプもしたくないんだ！
言語が偏ってる？ゴメソorz

まぁ、Wordとかと違って「コーディング」だけできるUIなら
ショートカット周りの工夫で、解決できるんジャマイカ

639 ：デフォルトの名無しさん：2005/12/17(土) 22:43:44

MAX/MSPもビジュアル言語の範疇かな？
確かに想定外のバグは出にくい気がする。
やれることが限られているからってのもあるけど。

640 ：デフォルトの名無しさん：2005/12/17(土) 23:13:27

やれることが限られているのは日帝が人材を奪ったから。

641 ：デフォルトの名無しさん：2005/12/18(日) 00:12:42

>>638
その言語は補完が提供されるIDEがあるわけで、偏ってるのはお前の脳味噌かと

642 ：デフォルトの名無しさん：2005/12/18(日) 01:14:24

言語が文字の変わりに図形を使用しても、バグが減る理由がない。
見渡しなら、テキストからの変換ツールがあればいい。
プログラミングの裾野を広げるには役立つが、
入力まで図形なんて、まともなプログラミングには生産性低すぎ。

昔だが、Mindstormでプログラミング環境が図形言語だったが、
気の利いた作品はみんなそんな環境は潰して普通にC++でコーディングされたものだった。

643 ：デフォルトの名無しさん：2005/12/18(日) 03:38:47

漏れもプログラムはソースだけで充分だと思う
FlashのActionScriptとかが典型的な例だ

644 ：デフォルトの名無しさん：2005/12/18(日) 03:40:01

↑使いにくいっていう例ね

645 ：デフォルトの名無しさん：2005/12/18(日) 04:14:56

UMLって図形っぽいよな・・・。

646 ：デフォルトの名無しさん：2005/12/19(月) 01:12:35

まあ、UMLじゃ動作保障無いけどな

647 ：デフォルトの名無しさん：2005/12/19(月) 01:24:28

MDAだって、結局UMLだけしょうもなくてテキスト言語併用だろ。

648 ：デフォルトの名無しさん：2005/12/19(月) 04:41:18

全部を図形にする必要はないんじゃない? レベルによって変えればいいと思う。

649 ：デフォルトの名無しさん：2005/12/19(月) 22:46:32

図形的に編集できる言語じゃなくて、コンパイル時に図形情報としてロジックを出力できる言語ならいいんでは？
ロジックの確認にだけ、図形情報を用いる。

650 ：デフォルトの名無しさん：2005/12/20(火) 01:12:13

点（命令）を羅列していくんじゃなくて、ワイアドロジックみたいな
感じでスレッドを線で表現して、それにフローチャートのように
分岐、繰り返しがくっついたようなものってないのかな。
線と線の間にはボックスがあって、それを突っつくと手続き型言語のような
命令文が入ってる。

651 ：デフォルトの名無しさん：2005/12/20(火) 03:57:07

あるよ
めちゃくちゃ開発効率悪いよ

652 ：デフォルトの名無しさん：2005/12/20(火) 11:04:43

業務はマルチスレッドなのに顧客の頭のなかがシングルスレッドだったりする

653 ：デフォルトの名無しさん：2005/12/20(火) 11:15:33

いまさらだがとりあえず言っとく

>>625
なあに、かえって免疫力がつく。

654 ：デフォルトの名無しさん：2005/12/20(火) 11:54:17

ビジネスロジック系のバグ潰しは厳しいなぁ。
大抵のバグはこの辺に仕込まれるんだよなぁ…
仕様、設計とコードの食い違いというかなんというか。

あくまで「プログラム」の範疇でいうなら、
モジュール又はメソッドの入出力の完全検査以外にあるまい。

配列とか配列のようなクラスの中身の型を制限するのは
C++ではテンプレ、Java5ではGenericsで実現済み( ArrayList<String> )だから、
次はサイズの制限も簡単に書けるように…
たとえば ArrayList<String>[0<][1000>=] とか書けるようにして、
それ以上のサイズの配列が渡される可能性がある呼び出し部分はエラーにしちまうとか。

そうすることでありえない値が入力されて発生するようなバグは減ると思うんだが…

655 ：デフォルトの名無しさん：2005/12/20(火) 12:32:48

>>654
std::vectorのat()でできますが。
#operator[]()を使われると制限できないが、そもそもvectorを使ってくれる保証もない。

656 ：デフォルトの名無しさん：2005/12/20(火) 15:21:09

>>651
そこまでは知っているんだけど、実際に触って確かめられないんだよねぇ
誰か窓環境で動くモノとかあったら、配っているところ知らない？

657 ：デフォルトの名無しさん：2005/12/20(火) 15:35:27

>>656
Fの運用監視ツールの運用設計画面なんかどうだ

658 ：デフォルトの名無しさん：2005/12/21(水) 00:00:20

バグを無くすには分岐とループを無くすのが効果的だよ
つまりエクセル最強

659 ：デフォルトの名無しさん：2005/12/21(水) 00:25:49

平面図形だからいけないんだ。これからの時代は立体だ。
で、3Dに見える眼鏡かけてデータグローブで立体になってる
オブジェクトを鷲掴みにして積み上げる。穴開けてねじ止め。
コンクリ固めて鉄筋を通す。

でも耐震強度偽装されて震度5で倒壊。

660 ：デフォルトの名無しさん：2005/12/21(水) 07:57:21

構造化プログラミングなんてキッシュイーターがやることだね。
本物のプログラマはgoto文を恐れずに使う。

661 ：デフォルトの名無しさん：2005/12/21(水) 11:39:07

>>658
エクセルは分岐できるじゃん、ループは怒るけど

662 ：デフォルトの名無しさん：2005/12/21(水) 11:43:21

キッシュおいしいよね

663 ：デフォルトの名無しさん：2005/12/21(水) 12:05:24

日本人じゃねーからナァ
キッシュなんてよー食わねーよな

664 ：デフォルトの名無しさん：2005/12/21(水) 12:32:52

本物のプログラマって、あれ、ただの時代遅れだろ。
古き良き、っていう郷愁なのかも知れないが。

665 ：デフォルトの名無しさん：2005/12/21(水) 16:29:09

>>664
あれは
Fortran -> C++
アセンブラ -> C
Pascal -> Java
と置き換えれば今でも通用するｗ

666 ：デフォルトの名無しさん：2005/12/21(水) 17:48:27

>>659
そういうのはしーぽんに任せる。

667 ：デフォルトの名無しさん：2005/12/21(水) 17:48:45

ソフトウェアの専門職に就くためには資格試験を通らなければなれないようにすべきだ

668 ：デフォルトの名無しさん：2005/12/21(水) 19:02:14

禿銅

669 ：デフォルトの名無しさん：2005/12/21(水) 19:09:52

金が絡むくだらない連中が反対しなければ良かったんだ。

670 ：デフォルトの名無しさん：2005/12/21(水) 20:05:56

>>667
その資格、毎年更新を義務化とかじゃなきゃすぐに意味なくなるぞ。

671 ：デフォルトの名無しさん：2005/12/21(水) 20:28:03

C#とJavaのどっちを試験問題に採用するかでMicrosoftとSunがモメたりするわけですね。

672 ：デフォルトの名無しさん：2005/12/21(水) 20:32:09

>>661
確かに分岐はできるけど、影響範囲は通常そのセルの中だけだと
思うから、非常に限定的だよ。

673 ：デフォルトの名無しさん：2005/12/21(水) 20:49:24

>>671
特定の言語を覚えているかどうかなんて問題外。
まぁ、試験用の独自言語を作ればどこも文句は言わないだろう。

674 ：デフォルトの名無しさん：2005/12/21(水) 21:17:46

>>673
現実的でない試験課題がでる意味の無い資格だとか文句が出ると思うが。

675 ：デフォルトの名無しさん：2005/12/21(水) 21:49:44

そこでLISPですよ

676 ：デフォルトの名無しさん：2005/12/21(水) 22:08:18

>>674
現実的でない？？
貴方の頭は一つの言語しか理解できないようにできているんですか？
現実って何ですか？言語の試験は別でしょう。

677 ：デフォルトの名無しさん：2005/12/21(水) 22:11:12

場合によれば、毎回問題用紙に疑似言語の説明が書いてあって、ある種の問題はそれを参考にして解答するようにすればいいな。

678 ：デフォルトの名無しさん：2005/12/21(水) 23:24:19

>>1
高速に動いて欲しい時にGC発動なんて御免

679 ：デフォルトの名無しさん：2005/12/21(水) 23:54:02

そういう部分はGC走らないようにコードを組むべきでは？

680 ：デフォルトの名無しさん：2005/12/22(木) 02:21:14

>>678
常にGCが動いていれば問題は無い

681 ：デフォルトの名無しさん：2005/12/22(木) 02:29:52

>>678
高速を求めるならアセンブラで書けよ。

682 ：デフォルトの名無しさん：2005/12/22(木) 03:39:56

>>678
Javaってそんなに長々と止まる時あるか?
別スレッドでGCは動きっ放しだから、中々止まらないのでは?

683 ：デフォルトの名無しさん：2005/12/22(木) 06:57:31

>>681
アセンブリな

684 ：デフォルトの名無しさん：2005/12/22(木) 06:58:49

>>682
つまりJavaは常に遅いということか

685 ：デフォルトの名無しさん：2005/12/22(木) 08:47:40

今時GCでギャーギャー言うヤツは素人

686 ：デフォルトの名無しさん：2005/12/22(木) 13:08:58

GCログ見てみろ。一瞬で終わってる。
まれに起きるFULL GCだけ、数秒かかってるけど。
つーかFULL GCってメモリがかなり圧迫されてない限り、ヒマな時しか起きないし。

687 ：デフォルトの名無しさん：2005/12/22(木) 15:43:21

スマートポインタ使えばGCいらなくない？

688 ：デフォルトの名無しさん：2005/12/22(木) 21:19:45

スマートポインタを用いた、参照カウンタ式ガーベジコレクションは
循環参照の問題と、実行スピードの問題がある。

参照カウンタのコストは結構高くつく。特にマルチスレッド環境では。
トータルの処理コストは他のガーベジコレクションに負ける。

689 ：デフォルトの名無しさん：2005/12/22(木) 22:06:43

速度有線の代表の一つといえる様なゲーム開発で、D言語が噂されているように
一定以上大規模なら、バグに悩まされるよりGCに頼った方が良いのが今の時代だよね

正直、後の時代、新しい言語がGC持たないというのはないんじゃないのかな。
汎用言語ならなおさら

690 ：デフォルトの名無しさん：2005/12/22(木) 22:15:02

>>683
どっちでもいいじゃん。
慣用的にアセンブラで通るんだから。

あと、「アセンブリ」っていうんなら、なぜ「アセンブリ言語」と言わないのか不思議なんだよ。

691 ：デフォルトの名無しさん：2005/12/22(木) 23:17:30

……俺、普通に使ってる気がするんだが。

692 ：デフォルトの名無しさん：2005/12/22(木) 23:30:54

アセンブリ言語と言わなかったのは私の落ち度だが、
アセンブラで書けよ
コンパイラで書けよ

違和感あるだろ？

693 ：デフォルトの名無しさん：2005/12/22(木) 23:41:31

JIS用語では「アセンブラ言語」だったな確か。

694 ：デフォルトの名無しさん：2005/12/23(金) 01:20:42

コンパイラ言語

695 ：デフォルトの名無しさん：2005/12/23(金) 07:21:33

実際に書ける香具師なら読み方なんか気にしないぞ

696 ：デフォルトの名無しさん：2005/12/23(金) 08:15:14

「コンパイラ」は直訳すると「翻訳者」なので、アセンブリ言語で
書かれたソースから機械語に変換するアセンブラもコンパイラだと
言える。

697 ：デフォルトの名無しさん：2005/12/23(金) 08:20:41

アセンブラはニモニックと機械語を一対一で置き換えてるだけ
ソースを翻訳している訳ではないのでコンパイラと呼ぶのは不適切

698 ：デフォルトの名無しさん：2005/12/23(金) 08:25:13

単なる翻訳でなく、意訳するのがコンパイラの仕事。
その意訳のためにかえってバグが生じることも稀にあるが、多くの場合恩恵の方が大きい。

699 ：デフォルトの名無しさん：2005/12/23(金) 08:27:58

T図式だとどっちも同じ｡

700 ：デフォルトの名無しさん：2005/12/23(金) 09:08:42

>>698
アセンブラは「単なる翻訳」ですらない。

701 ：デフォルトの名無しさん：2005/12/23(金) 12:46:44

assembling language = 記号言語
assembler language = アセンブラ言語

702 ：デフォルトの名無しさん：2005/12/23(金) 15:14:45

確かに、文字列置換を翻訳と考えるのは無理があったな。

703 ：デフォルトの名無しさん：2005/12/24(土) 02:28:34

com・pile
━━ vt. 資料を集める; 編集［編成］する;

おまえら、知ったか辞めとけって。翻訳て…こんなん高校英語だろｗ

704 ：デフォルトの名無しさん：2005/12/24(土) 04:42:41

中卒が辞書の一行目だけ引っ張って知ったかしてるｗｗｗ

【動-5】《コ》コンパイルする、機械語に翻訳する◆コンパイラー言語（機械コードと一対一に対応しない言語、使いやすい言語）の翻訳。アセンブラ言語（機械コードと一対一に対応する言語、コンピュータ技術者向きの言語）の翻訳はassemble。

705 ：デフォルトの名無しさん：2005/12/24(土) 11:40:16

ついでに言うとcompileを翻訳としておくとinterpretは通訳の意味だから
人にコンパイラとインタプリタの違いを説明するときに都合がよい。

706 ：デフォルトの名無しさん：2005/12/24(土) 11:42:57

まあ、こんぴゅーたーの分野でコンパイラっつったら
翻訳と翻訳してまず間違いないわな

707 ：デフォルトの名無しさん：2005/12/24(土) 18:09:31

OSを基本ソフト、ソースコードを設計図と言い張るくらい微妙だけどな

708 ：デフォルトの名無しさん：2005/12/24(土) 18:59:37

IBM用語

709 ：デフォルトの名無しさん：2005/12/24(土) 21:42:50

鍵盤

710 ：デフォルトの名無しさん：2005/12/25(日) 00:57:01

作譜言語で算帖に算譜を記述して、翻訳系に掛ける。

711 ：デフォルトの名無しさん：2005/12/25(日) 02:59:57

えっと、ゴメン。このスレ終わるかのごとくつまらないこと閃いちゃったんだけど

バグとは「プログラマの意図しない動作をする」ことだから、その原因は
・文法ミスで、意図しない動作を組み込んでしまう
・ライブラリの知識不足で、意図しない動作を組み込んでしまう
なんかの、ヒューマンエラーという事になるんだよね…。
まさしく、プログラミングというのはバグを入れ込む作業ということだよなぁ…

で、話の続きなんだけど。
「バグを入れにくい言語使用」なら、上の単純なミスを減らす言語を考えることなんだよね
>>62　とかも言っているけど。っていうか、2chのお約束でスレの1-100の間で基本的なことなら大体出ている気が…。

712 ：デフォルトの名無しさん：2005/12/25(日) 03:10:09

まず、バグを定義しろ。

713 ：デフォルトの名無しさん：2005/12/25(日) 03:17:54

>>704
その辞書いますぐ棄てた方がいいぞ

　　コンパイラ＝使いやすい言語
www

　　アセンブラ＝コンピュータ技術者向きの言語
禿藁

714 ：デフォルトの名無しさん：2005/12/25(日) 03:25:12

>>711
そういう視点で観れば Python なんかは果てしなくバグを産みやすいな

715 ：711：2005/12/25(日) 06:11:12

自分Python歴３日なので、特に興味本位で、その実例上げて欲しい
多分、Python人口自体も少ないので、Pythonで頻出するバグも良くリストアップされていないと思うし

716 ：デフォルトの名無しさん：2005/12/25(日) 08:08:58

pythonはお約束をみんなが守ることでその辺を解決しようとしてる。
Perlの方が歴史が長い分やばいんじゃね？

717 ：デフォルトの名無しさん：2005/12/25(日) 09:15:21

このスレタイに関していうとD言語とかいい線いってるとおもうね

718 ：デフォルトの名無しさん：2005/12/25(日) 12:12:08

自分にとっては「Cの設計者が不可能か不可能に近いほど困難と判断したテーマ」
を延々と話している様にしか見えないのだけれど

719 ：デフォルトの名無しさん：2005/12/25(日) 15:15:51

>>718
楽しければ別にいいじゃまいか

720 ：デフォルトの名無しさん：2005/12/25(日) 20:18:20

バグを定義しないと話が進まないな

721 ：デフォルトの名無しさん：2005/12/25(日) 20:19:59

定義厨うざい。
バグがどんなものかなんてなんとなくわかんだろ。

722 ：デフォルトの名無しさん：2005/12/25(日) 20:33:06

>>721
おまえが低脳

723 ：デフォルトの名無しさん：2005/12/25(日) 20:33:31

そうか？部分の仕様が既に問題を抱えてる類のバグがあまり語られてないように思うが。
そしておうおうにして、この手のが一番厄介。

724 ：デフォルトの名無しさん：2005/12/25(日) 20:37:16

>>717
D言語にこのスレのどんな機能が盛り込まれてる？

725 ：デフォルトの名無しさん：2005/12/25(日) 23:23:34

華麗にスルーできない機能

726 ：デフォルトの名無しさん：2005/12/26(月) 10:30:28

>>721
なんとなくじゃダメなんだよ
最近の建築偽装問題にも通じるところがあるが、曖昧なところが多ければ多いほど不正を見逃す原因になる

727 ：デフォルトの名無しさん：2005/12/26(月) 11:07:06

>>721
おまえがダメな方の人間だということはよくわかった

728 ：デフォルトの名無しさん：2005/12/26(月) 17:00:53

>>724
表明はCにもあるけど契約プログラミングはDから

729 ：デフォルトの名無しさん：2005/12/26(月) 21:15:52

>>722
>>726
>>727
じゃあお前らがこのスレにふさわしいバグの定義してみろ。
できもしないくせにえらそうなこと言うな。

730 ：デフォルトの名無しさん：2005/12/26(月) 21:18:02

>>729 みたいなのがバグ

731 ：デフォルトの名無しさん：2005/12/26(月) 22:10:14

>>723
その辺はもう少し上級レベルのモデリングとかでなんとかするんじゃないの？

732 ：デフォルトの名無しさん：2005/12/27(火) 19:28:00

言語仕様によってどこまでカバー出来るかな。

733 ：デフォルトの名無しさん：2005/12/28(水) 00:36:48

バグの定義は一応「作成者の意図しない動作をする」でいいんじゃないのかな？
適当に広いし…

>>723
例えば
・if(a==0)と書くつもりがif(a=0)と書く
・引数のスペルをタイプミス
とか、超有名な類かな…
テクニック的にはif(0==a)と書くのが常套手段だけど
正直な話、if文の条件式中じゃ代入は禁止したほうがいいかも

734 ：デフォルトの名無しさん：2005/12/28(水) 01:02:18

最近の言語じゃたいていそうなってない？
条件式の型がboolじゃないとエラー

735 ：デフォルトの名無しさん：2005/12/28(水) 01:47:01

>>733
コードが、そのコードを作成した者の意図しない動作をする、ということか？
でも、そんなのって、通常ほとんどなくないか？

コードから呼び出してる先の動作が理解と違ってたり、
もともと意図に入ってない条件が実は存在したり、
もともとの意図が間違ってる、とかがほとんどだけど。

動的言語だと違うのかな？
あるいは読み返しとかしないのかな？
仕事のコーディングで読み返ししないなんて俺には考えられないけど。

736 ：デフォルトの名無しさん：2005/12/28(水) 02:18:57

>>735
通常はほとんどないから虫であって、ワサワサ湧いてきたら怖いぜ。
まあ、概ねバグってるときはそうなんだけれども。

言語のほうでやれるのは「バカ避け（という語が嫌いな方は
フール・プルーフで）」しかないだろう。

つまりウッカリミスをつぶすGCであったり、
戻り値返すべきところを返さなきゃゴルァするとか、
ぬるぽってたら例外投げて沈めるとか、ｶﾞｯとか。

737 ：デフォルトの名無しさん：2005/12/28(水) 02:51:39

GCはメモリ開放しなくていいから楽、みたいな認識しかほとんどされてないのが不幸。

738 ：デフォルトの名無しさん：2005/12/28(水) 03:46:57

まず人間にバグがあり、それがプログラムに転写されているのだ。
よってバグのないプログラムを作りたいのならまず人間をデバッグ
する必要がある。

739 ：デフォルトの名無しさん：2005/12/28(水) 05:32:35

しかし、あまりアイデアを盛り込まない禁欲的な
言語仕様というのはあるだろう。

740 ：デフォルトの名無しさん：2005/12/28(水) 06:09:33

Pascalとか？
あれはコンパイラ側の都合で手抜き仕様で作られてるからな。
書きにくくて仕方ない。

741 ：デフォルトの名無しさん：2005/12/28(水) 17:28:36

簡潔という意味ならschemeに並ぶモノが思いつかないかな
例え機能を増やしても、バグが出ない様に、出ても分かる様にするのが今の時代の流れだから、長いものには巻かれて構わないと思うよ。
というか、そうでもしないともう現場をのりきれないでしょう…

742 ：デフォルトの名無しさん：2005/12/28(水) 18:37:41

「何でもできるよ」的言語はもう10年以上も昔にダメだしされてるじゃん。

743 ：デフォルトの名無しさん：2005/12/28(水) 18:51:35

なんでも出来る言語＝アセンブラ/機械語

744 ：デフォルトの名無しさん：2005/12/28(水) 19:17:19

確かに、何も出来ない言語にBUGの入る余地は無い罠w

745 ：デフォルトの名無しさん：2005/12/28(水) 20:25:47

みんな、解ってるとは思うが>>743は放置な

746 ：デフォルトの名無しさん：2005/12/28(水) 21:54:47

>>737
詳しく教えてください。

747 ：デフォルトの名無しさん：2005/12/29(木) 06:21:08

遅レスだが、not nullはAda(2005)にあるぞ

748 ：デフォルトの名無しさん：2005/12/29(木) 11:48:54

せっかくNULL返してるのに、判定しないでアクセスしようとするからダメなんだよ。
言語仕様以前のコーディングの問題だからなぁ・・・。

749 ：デフォルトの名無しさん：2005/12/30(金) 00:31:08

バカかお前。お前はなんでもかんでもコーディングの所為にしてろ。もうくんなアホ。

750 ：デフォルトの名無しさん：2005/12/30(金) 00:57:34

ここってネタスレじゃなかったの？

751 ：デフォルトの名無しさん：2005/12/30(金) 14:20:14

ということは、not nullがあるのはC#2.0とAda(2005)だけか。
実用されているとは言い難いな。

>436見て「あ、いいな」とか思ったけど、実務で使うのはもう少し後にするか。。。

752 ：デフォルトの名無しさん：2005/12/30(金) 21:48:05

>>751
【重要】一連のnot nullネタの始まりが>>407である件について

753 ：デフォルトの名無しさん：2005/12/31(土) 18:10:25

だからＭＬとかで書けばいいじゃん。

754 ：デフォルトの名無しさん：2005/12/31(土) 22:24:16

>752
ん？Curlにもnot nullがあるって事かな？
>407に書いてある事がよく分からん。。。

>753
言語を選べれば苦労しないさ。。。

755 ：デフォルトの名無しさん：2005/12/31(土) 23:19:01

>754
>言語を選べれば苦労しないさ。。。

じゃあこんなとこ来るなよｗ

756 ：デフォルトの名無しさん：2005/12/31(土) 23:39:53

すばらしい言語ができて、それが一般的になれば使える可能性あがるし

757 ：739：2006/01/01(日) 00:27:32

>>740
亀レスというか、年が明けてしまった。おめでとうございます。
MLを念頭に置いていました。Pascalというと参照型を採用した
ことが物議を醸した時代ですね。
バグは作法でしか対応できないとは思いません。

758 ：デフォルトの名無しさん：2006/01/02(月) 01:52:44

>>751
C#2.0にnot nullなんてあったっけ？Nullableならあるけど

759 ：デフォルトの名無しさん：2006/01/03(火) 04:33:17

ポインタ廃止しても、ヘッダファイル廃止しても、バグが減るどころか増えてるじゃん

760 ：デフォルトの名無しさん：2006/01/03(火) 04:51:47

>>759
どこにそんな統計情報あんの？

761 ：デフォルトの名無しさん：2006/01/04(水) 20:41:39

C#のNullable…本来nullが格納できない型がnullを格納できるようにする
Adaのnot null…本来nullが格納できる型からnullを禁止する

ちょっとちゃうな。確かに。

762 ：デフォルトの名無しさん：2006/01/07(土) 02:47:27

> 本来nullが格納できる型からnullを禁止する
こうならいいが、

> 本来nullが格納できない型がnullを格納できるようにする
これって、このスレ的には全然意味なくね？

763 ：デフォルトの名無しさん：2006/01/07(土) 02:54:55

>>407-412
いいな。

しかし、こうなるとif文やtry-catch文も式になって欲しいな。ついでに多値代入も。

764 ：デフォルトの名無しさん：2006/01/07(土) 04:52:58

ここまで出てないのが不思議だが、　ダウンキャスト禁止。

765 ：デフォルトの名無しさん：2006/01/07(土) 08:14:24

>>764
dynamic_cast もダメなの？

766 ：デフォルトの名無しさん：2006/01/07(土) 11:37:39

当然だろ。

767 ：デフォルトの名無しさん：2006/01/07(土) 11:42:59

変数名も、型情報として扱うってのはどうだ。
つまり、型は直接使えず、型のインスタンスを使う、みたいな。

何が嬉しいって、変数名はそれが何であるかを表してる。

int sec = hoge();

int hoge() {
…
　return millisec;
}

なんてのを防止できる。

768 ：デフォルトの名無しさん：2006/01/07(土) 12:12:38

> 変数名も、型情報として扱う
名前だけじゃなくて、型にDbCの制約みたいなファセットを設けられるといいな。
null可否も含めて。
型一貫性矛盾はもちろんコンパイルエラー。
ファセットは静的チェックできる物はコンパイル時チェックするし、
そうでないのはキャスト箇所で動的チェック。

Date deadline:<never null, must isWeekday()> = new Date(…);

769 ：デフォルトの名無しさん：2006/01/07(土) 12:23:38

ここに書き込んでる奴らはまずAdaでそれなりの規模のプログラムが書ける様になってから来い

770 ：デフォルトの名無しさん：2006/01/07(土) 18:07:42

>>769

自然数 N が与えられたとき、
1 から N までの数字を N 個並べる組み合わせをすべて
列挙するプログラムは Ada で書くとどうなりますか？

例えば N = 3 のとき
1 2 3
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
となるようにです。
よろしくおながいします。

771 ：デフォルトの名無しさん：2006/01/07(土) 19:03:48

>>770
http://pc8.2ch.net/test/read.cgi/tech/1010492940/

他のスレにも同じようなコト書いて無いか？

772 ：デフォルトの名無しさん：2006/01/07(土) 19:04:54

訂正というか番号付けわすれ
http://pc8.2ch.net/test/read.cgi/tech/1010492940/575

773 ：デフォルトの名無しさん：2006/01/07(土) 20:50:46

http://pc8.2ch.net/test/read.cgi/tech/1073673931/274
ここにもあるぞ

>766
無効だったら例外吐くんだからいいじゃん。

774 ：デフォルトの名無しさん：2006/01/07(土) 20:54:47

>>773
解ってないな。
ダウンキャストが必要になるって事は設計に穴があるって事だ。

だいたい、自分でキャストしておいて実行したらそこで例外発生って事は、それ自体バグだろ。

775 ：デフォルトの名無しさん：2006/01/07(土) 21:15:02

http://kimishima315.hp.infoseek.co.jp/top2.htm

776 ：デフォルトの名無しさん：2006/01/07(土) 21:20:17

http://kimishima315.hp.infoseek.co.jp/top2.htm

777 ：デフォルトの名無しさん：2006/01/07(土) 22:14:34

だから>>769にAdaで書いてみろって言ってんだろ

778 ：デフォルトの名無しさん：2006/01/08(日) 16:54:50

>>774
解ってないな。
ダウンキャストが必要　イコール　設計に穴、という
短絡思考しかできないんだろ。つまりお前の脳味噌に穴が空いているってことだ。

779 ：デフォルトの名無しさん：2006/01/09(月) 02:30:39

> ダウンキャストが必要　イコール　設計に穴、という短絡思考

お前の脳が蜂の巣でないなら、短絡思考でないことを示せよ。

780 ：デフォルトの名無しさん：2006/01/09(月) 02:34:25

gotoがある　イコール　設計に穴

781 ：デフォルトの名無しさん：2006/01/09(月) 04:08:48

やっぱ蜂の巣か。

782 ：デフォルトの名無しさん：2006/01/09(月) 08:20:11

１時間半しか待てんのか。

783 ：デフォルトの名無しさん：2006/01/09(月) 08:38:57

手抜きと省略は違う罠

784 ：773：2006/01/09(月) 14:09:24

>>774
> だいたい、自分でキャストしておいて実行したらそこで例外発生って事は、それ自体バグだろ。
バグなら例外吐くんだし、例外が検知されなければバグは見当たらないってことでしょ？
バグの出にくい言語ってのは、バグを検知しやすいという側面もあるでしょ？

何も否定されて無いように思うんだけど。

785 ：デフォルトの名無しさん：2006/01/09(月) 14:56:28

＞例外が検知されなければバグは見当たらないってことでしょ？
おいおい。基本が解ってないな。

「テストは、バグの存在は証明できるが、バグの非存在は証明出来ない。」
常識ですよ。

だいたい、ダウンキャストに失敗したら例外なんて、今当たり前に普及してるだろ。
そうなるまえに、そんなバグを仕込めないようにすると言ってるの。

786 ：デフォルトの名無しさん：2006/01/09(月) 21:40:04

>>764 >>774 >>778 >>784

オブジェクト指向を止めたら？

787 ：デフォルトの名無しさん：2006/01/09(月) 22:07:35

>>784
> バグの出にくい言語ってのは、バグを検知しやすいと
> いう側面もあるでしょ？

バグの出にくい言語と、バグを (実行時に) 検知し易い
言語 (と言うか、たぶん環境) は、全然違う概念だぞ。

今はまだ一生懸命バグを見つけてつぶして出荷している
のが現状だから、バグを検知し易いシステムと言うのも
今はまだ重要なんだけど、本当はバグを混入できないよ
うな言語や環境があれば面倒なテストなんかせずに出荷
できるでしょ？ここは、そういう夢物語を語り合うス
レだよ。

788 ：デフォルトの名無しさん：2006/01/09(月) 22:29:42

ダウンキャストについては、エラー出さずに実行される方が恐い。

789 ：デフォルトの名無しさん：2006/01/09(月) 22:30:27

いや、どんなけ言語仕様がよくてもテストは必要だろ。

790 ：デフォルトの名無しさん：2006/01/09(月) 23:20:12

>>786　←こいつホームラン級のバカだな

791 ：デフォルトの名無しさん：2006/01/09(月) 23:21:55

>>785
> 「テストは、バグの存在は証明できるが、バグの非存在は証明出来ない。」
知ってるから”見当たらない”という単語を使ったんだが。

> そうなるまえに、そんなバグを仕込めないようにすると言ってるの。
システム記述言語の側面を捨てるということなら、キャスト全部禁止（アップキャストは暗黙の変換）ということで同意できる。

>>787
どの時点のバグの話をしてるの？
要求
分析
設計
コーディング
どこから？
上流設計より上は言語の範疇じゃないように思うんだけど。

792 ：デフォルトの名無しさん：2006/01/09(月) 23:25:30

>>789
そりゃそうだ。だが、いくらテストしてもバグは残る。
なら入らなくて良いバグは最初から入らない方が良いに決まってる。

793 ：デフォルトの名無しさん：2006/01/09(月) 23:27:12

>>791
＞システム記述言語の側面を捨てるということなら、
kwsk

794 ：デフォルトの名無しさん：2006/01/09(月) 23:44:48

現状の静的言語を使ってまともに開発してて残るのは、

> 設計
この辺
> コーディング

に起因するバグがほとんど。ここをどうにか汁。

795 ：デフォルトの名無しさん：2006/01/10(火) 00:03:05

>>789
もちろんバグの混入はコーディング時だけじゃないから
全てのテストが不要になるわけじゃない。

でも、(夢物語だが) 言語仕様がきちんとしてれば、例
えばコーディングミスにかかわるテストは不要になるだ
ろ。願わくば、上流工程でもすばらしいツールが開発さ
れてテストがどんどん不要になればいいんだが…。

>>791
> 知ってるから”見当たらない”という単語を使った

言い訳なのか、話の流れが読めてないのか良くわからん
が、とにかく見苦しい。

> どの時点のバグの話をしてるの？

普通にスレを読んでりゃ、コーディング + 設計少々
ぐらいはわかりそうなもんだが…。

796 ：デフォルトの名無しさん：2006/01/10(火) 00:05:07

>>793
バイナリファイルを扱うときに構造体にキャストするとか、そんな感じじゃね？
ローレベルなの書いてるとキャスト無いとつらいからなあ

797 ：デフォルトの名無しさん：2006/01/10(火) 00:44:50

設計段階で既にBUGってるシステムを検知出来なきゃ、無駄な事さ♪

798 ：デフォルトの名無しさん：2006/01/10(火) 06:44:16

>>795
> が、とにかく見苦しい。
もう一回 >>774,784,785 を読みなよ。

俺も言葉足らずのところがあって >774 の
> ダウンキャストが必要になるって事は設計に穴があるって事だ。
これを否定する気はないということを追加しておく。
ただ、それの必要なレイヤも存在するから、当時の俺の、例外を吐くから構わないという意見になる。

> 普通にスレを読んでりゃ、コーディング + 設計少々
> ぐらいはわかりそうなもんだが…。
アンタだと知ってれば聞かないよ。

799 ：デフォルトの名無しさん：2006/01/10(火) 08:38:51

結局二人が「望んでいるもの」は
一致していたわけだ。

800 ：デフォルトの名無しさん：2006/01/10(火) 13:14:39

>>797
それを検知できる言語仕様を考えよ

801 ：デフォルトの名無しさん：2006/01/10(火) 13:32:12

100%バグと返せ、誤検出率を気にしなけりゃ完璧。
大体バグって言うのは人間共が自分の主観で決めるもので
コンピュータ側からしたら言われたとおりにしているだけ
言った事と思ってたことが違うのを自動的に検出しろっていうのは原理的に不可能だ

バグの検出は結局「思ってた事」を知ってるプログラマにしかできない。
まあ、可読性でも上げとけってこった。

一方で何故バグが生じるかと言えばその言語で可能な操作が多すぎる為だ
その性でプログラマが意図と異なる操作を指示してしまう危険が増える
バグの発生を減らしたきゃ自由度の低い言語を使えって事

バグ排除以外の言語の能力を全て無視すりゃ
究極形は>>2で」結論が出とる

802 ：デフォルトの名無しさん：2006/01/10(火) 14:03:23

プログラマ側でやりたいことは、プログラム上では数学的処理に変換されているけど、ここにバグ検知の見解の限界があると思う
それなら、コードに対して強力なタグ付けを行って、コンパイラ側にプログラマの意図を類推しやすい形でコードを書いてあげられれば、ミスの汲み出しがしやすくなると思うんだけど…

803 ：デフォルトの名無しさん：2006/01/10(火) 14:18:40

自然言語->論理式->ロジックプログラミング
という流れにポイントを絞る時期がきているのではないか。
これなら焦点が合わせやすい。

804 ：デフォルトの名無しさん：2006/01/10(火) 14:26:51

＞言った事と思ってたことが違うのを自動的に検出しろっていうのは原理的に不可能だ

その通り。
だが、言ったことの中の矛盾は検出できる。
それが、バグを出にくくする言語仕様ということ。

ついでにいうと、思ってる事を正確に沢山言わせた方が検出しやすい。
だから、動的言語より静的言語の方がステップが増える傾向がある。

もちろんそれだけじゃなくて
＞まあ、可読性でも上げとけってこった。
こういうようなのも重要だけど。

805 ：デフォルトの名無しさん：2006/01/10(火) 14:29:41

＞それなら、コードに対して強力なタグ付けを行って

プログラミングではプログラマの意図について名前を使う。
>>767-768　が、その具体案ではないか。

806 ：デフォルトの名無しさん：2006/01/10(火) 14:59:38

実行中のメモリやデータ構造が見える開発環境。

807 ：デフォルトの名無しさん：2006/01/10(火) 15:10:06

>言ったことの中の矛盾は検出できる

局所的な矛盾なら検出できる。そしてそれはどんな言語でも文法チェックと言う形で検出する。
だがグローバルな矛盾の検出は全ての入力に対する試験が必要になるので計算量的に不可能。

808 ：デフォルトの名無しさん：2006/01/10(火) 15:16:54

具体的に何を言ってるのかよくわからん。
グローバルに全然別に開発された部分同士で、
型の整合のチェックがなされて矛盾が検出される訳だが。

809 ：デフォルトの名無しさん：2006/01/10(火) 15:24:46

いわゆる実行時エラーの類のこと

810 ：デフォルトの名無しさん：2006/01/10(火) 15:25:18

というか、局所的な矛盾なら検出できる文法というのを披露していただきたい。

811 ：デフォルトの名無しさん：2006/01/10(火) 15:26:54

おまいはコンパイラに怒られたことがないのか?

812 ：デフォルトの名無しさん：2006/01/10(火) 15:28:18

>>809
ますます意味が分からん。
文法チェックなら、コンパイル時に行えるわけだが。
そして、実行時にエラーとして検出できる矛盾とはいかなるものか。

813 ：デフォルトの名無しさん：2006/01/10(火) 15:30:34

>>811
名前間違えとかその手のことか。
それなら、局所もグローバルも関係ないだろうよ。

814 ：デフォルトの名無しさん：2006/01/10(火) 15:32:08

開放したメモリを弄るのは明らかに矛盾だろ？

815 ：デフォルトの名無しさん：2006/01/10(火) 15:38:42

なるほど。しかしそれは型情報があればグローバルも局所もないな。
というか、いまどきGC前提だろ。

816 ：デフォルトの名無しさん：2006/01/10(火) 15:45:18

いや、局所とかグローバルといっても変数の話をしてるわけじゃないから
文単位での矛盾か文の集合体としての矛盾かというだけ
それに、GCは開放し忘れを防ぐだけで開放してしまった物を弄ることには何の影響もないぞ

817 ：デフォルトの名無しさん：2006/01/10(火) 15:48:18

おいおい、まだ弄れる物を解放するGCなんて怖くて使えんぞｗ

818 ：デフォルトの名無しさん：2006/01/10(火) 15:52:49

ふむ、今時はメモリの開放は全てGC任せが前提なのか

819 ：デフォルトの名無しさん：2006/01/10(火) 22:30:34

>>816
GC 使うならそうでないとあまりありがたくないだろ。

820 ：819：2006/01/10(火) 22:31:26

すまん間違えた >>816 じゃなくて、>>818 だった。

821 ：デフォルトの名無しさん：2006/01/10(火) 23:03:33

プログラムは書いた通りに動いてるだけ

822 ：デフォルトの名無しさん：2006/01/10(火) 23:07:57

それをバグとするか仕様と考えるかは使う方の受け止め方次第

昔からのエンジニアはプログラムには元々バグがあるものだと
織り込み済みでそれを回避した使い方を考えて使うもの

最近の風潮（バグ＝罪悪説）は素人が参加しだしたために広まったもの

823 ：デフォルトの名無しさん：2006/01/10(火) 23:15:26

「バグではありません。仕様です」つう釈明を流行らせたところもあるねｗ
昔では考えられない釈明だけど。
そしてユーザーは「回避した使い方を考えて使う」わけだ

824 ：デフォルトの名無しさん：2006/01/10(火) 23:18:29

馬鹿電波が紛れ込んできたな

825 ：デフォルトの名無しさん：2006/01/11(水) 00:01:36

>>824
俺はこのスレの初めから最後までバカしかいないと思ってる。

826 ：デフォルトの名無しさん：2006/01/11(水) 00:39:27

バカの出にくい言語仕様を考える。

827 ：デフォルトの名無しさん：2006/01/11(水) 00:43:21

それよりも、バカなことをしたくならない言語仕様を考えてくれ。

828 ：デフォルトの名無しさん：2006/01/11(水) 01:38:48

>>767-768は、膨らませて練り上げると、いい機能になりそうなんだが、どうだろう。

広い範囲での整合性のチェックといったら、結局、
型情報のチェックしかない。（ほかにあったらあげて欲しい）

なら、型情報をリッチにしていろいろチェックできるというのは、筋が通ってると思うのだが。

829 ：デフォルトの名無しさん：2006/01/11(水) 01:43:08

つtypedef

830 ：デフォルトの名無しさん：2006/01/11(水) 01:47:29

もちろんそれもいいんだけどね。もっとリッチに行こうぜ。

831 ：デフォルトの名無しさん：2006/01/11(水) 01:55:50

つstruct, class

832 ：デフォルトの名無しさん：2006/01/11(水) 02:02:15

強制ハンガリアンかよ。

833 ：デフォルトの名無しさん：2006/01/11(水) 02:05:16

error 10 行 : i はハンガリアン表記ではありません .
error 11 行 : j はハンガリアン表記ではありません .
error 12 行 : k はハンガリアン表記ではありません .

834 ：デフォルトの名無しさん：2006/01/11(水) 02:13:34

つまり、木は森に
エラーは大量のエラーに
バグは大量のバグに隠せと言うことだな
うむ、実に奥が深い

835 ：デフォルトの名無しさん：2006/01/11(水) 02:37:04

反ガリ案は違うと思うが…

836 ：デフォルトの名無しさん：2006/01/11(水) 07:19:29

概出かもしれんが次元解析してくれるとうれしい

837 ：デフォルトの名無しさん：2006/01/11(水) 08:37:25

変数に値をセットしたあと、その変数を参照することなく、
更に値をセットしうるときや、関数を抜けちゃいうるようなとき、
コンパイルエラーになるってのはどうだ。

838 ：デフォルトの名無しさん：2006/01/11(水) 11:05:21

賢いIDEなら、コーディング段階でそれぐらい出来そうだな。

839 ：デフォルトの名無しさん：2006/01/11(水) 11:17:10

>>837
そんなWARNINGを出すコンパイラは普通にある希ガス

840 ：デフォルトの名無しさん：2006/01/11(水) 11:19:29

-Wallをつけないでコンパイルする奴は馬鹿。

841 ：デフォルトの名無しさん：2006/01/11(水) 11:35:04

>>836
それって型推論とか違うのかな。よくわかってないけど。
あと、>>767-768みたいに、同じdoubleでも、ちゃんと型作って、さらに型同士の関係を定義しておくと。

ただ、金融の一部を除いて、業務のシステムではあんまり出番がなさそうな…。

842 ：デフォルトの名無しさん：2006/01/11(水) 12:28:45

>>841
角度をラジアンに変換するときに
rad = Θ * PI / 180;
見たいな計算をする訳だけど、
うっかり
rad = Θ * 180 / PI;
と書くと次元エラーを警告

843 ：デフォルトの名無しさん：2006/01/11(水) 12:29:11

ハンガリばかり連呼しているバカは一生コーダやってろよ。お前らは研究者に向いていない。

844 ：デフォルトの名無しさん：2006/01/11(水) 13:07:34

>>842
だからそれ、型チェックでしょ
180の型が度で。

845 ：デフォルトの名無しさん：2006/01/11(水) 13:25:47

>>842
次元解析でそれがエラーになるのはおかしい。
radian=degree*定数。
>>844の言ってることもずれてる。

846 ：デフォルトの名無しさん：2006/01/11(水) 14:17:51

だから、ここでのPIの型をradにしろって話だろ

847 ：デフォルトの名無しさん：2006/01/11(水) 21:15:16

俺はバグが見つけやすい言語であればいいじゃんと思ってたんだが
実行前に見つけるの前提？ってことはスクリプト系はここではスレ違いってことでいい？

848 ：デフォルトの名無しさん：2006/01/11(水) 22:14:28

「バグの出にくい」と逝っている以上は
実行中に見つかるのは手遅れだろ？

849 ：デフォルトの名無しさん：2006/01/11(水) 22:28:33

こうですか？わかりません（＞＜）
class rad{
double operater/(rad);
rad operater*(rad);
rad operater+(rad);
rad operater-(rad);
}

850 ：デフォルトの名無しさん：2006/01/12(木) 00:31:24

>class rad{
いいと思います。（radの掛け算はないと思うし、割り算はdoubleになると思うけど）
でも単位ごとにクラスができてたら、言語自体が収集つかなくなってしまいます。
実装レベルではπをdoubleとしながらも、コンパイラに「πはradianだよ」という
情報を与えてエラーにできないでしょうか？

851 ：デフォルトの名無しさん：2006/01/12(木) 00:46:21

だからclass定義するんじゃねえか馬鹿

852 ：デフォルトの名無しさん：2006/01/12(木) 05:02:12

>>850
> でも単位ごとにクラスができてたら、言語自体が収集つかなくなってしまいます
はぁぁぁぁ？？？？？

853 ：デフォルトの名無しさん：2006/01/12(木) 05:41:44

radrad operater*(rad);

854 ：デフォルトの名無しさん：2006/01/12(木) 05:45:37

double sin(rad);
double cos(rad);
double exp(rad);
とか定義しておかないといけない気が巣

855 ：デフォルトの名無しさん：2006/01/12(木) 08:48:51

>>851
新しい言語仕様を考えるスレで、なぜ既存言語仕様の話を？

>>852
もっとラジカルに型をバンバン楽に作らせろって事だと。

typedef double radian;
typedef double degree;
const <radian / digree> PI = およそ３ ;

double rad = Θ * PI / 180; //コンパイルエラー
radian rad = Θ * PI / 180; //コンパイルエラー
radian rad = Θ * PI / (digree)180; //OK.

double rad = Θ * 180 / PI; //コンパイルエラー
radian rad = Θ * (digree)180 / PI; //コンパイルエラー

こんな感じ。

856 ：デフォルトの名無しさん：2006/01/12(木) 08:57:36

あ、なんで　
const <radian/digree> PI なんだ。　
const degree PIでよか。

857 ：デフォルトの名無しさん：2006/01/12(木) 11:03:07

まとめ
結局C++もまともに使えていない馬鹿が
俺がバグを出すのは俺のせいじゃない言語が悪いんだ
という妄想で暴れてるｽﾚ

858 ：デフォルトの名無しさん：2006/01/12(木) 11:56:35

世の中の95%のPGがC++をまともに使えない件について

で、いちいちclassつくらんで次元解析する方法よろ

859 ：デフォルトの名無しさん：2006/01/12(木) 12:31:42

言語仕様を考えるスレなんだから、C++ とかの既存の言語でどうするかはスレ違いだよな

要するに次元は型情報で、次元解析は型検査なんだから
次元を何らかの形で記述できる文法にすれば十分可能な希ガス

double とか int とかの既存の型に次元情報を追加する形になるのかな

dimdecl m; // 単位次元の宣言
dimdecl kg;
dimdecl s;
dimdef N = kg * m / (s * s);

double<kg> mass = 5.656 kg;
double<m/s/s> acc = 7.878 m/s/s;
double<N> f = mass * acc;

Google電卓が参考になるかも

860 ：デフォルトの名無しさん：2006/01/12(木) 12:47:59

結局、前の方でも言われているけど
「強力な型チェック機能」が重要になるっていうのが一つの結論になるのかな？

個人的意見として、Javaみたいな堅苦しくって仰々しい言語になると返って使いすらいので
Lispやrubyみたいな手に馴染む感じを失わない文応でもあって欲しいんだけど

861 ：850：2006/01/12(木) 12:48:40

>>文応
文法…orz

862 ：デフォルトの名無しさん：2006/01/12(木) 13:01:25

「総称」などの概念は、生まれた経緯(理由)は違うものの
よりバグの出にくい言語仕様って言うことができますよね？
（↑の場合は型キャストのミスというバグからの開放）

863 ：デフォルトの名無しさん：2006/01/12(木) 13:10:46

>>859
それやりだすと補助単位が面倒だから補助単位は言語仕様に盛り込めないかね。
後は単位変換とか。
dimdecl g;
dimsubunit k = 1000;
double<g> mass = 5.656 <k>g;

dimdecl m;
dimdecl ft = 0.3048 m;
double<m> height = 10000 ft;

864 ：デフォルトの名無しさん：2006/01/12(木) 13:27:40

確かにGenericプログラミングとかパラメタライズトクラスとか近いな、というか、同じなのか？
たしかGenericプログラミングスレがあった気がするが

865 ：デフォルトの名無しさん：2006/01/12(木) 17:14:43

お前ら、ジェネリックとかアスペクト、アジャックスとかetc..のしょうもない言葉に釣られすぎ。
もっと骨のある奴はいないのか。

866 ：デフォルトの名無しさん：2006/01/12(木) 17:16:43

>>865
禿同
カルト的でマジキモイ

867 ：デフォルトの名無しさん：2006/01/12(木) 18:50:48

LISP クロージャ　無名関数　構造体ベース志向

868 ：デフォルトの名無しさん：2006/01/12(木) 18:56:19

土方を骨のある奴とは、モノは言い様だな

869 ：デフォルトの名無しさん：2006/01/12(木) 19:07:56

>>868
このスレは研究者のためのスレだけど、コーダには現場の意見を言ってもらいたい。
言語という具体的な道具を考える段階では、机上だけで考えても仕方がないのだから。

870 ：デフォルトの名無しさん：2006/01/12(木) 19:08:54

逆に言うと、コーダは机上の話には口を出すな、という事でもある。

871 ：デフォルトの名無しさん：2006/01/12(木) 19:09:24

JavaScriptのように文字列を関数に出来れば速くならないか？

872 ：デフォルトの名無しさん：2006/01/12(木) 19:55:43

トレース出力にコードとデータが混在していればクロスリファレンスしたくなくなる　デバッグに役立つじゃん

873 ：デフォルトの名無しさん：2006/01/12(木) 20:18:35

コーダーの立場でいえば、ライブラリや情報やIDEも考慮して、一番早くできればいい
バグがでないとしても、コーディング終わるのに他の100倍時間のかかる言語はいらない

874 ：デフォルトの名無しさん：2006/01/12(木) 20:41:40

Perl6を2/100ヶ月で作れるんならお前の意見はもっともだ

875 ：デフォルトの名無しさん：2006/01/12(木) 20:56:35

並列処理を記述するのにforkやpthreadを記述した時点で負けだと思う

876 ：デフォルトの名無しさん：2006/01/12(木) 20:58:47

>>871
Java6あたりでコンパイラ起動、リフレクション、動的バイトコードロード駆使すれば出来る

877 ：これで、厨度が計れるかも。：2006/01/12(木) 21:44:16

>>873
だったら、何倍までならいいの？

878 ：デフォルトの名無しさん：2006/01/12(木) 21:52:28

ツリービューとかツリー構造のデータを記述するのに向いた言語って無い?
多くの人がここで躓くんだ
Perlベースのモジュールで見たって5－6種類はもうすでにあるんじゃないかなと思うぐらいすごい
そしてＸＭＬ

879 ：デフォルトの名無しさん：2006/01/12(木) 21:57:46

>>876
今のJavaでもテキストファイルに吐いて、javacでコンパイルして、クラスローダで読み込めばできるよ。

880 ：デフォルトの名無しさん：2006/01/12(木) 22:18:26

ビジュアルプログラミング言語みたいなのはないのかな
マウスだけで全部プログラミングできてしまうようなやつ。

881 ：デフォルトの名無しさん：2006/01/12(木) 22:21:17

>>877
上手く説明する自信ない　すまん

コーディングオンリーで完成させる時間（バグでない言語）
コーディング＋修正で完成させる時間（バグ出る言語）

この2つを比較して上の方の時間の方が短ければよい

882 ：デフォルトの名無しさん：2006/01/12(木) 22:25:38

>>881
100倍で十分じゃん

883 ：デフォルトの名無しさん：2006/01/12(木) 22:27:28

>>875
Work-Time C

884 ：デフォルトの名無しさん：2006/01/12(木) 22:38:44

>>880 ⇒ >>637
て言うか、ビジュアルだからバグらないわけじゃないんだ
が、定期的にこの意見が出てくるな。

>>881
コーディングにかかる時間と、＋修正にかかる時間の大
体の比率もわからんのか？

まあ、完成までの時間しか考慮に入れていない時点で厨と
いうのはバレバレだがな。

885 ：デフォルトの名無しさん：2006/01/12(木) 22:40:28

>>880
操作をマウスで行うのか表示を画像形式にするのか良くわかんない PAD図で表示するとか構文解析図を表示するとか

886 ：デフォルトの名無しさん：2006/01/12(木) 22:46:06

>まあ、完成までの時間しか考慮に入れていない時点で厨と
>いうのはバレバレだがな。

他に何の時間を考慮しろと?

887 ：デフォルトの名無しさん：2006/01/12(木) 22:56:09

>>1 >>11 循環参照するポインタのリファレンスカウントがゼロにならないバグを組み込んだ

888 ：デフォルトの名無しさん：2006/01/12(木) 22:58:36

Ver1完成させるまでにかかる時間が少ないといいね
Ver1からVer1.1完成させるまでの時間が少ないといいね
Ver1.1からVer1.3完成させるまでの時間が少ないといいね？

他に何の時間を考慮するんだ？

889 ：デフォルトの名無しさん：2006/01/12(木) 23:01:30

Ver1からVer1.2に上がるまでの間に人が辞めてかないといいね
まず鬱になる　これ基本

890 ：デフォルトの名無しさん：2006/01/12(木) 23:27:02

MKSA<1,0,-2,0> 加速度[m/s^2]
こんな感じにすると単位同士の演算も簡単になりそうな気がします。

891 ：デフォルトの名無しさん：2006/01/12(木) 23:40:38

>>886, >>888
「作ったら、ハイおしまい。」のアマチュアさんは、楽
でいいね。

892 ：デフォルトの名無しさん：2006/01/12(木) 23:43:58

>>879
今のJavaじゃjavacが使えるかどうかやそもそもjavacでよいのかが分からない

893 ：デフォルトの名無しさん：2006/01/12(木) 23:52:15

D言語マンセースレはここですか?
しょっちゅうインデックス外の配列にアクセスしてしまいArray Bounds Error起こしてしまうんですが何とかならないでしょうか?

894 ：デフォルトの名無しさん：2006/01/13(金) 00:01:25

つiterator

895 ：デフォルトの名無しさん：2006/01/13(金) 00:03:04

言語を進化させるより人間の脳を進化させた方が早い

896 ：デフォルトの名無しさん：2006/01/13(金) 00:06:11

>>891
いやだからアマチュアさんにプロは何の時間を考慮するのか教えてくれと

897 ：デフォルトの名無しさん：2006/01/13(金) 00:09:11

鶏を割くに焉ぞ牛刀を用いん　>894

898 ：デフォルトの名無しさん：2006/01/13(金) 00:09:20

作業時間 Χ(x) 眠る時間 f(x) とすると　Χ(x)+f(x)=24時間を満たす最小の　f(x) を得られる x が求められる公式がこのスレで欲しい

899 ：デフォルトの名無しさん：2006/01/13(金) 00:31:43

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

900 ：デフォルトの名無しさん：2006/01/13(金) 00:35:57

>>886
稼動後のメンテナンス

901 ：デフォルトの名無しさん：2006/01/13(金) 00:38:27

>>893
配列を使わない。

>>896
売ってからのバグ対策とかは思いつかないの？
マジな話、バグ "0" になるならソフトによっては
100倍でも十分なケースもあるよ。

902 ：デフォルトの名無しさん：2006/01/13(金) 00:38:38

この流れで関係なくね？それ。
それとも改修のこと？

903 ：デフォルトの名無しさん：2006/01/13(金) 00:47:20

マニュアル作る時間じゃないのか？

904 ：デフォルトの名無しさん：2006/01/13(金) 00:49:06

>>901-902
パッチ配布(M$ではサービスパックなどとぬかしておるが)に掛かる時間のことだな

905 ：デフォルトの名無しさん：2006/01/13(金) 00:51:42

>>904
いまだにパッチの当たってないPCがわんさかあることを考えると、
時間は無限大とも言えるかも知れないですね。

906 ：デフォルトの名無しさん：2006/01/13(金) 00:53:28

>>903
マニュアルにバグがあるケースも多いですね。

907 ：デフォルトの名無しさん：2006/01/13(金) 00:54:23

ソフトの改変でセキュリティが弱くならない言語仕様を考えたくなる

908 ：デフォルトの名無しさん：2006/01/13(金) 00:57:49

>>879
今のJavaじゃなくてもリフレクションや動的バイトコード生成＆ロードだったら 1.1 の頃からできるし。

909 ：デフォルトの名無しさん：2006/01/13(金) 01:05:04

１．InputStreamでクラスファイルのバイナリを読む
２．ClassLoader#defineClass()にバイナリを渡してロード
３．Class#forName→Class#newInstance()→Class#getMethod→Method#invoke
って漢字か

910 ：デフォルトの名無しさん：2006/01/13(金) 01:15:05

完成までの時間しか考慮にいれないのは当たり前の話だ

保守作業が発生したとき、保守作業の完成までの時間が少ないといい
バージョンアップが発生すれば、バージョンアップの完成までの時間が少ないといい

完成までのコーディングと保守のコーディングを何で分けて考えるの？
同じコーディングじゃん　それで最終的に早い方がいいってだけじゃん？

911 ：デフォルトの名無しさん：2006/01/13(金) 01:20:32

保守の発生回数が少ないのが一番良いね

912 ：デフォルトの名無しさん：2006/01/13(金) 01:22:02

完成までを100として、保守が1でも1000回というのと、
保守も100だけど2～3回で収束するというのとを比べると、
どっちがいいかっていう問題ですね。

913 ：デフォルトの名無しさん：2006/01/13(金) 01:24:41

次スレタイトル

保守のしやすい言語仕様を考える

914 ：デフォルトの名無しさん：2006/01/13(金) 01:26:00

ファームウェアで保守なんて考えたら罰が当たるよ

915 ：デフォルトの名無しさん：2006/01/13(金) 10:11:56

開発速度が100倍になったら保守という作業は消滅する
って聞いた事がある

916 ：デフォルトの名無しさん：2006/01/13(金) 12:31:05

だから、３０歳過ぎて、社会の政治的な要因に太刀打ちできるような
立場になってからもデザインパターンみたいな一技術で重宝されるような
人物に対して「逃げ道だよな」って言ってるの。２０代の奴がやりたくてもできないような
ところで自分をアピールする術を持ってないのかって。
中堅者のやることっていったら、２０代の奴が仕事をしやすいように、いろいろと根回しすることだろ？
年齢重ねても、やることが２０代の延長だったら会社に居る意味ねーよ。
スパゲティコードだとか、その辺は中堅社員が口出すことじゃねーって。
むしろ、２０代の奴が気付いて、中堅社員に意見をＵＰして、それから中堅社員が根回しするのが理想。
要は、いい歳こいて低レベルな話してんじゃねーよって。もっと抽象的になれってことだ。

917 ：デフォルトの名無しさん：2006/01/13(金) 14:06:04

狂牛病を直すソフトウェアとか
鶏インフルエンザを予防するのとか

918 ：デフォルトの名無しさん：2006/01/13(金) 14:10:50

高齢化社会に備えて自宅で園芸をするための言語仕様とか考えといたほうがいいかも

919 ：デフォルトの名無しさん：2006/01/13(金) 14:15:41

路上駐車を防ぐ言語もいる
非常に重要　交通の妨げになる

920 ：デフォルトの名無しさん：2006/01/13(金) 21:19:11

女に縁のなかった俺がモテまくりでウハウハな言語ｷﾎﾞﾝﾇ

921 ：デフォルトの名無しさん：2006/01/13(金) 21:32:35

だから、３０歳過ぎて、狂牛病に太刀打ちできるような
立場になってからも鶏インフルエンザみたいな一予防で重宝されるような
高齢化社会に備えて「自宅で園芸をするための言語仕様とか考えといたほうがいいかも」って言ってるの。路上駐車の奴がやりたくてもできないような
ところで自分をアピールする術を持ってないのかって。
中堅者のやることっていったら、路上駐車の奴が交通の妨げをしやすいように、いろいろと根回しすることだろ？
年齢重ねても、やることが路上駐車の延長だったら会社に居る意味ねーよ。
防ぐ言語もいるだとか、その辺は非常に重要じゃねーって。
むしろ、路上駐車の奴が気付いて、女に縁のなかった俺がモテまくりで、それから中堅社員が根回しするのが理想。
要は、いい歳こいてウハウハな言語ｷﾎﾞﾝﾇじゃねーよって。もっと抽象的になれってことだ。

922 ：デフォルトの名無しさん：2006/01/13(金) 23:42:56

枯れたライブラリが山盛りで、
自分でほとんどコーディング量が少なくて済めばバグも出にくい

923 ：デフォルトの名無しさん：2006/01/14(土) 00:16:22

>>917-920
Javaならすべて実現できます。

924 ：デフォルトの名無しさん：2006/01/14(土) 00:22:21

もうこのスレ削除していいでしょや？
バカしかいない。このバカ！クズ！

925 ：デフォルトの名無しさん：2006/01/14(土) 00:26:57

まあ、コーディング量が少なければバグも少ないのはわ
かるが、たった２行でも日本語として？？な書き込みし
かできない >>922 がいる限り、バグは無くならないで
あろう。

926 ：デフォルトの名無しさん：2006/01/14(土) 00:28:02

コーディング量以前の問題だって早く気づけ、このバカ！クズ！

927 ：デフォルトの名無しさん：2006/01/14(土) 00:29:54

人間が作るからバグができる。
つまりバグがある言語は作った人の血が通っている。って昔の偉い人が・・・・

928 ：デフォルトの名無しさん：2006/01/14(土) 00:30:52

まぁ、あれだよ　2割8割。お前ら8割

929 ：デフォルトの名無しさん：2006/01/14(土) 00:38:31

お前らはね、努力もせずにバグがでるーバグがでるーとか言ってるのね。
そして、自分のバカさ加減を言語とか、コーディングスタイルとか、スパゲッティコードのせいにしたりするわけ。
～スタイルだの、～指向だの、といろいろいいわけを考える訳ね。
もうこのバカ！クズ！

930 ：デフォルトの名無しさん：2006/01/14(土) 00:44:16

山本インセンティブでどう？

931 ：デフォルトの名無しさん：2006/01/14(土) 01:16:35

>>929
馬鹿って言うやつが馬鹿だってママが言ってたお

932 ：デフォルトの名無しさん：2006/01/14(土) 02:25:13

>>914
でも最近は、ネットでファーム配信することも増えてきたよ。

>>915
意味不明？

933 ：デフォルトの名無しさん：2006/01/14(土) 02:40:06

1000だったらバグの出にくいｵﾊﾟｲうｐ

934 ：デフォルトの名無しさん：2006/01/14(土) 05:48:37

935 ：デフォルトの名無しさん：2006/01/14(土) 09:22:11

おれもそう思った

936 ：デフォルトの名無しさん：2006/01/14(土) 10:45:59

副詞ひとつでガタガタ言ってんなカス共
くやしかったら、まともなネタ振ってみろ

937 ：デフォルトの名無しさん：2006/01/14(土) 12:03:14

>>936
お前なんか超スーパーめっちゃ

938 ：デフォルトの名無しさん：2006/01/14(土) 14:43:06

>>922 が「副詞ひとつ」の問題とはとても思えない件について

939 ：デフォルトの名無しさん：2006/01/14(土) 15:53:46

>>936
プログラムだったら、カンマ一つで何百万ドルか吹っ飛
んだ例もありますが？
て言うか、>>922 のどの副詞を修正したら >>922 が
まともな日本語なるんだ？

940 ：デフォルトの名無しさん：2006/01/14(土) 21:37:40

ウチはスペースひとつで一億円ぶっ飛びましたが何か？

941 ：デフォルトの名無しさん：2006/01/14(土) 22:11:16

ウチはバグ数千個でプロジェクトぶっ飛びましたが何か？

942 ：デフォルトの名無しさん：2006/01/15(日) 00:53:04

害虫のバグ一つで今日のデートが吹っ飛びましたが何か。

943 ：デフォルトの名無しさん：2006/01/15(日) 00:54:58

ウチはカウントダウン一回でロケットがぶっ飛びましたがなんか

944 ：デフォルトの名無しさん：2006/01/15(日) 00:58:28

関数型言語は、マイナーながらそれなりに市民権を得つつある。
しかし、論理型言語や並列型言語がそうでないのは何故だろう。

945 ：デフォルトの名無しさん：2006/01/15(日) 01:00:27

STLやらBoost.LambdaからC++ユーザを関数型へ染めたのだ、とデムパしてみるテス。

946 ：デフォルトの名無しさん：2006/01/15(日) 01:09:12

味噌を作るための言語仕様はありますか？

947 ：デフォルトの名無しさん：2006/01/15(日) 01:18:23

>>945
確かに、C++というメジャー言語が、多数のユーザに
関数型の考え方を見せ付けたってのはあるだろうね。

948 ：デフォルトの名無しさん：2006/01/15(日) 01:38:15

味噌の地域性を表現する表象言語が必要になりました　どんな文法がよろしいでしょうか　記号体系でも結構です

949 ：デフォルトの名無しさん：2006/01/15(日) 01:45:04

なぜってね　いつも食べているものじゃないと安全管理に対する意欲が沸かないでしょ

950 ：デフォルトの名無しさん：2006/01/15(日) 02:01:07

>>948
成分表じゃダメか？

951 ：デフォルトの名無しさん：2006/01/15(日) 03:01:36

なんか、低脳荒らしがゴミレス量産してるな。

952 ：デフォルトの名無しさん：2006/01/15(日) 03:23:10

次スレはマ板だな

953 ：915：2006/01/15(日) 09:27:22

>>932
「新規開発のほうが保守するより安上がりになる」という意味さ

954 ：デフォルトの名無しさん：2006/01/15(日) 11:44:01

>>953
母体が 100倍以上あったら駄目ジャン。
つーか、テストの工数とか考えてないだろ。

955 ：デフォルトの名無しさん：2006/01/15(日) 13:02:13

M$は数年毎にOSを新規開発してるからなぁ
ある意味脅威的だよなぁ

956 ：デフォルトの名無しさん：2006/01/15(日) 13:08:53

新規開発じゃねぇだろ。単なる改造拡張。

957 ：デフォルトの名無しさん：2006/01/15(日) 13:53:53

>>955
うわぁ頭悪いねキミ

958 ：デフォルトの名無しさん：2006/01/15(日) 14:07:19

リッチな型情報を容易に使えること、というのが結論ということでよろしいか。
あと、馬鹿ネタ書いてる奴はマ板行け。

959 ：デフォルトの名無しさん：2006/01/15(日) 14:11:54

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

960 ：デフォルトの名無しさん：2006/01/15(日) 14:20:08

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

961 ：デフォルトの名無しさん：2006/01/15(日) 14:35:02

>>943
並列型言語は、
プログラムの潜在的な並列性を完璧に検出・並列実行できるため、
逆に処理記述の粒度が細かくて、面倒というか、コードが長くなるらしい。
あと、関数型言語以上に発想というか考え方の違いが大きいとか。
いや、全然解ってないんだけど。
解ってる人ツッコミよろ

962 ：訂正：2006/01/15(日) 14:35:31

>>944
並列型言語は、
プログラムの潜在的な並列性を完璧に検出・並列実行できるため、
逆に処理記述の粒度が細かくて、面倒というか、コードが長くなるらしい。
あと、関数型言語以上に発想というか考え方の違いが大きいとか。
いや、全然解ってないんだけど。
解ってる人ツッコミよろ

963 ：デフォルトの名無しさん：2006/01/15(日) 15:27:34

豆腐を４ラインで製造する言語仕様を考える

964 ：デフォルトの名無しさん：2006/01/15(日) 16:28:55

コンパイラ言語逝ってよし

965 ：デフォルトの名無しさん：2006/01/15(日) 16:32:17

もうお父さん型無しだよ。

966 ：デフォルトの名無しさん：2006/01/15(日) 16:37:10

カタナシヨーグルト

967 ：デフォルトの名無しさん：2006/01/15(日) 17:02:42

話について行けない低脳ゴミPGが暴れてるな。
お前が早く業界から去ることが、お前も含めたみんなのためになる。

968 ：デフォルトの名無しさん：2006/01/15(日) 17:59:08

オマエモナー

969 ：デフォルトの名無しさん：2006/01/15(日) 18:35:02

Visual D

970 ：デフォルトの名無しさん：2006/01/15(日) 19:12:05

Borland D Builder

971 ：デフォルトの名無しさん：2006/01/15(日) 19:57:06

>>962
KLICの場合は書き手の感覚では、Prologと同じレベル。
バックトラックしないのだからまったく別の言語だが、
とくに粒度が細かいとか、コードが長くなることはない。
面倒臭さに至ってはこちらの方が楽。

972 ：デフォルトの名無しさん：2006/01/15(日) 21:37:53

>>958
>>960
型無し言語スレ、最初はあほかと思ったけど、途中議論始めてからは良スレ化したね

>どうせなら、型と双璧をなす(俺主観)、「ロール」も
>チェック対象になるような言語が欲しいです。
何この俺

973 ：デフォルトの名無しさん：2006/01/16(月) 00:50:26

>>960
結局、何年も前のスレと、似たようなこと話してるんだね、このスレ。
このスレ独自の話題もない訳じゃないが。

974 ：デフォルトの名無しさん：2006/01/16(月) 00:52:30

その「ロール」って、上の方にあった、名前を型の属性にするってのと似てるな。

975 ：デフォルトの名無しさん：2006/01/16(月) 01:33:43

c言語で
　　　　int a = 1;
　　　　int b = 3;
　　　　float c = a / b;
で計算すると c=0 になってしまいます。
　　　　float c = 1.0 * a / b;
だとちゃんと c = 0.3333 になります。
これって結構バグの温床になっているような気がするけど、
うまい回避方法ってありますか？
これはもうc言語特有の問題なんでしょうか。

976 ：デフォルトの名無しさん：2006/01/16(月) 01:44:14

float c = (float)a / b;

977 ：デフォルトの名無しさん：2006/01/16(月) 02:23:34

>>975みたいな言語仕様を理解できてない馬鹿が存在すると、
いくら言語が優れていても意味なー

978 ：デフォルトの名無しさん：2006/01/16(月) 02:46:37

>>975
コンパイラが警告だしてくれりゃそれでいいんじゃない？

979 ：デフォルトの名無しさん：2006/01/16(月) 09:07:53

>>973
言語の進化は、私たちが驚くに値するほどゆっくりしか進行していないと言うのが解釈として正しいと思うよ。
何処でも同じ話題が出ると言うことは、欲しい言語の方向は結構決まっているみたいなんだけどね。

980 ：デフォルトの名無しさん：2006/01/16(月) 09:26:58

>>979
発想が何かに縛られているということではないかな。

981 ：デフォルトの名無しさん：2006/01/16(月) 11:59:16

単に大昔に通り過ぎてすでに実装されている機能を知らない馬鹿共が
車輪の再発明さえもできずにそれを夢見てるだけ

982 ：デフォルトの名無しさん：2006/01/16(月) 12:36:09

無知と馬鹿は違うし、車輪の再発明くらいはしてるだろ。

983 ：デフォルトの名無しさん：2006/01/16(月) 12:42:09

それよりもどうやって車輪で毎日食べる豆腐が作れるかだ　これでバグの温床が減るはず

984 ：デフォルトの名無しさん：2006/01/16(月) 13:42:59

車輪だって４つ再発明すれば車ができぞ。

985 ：デフォルトの名無しさん：2006/01/16(月) 13:45:15

>>984 実際最近の電気自動車の車輪は車輪の再発明に近いものがある

986 ：デフォルトの名無しさん：2006/01/16(月) 15:03:36

>975
型の厳格な言語としてそれは当たり前の動作。
暗黙に変換される事こそバグの元だろ。

987 ：デフォルトの名無しさん：2006/01/16(月) 15:32:47

>>986
1.0 を掛けると陽に移行したことになるの？

988 ：デフォルトの名無しさん：2006/01/16(月) 15:44:31

私は頭の硬いCOBOLで、Cは解らないのですが、
>>975はそういう思い付きの言語仕様に対する
疑義のように読み取れますが。

989 ：デフォルトの名無しさん：2006/01/16(月) 15:46:38

assert( typeof(a).float == YES ); みたいなの付けてチェックするとか

990 ：デフォルトの名無しさん：2006/01/16(月) 15:50:10

Java流に書けばアサーションていうの必要ないんじゃん

991 ：デフォルトの名無しさん：2006/01/16(月) 17:21:00

>>982
無知の自覚が無いのが馬鹿
そしてこのスレには明らかに馬鹿が居る

992 ：デフォルトの名無しさん：2006/01/16(月) 17:36:58

強力な型付けがバグを減らすために重要って事が一つの結論なら

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

既存の言語への拡張でも良いし、新しい言語を提案するのも良いし
うまく行けば後の世に繋がる

993 ：デフォルトの名無しさん：2006/01/16(月) 17:57:28

Adaで書け

994 ：デフォルトの名無しさん：2006/01/16(月) 18:50:37

　　　　　　　　　　　　　　　　　　　　　　　　いっそのこと論理型言語に乗り換えろ

995 ：975：2006/01/16(月) 19:26:25

レスどうもです

>>976
だからそういう(float)のようなものを付けなければいけないことに
気づかないことが多いのではないかと思ったんです。

>>978
コンパイラはgccですが、警告は出してくれませんでした。

>>986
そんなもんですかねー？確かにこの計算で0を答えとして求めたい
という場合もあるかもしれないな。

>>988
そうです。いちいち型キャストとか考えなければいけないのは
めんどくさいと思ったので。

>>989-990
そんな方法があるんですか。勉強してみます。

>>991
ぎ、ギクッ

996 ：デフォルトの名無しさん：2006/01/16(月) 19:54:11

暗黙のキャストが邪悪なのは常識
しかし，利便性と天秤にかけた結果敢えて残されている
利便性を捨てて避けたければTypedefで見かけ上別の型にしてしまえば良いだけの話
>>975は型が理解できていない初心者というだけ

997 ：デフォルトの名無しさん：2006/01/16(月) 19:59:07

演算子の記号をもう一つ付け加えられればいいかと思うけどね

[int][浮動小数除算をする記号][int] が (float)[int]/(float)[int]) を糖衣したもの

の様な

…VBだと逆のは有るんだけどな

998 ：デフォルトの名無しさん：2006/01/16(月) 20:11:02

int が何バイトか OS 毎に違うのではなく、言語で固定、ってのはどうよ。

999 ：デフォルトの名無しさん：2006/01/16(月) 20:13:48

うっほっほー　やっほっほっほ　うっほほーい

1000 ：デフォルトの名無しさん：2006/01/16(月) 20:17:10

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

http://pc8.2ch.net/test/read.cgi/tech/1137410170/

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。