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

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

最近のjava人気について part15

1 :仕様書無しさん:04/03/18 22:18
thread.setPart(BigDecimal.valueOf(14).add(BigDecimal.valueOf(1)));

前スレ
http://pc.2ch.net/test/read.cgi/prog/1079278426/l50

2 :最凶VB厨房:04/03/18 22:19
駄スレ

3 :仕様書無しさん:04/03/18 22:20
BigDecimal.valueOf(1).add(BigDecimal.valueOf(3).multiply(BigDecimal.valueOf(5)))

4 :仕様書無しさん:04/03/18 22:21
可読性を向上させた書き方
BigDecimal(1).add(BigDecimal(3).multiply(BigDecimal(5)))


5 :仕様書無しさん:04/03/18 22:24
>>4の意味。

1 + 3 × 5 = 16

6 :仕様書無しさん:04/03/18 22:24
演算子再定義最高!

7 :仕様書無しさん:04/03/18 22:25
>>4
それはオブジェクト指向をなめた書き方

8 :仕様書無しさん:04/03/18 22:26
>>1
C#なら

this.Part = 14 + 1;

9 :仕様書無しさん:04/03/18 22:26
>>3
だからそんなことやるんだったら

BigDecimal result = new BigDecimal(Byte.toString(1 + 3 * 5));

にしたほうがいいっていってるんだが。



10 :仕様書無しさん:04/03/18 22:27
>>6
演算子の定義方法がいい加減なやつがいなければ最高と言い切れるわけだが
世の中そうもいかない


11 :仕様書無しさん:04/03/18 22:28
>>9
はぁ? int result=1+3*5 の方がいいに決まっているだろ?
なんのためにBigDecimal使っていると思ってんだ?
ただの例だろ。

12 :仕様書無しさん:04/03/18 22:28
Javaのコーダにいい加減なやつがいなければ最高と言い切れるわけだが
世の中そうもいかない

13 :仕様書無しさん:04/03/18 22:30
>>8
Javaなら(partがBigDecimal型のとき)
this.part = new BigDecimal(Byte.toString(15));
または

this.part = BigDecimal.valueOf(15);

しかし少数を扱うときはBigDecimal#valueOf()は使用禁止!

this.part = new BigDecimal("10.00001");
とすること!
理由はドキュメントを読めばわかる

14 :仕様書無しさん:04/03/18 22:30
1+3*5-7を>>3の方法で書いたら
ものすごく可読性悪くなるなw

15 :仕様書無しさん:04/03/18 22:31
>>13
つまり馬鹿には使えない複雑怪奇仕様ということですね?

16 :仕様書無しさん:04/03/18 22:31
>>11
はぁ? byte result=16 の方がいいに決まっているだろ?
なんのためにBigDecimal使っていると思ってんだ?
ただの例だろ。

C厨やC#厨はホントに浅はかだねw

17 :仕様書無しさん:04/03/18 22:32
というか、お前ら、桁数が一桁や二桁の整数をあつかうくらいで
BigDecimalを使うって発想が馬鹿なんだYO!

これだからC厨やC#厨は

18 :仕様書無しさん:04/03/18 22:32
相変わらず話がループしてるなw

19 :仕様書無しさん:04/03/18 22:32
>>16 最後の一行は蛇足。

20 :仕様書無しさん:04/03/18 22:33
>>17
Javaは遅いからBigDecimalなんて使っちゃダメだよね

21 :仕様書無しさん:04/03/18 22:35
そうだった。Javaは誰が使っても遅いんだった

22 :仕様書無しさん:04/03/18 22:35
金融系の基幹業務に何処の馬の骨が作ったのかもわからんような物が使えるかよ(藁

23 :仕様書無しさん:04/03/18 22:36
やっぱりCOBOL最強

24 :仕様書無しさん:04/03/18 22:36
というかねえ整数を使うときはBigDecimalなんかではなく
BigIntegerをつかうんだけどねえ。
それどころか桁数1,2桁しかないもので計算結果がintどころかshortやbyteを
超えないものにわざわざBigDecimalやBigIntegerを使おうとする
C厨やC#厨って頭悪いんじゃねえ野か?

それをわかっちゃいない馬鹿がC厨やC#厨には多いことか。

25 :仕様書無しさん:04/03/18 22:37
>>17
こまかい揚げ足鳥うるせーよ。
これで満足だろ? えっ?

BigDecimal.valueOf(100000000000000000000).add(BigDecimal.valueOf(300000000000000000000).multiply(BigDecimal.valueOf(500000000000000000000)))


26 :仕様書無しさん:04/03/18 22:37
>>22
そうそう、確かにCやC++やC#は金融系には向いてないな(藁

27 :仕様書無しさん:04/03/18 22:38
>>25
ウザイC#厨やC厨やCOBOL厨をへこませるための作戦だったわけだが


28 :仕様書無しさん:04/03/18 22:38
>>24
君。さっきからなんでC厨やC#厨のせいにしようとしているのかな?
アンチはCやC#しか使えないとか妄想でもしているのかな?

29 :仕様書無しさん:04/03/18 22:38
>>27
見事に失敗したわけだがw

30 :仕様書無しさん:04/03/18 22:38
javaじゃCOBOLに勝てないもんな。

31 :仕様書無しさん:04/03/18 22:39
>>25
> >>17
> こまかい揚げ足鳥うるせーよ。
> これで満足だろ? えっ?
>
> BigDecimal.valueOf(100000000000000000000).add(BigDecimal.valueOf(300000000000000000000).multiply(BigDecimal.valueOf(500000000000000000000)))
>

はいおまえボーーーーつ(没)。
プログラマ失格。おまえは首です。JavaプログラマからC++プログラマに格下げされました
給料も1割減ります。

32 :仕様書無しさん:04/03/18 22:39
>>25
コンパイルエラー(ワラ
やっぱりJava使えねーな(ハゲワラ

33 :仕様書無しさん:04/03/18 22:40
>>30
プ 負け犬COBOLerの遠吠え

34 :仕様書無しさん:04/03/18 22:40
>>31
誰もお前の意見なんか聞いていないw

35 :仕様書無しさん:04/03/18 22:41
先に前スレ埋めろ

36 :仕様書無しさん:04/03/18 22:41
>>31
> JavaプログラマからC++プログラマに格下げされました

墓穴ほったな。JavaプログラマからC++プログラマに格上げしてんじゃんw

37 :仕様書無しさん:04/03/18 22:42
>>25
一ステートメント中が長すぎて情けないと思いませんか。
式を分割し整理しましょう。



38 :仕様書無しさん:04/03/18 22:43
>>36
墓穴掘ったなw
実質C++プログラマの給料はJavaプログラマより安いw

39 :仕様書無しさん:04/03/18 22:43
派遣の単価限定の話だろ。(ゲラ

40 :仕様書無しさん:04/03/18 22:43
>>35
C厨をはじめとするアンチの馬鹿どもに埋めさせておけ

41 :仕様書無しさん:04/03/18 22:44
>>40
で、お前はここを一生懸命埋めるわけだなw

42 :仕様書無しさん:04/03/18 22:46
java厨ってIDE何使ってんの?

43 :仕様書無しさん:04/03/18 22:46
>>32
コンパイルエラーになる原因がまずひとつ。

>>25がJavaのステートメント記述方法を知らない。

次が重要。

>>25がlong型の桁数最大値を知らない。


44 :仕様書無しさん:04/03/18 22:46
javaといえばviに決まってます

45 :仕様書無しさん:04/03/18 22:48

>>41
で、今お前もここを埋めているわけだなw 

46 :仕様書無しさん:04/03/18 22:49
>>25
Javaでintの最大値を超えるlong型の値リテラルを記述する方法がわかっていないようです(藁

C厨はこれだから(ry
Cと同じだと思い込んでJavaをやると痛い目をみるわけだw

47 :仕様書無しさん:04/03/18 22:49
>>45
その通りだ。相手を馬鹿呼ばわりしても同レベルって奴だなw


48 :仕様書無しさん:04/03/18 22:50
>>46
ねぇねぇ。なんでC厨だと思ったわけ。
ということにしたいんですねー。って奴?

49 :仕様書無しさん:04/03/18 22:50
向こうは埋まったから来てやったぞ。厨ども。

50 :仕様書無しさん:04/03/18 22:50
誤爆した。ワラ
http://pc.2ch.net/test/read.cgi/prog/1071385707/439

51 :仕様書無しさん:04/03/18 22:51
>>50
ワロタ 

52 :仕様書無しさん:04/03/18 22:52
>>25はlongやdoubleの範囲を超える値を
BigDecimalで簡単に表現する方法をわかっていないようです。

彼はそんなことも知らないでJavaを批判していたようです。

人間として失格ですね

53 :仕様書無しさん:04/03/18 22:53
>>48
構造体とクラスとの区別がわからないでCマンセー、ポインタ演算マンセー、
といっている馬鹿がいるからですw


54 :仕様書無しさん:04/03/18 22:54
えっ? 文章の流からすると>>25はJava厨でしょ?

55 :仕様書無しさん:04/03/18 22:54
>>53
ねぇねぇ。どこにいるの? 脳内? それとも脳無い?

56 :仕様書無しさん:04/03/18 22:54
BigDecimalを使うような状況になったらCOBOLを使えばいいのさ

Javaでなんでもやろうとする奴はJavaを知らない

57 :仕様書無しさん:04/03/18 22:55
>>53
構造体の無いJava厨に言われる覚えはありません

58 :仕様書無しさん:04/03/18 22:55
構造体の存在すら知らないJava厨

59 :仕様書無しさん:04/03/18 22:55
>>54はC厨だけど

60 :仕様書無しさん:04/03/18 22:56
根拠もなくJavaマンセーといってる馬鹿は?


61 :仕様書無しさん:04/03/18 22:56
構造体があればクラスはいらないといって必死にJavaをたたこうとするC厨

62 :仕様書無しさん:04/03/18 22:56
Javaって何を記述するために特化された言語なの?
ブラウザや携帯の中でくるくるするやつ?

63 :仕様書無しさん:04/03/18 22:56
Java厨になんでJavaに構造体がないの?って聞くと、
クラスにすればいいじゃんと涙目で訴えるのが笑える

64 :仕様書無しさん:04/03/18 22:57
根拠もなくCOBOLマンセーといっている馬鹿は?

65 :仕様書無しさん:04/03/18 22:57
最近Javaって話題が無いね。寂しくない?

66 :仕様書無しさん:04/03/18 22:57
Javaのクラスってスタックに取れないの?

67 :仕様書無しさん:04/03/18 22:57
>>61
そんなやついないって。妄想しすぎるのもいい加減にな。

68 :仕様書無しさん:04/03/18 22:57
C厨になんで君はクラスを使えないのって聞くと、
構造体にすればいいじゃんと涙目で訴えるのが笑える


69 :仕様書無しさん:04/03/18 22:58
JavaはVMだな。
全てクラスで記述するし。
多重継承もない。
でも俺はJava嫌い。


70 :仕様書無しさん:04/03/18 22:58
>>66
java.util.Stackのこといってるのかはっきりせい

71 :仕様書無しさん:04/03/18 22:58
>>69
多重継承あるよ

72 :仕様書無しさん:04/03/18 22:58
>>61
> 構造体があればクラスはいらないといって必死にJavaをたたこうとするC厨
むしろ、
クラスがあれば構造体はいらないといって必死にJavaを擁護するJava厨が多いんだが。

73 :仕様書無しさん:04/03/18 22:59
>>68
手続き型だからじゃん?

74 :仕様書無しさん:04/03/18 22:59
>>67
やっぱりチミはC厨だったんだね(ププ
シチュ━━━━━━!(ワラ

75 :仕様書無しさん:04/03/18 22:59
クラスが必要なら拡張子をcppにしますが、何か? 

76 :仕様書無しさん:04/03/18 23:00
C#は構造体もクラスも使えるよ。

77 :仕様書無しさん:04/03/18 23:01
>>72
> >>61
> > 構造体があればクラスはいらないといって必死にJavaをたたこうとするC厨
> むしろ、
> クラスがあれば構造体はいらないといって必死にJavaを擁護するJava厨が多いんだが。
根拠なさそうだね。

むしろ、
関数があればオブジェクト指向やクラスはいらないといって必死にCを擁護するC厨が多いんだが。


78 :仕様書無しさん:04/03/18 23:01
やっぱりこいつC厨だったのか。
態度が突然変わったぞ

79 :仕様書無しさん:04/03/18 23:02
>>76
ところが

C#の構造体 ≠ C/C++の構造体

80 :仕様書無しさん:04/03/18 23:02
C厨と判断した根拠が知りたいなぁ。
どうせ思い込みなんだろうがw

81 :仕様書無しさん:04/03/18 23:02
ここにいるJava厨は成りきりか学生です。
なぜなら、職業ドカタjavaPGは年度末の今頃はデスマです。

82 :仕様書無しさん:04/03/18 23:02
>>73
ププ いやいや、それはC厨がオブジェクト指向を理解できずに
ついていけないから必死になっているんだよ(ワラ

83 :仕様書無しさん:04/03/18 23:03
>>79
それは実装が違うだけだろ?

84 :仕様書無しさん:04/03/18 23:04
>>82
誰もお前の意見なんか聞いていない。

85 :仕様書無しさん:04/03/18 23:04
ここにいるC厨は成りきりか学生です。
なぜなら、職業ドカタC-PGは年度末の今頃はデスマです。

ここにいるC#厨は成りきりか学生です。
なぜなら、職業ドカタC#は年度末の今頃はデスマです。

ここにいるCOBOL厨は成りきりか学生です。
なぜなら、職業ドカタCOBOLは年度末の今頃はデスマです。


これも用意しないと成り立たないなw

86 :仕様書無しさん:04/03/18 23:05
Java厨と判断した根拠が知りたいなぁ。
どうせ思い込みなんだろうがw   




87 :仕様書無しさん:04/03/18 23:05
クラスを使えるからといってオブジェクト思考を理解してるとは限らない
ほとんどのJava厨は他人のふんどしでしかプログラムを書けない

88 :仕様書無しさん:04/03/18 23:05
生きが良いなっw

89 :最凶VB厨房:04/03/18 23:06
VB厨と判断した根拠が知りたいなぁ。


あぁ、まだだったか。

90 :仕様書無しさん:04/03/18 23:06
>>87
切り貼りするだけだからね。

91 :仕様書無しさん:04/03/18 23:06
>>80
C厨はオブジェクト指向や構造体の話題で馬鹿にされるとムキになるからw


92 :仕様書無しさん:04/03/18 23:07
それよりか激しく醜いんだが
BigDecimal.valueOf(1).add(BigDecimal.valueOf(3).multiply(BigDecimal.valueOf(5)))



93 :仕様書無しさん:04/03/18 23:07
>>91
なるほど、君はそういう思い込みで生きているんだなw

94 :仕様書無しさん:04/03/18 23:07
>>90
そういうことははオブジェクト指向を理解していないために
必死に関数を切り貼りするC厨の十八番ですね

95 :仕様書無しさん:04/03/18 23:08
>>87
おまえのまわりだけでなー

96 :仕様書無しさん:04/03/18 23:08
>>92
実数がひとつもないもにわざわざBigDecimalですか(ワラ

97 :仕様書無しさん:04/03/18 23:08
何でもしようとするとからな...
で、Javaって何の目的で作られたんだっけ?自己満足?

98 :仕様書無しさん:04/03/18 23:09
かっこの位置がおかしいんじゃねぇ?
× BigDecimal.valueOf(1).add(BigDecimal.valueOf(3).multiply(BigDecimal.valueOf(5)))
○ BigDecimal.valueOf(1).add(BigDecimal.valueOf(3)).multiply(BigDecimal.valueOf(5))

99 :仕様書無しさん:04/03/18 23:09
>>97
アプレットぐるぐる

100 :仕様書無しさん:04/03/18 23:09
さてさて、Java嫌いな>>25はこれがコンパイルエラーになった原因と
エラーを解除する原因を理解できたかな?

>>25
> こまかい揚げ足鳥うるせーよ。
> これで満足だろ? えっ?
>
> BigDecimal.valueOf(100000000000000000000).add(BigDecimal.valueOf(300000000000000000000).multiply(BigDecimal.valueOf(500000000000000000000)))
>


101 :仕様書無しさん:04/03/18 23:10
>>94
おまえのまわりだけでなー

102 :仕様書無しさん:04/03/18 23:10
>>99
違う。

家電

103 :仕様書無しさん:04/03/18 23:10
>>100
お前まだわかんねーの? だせーw

104 :仕様書無しさん:04/03/18 23:10
>>101は同じことしかいえないオウムになってしまいましたw


105 :仕様書無しさん:04/03/18 23:11
>>103は厨房ですねw
コンパイルエラーのメッセージがいくつ出るとお思いですか?
わからないなら自分でコンパイルしましょうねw

106 :仕様書無しさん:04/03/18 23:11
なんかJavaのコードって汚いな....

107 :仕様書無しさん:04/03/18 23:12
関数って切り貼りするものじゃないよ
君はクラスを切り貼りすのかい?


108 :仕様書無しさん:04/03/18 23:12
>>105
他人に聞いてないで、自分で実行してみろよw

109 :仕様書無しさん:04/03/18 23:15
何でも詰め込んで破綻したアプリがあったなぁ
何でも詰め込んで破綻した言語はもっと一杯あるけどね

110 :仕様書無しさん:04/03/18 23:15
>>98
> かっこの位置がおかしいんじゃねぇ?
> × BigDecimal.valueOf(1).add(BigDecimal.valueOf(3).multiply(BigDecimal.valueOf(5)))
> ○ BigDecimal.valueOf(1).add(BigDecimal.valueOf(3)).multiply(BigDecimal.valueOf(5))

これはどちらもコンパイルが通りますよw
しかも結果が異なりますよ、無知なC厨さんw

111 :仕様書無しさん:04/03/18 23:16
>>109
なんにもないHSPが最強って事ですね

112 :仕様書無しさん:04/03/18 23:16
>>107
馬鹿ですね。ポリも―ふぃズムもしらない馬鹿C厨がここに一人

BirdgeパターンもStrategyパターンもしらない馬鹿C厨がここに一人

113 :仕様書無しさん:04/03/18 23:16
>>110
なんでまたC厨ってことにしたがってるの?

114 :仕様書無しさん:04/03/18 23:17
>>108
哀れなC厨の断末魔か・・・

115 :仕様書無しさん:04/03/18 23:17
>>112
お前、皮肉って言葉知らないだろ?
もっと日本語勉強しとけ。

116 :仕様書無しさん:04/03/18 23:18
クラスやオブジェクト指向の話をするとそらそうとするからねえw

COBOL厨もC厨も同属だけどねw

117 :仕様書無しさん:04/03/18 23:18
>>114
負け犬の遠ぼえですか?

118 :仕様書無しさん:04/03/18 23:18
>>115
お前、実証主義って言葉知らないだろ?
もっと日本語勉強しとけ。


119 :仕様書無しさん:04/03/18 23:18
>>116
誰もそらしてないと思うけど?
一体君の敵は誰なんだい?

120 :仕様書無しさん:04/03/18 23:19
今日のはまた生きが良いな

121 :仕様書無しさん:04/03/18 23:19
豪華に見えて、中身のない言語は人気があります


122 :仕様書無しさん:04/03/18 23:19
>>118
話がつながってないw

123 :仕様書無しさん:04/03/18 23:19
>>119
脳に響くデムパ

124 :仕様書無しさん:04/03/18 23:19
そうそう、C厨の負け犬の遠吠え。
オブジェクト指向の話をすると必死にそらす。

Javaではオブジェクト指向をろくにしらないとなにもプログラミングできないことも
知らずにねw ほんとにJavaを批判できる資格があるのかなあ、こういう人たちは。
Javaを批判するならその前にオブジェクト指向やデザインパターンのことをよく勉強してからにしてほしいなあ。


125 :仕様書無しさん:04/03/18 23:20
わはは
Java厨房は敵が多くて大変ですね

Del厨やHSP厨も潜伏してるんじゃないかなあ
あっ、Lisp厨やScheme厨もJavaを貶してるかもね

126 :仕様書無しさん:04/03/18 23:20
潜伏中のPerl厨は手を挙げて!

127 :仕様書無しさん:04/03/18 23:20
>>119
私は無敵ですが何か。

あたたの敵はJava厨なんだそうですね。
かわいそうに。手ごわい相手を敵にまわしてしまったそうですねw

128 :仕様書無しさん:04/03/18 23:21
同じパターンが何度も出現するということは
設計がおかしいか、言語が貧弱である事の証拠

覚える事は少なければ少ない程よい
いい加減丸暗記でプログラムは作れない事を知れ

129 :仕様書無しさん:04/03/18 23:21
>>124
「そうそう」といいながら何で反対のことを言っているんだ?
やっぱり日本語読めないのかなぁ

130 :仕様書無しさん:04/03/18 23:21
すいません。生きのいいブラックバスがいるスレはこちらですか?

131 :仕様書無しさん:04/03/18 23:22
>>106
C++やCOBOLコードよりはまし。
ここでBigDecimalであれこれやってるやしは
分割統治という言葉をしらずに
ひとつのステートメントにすべてつめこもうとする
きたないコードしかかけない。

132 :仕様書無しさん:04/03/18 23:23
そうです。>>130がその生きのいいブラックバスです。

133 :仕様書無しさん:04/03/18 23:23
>>129
きみは日本語も英語もJava語もC言語も読めない人なんですねw

134 :仕様書無しさん:04/03/18 23:24
BigDecimalの話題をしようとして論破されると
やっぱり話題をそらそうとするアンチJava厨w

135 :仕様書無しさん:04/03/18 23:24
>>131
> ここでBigDecimalであれこれやってるやしは
> 分割統治という言葉をしらずに
> ひとつのステートメントにすべてつめこもうとする
> きたないコードしかかけない。

それでは君は同じコードをどうかくというのかね?

136 :仕様書無しさん:04/03/18 23:24
>>110について>>98はどんな返答をするのかな
Cしか知らない人ってホントに哀れですね。

137 :仕様書無しさん:04/03/18 23:25
分割統治って意味違うだろ

138 :仕様書無しさん:04/03/18 23:25
>>133
人格否定しかしていない。負け犬の遠ぼえにふさわしいな。

139 :仕様書無しさん:04/03/18 23:26
>>135
君はステートメントを分割する、
インデントをつける、
マジックナンバーを定義するという初歩的なことを知らないのかね?
そうか、メモリのことばかりきにしすぎてマジックナンバーすらつかえないのか(ワラ
Cをやっていたくせに#defineも使えないんだ(w

140 :仕様書無しさん:04/03/18 23:26
>>136
他人に聞かないで、自分で実行してみろよ

141 :仕様書無しさん:04/03/18 23:26
>>137
ああ、違うとも。
比喩をこめていってやったのさ。


142 :仕様書無しさん:04/03/18 23:27
>>139
そういう一般論はいいから、
実際のコードで示せ。

143 :仕様書無しさん:04/03/18 23:27
>>140
日本語読めてますか?
必死に話題をそらして自分の無知を認めないとは哀れな人ですね

144 :仕様書無しさん:04/03/18 23:28
> そうか、メモリのことばかりきにしすぎてマジックナンバーすらつかえないのか(ワラ
馬鹿だなこいつ。メモリとマジックナンバーは関係ないよ。


145 :仕様書無しさん:04/03/18 23:28
>>142
ちょっとしたものがすでにこのスレに出てるよ。
前スレにもあったかな。
まだまだきれいにし甲斐があるけど

146 :仕様書無しさん:04/03/18 23:29
>>143
はいはい。いいから自分で実行しましょうねー

147 :仕様書無しさん:04/03/18 23:29
ところで、確定申告はちゃんとすませたか?おまいら

148 :仕様書無しさん:04/03/18 23:29
あのさぁ、デザパタのまえにYAGNIとかついて知ったほうがいいよ
なんでもできる万能クラスは存在価値なし

149 :仕様書無しさん:04/03/18 23:29
>>144
馬鹿だなこいつ、変数を再利用せずに宣言しすぎることとメモリは関係あるよ

150 :仕様書無しさん:04/03/18 23:30
> 変数を再利用せずに宣言しすぎること
おい。一体だれがそんなことを言い出したんだ?w

151 :仕様書無しさん:04/03/18 23:31
マジックナンバーが変数を再利用せずに宣言することと
勘違いしてんじゃねーの? 本格的な馬鹿だな。

152 :仕様書無しさん:04/03/18 23:31
Javaしか知らない奴はイラネ

153 :仕様書無しさん:04/03/18 23:33
144 名前:仕様書無しさん :04/03/18 23:28
> そうか、メモリのことばかりきにしすぎてマジックナンバーすらつかえないのか(ワラ
馬鹿だなこいつ。メモリとマジックナンバーは関係ないよ。

149 名前:仕様書無しさん :04/03/18 23:29
>>144
馬鹿だなこいつ、変数を再利用せずに宣言しすぎることとメモリは関係あるよ


一体何の関係が?(ワラ

154 :コボラ出血熱:04/03/18 23:33
> 変数を再利用せずに宣言しすぎること

そうだ。グローバル変数こそ理想的である。

155 :仕様書無しさん:04/03/18 23:34
>>146
はいはい、自分から実行しましょうねー。
やっぱり逃げ腰だなC厨。

ささ、もう一度アンチJava厨に対する審判を行いますか(ワラ

>>110について>>98はどんな返答をするのかな
Cしか知らない人ってホントに哀れですね。

>>98はこんなことを書いた。
> かっこの位置がおかしいんじゃねぇ?
> × BigDecimal.valueOf(1).add(BigDecimal.valueOf(3).multiply(BigDecimal.valueOf(5)))
> ○ BigDecimal.valueOf(1).add(BigDecimal.valueOf(3)).multiply(BigDecimal.valueOf(5))
どうやら>>98は上の式がコンパイル・実行できないと勘違いしていたらしい。
しかし>>110で論破されているw
どちらもコンパイルできるのだ。

つまり>>98はオブジェクト指向を理解できていない証拠なのだw
メソッドを演算子と一緒だと勘違いしているということなのだ!(ワラ
>>98はCしかできないからこういう罪を犯すのですw

さて、間違いを犯した>>98にはどんな罰をあたえましょうか?



156 :仕様書無しさん:04/03/18 23:34
ところでお前ら納期は大丈夫か?今日はまだ週末じゃないぞ。

157 :仕様書無しさん:04/03/18 23:35
>>155
君。まだやっていたの?

158 :仕様書無しさん:04/03/18 23:35
Javaはグローバル変数がないから糞
Javaはメモリを使いすぎるから糞

まぁ、糞プログラマにはお似合いの厨房御用達言語だな

159 :仕様書無しさん:04/03/18 23:37
お前かグローバル変数安易に宣言する奴は。

お願いだからコメントぐらいつけて。

160 :仕様書無しさん:04/03/18 23:37
プリプロセッサはメモリを食います

161 :仕様書無しさん:04/03/18 23:37
綺麗な流れるようようなコードより勝てるコードじゃないと...
案件受注から15日以内に納入できないと勝利はおぼつかない。
リスタートからのセットプレイがポイントになる。


162 :仕様書無しさん:04/03/18 23:39
>>142
> そういう一般論はいいから、
> 実際のコードで示せ。
ほれ。>>3>>9、どっちがきれいだと思う?

>>3
public BigDecimal calculate(){
 return BigDecimal.valueOf(1).add(BigDecimal.valueOf(3).multiply(BigDecimal.valueOf(5)))
}

>>9
public BigDecimal calculate(){
 return BigDecimal result = new BigDecimal(Byte.toString(1 + 3 * 5));
}

一番きれいなのはこれだがw
public BigDecimal calculate(){
 return new BigDecimal("16");
}

しかし効率がよいのはこれだがw
public BigInteger calculate(){
 return BigIntegervalueOf(16L);
}

しかしもっといいのはこれだがw
public byte calculate(){
 return 16;
}

163 :仕様書無しさん:04/03/18 23:40
一生懸命書いたんだろうな、無駄コード


164 :仕様書無しさん:04/03/18 23:40
>>158
> Javaはグローバル変数がないから糞
> Javaはメモリを使いすぎるから糞
>
> まぁ、糞プログラマにはお似合いの厨房御用達言語だな

まぁ、あなたはなんと見事な逆説を唱える糞コボラですねw
さすが厨房用化石言語COBOLを使っているだけのことがあるw

つまりあなたはJavaどころかC#やSmalltalkなども敵に回しているようですねw

165 :仕様書無しさん:04/03/18 23:41
>>163
ププ 反論できずに必死に言い訳して逃げるC厨

166 :仕様書無しさん:04/03/18 23:41
Java厨どうした。キレがなくなってきたぞ
それとも今GC中なのか?

167 :仕様書無しさん:04/03/18 23:41
今日のJava厨担当は頑張るな。

168 :仕様書無しさん:04/03/18 23:41
>>163
> 一生懸命書いたんだろうな、無駄コード

publicをつける意味や戻り値がBigDecimalになっていることに
困惑しているC厨の負け惜しみだw

169 :仕様書無しさん:04/03/18 23:42
144 名前:仕様書無しさん :04/03/18 23:28
> そうか、メモリのことばかりきにしすぎてマジックナンバーすらつかえないのか(ワラ
馬鹿だなこいつ。メモリとマジックナンバーは関係ないよ。

149 名前:仕様書無しさん :04/03/18 23:29
>>144
馬鹿だなこいつ、変数を再利用せずに宣言しすぎることとメモリは関係あるよ

170 :仕様書無しさん:04/03/18 23:43
>>166
それは

アンチJava厨どうした。キレがなくなってきたぞ
それとも今GC中なのか?


の間違いじゃないのププ

BigDecimalの正しい使い方も理解できないC馬鹿やCOBOL馬鹿が多いスレですからねw

171 :仕様書無しさん:04/03/18 23:45
>>162
1とか3とか小さい値じゃなくて、
longじゃ足りないような大きな数値でやってみな

172 :仕様書無しさん:04/03/18 23:45
金にもならんコードよく書くよね。
まぁアマチュアリズムに溢れててよろしいのではないかと。


173 :仕様書無しさん:04/03/18 23:45
>>167
白い巨塔終わったんでJava厨の役をやりにきたらいらないみたい
代わりに.net厨でもやるか

174 :仕様書無しさん:04/03/18 23:47
やっと2号が来たぞ。よかったな。1号。

175 :仕様書無しさん:04/03/18 23:47
なんだいないのかよ、つまんねーの。
んじゃ漏れオプソ厨やっかな。


176 :仕様書無しさん:04/03/18 23:48
で?そんなにCOBOLで普通にできる事をJavaで汚く書かれてもなぁ

177 :仕様書無しさん:04/03/18 23:48
>>175
一人二役やってなさい。

178 :仕様書無しさん:04/03/18 23:49
もう170か?お前らスレはもっと大切にしろ。

179 :仕様書無しさん:04/03/18 23:50
BigDecimalなんか使わなきゃならない大きな数字を
扱うときにJavaが汚いのは有名な話。

180 :仕様書無しさん:04/03/18 23:50
>>178
どうせひろゆきの金だし。

181 :仕様書無しさん:04/03/18 23:50
Java厨はりソースには無頓着だからなぁ

182 :仕様書無しさん:04/03/18 23:52
そのうちガベコレがガッっと動いて綺麗になります。

183 :仕様書無しさん:04/03/18 23:52
俺はソースにこだわるぜ。

184 :仕様書無しさん:04/03/18 23:53
さてさて、もうひとつC厨とCOBOL厨に裁きをいれるときがやってまいりましたw

>>25はどうやらこれが正しい記述方法だと勘違いしているようですw
エラーの原因はセミコロンがないだけではありませんよ(ワラ
それだけでなく記述が汚いですねえ。
それから整数リテラルの正しい記述もわかっていないため思うような結果がまず得られませんw
それだけでなく彼はlong型の最大値も理解していません。

それ以外にも盲点が!
彼はBigDecimal, BigIntegerで、long型やdouble型の精度を超える
値をBigDecimal, BigIntegerオブジェクトに変換する方法をわかっていませんw
かれはBigDecimalクラス、BigIntegerクラスのメソッドやコンストラクタ
をまだ把握しきっていません(ワラ
彼はBigDecimal.valueOf(long)やBigDecimal(duble)は知っているようですが
BigDecimal(String)は知らなかったようです(ハゲワラ

BigDecimalクラスは実数を扱うクラス。それにもかかわらず
彼は整数をBigDecimal型に変換している。
本来ならば、こういうときはBigIntegerに入れたほうが高速になるわけです。
あとからBigDecimal型の値にどうしても計算させたければ
まず最初にBigInteger型同士で計算させればすむことなのです。
それが済んでからBigDecimal型に変換すればほかのBigDecimalオブジェクトとの
演算ができるわけです。それを彼は理解していないようでした。

さすがC言語厨w さすがコボル厨。彼のレベルはこの程度でしたw
> こまかい揚げ足鳥うるせーよ。
> これで満足だろ? えっ?
>
BigDecimal.valueOf(100000000000000000000).add(BigDecimal.valueOf(300000000000000000000).multiply(BigDecimal.valueOf(500000000000000000000)))


185 :仕様書無しさん:04/03/18 23:54
マジックナンバー厨がんばれ

186 :仕様書無しさん:04/03/18 23:55
>>184
またずいぶんと遅レスだなw
なんでそんなに必死なの?

187 :仕様書無しさん:04/03/18 23:55
>>181
> Java厨はりソースには無頓着だからなぁ
プ 浅はかですねw

java.lang.ref.SoftReferenceや
java.lang.Runtime#freeMemory()などを使えば
リソースに無頓着ではいられなくなりますが何か。


188 :仕様書無しさん:04/03/18 23:56
>>186
言い訳に必死ですねw

189 :仕様書無しさん:04/03/18 23:56
COBOLにlongという型はないよ
おまえももぅ少しCOBOLを知ってから物言えよ。

190 :仕様書無しさん:04/03/18 23:57
>>186
掲示板をチャットと勘違いしている坊や、
君は随分と暇そうだねw

191 :仕様書無しさん:04/03/18 23:57
リソースといわれてメモリのことしか思いつかない
Java厨の浅はかさ

192 :仕様書無しさん:04/03/18 23:57
てか、Javaのソースが汚いと言われて
COBOLやC++よりマシなんて言い出す所が
Java厨の厨たる由縁だよねぇ。
なんで美しいコードを書いて示す前に○○よりマシなんて他と比べちゃうんだろ。
なんか劣等感丸出しって感じw

193 :仕様書無しさん:04/03/18 23:58
>>189
だれかそんなことをいいましたか?
あなたは知障ですか?


194 :仕様書無しさん:04/03/18 23:58
>>192
Java厨なんてここにはいませんが

195 :仕様書無しさん:04/03/18 23:59
そうそう、Java厨なんてほんとうはこのスレにはいない

196 :仕様書無しさん:04/03/18 23:59
> 掲示板をチャットと勘違いしている坊や、
Java厨は掲示板をチャットと勘違いしているから
レスつけまくってリソース無駄遣いしているのか。


197 :仕様書無しさん:04/03/19 00:00
こいつ、メモリ以外のリソースもGCが回収すると信じてそうで恐いな...

198 :仕様書無しさん:04/03/19 00:00
>>191
意標を突かれてなかったことにしてくれと懇願するかのように
話題をそらそうと必死になるアンチJava厨

199 :仕様書無しさん:04/03/19 00:00
いるのは真のJava厨のみ。

200 :仕様書無しさん:04/03/19 00:01
アンチJava厨は掲示板をチャットと勘違いしているから
適当な言い訳レスつけまくってリソース無駄遣いしているのか。

201 :仕様書無しさん:04/03/19 00:01
>>194>>195
うんうん。本当にそうだよね(w

202 :仕様書無しさん:04/03/19 00:02
>>198
ずいぶんわざとらしい解説が入ってるなw

203 :仕様書無しさん:04/03/19 00:02
>>197
HDDは大容量化しているのでそこらへんのリソースはまず大丈夫

ほかのリソースは?

204 :仕様書無しさん:04/03/19 00:03
必死なのは誰でしょう?

205 :仕様書無しさん:04/03/19 00:03
はっきり言おう。
本当のJava厨は怖くてこのスレには入れません。(マジ

206 :仕様書無しさん:04/03/19 00:06
最近、俺の周りでJavaのプロジェクトがコケまくってんだよな。
で.netにしたら、それもコケてやんのw
もう笑うしかねーよw

207 :仕様書無しさん:04/03/19 00:06
ソースネクスト、StarSuiteを1,980円で販売〜藤原紀香を新キャラクターに採用
http://pc.watch.impress.co.jp/docs/2004/0115/source.htm
だってさ

なにがオプソだ、やっぱりSun、お前もか、だよな。OpenOfficeってどうなったのさ?
ようはSunはオプソとかどうでもよくて結局M$に一矢報いたいだけなのかも。
java厨、やっぱりお前ら騙されているんじゃないのか?
周りは気づいているぜ(w。

http://japan.cnet.com/news/ent/story/0,2000047623,20064923,00.htm
http://linux.ascii24.com/linux/news/today/2000/07/20/505216-000.html
http://linux.ascii24.com/linux/news/today/2001/09/28/629997-000.html

208 :仕様書無しさん:04/03/19 00:09
http://www.itmedia.co.jp/enterprise/0403/11/epn02.html
Microsoft、SQL ServerとVisual Studio .NETの新版のリリース延期



209 :仕様書無しさん:04/03/19 00:10
>>207
サポートが受けたい奴だけでしょ。

210 :仕様書無しさん:04/03/19 00:11
さてさて、>>184の続きをしようではないか。

BigDecimal.valueOf(100000000000000000000).add(BigDecimal.valueOf(300000000000000000000).multiply(BigDecimal.valueOf(500000000000000000000)))

こいつを訂正するには↓

public BigDecimal calculate(){
 return new BigDecimal(new BigInteger("100000000000000000000").add(new BigInteger("300000000000000000000").multiply(new BigInteger("500000000000000000000"))));
}

これでひとまずコンパイルエラーは避けられた。
しかしこれは綺麗なコードではない。

さて問題だ。これを綺麗なコードにするにはどうするか?
あとは簡単だw
これができなければキミたちはプログラマ失格だw

さてさて、
聴衆(Javaが嫌いな厨房ども(たとえばCOBOL厨とかC厨とかC#厨とか))の反応やいかに?

211 :仕様書無しさん:04/03/19 00:12
Sunはオープンソースのふんどしで相撲をとりたいだけでしょ。
末路はNetscape化するオカン

212 :仕様書無しさん:04/03/19 00:12
>>207
> なにがオプソだ、やっぱりSun、お前もか、だよな。OpenOfficeってどうなったのさ?
> ようはSunはオプソとかどうでもよくて結局M$に一矢報いたいだけなのかも。
プ オープンソースビジネスというものをよく理解していないようですね。

EclipseとWSADとの関係、IBMのオープンソースビジネスモデルすら
理解していないようですねw

213 :仕様書無しさん:04/03/19 00:12
>>208
あーあ。
Yukonには少し期待してたのに。

214 :仕様書無しさん:04/03/19 00:14
さてjavaはどうなる?Sunはオプソ化すらしないとハッキリいっとるぞ(w
ある日いきなりごっそりエクストラチャージをかける可能性もなきにしもあらず。
「javaが無料である時代は終わった」とかなんとか....


215 :仕様書無しさん:04/03/19 00:14
>>207
> ソースネクスト、StarSuiteを1,980円で販売〜藤原紀香を新キャラクターに採用
> http://pc.watch.impress.co.jp/docs/2004/0115/source.htm
> だってさ
>
> なにがオプソだ、やっぱりSun、お前もか、だよな。OpenOfficeってどうなったのさ?
> ようはSunはオプソとかどうでもよくて結局M$に一矢報いたいだけなのかも。

プププ OpenOfficeは死んだと勘違いしていませんか(藁
オープンソースが突然有償化することはありませんよw
上位版と下位版との区別もつかないお馬鹿さんですねあなたは
http://ja.openoffice.org/start/


216 :仕様書無しさん:04/03/19 00:15
http://itpro.nikkeibp.co.jp/free/NC/TOKU1/20030703/1/
口座振替システムを再構築するにあたり、オープン系プラットフォームの
採用と同時に、「開発したソフト部品を再利用できる、プラットフォーム
に依存しない点を買って」Javaの採用を決めた

217 :仕様書無しさん:04/03/19 00:16
>>210
もったいぶってないで早く結論を書けば?
いい加減みんな飽きてきてるんだからさ。

218 :仕様書無しさん:04/03/19 00:16
>>214
> さてjavaはどうなる?Sunはオプソ化すらしないとハッキリいっとるぞ(w
ププ Javaはすでにほとんどオープンソース化されていますが(藁
どうやらあなたはしったかぶりをしているようですね。
無知なC厨やC#厨はこれだからw


219 :仕様書無しさん:04/03/19 00:16
javaはオープンソースじゃありません(w

220 :仕様書無しさん:04/03/19 00:16
http://www.itmedia.co.jp/enterprise/0402/18/epn08.html
UFJ銀行に見る基幹システムJ2EE採用要件

221 :仕様書無しさん:04/03/19 00:16
>>216
そしてデスマ

222 :仕様書無しさん:04/03/19 00:17
>>199はJava厨です


223 :仕様書無しさん:04/03/19 00:18
> public BigDecimal calculate(){
>  return new BigDecimal(new BigInteger("100000000000000000000").add(new BigInteger("300000000000000000000").multiply(new BigInteger("500000000000000000000"))));
> }
さらに汚いな。しかも、これカッコが足りないだろ?


224 :仕様書無しさん:04/03/19 00:18
>>217
いや、アンチJava厨をへこませるまでじらしてあげようプププ

225 :仕様書無しさん:04/03/19 00:19
つーか既によんでないが

226 :仕様書無しさん:04/03/19 00:20
2004年9月稼動か...あと半年だぞ。


227 :仕様書無しさん:04/03/19 00:21
中部電力のやつどうなったんだろう

228 :仕様書無しさん:04/03/19 00:21
>>223
> > public BigDecimal calculate(){
> >  return new BigDecimal(new BigInteger("100000000000000000000").add(new BigInteger("300000000000000000000").multiply(new BigInteger("500000000000000000000"))));
> > }
> さらに汚いな。しかも、これカッコが足りないだろ?

プププ さて、自分で綺麗にできるかなw
こんな簡単な問題すらもできなければC厨はプログラマ失格だねw

括弧が足りないと思うなら自分でコンパイルしてみることだねw
キミは早速間違いを犯しましたねw

やはりC厨やC#厨やCOBOL厨のレベルはこの程度だw

229 :仕様書無しさん:04/03/19 00:21
BigDecimal厨はいいや。飽きた。

230 :仕様書無しさん:04/03/19 00:21
さてさて、>>184の続きをしようではないか。

BigDecimal.valueOf(100000000000000000000).add(BigDecimal.valueOf(300000000000000000000).multiply(BigDecimal.valueOf(500000000000000000000)))

こいつを訂正するには↓

public BigDecimal calculate(){
 return new BigDecimal(new BigInteger("100000000000000000000").add(new BigInteger("300000000000000000000").multiply(new BigInteger("500000000000000000000"))));
}

これでひとまずコンパイルエラーは避けられた。
しかしこれは綺麗なコードではない。

さて問題だ。これを綺麗なコードにするにはどうするか?
あとは簡単だw
これができなければキミたちはプログラマ失格だw

231 :仕様書無しさん:04/03/19 00:22
>>224
馬鹿だし空気読めないし.....
救いようがねーな。

232 :仕様書無しさん:04/03/19 00:22
>>229
だーめだ。まだ続けろ

233 :仕様書無しさん:04/03/19 00:22
>>228
Java厨には綺麗にできないと証明するような発言するなよ。

234 :仕様書無しさん:04/03/19 00:22
C/C++、COBOL:オープン
J2SE:ほぼオープン
J2EE:まだまだSun支配
.NET:完全なMS支配

235 :仕様書無しさん:04/03/19 00:22
>>231
空気を読めない馬鹿はきみのほう

236 :最凶VB厨房:04/03/19 00:23
http://www.itmedia.co.jp/enterprise/0403/17/epc15.html

237 :仕様書無しさん:04/03/19 00:23
>>233
C厨, C++厨、C#厨、COBOL厨には綺麗にできないと証明することは簡単ですが何か

238 :仕様書無しさん:04/03/19 00:24
やっぱりC厨もC#厨もC++厨もCOBOL厨もVB厨もこんなもんか・・・・・・

239 :仕様書無しさん:04/03/19 00:25
>>230
グローバル変数厨コボラには理解できません。


240 :仕様書無しさん:04/03/19 00:25
と、perl厨がつぶやいた


241 :仕様書無しさん:04/03/19 00:25
先生 BigDecimalについてもっと教えてください。Cは早く捨てたいです。

242 :仕様書無しさん:04/03/19 00:26
>>230
汚いコードかいてもそれを自慢の種にしてしまう神経が麻痺したC++厨には
敷居が高すぎる問題です。

243 :仕様書無しさん:04/03/19 00:26
>>241
そのまえにCOBOLを捨てなさい。

244 :仕様書無しさん:04/03/19 00:27
>>234

当スレの不思議

1.MS支持者が、JAVAをオプソでないと批判「自分はもっとじゃん」
2.JAVA支持者が、J2SEのSun支配を認めたがらない「事実は事実でしょ」

245 :仕様書無しさん:04/03/19 00:28
オペレータオーバーロード厨のレベルもこの程度ってか

C++厨やC#厨は演算子再定義ができるできるといっておきながら
いい加減な再定義しかできない低脳なわけですからw

246 :仕様書無しさん:04/03/19 00:28
Javaをたたくと、こう、痛い目にあうんだよw  

247 :仕様書無しさん:04/03/19 00:29
Perlしかできないやつって正規表現を理解しただけで満足して
自慢している馬鹿だから。

248 :仕様書無しさん:04/03/19 00:33
さて、結論だ。

見事にJavaを貶そうとした者に天罰が下ったようだ。

C厨やC#厨、COBOL厨がBigDecimalの話題で
Javaの評判を下げようという陰謀を企てようとしたが
どうやら見事に失敗したようだ。

BigDecimalの仕様をしっかりと理解していなかったことが
彼らが敗北した理由である。

C厨もC#厨もCOBOL厨も皆負け犬となってしまった。
かれらのことをこう呼ぼう。

「C++厨の仮面をかぶり
オブジェクト指向を理解したつもりがしっかりと理解していないC厨」


249 :仕様書無しさん:04/03/19 00:35
>>248
ってそれキモいコピペ嵐の主張じゃん

自称C++厨の化けの皮をはがせ!
と同レベルだよ

250 :仕様書無しさん:04/03/19 00:35
C厨敗退か・・・


251 :仕様書無しさん:04/03/19 00:36
と、C厨が泣き言をいっております。

252 :仕様書無しさん:04/03/19 00:36
>>249
いいからお前は黙って負けを認めろ!

253 :仕様書無しさん:04/03/19 00:36
>>249
とりあえず全世界のJavaプログラマの前で土下座して謝れ

254 :249:04/03/19 00:38
ごめん俺C厨じゃなくてSqueak厨だから

Morphicマンセー

255 :仕様書無しさん:04/03/19 00:39
いや、未来のプログラミング言語の原型たるJavaを貶したからには
全世界のJavaプログラマだけでなくすべてのプログラマに対して
土下座して謝るべきだ。

256 :仕様書無しさん:04/03/19 00:39
と、Squeak厨の仮面を被ったC厨がわめいています。

257 :仕様書無しさん:04/03/19 00:40
COBOL厨はグローバル変数しかつかえない馬鹿だから


258 :仕様書無しさん:04/03/19 00:40
涙目になって叫んでいる>>254がいます(嘲笑


259 :仕様書無しさん:04/03/19 00:41
いまごろC厨は泣き寝入りをしていることだろうw
プ これを自業自得というんだよなw

クックック、 馬鹿が、オブジェクト指向もろくに知らないくせにJavaに挑もうとは
数億年早いんだよw

260 :仕様書無しさん:04/03/19 00:42
C厨はJavaを支える土台にでもなっていればいいんだよ(ワラ
奴隷としてなw

261 :仕様書無しさん:04/03/19 00:42
分かったよ
世界中のJavaプログラマに土下座して謝るから
世界中のJavaプログラマを一ヵ所に集めてくれ。
明日の20:00に名古屋ドームに集合な。

262 :仕様書無しさん:04/03/19 00:42
Javaを支える土台 → JVM ← Cでできているw

263 :249:04/03/19 00:45
ごめん俺Squeak厨じゃなくてJava厨だから

developerWorks Subscriptionマンセー

264 :仕様書無しさん:04/03/19 00:45
>>261
これはまいった。一本とられた。

ってお前は一休さんか。

265 :仕様書無しさん:04/03/19 00:47
warota
おまいは名古屋か。今度出張行ったら飲むか?

266 :仕様書無しさん:04/03/19 00:49
>>263
とJava厨の仮面を被った負け犬C厨が騒いでおります。

267 :仕様書無しさん:04/03/19 00:49
名古屋市民、
東京に飲みに来い。

268 :仕様書無しさん:04/03/19 00:51
世界中のJavaプログラマって名古屋ドームで納まるの?

269 :仕様書無しさん:04/03/19 00:51
>>261
自分で責任をもって自分の足で世界を渡り歩きながら全プログラマに謝罪しに行きましょう。
わざわざ名古屋に呼び寄せることは忙しいプログラマにとって失礼極まり無いことであり
反省の色がない証拠です。

270 :仕様書無しさん:04/03/19 00:52
C言語を実務でつかってる人って
何系の開発の人?


271 :仕様書無しさん:04/03/19 00:53
イケメン系。

272 :仕様書無しさん:04/03/19 00:53
>>268
いいえ、Javaプログラマに限らず世界中のプログラマに対して謝罪し渡り歩くという
ミッションを>>261遂行して貰います。

ささ、>>268よ、名古屋から飛行機に乗ってアメリカに出発しなさい。


273 :仕様書無しさん:04/03/19 00:53
>>244
MS支持者は、コードで金取るのは当然と考えているので、共産主義みたいなオプソが嫌い。
さらに実質Sun支配下にあるJ2SEのくせにオプソきどってMS叩くjava厨はもっと嫌い。



274 :仕様書無しさん:04/03/19 00:53
>>270
WEB系以外

275 :仕様書無しさん:04/03/19 00:54
>>270
> C言語を実務でつかってる人って
> 何系の開発の人?
>
ドカタ系

276 :仕様書無しさん:04/03/19 00:54
C厨が惨敗しているぞ

277 :仕様書無しさん:04/03/19 00:55
Cは機器開発でそ

278 :仕様書無しさん:04/03/19 00:55
にゃーごやはええでー

279 :仕様書無しさん:04/03/19 00:55
今夜はC厨は敗北宣言したか。

さて、酒を飲んで寝るぞ

乾杯!


280 :仕様書無しさん:04/03/19 00:56
JavaOneの会場行けば効率いいかも。

281 :仕様書無しさん:04/03/19 00:58
java、cobol一括りで給与計算でそ。つまり早い話事務仕事。

Cはデバイスとか計測機器とかそういう方面の
開発系でつかわれとりますな。ProjectXとかそっち方面ですな。


282 :最凶VB厨房:04/03/19 00:59
VBは技術系だね。

283 :仕様書無しさん:04/03/19 01:00
まぁでも思うにCOBOLのバッヂ処理で済むような事務仕事を
なんでjavaはあんな手間隙かけて面倒にやるんでしょうね。
そこが謎です。
javaってプログラム組むより電卓叩いたほうが速そうなことばっかり
いったい何のやくに立つのか...

284 :仕様書無しさん:04/03/19 01:00
>>282
土方系

285 :仕様書無しさん:04/03/19 01:02
>>282 グラフ書かせたりする香具師ですな。
マセマティカとかない貧乏な開発室はわりと
VB使ってますな。


286 :仕様書無しさん:04/03/19 01:03
LINE文とかで?

287 :仕様書無しさん:04/03/19 01:06
いやExcel(計算したりグラフ書かしたりする)みたいな香具師のライブラリがあるらっすい。
良く知らんが。


288 :仕様書無しさん:04/03/19 01:07
文化オリエントだな。

289 :仕様書無しさん:04/03/19 01:08
ならExcelで十分なのにな。

290 :仕様書無しさん:04/03/19 01:09
東方文化?トルコ−イラクあたりか?

291 :仕様書無しさん:04/03/19 01:10
グレープCITY

292 :仕様書無しさん:04/03/19 01:12
単に使っている人達が楽なんじゃないの?>VB
コーディングより出力結果が重要なところもあるっつーことでしょ。


293 :仕様書無しさん:04/03/19 01:14
大学の先生はROM-BASICの頃から自分でプログラム
してた人が多いからその流れだろね。

294 :最凶VB厨房:04/03/19 01:18
出力結果よりコーディングが重要なところってあるけ?

295 :仕様書無しさん:04/03/19 01:19
>>273
正面の敵より、中途半端な奴が嫌いって訳ね。これは納得。
一緒にSunを叩こう

296 :仕様書無しさん:04/03/19 01:20
>>293
ROM-BASICは書いても保存できないでしょ。
DISK-BASICじゃないの? それともNECとかは違ったの?

297 :仕様書無しさん:04/03/19 01:21
>>294
コードの綺麗さがどうとか、再利用がどうとかいっているところかと
ようは暇なところでしょね。

298 :仕様書無しさん:04/03/19 01:22
DISK BASICは、PC DOS 6あたりから無くなったんだよね。
MSとのクロスライセンス解消で。代わりにREXXがついてきたけど。

299 :仕様書無しさん:04/03/19 01:23
>>297
「とりあえず作り始めよう」するから、デスマするんだよ(マジ)

300 :仕様書無しさん:04/03/19 01:24
RTTIできないBCB以外のC++なんて糞だよな?


301 :仕様書無しさん:04/03/19 01:25
最強のC++コンパイラはVC++.NET

302 :仕様書無しさん:04/03/19 01:27
>>299
簡単には作れもしない必要以上のことを
ソフトウェアに望むからデスマするんだよ(マジ)
給与計算なんざバッヂ処理で十分。


303 :仕様書無しさん:04/03/19 01:29
>>300 BCBってボーランド? BCCではなくて?

304 :仕様書無しさん:04/03/19 01:31
QuickBasicが良いよ

305 :仕様書無しさん:04/03/19 01:44
静かになったな

306 :仕様書無しさん:04/03/19 01:47
>>305
ム板に行ったんじゃない?

307 :仕様書無しさん:04/03/19 01:49
×ム板に行ったんじゃない?
○ム板に帰ったんじゃない?


308 :仕様書無しさん:04/03/19 01:55
俺の上司は、少し暇になると簡単には作れもしない必要以上のことを「とりあえず作り始めよう」
と言い出して周りをウンザリさせます。

309 :仕様書無しさん:04/03/19 02:02
>>308 開発系だとそれができないと仕事にならんけどね。それが仕事だから。


310 :仕様書無しさん:04/03/19 03:27
>>303
ボーランドCビルダー。統合環境付き

311 :仕様書無しさん:04/03/19 09:33
Delphiあげ

312 :仕様書無しさん:04/03/19 10:10
給食のおばちゃん(実働180日年収800万退職金2800万)>>>>>>>>>PG

313 :仕様書無しさん:04/03/19 10:22
バスの運転手>>給食のおばちゃん>>>>>>>>>>>>>>>>>>PG

314 :仕様書無しさん:04/03/19 10:26
郵便局の配達員のほうがましだ罠

315 :仕様書無しさん:04/03/19 10:29
郵政外務>>>>>>>>>>>>>>>>>>>PG

316 :仕様書無しさん:04/03/19 10:36
給料、労働時間、責任、福利厚生

市バス>給食>郵外>>>>>>>>>>>>>>>>>>>PG

317 :仕様書無しさん:04/03/19 12:00
まぁ世の中うまく泳げと。給食のおばちゃん最強神話誕生

◆ 警察キャリア(行法経)と検察官と銀行員の年収比較(改)
 年収     官職等
3,131万円 検事総長(63歳)
2,777万円 東京高等検察庁検事長(62歳)
2,558万円 次長検事(60歳)、高等検察庁検事長(59歳)
2,505万円 警察庁長官(57歳)、法務事務次官(検事)、検事一号
2,362万円 警視総監(57歳)
2,206万円 警察庁次長(56歳)、公安調査庁長官(検事)、検事二号
2,058万円 検事(50歳)
1,908万円 警察庁局長(54歳)、法務省局長(検事)
1,744万円 検事(46歳)
1,623万円 警察庁審議官(52歳)、管区警察局長(53歳)
1,300万円 警察庁課長(46歳)、県警本部長(46歳)、検事(40歳)、(民間)東京三菱銀行員(43歳)
1,000万円 ★札幌市バス職員(平均)
 900万円 検事(35歳)、(民間)東京三菱銀行員(35歳)
 800万円 ★学校給食調理員(平均)
 650万円 検事(30歳)、警察キャリア(35歳)
 500万円 警察キャリア(30歳)

318 :仕様書無しさん:04/03/19 12:22
ネタスレ化してきたお陰で、
「俺って頭いいんだぜぇ〜!!」
って言いたいだけのガキが消えたな。

319 :包茎 ◆8fOTfwdIi. :04/03/19 12:25
http://www.google.co.jp/search?hl=ja&ie=UTF-8&oe=UTF-8&c2coff=1&q=%22%E5%AD%A6%E6%A0%A1%E7%B5%A6%E9%A3%9F%E8%AA%BF%E7%90%86%E5%93%A1%22+%E5%B9%B4%E5%8F%8E&lr=
ほ、ほんとだ……凄い

320 :仕様書無しさん:04/03/19 12:34
プログラミングの頭の良さって、スピードの違いだけだと思うが。
知識に馴染んでいてあまり調べないで動かせれば、すなわち頭いい。
でも調べりゃわかる。その程度のものだろ。

321 :仕様書無しさん:04/03/19 12:39
頭の悪い人が必死です

322 :仕様書無しさん:04/03/19 12:46
>>318
まぁ〜元々ネタスレだし、それ以前に板自体がネタ板な
わけだが・・・

323 :包茎 ◆8fOTfwdIi. :04/03/19 12:47
>>320
そうやって君は、保守やる人間が死ぬようなソースを書くわけだね
っていうか日本語なんとかしろ

324 :仕様書無しさん:04/03/19 12:52
給食のおばちゃんは朝が早いです。
無理。。

325 :仕様書無しさん:04/03/19 13:14
でも少子化で今後参入は難しいよ。

326 :仕様書無しさん:04/03/19 13:19
>>234
9時始業だよ。15時に終了。
夏休み1ヶ月半とかとれるし

327 :仕様書無しさん:04/03/19 13:24
>>320
そのスピードは、結構重要なんだが・・・。
物理的生産力で5倍の差だったら俺は見たことがある。
5倍ってすげー差だぞ。内容のレベルは同質でな

328 :仕様書無しさん:04/03/19 13:32
今日のトリビア

PGの悲惨度は、牡丹と薔薇より高い

329 :仕様書無しさん:04/03/19 13:32
給食のおばちゃんを電算化しよう

330 :仕様書無しさん:04/03/19 13:43
      ,,r-─- 、
     / / ⌒`ヽ
     | /      |    
     |/─⊂⊃⊂⊃ 異議あり!給食はんまい!  
     (6     ゝ l   
      `、   〓 /   
      |ヽ _ /  ______ __
     /lヽィ介、/|`´         ||_っィー'
    /  ヽ`Y´/  ,,ィー────┘
ミッチー弁護士

331 :仕様書無しさん:04/03/19 15:01
人を育てる際やリクルートする際に電子回路、電気の基礎技術など
理系の必須項目をきちっと抑えていることを考えていないのではないか?
オブジェクト指向、JAVA、UMLだといっても結局メモリと演算の繰り返しで
トランジスタでon、offしているという認識を持てるかもてないかで
基盤に対する考え方が違うと思う。結局実世界との関係を概念モデルでしか
考えられない技術者が多すぎると考える。

332 :仕様書無しさん:04/03/19 15:03
JAVA シューティング作成委員会
http://pc2.2ch.net/test/read.cgi/tech/1062310183/

333 :仕様書無しさん:04/03/19 15:49
>>300
void型で実現できるっしょ。要するにチミは工夫が足りないんだよ。

334 :仕様書無しさん:04/03/19 15:53
>>333
給食がvoidで実現?

335 :仕様書無しさん:04/03/19 16:01
>334
日下部給食?

336 :仕様書無しさん:04/03/19 17:23
いつもの二人は閏秒で暴れてるのかな。今日は。

337 :仕様書無しさん:04/03/19 19:53
  ┏┳┳┓     ハイ.     ┏┳┳┓
┏┫┃┃┃     Javaは   ┃┃┃┣┓
┃┃┃┃┣┓   ここまで ┏┫┃┃┃┃
┃      ┃┃┏━━━┓┃┃      ┃
┃ Java  ┣┫ . ・∀・ ┣┫. STOP!┃
┗━━━━┛┗┳━┳┛┗━━━━┛
            ┏┻┓┃
        ┏━┛  ┣┻┓
        ┗━━━┫  ┗━┓
.             ┗━━━┛

338 :仕様書無しさん:04/03/19 22:26
double の演算で誤差出る言語仕様が納得いかん。
誤差が出ても良い科学計算に最適化しパフォーマンスを
優先したって、もう言語仕様が金融に向かない。

業務で double 精度の演算が膨大にあって BigDecimal が
かなり嫌いになった。普通に演算子でやらしてくれよと。

BigDecimal を分かってないとか言うテル香具師は
ほんとにこんなものが使いやすいと思ってるのか?

339 :仕様書無しさん:04/03/19 22:27
浮動小数点ならCでもなんでも誤差がでるだろうよ・・・・


と、釣られてみる

340 :仕様書無しさん:04/03/19 22:28
実際javaは人気あんの?

341 :仕様書無しさん:04/03/19 22:32
javaでOS書いた人っている?

342 :仕様書無しさん:04/03/19 22:33
>>339
だから、でかい数 or 小数を扱う演算に
浮動小数点型しか使えない、普通の演算子が使えない
言語仕様が嫌いと言ってんだろ? Cも含めて。

にしても最近の言語なのに大きな欠点だな。

343 :仕様書無しさん:04/03/19 22:36
固定小数点か、貨幣型みたいなのが欲しいと。

やはりVB.NETが最強だわ。

344 :仕様書無しさん:04/03/19 22:39
C#にもあるぞ。っていうか.NET自体にあるんだけどね。

345 :仕様書無しさん:04/03/19 22:40
>>336
閏病の話であそこまで粘着する奴も凄いよな。
実業務でどれほど使う場面が存在するんだ・・・とこっちのすれでも釣ってみる。

346 :仕様書無しさん:04/03/19 22:41
CTSね。

347 :仕様書無しさん:04/03/19 22:47
このスレはマターリ禁止でつよ。

348 :仕様書無しさん:04/03/19 22:51
>>347
じゃあ、

>>345
てめーの狭い視野でものをかたるんじゃねーよ。
そんなシステム幾らでも世の中あるんだよ。

と自作自演してみる。


349 :仕様書無しさん:04/03/19 22:59
未経験者が無料ツールで始めるプログラミング教室
http://www.itmedia.co.jp/news/articles/0403/19/news075.html

死滅したJavaでプログラミング始める奴なんていないけどな。(ゲラ

350 :仕様書無しさん:04/03/19 23:05
>>338
演算子かメソッドコールかなんて、極言すれば単に慣れの問題。
ロートルC使いに媚びて言語仕様の大方針を曲げるような事をしなかったのが
えらいと思うけどねー。


351 :仕様書無しさん:04/03/19 23:07
>>350
じゃあなんでStringに+演算子を作ったのかな?w

慣れの問題を甘く見ないように。可読性に直結している。

352 :仕様書無しさん:04/03/19 23:09
いいぞいいぞ、赤かて白かて、どっちでもいいぞ。

353 :仕様書無しさん:04/03/19 23:10
>>351
C++の演算子オーバーロードの弊害とどっちとるかという話でしょ。


354 :仕様書無しさん:04/03/19 23:10
>>349
MSがjavaなんか勧めるわけねぇだろ。アホか。

355 :仕様書無しさん:04/03/19 23:12
>>353
文字列と同じように、BigDecimalに通常の算術演算子を
使えるようにしろという話でしょ?

356 :仕様書無しさん:04/03/19 23:16
>>355
だから、演算子の前後のオブジェクト型によって、演算子の挙動を
変えることをどこまで許すかってことでしょ。

357 :仕様書無しさん:04/03/19 23:19
>>356
演算子の挙動なんて変えなくていいじゃん。
Stringと同じ。

358 :仕様書無しさん:04/03/19 23:19
>>350
慣れの問題ってw
それ言い出したら何でもそうだろw

359 :仕様書無しさん:04/03/19 23:28
>>287
そんな使い方するんだったらMATLAB使った方がまし。
MATLABは行列演算が容易、得意なうえに
グラフ表示も簡単にできる。

MATLABはオブジェクト指向言語としては糞だが。

360 :仕様書無しさん:04/03/19 23:32
>>283
> まぁでも思うにCOBOLのバッヂ処理で済むような事務仕事を
> なんでjavaはあんな手間隙かけて面倒にやるんでしょうね。
> そこが謎です。
> javaってプログラム組むより電卓叩いたほうが速そうなことばっかり
> いったい何のやくに立つのか...


デザインパターンとかアーキテクチャーパターンとかを勉強すれば
一発でその謎が解けるんだが。


Javaを使わないことは工場を使わずに職人芸でものを作ることを意味するわけだが。
それも、たった一種類の小さな木工品を作るためにわざわざ
工場を使うことはあまりにも無駄で面倒なことであることはあなたの言うとおりですが
複数の形状や構造などが異なる木工品や機械を大量生産するならば
工場を使った方が圧倒的に効率がいいわけです。


361 :仕様書無しさん:04/03/19 23:35
>>295
Apache Jakarta Projectの製品のライセンス形態をろくに理解していない
>>273の言うことなど鵜呑みにするな。
Sunを叩いたところでオープンソースプロジェクトであるApahe Jakarta Projectには何の影響もない。


362 :仕様書無しさん:04/03/19 23:35
>>294
フレームワークやミドルウェアの開発ではコーディングは重要。

363 :仕様書無しさん:04/03/19 23:37
つまり、100円ショップの製品やテレビのような大量生産品にはjavaを使う。
戦闘機や列車のようなものはJavaは使わない。



364 :仕様書無しさん:04/03/19 23:38
>>302
> >>299
> 簡単には作れもしない必要以上のことを
> ソフトウェアに望むからデスマするんだよ(マジ)
> 給与計算なんざバッヂ処理で十分。
そんなこといっているから仕事がドカタ化していくんだよ。
コードの拡張性が低下し他人の作ったコードにはめもくれず
結局一から作り直すという無駄な手間が増える。

それにネットワークを媒介するのは単純な処理では済まされない。
電子銀行などでは確実な処理が重要になるように。


365 :仕様書無しさん:04/03/19 23:39
>>363
100円ショップでは買えない火星探査機コントローラや自動販売機、
クレジットカードにはJavaが使われていますが。

366 :仕様書無しさん:04/03/19 23:40
>>363
Javaが搭載された携帯電話は100円では買えませんが。

367 :仕様書無しさん:04/03/19 23:40
>>363
Javaが搭載された列車もありますが。

368 :仕様書無しさん:04/03/19 23:40
おまいのクレジットカードにはJVMがのってるのか

369 :仕様書無しさん:04/03/19 23:41
>>363
Windowsは戦闘機に使うには不向きですが

370 :仕様書無しさん:04/03/19 23:41
>>363
火星探査機にはJavaが使われますが

371 :仕様書無しさん:04/03/19 23:42
>>368
Javaが搭載されたクレジットカードはすでにありますが

372 :仕様書無しさん:04/03/19 23:42
>>363
Javaを搭載した金融システムは100円やテレビを買う金では買えるものではありませんが。

373 :仕様書無しさん:04/03/19 23:44
軍艦や戦闘機、列車など、大量生産品でないものは今でも職人による手作りである。
これをソフトウェアで例えるなら、再利用性の求められないコードにオブジェクト指向や
デザインパターンを適用することは、無駄な工数、非効率的なコードを生むだけだと
いうことだろう。

374 :仕様書無しさん:04/03/19 23:44
>>365
JavaChipは100円では買えませんが。JavaChipは一個2500円ほどしますが。
C言語Chipなら一個100円で買えるようですがw

375 :仕様書無しさん:04/03/19 23:44
>>373 ← こういうアンチはなにもわかっていない。

376 :仕様書無しさん:04/03/19 23:44
さあ、盛り上がってきますたっ!

377 :仕様書無しさん:04/03/19 23:45
360 名前:仕様書無しさん[] 投稿日:04/03/19 23:32
>>283
> まぁでも思うにCOBOLのバッヂ処理で済むような事務仕事を
> なんでjavaはあんな手間隙かけて面倒にやるんでしょうね。
> そこが謎です。
> javaってプログラム組むより電卓叩いたほうが速そうなことばっかり
> いったい何のやくに立つのか...


デザインパターンとかアーキテクチャーパターンとかを勉強すれば
一発でその謎が解けるんだが。


Javaを使わないことは工場を使わずに職人芸でものを作ることを意味するわけだが。
それも、たった一種類の小さな木工品を作るためにわざわざ
工場を使うことはあまりにも無駄で面倒なことであることはあなたの言うとおりですが
複数の形状や構造などが異なる木工品や機械を大量生産するならば
工場を使った方が圧倒的に効率がいいわけです。

378 :仕様書無しさん:04/03/19 23:46
363 名前:仕様書無しさん[sage] 投稿日:04/03/19 23:37
つまり、100円ショップの製品やテレビのような大量生産品にはjavaを使う。
戦闘機や列車のようなものはJavaは使わない。

373 名前:仕様書無しさん[] 投稿日:04/03/19 23:44
軍艦や戦闘機、列車など、大量生産品でないものは今でも職人による手作りである。
これをソフトウェアで例えるなら、再利用性の求められないコードにオブジェクト指向や
デザインパターンを適用することは、無駄な工数、非効率的なコードを生むだけだと
いうことだろう。


379 :仕様書無しさん:04/03/19 23:48
>>373
> 軍艦や戦闘機、列車など、大量生産品でないものは今でも職人による手作りである。
> これをソフトウェアで例えるなら、再利用性の求められないコードにオブジェクト指向や
> デザインパターンを適用することは、無駄な工数、非効率的なコードを生むだけだと

軍艦や戦闘機、列車は再利用生を求められて設計されていますが。



380 :仕様書無しさん:04/03/19 23:52
>>373
軍艦や戦闘機、列車などに使われるすべての部品が
すべて職人だけの手によって作られるものではありませんが。
数が少ないときだけそういうものが職人芸に頼らざるを得ないだけだが。


コンピュータという論理的な世界に
アナロジーな原始的な職人芸を持ち込むことがそもそもの間違い。

あなたがつくる高層ビルはオフィスにもならない
機能性無き芸術性だけしか持たないサグラダファミリァ大聖堂程度のものですか?

高層ビルを建築するためにあなたはクレーンを使わずに
「職人芸だっ!」といって素手で立てようという馬鹿なことをするのですか?
それは身の程知らずというものです。
身の程知らずどころか他人にも多大な迷惑をかけます。

大規模開発では素直にデザインパターンやアーキテクチャーパターンを使いなさい。

381 :仕様書無しさん:04/03/19 23:53
大量生産の民生品でいいじゃん。java

382 :仕様書無しさん:04/03/19 23:54
>>380

360にいえよw

383 :仕様書無しさん:04/03/19 23:55
>>373
> 軍艦や戦闘機、列車など、大量生産品でないものは今でも職人による手作りである。
あなたはそれらをすべて職人だけでしか作られないと勘違いしています。
個々の部品は職人だけでは作ることはできません。

それらの大型機器は事前にコンピュータで緻密にシミュレートし計算し試行錯誤、
テストを繰り返しなから設計されてゆくものです。

それがオブジェクト指向設計、テスト駆動開発というものです。

> これをソフトウェアで例えるなら、再利用性の求められないコードにオブジェクト指向や
> デザインパターンを適用することは、無駄な工数、非効率的なコードを生むだけだと
> いうことだろう。


384 :仕様書無しさん:04/03/19 23:56
>>373
総論同意。
「非効率的なコード」っていうのはほとんどの場合、問題にならないけど
「無駄な工数」が発生するのは事実だなあ

#多量少品種生産と少量多品種生産の比喩は、
#ソフト開発を論じるには不適切のような・・・

385 :仕様書無しさん:04/03/19 23:56
>>363
Javaライセンスは100円ショップや電気屋で買えるようなものではありませんが

386 :仕様書無しさん:04/03/19 23:56
建売住宅なら、大量生産の汎用建材をドカタに組ませれば完成するし、品質も安定するだろう。

しかし、一品物の高層ビルは建築士による設計と、熟練工による作業、専用部品の製造が必然的に発生する。

387 :仕様書無しさん:04/03/19 23:59
まあ、大規模=馬鹿を頭数揃えてローラー作戦なわけで。
職人好きな方が想定しているであろうところの職人の能力を持つひとなんて、
ほとんどいないわけで。
Javaで大規模=馬鹿ばっかりだけど何とかしようという悲惨な試みなわけで。
そういうのはJava言語の性質がドウノコウノと全く関係無い話で破綻すること
が多いわけで。

388 :仕様書無しさん:04/03/19 23:59
つまり、デザインパターンを設計と例えるのなら、Javaで使われている開発手法は
大規模開発に適切なことになる。

本当に誤ったのは、>>.360がこれらの開発手法を工場による大量生産に例えたことにある。

批判は>>360にどうぞ。

389 :仕様書無しさん:04/03/20 00:00
Java厨ってこんなにアフォぞろいなんだな。

390 :仕様書無しさん:04/03/20 00:01
小規模って楽しいよね
クラフトマンシップを限界まで発揮できるよ

391 :仕様書無しさん:04/03/20 00:03
C厨の一方的勝利か。

392 :仕様書無しさん:04/03/20 00:05
>>384
> 総論同意。
部分的に同意と答えないあなたはの見識には疑わざるを得ません。

> 「非効率的なコード」っていうのはほとんどの場合、問題にならないけど
> 「無駄な工数」が発生するのは事実だなあ
すでにできあがったシステムに途中から職人がコードを追加する分には
使えないコードは一時的に破棄する、で済まされやすいことですが
職人が無計画に一から書いたコードは後継者に多大な負担をかけ
チームワークを台無しにします。

むしろ設計書を見ずに開発する一般プログラマの職人と
設計書大型機械を製造する職人とは一緒にするべきではありません。

> #多量少品種生産と少量多品種生産の比喩は、
> #ソフト開発を論じるには不適切のような・・・
いずれにしても 軍艦や戦闘機、列車などを製造する職人を
木工や陶芸などを作る職人と一緒にすることは不適切。


393 :仕様書無しさん:04/03/20 00:11
Java以外の言語でも仕様書はあるのよ〜

394 :仕様書無しさん:04/03/20 00:12
デザインパターンとかアーキテクチャーパターンだけが設計じゃない罠

395 :仕様書無しさん:04/03/20 00:12
>>384
ならばプログラミングは建築に喩えるのがふさわしい。


最近ではEmacsやApache Ant, JUnit, CVSなどの開発環境(ビルドツール)
が充実してきて新たな開発手法パラダイムが生まれた。

昔はコーディングしながら必死に最適化することばかり考えていた。

しかし今は試行錯誤と開発効率を重視するため最適化は二の次である。
よってできあがったアプリケーションは最初は遅いものになるが
完成後に最適化を行うことで開発効率を一挙に高めることができる。

さらに、Javaを上手に使った開発では、

まず最初にJavaで開発ありき、
次にJavaからC++に移植し最適化せよ。
という順序を守ると開発効率が格段に向上する。
最近ではJavaをネイディブコンパイルするツールや
C++コードに変換するツールも数多くある。

最初からC++でコーディングするよりも最初からJavaでコーディングしたほうが
コードを綺麗に保ちやすくバグが少ない。
Javaでバグを削ってからそれをC++に写し最適化する。これ最強。


396 :仕様書無しさん:04/03/20 00:12
SunのJVMはどうやって設計されていますか?

397 :仕様書無しさん:04/03/20 00:13
>>391
すでにC厨は昨夜一方的に敗北していますが何か


398 :仕様書無しさん:04/03/20 00:14
C厨ってやっぱりデザインパターンも理解できないこんなアフォ揃いだな

399 :仕様書無しさん:04/03/20 00:15
批判は>>360にどうぞ。

400 :仕様書無しさん:04/03/20 00:17
>>388
> つまり、デザインパターンを設計と例えるのなら、Javaで使われている開発手法は
> 大規模開発に適切なことになる。
>
> 本当に誤ったのは、>>.360がこれらの開発手法を工場による大量生産に例えたことにある。
どこが誤りなんだ?
工場にたとえることはふつうに行われていることだが。

GoFデザインパターンで有名な

Factory Method パターン、
Abstract Factoryパターンを知っているか?


それなりの副作用もあるがなにもやらないよりままし。
どこにこいつらを適用すべきかをセンスよく考えれば開発効率は格段に向上するぞ。

今からでも遅くない、有名なデザインパターン23種くらい覚えれ。簡単だから



401 :仕様書無しさん:04/03/20 00:19
>>392
まるで文化大革命だね(w
同志よ共に共産主義の理想を実現しよう。
まずは計画経済だ。
5カ年計画でクラスを設計しよう。

402 :仕様書無しさん:04/03/20 00:19
設計士による設計に例えたらってことだろ?


403 :仕様書無しさん:04/03/20 00:20
>>395
>昔はコーディングしながら必死に最適化することばかり考えていた。

これは間違いだよ

昔からのプログラマだって、まともな人は
ワインバーグの本はもちろんProgramming Pearls
Writing Efficient Programを読んでいたよ

404 :仕様書無しさん:04/03/20 00:20
>>387
> まあ、大規模=馬鹿を頭数揃えてローラー作戦なわけで。
> 職人好きな方が想定しているであろうところの職人の能力を持つひとなんて、
> ほとんどいないわけで。
> Javaで大規模=馬鹿ばっかりだけど何とかしようという悲惨な試みなわけで。
アフォだな。ではUnixやWindowsは一人の人間だけの手によって開発されたとでも
思っているのか? 当初はオブジェクト指向など使われなかったが
OSの開発にはコアな部分を除いて徐々にオブジェクト指向が使われるようになったぞ。

それもしらずにJavaで大規模が馬鹿ばっかりだと? ふざけるのもいい加減にしろ。


405 :仕様書無しさん:04/03/20 00:21
ソフトウェアの設計手法はデザインパターンだけではありません。

406 :仕様書無しさん:04/03/20 00:22
まあ、360の時点で壮絶な自爆だなw

407 :仕様書無しさん:04/03/20 00:25
デザインパターンと唱えただけで誰でも極楽浄土に逝けるのです。
ありがたや、ありがたや。こうとなえて
1998年java厨はデザパタ真宗を興した。


408 :仕様書無しさん:04/03/20 00:25
そう。Javaは工場である。
金髪や茶髪のDQN工員に効率よく一定品質のものを大量生産せせるための機構なのである。

Javaでデスマってる開発室に行けば、彼ら工員によく似た専門学校卒の派遣PGが馬車馬のように
働かされているであろう。

409 :408:04/03/20 00:26
つまり、>>360の逝っている事は全く的を射ている。

410 :仕様書無しさん:04/03/20 00:27
>>401
お前は資本主義というものが一人だけでなんでもできると関知がしている。
資本主義という世界は一人ではなにもできない仕組みだ。
全部一人だけで開発できると思っているなら
お前は「資本」なしで一人だけで九州から北海道にまで行ってみろ。
お前は「資本」なしで自給自足の生活を送ってみろ。
お前が九州から北海道に行くためには鉄道やバス、飛行機などの交通機関が必要だ。
お前は鉄道を自分で敷設することはできない。
他人の力を借りずにすべて自分でやりたいと思うなら鉄道を
自分で敷設していかなければならない。

もし他人の力を借りたくなければ昼食もすべて自分でとりたければお前はレストランに行ってはならない、
今からお前は畑を耕し、狩りをし、漁をするなどして食料を確保し、
その食料を自分で加工し、自分で調理しなければら無い。
お前は一人では何もできないのだ。

「資本」というのは複数人の努力によって成り立っている者だ。

お前が目指しているものは所詮、「専制政治」であることにすぎないのだ。



411 :仕様書無しさん:04/03/20 00:28
>>406
> まあ、360の時点で壮絶な自爆だなw
あれで自爆だってw
どう見たってお前の脳内自爆だろw


412 :仕様書無しさん:04/03/20 00:29
>>394
彼はそれを前提にして説明しているのだからそうやって馬鹿にするべきじゃない

413 :仕様書無しさん:04/03/20 00:30
>>410
君が言っていることを裏返せば
資本さえあれば(金かければ)、
資本主義ではなんでも一人でできるのでは?
漏れはそうは思わないがね(w


414 :仕様書無しさん:04/03/20 00:31
>>408
一昔前はCOBOLだったよね。いまはJava。ほんの少し前はVB。

415 :仕様書無しさん:04/03/20 00:34
>>408
> そう。Javaは工場である。
> 金髪や茶髪のDQN工員に効率よく一定品質のものを大量生産せせるための機構なのである。
>
> Javaでデスマってる開発室に行けば、彼ら工員によく似た専門学校卒の派遣PGが馬車馬のように
> 働かされているであろう。
いい加減に現実を見ろよ真性DQNのC厨w
そのたとえは違うな。
Javaそのものが工場で。
Javaプログラマを工場と工場を動かす部品を造る側なんだよ。
ドカタはC厨だよw

Abstract Factoryパターンのクラス図を見てみろよw

上位JavaプログラマはAbstractFactoryクラス、AbstractProductクラスを継承して
ConcreteFactoryクラス、ConcreteProductクラスを設計し
下位Javaプログラマはそのフレームワークを利用して工場を使う。
そしてその工場のなかで必死に最適化処理を行うのは
それらのJavaコードから変換されたC++コードを必死に最適化するC厨の仕事だよw



416 :仕様書無しさん:04/03/20 00:35
>>413
馬鹿だねチミ、資本=金と直結するとかしか考えないアフォですね。

417 :仕様書無しさん:04/03/20 00:36
>>414
 >>408のような煽りを煽りとも思わず鵜呑みにするあなたの人格を疑います。

418 :仕様書無しさん:04/03/20 00:37
納品された部品をアッセンブルして大量生産するところが工場ですよ。

419 :仕様書無しさん:04/03/20 00:37
>>407
デザインパターンなんて基礎中の基礎。
それしら理解できないC厨にデザインパターンを紹介してやるために
デザインパターンを説明してやったことをありがたいとも思わずに
そのような無礼な態度をとるのか貴様は!

420 :仕様書無しさん:04/03/20 00:38
部品を組み立てるだけか〜。韓国みたいだなw

421 :仕様書無しさん:04/03/20 00:39
Javaはサムソン電子ですか?

422 :仕様書無しさん:04/03/20 00:39
デザパタ覚えたてのやりたいサカリ馬鹿が今年も引っかかったみたいですね。

423 :仕様書無しさん:04/03/20 00:40
僕らは工場で生産する製品のデザインをしよう。

君らは工場でうまく生産する方法を考えてくれ。
むかし作ったクラスとやらの焼き直しでいいんだろ?簡単だよな。
もし君がうまくできないんなら海外に工場うつすんで
そのつもりで頑張ってね。もちろんその時、君は用なしだよ。


424 :仕様書無しさん:04/03/20 00:40
きみらまだこの問題も解けないの?
あれから一日も経っているのにw
小学生でも解る問題もとけないなんてC厨はやっぱりその程度なんだねw

230 名前:仕様書無しさん 投稿日:04/03/19 00:21
さてさて、>>184の続きをしようではないか。

BigDecimal.valueOf(100000000000000000000).add(BigDecimal.valueOf(300000000000000000000).multiply(BigDecimal.valueOf(500000000000000000000)))

こいつを訂正するには↓

public BigDecimal calculate(){
 return new BigDecimal(new BigInteger("100000000000000000000").add(new BigInteger("300000000000000000000").multiply(new BigInteger("500000000000000000000"))));
}

これでひとまずコンパイルエラーは避けられた。
しかしこれは綺麗なコードではない。

さて問題だ。これを綺麗なコードにするにはどうするか?
あとは簡単だw
これができなければキミたちはプログラマ失格だw

425 :仕様書無しさん:04/03/20 00:40
サムソンJavaにJVMを納品しますタ

426 :仕様書無しさん:04/03/20 00:42
バカはJavaとデザインパターン(アーキテクチャ、イディオムはもちろんPLoP Vol.1すら読んだことない)
おまけでXPとアジャイルぐらいしか知らんからな

427 :仕様書無しさん:04/03/20 00:42
>>420
馬鹿も休み休み言え。
ならば日本の自動車生産に代表された加工貿易はどうなのだ?
海外から材料を輸入してそれを組み立てただけで売りさばいていただろう。

428 :仕様書無しさん:04/03/20 00:42
デザインから、開発まで出来る俺には関係ない話しだべ。



429 :仕様書無しさん:04/03/20 00:43
デザパタ宗の言うことは嘘だ。我等がデザパタ真宗こそが
正しく継承をしておる。渇!!

430 :仕様書無しさん:04/03/20 00:44
工場とは、N中国人工員を集めて、効率的に大量生産するための施設である。
しかしその工場で中国人が使っている工作機械は、職人達により手間隙かけて作られた日本製である。

431 :仕様書無しさん:04/03/20 00:44
>>426
それをいうなら

バカはCしか(デザインパターン、XP、アジャイルアーキテクチャ、イディオムはもちろんPLoP Vol.1すら読んだことない)
知らない。
おまけで構造体ぐらいしか知らんからなw


432 :仕様書無しさん:04/03/20 00:44
>>428
お前はデザインもイディオムも知らないw

433 :仕様書無しさん:04/03/20 00:45
>>429
お前の態度に喝

434 :仕様書無しさん:04/03/20 00:45
アジャイルアーキテクチャワラタ

435 :仕様書無しさん:04/03/20 00:45
本を読んでできる気になる

436 :仕様書無しさん:04/03/20 00:46
>>427
海外から部品を輸入して組み立ててるだけなのは韓国の自動車会社ですが。何か?
日本は部品から作ってますよ?あなたはそんなことも知らない厨ですか?

437 :仕様書無しさん:04/03/20 00:46
>>422
ほんと、デザインパターンどころかクラスの使い方を覚えたてのサカリ馬鹿C厨が今年も引っかかったみたいですね。


438 :仕様書無しさん:04/03/20 00:47
>>434
> アジャイルアーキテクチャワラタ
そんな用語はないが
おまいの脳内用語ですか?

439 :仕様書無しさん:04/03/20 00:48
日本製工作機械は職人さんのカンで作られている。
職人さんの手は機械では計測できない誤差を感じ
修正することができる。


440 :仕様書無しさん:04/03/20 00:48
>>436
五十歩百歩国が何を言う。アメリカを見習え。このアフォ右翼が

441 :仕様書無しさん:04/03/20 00:48
public BigDecimal calculate(){
 return new BigDecimal("1E20").add(new BigDecimal("3E20")).multiply(new BigDecimal("5E20"));
}

一応。


442 :仕様書無しさん:04/03/20 00:48
>>439
しかしCPUの開発はそうはいかない

443 :仕様書無しさん:04/03/20 00:49
>>442
SH-Mobile大変らしいね

444 :仕様書無しさん:04/03/20 00:49
H8のようにはいかない

445 :仕様書無しさん:04/03/20 00:50
>>440
ププッ知らない厨ですか?

446 :仕様書無しさん:04/03/20 00:52
そのとおり。Javaは工場である。
金髪や茶髪のDQN工員に、効率よく一定品質のものを大量生産させるための機構なのである。

Javaでデスマってる開発室に行けば、彼ら工員によく似た専門学校卒の派遣PGが馬車馬のように
働かされている姿を見ることができるだろう。




447 :仕様書無しさん:04/03/20 00:53
>>441
おや、C厨は馬鹿だけど学習能力あるみたいですねw
それだけではまだまだ綺麗になったとはいえませんね。

448 :最凶VB厨房:04/03/20 00:53
外見だけで判断するのは頭の悪い人間の陥りやすい罠である。

449 :仕様書無しさん:04/03/20 00:53
>>446
> そう。Javaは工場である。
> 金髪や茶髪のDQN工員に効率よく一定品質のものを大量生産せせるための機構なのである。
>
> Javaでデスマってる開発室に行けば、彼ら工員によく似た専門学校卒の派遣PGが馬車馬のように
> 働かされているであろう。
いい加減に現実を見ろよ真性DQNのC厨w
そのたとえは違うな。
Javaそのものが工場で。
Javaプログラマを工場と工場を動かす部品を造る側なんだよ。
ドカタはC厨だよw

Abstract Factoryパターンのクラス図を見てみろよw

上位JavaプログラマはAbstractFactoryクラス、AbstractProductクラスを継承して
ConcreteFactoryクラス、ConcreteProductクラスを設計し
下位Javaプログラマはそのフレームワークを利用して工場を使う。
そしてその工場のなかで必死に最適化処理を行うのは
それらのJavaコードから変換されたC++コードを必死に最適化するC厨の仕事だよw

450 :J2EE使いですが:04/03/20 00:54
>>446
Java全体をそう考えるのは反対だけど、J2EEプログラミングは
まさにそれだと思う今日この頃。

451 :仕様書無しさん:04/03/20 00:54
>>441
もっと綺麗にしなさい。
このさい、最適化のことは優先しないこと。

452 :仕様書無しさん:04/03/20 00:55
>>450
そうだね。

453 :仕様書無しさん:04/03/20 00:55
>>450
派遣プログラマにJ2EEという高度な技術を取り扱うことはできません

454 :仕様書無しさん:04/03/20 00:55

僕らは工場で生産する製品のデザインをしよう。

君らは工場でうまく生産する方法を考えてくれ。
むかし作ったクラスとやらの焼き直しでいいんだろ?簡単だよな。
もし君がうまくできないんなら海外に工場うつすんで
そのつもりで頑張ってね。もちろんその時、君は用なしだよ。

ああ、デジャブュッ


455 :仕様書無しさん:04/03/20 00:56
工場とは、中国人工員を集めて、効率的に大量生産するための施設である。
しかしその工場で中国人が使っている工作機械は、職人達により手間隙かけて
作られた日本製である。


456 :仕様書無しさん:04/03/20 00:56
>>450
J2EEはDQNには扱えない敷居が高い代物。

457 :仕様書無しさん:04/03/20 00:57
C厨の哀れなコピペが始まりましたw

458 :仕様書無しさん:04/03/20 00:58
C厨、また今夜も敗北宣言かw
情けないぞC厨。
過去の業績はどうした(ワラ

459 :仕様書無しさん:04/03/20 00:59
public BigDecimal calculate(){
 return BigDecimal.valueOf((1+3)*5).movePointRight(20*20);
}

んじゃこういうの?

460 :仕様書無しさん:04/03/20 00:59
>>456
そりゃキミが現場を知らないからだよ。
単純化された個々の作業を大量のドカタに投げて人海戦術で片付けるのさ。
殆どのケースでデスマになる。

461 :最凶VB厨房:04/03/20 01:00
類は友を呼ぶという奴だなww

462 :仕様書無しさん:04/03/20 01:00
上流での切り分けが失敗しててまたデスマ

463 :仕様書無しさん:04/03/20 01:00
>>451
アンタ、人にもの聞くときは「教えてください」だろ。
しかもいつまで、その話してんだ。空気嫁。

464 :仕様書無しさん:04/03/20 01:01

それにしてもこのスレ読んでいると
やっぱjavaの未来って暗いかなと...
他の言語も勉強したほうがいいでせうか?

465 :最凶VB厨房:04/03/20 01:02
>>464
VBを勉強しなさい。
VBは君の未来を明るくしてくれる。

466 :J2EE使いですが :04/03/20 01:02
>>456
システムのアーキテクチャ設計する人とかは賢い人じゃないと無理だろう
けどさ、EJBだのServletだのJSPそのものを書くのは、多少頭のよい工場
労働者程度の作業でしかないとおもうですよ。マジデ。

467 :仕様書無しさん:04/03/20 01:03
>>464
>>457君や>>458さんに助言を頂いたらどうかな?

468 :仕様書無しさん:04/03/20 01:05
>>464
たとえ将来安泰だとしても 1 言語べったりじゃ話にならん。
視野も狭くなるし。

469 :J2EE使いですが:04/03/20 01:06
>>466のつづき
つうか、そういうことができるようにしたのがJ2EEの存在意義。

頭のよい人ばっかりならRMIやCORBAの時点で何とかなったはず。全然流行んな
かったのは「PGと呼ばれる人間の大部分を占める馬鹿PGには難しすぎて技術者
人口が増えなかったから。」
アホを囲い込むのが至上命題。J2EEはそのための戦略。

470 :最凶VB厨房:04/03/20 01:07
そこでアホのすすめですよ

471 :仕様書無しさん:04/03/20 01:07
そこでVBによるCOMですよ。アフォでも組める

472 :仕様書無しさん:04/03/20 01:10
>>465
もともはfortranからやってます。あとVB/perlは多少できます。
というか触ったことがあります。
VBは凄いなあと思いましたが、実用になるのか..みたいな不安がありました。
でもあれも細かいところが良くわかりませんね。
C/C++ってのはやはりPGとしては必修でしょうか?


473 :仕様書無しさん:04/03/20 01:11
>>471
VB6は個々の作業はドカタでもできるが、分割して人海戦術で片付けるのにはちょっと。
VB.NETやJ2EEのほうが向いている

474 :最凶VB厨房:04/03/20 01:12
VB、VBって言ってきたけれど、Javaに乗り換えようかな

475 :仕様書無しさん:04/03/20 01:12
>>474
裏切り者!!!!!!

476 :仕様書無しさん:04/03/20 01:12
J2EE は WebLogic、WebSphere、Oracle が儲けるための道具。
EJB や JSF などオプソがあまり整備されていない部分で。

だいたいアーキテクトなんか PJ にほんの少しいればいい。
あとはフレームワークに沿って PG が実装すればいい。

477 :最凶VB厨房:04/03/20 01:13
>>472
細かいところを知りたいというのであれば
アセンブリはどうだろうか?
http://black.sakura.ne.jp/~third/programming/asm/assembly.html

478 :仕様書無しさん:04/03/20 01:14
そこでJBossですよ。お父さん

479 :仕様書無しさん:04/03/20 01:15
システムのアーキテクチャ設計とかエンタープライズなんて案件、
だってほとんどないんだもの(みつを)

480 :最凶Java厨房:04/03/20 01:15
心、入れ替えます。

481 :仕様書無しさん:04/03/20 01:16
アーキテクチャ設計なんて顧客にひっくり返され、PGに恨まれるためにあるようなものだ

482 :仕様書無しさん:04/03/20 01:16
ジサクジエンキター

483 :仕様書無しさん:04/03/20 01:17
>>478
その JBoss も EJB に愛想つかして JBoss4 で AOP に
走ってるしな。

484 :仕様書無しさん:04/03/20 01:17
>>477
あああ、そういう意味じゃなくて言語使用の細かいところです。
ASMなら68系だけやったことがあります。8086は知りません。


485 :仕様書無しさん:04/03/20 01:17
なんだかしおらしくなってきました。

486 :最凶VB厨房:04/03/20 01:20
>>484
男ならなんでもいいから一つバチッと決めて
かじって食いついて丸呑みせんかい!

487 :仕様書無しさん:04/03/20 01:21
そこでMASM.NETですね。

488 :仕様書無しさん:04/03/20 01:26
>>469
これは同感。ソフトウェア開発の職人芸から工業化は昔から言われて来た。
そこで、構造化、4GL、ADSG、DOA、OO、RADとか色々なメソッドやツールはあるが、
1つの(ある程度まとまった)形がJ2EEやフレームワークとツール群。

理屈上は、言語はJavaでなくても同じ事はできるけど、
実際にできているのは今ではJavaが筆頭。

大半のPGは部品の組み立て工なので、それほどプログラミングの才能はいらない。
品質も平均化する。

489 :仕様書無しさん:04/03/20 01:54
javaとその周辺ツールが工場であり、大量のDQN工員で効率よく一定品質の製品を製造
するための設備であることはわかった。では、その工場の経営者であるSunやIBMがどう
やって工員を募集しているのか見てみよう。

 「バカでもできる作業員募集!!」

こんな謳い文句ではPGは集まらない。基本的にPGはその実力に関わらずプライドが高い
のだ。
 まず、彼らはオープンソースを巧みに使い、PGがその崇高なそのコミュニティの一員と
なれる勘違いさせることで勧誘する。Eclipse等はそのための餌である。松本智頭夫の空
中浮遊写真とは少々異なるが。
 次に上昇志向を満たすためにキャリアアップの道を示す。如何にもセレブを感じさせる、
「エンタープライズ・アーキテクト」がそれである。現実には、システム開発創生期から変
わらぬ我侭なユーザーと、DQN工員の板ばさみになる緩衝材、サンドバックに過ぎない
のだが。。。いや、個々のPGの作業がより単純化されるだけに、その作業の負担は増して
いるかもしれない。



490 :仕様書無しさん:04/03/20 02:38
バカでもできるってw

できるならバカじゃないじゃん。矛盾している。

491 :仕様書無しさん:04/03/20 02:55

javaつーのは手段のためなら目的を選ばず、って感じ。

手間が増えようが、規模がどうであろうがどうでもいいのだ。
何よりもjavaであることが優先される。
烈しく無意味かも。


492 :仕様書無しさん:04/03/20 03:08

javaってのは部品の組み立て(コードの記述)前に、プロジェクトに関わるチームすべての者が
何十冊何千行もの開発手法に関するテキストを読み、その内容を完全に理解、
マスターしていなければならないようだ。

それをしなければシステムの設計もコードの再利用もできないらしい。

そんなことをしているうちにチームはどれだけの仕事ができるだろう。
コード記述以前の事前勉強の時間でコードを再利用しないで最初から書き直すぐらいの
ことは十分できそうだ。こんなんじゃほんと無意味じゃないのかな。


493 :仕様書無しさん:04/03/20 03:16
>>492
かなりストレスがお溜まりのようで。
まあ、Javaのリーダーとかは文系出身のオブジェクト指向しか知らない人だったりするから、
そういうことにもなるんでしょうな。

494 :包茎 ◆8fOTfwdIi. :04/03/20 03:20

メールってのはタイピング(本文の記述)前に、コミュニケーションを取る相手全てが
何十冊何千行ものコンピューター入門書を読み、その内容を完全に理解、
マスターしていなければならないようだ。

それをしなければメーラーの起動もメールの送受信もできないらしい。

そんなことをしているうちに人間はどれだけの意思疎通ができるだろう。
本題の記述以前の事前勉強の時間で葉書を書いてポストに入れるぐらいの
ことは十分できそうだ。こんなんじゃほんと無意味じゃないのかな。

495 :仕様書無しさん:04/03/20 03:54
>>494
そうそう。そういう香具師ですわ。
どうでもいいような電話一本で済む内容をメールでだらだら書いてきて
普段からやたらどうでもいいような文章やネチケットとかに五月蝿い香具師っていますよね。
メーリングリストとかで関係ないことで人にイヤミ言うタイプ。
頭はいいんだろうけど、チームにこういう香具師が混じってるとほんと疲れる。マジで。



496 :仕様書無しさん:04/03/20 03:59
ドカタ言語ですから。

497 :仕様書無しさん:04/03/20 04:04
ほんとsunの売り子かこやつは?と思うことしばし。
アメリカのなんとかちゅー書物のなんとかつー手法がどうたら
ディスクに積み上げて仕事もせんでそんな話ばかりしとりますわ。
エディタ起こしているのほとんどみたことなかったり。
こんなんでもPG名乗ってんだから世も末かと。

498 :仕様書無しさん:04/03/20 04:48
Javaは簡単と言われるも、ほとんどのJavaプロジェクトが
トラブルを起こしているような気がする。
なぜなら、無能な単なる偽サラリーマンSEが設計の真似事をし、
PGにコーディングさせようとするからである。
無能なサラリーマンSEは、設計などできないのである。
設計〜実装までをこなせない人間はクズである。



499 :仕様書無しさん:04/03/20 07:16
>>498
JAVAが一番輝く大規模Web系では、設計と実装は別の人があたりまえ。

設計した人が実装もできるけど、その状態になっていたら死の行軍です。


500 :仕様書無しさん:04/03/20 08:16
>>499
実装もできない、自分の非を絶対に認めない。立場上優位なおばかな
設計者のプロジェクトが死の行軍だろ。


501 :仕様書無しさん:04/03/20 09:10
>>500
それは設計能力がないだけ。
実装能力と設計能力を同列で語るのって日本の悪いところ。

普通の建設業界で、大きい仕事で設計者と大工が同じ能力を求められるか?
それぞれの専門家がやるだろ?

単にこの業界の未熟さにあなたが染まってるだけだよ。

502 :仕様書無しさん:04/03/20 09:28
>>501
>設計能力ないだけ。
といいますが、その設計能力は現場から知らないと
この業界に限らず優秀なリーダーになるとは思えませんが。
俺は現場を知らなくても、リーダーになれるというのは技術者じゃない。
じゃまだからひっこんでろ。

現場をしらない、新人がいきなリーダーとかなれるこの業界が未熟なのが問題。


503 :仕様書無しさん:04/03/20 09:47
 501は、もっと視野を広げないと会社にすがる下らない人間になっちまうぞ。
バックに会社がないと設計者にもなれないんだろう?
バックに会社がなく、裸の一個人として独立できるか、否か考えてみろよ。
君の意見を皆に納得させるためには、現場を知っていて的確な指示が必要となってくるだろう。

幸いにも、君はバックに会社がある。君のトンチンカンな意見、指図にも
立場的に弱い方々が、合わせてくれているんだよ。(感謝するんだな)
現場を知る必要がないと錯覚しているのは、君が会社に依存している証拠だ。

本当の専門家になりたければ、泥まみれになって現場を知ることだな。
そういう努力が出来ない人間は、それなりの成果、人生しかおくれない。
たいていは、三流とまりなので、リーマンに一流になれとはいいませんけどね。
三流は三流なりに、謙虚になって、じゃまはしないでください。



504 :仕様書無しさん:04/03/20 10:01
あのさ、PLと設計者と製造を混同してないか?
ほんとに大規模システムやったことあるのか?
10人程度ならPL兼設計者兼PGリーダーでいいよ。

それ以上だったら、役割分担は当然。

で、役割分担と出来ることは別だと理解できてないでしょ?


505 :仕様書無しさん:04/03/20 10:15
>>504
規模がどんなに大きくても、小さくても根本は同じ。
上に立つものは現場を知ることは必要だろ。

役割分担はあって当然でそれに対して異論はない。

ただ、現場をしらないPL、設計者が監督やっちゃいけない。
さらに、現場を知る必要は無い。と考えている。痛い方は引っ込んでもらいたい。

経験を積んでいない、現場を知らない大工がいきなり東大寺の修復はやらないだろ。
それがこの業界では出来ちゃうんだよな。いわゆるSヨ。


506 :504:04/03/20 10:20
まあ、私は>>499を書いたんだけどね。
500でずれてるんだよな、論点が。

507 :仕様書無しさん:04/03/20 10:32
Jakarta Projectは実装者と設計者の関係はどうなっているのだろうか。
少なくともPG経験の無い文系SEが設計者でないことは間違いないだろう。

508 :仕様書無しさん:04/03/20 10:33
設計者とマネージャーを混同していないだろうか。

509 :仕様書無しさん:04/03/20 10:36
個々の作業が分割しやすく統合しやすい、人海戦術ドカタ開発に向いたJavaだからこそ
設計者が重要なのだ。個々の作業をイメージング出来ない無能者に、設計を要求すること
は無謀である。PGの経験は必要ないかもしれないが、経験が無いとイメージングしにくい
のが現実である。

510 :仕様書無しさん:04/03/20 10:41
実際には顧客と工員、上司の板挟みになってノイローゼになるだけなんだけどね。

511 :仕様書無しさん:04/03/20 10:44
もっと話を戻すと、>>498がいうことはある程度正しいと思う。
だが、そんな奴を100人集めたら幾らかかる?

各プロジェクトのリーダークラスを集めて製造できるなら誰も苦労はしないよな。

512 :仕様書無しさん:04/03/20 10:48
設計の方法論は、確かに現場のドカタにとっても全体にとっても効率的な設計を
定義づけている。それに従えば、優秀な設計ができるであろうことは間違いない。

しかし、優秀な方法論と優秀な設計は別であり、それを現場に適用するのは設計者の
能力次第である。少なくとも、方法論の優秀さと設計の優秀さの区別が出来ない無能者
には不可能なのではあるまいか。そして、現場の工員より設計者のほうがミスの波及する
範囲が広く、より責任は重要である。間抜けな設計を平然と行った設計者が、
「お前も現場に行ってツルハシ振って来い!」
と罵倒されるのは当たり前である。

513 :仕様書無しさん:04/03/20 10:51
×:重要である
○:重大である

514 :仕様書無しさん:04/03/20 10:53
今日の格言:
「オブジェクト指向を適用しようがデザインパターンを導入しようが、設計者がゴミなら設計もゴミ」

515 :仕様書無しさん:04/03/20 10:53
今日の格言:
「設計者に現場の経験が有ろうが無かろうがバカはバカ」

516 :仕様書無しさん:04/03/20 11:02
Javaの現場がデスマになりがちなのはSEが無能だからってこと?
PGはバカでもOKなんだよね?(藁

517 :仕様書無しさん:04/03/20 11:14
確かにJavaは工場である。
DQN工員でも作業できるように分割・単純化し、統合を容易にする。
しかし、そもそも、それらの設計論が構築された現地のDQN工員と、日本のDQN工員には
差異があるのではないだろうか。日本以外の国でも金髪や茶髪で将来のことも考えていない
低学歴専門学校卒の派遣PGが工員として働いているのだろうか。

518 :仕様書無しさん:04/03/20 11:18
日本の開発現場では、工員を紙カード時代のキーパンチャーのように捉えていないだろうか
実は流行の設計論ではPGをただの作業員としてではなく一定水準のPGと定義しているのでは
ないではなかろうか 古来の流儀で都合よく解釈しているだけではなかろうか
工員であるPGのスキルを低く見積もりすぎることは設計者の負担が増すばかりではなかろうか



519 :仕様書無しさん:04/03/20 11:18
阿南ニ尉>>>>>>>>>>>>>>>>>>PG

520 :仕様書無しさん:04/03/20 11:27
>>516
つまり、Javaの人海戦術ドカタ現場は上から下までアフォばかり。と。

521 :仕様書無しさん:04/03/20 11:52
そもそも、XPだのデザインパターンやオブジェクト指向等の実際の現場での適用が
誤っているのではという認識は無いだろうな。SEさんたちは。
だから、PGに「現場経験が無いアフォは駄目だ」と言われるんだよ。
たぶん、何故言われるのかすら理解出来ないだろうけど(w

どんなに優れた理論でも、千差万別の現場に適用して開発作業を運用するのは
設計者やPLの能力次第。優れた理論を導入した(つもり)から設計者やPLが優秀では
無いのさ。理論は銀の弾丸かもしれないが、それで狙いをつけて撃つのは人間なんだな。



522 :仕様書無しさん:04/03/20 11:55
>>504
PMとQAとアーキテクトとデザイナーとデベロッパ
じゃダメ?

523 :仕様書無しさん:04/03/20 11:55
つまり、Javaの人海戦術ドカタ現場は上から下までアフォばかり。と。

524 :仕様書無しさん:04/03/20 12:00
建築現場でも新工法の現場への適用を誤ったら、「現場に行って来い!カス!氏ね」
といわれますよん。

525 :仕様書無しさん:04/03/20 12:04
>>464
ほかのスレも嫁。いや、ほかのサイトも嫁。
このスレに集まっている香具師は単なるJava嫌いなC厨の巣窟。
考え方が古くさく時代遅れなんだよ。
それともお前は釣り師か?


>>465
それではますます未来が暗くなってゆくものだなw

526 :仕様書無しさん:04/03/20 12:06
>>460
君は実にハッタリ釣り馬鹿だなぁ〜(AA略

527 :仕様書無しさん:04/03/20 12:10
>>459
> public BigDecimal calculate(){
>  return BigDecimal.valueOf((1+3)*5).movePointRight(20*20);
> }
>
> んじゃこういうの?

あなたは相当の馬鹿ですね。

↓これと結果が全くことなることも解らないようですね。
public BigDecimal calculate(){
 return new BigDecimal(new BigInteger("100000000000000000000").add(new BigInteger("300000000000000000000").multiply(new BigInteger("500000000000000000000"))));
}

あなたみたいなヴァカがいるからバグが増え続け多くの人が迷惑を受けることを
わかっていますか?


528 :仕様書無しさん:04/03/20 12:12
>>441
> public BigDecimal calculate(){
>  return new BigDecimal("1E20").add(new BigDecimal("3E20")).multiply(new BigDecimal("5E20"));
> }
> 一応。

そもそも、整数だけの演算にBigDecimalを使っても無駄だということを
あれほど言ったにもかかわらずまだ理解していないようですね
C言語厨は池沼ですか?

529 :仕様書無しさん:04/03/20 12:14
>>511
マジレスだが。「そんな奴」を集めるのが、事実上、一番安上がりなんだ

530 :仕様書無しさん:04/03/20 12:16
>>476
> J2EE は WebLogic、WebSphere、Oracle が儲けるための道具。
アフォ言え。JBossはそうじゃねえぞと。JBossではJBoss Groupはそう簡単に
儲からないぞと

531 :仕様書無しさん:04/03/20 12:17
>>483
JBoss4でEJBが使えないと勘違いしている臭い香具師

532 :仕様書無しさん:04/03/20 12:18
JBossを選択したばっかりに、現場でJBossのデバッグをする羽目になったり。

533 :仕様書無しさん:04/03/20 12:19
>>489
Eclipseが餌か(ワラ
ならVS.NETはVB厨やVC++厨をひきつけるための格好の餌だなw

534 :仕様書無しさん:04/03/20 12:20
>>491
その性格をもつものはドトネトだろ

535 :仕様書無しさん:04/03/20 12:22
>>493
> >>492
> かなりストレスがお溜まりのようで。
> まあ、Javaのリーダーとかは文系出身のオブジェクト指向しか知らない人だったりするから、
> そういうことにもなるんでしょうな。
相変わらずそのような偏見を持っているクズには呆れる。
文系馬鹿はオブジェクト指向しらりかいできないクズが多いのが現実。
目に見えるものしか真実に見えない馬鹿どものあつまりだからな。
哲学ができるやつなら少しは理解できるみたいだが、それ以外はほとんど理解できない。
それゆえに文系はVB厨の巣窟化している。
文系はM$のマーケティングに騙されやすいしドトネトにも填りやすい。

536 :仕様書無しさん:04/03/20 12:23
プロジェクト全体の効率を考えないとどんな理想を語っても無意味。
会社は人に勉強や実験をさせるために雇っているわけじゃない。
仕事しようよ。現場経験が無いアフォは駄目だ


537 :仕様書無しさん:04/03/20 12:24
>>498
その問題を勝手にJavaのせいにしているお前も無能

538 :仕様書無しさん:04/03/20 12:25
>>536
オマエサンが適材適所という言葉をしらずに人のいっていることを脳内変換していないかと
疑ってみる。

539 :仕様書無しさん:04/03/20 12:26
javaが悪いんじゃないんですよ。

540 :仕様書無しさん:04/03/20 12:27
>>535
文理で分けてるのって餓鬼の論理か?


541 :仕様書無しさん:04/03/20 12:28
適材適所できるぐらい人員に余裕があれば誰も苦労しないと言ってみる

542 :仕様書無しさん:04/03/20 12:28
>>507
そもそもオープンソースプロジェクトの開発体制を理解していないなお前。
コミッタとコントリビュータという香具師がいるわけだが。

オープンソースの世界ではだれでも設計者、実装者になれる。
だが設計者、実装者になれても自分の設計と、実装がコミッタに受け入れられなければならない。



543 :仕様書無しさん:04/03/20 12:29
>>541
限られたリソースの中でそれを割り振るのがプロジェクト管理というもの。

544 :仕様書無しさん:04/03/20 12:29
>>540
それをいうなら>>492のような餓鬼に言え

545 :仕様書無しさん:04/03/20 12:30
さあ、盛り上がってまいりますた

546 :仕様書無しさん:04/03/20 12:30
>>509
> 個々の作業が分割しやすく統合しやすい、人海戦術ドカタ開発に向いたJavaだからこそ
いい加減にその曲解はやめたらどうだ。
人海戦術ドカタ開発に向いた言語はオブジェクト指向も使えないC言語のような言語をいう。


547 :仕様書無しさん:04/03/20 12:31
>>545
おまえのせいで盛り下がった

548 :仕様書無しさん:04/03/20 12:31
C厨にとってJavaはますます驚異のものになっていくんだろうな。

549 :仕様書無しさん:04/03/20 12:31
>>546
そうだよな。
Cだと言い訳なしで何でもできるから、それこそ人海戦術が効く。

550 :仕様書無しさん:04/03/20 12:33
そうだな。CができるPGが一番多いし。集めやすい。

551 :仕様書無しさん:04/03/20 12:33
オブジェクト指向とアジャイルを否定している香具師がいるが
いつまでも否定して何も学習しようとしないのは視野が狭すぎる証拠だ。
そんなことだから大規模開発でデスマに陥る。



552 :仕様書無しさん:04/03/20 12:34
>>549
それだったらC++のほうが現実的だろ

553 :仕様書無しさん:04/03/20 12:34
>>550
Cが一番多いといったらまさにピラミッドの最下層に位置するドカタじゃねえかと

554 :仕様書無しさん:04/03/20 12:35
>>552
C++はそれをきちんと扱えるPGを集めるのに苦労する。
生Cはルールが単純なのでいい。

555 :仕様書無しさん:04/03/20 12:35
>>550
大学の授業でCをやったと言い張る馬鹿が新卒に入り込んで(ry
嫌な凝った。奴らはデスマ製造機だ。

556 :仕様書無しさん:04/03/20 12:36
>>554
ということはJava。
Cはデザインパターン使えないし

557 :仕様書無しさん:04/03/20 12:36
>>554
ということはD言語
Cはデザインパターン使えないし

558 :仕様書無しさん:04/03/20 12:36
>>555
そんなのどの言語でも一緒だ。

559 :仕様書無しさん:04/03/20 12:37
火事場にデザインパターンなどいらん。

560 :仕様書無しさん:04/03/20 12:38
やっぱりこいつらJavaを否定しておいてC言語しかしらねえ奴だったのか・・・
デザインパターンくらい簡単だから覚えろってのが。
それを覚えればCしかできない馬鹿に
C++でクラスの上手な使い方を教えられるってのに。


561 :仕様書無しさん:04/03/20 12:39
Javaは常にデスマになると言い張るバカがいるが、それはデザインパターンの適用が
誤っているからである。Javaやデザインパターンが悪いわけじゃない。

562 :仕様書無しさん:04/03/20 12:39
>>559
火事場にいらん? んなこたあない。即座に作れるものを否定するか。

いらんのは組み込み系だろ?
携帯電話Javaですらリソースの問題からデザインパターンを適用する余裕どころか
継承や例が処理を使う余裕すらない。


563 :仕様書無しさん:04/03/20 12:40
あのさ、デザインパターンは言語に関係ないよ。
デザパタ覚えて使いたがるのは、猿のおなにい。
パターンを使うために設計をゆがめるとかやるからね。w


564 :仕様書無しさん:04/03/20 12:40
>>561
うっさいぞお前。Java厨のフリをしたC厨。
それで自演していないと見せかけて説得力あるつもりか


565 :仕様書無しさん:04/03/20 12:41
被害妄想おびてきますた

566 :仕様書無しさん:04/03/20 12:41
>>563
おい、お前。、 >>563 == >>561
だろ。自作自演してまで自分がCしかできないことの威信を保ちたいか?

567 :仕様書無しさん:04/03/20 12:42
>>566
違うし、反論になってないから議論にならないよ。

568 :仕様書無しさん:04/03/20 12:43
C厨が最初にJavaを否定したときはまっさきに「Javaは遅い」であり
Javaを勉強する手間を省きたいばかりにその言葉を常套句にすることで
Javaプロジェクトから逃げてばかりいたわけだが、
最近ではその常套句もほとんど通用しなくなっているのが現実。

569 :仕様書無しさん:04/03/20 12:44
>>568
クライアントサイドのJAVAが壊滅したからね。
サーバーサイドは否定しないけど、クライアント用途じゃJAVAVMがだめ。

570 :仕様書無しさん:04/03/20 12:44
>>531
そんなわけねーだろ。オサーンのために EJB は残すだろ。

571 :仕様書無しさん:04/03/20 12:44
>>563
アフォですかと。
他人がデザインパターンを使って設計したAPIの使い方が
わからないからデザインパターンすら否定して必死に自己弁護しているだけだろお前。

572 :仕様書無しさん:04/03/20 12:45
>>569
クライアントサイドではJNLP, JavaWebStartが息を吹き返すと言われている。

573 :仕様書無しさん:04/03/20 12:46
タダの配列で何も問題ないものまでIteratorとかなw

574 :仕様書無しさん:04/03/20 12:46
>>569
JAINが突如クライアントサイドで力を発揮する可能性もあり

575 :仕様書無しさん:04/03/20 12:46
>>572
言われている・・・。
JAVAを全否定はしないけど、何度そんなことを言ってたことか・・・。

576 :仕様書無しさん:04/03/20 12:47
>>574
可能性も・・・。

なんつうか、普通に普及して安定して使えるのは何年後になるんだ?

577 :仕様書無しさん:04/03/20 12:47
>>573
そういうことは設計者に文句を言えと。
納得がいかないなら配列版を自分で実装してみろと。

しかしだ、メソッドの引数にjava.util.Listをとるようにする
手法は便利で使えるぞ。


578 :仕様書無しさん:04/03/20 12:49
>>571
なんでそうレッテル張りに躍起かな。

579 :仕様書無しさん:04/03/20 12:49
>>556-557
×デザインパターン
○GOF本に載っているデザインパターン

>>563
そだね。

580 :仕様書無しさん:04/03/20 12:49
>>573
あるある。
なんでこんな凝ったことする必要あんの?これってどう考えても順次参照しないしみたいな


581 :仕様書無しさん:04/03/20 12:49
>>575-576
お前みたいなのがXMLを否定し
XMLの導入に抵抗していた抵抗勢力の典型なのか。
「XMLはまだ標準化されていないから(ry」
とかいって引っ込み思案でXMLを使おうとすらせず遅れをとっているわけだ。

582 :仕様書無しさん:04/03/20 12:50
>>578
Java叩いている奴のほうがレッテル張りが多いけど。
ドカタだとかJavaしか知らないだとかな

583 :仕様書無しさん:04/03/20 12:50
>>577
禿同。Javaが悪いわけでもデザパタが悪いわけでもない

584 :仕様書無しさん:04/03/20 12:51
>>579
アホ、CだけではGoF以外のデザインパターンも仕えねえぞC厨

585 :仕様書無しさん:04/03/20 12:51
>>583
意味不明。Javaは関係ないだろと

586 :仕様書無しさん:04/03/20 12:51
>>581
空想豊かですね。私がそんなに想像されてしまうなんて。

XMLってただのファイル形式の一種。それ以上それ以下なし。
使うときは使うし、不要なら使わないし。
大体、プログラム組むときには、XMLを意識しないでも組めるし。


587 :仕様書無しさん:04/03/20 12:51
鯖は Java、蔵は Flash、.NET、Curl とかでいいじゃないか。
リッチクライアントがこなせない Javaだけ厨 はイラネ。ってかダメポ。

588 :仕様書無しさん:04/03/20 12:53
オナニーに夢中のデザパタ厨は氏ねってこった

589 :仕様書無しさん:04/03/20 12:53
>>587
いや、その通りだと思うけどね。
JAVAに夢を託してる人が必死すぎて。


590 :仕様書無しさん:04/03/20 12:54
>>586
XMLを理解したつもりになっている臭い。

XMLはオブジェクト指向言語で使った方が使い勝手がよろしいし。

ただのファイル形式であるこたああたり米田路が。
XMLを使っているAPIではXMLから離れることは容易ではない上に
XMLを使ってくれないと嫌がる顧客もいる。

591 :仕様書無しさん:04/03/20 12:54
そう?イテレータくらいCでも書けるだろ。


592 :仕様書無しさん:04/03/20 12:54
>>587
> リッチクライアントがこなせない Javaだけ厨 はイラネ。ってかダメポ。
こういう香具師がレッテル張りという

593 :仕様書無しさん:04/03/20 12:55
>>584
どうも「デザインパターン」という言葉の定義が違う様だね。
俺の定義は「設計の雛型」だ。
君の定義を言って見てくれ

594 :仕様書無しさん:04/03/20 12:57
>>590
XMLは単なるインターフェースの定義であって、別に顧客が嫌がるレベルじゃない。
顧客にとって必要か不要かの二択だ。


595 :仕様書無しさん:04/03/20 12:58
>>587
証券とかは Flash とかのリッチクライアントは必須だな。

596 :仕様書無しさん:04/03/20 12:58
システムを構築する目的が、
デザインパターンを使うこととか、XMLを使うことになってるだろ。

597 :仕様書無しさん:04/03/20 13:00
考え中

598 :仕様書無しさん:04/03/20 13:01
>>589
お前はなにもわかっていない。
Javaを推す理由をわかっていない。

599 :仕様書無しさん:04/03/20 13:02
どんなに優れた理論でも、千差万別の現場に適用して開発作業を運用するのは
設計者やPLの能力次第。優れた理論を導入したから設計者やPLが優秀なのでは無い。



600 :仕様書無しさん:04/03/20 13:02
>>598
じゃあ列挙してみ。


601 :仕様書無しさん:04/03/20 13:02
給食のおばちゃん>おまいら

602 :仕様書無しさん:04/03/20 13:02
>>594
それがだ、XMLフォーマットを標準にしているアプリが増えてきている。
顧客が技術素人でない場合はXMLのことで細かい要求をしてくることもある

603 :仕様書無しさん:04/03/20 13:04
ゴミ収集の茶髪のあんちゃん>おまいら

604 :仕様書無しさん:04/03/20 13:04
>>599
デザパタの優秀さと、それを使いこなすことは別なのにね。
当然、適用するのが不適切な場合も多い。


605 :仕様書無しさん:04/03/20 13:04
>>598
こんなのは嫌いか?

鯖Java + 蔵Flash
ttp://itpro.nikkeibp.co.jp/free/NC/TOKU1/20030812/1/

606 :仕様書無しさん:04/03/20 13:05
>>602
それはそれぞれのアプリの問題でしょ?
Apacheとかの定義がXMLだとかは知ってるよ。

XML万能主義とか一個の技術しか見えていないと、技術馬鹿と呼ばれるよ。

XMLの適用に馴染まないデータ交換とかも実際にあるし。
(大量かつ特定相手間のインターフェースとか)

607 :仕様書無しさん:04/03/20 13:05
くそう。今日のC厨はGOFを知ってやがる

608 :仕様書無しさん:04/03/20 13:06
STOP看板をもって交通整理をする米公務員>おまいら

609 :仕様書無しさん:04/03/20 13:07
吸殻を片付けるのが専門の某国公務員>PG

610 :仕様書無しさん:04/03/20 13:07
いつもの逃亡がはじまりますた

611 :仕様書無しさん:04/03/20 13:09
社会の最底辺のゴミPGがえらそうに

612 :仕様書無しさん:04/03/20 13:09
(^ー^)ノま、どうあがいても99.99%のPGは、ゴミなのですよ

613 :仕様書無しさん:04/03/20 13:10
その点、エンタープライズ・アーキテクトですよ。

614 :仕様書無しさん:04/03/20 13:10
JAVAを押す理由はまだ?

615 :仕様書無しさん:04/03/20 13:11
いや市役所でしょ。

616 :仕様書無しさん:04/03/20 13:11
逃亡age

617 :仕様書無しさん:04/03/20 13:12
中卒で地方初級市役所>>>>>>>>>>>>>>>>>>>PG

618 :仕様書無しさん:04/03/20 13:12
>>607
ワラタ
cしか知らないと、GOFを知っている人はほとんどいないんだよ
だからXX厨って言い方をヤメレ

619 :仕様書無しさん:04/03/20 13:13
C厨がGOFをしってても糞の役にもたたねえけどな。
給食のおばちゃん以下だ。カスどもwwww

620 :仕様書無しさん:04/03/20 13:13
>>598
ほんまは Java でいっぱいいっぱいで、それ以外は
もう覚えれないんでしょ? 悲しいね。

621 :仕様書無しさん:04/03/20 13:14
OOで給食のおばちゃんをこえてください(w
ポインタで清掃員をこえてください(w

622 :仕様書無しさん:04/03/20 13:15
つうか、今時Cしか出来ない奴とかJavaしか出来ない奴がいるのかよw

623 :仕様書無しさん:04/03/20 13:16
職業
1.会社員 2.自営業 3.公務員 4.アルバイト 5.主婦 6.無職 7.その他( PG )

624 :仕様書無しさん:04/03/20 13:16
>>622
Cしか出来ない奴・・・このすれのC厨
JAVAしか出来ない奴・・・このスレのJAVA厨

625 :仕様書無しさん:04/03/20 13:17
>>622
C と Java しか出来ない香具師は多い。

626 :仕様書無しさん:04/03/20 13:18
今日もJava厨は逃げたか

627 :仕様書無しさん:04/03/20 13:18
>>624
で、おまいは両方ろくに出来ないと。

628 :仕様書無しさん:04/03/20 13:19
今までの経験言語。

C、C++、JAVA、VB、Delphi、ふぉーとらん、88ベーシック
・・・そしてファミリーベーシック&V3.


629 :仕様書無しさん:04/03/20 13:19
(^ー^)ノへいへーい。好きでプログラマーやってる人ならともかく、言語で云々罵り合ってる連中げんきー?
職業でやるなら、公務員に勝るものはないぞー(w

630 :仕様書無しさん:04/03/20 13:20
>>626
ん?鯖ではJava最強ですよ。IoC が熱いですよ。

631 :仕様書無しさん:04/03/20 13:21
で、JAVAを押す理由は?

632 :仕様書無しさん:04/03/20 13:21
>>630
ん?国内では公務員最強ですよ。公務員試験競争が熱いですよ。

633 :仕様書無しさん:04/03/20 13:22
今日もJava厨は逃げたか

634 :仕様書無しさん:04/03/20 13:22
>>631
そいつは逃げたみたい。

635 :仕様書無しさん:04/03/20 13:23
>>632
国内だけじゃなく全世界でだ
資本主義大国のアメリカでは、日本以上に公務員が勝ち組みになっている

636 :仕様書無しさん:04/03/20 13:23
>>634
煽りじゃなくて、議論の下地になるかと楽しみにしてたのに。


637 :仕様書無しさん:04/03/20 13:23
JAVAを推す理由
ナウイから

638 :仕様書無しさん:04/03/20 13:24
市役所ねえ。。
マジレスすると、駅前再開発の担当になったりするとなかなか大変みたいよ。
Bな人とか893な人とかZな人のの立ち退きとか。家族が脅迫されたり。

639 :仕様書無しさん:04/03/20 13:25
>>633
HiveMind、XWork、Spring、Pico、SeasarV2 いいですよ。
.NET はそのうちパクるんだろーな。

640 :仕様書無しさん:04/03/20 13:25
>>638
最近はプロ市民こないよー
事務員に化けた警察官が窓口にいるから

641 :仕様書無しさん:04/03/20 13:26
>>637
ヤングがイカしてるね。

642 :仕様書無しさん:04/03/20 13:26
JAVAを推す理由は
バージョンが大量にあって、欠点をそれで埋めてるから

JAVAを推さない理由は
バージョンが大量にありすぎて、崩壊が目に見えてるから

643 :仕様書無しさん:04/03/20 13:26
>>640
いや、自宅に脅迫電話がかかってくんのよ。

644 :仕様書無しさん:04/03/20 13:27
>>643
ないよー

645 :仕様書無しさん:04/03/20 13:28
JAVAを推す理由
.NET厨の本音はこんなだから
http://pc2.2ch.net/test/read.cgi/tech/1033489735/546

646 :仕様書無しさん:04/03/20 13:29
まあ、そう思い込んどきな。
すれ違いのなで終了

647 :仕様書無しさん:04/03/20 13:30
>>646
本音を暴露された .NET 厨が逃げ出しました。

648 :仕様書無しさん:04/03/20 13:30
>>642
バージョン問題ってDLLHell以上に酷いよな。
いろいろ組み合わせてるうちにバージョン限定、その環境限定に近くなるし。

649 :仕様書無しさん:04/03/20 13:31
>>647
市役所の話ですよ。どこに.net厨がいますか?ノイローゼですか?

650 :仕様書無しさん:04/03/20 13:32
JAVAを推す理由
ちょっとだけ馬鹿でも扱えるから女が多い

VBを推す理由
かなり馬鹿でも扱えるから女も同数

結論:馬鹿でも使えるVBはイケてる。でも役所には勝てない

651 :仕様書無しさん:04/03/20 13:32
市役所の職員に電話なんてしたら一発で刑事事件にされるぜ
プロ市民はそんな危険なことはしません

652 :仕様書無しさん:04/03/20 13:33
さあ、不法投棄業者の事務所に踏む込む勇気が君に有るか。


653 :仕様書無しさん:04/03/20 13:33
>>648
自由な組み合わせを取るかの問題だな。
メインフレームとか .NET のように 1 社独占の時代はバージョン問題は
起こりにくいな。

654 :仕様書無しさん:04/03/20 13:35
>>650
俺 Java 厨だけど、VB は女が多いのか。
VB にしようかな・・・

655 :仕様書無しさん:04/03/20 13:35
話題を逸らそうと必死な奴がいるスレはこちらですか。

656 :仕様書無しさん:04/03/20 13:36
>>655
自作自演までしてるが、相手にされてないよ。

657 :仕様書無しさん:04/03/20 13:37
でさ、JAVAを♂、李優さん(中国人)はまだ?

658 :仕様書無しさん:04/03/20 13:38
>>657
なにそれ?

659 :仕様書無しさん:04/03/20 13:40
まとめてDVDに焼けば無問題ですが。何か?

660 :仕様書無しさん:04/03/20 13:42
ってか現状 Java を推さない理由を教えてよ。
それとなにが良いですか?

鯖Java + 蔵Flashとかのリッチクライアント がいいと思う。
枯れ具合、実績、現状の仕事量で。

661 :仕様書無しさん:04/03/20 13:43
何を焼くの?

662 :仕様書無しさん:04/03/20 13:43
>>660
プロジェクトによって選ぶだけ。
選択肢の一つ。

663 :仕様書無しさん:04/03/20 13:45
>>662
では、Amazon のようなシステムの場合、何を使う?

664 :仕様書無しさん:04/03/20 13:46
>>663
”Amazon のようなシステム”ってどういう奴?

665 :仕様書無しさん:04/03/20 13:47
Perl

666 :仕様書無しさん:04/03/20 13:47
在庫管理、WEB販売、予約、発注管理、顧客管理ってとこだろ。

プログラミング☆レシピ+SQLServerかな?

667 :仕様書無しさん:04/03/20 13:47
>>662
ほんとか? 方式設計者が得意なものを使うのが現実だろ。

668 :仕様書無しさん:04/03/20 13:48
サーバ、COBOL
クライアント、VB


669 :仕様書無しさん:04/03/20 13:48
>>668
サーバー側は安定してますな(w

670 :仕様書無しさん:04/03/20 13:49
>>664
詳細な要件定義が欲しいのか? めんどくさいよ。

671 :仕様書無しさん:04/03/20 13:49
>>669
じゃあクライアントはPowerCOBOLにしとくか?

672 :仕様書無しさん:04/03/20 13:50
ねぇねぇそんなにプログラミング大好きなの?
正直、金を得る手段じゃないの?
なんで、これから賃金が悪化するってわかってる業界にとどまるの?

673 :仕様書無しさん:04/03/20 13:51
>>672
今の日本でこれから賃金が悪化しない業界があったら教えてくれ。
公務員でさえ怪しいぞ。

674 :仕様書無しさん:04/03/20 13:52
公務員が危ういって?
日本の将来の形のアメリカみてこいよ。公務員最強神話は万国共通だよ

675 :仕様書無しさん:04/03/20 13:52
と、ITバブル崩壊で尻の毛まで抜かれた無職が申しております。

676 :仕様書無しさん:04/03/20 13:53
>>672
それじゃあ、いい仕事教えてくれよ。

677 :仕様書無しさん:04/03/20 13:53
>>672
金を得るだめだが、俺はプログラミング大好きだよ。
でも PG でプログラミング嫌いっていう香具師いるね。
転職しろよって思うけど。

678 :仕様書無しさん:04/03/20 13:53
旧ソ連の公務員が最強

679 :仕様書無しさん:04/03/20 13:53
>>674
ここで政治を語るのはなんだけど、アメリカの公務員が安泰?
80年代の赤字時代から90年代にかけて何をやったか知ってるのか?

680 :仕様書無しさん:04/03/20 13:55
>>679
無知は放置汁

681 :仕様書無しさん:04/03/20 13:55
この板にいる香具師って、みんなプログラミング大好きだと思ってた。
違うの?

682 :仕様書無しさん:04/03/20 13:56
>>677
そういう人は、プログラマーでいい。
よーするに金を得るためだけにプログラマーって人で、このスレで罵り合ってるのはアホじゃないか?と
言いたい。

>>679
はい安泰です。
国家は名義変更大好きです

683 :仕様書無しさん:04/03/20 13:57
>>681
最初は嫌いで嫌いでしょうがなかったです。
痛いだけで何もよくないし。
でも、彼が上で必死な顔をしているのがなんとなくいとおしくて。

でも、半年ぐらいして・・・

684 :仕様書無しさん:04/03/20 13:58
>>681
いや。単純にそうとは言い切れない。
java厨は、おそらく18〜24歳くらいが主流だと思う。
最初に会社で習った言語、もしくは自分が最初に覚えた言語だったってだけで支持しているやつも多くいるように見受けられる

685 :仕様書無しさん:04/03/20 13:58
JDKファイナルバージョンとか出して
面白おかしく最期を迎えてほしい。

686 :仕様書無しさん:04/03/20 13:59
JavaファイナルバージョンX
とかな(w

687 :仕様書無しさん:04/03/20 14:00
バブル崩壊後はなりたくてPGになった奴ばかりじゃないんだよ。
80年代は零細ソフト会社にバイトに行ってはまり込み、そのまま居座った奴とかいたけどね。

688 :仕様書無しさん:04/03/20 14:00
>>684
プログラミング大好きと特定言語厨は相反するのか?

689 :仕様書無しさん:04/03/20 14:01
>>681
言語の雑談が好きな人はプログラミングも好きだとは思うんだけど
「生半可な知識と経験しかない教えたがり屋」や「そのような人を貶めることが楽しい人」
はどうなのかなあ?

690 :仕様書無しさん:04/03/20 14:01
>>688
プログラミング大好きって人はおのずといろんな言語触るから一長一短を知ってる。
あえて特定言語支持者に見せかけてこのスレを煽ってるやつも結構見受けられるがな(w

691 :仕様書無しさん:04/03/20 14:02
>>687
そういう香具師がこの板に来るか?
しょうがなしに質問スレには来るかもしれんけど。

692 :仕様書無しさん:04/03/20 14:02
>>681
オマエ、単細胞だな。

693 :仕様書無しさん:04/03/20 14:03
>>691
全然興味なくても、自分のやっている言語(仕事)をけなされるとムカツクってことはあるだろうさ

694 :仕様書無しさん:04/03/20 14:04
>>690
このスレや死滅スレに居る香具師はプログラミング大好きだと思う。

695 :仕様書無しさん:04/03/20 14:05
>>692
で、おまいはプログラミング大好きなのか?

696 :仕様書無しさん:04/03/20 14:06
>>694
プログラミング大好きなら言語に偏ることはない。
いやお得意の言語というのは生まれるがな

697 :仕様書無しさん:04/03/20 14:07
>>691
会社の休憩中の雑談みたいなもんだよ。
大好きを強要するなよ。

698 :仕様書無しさん:04/03/20 14:07
さあ、活気が戻ってまいりますた

699 :仕様書無しさん:04/03/20 14:07
それを楽しむスレですから

700 :仕様書無しさん:04/03/20 14:09
プログラミング大好きな人たちの給料ってどんなもん?
プログラミング好きは、えてしてプログラミングも得意だから評価されてるだろ?会社で。
年収おいくら?

701 :仕様書無しさん:04/03/20 14:10
>>696
死滅スレで言語の利点が分かる。信用度は 20% ?
欠点の信用度は 5% くらいか?知らないで欠点言う香具師多いし。

702 :仕様書無しさん:04/03/20 14:10
無職うざい

703 :仕様書無しさん:04/03/20 14:12
>>700
自称フリー 700 万くらい。十分っす。

704 :仕様書無しさん:04/03/20 14:14
会社員450万(額面)

705 :仕様書無しさん:04/03/20 14:15
たかいじゃーん

706 :仕様書無しさん:04/03/20 14:26
派遣PGの年収ってどれくらい?

707 :仕様書無しさん:04/03/20 14:26
>>703
5年後も700万、10年後は雇ってくれない。

708 :仕様書無しさん:04/03/20 14:27
と、無職が申しています。

709 :仕様書無しさん:04/03/20 14:29
で、結局JAVAを押す理由は?

710 :仕様書無しさん:04/03/20 14:38
>709
なんとなく

711 :仕様書無しさん:04/03/20 14:47
>>709
現状、推さない積極的な理由が無いから。

712 :仕様書無しさん:04/03/20 14:58
>>709
仕事量の割に、マが少ないから。今は。

713 :仕様書無しさん:04/03/20 15:49
給食のおばちゃんって1000人以上(最近の学校はもっと少ないか?)の
命を預かってるわけだからおまいらより給料が高いのは当たり前

714 :仕様書無しさん:04/03/20 16:09
>>596
> システムを構築する目的が、
> デザインパターンを使うこととか、XMLを使うことになってるだろ。
藻前の脳内でのみな

715 :仕様書無しさん:04/03/20 16:12
>>604
> >>599
> デザパタの優秀さと、それを使いこなすことは別なのにね。
あなたはまだまだ何もわかっていないようですね。
デザインパターンは経験則ですが。
C++/JavaすらやらずにC言語ばかりやってオブジェクト指向にはろくに手を出さなかった
結果あなたはデザインパターンに対する勘違いを引き起こしているようですね。


> 当然、適用するのが不適切な場合も多い。
たとえば具体的にどういうもの?


716 :仕様書無しさん:04/03/20 16:14
>>701
> >>696
> 死滅スレで言語の利点が分かる。信用度は 20% ?
> 欠点の信用度は 5% くらいか?知らないで欠点言う香具師多いし。

あれだけじゃわからねえよ。
うそばっかりついているやつが集まっているんだからな。
技術系メーリングリストや専門家による比較、論文のほうが言語の利点はよくわかる。


717 :仕様書無しさん:04/03/20 16:27
>>709
> で、結局JAVAを押す理由は?
押すんじゃなくて推すだろヴォケ。

初心者にJavaを推す理由は
●オブジェクト指向を習得しやすいこと、
●コンパイラの厳しいエラーメッセージがプログラマに厳しいバグ対策を要求し
バグの少ないプログラムを作ることを強いらせる。
●C/C++/C#/Dなどの言語に似ておりそれらの他の言語への以降も、またその逆も容易。
●Javaを習得しておけば他のどんなオブジェクト指向言語の習得も怖くない。
●C++やC#にあるような尾てい骨やむだ毛のような余計な機能を切り落とし
重要な機能を使うことに専念でき開発効率を高めている。
●多くの専門家が未来のプログラミング言語はJavaのような言語になると言っている。
●C#, D言語などをみてもわかるように未来のプログラミング言語はJavaベースとなり、
今Javaを習得して将来Javaの代替が登場してもほとんど困らない。そのとき、
C++の大半のコードとくらべ、Javaコードを他の新言語に移植することが容易。
●未来のプログラミング言語がJavaライクなものになる以上、
今Javaでプログラミングしておけば将来それらの資産が無駄になる可能性は
非常に低い。


718 :仕様書無しさん:04/03/20 16:27
XMLがあればCSVはいらない

719 :仕様書無しさん:04/03/20 16:29
>>718
XMLは汎用的だが、特定業務の場合は不要だな。
データ量を無駄に増やすだけ。


720 :仕様書無しさん:04/03/20 16:29
>>717
初心者て・・・・

お客様に御酢理由ですよ

721 :仕様書無しさん:04/03/20 16:32
>>717
言ってることは間違ってはいないが、同じことを繰り返して言っていないか?
3つ目以降は不要だし、多くの専門家というあたりが弱い。自分の言葉でしゃべれ。

実際のところ、後発のC#のほうが良いと思う部分はあるけどね。

722 :仕様書無しさん:04/03/20 16:33
>>606
> >>602
> それはそれぞれのアプリの問題でしょ?
> Apacheとかの定義がXMLだとかは知ってるよ。
その程度しかしらないヴァカか貴様。

> XML万能主義とか一個の技術しか見えていないと、技術馬鹿と呼ばれるよ。

> XMLの適用に馴染まないデータ交換とかも実際にあるし。
> (大量かつ特定相手間のインターフェースとか)

どうやら、このスレには
相変わらずXMLとか新しい用語など苦手なことを話題にされると
すぐ勝手に「XML万能主義」だとか勝手にXML一個の技術しか考えていないと
脳内変換するヴァカがいるみたいだな。

こういう固定観念を持つヴァカは40代の脳が退化して頭が堅くなったおっさんじゃねえのか?

どんなデータフォーマットもXMLにしなきゃならんと勝手に決めつける餓鬼か貴様は。
画像や音声をXMLだけで管理したいとほざくか貴様は。
RDBMSだけで管理できるものをすべてXMLだけで管理したいか貴様は。

勝手に脳内変換するな糞餓鬼。


723 :仕様書無しさん:04/03/20 16:34
>>720
テンプレートを作るのが面倒くさいので今は後回し。
客に推す理由など無い。顧客や発注の立場として推す理由を示してやることならできるが。


724 :仕様書無しさん:04/03/20 16:35
>>722
日本語が相変わらず読めない人だね。
どこにそんなことが書いてるんだ?
あなたが妄想してつなげた内容に自分で反論してどうするんだ?



725 :仕様書無しさん:04/03/20 16:36
>>721
> >>717
> 実際のところ、後発のC#のほうが良いと思う部分はあるけどね。
クライアントサイドでのみWindowsのシェアが大きいからとか
使える値型の種類が多いとかオペレーターオーバロードが多いとか
プロパティだとかインデクサ程度でC#のほうがいいとかぬかさないように。

726 :仕様書無しさん:04/03/20 16:36
>>724
日本語が読めないのはあなたですw

727 :仕様書無しさん:04/03/20 16:37
>>723

728 :仕様書無しさん:04/03/20 16:37
>>724
XMLを主唱したくらいで勝手にXML万能主義と脳内変換する
あなたのほうが妄想が大きいのに自己否定してどうするんだ?w

729 :仕様書無しさん:04/03/20 16:38
>>726
じゃあさ、元の文書のどこに

>どんなデータフォーマットもXMLにしなきゃならんと勝手に決めつける餓鬼か貴様は。
>画像や音声をXMLだけで管理したいとほざくか貴様は。
>RDBMSだけで管理できるものをすべてXMLだけで管理したいか貴様は。

って書いてある?
そういうことを言う奴を否定した文書なんだけどね。

730 :仕様書無しさん:04/03/20 16:39
>>728

> 718 名前:仕様書無しさん 本日のレス 投稿日:04/03/20 16:27
>XMLがあればCSVはいらない



731 :仕様書無しさん:04/03/20 16:40
>>573
> タダの配列で何も問題ないものまでIteratorとかなw
おっと、お前、最近結城浩の本の最初のページを読み始めたところだろ。
わかるんだよw 一番最初にIteratorのことを説明しているからな。
今お前はそれを読んでさわりだけを理解して必死になってるんだろw

732 :仕様書無しさん:04/03/20 16:42
>>729
じゃあさ、元の文書のどこに

> XML万能主義

って書いてある
そういうことを言う奴を否定した文書なんだけどね。

733 :仕様書無しさん:04/03/20 16:42
証人喚問 

734 :仕様書無しさん:04/03/20 16:46
>>575
> >>572
> 言われている・・・。
> JAVAを全否定はしないけど、何度そんなことを言ってたことか・・・。

>>574
> 可能性も・・・。
> なんつうか、普通に普及して安定して使えるのは何年後になるんだ?

なんとなくお前らの歳がわかってくるなw
お前らが望むのは自分がIT業界を引退する前に
明日にでもすぐに普及して欲しいというせっかちな欲求だなw

もうそろそろ引退時だから新たなソフトウェア開発手法や
新しい言語を覚える気になれない化石なんだろw

735 :仕様書無しさん:04/03/20 16:46
基地外一人、スレにお帰〜え〜り〜。
時間的には競馬でも逝ってたのかな。JAVAで予想して。

736 :仕様書無しさん:04/03/20 16:48
apacheの定義がXMLてwwwwww
バカは死ななきゃwwwww

737 :仕様書無しさん:04/03/20 16:50
>>731
それJavaの本だよな。
全くJava厨はしったかなんだよな。

738 :仕様書無しさん:04/03/20 16:52
大体さ、デザインパターンとか技術つうものは、
さらりと使うのが粋ってもんだろ?

それを覚えたてだと、使ったことを自慢したくでしょうがない。

739 :仕様書無しさん:04/03/20 16:55
STLじゃないの?


740 :仕様書無しさん:04/03/20 16:57
>>468
一言語べったりな香具師なんていねえよ。
このスレでJavaを推している香具師はCもC++もPerl知っているみたいだし
なんとMATLABなんかまで知っていやがる。

741 :仕様書無しさん:04/03/20 16:57
>>737
お前の言っていることに根拠なし。
クラスと構造体との区別もつかないC厨のほうが全く知ったかなんだな

742 :仕様書無しさん:04/03/20 16:59
>>738
覚えてから使うやつはいねえよ。
ここにこのデザインパターンを使ってみようと
実際に何かを作りながら使ってみようとするだろ。
しかもデザインパターンを使うことで利便性があがり
プログラミング効率が上がればタダ使うこと自体よりも
別のことで自慢したくなろう。

743 :仕様書無しさん:04/03/20 17:00
>>735
競馬の話をするとはC厨はやっぱり低賃金なんだな・・・

744 :仕様書無しさん:04/03/20 17:01
>>731
結城ヲタは残念ながらおまえだけ

745 :仕様書無しさん:04/03/20 17:01
C厨が競馬? プ ワロタ
給料が安いから競馬で儲けようだって(ワラ
プ ますますお前の生活が貧しくなるぞ(ゲラ


746 :仕様書無しさん:04/03/20 17:02
>>744
結城ヲタは残念ながら正真正銘お前だけです

747 :仕様書無しさん:04/03/20 17:02
派遣Javaプログラマーのカコイイ趣味教えて!

748 :仕様書無しさん:04/03/20 17:03
>>736
> apacheの定義がXMLてwwwwww
> バカは死ななきゃwwwww

うんうん、ホンット、C厨って馬鹿だねwwwwww

749 :仕様書無しさん:04/03/20 17:04
派遣Cプログラマーのカコイイ趣味教えて!  


750 :仕様書無しさん:04/03/20 17:04
>>749
> 派遣Cプログラマーのカコイイ趣味教えて!  

はずれ馬券集め (プ

751 :仕様書無しさん:04/03/20 17:06
デザインパターンの話題をJava厨に持ち出され、
C厨が必死にデザインパターンを勉強している姿がよく描かれている。
彼は今から必死にC++でクラスの継承、抽象クラスについて理解しようとしていたのであった。


752 :仕様書無しさん:04/03/20 17:06
アホアンチ、土曜は休みか?

753 :仕様書無しさん:04/03/20 17:07
C厨、今日も競馬にはずれたか? (ププ

754 :仕様書無しさん:04/03/20 17:13
>>586
> 大体、プログラム組むときには、XMLを意識しないでも組めるし。
こいつ、XMLを使う理由を何もわかってないな。
XMLを偉ぶ理由のひとつは他のアプリケーションでもデータフォーマットの互換性を
保つことがあげられるわけだが。
それを独自フォーマットにして他のソフトで読もうとしたが読めない、
仕方がないので構文解析器や正規表現で自力でそのフォーマットを読めるように
プログラミングする、コンバータをプログラミングするなど。

このときにXMLを使えばこういった負担を無駄にふやすことなく
ツリー構造を変換するなどだけで
フォーマットを再定義できるわけだが。

XMLスキーマの定義がヘタレ出なければの話だが。

755 :仕様書無しさん:04/03/20 17:14
>>593
> >>584
> どうも「デザインパターン」という言葉の定義が違う様だね。
> 俺の定義は「設計の雛型」だ。
なんだその脳内デザインパターンは(ワラ
プ どうりでデザインパターンをよく理解していないようだ。


756 :仕様書無しさん:04/03/20 17:14
>>754

  馬        鹿



757 :仕様書無しさん:04/03/20 17:16
>>607
> くそう。今日のC厨はGOFを知ってやがる
プ GoFのさわりくらいならお前みたい自作自演ヴァカC厨でも理解できるだろw

実際に使ったこともないアフォC厨が多いがな(ワラ

758 :仕様書無しさん:04/03/20 17:17
>>756
ププ C言語厨はついに馬鹿しかいえなくなったか(嘲笑激藁
まるでだだをこねる餓鬼のようになw
所詮C言語厨のレベルなんてこんなもんだなw

759 :仕様書無しさん:04/03/20 17:18
>>754
引用部分とあんたの内容が全然あってないよ。


760 :仕様書無しさん:04/03/20 17:18
C厨は過去の栄光にすがりついているアフォなんだよなw
10年前にCがまだ全盛期だった頃を懐かしんでいるんだろ(藁
そして時代遅れになりCしかしらないと悟られたことを恨みJavaスレで
Javaに八つ当たりしているんだろ(ワラ

所詮はC厨は餓鬼なんだよ餓鬼(ワラ


761 :仕様書無しさん:04/03/20 17:19
>>759
ププ 言い訳しかできない餓鬼ですな(ワラ
技術的に反論できない能なしC厨w

762 :仕様書無しさん:04/03/20 17:20
年が経つにつれてCしかできない奴は淘汰されていくんだろうな(ゲラ

763 :仕様書無しさん:04/03/20 17:21
職場でいじめられても強く生きるJava派遣ってすごいですね。

764 :仕様書無しさん:04/03/20 17:22
>>618 == >>607
> >>607
> ワラタ
> cしか知らないと、GOFを知っている人はほとんどいないんだよ
> だからXX厨って言い方をヤメレ

プ C厨はこうやって自作自演して自分を慰めようと自己弁護しようと必死になってる(ワラ
現実を見ろよ。デザインパターンは理論だけ知っていても使えない奴はクズでC厨と同じなんだよ(ワラ

GoF以外にもデザインパターンがあることも知らなかったC厨(ワラ

765 :仕様書無しさん:04/03/20 17:23
あ?アホアンチ、宿題は?

766 :仕様書無しさん:04/03/20 17:23
職場でいじめられても職場を転々とするC言語派遣ってすごいですねw

767 :仕様書無しさん:04/03/20 17:25
>>628
> 今までの経験言語。
>
> C、C++、JAVA、VB、Delphi、ふぉーとらん、88ベーシック
> ・・・そしてファミリーベーシック&V3.
>
プ 使えねえ奴だな(ゲラ
たったそれしか知らないのか(ワラ
C厨と同じレベルだなw

768 :仕様書無しさん:04/03/20 17:26
Java派遣がつくったプログラムを
Javaを知らないプロパがメンテする光景が楽しいです。

769 :仕様書無しさん:04/03/20 17:27
>>642
> JAVAを推す理由は
> バージョンが大量にあって、欠点をそれで埋めてるから
プ C++の乱立に比べたら少ないだろw
VC++やVBはバージョン互換性の無さからいsて糞だなw
それで仕方が無くC#なんて糞言語を作ったんだろM$は(ワラ


770 :仕様書無しさん:04/03/20 17:27
C派遣がつくったプログラムを
Cを知らないプロパがメンテする光景が楽しいです。

771 :仕様書無しさん:04/03/20 17:29
なんで他人が作ったものにそんなに熱くなれるのよオマイラ。
あんたら、言語仕様設計に関わったの?

772 :仕様書無しさん:04/03/20 17:29
>>648
> >>642
> バージョン問題ってDLLHell以上に酷いよな。
ププ Javaでバージョン問題にぶつかったときの対応策も知らないヴァカがいるぞここに。
DLLHellよりも簡単に処理できるのにな(ワラ


773 :仕様書無しさん:04/03/20 17:30
>>771
Java派遣の人生がかかってるんですよ。

774 :仕様書無しさん:04/03/20 17:31
>>771
関わったが(ワラ
yaccとか使ってなw
ヴァカが糞言語作っているのを見守ってやったよ(ゲラ
100万もかけたが公開もされない誰も使わない糞言語だったがなw



775 :仕様書無しさん:04/03/20 17:32
>>771
C言語派遣の人生がかかってるんですよ。

776 :仕様書無しさん:04/03/20 17:33
>>775
やっぱりそうなんだ。Cだけでは食っていけないんだ。
組み込み系派遣Cプログラマは短命なだけあるね。



777 :仕様書無しさん:04/03/20 17:33
>>774
何の話してんの?バカ?

778 :仕様書無しさん:04/03/20 17:35
>>654
> >>650
> 俺 Java 厨だけど、VB は女が多いのか。
> VB にしようかな・・・

プ こいつその程度の自作自演でVBやりたがる奴が増えると思っているのか(ワラ

779 :仕様書無しさん:04/03/20 17:36
>>777は言語の作り方も知らないDQNであることが判明しました。
Cしか知らない奴ってこの程度だねw

780 :仕様書無しさん:04/03/20 17:36
>>663
AmazonはPerlも使っていればASPも使っていればJavaも使ってる。

781 :仕様書無しさん:04/03/20 17:37
>>731
結城先生。こんなところでまで宣伝ですか。

782 :仕様書無しさん:04/03/20 17:39
>>684
> 最初に会社で習った言語、もしくは自分が最初に覚えた言語だったってだけで支持しているやつも多くいるように見受けられる
そんな奴はおらんよ。最初は皆Cから始めてそれからJavaに移行する。

783 :仕様書無しさん:04/03/20 17:40
>>782
なに言ってんだよジジイwwwwww

784 :仕様書無しさん:04/03/20 17:40
>>687
> バブル崩壊後はなりたくてPGになった奴ばかりじゃないんだよ。
> 80年代は零細ソフト会社にバイトに行ってはまり込み、そのまま居座った奴とかいたけどね。

ププ >>687の年齢がよくわかるw

785 :仕様書無しさん:04/03/20 17:40
午前中の奴より生きが良いな。アイツはとんでもないヘタレだった。
逃亡するし。


786 :仕様書無しさん:04/03/20 17:41
>>784
それが分かるおまいの年齢もな

787 :仕様書無しさん:04/03/20 17:42
>>785
氏ねよ粘着

788 :仕様書無しさん:04/03/20 17:42
>>782
今時糞Cなんかからはじめるのはお前だけ

789 :仕様書無しさん:04/03/20 17:46
>>787
午前中のヘタレさんですか?

790 :仕様書無しさん:04/03/20 17:46
>>729
じゃあさ、元の文書のどこに

> XML万能主義

って書いてある?
そういうことを言う奴を否定した文書なんだけどね。

791 :仕様書無しさん:04/03/20 17:51
>>331
> 人を育てる際やリクルートする際に電子回路、電気の基礎技術など
> 理系の必須項目をきちっと抑えていることを考えていないのではないか?
> オブジェクト指向、JAVA、UMLだといっても結局メモリと演算の繰り返しで
> トランジスタでon、offしているという認識を持てるかもてないかで
> 基盤に対する考え方が違うと思う。結局実世界との関係を概念モデルでしか
> 考えられない技術者が多すぎると考える。


バカタレ! 理系のソフトウェア工学を侮辱するのか貴様!
そんな数理論理学なんぞソフトウェア工学を語る者は知っとるわい!
概念モデルで考えた方が効率がいいからそうしているに決まっているだろうが。
それを「でしか考えられない」だとは何事か!

貴様は物理学をなめている。物理シミュレータはオブジェクト指向が必須だぞ!
SIMULAはオブジェクト指向言語だぞ!


792 :仕様書無しさん:04/03/20 17:52
>>788
じゃお前は何から始めるんだ(ワラ
Javaやったがオブジェクト指向がわからないだとか
コンパイルエラーがでまくってわからないからCに成り下がったか(ワラ

793 :仕様書無しさん:04/03/20 17:54
>>792
Javaで始めてJavaだよ。おっさん

794 :仕様書無しさん:04/03/20 17:55
>>338
> double の演算で誤差出る言語仕様が納得いかん。
> 誤差が出ても良い科学計算に最適化しパフォーマンスを
> 優先したって、もう言語仕様が金融に向かない。
>
> 業務で double 精度の演算が膨大にあって BigDecimal が
> かなり嫌いになった。普通に演算子でやらしてくれよと。
>
> BigDecimal を分かってないとか言うテル香具師は
> ほんとにこんなものが使いやすいと思ってるのか?


プ こいつ、10進2進誤差を知らないヴァカだな。
doubleで誤差が出る言語なんぞ腐るほどあるわけだが(ワラ
そんなこともしらないで納得いかないならC系言語は全滅だな(ゲラ
COBOLしか知らないから己の無知をさらけ出すことになるんだよ(嘲笑



795 :仕様書無しさん:04/03/20 17:55
>>793
恥ずかしwwww

796 :仕様書無しさん:04/03/20 17:55
>>791
専門学校卒のPGはそんなことしりませんが何か?

797 :仕様書無しさん:04/03/20 17:56
>doubleで誤差が出る言語なんぞ腐るほどあるわけだが(ワラ

だから?

798 :仕様書無しさん:04/03/20 17:56
>>795
うざいよ。おっさん

799 :最凶VB厨房:04/03/20 17:56
誤差なんて気にするほうが馬鹿。

800 :仕様書無しさん:04/03/20 17:58
>>796
そのかわりおっさんの知らない遊びをしってるけどな。

801 :仕様書無しさん:04/03/20 17:59
>>780
実際に何使ってるかなんか誰も聞いてない。

802 :仕様書無しさん:04/03/20 18:00
たしかに10進2進変換誤差もしらない奴が>>791みたいなことを
いっているのはおかしい。矛盾しているとしかいいようがないな。
10進2進変換誤差も理系の必須項目だ。

しかもJavaのdouble型仕様は IEE754で定められている仕様に準拠しているわけだが。
それもしらないのかこのCOBOLerは。

こいつは精度が高い=桁数が大きい
だけとしか考えていないんだろうか。だとしたら致命的だなw
だからBigDecimalが解っていないといわれるんだよw

しかも10進数よりも2進数のほうが計算が速いことも知らないとしたら
こいつ本当に致命傷だぞw

803 :仕様書無しさん:04/03/20 18:02
>>794
結局 10進演算では COBOL 最強ってことだな。

804 :仕様書無しさん:04/03/20 18:02
>>796
だからSIMULAも知らないC厨は糞だっていってるんだよ。
そんなアフォがJavaやオブジェクト指向を否定し理系じゃないとか
言っている奴訳だ。馬鹿は死ななきゃなおらないみたいだなホントに

805 :仕様書無しさん:04/03/20 18:02
>>797
CでもC#でも誤差でるよ。
2進数である以上。

806 :仕様書無しさん:04/03/20 18:03
おっす。オイラ派遣PG
Java歴3年。皆が行くからとりあえず専門学校行ったけど、
特にやりたいことも無いし、派遣PGで食うのには困らないし。
将来のことは考えたこと無いけど、仲間と騒いだり、職場のかわいい女PGと遊んだりで楽しいよ。
趣味は博打。パチンコ、ナンバーズやロトも買うよ。いつか一攫千金を夢見てる。
夢は大きく持たないとね!

発泡酒を飲んで騒ぎ、スタジアムで騒ぐ。人生最高!
でも、スポーツ新聞読むと自民党は極悪非道だと思う。ゆるせない。
政権交代すればいいのに。


807 :仕様書無しさん:04/03/20 18:03
にしてもBigDecimalを使ったら
激しく可読性が悪いんだが。

808 :仕様書無しさん:04/03/20 18:04
>>803
10進演算しなくてもいいところで10進演算するCOBOLは遅くて最低。
量子コンピュータが出ればCOBOLの存在価値はますます薄れていくな。
ついでにC言語もアセンブラも。

809 :仕様書無しさん:04/03/20 18:05
>>807
このすれでBigDecimalを知ったぶって使ってる香具師は
可読性の悪い書き方しかできない香具師ばかり。

一人だけよく書けてる香具師がいるみたいだが。

810 :仕様書無しさん:04/03/20 18:05
おっす。オイラ派遣PG
C歴3年。皆が行くからとりあえず専門学校行ったけど、
特にやりたいことも無いし、派遣PGで食うのには困らないし。
将来のことは考えたこと無いけど、仲間と騒いだり、職場のかわいい女PGと遊んだりで楽しいよ。
趣味は博打。パチンコ、ナンバーズやロトも買うよ。いつか一攫千金を夢見てる。
夢は大きく持たないとね!

発泡酒を飲んで騒ぎ、スタジアムで騒ぐ。人生最高!
でも、スポーツ新聞読むと自民党は極悪非道だと思う。ゆるせない。
政権交代すればいいのに。

811 :仕様書無しさん:04/03/20 18:05
>>804
知ったかうざいよ。おっさん。

812 :仕様書無しさん:04/03/20 18:05
>>808
> 量子コンピュータが出ればCOBOLの存在価値はますます薄れていくな。
逆だろ? 遅さの問題が解決するんだから
どこでも10進演算しても問題なくなる。


813 :仕様書無しさん:04/03/20 18:06
>>810
コピペうざいよ。おっさん。

814 :仕様書無しさん:04/03/20 18:07
>>809
君はBigDecimalで可読性がいい書き方ができるのかね?
それではA+B*C(それぞれの変数はBigDecimalが必要な大きさの数値)を
可読性がいい書き方で書いてみたまえ。

815 :仕様書無しさん:04/03/20 18:07
>>809
動けばいいじゃん。がたがたいうなよ。うざい。

816 :仕様書無しさん:04/03/20 18:07
>>808
その遅いってのは、どれくらい差があるの?
弾道ミサイル軌道計算とかならいざ知らず
基幹業務とかのボトルネックになるの?

817 :仕様書無しさん:04/03/20 18:07
このスレでBigDecimalが使いにくい、読みにくいと言っている香具師は
変数すらつかわずに
その場その場でnew BigDecimal() とかBigDecimalvalueOf(long)とか
とかやってる香具師ばかりだからな。
しかもBigIntegerで済むものをわざわざBigDecimalを使っているヴァカ


818 :仕様書無しさん:04/03/20 18:09
>>815
お前のプログラムは保守できない。

819 :仕様書無しさん:04/03/20 18:09
>>817
BigIntegerでもBigDecimalでもいいから書いてみろよ。

820 :仕様書無しさん:04/03/20 18:09
>>814
おまえがいわなくてもすでに>>210あたりが出題している。

821 :仕様書無しさん:04/03/20 18:10
>>817
BigInteger だと見やすくなるのか?

822 :仕様書無しさん:04/03/20 18:10
>>820
あの可読性が悪いコードが答えなの?

823 :仕様書無しさん:04/03/20 18:10
>>818
おまいに頼んでねえっつうの。
だいたいメンテすんのは俺より若い奴だしそんときゃ俺いないから関係ない。

824 :仕様書無しさん:04/03/20 18:11
>>817
COBOL は見やすい。

825 :仕様書無しさん:04/03/20 18:11
BigDecimalの可読性が低いことを示すための例なのに、
BigIntegerでいいじゃんとかlongでいいじゃんとか
言っている奴がいるのが笑えるw

826 :仕様書無しさん:04/03/20 18:11
やれやれ。おっさんの古文書自慢かよw

827 :仕様書無しさん:04/03/20 18:12
>>814
BigInteger A = BigInteger(aString);
BigInteger B = BigInteger(bString);
BigInteger C = BigInteger(cString);

BigInteger result = A.add(B.multiply(C));

828 :仕様書無しさん:04/03/20 18:12
演算子のほうが見やすいに決まってるだろ。

829 :仕様書無しさん:04/03/20 18:13
>>827
> >>814
> BigInteger A = BigInteger(aString);
> BigInteger B = BigInteger(bString);
> BigInteger C = BigInteger(cString);
>
> BigInteger result = A.add(B.multiply(C));

このヴォケC厨! それでコンパイルが通ると思ってんのか餓鬼!

830 :仕様書無しさん:04/03/20 18:13
>>828

ここはSmallTalkerを激昂させる台詞が聞けるインターネットですね。

831 :仕様書無しさん:04/03/20 18:13
>>827
変数名に大文字なんかつかんじゃねえよヴォケC厨

832 :仕様書無しさん:04/03/20 18:13
>>827
A+B*Cという短い計算式が
そんなに長くなってしまうの?
わざわざオブジェクトまで生成して。
そりゃ可読性が悪いといわれるのも当然だね。

833 :仕様書無しさん:04/03/20 18:14
>>827
a + b * c
のほうが見やすい。

834 :仕様書無しさん:04/03/20 18:14
動くとこからコピペしてきて、コンパイルが通るまで修正を繰り返せばいいじゃん。
おっさんは効率悪いな。

835 :仕様書無しさん:04/03/20 18:14
>>829
あ。

new 忘れた。

モウダメポ

836 :仕様書無しさん:04/03/20 18:16
>>835
本質じゃないとこばかり突っ込む馬鹿が多いからな。

837 :仕様書無しさん:04/03/20 18:16
本質の所に突っ込もう。


可読性わるっ。

838 :最凶VB厨房:04/03/20 18:17
>>836
VBを馬鹿にするやつに多いよな

839 :仕様書無しさん:04/03/20 18:17
>>827

正しい書き方
String aString = "16712661758975651767516156375671772676765675
 1671266175897565176751615637567177267676567516712661758975
 6517675161563756717726767656751671266175897565176751615637
 5671772676765675167126617589756517675161563756717726767656
 7516712661758975651767516156375671772676765675167126617589
 75651767516156375671772676765675";

String bString = "577485774878674654656446577487867465465644655
 87942316453567655774878674654656446558794231645356757748786
 74654656446558794231645356757748786746546564465587942316453
 56765408608060088408654086080600884086540860806008840840860
 80600884085587942316453567654086080600884085774878674654656
 44655879423164535676540860806008840857748786746546564465587
 94231645356765408608060088408577487867465465644655879423164
 53567654086080600884087867465465644655879423164535676540860
 8060088408";

String cString = "1081086057557710860575577577108605755775779846
 879879464136854385640898468798794641368543856408577984687987
 946413685438564086051086057557757798468798794641368543856408
 755775108605755775779846879879464136854385640877910860575577
 577984687987946413685438564088468798710860575577577984687987
 9464136854385640894641368543856408";

BigInteger a = BigInteger(aString);
BigInteger b = BigInteger(bString);
BigInteger c = BigInteger(cString);

BigInteger result = a.add(b.multiply(c));

840 :827:04/03/20 18:17
>>832

でも、別に演算子パースして実行するクラス書けば

BigInteger result = CalcUtil.calc("3000000000000 + 8000000000000000 * 900000000000");

でもいいんだけどね。

841 :仕様書無しさん:04/03/20 18:18
>>827

正しい書き方
String aString = "16712661758975651767516156375671772676765675
 1671266175897565176751615637567177267676567516712661758975
 6517675161563756717726767656751671266175897565176751615637
 5671772676765675167126617589756517675161563756717726767656
 7516712661758975651767516156375671772676765675167126617589
 75651767516156375671772676765675";

String bString = "577485774878674654656446577487867465465644655
 87942316453567655774878674654656446558794231645356757748786
 74654656446558794231645356757748786746546564465587942316453
 56765408608060088408654086080600884086540860806008840840860
 80600884085587942316453567654086080600884085774878674654656
 44655879423164535676540860806008840857748786746546564465587
 94231645356765408608060088408577487867465465644655879423164
 53567654086080600884087867465465644655879423164535676540860
 8060088408";

String cString = "1081086057557710860575577577108605755775779846
 879879464136854385640898468798794641368543856408577984687987
 946413685438564086051086057557757798468798794641368543856408
 755775108605755775779846879879464136854385640877910860575577
 577984687987946413685438564088468798710860575577577984687987
 9464136854385640894641368543856408";

BigInteger a = new BigInteger(aString);
BigInteger b = new BigInteger(bString);
BigInteger c = new BigInteger(cString);

BigInteger result = a.add(b.multiply(c));

842 :仕様書無しさん:04/03/20 18:19
>>840
> でも、別に演算子パースして実行するクラス書けば
さらに遅くなるけどなw

843 :仕様書無しさん:04/03/20 18:19
>>832
その程度で可読性が悪いと思うなら
どのオブジェクト指向言語も使いこなせないぞ。


844 :827:04/03/20 18:19
>>841
いや、普通そこまで長かったらリソースファイルから読むだろ。

845 :仕様書無しさん:04/03/20 18:20
ほんと、ソフトが好きなんだねぇ。おっさんたち。

846 :仕様書無しさん:04/03/20 18:21
>>844
読むか、計算するかどちらか。

847 :仕様書無しさん:04/03/20 18:21
で、これのどこがJAVAの有意義な議論なんだ?
オナニーは自室で。

848 :仕様書無しさん:04/03/20 18:21
>>845
おっさんはお前だろC言語厨

849 :仕様書無しさん:04/03/20 18:22
>>840
見にくいってのを認めてるんだったら言語でサポートしてくれとおも。

850 :仕様書無しさん:04/03/20 18:22
>>848
ノイローゼですか?

851 :仕様書無しさん:04/03/20 18:23
>>846
SQLにして実行すれば、パースはOracleとかがやってくれるぞ(w

ていうか、BigIntegerなんて実際にはどうせデータベースに入ってるだけなんだから、

BigInteger b = resultSet.getBigInteger(1);

でいいだろ。

852 :仕様書無しさん:04/03/20 18:23
円周率とかexp()関数などのマクローリン展開をBigDecimalを使て求めるとオモロイよ。


853 :仕様書無しさん:04/03/20 18:23
>>851
そのとおり

854 :仕様書無しさん:04/03/20 18:24
>>852
そういうものは学生が勉強としてやっていればよい。

855 :仕様書無しさん:04/03/20 18:25
>>849
だよね。Stringに+演算子加えたのに比べれば、
intやlong等と同じ数値に算術演算子を加える方がよっぽどまとも。

856 :仕様書無しさん:04/03/20 18:25
>>850
PCやりすぎていかれてるんだろ。
社畜に多いけど、ああはなりたくないな。

857 :仕様書無しさん:04/03/20 18:26
> CalcUtil.calc("3000000000000 + 8000000000000000 * 900000000000");

このメソッドの実装は Oracle に渡すと。

858 :仕様書無しさん:04/03/20 18:27

お前らの書いたプログラムって、よく無限ループしないか?
大丈夫か?


859 :最凶VB厨房:04/03/20 18:28
>>858
大丈夫だけど?例外出して止まってくれるから

860 :仕様書無しさん:04/03/20 18:28
>>858
もうちょっと建設的なレスしろ。

861 :仕様書無しさん:04/03/20 18:28
>>857
ちょっと大きい数値を使うだけで、
Oracleサーバ立ててわざわざそこに代理させるのかw

862 :仕様書無しさん:04/03/20 18:29
>>860
十分建設的だろ?
今の話題って>>1付近からあるじゃん。

863 :仕様書無しさん:04/03/20 18:29
>>861
演算サーバだよ。最近流行りの分散だ。

864 :仕様書無しさん:04/03/20 18:30
だからさ、動くとこからコピペしてきて、コンパイルが通るまで修正を繰り返せばいいじゃん。
機械に任せるのが賢いし、既にあるとこから持ってきたコードなんで、社員に文句言われても
言い返せる。仕事は手早くね。


865 :仕様書無しさん:04/03/20 18:30
建設的な発言ってのは
結論が出ていない話題を
途中で中断させることか?w

866 :仕様書無しさん:04/03/20 18:31
>>864
誤爆? 全く関係無い話だよね。

867 :仕様書無しさん:04/03/20 18:31
>>865
で、この話題がJavaの人気の何に関係あるんだ?

868 :仕様書無しさん:04/03/20 18:32
あれだ。建設的 = ドカタ的

869 :仕様書無しさん:04/03/20 18:32
>>867
Javaが嫌われている原因の一つだろ?

870 :仕様書無しさん:04/03/20 18:32
>>867
まーそういうことを言うな。

871 :仕様書無しさん:04/03/20 18:33
Javaしか仕事無いのにケチつけても仕方なくないかなぁ。

872 :仕様書無しさん:04/03/20 18:34
嫌われている原因の話題をもみ消す。
そりゃJava厨にとっては建設的だろうよw

873 :仕様書無しさん:04/03/20 18:35
いつになったらJavaでBigDecimal型に
算術演算子が使えるようになるの?

874 :仕様書無しさん:04/03/20 18:35
> CalcUtil.calc("3000000000000 + 8000000000000000 * 900000000000");

こんなの Jakarta に無いのか?
アホっぽいから無いかな。

875 :仕様書無しさん:04/03/20 18:36
>>873
明日くらい。

876 :仕様書無しさん:04/03/20 18:36
もう既定の話をぐだぐだ言うのはやめろよ。おっさん

877 :仕様書無しさん:04/03/20 18:36
でも、Javaは悪くないんですよw

878 :仕様書無しさん:04/03/20 18:36
>>876
もみ消そうと必死だなw

879 :仕様書無しさん:04/03/20 18:36
>>876
規定?

880 :仕様書無しさん:04/03/20 18:37
>>877
BigDecimalに算術演算子が使えないのは
Javaが悪いだろw

881 :仕様書無しさん:04/03/20 18:37
>>876
じゃ、なんかネタふれよ。

882 :仕様書無しさん:04/03/20 18:37
>>849
言語でサポートするのは副作用が起こりうることは免れないな。
Stringのように固定でいいが。
プリミティブ型でないStringを除くオブジェクトで加算をやるとき、

プラス演算子 + がオブジェクトをtoString()でString型に変換された文字列を
連結するためのものなのか、BigIntegerやBigDecimalどうしの加算なのかを区別するほうほうが
必要になってくる。

BigInteger a = BigInteger.valueOf(1234);
BigInteger b = BigInteger.valueOf(5678);
としたとき

System.out.println("" + a + b);
の結果は
12345678となる。
( 余談だがここで""をとったSystem.out.println(a + b);の結果は
「演算子 + は引き数の型 java.math.BigInteger, java.math.BigInteger で未定義です。」
とコンパイルエラーがでる。 )
●注意! JavaではすべてのオブジェクトをString型に代入すると暗黙のうちに
 そのオブジェクトのtoString()メソッドが呼び出される。
 Stringオブジェクトが含めてString以外のオブジェクトを + 演算子で結ぼうとすると
 String以外のオブジェクトは暗黙のうちにtoString()メソッドが呼び出されてしまう。
つまり、System.out.println("" + a + b);はSystem.out.println("" + a.toString() + b.toString());
と同義である。

883 :仕様書無しさん:04/03/20 18:37
でも、BigDecimalは悪くないんですよw

884 :仕様書無しさん:04/03/20 18:38

つーかしばらくはこれで食いたい。
それだけ。
つーことでJAVA普及こそ我が天命。
つーことにしとこう。

javaはいいぞぉ〜


885 :仕様書無しさん:04/03/20 18:39

結果を12345678にするか、6912にするかを選ぶ仕様が必要になってくる。
すでに+演算子は、Stringオブジェクトと結びつけようとするときのみ
このような仕様として定義されており、加算演算子として定義することは危険と見なされる。

その区別を定義する方法をどうにかしようとするとこんどは   
またあらたにとんでもない副作用が起きる。 

こういうことは言語レベルでサポートするべきではない。IDEなどツールでサポートすべきだ。

886 :仕様書無しさん:04/03/20 18:39
言われたようにやりゃいいじゃん。どうせ殆どの作業はこぴぺだし

887 :仕様書無しさん:04/03/20 18:39
>>883
そのネタ飽田

888 :仕様書無しさん:04/03/20 18:40
>>882
Number のサブクラスの場合は数値演算を行う。
これでいいとおも。

889 :仕様書無しさん:04/03/20 18:40
>>882
その問題はBigIntegerやBigDecimalだけでなく
intやlongでも発生する問題じゃん。

intやlongはどうやって解決している?
同じ方法を取ればいいだけだよ。

890 :仕様書無しさん:04/03/20 18:41
BigDecimalなら自動化ツールでどうにかなる。
Jakarta Velocityで自動変換とか汁。
だから言語レベルであんなもんはいらんと。
Apache Antでその変換をタスクとして定義してしまえばいらんど

891 :仕様書無しさん:04/03/20 18:41
>>888
両方の項が Number のときだけ。

892 :仕様書無しさん:04/03/20 18:42
固定小数点の型があればよいのでは。

893 :仕様書無しさん:04/03/20 18:42
>>888
そんなことをするとなんでもかんでもNumberクラスのサブクラスを
定義しようとする輩が現れる。
行列クラスとかをNumberクラスのサブクラスにするなよと

894 :仕様書無しさん:04/03/20 18:42
>>892
それがBigDecimalだろ

895 :仕様書無しさん:04/03/20 18:43
>>890
ベロ使っていいんならなんでもありだろ。
そんなソースはだめ。反則。

896 :仕様書無しさん:04/03/20 18:44
ん?longやintと同じように扱えないの?

897 :仕様書無しさん:04/03/20 18:44
>>890
ようするにプリプロセッサが必要というわけですね。
なんでJavaにはプロプロセッサが無いのでしょう?

898 :仕様書無しさん:04/03/20 18:44
>>893
間違った継承をする香具師は今でもたくさんいる。

899 :仕様書無しさん:04/03/20 18:45
>>891
じゃあ、Numberクラスを継承して新たにクラスを定義した場合、
またそれようにそれぞれクラスの演算子を定義し直さないと行けなくなる。
たとえば複素数クラスをNumberクラスのサブクラスにした場合、
当然ながら演算子の挙動は異なる。複素数型と実数型を足した場合とか
オーバーロードすべき演算子の数が最低でも8つ以上になる。

900 :仕様書無しさん:04/03/20 18:46
>>897
スパゲティコード生成抑止効果のため。

Jakarta Velociyで十分だろ。

901 :仕様書無しさん:04/03/20 18:47
クラスとかそんなものはどうでもいい。
int、longと同じでさらに桁を増やして
小数点も使えるような型にすれば言いだけ。

演算子の挙動は、int、longと同じ。
文字列と連結しようとしたときの挙動も、
int、longと同じ。

単に桁が増えただけ。
これで問題がおきることは無い。

902 :仕様書無しさん:04/03/20 18:47
>>898
そこでSunが実装したBigDecimalとかBigIntegerがきにいらないからといって
Numberクラスを継承して独自にBig系似クラスを定義して
独自に演算子を定義して、他の型と互換性の無い演算子と
使い回されるのは嫌。そんな香具師はC++でもやってくれと


903 :仕様書無しさん:04/03/20 18:48
longやdoubleでは演算子使えるのになんでBigDecimalでは使えないんですか?

904 :仕様書無しさん:04/03/20 18:48
>>900
やっていることはプリプロセッサといっしょ。

905 :仕様書無しさん:04/03/20 18:48
>>899
うーん。じゃ、固定小数点のプリミティブ型を用意しる。
ってか理想形ってどんなの?

906 :仕様書無しさん:04/03/20 18:48
>>901
だからBigDecimalがすでにそれを実現しているんだって。

907 :仕様書無しさん:04/03/20 18:49
>>901
禿しく同意。つうか、何故そうなってないのか理解出来ない。
何か理由があるんですか?

908 :仕様書無しさん:04/03/20 18:49
>>903
BigDecimalはクラスだから使えないということ。

909 :仕様書無しさん:04/03/20 18:49
おもろないから話題かえて

910 :仕様書無しさん:04/03/20 18:50
>>906
演算子使えませんが何か?

911 :仕様書無しさん:04/03/20 18:50
128bit/64bit固定小数点のプリミティブ型があれば解決

912 :仕様書無しさん:04/03/20 18:50
>>905
プリミティブ型はあれ以上増えないと思われ。
Big系の最適化は別のところで行えると思われ。
Big系クラスのソースにnativeキーワードがふんだんにつかわれることで
いずれ最適化されるかと。


913 :仕様書無しさん:04/03/20 18:50
PL/SQL以下だな。

914 :仕様書無しさん:04/03/20 18:50
>>906
おい。

915 :仕様書無しさん:04/03/20 18:50
そもそもBigDecimalがクラスだってのが
問題なわけか。

916 :仕様書無しさん:04/03/20 18:52
マシンのCPUが64bitになっても固定小数点64bitが使えないjava素敵っ!

917 :仕様書無しさん:04/03/20 18:53
>>911
64bitsはすでにある。
128bitsは無い。
プリミティブ型にこだわる必要性はそんなにないだろと。
演算子はJakarta Velocityがあればいらないだろと。

BigDecimalで128bits精度を維持したければ
J2SE1.5を待て。
java.mathパッケージを見よ。
MathContextクラスが定義された。
このクラスをBigDecimalコンストラクタの引数に入れることで
精度を128bitsなどに設定できる。

918 :仕様書無しさん:04/03/20 18:53
>>909
話題提供しる。

919 :仕様書無しさん:04/03/20 18:54
>>916
使えるぞヴォケ。
longとdoubleが。浮動だが。
固定にこだわる必要なし。
よけいな無駄なものは切り捨てる、それがJavaのポリシーだろ

920 :仕様書無しさん:04/03/20 18:54
>>915
それはSmalltalkerに喧嘩を売っているということですか。

921 :仕様書無しさん:04/03/20 18:54
> 演算子はJakarta Velocityがあればいらないだろと。
そう思っているのはお前だけなんだが?
そんなにJakarta Velocityが好きなら、
StringもJakarta VelocityでやれとSUNに言えよ。

922 :仕様書無しさん:04/03/20 18:55
PC98のDOSで使えないJavaなんて
(゚听)イラネ

923 :仕様書無しさん:04/03/20 18:55
その程度のことはjdkのなかで完結させなよ。

924 :仕様書無しさん:04/03/20 18:56
なぜSUNは固定小数点が必要だって事に
気が付かなかったのでしょうか?

925 :仕様書無しさん:04/03/20 18:56
>>919
固定小数点なんかいらないよね。

926 :仕様書無しさん:04/03/20 18:56
>>920
そんなオナニー言語はいらん。

927 :仕様書無しさん:04/03/20 18:56
>>924
金勘定に疎いから。今の経営状況をみればよく分かるw

928 :最凶VB厨房:04/03/20 18:57
import java.math.*;
public class Bignayatu
{
public static void main(String[] args)
{
BigDecimal bi=new BigDecimal("1234564" );
BigDecimal dd=new BigDecimal("35.16246541");
bi.add(dd);

System.out.println(bi);
}
}
biの値が変わりません。どうしたらいいですか?

929 :仕様書無しさん:04/03/20 18:57
>>927
それか!

930 :仕様書無しさん:04/03/20 18:58
>>928
ネタはいいです・・・

931 :仕様書無しさん:04/03/20 18:58
>>905
Jakarta Velocityを使うことが理想型。

しかもVelocityはJSP, Strutsでも愛用されている。
それいがいにC#っぽい記述をJavaで使いたいときにも使われる。
Javaではforeachが使えない。
こんなときVelocityが役立つ。Velocityでforeachで書けば
自動的にそれをfor文のそれに相当する記述に変換してくれる。


プログラミングの自動化においてVelocityのようなツールは非常に重要だ。

新しい型を定義するとき、大抵、equals(), hashCode() などのメソッドをオーバーライドする
そのとき、Velocityが非常に役立つ。
さらに不変クラスを定義するときもVelocityが役立つ。



932 :仕様書無しさん:04/03/20 18:58
「どうして株価がどんどん下がるのですか?」
「浮動小数点の丸め誤差です。気にする必要はありません。」


933 :仕様書無しさん:04/03/20 18:59
longで固定小数点をつくればいいじゃーん

934 :仕様書無しさん:04/03/20 18:59
>>931
> それいがいにC#っぽい記述をJavaで使いたいときにも使われる。
> Javaではforeachが使えない。
Javaは糞。C#マンセーというわけですな。

935 :仕様書無しさん:04/03/20 19:00
Javaが超精密な分野では相手にされない理由がわかりました。

936 :仕様書無しさん:04/03/20 19:00
>>921
なんでStringをVelocityでやる必要があるんだ?
必要ないだろ。Stringで+演算子で文字列を連結することには
特に大きな副作用がないからそれでいいとしていることをわかってないんじゃないのか?

937 :仕様書無しさん:04/03/20 19:00
>>931
ベロ大好きなんだね。

938 :仕様書無しさん:04/03/20 19:01
>>934
そんなところで比較しているようではドングリの背比べと思われてもしょうがないな。
そんなことでC#マンセーになるならC++マンセーが現実解だろ。

939 :仕様書無しさん:04/03/20 19:01
>>935
勘違い君ですねあなたは。

940 :仕様書無しさん:04/03/20 19:01
>>936
副作用あるだろ
Integer a = new Integer(1234);
Integer b = new Integer(5678);
としたとき

System.out.println("" + a + b);
の結果は
12345678となる。


941 :仕様書無しさん:04/03/20 19:03
>>928
> import java.math.*;
> public class Bignayatu
> {
> public static void main(String[] args)
> {
> BigDecimal bi=new BigDecimal("1234564" );
> BigDecimal dd=new BigDecimal("35.16246541");
> bi.add(dd);
>
> System.out.println(bi);
> }
> }
> biの値が変わりません。どうしたらいいですか?

アフォ、死ね。BigDecimalは可変クラスじゃねえんだよヴォケ

942 :仕様書無しさん:04/03/20 19:03
>>936
禿同。禿同。

なんでBigDecimalをVelocityでやる必要があるんだ?
必要ないだろ。BigDecimalで+演算子で演算することには
特に大きな副作用がないからそれでいいとしていることをわかってないんじゃないのか?

943 :仕様書無しさん:04/03/20 19:03
System.Decimalを使いましょう^^

944 :仕様書無しさん:04/03/20 19:04
>>941
マジレスですか?

945 :仕様書無しさん:04/03/20 19:04
またしてもJava厨のアホさ加減がかいま見れました。

946 :仕様書無しさん:04/03/20 19:05
>>940
Javaの仕様を理解できない香具師が犯す間違いだろ。

その程度で副作用言い張るならC#なんてとんでもない副作用の塊だ。
そしてC++は最も大きな副作用をもつ言語だ。


947 :仕様書無しさん:04/03/20 19:05
またしてもC厨のアホさ加減がかいま見れました。
のほうが現実解です


948 :仕様書無しさん:04/03/20 19:07
>>946
そのとおり、>>882のJava厨のバカさ加減がわかったでしょ?

949 :仕様書無しさん:04/03/20 19:08
先生 J#ではSystem.Decimalの演算子は使えますか?

950 :仕様書無しさん:04/03/20 19:08
いい加減BigDecimalを言語レベルでサポートしろという
結論に落ち着きましたか?

951 :仕様書無しさん:04/03/20 19:08
やはりVB.NETに勝てないのか

952 :仕様書無しさん:04/03/20 19:09
>>949
J#はJavaのパクリとして設計されたんだから
Javaの欠点も存在するんじゃない?

953 :仕様書無しさん:04/03/20 19:11
>>952
オンラインヘルプには

public static System.Decimal op_Addition(
System.Decimal d1,
System.Decimal d2
);
public static System.Decimal op_Decrement(
System.Decimal d
);

なんてのがありますな。op_Additionが加算演算子の定義なのかな。

954 :最凶VB厨房:04/03/20 19:12
はい!使ってみました!
Dim d As Decimal = 1234564
Dim dd As Decimal = 35.16246541
d += dd
Console.WriteLine(d)
見やすくて大変感激しました!

955 :仕様書無しさん:04/03/20 19:13
ああ、ブビに抜き去られてしまった

956 :仕様書無しさん:04/03/20 19:31
先生 J#ではエラーになってしまいます

public static void main(String[] args)
{
  System.Decimald = 12345664;
  System.Decimaldd = 35.1326447;
  d += dd;
  System.Console.WriteLine(d);
}

957 :仕様書無しさん:04/03/20 20:10
Javaの仕様で問題なし。
見辛いなんて言うやつは、メソッド名レベルの英語も分からない低脳だろ。

958 :仕様書無しさん:04/03/20 20:13
固定小数点のプリミティブ型かあれば全て解決

959 :仕様書無しさん:04/03/20 20:24
>>957
世間はそう取らない。演算子は見やすい。
その証拠にStringに+演算子が付け加えられた。
お前はJava自身まで否定するきか?

960 :仕様書無しさん:04/03/20 20:25
Stringに+が無かったら理解できるけどね。統一されてないよね。

961 :仕様書無しさん:04/03/20 21:03
偉そうなこと言う前に、多倍長固定小数点演算用のプリコンパイラでも自作したら?


962 :仕様書無しさん:04/03/20 21:06
BigDecimalで無問題。

963 :仕様書無しさん:04/03/20 21:12
>961
昔JHBで「デラゲーツの別案」というサブジェクトでグダグダ言っているやつが居たなぁ。
そいつがココに来ているんじゃないの?


964 :仕様書無しさん:04/03/20 21:13
COBOL って通貨の概念はあるのかな。
寡聞にしてよく知らないんだけど。



965 :仕様書無しさん:04/03/20 21:21
>>961
自作なんかしたら、他と統一できなくて
混乱するだけというのが分からんか?

966 :仕様書無しさん:04/03/20 21:23
SUNが作れば良いじゃん

967 :仕様書無しさん:04/03/20 21:24
>>962
お前の意見なんかどうでもいい。
演算子が使えないのが問題と多くの人が言っている。

968 :最凶VB厨房:04/03/20 21:24
.netで無問題

969 :仕様書無しさん:04/03/20 21:25
禿同。さっさとSUNは演算子が使える固定小数点型を作ってくれ。

970 :仕様書無しさん:04/03/20 21:26
Javaに過ちは無い

971 :仕様書無しさん:04/03/20 21:27
ブビですら使えるのに・・・。情けない。

972 :仕様書無しさん:04/03/20 21:29
>>969
結局そこにたどり着くんだよね。
SUNは固定小数点型が必要だって気づかなかったのだろうか?
所詮組み込み用として作られた言語か。

973 :仕様書無しさん:04/03/20 21:30
Javaは悪くないSUNが悪い。

974 :仕様書無しさん:04/03/20 21:30
組み込み用としても使われてないけどなw

975 :仕様書無しさん:04/03/20 21:34
金融系で使われることを考慮していなかった。と。

976 :仕様書無しさん:04/03/20 21:41
C#のdecimalとJavaのBigDecimalとでは若干仕様が違う。
C#は128bitsまでしか使えないという欠点を持つ。

>>91-93
すべて却下。現実を見なさい

>>942
頭悪いぞお前。
筋がとおっていないどころか
日本語になってないぞ。

>>950
そういう結論を持ちたいなら
JCP(Java Community Process)に手紙を送ってみろ。

ほれ
http://jcp.org/

977 :仕様書無しさん:04/03/20 21:41
>>946
そのとおり、>>882を読んでも理解できないC厨( >>948 )のバカさ加減がわかったでしょ?


>>948
プ お前頭おかしくなったか?(ワラ


978 :仕様書無しさん:04/03/20 21:46
JavaにはC#のDecimalに対応する型が無いんだよなぁ。
それでDecimalで十分なのにBigDecimalを使わなきゃいけない。

979 :仕様書無しさん:04/03/20 21:46
>>951
プ またまたよりにもよってVB.NETかよ(ワラ
C#じゃないんだな。
C#すらJavaには勝てないがw

980 :仕様書無しさん:04/03/20 21:49
>>882よんだけど笑える。
> プラス演算子 + がオブジェクトをtoString()でString型に変換された文字列を
> 連結するためのものなのか、BigIntegerやBigDecimalどうしの加算なのかを区別するほうほうが
> 必要になってくる。

文字列と連結したときに文字列として連結するか
数値として計算するかってBigDecimalの問題じゃなくて
Stringの問題じゃん。

>>882はバカだって事が良く分かった。

981 :仕様書無しさん:04/03/20 21:51
飽きもせずに何時間も枝葉の議論を・・・。

982 :仕様書無しさん:04/03/20 21:53
C#厨がいかにして短絡的な思考しか持っていないかが良くわかった。
演算子オーバーロード厨の論理はここまで破綻しているとjは。
C#厨の主張は矛盾だらけだ。

>>978
自分でBigDecimal#setScale()を微調整汁。
それが使いにくいならそういうフレームワークを自作汁。
それかJ2SE1.5のjava.math.MathContextクラスを使え。
そこにMathContext.DECIMAL128という定数がある。
そいつをBigDecimalのコンストラクタにつっこめ。

こうやってな。

BigDecimal value = new BigDecimal("6.879, MathContext.DECIMAL128");

これでC#のdecimalとほぼ同様の精度に固定できる。

983 :仕様書無しさん:04/03/20 21:53
こんちくしょう!あおられたぞーーーーー(フンガー

984 :仕様書無しさん:04/03/20 21:53
>>980
だよねー。intでも同じ問題は発生しているのに
本質が分かってないよねー。

笑えるネタ再浮上させた>>977に感謝w

985 :仕様書無しさん:04/03/20 21:54
>>982
> それが使いにくいならそういうフレームワークを自作汁。
自作したら他と統一できなくて
混乱を増すだけだということぐらいわからんか?


986 :最凶VB厨房:04/03/20 21:56
おもしろいお方だw
β版をうれしそうにすすめられてもですねぇ。

987 :仕様書無しさん:04/03/20 21:56
>>982
激しく見にくいんだが?


988 :仕様書無しさん:04/03/20 21:56
>>980
馬鹿はお前だとしか言いようがない。
お前の知能指数の低さが最も笑える。

くだらない宗教戦争をしたがるお前の心がイカれている。
それがみっともないほど笑える。
Stringには問題は無い。
お前は読解力もなければ日本語を読む能力がないということが良く分かった。
無駄に演算しオーバロードを自由に定義できることの副作用とその対策を
お前は寝ることができていない。


989 :仕様書無しさん:04/03/20 21:58
>>984がどうしようもない厨房だと言うことがわかった。

さらに>>980>>984が同一人物であることも発覚!
そこまでしてC#を弁護する馬鹿さ加減には失笑を買わざるを得ない

990 :仕様書無しさん:04/03/20 21:59
>>985
演算子を自作するほうがよほど
混乱をきたすだけだということぐらいわからんのか?

991 :仕様書無しさん:04/03/20 21:59
寝ろ!とりあえず寝ろ!!

992 :仕様書無しさん:04/03/20 21:59
> 無駄に演算しオーバロードを自由に定義できることの副作用とその対策を
だれがオーバーロードの話をしているんだ?
Stringの+はオーバーロードかよ?
こいつはなんかとんでもない勘違いをしているようだ。


993 :仕様書無しさん:04/03/20 22:00
>>987
MathContext.DECIMAL128をマジックナンバーでどうにかすることくらい
考えれ

994 :仕様書無しさん:04/03/20 22:00
>>989
煽られて必死になっているところをみると
お前も誰かと同一人物っぽいな。

995 :仕様書無しさん:04/03/20 22:01
さあ、盛り上がってまいりました。(ドンドコドン

996 :仕様書無しさん:04/03/20 22:01
>>992
アフォか。読解力のないやつだな。
餓鬼の粘着みたいにいつまでもだだをこねるな。
Stringの+は自分で自由にオーバーロードできるものではないということがわからんのか貴様

997 :仕様書無しさん:04/03/20 22:01
>>994
自作自演がばれて必死になっているおまえは 
>>980>>984と同一人物っぽいな

998 :仕様書無しさん:04/03/20 22:01
>>990
誰も演算子の自作の話なんかしていませんが何か?
Stringに+を作ったように、
Decimalに+等を作れというだけのことですが?

999 :仕様書無しさん:04/03/20 22:02
がんばれ。おっさん^^

1000 :最凶VB厨房:04/03/20 22:02
VB大人気

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

212 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)