06/05/10 19:24:49
>>415のマシンのスペック情報ﾏﾀﾞｰ？
447:仕様書無しさん
06/05/10 19:25:42
>>442
冗長性もとくになく短いだろw
文字区切りも少ないしな
448:仕様書無しさん
06/05/10 19:25:58
getJavatyuUnkonaBakadayon
configureResponseFromAxisFault
漏れのサンプルのが短かったよ＞レスくれJava厨
449:仕様書無しさん
06/05/10 19:26:25
>>415のマシンは500MHz程度と見た
そりゃ遅くなる罠
450:仕様書無しさん
06/05/10 19:27:43
>>448
前者は意味が通じないし冗長だし
後者のほうが意味がわかる。
getCgenngochu(Attribute.UnkodaBakadayon)
のほうがいいな
451:仕様書無しさん
06/05/10 19:28:35
そもそもBakadayonというネーミングがC言語厨のセンスの無さを
伺わせる。
452:仕様書無しさん
06/05/10 19:29:20
しかもC言語厨はUnkodaなんてネーミング。
小学生かお前はw
453:仕様書無しさん
06/05/10 19:30:38
長さで負けたので悔しくてネーミングを叩きだしましたｗ
454:仕様書無しさん
06/05/10 19:32:43
喪前の設計センスはいいなｗ
apacheに言ってやれよｗ
クラス設計を見直したほうが良いってさｗ
455:仕様書無しさん
06/05/10 20:42:03
>>431
お前らさ、>>403のコードが1.5だということすらわからないの？ｗ
-serverオプションとかさあ、つけて自分のマシンで試してみりゃいいじゃねぇか
ソースも出てることだし。
まあ、Javaは遅いよ。何が原因かは知らんが。
456:仕様書無しさん
06/05/10 20:48:30
> 長さで負けたので悔しくてネーミングを叩きだしましたｗ
またC言語厨の言い訳だw
名前のセンスのもんだいなんだがw
457:仕様書無しさん
06/05/10 20:49:29
>>455
10倍速くしたというのが信用できないから
まずは言い出しっぺのあんたからスペックを提示してみたほうが
いいんじゃないか
458:仕様書無しさん
06/05/10 20:50:32
別に信用しなくてもいいんじゃね？そんなに信用できないなら実行してみれば？ｗ
459:仕様書無しさん
06/05/10 20:57:45
まあでもネタみたいに見える。俺はめんどくさいからやらないけど。誰かが追試してくれればいい。
460:仕様書無しさん
06/05/10 21:05:14
クレクレ君に真面目に付き合うとこうなるという例。
461:仕様書無しさん
06/05/10 21:15:37
面白いことを発見した。
コードを以下のように書き換えたら
List<Integer> list = new ArrayList<Integer>();
Set<Integer> set = new TreeSet<Integer>(list);
Random r = new Random();
final int N = 1000000;
for (int i = 0; i < N; ++i) {
set.add(r.nextInt());
}
long start = System.currentTimeMillis();
Collections.sort(list);
long end = System.currentTimeMillis();
System.out.println("Java : " + (end - start) + "ms"); //$NON-NLS-1$ //$NON-NLS-2$
こういう結果になった。
Java : 0ms
462:仕様書無しさん
06/05/10 21:18:06
Javaのほうが速くなってるのはどうして？
463:仕様書無しさん
06/05/10 21:21:02
それに何の意味があるの？
464:仕様書無しさん
06/05/10 21:21:52
>>462
Set.addのときにソートしてるから。
くだらないから無視しときなさい。
465:仕様書無しさん
06/05/10 21:31:31
set.addもうちの環境だとC++と比べて2倍ぐらい遅いなあ。
やっぱりJavaは遅いのかな。遜色ないと聞いていたのに。
466:仕様書無しさん
06/05/10 21:42:26
おそらく、C++のSTLとJavaのコレクションを比べるから2～10倍遅くなってしまうだけで、
よく言われる遜色ないというのは、細かいルーチンを自分で手で書いて
比べれば遜色ないという意味だろう。
おそらくSTLのチューンが進んでいるのではないだろうか。
467:仕様書無しさん
06/05/10 22:21:38
>>464
つまり、Set.addでソートしておけば速いってことじゃないのかな？
468:仕様書無しさん
06/05/10 22:21:52
>>465
ソースコード公開きぼん
469:仕様書無しさん
06/05/10 22:22:46
>>466
2～10倍になるちゃんとしたデータが欲しい。
sortは差はかなりでているけど
ほかのコレクション系についてはどうだろうか。
470:仕様書無しさん
06/05/10 22:43:31
>>467
それはJavaとC++を比べてどうこういうのとは問題が違うだろう。
471:仕様書無しさん
06/05/10 23:04:45
コードレビューや技術的な話になるとすっかりなりを潜めるｸﾞﾗﾏｸﾝ
472:仕様書無しさん
06/05/10 23:08:28
ﾌﾝﾌﾝ
JAVA厨藁
473:仕様書無しさん
06/05/10 23:14:11
つかVBは蚊帳の外
474:仕様書無しさん
06/05/10 23:14:56
コードレビューはeclipseがやってくれるから大丈夫、
変数が変でもあとでリファクタリングすれば大丈夫
て思ってるんじゃね？
475:仕様書無しさん
06/05/11 00:28:15
そんなＶＢ厨やC言語厨みたいな甘い思考じゃあるまいし
476:仕様書無しさん
06/05/11 00:29:04
データ無いのか。
TreeSet使った場合のC++版のソースコードは見せないのか。
つまりJavaでやってもC++でやっても大差ないってことかな
477:仕様書無しさん
06/05/11 02:46:37
その程度のこと自分で書けよｗ
何も出来ない奴は情報を得る資格もないし、これから苦労するぞ。
478:仕様書無しさん
06/05/11 08:11:29
書けないからクレクレしてパクリたいのがJava厨ですから
479:仕様書無しさん
06/05/11 13:32:58
どうせC厨も何もかけないだろ
オブジェクト指向も何もわかってないんだからな
480:仕様書無しさん
06/05/11 16:16:09
で、単純にソートしたのが早いのは分かったけどその後はどうするの？
項目のinsertしたあと毎回ソートするの？
481:仕様書無しさん
06/05/11 16:18:25
クタたんは解体されます。
482:仕様書無しさん
06/05/11 21:30:10
んだな。insertするたびにsortするのはアホらしいな。
だからJava標準関数には凝ったsortのアルゴリズムが
用意されていないんだろうな。
だから挿入ソートで挿入した時点で即座に
順序が決まるSortedSet, SortedMapのサブクラスのコレクションクラス
であるTreeSetやTreeMapなどのほうが
使い勝手がいいな
483:仕様書無しさん
06/05/11 21:33:25
だから何？そんなこと言ってみたってJavaが遅いことには変わりないんだけど。
484:仕様書無しさん
06/05/11 21:38:47
sortの使い道がわかってないな。
insertするたびにsortする馬鹿なんか、もともとどこにもいねぇよｗ
それでもsortって関数は存在し、使われてるわけだ。
人間一人にsortの使い道を全て想像できるわけないだろ。
485:仕様書無しさん
06/05/11 22:36:29
>>483
それこそだから何？
遅いからどうしたって話なんだけど。
仕事もたくさんあるしC++にリプレースする必要が
あるほど遅くは無いんだけど。
486:仕様書無しさん
06/05/11 22:37:10
>>484
> sortの使い道がわかってないな。
> insertするたびにsortする馬鹿なんか、もともとどこにもいねぇよｗ
sortに拘るC言語厨がいるから突っ込んでやったんだろ
487:仕様書無しさん
06/05/11 22:39:14
>>486
だから、それがめちゃくちゃ的外れな突込みだがな。
488:仕様書無しさん
06/05/11 22:40:30
>>485
スレタイ見てみろ。遅さを議論するスレです。
sortの使い方を議論するスレでも仕事にどちらが使えるかを
議論するスレでもない。
489:仕様書無しさん
06/05/11 22:50:42
sortにこだわってるのはむしろJava厨。
とっくにset.addも2倍遅いという結論が出てる。
俺も試してみたけど、そのぐらい遅かった。
490:仕様書無しさん
06/05/12 00:04:06
>>488
え？ Javaが遅い遅いと愚痴をこぼしてばかりいる
バブル世代の愚かさを嘲笑うスレじゃなかったっけ
491:仕様書無しさん
06/05/12 00:04:24
>>489
sortが遅いと言い出しっぺしたのはC言語厨だろ
492:仕様書無しさん
06/05/12 01:10:27
口が軽く仕事の厚みもペラペラの
JAVAさんのネタでした。
チャンチャン
493:仕様書無しさん
06/05/12 02:39:52
>>491
sortを最初に言ったのはJava厨じゃなかったかもしれないが(C言語厨？w)
それにこだわってクレクレ言いまくった挙句、的外れな指摘をスルーされても
繰り返しまくったのはJava厨だろ。
まあJavaの知識すら初歩レベルっぽいからJava厨とは呼べないかもしれないけど。
494:仕様書無しさん
06/05/12 02:42:25
C#って最近きてるよね。くさってもMicrosoftですよ。Javaはピンチですよ。
495:仕様書無しさん
06/05/12 02:44:49
いや、まだ全然大丈夫だろ。
496:仕様書無しさん
06/05/12 02:45:36
M$の人いってたけど、来年はC#の年になるみたいだね
C#の開発の方が来年は多くなるみたい。そのせいで
単価ちょっとずつ上がってるってさ
497:仕様書無しさん
06/05/12 02:46:46
いくらM$でもそこまでは言わないだろｗ
ソースあるのか？
498:仕様書無しさん
06/05/12 08:18:58
実際.aspxでぐぐってみろよ
JR東日本も.net C#その他多数公開されている
今後どんどん増える。
JavaはJAL,ANA,GET-Uしかない、2chで遅いと有名になってしまって今後増えそうもない。
499:仕様書無しさん
06/05/12 08:27:36
カブドットコムのチャートもJAVAなんだけど
いちいち再描画するのが遅い
500:仕様書無しさん
06/05/12 09:01:46
>クレクレ言いまくった挙句
ﾜﾗﾀ
501:仕様書無しさん
06/05/12 09:44:16
正解を言うと、Javaのコレクションが遅いのは、Object単位で
操作してるから。
これはJavaの構造上どうしようもない。
どうあがいてもコレクションがSTLを上回ることはないよ。
502:仕様書無しさん
06/05/12 10:12:18
JavaがC++と同等に速いというのは、
・基本データ型にコレクションを使わない
・描画は除外
・起動時間は除外
という条件を満たしてはじめて成り立つ。
世の中、たいていのうまい宣伝文句にはこうやって条件が
省かれてるんだよ。
503:仕様書無しさん
06/05/12 18:36:20
>・起動時間は除外
詐欺
504:仕様書無しさん
06/05/12 22:51:26
C#もそんなに速いとも思えんけどね
505:仕様書無しさん
06/05/12 23:29:55
ネィティブ以外は糞。
506:仕様書無しさん
06/05/12 23:45:36
VMのつくりは、C#のほうがすっきりしているし
遅いというなら、メモリ管理全部アンマネージで管理してみろ
507:仕様書無しさん
06/05/13 04:32:01
ていうか、なんだかんだいってSunのソフトって、質に関してはMSのほうが遥かに上だな。
まあ、かけた金額からいっても比べるのは可哀想かもしれないけど。
508:仕様書無しさん
06/05/13 20:33:22
Javaの貧弱さとMSの技術力（資金力）の高さはしかたない
509:仕様書無しさん
06/05/13 21:26:20
なんか最近のJavaとJava厨押されっぱなしだな
510:アホアホうんこ
06/05/13 22:06:14
JAVA使いってのは小僧が多いし、
経験もない頭でっかちが命削ってコード書いてきたベテランに口喧嘩してもかなうはずがない
JAVA厨が押されて当たり前でしょう
511:アホアホうんこ
06/05/13 22:11:01
JAVAだ、Ｃ＃だ、.NETだ、言語 言語 と騒いでいるが、一番重要な言語を忘れてないかい？
そんな賞味期限つきの言語なんかよりよっぽど大切な言語、それは
ストラクチャークエリー言語でしょ
512:仕様書無しさん
06/05/13 22:20:28
SQLっていっても複数あるわけだが・・・
そのなかで騒いでいるのと同じでしょ・・・
513:アホアホうんこ
06/05/13 22:27:30
ＳＱＬ９９だけ知ってれば問題ないでしょ、
５１２は知ったかぶり
514:512
06/05/13 22:38:48
すまん。やっぱり無理な突込みだったな
515:アホアホうんこ
06/05/13 22:48:10
実を言うと俺（アホアホうんこ）はギリギリＪＡＶＡ世代で
仕事でＪＡＶＡのアプリ、ＪＳＰ、サーブレットやった事あるけど
開発するとき、デバッグとか重くて毎回イライラしてた
イクリプスやフォルテ（ワンスタジオの先祖）は重くてダメポンだけど、ちょっと前のＡＰワークスなんて
重すぎてデバッグかけるとＰＣがフリーズだったぞ（ペン３、メモリ５１２だったけど）、スーパーダメダメ
といろいろやったけど、ＰＧ的にはＭＳ製品がイイヨ。サクサクとデバッグできるし
設計側の目で見た場合はJAVAでも何でも、どーでもいいよ
516:仕様書無しさん
06/05/13 23:28:40
携帯アプリ開発の俺が一番アホアホうんこだから心配しなくていいよ。
517:仕様書無しさん
06/05/14 04:54:33
＞ＳＱＬ９９だけ知ってれば問題ないでしょ、
ほんまかよ。
518:仕様書無しさん
06/05/14 09:13:42
SQL99 て言いたいだけだろ。
あれに完全準拠した DBMS などなく、
しかもチューニングの手法もバラバラな状況で
「SQL99 だけ知ってれば」
など笑止。
519:仕様書無しさん
06/05/14 20:08:24
>>502
> JavaがC++と同等に速いというのは、
> ・基本データ型にコレクションを使わない
> ・描画は除外
> ・起動時間は除外
> という条件を満たしてはじめて成り立つ。
今のマシンパワーならそれらの条件を
満たさなくても十分速いよ
520:仕様書無しさん
06/05/14 20:09:09
とりあえずやねうらおを撲滅させて
次はネカマのryokoを撲滅させるか。
奴はC++をマンセーしていたよな。
痛い目に遭わせてやる
521:仕様書無しさん
06/05/14 20:15:09
>>519
そのマシンパワーがあればC++はもっと速いよ
つまりどんな環境であっても
C++＞＞＞Java
この構図はかわらないわけだ
522:仕様書無しさん
06/05/14 20:49:15
Java支持派の受け答えはどっかの学会の答弁みたいだな。
523:仕様書無しさん
06/05/14 20:54:23
そりゃそうじゃね。やり込められないように逃げて
突っつき返して逃げるしかないし
524:仕様書無しさん
06/05/14 20:55:00
稚内のおっさんの影響か？
525:仕様書無しさん
06/05/14 23:11:54
>>521
> >>519
> そのマシンパワーがあればC++はもっと速いよ
> つまりどんな環境であっても
> C++＞＞＞Java
> この構図はかわらないわけだ
絶対的な微々たる速度差でC++がJavaに勝っているからといって
今更Javaで作られた製品をすべてC++に移行するのは
まったく採算に合わないわけだが。
各OSやCPU毎にまた作り直すのは
アプリが大規模で有ればあるほど無駄というものだよ。
526:仕様書無しさん
06/05/14 23:12:38
ryokoのブログが消えて
やねうらおが会社を畳む。
次はどこのC言語厨を攻撃するか
527:仕様書無しさん
06/05/14 23:15:09
今のマシンでもJavaの起動は遅いよ。
528:仕様書無しさん
06/05/14 23:28:19
>>527
バカだなお前
一度起動したら二度と起動し直さなくても良いように作れば良いんだよ。
529:仕様書無しさん
06/05/14 23:39:07
>>528
奇才現る
530:仕様書無しさん
06/05/14 23:57:05
バカだなお前
起動しないようにすれば良いんだよ。
531:仕様書無しさん
06/05/15 00:59:34
どれだけパソコンが進化しても、クリティカルな処理が2倍になったりすると、
2倍にならない場合と比べて不便だろ。
クリティカルな処理にコレクションを使えないというのは結構きつい。
532:仕様書無しさん
06/05/15 01:16:10
＞＞５１９
十分遅くて、メモリ馬鹿食いです、、、
533:仕様書無しさん
06/05/15 01:17:09
＞＞５２５
全てのOSで動作させないものほど、機種依存を高めて安定させるべき
534:仕様書無しさん
06/05/15 01:17:48
十分遅いし、そのくせメモリ馬鹿食い
だからSはノード増やせとかDQNな事を
平気で言ってくる
535:仕様書無しさん
06/05/15 01:37:00
>>531
どんなときでも同じプログラムの速度差が2倍の比例関係にあるとは
限らないんだが。そんな単細胞みたいなワンパターンな
考え方しかできないからいつまでたってもJavaに飛び込むことができないんだよ。
Javaはレスポンス性能ではC++には劣るが、
スループット性能ではC++をはるかに上回る。
536:仕様書無しさん
06/05/15 01:37:47
>>532
CPU3GHz, メモリ2GBだが、Javaは十分速いぞ。
わざわざC++にリプレースする必要もない。
これがサーバアプリだったらなおさらC++に
リプレースするメリットなんて全くない。
537:仕様書無しさん
06/05/15 01:38:24
>>533
> ＞＞５２５
> 全てのOSで動作させないものほど、機種依存を高めて安定させるべき
全てのOSに対応させてどうする。
使いもしない古臭いOSにまでいちいち対応するニーズがどこにある。
538:仕様書無しさん
06/05/15 01:41:34
JavaのGUIは負荷が応答がなくなるのを何とかして欲しいんだが
539:仕様書無しさん
06/05/15 01:42:48
>>538
×負荷が
○負荷が高くなると
540:仕様書無しさん
06/05/15 01:58:59
たとえばどんなアプリ？
541:仕様書無しさん
06/05/15 02:24:58
＞Javaはレスポンス性能ではC++には劣るが、
＞スループット性能ではC++をはるかに上回る。
分かりやすく説明しておくれ。
542:仕様書無しさん
06/05/15 02:48:28
聞くまでも無くハッタリｗ
543:仕様書無しさん
06/05/15 06:56:33
ApacheがなぜJavaで出来てないのか考えたらわかりそうなものなのになｗ
544:仕様書無しさん
06/05/15 07:09:20
Javaで作られたサーバーって結構あるんだが。
545:仕様書無しさん
06/05/15 07:28:32
そして結構失敗してるな。
546:仕様書無しさん
06/05/15 07:42:33
YahooのサーバーがJavaなわけだが。
もとはLispだが。
547:仕様書無しさん
06/05/15 07:52:52
＞＞５３６
あ り え な い
548:仕様書無しさん
06/05/15 11:58:27
>>543
「開発が始まった当初、Java など存在していなかったから」以外の理由が？
549:仕様書無しさん
06/05/15 19:43:48
>>538
AWT-Thread以外からのデータ投入は、
キューイングしてかつ適当なインターバル開けてかつAWT-Threadに移譲してる。
それでも極まれに数十秒AWT-Threadが戻ってこないときがある。
awt と swing 整理して綺麗に書き直して欲しい。
550:仕様書無しさん
06/05/15 20:12:11
>>547
ありえない根拠は？
Javaの仕事とC++の仕事、どっちが
多いと思っているんだ？
551:仕様書無しさん
06/05/15 21:46:35
>>550
まぁC++使いこなせる奴がそういないからね。
552:仕様書無しさん
06/05/15 21:53:41
いや、そういう理由だけでC++の仕事が少ない分けじゃあないハズなんだが。
ヘッダファイルの扱い欠陥が管理のしづらさと言語としての使いにくさを決定的に
してC++の人気が減ったのではないかと思う。
553:仕様書無しさん
06/05/15 22:15:42
ヘッダファイルの扱い欠陥？何を言ってるんだ？池沼か
原因はそんな事じゃないだろ。 もっと単純な事だ
使いこなせる奴がいない
これだけだ
554:仕様書無しさん
06/05/15 22:20:43
マが低レベル化したからね。
昔は中高生が趣味でアセンブラ使ってたわけで。
555:仕様書無しさん
06/05/15 22:22:24
今日も元気に沸いてるお
556:仕様書無しさん
06/05/15 22:22:58
Javaの仕事が多いなら理由はJavaコンサルが大風呂敷広げてホラ吹きまくってそれが客にウケたからだ。
少なくとも技術的に良かったからではない。
557:仕様書無しさん
06/05/15 22:29:13
つーか、お前らJava嫌いなC言語厨の
コミュニケーション能力が弱いから顧客を
説得できないだけじゃねえのか？
そうとしか思えないのだが。
558:仕様書無しさん
06/05/15 22:38:27
いやプログラマの質の劣化が進んでるから（特に若年層） 抽象的でメモリリークなどの責任を他の要素に負わせやすく
また、開発環境もタダで出回っていて業務外で自習させられることも手伝って、Javaが伝搬してるってことだな。
伝染病末期の日和見感染みたいなもんだよ
559:仕様書無しさん
06/05/15 23:01:15
>>558の発言のどこに真実が隠されているのだろう・・・・・・・・・・
560:仕様書無しさん
06/05/15 23:25:31
この世にプログラム言語がJavaしかなかったとしよう。
この世の終りだ。
561:仕様書無しさん
06/05/15 23:56:06
そんだけ客が馬鹿になったというか、客が技術の移り変わりについていけなくなっている。
まぁいらん技術ばかりだったとしてもだ。
そんな世界でのコンサルってのは、説得力とかいらん。
技術者的善意があっては勤まらないものになってきている。
いや、中には素で自分は素晴らしいソリューションを提供しているのだと勘違いしているのもいるけど。
562:仕様書無しさん
06/05/15 23:58:36
JAVANUMAとか考えるとおぞましくて死にそう
563:仕様書無しさん
06/05/16 00:01:55
元々Windowsプログラミングができない人向けにSunが社内ツールとしてつくったのがJavaのはじまりだからね
564:仕様書無しさん
06/05/16 00:04:06
あのSUNの糞爺がお救い言語を開発しなければ世の中
間違ったほうにはいかなかった。
でもそろそろSUNは無くなる来期も赤字なら確実に消える
これはつまり暗く腐った臭気を漂わせていたJAVAから
我々が解放されることを意味している
565:仕様書無しさん
06/05/16 00:17:10
>564
大罪を犯したSunには消えて欲しいが、そうなるとM$の対抗馬が完全に消える
やりたい放題になるよ。。。
566:仕様書無しさん
06/05/16 00:19:07
みんなうそばっかしだね
567:仕様書無しさん
06/05/16 00:23:12
まぁノベルとか赤帽潰れたらWindowsでいくからそれはそれでいいよ
SUNは邪魔業界のゴミでしかない。
JAVAのコミュニティでVMが糞とかいうと凄い非難浴びるしな
会社でも同じ事言うがすげー顰蹙買う
568:仕様書無しさん
06/05/16 03:39:33
>>549
なるほど、勉強になった。
ありがとう。
569:仕様書無しさん
06/05/16 03:46:32
>>568
それでいいのか？
570:仕様書無しさん
06/05/16 05:56:53
Javaが人気出たのはEclipseが便利すぎるから。
571:仕様書無しさん
06/05/16 07:59:40
import java.awt.*;
import java.awt.event.*;
class baka1 extends WindowAdapter {
public static void main(String args[]) {
new baka1().start();
}
private void start() {
Dialog alert = new Dialog(new Frame() , "うるさい>>1は死ね");
alert.add(new Label("嘘つくな>>570も死ね"));
alert.setSize(300 , 150);
alert.setVisible(true);
alert.addWindowListener(this);
}
public void windowClosing(WindowEvent e) {
System.exit(0);
}
}
572:Mb
06/05/16 08:24:04
>>570
年寄りはeclipse 使わんほうがいい。
あれだけ楽だと早くボケが来る。
最近はeclipse 使わんとスペルミスばっかりで
コンパイルさえ通らん。
573:仕様書無しさん
06/05/16 09:03:02
>>569
今はJava系開発から離れてるからとりあえずいいよ
574:仕様書無しさん
06/05/16 14:09:12
>>535
正解
JavaでC以上のスピードを出すのはサーバーVMのときだけ
サーバーVMは強度の最適化のためにメモリとコンパイル速度が
通常のhotspotクライアントよりかかるためにレスポンスは悪い
上で出てたC++のコードとあわせるならプリミティブを登録するListにかえるべき
Javaのパフォーマンスチューニングは無料で使えるプロファイラで簡単にできるんだから
馬鹿でも最適化は容易だよ
575:仕様書無しさん
06/05/16 14:12:10
>>573
こんなのがJavaの技術者の平均レベルを下げている例
実際はできるやつはCだろうがJavaだろうが自分で勉強してなんでもこなす
すぐに調べれば分かるようなことをまったく理解しないまま進めるやつもいるからな
576:仕様書無しさん
06/05/16 14:27:02
>>575
だから開発してないっていってるじゃん
Java製アプリ使ってるだけだっつに
下二行は常識だろ
それこそ何の意味もない書き込みだ
577:仕様書無しさん
06/05/16 16:47:11
URLﾘﾝｸ(www.google.com)
578:仕様書無しさん
06/05/16 17:21:02
C++/CLI の登場、によるJavaの衰退はもう止まらないだろうね、、、
ECMA 標準に、そして ISO もまもなく、、、。
Standard ECMA-372 C++/CLI Language Specification
URLﾘﾝｸ(www.ecma-international.org)
URLﾘﾝｸ(signe.japan.webmatrixhosting.net)
Java房も下のコードを見れば、、
int main() {
System::Console::WriteLine("hello, world");
}
C++でネイティブ、.Net、他言語連携、、、、
全てが行え、かつ統一的なコーディングが可能である。
JavaもCLI配下になって生き残るのか。。。。？
579:仕様書無しさん
06/05/16 19:12:14
日本語でおけ
580:仕様書無しさん
06/05/16 19:25:58
MS-GW か。
581:仕様書無しさん
06/05/16 19:26:23
GW じゃねーよ GK だろ阿呆＞俺
582:仕様書無しさん
06/05/16 20:47:50
>>561
そう顔真っ赤になってまで必死になるな。
そんなに客が馬鹿だと思うなら
客を説得すればいいのにw
それすらできないからJavaのせいにして
「Javaは馬鹿でもできる言語だから仕事が多いんだ！」と
ファビョっているんだろC言語厨は。
C言語厨は実に商売が下手だなあw
583:仕様書無しさん
06/05/16 20:51:06
>>577
Javaのトレンドが圧倒的だね。
C#はちょっと伸びようとしているけど全然のびが悪い。
C++は全くグラフ上から姿を現さない。
584:仕様書無しさん
06/05/16 22:55:12
トレンドも何も・・・
585:仕様書無しさん
06/05/16 23:02:55
今Javaは上昇トレンドです
586:仕様書無しさん
06/05/16 23:18:24
>>574
アホか？
そもそもC++じゃそういうコード書くときにはvectorなんてちんたらしたもんは使わんだろ。
587:仕様書無しさん
06/05/16 23:21:26
>>586
それならJavaだって自前でかくわけだし同じだろ
そうなるとバブルソートじゃないけどCのほうが遅くなるかもね
>>583
Cだとかなりの数が出るからC++だとちと問題だと予想する
それでもTOPはJavaだが
588:仕様書無しさん
06/05/16 23:35:35
Javaは乱立していたUnix系OS上での共通基盤という意味があったのだが、残念ながら
Linuxの一人勝ちでその意味も薄れてしまった。
SolalisやAIX機はx86PCよりパフォーマンスがずっと優れており、VMに足を引っ張られても
問題ないってのがそもそもJavaの前提なんだな。
ところがx86の進化は留まるところをしらず、sparcはおろかalphaすら抜き去って最速になり
しかも低コスト。
対応すべきOSが集約してきたらC/C++で組めばいいだけのこと。
今やSolarisやAIXなんかは無視しても全然無問題で、LinuxとWin32でC/C++使えばそれでOKなのだ。
589:仕様書無しさん
06/05/16 23:37:51
こらこら死刑宣告をコピペするな。
590:仕様書無しさん
06/05/16 23:59:52
>>588
> Javaは乱立していたUnix系OS上での共通基盤という意味があったのだが、残念ながら
> Linuxの一人勝ちでその意味も薄れてしまった。
それでもJavaを使わないと。Windowsの各バージョンとLinuxの各バージョン毎にコンパイラやバイナリを
変える必要が出てくるんだがな。
> 対応すべきOSが集約してきたらC/C++で組めばいいだけのこと。
> 今やSolarisやAIXなんかは無視しても全然無問題で、LinuxとWin32でC/C++使えばそれでOKなのだ。
LinuxやWindowsでもバージョンやカーネルが異なる、APIが異なることで
コンパイラやバイナリを変えないと動かないものがあるのでJavaの必要性がないとは
まだまだ言い切れないぞ。
甘く見ていると、こういう結末が待っているぞ。
お前がC++で、あるソフトを作ったとする。10年経過した。
その間にOSは変わった。古いコンパイラでコンパイルしたバイナリが動かなくなった。
591:仕様書無しさん
06/05/17 00:00:39
Javaが速いとか言ってるやつはJavaしかやったこと無い奴なのかね？
そうだ、そうに違いない。
592:仕様書無しさん
06/05/17 00:01:06
新しいコンパイラを導入した。
10年前のソースコードをコンパイルできなくなった。
593:仕様書無しさん
06/05/17 00:02:21
そもそも10年たったらそんなソフト使わない。
企業も見切りをつける。
というかその間何度も新しいソフトを開発してるわなぁ。
594:仕様書無しさん
06/05/17 00:02:32
OSが乱立していた時代に別ﾌﾟﾗｯﾄﾎｰﾑ上で同じｱﾌﾟﾘを動かそうとしていて一応完成
したのがWindows。まあ結局ﾌﾟﾗｯﾄﾎｰﾑ自体同じになったわけだが。
あの頃屋根(マシン)の上に屋根(OS)乗っけるのは無駄だとおもったものだ。
OSなんぞメモリ管理さえしてりゃいいんだよと思ったものだ・・・。
で、そのメモリ管理さえ明け渡して、屋根の上の上に乗っけるようなJavaって
何だと当時思った。今でもそうだが。
Javaって結局だめだと思ったのは、所詮Javaはエミュでエミュはマシン環境に
依存しない位ガチガチにしなきゃいけなくて(クロック速度レベルまで)で、
ある程度あきらめないといけない。
Javaはそういった出来の良いエミュの定義踏み外しているのでだめぽ。
595:仕様書無しさん
06/05/17 00:03:07
さらに10年経過した。新たなOSが生まれた。
それどころか、新たなCPUが生まれた。
20年前のC++ソースコードは使い物にならなくなり、
現在の環境に対応させるために何100兆円もの予算
をかけなければならなくなった。
(これは、都庁を修理するのに一から立て直すのと同じくらい
コストがかかってしまう問題に似ているな。実に。)
596:仕様書無しさん
06/05/17 00:04:33
20年前に作ったchar*の文字列操作俺様ライブラリを今でも使っていますが。
597:仕様書無しさん
06/05/17 00:05:59
新世代VMを導入した。
１年前のバイトコードが動かなくなった。
598:仕様書無しさん
06/05/17 00:08:56
50年後、量子コンピュータが実用化された。
今までのソースコードはすべて役に立たなくなった。
C++で記述されたソースコードの量子コンピュータに
対応させるためのリプレースは莫大なコストがかることがわかった。
一方、Javaで記述されたソースコードはJVMを
量子コンピュータに対応させるだけでJavaソースコード全般を
修正する必要はなかった。そのためコストはC++よりもかからず、
C++しかできなかった者達はマスケット銃が発明されて衰退していった
騎士達のように悲惨な運命を辿っていった。
>>593
訂正コストというものを解っていないな。
世の中には何百年経っても難なく利用されている建造物が
いくつも存在する。
ところが、あの都庁のザマは一体なんだ？ まさにC++だけで作った建造物だ。
もうあの建物も持たないぞ。あの建物は短命で、早い時期に死ぬ。
あれだけ無駄にお金をかけておきながら。
599:仕様書無しさん
06/05/17 00:10:02
やねうらおの匂いがする。
600:仕様書無しさん
06/05/17 00:17:11
そんな例出していいのか？
＞JVMを量子コンピュータに対応させるだけで
ここの部分はJavaじゃ書けないぞ？
601:仕様書無しさん
06/05/17 00:19:47
考えて見りゃJVMがC++のバイナリである以上、Javaも共崩れだな。
602:仕様書無しさん
06/05/17 00:20:15
んな早いコンピュータできたらJVMじゃなくてx86VMつくればいいだけだっぺよ。
603:仕様書無しさん
06/05/17 00:20:41
>>597
ﾌﾛﾇ
604:仕様書無しさん
06/05/17 00:23:58
>>598
現時点で10年以上前からあり一度も手直しされていない今でも現役なソフトを教えてください。
骨董品や建造物のような概念持ち込まれてもね。
605:仕様書無しさん
06/05/17 00:26:25
SesserではPojoとJunitのみがJavaの資産であるといってたからな、、、
いまはCが最も汎用的な言語であり、C++/CLIが今後の主流だろうね
JavaですらCLIあれば吸収できるし
606:仕様書無しさん
06/05/17 00:29:48
おじゃばさまは自分らだけじゃ生きていけない事を肝に銘じとかなければいけない
607:仕様書無しさん
06/05/17 01:04:22
>>598
お前なかななセンスあるな
608:仕様書無しさん
06/05/17 01:07:09
自作自演ｷﾀｰ
609:仕様書無しさん
06/05/17 01:27:51
50年後、量子コンピュータが実用化された。
今までのソースコードはすべて役に立たなくなった。
C++で記述されたソースコードの量子コンピュータに
対応させるためのリプレースは莫大なコストがかることがわかった。
一方、Javaで記述されたソースコードはJVMを
量子コンピュータに対応させるだけでJavaソースコード全般を
修正する必要はなかった。そのためコストはC++よりもかからず、
C++しかできなかった者達はマスケット銃が発明されて衰退していった
騎士達のように悲惨な運命を辿っていった。
その後・・・ソースコードを修正する必要がないので、
牢獄につながれていたJava奴隷も晴れて捨てられた。
一部は結合テスト要員としてその姿を見かけたが、
殆どが悲惨な運命を辿っていったと言う。
610:仕様書無しさん
06/05/17 03:01:25
いい加減飽きた
611:仕様書無しさん
06/05/17 03:31:19
>>604
URLﾘﾝｸ(www.vector.co.jp)
612:仕様書無しさん
06/05/17 03:33:06
>>609
だれにも指示されないネガティブキャンペーン乙
やねうらお信者の馬鹿共が書いたおとぎ話ですかw
613:仕様書無しさん
06/05/17 07:48:13
おじゃばさま乙
614:仕様書無しさん
06/05/17 10:21:24
おじゃばさまはJVMの中の人の苦労は完全に計算外なんだな。
615:仕様書無しさん
06/05/17 12:20:35
JVMの開発のことは計算に入れているだろ。
だが、Javaで書いても問題が無いものをわざわざC++で書こうと
する馬鹿の言うことなどもちろん計算外だがなw
616:仕様書無しさん
06/05/17 13:52:06
>>615
そうか？
＞Javaで記述されたソースコードはJVMを量子コンピュータに対応させるだけで
一言で片付けてるけど、これは誰がやるんだ？
617:仕様書無しさん
06/05/17 13:54:57
ジェバンニ
618:仕様書無しさん
06/05/17 14:02:06
量子コンピュータにJVMを対応しても、量子コンピュータは得意な
計算領域が違うんだからそれにあわせた言語設計をして、
その言語を用いて一から組んだほうが良いんじゃないのか？
じゃないと、以前のバイトコードを量子コンピュータで実行できたからって、
VMがもの凄いボトルネックになりそうなんだが。
まぁ、量子コンピュータも言語の知識もあまり無い俺の妄想だが。
619:仕様書無しさん
06/05/17 15:08:06
>>616
C++をスコップ、
JVMをある高機能なクレーンだとしよう。
このクレーンを使わずC++スコップだけで超高層ビルを
建設することはできなくもないかもしれないがw、
非常にコストと時間がかかる。
そこでJVMクレーンを導入すると超高層ビルを
建設することは容易になるというわけだ。
武器や炎(JVM)を持ったサル(Javaソフトウェア)と武器を持たない、
火興しもできないサル(C++ソフトウェア)、
どちらが強いと思う？
武器を持てば、確かに重たくなって動きは鈍る。
だが敵を容易に倒せるようになるわけだ。
賢くなると敵も武器(JVM)を使うようになるが。
(それが今日の人類を形成しているわけで)
「武器(Java VM)を持たない方が(C++は)強い、刀で戦うだけでアメリカに勝てる」
だなんてまるで旧日本陸軍なんだよ。
620:仕様書無しさん
06/05/17 15:10:23
>>618
確かに、if文やループ文、boolean型など
若干変化が起こりそうだけどな。
変化というより、追加となるかな。
プログラミング言語は自然言語に近づこうとしているので
新しいプログラミング言語がJavaのような言語に近づくのは
自然な前進ともいえるがね。
その中でC++やC#、Perl, PHPやLisp、アセンブラのような言語もJavaとは
違う方向から進化してゆくものだけどね。
621:仕様書無しさん
06/05/17 15:28:18
たとえ話のセンスがない上にむちゃくちゃで話にならないな。
頭おかしいのか？
Javaは図書カードのようなもの。本屋と金券屋しか扱えない。
図書流通業界つう狭い業界でしか通用しない。基本換金できないし、加盟店でしか扱えない。
JVMは日本図書流通（株）みたいなもんだよ。ここが現金と交換しないと無意味。
他のネイティブ言語で扱ってるのは、現金そのもの。
俺もセンスないわｗ
622:仕様書無しさん
06/05/17 15:31:50
あ！思いついたわ。
Javaのバイトコードは旧日本軍が発行してた軍票のようなもの。
軍隊が威勢がいいうちはお金の代わりに使えたが、まけたとたんに紙切れ。
JVMは旧陸軍みたいなもんだな。
ネイティブのコードは、国が認証した中央銀行が発行した通貨。
プロセッサ＋OSが国家みたいなもんだろ。
親亀の背中に小亀を乗せて～
623:仕様書無しさん
06/05/17 16:04:46
JAVAよぉ～
なんだかんだでバージョン合ってないと動かなかったりするだろ・・・・
624:仕様書無しさん
06/05/17 16:20:16
>>621
いや、お前のほうが頭がおかしいw
625:仕様書無しさん
06/05/17 16:21:13
>>622
>>619にC++狂信者を旧日本軍扱いされたからといって
そうカリカリするなよw
626:仕様書無しさん
06/05/17 16:23:48
>>619
いや、その強力なJVM自体を作るのにC++屋さんの協力が必要だと言ってるのだが。
なんか話がかみ合ってないな。
627:仕様書無しさん
06/05/17 16:34:26
しかし、旧日本軍などという連中が皇軍を貶める売国奴である件に関しては語らないのか？
628:仕様書無しさん
06/05/17 16:37:01
うっせー
629:仕様書無しさん
06/05/17 16:47:55
太平洋戦争はもうとっくに終わったのだよ。
アメリカが勝利下のさ。
630:仕様書無しさん
06/05/17 16:48:55
黒船来航からの１００年戦争はまだ終わってないと思うが？
631:仕様書無しさん
06/05/17 16:56:51
あれからすでに100年以上経っているんだけど
632:仕様書無しさん
06/05/17 16:59:11
つまり、おまいは自分は皇軍の輝かしい歴史に連なる大和民族ではないと？
633:仕様書無しさん
06/05/17 18:39:32
>>632は朝鮮人ですか？
634:仕様書無しさん
06/05/17 21:27:17
>>619
意味わかんねぇよ。
何でJavaがクレーンでC++がスコップなんだよ？
っていうか、>>616の問いの答えになってねえよ。
635:仕様書無しさん
06/05/17 22:04:03
JAVA厨は頭の中が回転してないから支離滅裂の事しか言えないんだよ。許してあげて。
636:仕様書無しさん
06/05/17 22:40:41
C言語厨は頭の中が回転してないからコミュニケーション能力が欠如して
人の話を聞かずに勝手に独断で話を先に進めてかつ支離滅裂の事しか言えないんだよ。許してあげて。
637:仕様書無しさん
06/05/17 23:23:27
>>636
これが噂のJava厨か。
頭の回転とコミュニケーション能力がどう関係しているのか説明してもらいたいな。
638:仕様書無しさん
06/05/17 23:26:20
大体、スコップとクレーンってどういう脳の構造で比較するんだよ。
スコップ：ショベルカー
滑車：クレーン車
これならわかるけど。頭やっぱり壊れてるんじゃないの？おじゃばさまって。
639:仕様書無しさん
06/05/17 23:31:06
>>636のおじゃばさまの書き込みは相手より中傷する言葉の数を上回ることにより優越感を見出している。
やっぱりアホだね。
640:仕様書無しさん
06/05/18 01:06:30
中傷している時点でもC厨もアホだかな。
641:仕様書無しさん
06/05/18 01:31:02
Java厨に中傷することはアホではない
642:仕様書無しさん
06/05/18 01:32:04
Java厨を だな。日本語まともに使えない俺はアホだな
643:仕様書無しさん
06/05/18 01:32:14
>>641
お前、狂ってきているぞw
もうｱﾙｶｲｰﾀﾞみたいなw
「アメリカ人を殺せば100ドルあげるよw」みたいな
644:仕様書無しさん
06/05/18 07:50:21
SesserではPojoとJunitのみがJavaの資産であると
645:仕様書無しさん
06/05/18 08:34:58
sesserて書いてあるのを見ると
akiraのﾗｯｾｰﾗていう音楽を思い出す
646:仕様書無しさん
06/05/18 10:43:14
今C++の価値なんてもうかなり薄れている。
これもインターネットが出て、Perl/CGIが出てから
スタンドアロンアプリの価値が薄まったため。
そこへJava ServletがさらにC++に止めを刺す状況になった。
今C++は組み込み系やJVM開発など細々とした分野でしか
生き残る術が無くなってしまった。
今C++を推し薦める者の大多数はただのマニアや生産性の無いオタクだけである。
647:仕様書無しさん
06/05/18 10:46:05
>>634
Javaを武器を持ったサルや火おこしを使えるようになったサル、
C++を武器も火おこしも使えないサルに喩えている例もわかりやすいんじゃないかな。
648:仕様書無しさん
06/05/18 10:52:37
その例えで言うなら
武器と火を使いこなす一部のC++人間に支配されるJava猿、
の方が正しくね？
649:仕様書無しさん
06/05/18 10:55:01
>>647
いやむしろ、観光地で自らが作り出した工業製品を使う人類（多言語使用者）と
群がってきて勝手に車に入り込んでお菓子などを盗んでいく猿（Java厨）の差なのでは・・
650:仕様書無しさん
06/05/18 10:57:20
JVMを取り上げたら何もできないJava猿。
そいつらにJVMを作って与えたC++。
C++は神なのか？
JVMを作れる新しい言語が出てきたとして、それはJavaではないのは自明だわな。
651:仕様書無しさん
06/05/18 11:22:46
C++ 面倒な仕事を安い賃金で引き受ける中国の企業
Java 中国から安く仕入れた材料で製品を作る日本の企業
652:仕様書無しさん
06/05/18 11:52:25
C++ コア技術を擁し大もうけするM$様＆Inteｌ様
Java 秋葉原の裏道で箱に詰めて売り出すショップ
653:仕様書無しさん
06/05/18 15:49:58
>>648-652
てか、なんでお前ってそんなにJavaを目の敵にしているんだ。
一人で妄想に任せた連続投稿を繰り返して
すごい私怨の塊だなw
654:仕様書無しさん
06/05/18 16:01:35
ここまでJava嫌いな奴ってどうにかしておるで。
まあC++をマンセーしているようだけども
実際にはC++のCの字すら使いこなせない低脳さんなんでしょうな。
655:仕様書無しさん
06/05/18 16:10:02
この板、人が少ないから連投するとすぐわかるよな
656:仕様書無しさん
06/05/18 16:24:07
それにしても、彼はなぜJavaが嫌いなんでしょう？
657:仕様書無しさん
06/05/18 16:33:32
いかさま連投でっち上げ乙。
ジャバジャバあふれる低脳乙。
いいかおまいら。
コンピュータシステムはうざい。まんどいものなんだよ。
そのまんどくさい程度をさらにぐぐっ！と跳ね上げるじゃば。
うざいうざいうざいうざすぎる。
658:仕様書無しさん
06/05/18 16:36:28
はいはいわろすわろす
いかさま連投でっち上げ乙。
C言語C言語あふれる低脳乙。
いいかおまいら。
コンピュータシステムはうざい。まんどいものなんだよ。
そのまんどくさい程度をさらにぐぐっ！と跳ね上げるじゃば。
うざいうざいうざいうざすぎる。
659:仕様書無しさん
06/05/18 18:00:21
おい、1箇所修正漏れてないか？
660:仕様書無しさん
06/05/18 18:15:05
お得意のリファクタリングにまかせるんでしょ
661:仕様書無しさん
06/05/18 20:39:29
くだらん
662:仕様書無しさん
06/05/18 21:12:33
発注先に、使ってるJVMの外部仕様書まで要求したら目を回していた。
「おたくはJVM部分の保守はしないってことか？」と怒鳴ったら泣き出した。
今は反省している。
663:仕様書無しさん
06/05/18 21:14:26
じゃばうざい
[ﾟдﾟ]
/[＿]ヽ
| | リファクタリングかんりょうしますた
664:仕様書無しさん
06/05/18 21:46:08
>>662
それはたんに>>662の頭が弱いだけではないかと。
君は必死になっていつもネタを考えているようだけど、
君が作り話をしてもまず受けないし。
自作自演で自画自賛するだけでしょw
665:仕様書無しさん
06/05/18 21:48:07
なぜ改行が多いのですか
JAVAのひとはそうなんですか
666:仕様書無しさん
06/05/18 21:49:15
C++の人はどうなんですか。
ソースファイルの末端に改行を入れないのですか
あーそーですか
667:仕様書無しさん
06/05/18 23:41:52
JAVA房さ、リファクタリンとか騒ぐなら
お前の人生リファクタリングしたほうがいいぞ
日本以外じゃJAVA＝上級スクリプト系言語
レベルの扱いだぞｗ
668:仕様書無しさん
06/05/18 23:50:19
Java房から教わった、あのとき2chで始めて知った「リファクタリング」という言葉に
毒づいて根に持っているのかC言語厨w
っていうかC++厨をJava厨にリファクタリングしたほうがいいぞ。
そうすればC++厨も職にあぶれる心配もなくなる。
アメリカじゃCだけしか知らないんでは仕事も無いぞw
669:仕様書無しさん
06/05/18 23:52:39
ここはジャパンデース
670:仕様書無しさん
06/05/18 23:53:01
何回も思うんだが、お前日本語おかしい。
２ちゃん用語（２典とかな）でも見ながら書いてる第三国人の方ですか？
671:仕様書無しさん
06/05/19 00:02:16
じゃ、お前は第四国人ですかね
672:仕様書無しさん
06/05/19 00:06:28
あたまのねじが・・・
おじゃば・・・
カワイソス
673:仕様書無しさん
06/05/19 00:25:58
そもそもC言語厨ってなんでそんなに頭が悪いの？
674:仕様書無しさん
06/05/19 00:27:11
C言語厨の頭のネジをはずし
カバーをはずし
Javaチップ埋め込み手術
C言語厨の歪んだ人格が補正された！
675:仕様書無しさん
06/05/19 00:27:25
ぐー
676:仕様書無しさん
06/05/19 00:28:08
うちの会社にC++使いがやってきた。
Javaは扱ったことが無いと言うので私は得意げにJavaを教えてやろうとしました。
しかし次の日、そいつは普通にJavaを使いこなしていました。
そいつ 「Java？こんなの使えるようになるのに1日も必要ないね」
如何にJava使いは上辺だけの知識しかないということが分かりました。
677:仕様書無しさん
06/05/19 00:30:44
いつも一人でJavaに粘着しているC言語厨は
一体どんな僻みを持っているのでしょうか
678:仕様書無しさん
06/05/19 00:31:22
>>676
ネタだよね。
JavaとC++とを置き換え他方がいいんでね？
679:仕様書無しさん
06/05/19 01:05:36
ライブラリ使わせてもらって組んでるだけのクセに偉そうですよね。みんな。
680:仕様書無しさん
06/05/19 01:21:39
じゃ、Javaのライブラリ使わせて貰っているJakarta は？
681:仕様書無しさん
06/05/19 01:25:26
っていうかC言語厨がJava厨に言いがかりつけるのは
アセンブラ厨がC言語厨に言いがかりつけるのと同じ事やね。
エレキのハード屋がアセンブラソフト屋に言いがかりをつけるのと同じ
ともいえるし。
メカ屋がエレキ屋に言いがかりをつけるのと同じともいえるね。
昔の人間ほど新しいものに対する変化が弱く、恐れ、
なんとかして保身に走ろうとする。
そう、C言語厨は「変化ヲ抱擁セヨ」がなっていない人たちなのだ。
もう老人なのだよ。彼らは。
「最近のわかいもんは冷房なんかつけて贅沢しおって！私が若い頃は
冷房なんかなかったんだぞ！」とよく後輩に逆ギレをするのがC言語厨なのである。
682:仕様書無しさん
06/05/19 06:41:58
ふと想った。
Javaの言語仕様そのままでexeを作れるようになれば、
Windowsプログラムに関して言えば、
C/C++のWin32API利用なんかよりも開発速度が上がる気がする。
データ容量などの多少の犠牲があるにしても、
それを補っても費用対効果が上昇するのでは無いかなぁ。
以上、便所の落書きでした。
683:仕様書無しさん
06/05/19 07:06:29
ずっとよんだけどさ。
やっぱしあたまわるいね。おじゃばくん。
とくに>>682
おまえ、最近のLinuxいじってないだろ。
GCJもしらないんだな。
ぷろぐらまのふりはもういいから
おなにーしてねなさい。
684:仕様書無しさん
06/05/19 07:37:06
なんつーか、Java厨って、世間で言うところのオタクに見えるんだよね。
オブジェクト指向とかこっちにとっては知識のかけらでしかないのに、
Java厨にとっては世界の全てと思っているように見えてしまって興ざめする。
オタクよろしくオブジェクト指向の話しかしないしさ。
685:仕様書無しさん
06/05/19 08:44:52
サービスを作成するにはRFC仕様をじっくりと検討し
OSのAPIで実現可能か調査しセキュリティ実装の検討をし
その他もろもろの仕様検討をしクラスに落として行く。
OSとかRFC仕様とか多種多様な要件をひとつにまとめあげるスキルが必要
なんだけど、Java厨さんの場合は単純にクラスだぜ！すげえだろう
って浅く薄い発言しかできないのが気にかかるかな。
686:仕様書無しさん
06/05/19 08:47:14
下請は余計なことを悩まなくていいよ。
687:仕様書無しさん
06/05/19 11:05:28
>>668
>C++厨をJava厨にリファクタリングしたほうがいいぞ。
お前も、自分が何言ってるのかくらい認識したほうがいい。
知らない単語も使わないほうがいいな。
>>678
>JavaとC++とを置き換え他方がいいんでね？
成立しない。
C++ を「使いこなす」には、あの泥臭い仕様を理解しなければならないわけで。
…いや、理解していなくても「こんなの使えるようになるのに1日も必要ないね」
と言い放つ阿呆は確かに存在するが。
688:仕様書無しさん
06/05/19 16:55:19
Javaに欲しいものを思い出した。
1. 値としてのObject (コピーコンストラクタや代入演算子そして値としてのObject渡し)
実際使うかどうかはわかんないけど、言語としてね・・・
2. const (言われてみりゃ欲しい)
3. コンストラクタからメソッドを呼び出したときに派生クラスのオーバーライドメソッドを呼び出さないで。
これはどう考えてもC++が正解 (少なくとも1.3のときはこんな動作だった)
689:仕様書無しさん
06/05/19 18:32:23
>>683
ATL/WTL 後CLI がそれだ
Javaを使うひつようはない
690:仕様書無しさん
06/05/19 23:10:05
>>682
それだったら既にあるんだが。
691:仕様書無しさん
06/05/19 23:11:19
>>684
そうか？ C言語厨のほうがオタクに
見えるんだけどね。
金にもならない癖にC/C++マンセーするなんて
生産性の無い馬鹿のやることじゃん。
しかもオタクよろしくガンダムの話しかしないしさ。
692:仕様書無しさん
06/05/19 23:14:28
>>688
> Javaに欲しいものを思い出した。
> 1. 値としてのObject (コピーコンストラクタや代入演算子そして値としてのObject渡し)
> 実際使うかどうかはわかんないけど、言語としてね・・・
CloneableインタフェースとObject#clone()で代用すればいいことをなぜそんなに欲しがる。
> 2. const (言われてみりゃ欲しい)
static finalがあるからそういう無駄なものは不要。
> 3. コンストラクタからメソッドを呼び出したときに派生クラスのオーバーライドメソッドを呼び出さないで。
> これはどう考えてもC++が正解 (少なくとも1.3のときはこんな動作だった)
なぜそういう仕組みにしないといけないのか？、また、そうなった場合の対応方法について
知りたければ「Effective Java」、「Javaの鉄則」を読め。
693:仕様書無しさん
06/05/19 23:15:04
>>685
アセンブラ厨がC言語厨に零した愚痴にそっくりだな
694:仕様書無しさん
06/05/19 23:21:11
アセンブリ言語→アセンブル→実行形式バイナリ
C言語→コンパイル→実行形式バイナリ
Java言語→コンパイル→バイトコード
695:仕様書無しさん
06/05/19 23:24:06
しかしあれだな。Javaバカ、オブジェクト指向原理主義バカもすっかり減ったよね。
696:>>688じゃないけど
06/05/19 23:24:28
>>692
> 1
clone()は使いにくい。
> 2は同意
> 3
保守とかやってると、そういう仕組みの方が都合が良い事がある。
697:仕様書無しさん
06/05/19 23:35:49
たかがOOが銀の弾丸ならこの業界も苦労しない罠。
698:仕様書無しさん
06/05/19 23:54:13
OOすれば再利用性が高まる…そんな風に考えていた時期が、俺にもありました。
699:仕様書無しさん
06/05/19 23:55:30
そうそう。狼男のつもりでいたらヴァンパイアだったりするからな
700:仕様書無しさん
06/05/19 23:57:43
ビジネスロジックを書くのに最強の再利用手段は
コピペだ。
いやマジで。
701:仕様書無しさん
06/05/19 23:59:03
cloneがObjectのメソッドでマーキングインターフェイスで
サポートしていないクラスの場合は例外をスローするという
嫌がれせとしか思えない糞仕様を設計したやつはだれですか。
702:仕様書無しさん
06/05/20 00:16:09
「C」にしろ「Java」にしろ、仕事によって使い分けてりゃいいんでない？
言語もツールだろ？
画像処理の高速化に、アセンブラを使うようなものでないのかい？
703:仕様書無しさん
06/05/20 00:18:46
1. については、「値」のほうが便利な場合があるから。例えば再帰呼び出し。
すべてのObjectがImmutableだったらclone()一本やりでも筋は通るけどね。
代わりにせめてassign()、equals() の標準インターフェイス
2. C++でメソッドや引数につける const の事を指している。(説明不足だったな)
3. 対応(あるいはノウハウ)の必要性は少ないほうがよくないか？
704:仕様書無しさん
06/05/20 00:42:27
あっequals()はObjectで定義だったな。(ハズイ
705:仕様書無しさん
06/05/20 00:43:21
ジャバカ
706:仕様書無しさん
06/05/20 00:46:52
>>696
お前はそこいらで適当にJavaの愚痴を有ること無いこと
書いてる馬鹿と違ってまともそうな発言をしているのでレスしよう。
> >>692
> > 1
> clone()は使いにくい。
どう使いにくい？ clone()と長く書くことが苦痛か？
clone()のオーバーライドが面倒か？
それと、不変クラスを定義した場合、clone()のオーバーライドは不要。
clone()の定義が面倒か？
> > 2は同意
> > 3
> 保守とかやってると、そういう仕組みの方が都合が良い事がある。
それはお前のスキルに問題があるといいたいが、
IDEで補う事が可能。
707:仕様書無しさん
06/05/20 00:47:30
>>701
C#にも似たようなものが(ry
708:仕様書無しさん
06/05/20 00:53:37
今度のjavaのオプションにハイフンdqnが付くみたいだね
709:仕様書無しさん
06/05/20 00:57:37
>>706
コピーしたいだけなのにいちいちオーバーライドするのは面倒。
まぁ、慣れの問題だとは思うが。
710:仕様書無しさん
06/05/20 00:57:48
>>703
> 1. については、「値」のほうが便利な場合があるから。例えば再帰呼び出し。
> すべてのObjectがImmutableだったらclone()一本やりでも筋は通るけどね。
> 代わりにせめてassign()、equals() の標準インターフェイス
IDE使え。
> 2. C++でメソッドや引数につける const の事を指している。(説明不足だったな)
前者ではフィールドをfinalにしろ。
後者では引数にfinal指定をすればいいだけの話だ。
> 3. 対応(あるいはノウハウ)の必要性は少ないほうがよくないか？
既に少ない。C++と比べたら楽な門だ。
711:仕様書無しさん
06/05/20 00:58:33
cloneは何のためにある？
共通のインターフェイスとしてクローンという機能を提供するためのはずだ。
そうじゃないなら、勝手にcloneメソッドを各クラスが提供すればいいだけの話。
なら共通のセマンティックをサポートするために、不変クラスでもcloneは必要のはずだ。
で、なんでcloneがObjectのメソッドになってるのか理解できないんだよね。
上記目的をサポートするためだけなら、Cloneableにcloneメソッドがあればいい。
何もわざわざObjectレベルで付けて、しかもサポートしないときには例外なんて
おかしなことをする必要は無いはず。
まあそれ以前にclone自体が単純にいまいち使いにくいけどね。
※別にJavaに限った話ではなくてC#とかでも同じだが。
712:仕様書無しさん
06/05/20 01:00:11
>>709
クラスの定義に応じて深いクローニングや浅いクローニングを
指定する必要があるのにそれはないだろう。
それは急ぎたいのに信号無視したいといってるのと同じだぞ。
713:仕様書無しさん
06/05/20 01:01:20
>>711
> cloneは何のためにある？
> 共通のインターフェイスとしてクローンという機能を提供するためのはずだ。
> そうじゃないなら、勝手にcloneメソッドを各クラスが提供すればいいだけの話。
> なら共通のセマンティックをサポートするために、不変クラスでもcloneは必要のはずだ。
> で、なんでcloneがObjectのメソッドになってるのか理解できないんだよね。
それについてもEffectiveJava に書いてある。
> 上記目的をサポートするためだけなら、Cloneableにcloneメソッドがあればいい。
そうすると新たな問題が生まれる。
714:仕様書無しさん
06/05/20 01:02:05
>>703
> 1. については、「値」のほうが便利な場合があるから。例えば再帰呼び出し。
> すべてのObjectがImmutableだったらclone()一本やりでも筋は通るけどね。
> 代わりにせめてassign()、equals() の標準インターフェイス
assign()が何をアサインするメソッドなのか？
715:仕様書無しさん
06/05/20 01:02:28
>>702
今Cの仕事が減っているからねえ。
どうなんだか
716:仕様書無しさん
06/05/20 01:04:18
>>701
> cloneがObjectのメソッドでマーキングインターフェイスで
> サポートしていないクラスの場合は例外をスローするという
> 嫌がれせとしか思えない糞仕様を設計したやつはだれですか。
お前はクローニングについてかなり勉強不足。
そこでJavaを批判する前にまずJavaを基礎から勉強し直して出直してこい。
717:仕様書無しさん
06/05/20 01:04:45
>>700
マジレスするにしても痛い。
勉強不足。
718:仕様書無しさん
06/05/20 01:05:14
>>695
速度原理主義なC言語厨もどうにかしてると思うが
719:仕様書無しさん
06/05/20 01:07:42
>>717
学生乙
720:仕様書無しさん
06/05/20 01:09:36
>>712
> それは急ぎたいのに信号無視したいといってるのと同じだぞ。
意味が分かりません。
721:仕様書無しさん
06/05/20 01:11:37
ナイス突込
722:仕様書無しさん
06/05/20 01:15:32
>>716
それは同一クラスのインスタンスを作るという目的のこと？
それとも別の理由？
Object.cloneに当たる機能は別（出なくてもいいかも知れんけど）もってて
Cloneableにcloneがあるのではなぜいけない？
723:仕様書無しさん
06/05/20 01:18:54
このスレのC言語厨は論理的思考能力が無いアホばかりだろ。
発言一つ一つに根拠無いものばかりでな。
ようするに連中は頭がおかしいだけなんだよ
724:仕様書無しさん
06/05/20 01:19:59
>>722
それがCloneNotSupportedExceptionとどう関係有るんだ
725:仕様書無しさん
06/05/20 01:20:03
>>715
Javaのスレだったな。
じゃあ『C#』あたりで…ノシ
726:仕様書無しさん
06/05/20 01:25:00
>>723
オ マ エ モ ナ ー
とでも言って欲しいのか？
727:仕様書無しさん
06/05/20 01:25:53
C#の仕事も少ないんだなー
728:仕様書無しさん
06/05/20 01:38:07
ちょっと質問。
よくcloneメソッドをpublicなメソッドに
オーバーライドして云々て記述を見るんだけど、
これってオーバーライドしてるんじゃなくて、
正確にはオーバーロードに当たる？
729:仕様書無しさん
06/05/20 01:39:59
>>727
そ。
じゃあ『Java』で…って、そういう事いいたかったんじゃないぽw
730:仕様書無しさん
06/05/20 03:21:15
>>710
final は参照変数の不変を指示するだけで参照されてるObjectの不変の指示じゃないよ。意味が違う。
まぁ実のところネタとして理想論みたいなのをいってるだけで実用上特に問題とは思ってないよ。
だからIDE云々というのもちょっと俺にとっては的はずれ。文法レベルでという話ね。
>>714
同一クラスおよびその派生クラスの代入という意味ね。元ネタは>>688
>>728
ちょwwwおまっwww オーバーライドで正解。
オーバーロードは引数が違う場合じゃあるまいか。
731:仕様書無しさん
06/05/20 03:28:39
あっ一個忘れた
>>712
浅いコピーデフォルトでいいじゃん。
比較対照としては適切じゃないけどC++ のデフォルトの operator= はいい仕事するよ。
732:仕様書無しさん
06/05/20 03:51:43
悪い。思い残しがないように(?)もう一個だけ。
>>710
>> 2. C++でメソッドや引数につける const の事を指している。(説明不足だったな)
>前者ではフィールドをfinalにしろ。
いまいち意味がわからない。メソッド単位にObjectを変更するかしないかを指定したいのだが。
全メソッドがconstなら結果としてImmutable Objectとなるおまけも付いてくるよ。
733:仕様書無しさん
06/05/20 08:53:54
ストールマン氏は、「Java Trap」（Javaの罠）と題された論文の中で、こういったオープン
ソースプロジェクトでJavaを使うことに対する批判を展開している。
「SunのJavaプラットフォーム上でJavaプログラムを開発すれば、無意識にSun独自の
機能を利用しがちである。気づいたときには、もう何カ月もその機能を使っていて、プログ
ラムを書き直すのに、さらに多くの月日がかかるという可能性もある。『最初からやり直す
のは大変だ』ということになるわけだ。あなたのプログラムは“Javaの罠”に落ちたのである。
そのプログラムはフリーソフトウェアの世界では使えないのだ」とストールマン氏は記している。
ストール万はこんなことを言ってるようだけど、C/C++信者はストール万の批判を鵜呑みにして
Javaを批判しているんだね。
2chで批判するときは事実を歪曲して批判しているようだけど。
734:仕様書無しさん
06/05/20 08:54:37
>>728
clone()というメソッドを作ったならばオーバーライド
735:仕様書無しさん
06/05/20 09:01:48
>>730
> >>710
> final は参照変数の不変を指示するだけで参照されてるObjectの不変の指示じゃないよ。意味が違う。
> まぁ実のところネタとして理想論みたいなのをいってるだけで実用上特に問題とは思ってないよ。
そのときはCollectionsクラスのユーティリティメソッドとGenericsを組み合わせればいいのではないかと。
> だからIDE云々というのもちょっと俺にとっては的はずれ。文法レベルでという話ね。
面倒くさいならIDEのコードアシストを使えばいいってことを言いたいんでは？
736:仕様書無しさん
06/05/20 09:01:50
>>732
> 悪い。思い残しがないように(?)もう一個だけ。
> >>710
> >> 2. C++でメソッドや引数につける const の事を指している。(説明不足だったな)
> >前者ではフィールドをfinalにしろ。
> いまいち意味がわからない。メソッド単位にObjectを変更するかしないかを指定したいのだが。
フィールドをfinalにすると一度コンストラクタでfinalフィールドに代入された値は
二度と変更できず不変になるってことでは。そうすればObjectを変更できなくすることができる。
当然クラスもfinalにしてsetterメソッドも廃止しないといけないけど。
メソッド単位でオブジェクトを可変にできるようにしたければ別途Mutableになるクラスを作った方が
いいんじゃないかと思う。ImmutableなStringクラスに対してMutableなStringBuffer, StringBuilderクラスを
用意するように。
737:仕様書無しさん
06/05/20 13:27:45
C言語厨を叩くJava厨 → Java使える C使えない
Java厨を叩くC言語厨 → Java使える C使える
つまりC言語厨は両方使った上でCのが良いって判断。
それに、Java厨はCが使えないくせにCを叩くからバカにされる。
738:仕様書無しさん
06/05/20 13:31:51
てことは、cloneメソッドは例外をスローする？
cloneをオーバーライドしてるって例をみるとthrowsないんだけど、
javaってオーバーライドする場合は書かなくてもいいんだっけ？
いや、なんか俺勘違いしてる気がしてきた。
もうjava忘れちゃってるな…
739:仕様書無しさん
06/05/20 13:34:03
あ、制約をゆるめる方向だからいいのか…
740:仕様書無しさん
06/05/20 13:58:04
プログラム言語は経済的に人類の役にたつかどうかだから・・・。
だとすると、Java、C、C++いずれが有用かは、すべて採用シェアでわかる。
難しく考える必要はない。
プログラマーの都合で判断しないこと。
741:仕様書無しさん
06/05/20 14:03:18
じゃ、MS寡占の世界ではC/C++ってことで終了だな
742:仕様書無しさん
06/05/20 14:17:38
>>MS寡占の世界ではC/C++ってことで終了だな
そう思うならC/C++つっぱしれば。C#もいいんじゃないｗ
743:仕様書無しさん
06/05/20 14:43:46
>>735 >>736
引数になるのはCollectionのクラスのみを仮定しているわけじゃないよ。
全てのクラスにImmutable, Mmutable の2つを作れというのは現実的じゃない気がする。
(コンパイル時にチェックできるという意味で)文法レベルで静的にチェックできるほうがよくない?
Collections.unmodifiableXXX は動的チェックだし、Immutable, Mmutable という構成の場合は
後の派生クラスの生成まで考えると Mmutable <- Immnutable って作るだろうからdowncastで突破(?)される
それよりconst欲しくない? ということ。あくまでもネタだけどね。
Generics まで導入した現在、simple is best という訳でもなかろう。
>>737
こんな事書いてる俺はJavaのほうが使用頻度高かったりする訳だ。
744:仕様書無しさん
06/05/20 18:22:48
C++をマスターする。
これは云わばあらゆる言語をマスターする事と同じである。
C/C++とJavaの経験者だったら何でもかんでもJavaが最強とほざく奴なんて皆無。
やったけどJava最強とか抜かす奴は使いこなせてないだけ。ただJavaに流れただけのウンコ。
要するにJava厨はほぼJavaしか扱った事の無く、俺がJava使ってんだからJava最強と脳内保管
しているウンコ。
ウンコしてくるわ。
745:仕様書無しさん
06/05/20 18:49:17
>>744
まれにその逆も混じってるぞ。
746:仕様書無しさん
06/05/20 18:59:11
Javaしか選択肢がない未来になってもそれはそれでいいんだがな。
そうするとLinuxディストリよろしく独自JVMで儲けるビジネスとか出てきそう。
そうなるとJVMプログラマとJavaプログラマに二分化が進む。
そうするとどちらに入りたいかで学ぶ言語は決まってくる。
プログラマ的にはどちらにつくのがおいしいかね？
Java側についてホラ吹きエヴァンジェリスト目指す方が金になる気もするが。
C++側について高機能独自JVMを世に出すという行為も悪くはない気がする。
747:仕様書無しさん
06/05/20 19:05:13
> ホラ吹きエヴァンジェリスト目指す
既にプログラマではない気がする。
748:仕様書無しさん
06/05/20 19:49:22
人を騙す商売が一番儲かるんだよなあ。
JavaJava詐欺でウハウハな奴って多いもんな。
749:仕様書無しさん
06/05/20 19:56:00
C++厨は信じたくないかもしれないが、C++使いからJavaに流れる奴多いよ。
Javaのほうが圧倒的に楽だから、戻れないんだそうな。
Eclipseが大きい。
750:仕様書無しさん
06/05/20 20:22:17
別にC++厨だが、Javaの方が楽だと思ってるよ。
751:仕様書無しさん
06/05/20 20:25:27
そりゃＪａｖａの方が何年も後発なんだし近代のプラットホームに合致しているのは当たり前で、
優れている部分も多々ある。
俺も>>743みたくJavaを採用する局面の方が多かったりもするが、
C/C++を使えもしないJava厨がなんの根拠もなくC/C++を叩くのは変だろ。
要はJavaがバカにされてるんじゃなくてJavaを信仰するヘタレがバカにされてるのさ。
752:仕様書無しさん
06/05/20 20:51:43
はあ？
753:仕様書無しさん
06/05/20 20:57:59
はあ、その通りでございます
754:仕様書無しさん
06/05/20 21:17:02
C++の方がなんでもありのワイルドカードみたいで好き。
でも楽がしたいときはJava使う。
755:仕様書無しさん
06/05/20 21:53:25
このスレは>>737みたいな根拠無き発言とJava屋に対する私怨に
まみれたスレですね
756:仕様書無しさん
06/05/20 21:55:19
>>738
まずはプログラミングしてみろ。
やってみればどうなるか、どうすればいいかわかる。
今のお前はthrowもthrowsもわかってないだろ。
>>737の意に反して、C言語厨はこのようにJavaも
わからずにJavaを叩いている。
>>737がどれだけ出鱈目で信憑性の無い発言をしているかがよくわかるだろう。
757:仕様書無しさん
06/05/20 21:58:54
>>741
> じゃ、MS寡占の世界ではC/C++ってことで終了だな
現実をよーくみろ。現場で活躍している人間がそんな発言を
するとは実に恥ずかしいぞ。
M$がデスクトップ市場を寡占してもサーバサイドアプリケーションの開発が
圧倒的でサーバに使われるOSやWebサーバも非M$のものだ。
そしてアプリはJava製やPHP製のものばかりで、明らかにC/C++製の
アプリは少ない。そして仕事も見事に少ない。
そして今、リッチクライアント技術が対当している。JavaWebStartやClickOnce, Flash, Ajax
がC/C++スタンドアロンアプリの代わりを担っている。
もう、お前が想像しているようなスタンドアロンアプリの時代は終わったのだよ。
758:仕様書無しさん
06/05/20 22:01:08
>>744
> C++をマスターする。
> これは云わばあらゆる言語をマスターする事と同じである。
そんなことをビックマウスみたいに言ってる奴に限ってJavaの開発に関わってもデスマって
LISPもPerlもPHPも使いこなせないんだよな。
759:仕様書無しさん
06/05/20 22:02:00
>>748
貧乏C言語厨君、Javaアーキテクトの金持ちを嫉んで共産党なんかに入らないようになw
760:仕様書無しさん
06/05/20 22:02:26
>>749
そうそう、EclipseスレでもCDTやってる香具師が多かったからな
761:仕様書無しさん
06/05/20 22:06:43
>>743
> >>735 >>736
> 引数になるのはCollectionのクラスのみを仮定しているわけじゃないよ。
> 全てのクラスにImmutable, Mmutable の2つを作れというのは現実的じゃない気がする。
速度面やリソース面の問題を気にするなら現実的になりうるときもある。
可変クラスを不変クラスがラップするなど。
> (コンパイル時にチェックできるという意味で)文法レベルで静的にチェックできるほうがよくない?
> Collections.unmodifiableXXX は動的チェックだし、Immutable, Mmutable という構成の場合は
> 後の派生クラスの生成まで考えると Mmutable <- Immnutable って作るだろうからdowncastで突破(?)される
それはMmutableクラスがImmnutableを継承しているという図か？
そもそも不変クラスというものはfinal宣言をして継承を禁止するはずだが。
継承せず、可変クラスが不変クラスに委譲(ラップされる)のがいいのではないかと。
> それよりconst欲しくない? ということ。あくまでもネタだけどね。
いらない。
762:仕様書無しさん
06/05/20 22:54:07
>>756
いや、思い出したからもういい。
763:仕様書無しさん
06/05/20 23:13:57
粘着気味で悪いが
>>761
> 継承せず、可変クラスが不変クラスに委譲(ラップされる)のがいいのではないかと。
了解。
> いらない。
代替手段があることはよくわかったが、できればいらないと言い切る理由が知りたいな。
Collections.unmodifiableXXXは前述したように動的チェックだし、委譲クラス作成も面倒、
両者ともconstがあったと仮定した場合に比べれば可読性に劣ると思うが。
調べてみたらconstは一応予約語だし、バイトコードのメソッド定義にも余裕があるしで、
実装するのに問題はなさそうなんだけどな。
764:仕様書無しさん
06/05/20 23:36:21
ポインタが理解できなくてC/C++で挫折しちゃったから
信仰するのがJavaかVBしかないんだろうなｗ
765:仕様書無しさん
06/05/20 23:43:38
764はポインタが難しいと思ってるC厨。C++の知識はなし。
766:仕様書無しさん
06/05/20 23:46:19
765はポインタが理解できないVB厨。C/C++の知識はなし。
767:仕様書無しさん
06/05/20 23:53:23
残念ながら、テンプレート最強！boost最高！なんて言ってた奴が
eclipse使ったら一発でJava厨になっちゃうわけよ。
768:仕様書無しさん
06/05/20 23:58:56
絶対ならない。
STL,BOOST使いこなせねーから流れたんだろ。
使いこなせる奴にJava厨はいない。
769:仕様書無しさん
06/05/21 00:34:15
>>768
C++厨は信じられないと思うが、767が現実なんだよ。
入力した瞬間にエラーがわかり、自動でコードを生成する
eclipseの魅力に取り付かれると抜け出せない。
770:仕様書無しさん
06/05/21 00:35:44
>>757
リッチクライアントなら.NETのスマートクライアントを忘れてるぞ。
見た感じ@ITとかでで踊ってるトピックしか知らないようだな。
771:仕様書無しさん
06/05/21 00:40:54
>>770
@にはスマクラについても書いてるしたぶん、>757はしったか
糞コンサルなんじゃねぇの？
772:仕様書無しさん
06/05/21 00:42:54
つClickOnce
773:仕様書無しさん
06/05/21 01:02:09
むしろSTL,BOOSTとか好む奴こそJavaに流れそうなもんだが。
774:仕様書無しさん
06/05/21 01:06:02
ああ、スマクラの次バージョンがClickOnceだったか。
775:仕様書無しさん
06/05/21 01:08:18
とはいえこれはこれで業務で使うには悩む。
776:仕様書無しさん
06/05/21 01:19:55
スマートクライアントは設定が環境依存してるのか面倒くさかったな。
仕様通りに動かないんだが、仕様上だと可能とかでコンサルしかしてないやつが怒る怒る。
777:仕様書無しさん
06/05/21 01:59:37
>>769
そんなに紳士に返答されたらこっちは困るだろ。
778:仕様書無しさん
06/05/21 03:00:04
eclipseからVC++に移った俺だがeclipseに戻りたいとは思わない
779:仕様書無しさん
06/05/21 08:35:46
ずっとVC++使ってた漏れはeclipseを評価したとたんに
「こりゃだめだ、使い物ならん」で終了した。
780:仕様書無しさん
06/05/21 08:38:25
>>767
>eclipse使ったら一発でJava厨になっちゃうわけよ
ようはスキルが低いやつがとっつくのに最良というだけじゃないの？
781:仕様書無しさん
06/05/21 09:29:31
>>779
多分、一時間以下とか、その程度しか使ってないからだな。それは。
>>780
スキルは関係ないだろうな。スキルが低いとどうなるかはわからんが、
少なくともスキルが高くても、クイックフィックスやgetter、setter、constructorの
自動生成、ファイル等の名前変更なんかは楽だと感じる。
782:仕様書無しさん
06/05/21 10:09:36
むしろスキルの低い奴は最悪のとっつきにくさを感じる。
VSとはその点で大きく劣る。
783:仕様書無しさん
06/05/21 10:35:55
そうなのか？eclipseで最初に感動するのは、間違っているところに赤いアンダーラインが
引いてあるところ。コンパイルしてから間違いがわかるのは普通だが、
コンパイルする前から、常時そうなってる。
これはいくらスキルが低くても、一目で気づくと思うがなぁ。
784:仕様書無しさん
06/05/21 10:53:19
>>783
職場で改修作業が多いからはじめっから注意、警告アンダーラインばっかりだから
そんなのちょこっと出てもまったく気にならない奴が量産されてるけどｗ
785:仕様書無しさん
06/05/21 10:54:36
>>767
> 残念ながら、テンプレート最強！boost最高！なんて言ってた奴が
> eclipse使ったら一発でJava厨になっちゃうわけよ。
うむ！ まったくそのとおりだ！
786:仕様書無しさん
06/05/21 10:55:12
>>768
> 絶対ならない。
> STL,BOOST使いこなせねーから流れたんだろ。
> 使いこなせる奴にJava厨はいない。
根拠は？ 具体的に。
STLもBOOSTも使えないようではJavaをやってもうまく使いこなせないぞw
787:仕様書無しさん
06/05/21 10:55:59
>>770-771
イタイドトネト厨だなw
788:仕様書無しさん
06/05/21 10:56:09
>>786
ＢＯＯＳＴなんて使ってないなぁ。
あれ、使えそうで痒いところに全くといっていいほど手が届かないし。
789:仕様書無しさん
06/05/21 10:56:14
>>784
それでも、数回コンパイルしてみりゃ気づくだろｗ
注意や警告なら修正しなくてもいいかもしれんが、エラーは否応なしに
修正しなくちゃならんからな。
790:仕様書無しさん
06/05/21 10:57:23
>>780
> >>767
> >eclipse使ったら一発でJava厨になっちゃうわけよ
> ようはスキルが低いやつがとっつくのに最良というだけじゃないの？
VC++のほうをマンセーしてるおまいらは
VB厨みたいな奴らだろ。スキルの低いVB厨はEclipseを使いこなせず
Visual Studioに飛びつく。
表向きはVC++やってるように見せかけておいてな。
791:仕様書無しさん
06/05/21 10:58:56
Java1.0からJava2.0
[Java1.0]Javaについての本が本棚に10冊以上ある
↓
[Java2.0]Javaについてのブログを10個以上読んでいる
[Java1.0]Java番組をワンセグ携帯で見たい
↓
[Java2.0]携帯から直接Javaできる端末が欲しい
[Java1.0]小泉政権は国民のJava格差を拡大させている
↓
[Java2.0]この国のJavaの８割を、エスタブリッシュメント層が独占している
[Java1.0]Javaと仕事のどちらをとるかと問われると困る
↓
[Java2.0]Javaと仕事のどちらをとるかと問われて即決できる
[Java1.0]あと５年以内にJavaは上位２社だけが独占する
↓
[Java2.0]Javaにかかるコストはほぼゼロになり、多くの人がJavaをベースに事業を展開する
[Java1.0]Javaについての俳句を伊藤園「お～いお茶」に応募した
↓
[Java2.0]wikipediaのJavaの項目に加筆した
[Java1.0]Javaのために人生をかける生き方もありだ
↓
[Java2.0]Javaだけの人生はリスクが大きすぎる
[Java1.0]会社でネット見てばかりの先輩がブログにJavaについて書いてて痛かった
↓
[Java2.0]会社の上司がJava2.0とか言ってて「意味わかってんのかな」と思う
[Java1.0]本のしおりとしてJavaを使ったことがある
↓
[Java2.0]Javaのタグ付けには一家言ある。他人のタグの付け方に時々腹が立つ
[Java1.0]２ちゃんねるでJava板をチェックする
↓
[Java2.0]RSSリーダーで「梅田望夫の世界を変えるJava」を購読する
792:仕様書無しさん
06/05/21 10:59:50
Eclipse1.0からEclipse2.0
[Eclipse1.0]Eclipseのために人生をかける生き方もありだ
↓
[Eclipse2.0]Eclipseだけの人生はリスクが大きすぎる
[Eclipse1.0]Eclipseはできれば一生涯続いて欲しい
↓
[Eclipse2.0]40歳ぐらいまでにEclipseを卒業したい
[Eclipse1.0]２ちゃんねるでEclipse板をチェックする
↓
[Eclipse2.0]RSSリーダーで「梅田望夫の世界を変えるEclipse」を購読する
[Eclipse1.0]Eclipse番組をワンセグ携帯で見たい
↓
[Eclipse2.0]携帯から直接Eclipseできる端末が欲しい
[Eclipse1.0]ときには、ビジョンを持たないEclipseをしてしまう
↓
[Eclipse2.0]自分のビジョンに合わないEclipseはあり得ない
[Eclipse1.0]会社でネット見てばかりの先輩がブログにEclipseについて書いてて痛かった
↓
[Eclipse2.0]会社の上司がEclipse2.0とか言ってて「意味わかってんのかな」と思う
[Eclipse1.0]本のしおりとしてEclipseを使ったことがある
↓
[Eclipse2.0]Eclipseのタグ付けには一家言ある。他人のタグの付け方に時々腹が立つ
[Eclipse1.0]Eclipseは自分をときどき後ろ向きにさせる
↓
[Eclipse2.0]常に前向きな思考を保つためにEclipseがある
[Eclipse1.0]Eclipseについての俳句を伊藤園「お～いお茶」に応募した
↓
[Eclipse2.0]wikipediaのEclipseの項目に加筆した
[Eclipse1.0]ビジネスとEclipseは完全に別物だ
↓
[Eclipse2.0]すべてのEclipseはビジネスにつながる
793:仕様書無しさん
06/05/21 11:00:11
Web1.0からWeb2.0
[Web1.0]Web番組をワンセグ携帯で見たい
↓
[Web2.0]携帯から直接Webできる端末が欲しい
[Web1.0]Webについての俳句を伊藤園「お～いお茶」に応募した
↓
[Web2.0]wikipediaのWebの項目に加筆した
[Web1.0]小泉政権は国民のWeb格差を拡大させている
↓
[Web2.0]この国のWebの８割を、エスタブリッシュメント層が独占している
[Web1.0]本のしおりとしてWebを使ったことがある
↓
[Web2.0]Webのタグ付けには一家言ある。他人のタグの付け方に時々腹が立つ
[Web1.0]会社の上司にWebをするのは野暮だ
↓
[Web2.0]会社の上司とWebの未来について熱く語ってしまう
[Web1.0]誰だかわからない大勢とWebを共有するなんて気持ち悪い
↓
[Web2.0]大多数が参加するWebこそ、自分のフィールドだ
[Web1.0]２ちゃんねるでWeb板をチェックする
↓
[Web2.0]RSSリーダーで「梅田望夫の世界を変えるWeb」を購読する
[Web1.0]Webについて語るとき、野球にたとえることが多い
↓
[Web2.0]Webについて語るとき、アメリカ大統領にたとえることが多い
[Web1.0]あと５年以内にWebは上位２社だけが独占する
↓
[Web2.0]Webにかかるコストはほぼゼロになり、多くの人がWebをベースに事業を展開する
[Web1.0]自分らしい、等身大のWebが好きだ
↓
[Web2.0]国際基準で上位のWebを狙っていきたい
794:仕様書無しさん
06/05/21 11:00:41
アーキテクト1.0からアーキテクト2.0
[アーキテクト1.0]２ちゃんねるでアーキテクト板をチェックする
↓
[アーキテクト2.0]RSSリーダーで「梅田望夫の世界を変えるアーキテクト」を購読する
[アーキテクト1.0]アーキテクトはできれば一生涯続いて欲しい
↓
[アーキテクト2.0]40歳ぐらいまでにアーキテクトを卒業したい
[アーキテクト1.0]アーキテクトについて語るとき、野球にたとえることが多い
↓
[アーキテクト2.0]アーキテクトについて語るとき、アメリカ大統領にたとえることが多い
[アーキテクト1.0]アーキテクト番組をワンセグ携帯で見たい
↓
[アーキテクト2.0]携帯から直接アーキテクトできる端末が欲しい
[アーキテクト1.0]アーキテクトと仕事のどちらをとるかと問われると困る
↓
[アーキテクト2.0]アーキテクトと仕事のどちらをとるかと問われて即決できる
[アーキテクト1.0]2004年、初めてネットだけで成立するアーキテクトが誕生する
↓
[アーキテクト2.0]2014年、すべてのアーキテクトはネットでのみ存在する
[アーキテクト1.0]アーキテクトについての本が本棚に10冊以上ある
↓
[アーキテクト2.0]アーキテクトについてのブログを10個以上読んでいる
[アーキテクト1.0]ビジネスとアーキテクトは完全に別物だ
↓
[アーキテクト2.0]すべてのアーキテクトはビジネスにつながる
[アーキテクト1.0]同時にできるアーキテクトは１つだけだ
↓
[アーキテクト2.0]同時に２つ以上こなしてこそアーキテクトだ
[アーキテクト1.0]アーキテクトのために人生をかける生き方もありだ
↓
[アーキテクト2.0]アーキテクトだけの人生はリスクが大きすぎる
795:仕様書無しさん
06/05/21 11:04:59
ﾂﾏﾝﾈ
796:仕様書無しさん
06/05/21 11:10:58
トラックバック:URLﾘﾝｸ(d.hatena.ne.jp)
やねうらおにトラックバック
797:仕様書無しさん
06/05/21 11:11:25
トラックバック:URLﾘﾝｸ(d.hatena.ne.jp)
やねうらおにアタック
798:仕様書無しさん
06/05/21 11:11:47
トラックバック成功！！！！！！！！！！！！！！！！！！！！
799:仕様書無しさん
06/05/21 11:19:45
何がSTLだよ。そっち方面じゃJavaのが圧倒的に充実してんじゃねーかｗ
800:仕様書無しさん
06/05/21 11:21:25
>>790
あごめん高価なエンタープライズ版使っている漏れは気づかなかったけど
貧乏だから飛びつくが最大の要素だと思うよ
801:仕様書無しさん
06/05/21 11:22:37
>>800 エンタープライズアーキテクト1.0からエンタープライズアーキテクト2.0
[エンタープライズアーキテクト1.0]エンタープライズアーキテクトと仕事のどちらをとるかと問われると困る
↓
[エンタープライズアーキテクト2.0]エンタープライズアーキテクトと仕事のどちらをとるかと問われて即決できる
[エンタープライズアーキテクト1.0]エンタープライズアーキテクトにインターネットの力を借りるのは邪道だ
↓
[エンタープライズアーキテクト2.0]インターネットはエンタープライズアーキテクトの可能性を大きく拡げると思う
[エンタープライズアーキテクト1.0]本のしおりとしてエンタープライズアーキテクトを使ったことがある
↓
[エンタープライズアーキテクト2.0]エンタープライズアーキテクトのタグ付けには一家言ある。他人のタグの付け方に時々腹が立つ
[エンタープライズアーキテクト1.0]小泉政権は国民のエンタープライズアーキテクト格差を拡大させている
↓
[エンタープライズアーキテクト2.0]この国のエンタープライズアーキテクトの８割を、エスタブリッシュメント層が独占している
[エンタープライズアーキテクト1.0]２ちゃんねるでエンタープライズアーキテクト板をチェックする
↓
[エンタープライズアーキテクト2.0]RSSリーダーで「梅田望夫の世界を変えるエンタープライズアーキテクト」を購読する
[エンタープライズアーキテクト1.0]会社の上司にエンタープライズアーキテクトをするのは野暮だ
↓
[エンタープライズアーキテクト2.0]会社の上司とエンタープライズアーキテクトの未来について熱く語ってしまう
[エンタープライズアーキテクト1.0]自分らしい、等身大のエンタープライズアーキテクトが好きだ
↓
[エンタープライズアーキテクト2.0]国際基準で上位のエンタープライズアーキテクトを狙っていきた
802:仕様書無しさん
06/05/21 11:22:40
い
[エンタープライズアーキテクト1.0]エンタープライズアーキテクトはできれば一生涯続いて欲しい
↓
[エンタープライズアーキテクト2.0]40歳ぐらいまでにエンタープライズアーキテクトを卒業したい
[エンタープライズアーキテクト1.0]エンタープライズアーキテクトは自分をときどき後ろ向きにさせる
↓
[エンタープライズアーキテクト2.0]常に前向きな思考を保つためにエンタープライズアーキテクトがある
[エンタープライズアーキテクト1.0]同時にできるエンタープライズアーキテクトは１つだけだ
↓
[エンタープライズアーキテクト2.0]同時に２つ以上こなしてこそエンタープライズアーキテクトだ
803:仕様書無しさん
06/05/21 11:24:20
Developer1.0からDeveloper2.0
[Developer1.0]ときには、ビジョンを持たないDeveloperをしてしまう
↓
[Developer2.0]自分のビジョンに合わないDeveloperはあり得ない
[Developer1.0]Developerはできれば一生涯続いて欲しい
↓
[Developer2.0]40歳ぐらいまでにDeveloperを卒業したい
[Developer1.0]ビジネスとDeveloperは完全に別物だ
↓
[Developer2.0]すべてのDeveloperはビジネスにつながる
[Developer1.0]自分らしい、等身大のDeveloperが好きだ
↓
[Developer2.0]国際基準で上位のDeveloperを狙っていきたい
[Developer1.0]２ちゃんねるでDeveloper板をチェックする
↓
[Developer2.0]RSSリーダーで「梅田望夫の世界を変えるDeveloper」を購読する
[Developer1.0]Developerと仕事のどちらをとるかと問われると困る
↓
[Developer2.0]Developerと仕事のどちらをとるかと問われて即決できる
[Developer1.0]会社でネット見てばかりの先輩がブログにDeveloperについて書いてて痛かった
↓
[Developer2.0]会社の上司がDeveloper2.0とか言ってて「意味わかってんのかな」と思う
[Developer1.0]Developer番組をワンセグ携帯で見たい
↓
[Developer2.0]携帯から直接Developerできる端末が欲しい
[Developer1.0]会社帰りにコンビニでDeveloperの新製品を見つけて買う。前とほとんど同じ味。がっかり。
↓
[Developer2.0]amazonを開くと、リコメンドにDeveloperがズラリ。思わずノートＰＣのディスプレーを閉じる
[Developer1.0]Developerについての俳句を伊藤園「お～いお茶」に応募した
↓
[Developer2.0]wikipediaのDeveloperの項目に加筆した
804:仕様書無しさん
06/05/21 11:24:55
C言語厨にはどれも此も痛い話だなw
805:仕様書無しさん
06/05/21 11:25:48
Dependency Injection1.0からDependency Injection2.0
[Dependency Injection1.0]Dependency Injectionについて語るとき、野球にたとえることが多い
↓
[Dependency Injection2.0]Dependency Injectionについて語るとき、アメリカ大統領にたとえることが多い
[Dependency Injection1.0]Dependency Injectionのために人生をかける生き方もありだ
↓
[Dependency Injection2.0]Dependency Injectionだけの人生はリスクが大きすぎる
[Dependency Injection1.0]ときには、ビジョンを持たないDependency Injectionをしてしまう
↓
[Dependency Injection2.0]自分のビジョンに合わないDependency Injectionはあり得ない
[Dependency Injection1.0]あと５年以内にDependency Injectionは上位２社だけが独占する
↓
[Dependency Injection2.0]Dependency Injectionにかかるコストはほぼゼロになり、多くの人がDependency Injectionをベースに事業を展開する
[Dependency Injection1.0]小泉政権は国民のDependency Injection格差を拡大させている
↓
[Dependency Injection2.0]この国のDependency Injectionの８割を、エスタブリッシュメント層が独占している
[Dependency Injection1.0]会社帰りにコンビニでDependency Injectionの新製品を見つけて買う。前とほとんど同じ味。がっかり。
↓
[Dependency Injection2.0]amazonを開くと、リコメンドにDependency Injectionがズラリ。思わずノートＰＣのディスプレーを閉じる
[Dependency Injection1.0]誰だかわからない大勢とDependency Injectionを共有するなんて気持ち悪い
↓
[Dependency Injection2.0]大多数が参加するDependency Injectionこそ、自分のフィールドだ
[
806:仕様書無しさん
06/05/21 11:25:53
Dependency Injection1.0]会社でネット見てばかりの先輩がブログにDependency Injectionについて書いてて痛かった
↓
[Dependency Injection2.0]会社の上司がDependency Injection2.0とか言ってて「意味わかってんのかな」と思う
[Dependency Injection1.0]Dependency Injectionについての俳句を伊藤園「お～いお茶」に応募した
↓
[Dependency Injection2.0]wikipediaのDependency Injectionの項目に加筆した
[Dependency Injection1.0]同時にできるDependency Injectionは１つだけだ
↓
[Dependency Injection2.0]同時に２つ以上こなしてこそDependency Injectionだ
807:仕様書無しさん
06/05/21 11:28:33
Javaの案件つーのはスケーラビリティだなんだつって開発環境以外のところに金がかかってしょうがねーんだよ。
何も知らねーなほんと。
808:仕様書無しさん
06/05/21 11:53:22
JavaだとC++よりもできることが増えるからそりゃそーだろ
809:仕様書無しさん
06/05/21 12:19:23
できることは増えてねーし。むしろC/C++と比べて出来ないことだらけ。
言語の高級化つーのは、敢えて言えば出来ないことを増やすことと引き換えに生産性を高めることをいう。
そこがわかってねー馬鹿が多すぎる。
従ってJavaの是非は、果たして生産性が高めることに成功したのかという一点について論じられるべき。
810:仕様書無しさん
06/05/21 12:30:21
>>808
に具体例を提示していただきたいｗｗｗｗｗｗ
811:仕様書無しさん
06/05/21 12:37:30
ORマッピングもDIも「事実上」できねーだろ。お前もだまれや。
812:仕様書無しさん
06/05/21 12:42:07
Java VM も C で実装されている以上、Java VM と同じ働きをする
ライブラリを C/C++ で実装すれば理論上は可能じゃね？
813:仕様書無しさん
06/05/21 12:58:27
>>811は真性バカ。
814:仕様書無しさん
06/05/21 13:13:15
>>809
> できることは増えてねーし。むしろC/C++と比べて出来ないことだらけ。
いや、C++の時と比べて無駄な短調作業が経る分だけ余裕ができるので
Javaでできることの可能性が拡大して、プログラマは開発以外のところに余裕を持てるようになり、
設計まで担当できるから開発以外のところに金がかかるような錯覚に陥るんだろうよ。
815:仕様書無しさん
06/05/21 13:15:27
>>812
> Java VM も C で実装されている以上、Java VM と同じ働きをする
> ライブラリを C/C++ で実装すれば理論上は可能じゃね？
そんなライブラリがあったとしても開発コストは嵩むよ。
今Javaで頻繁に行われているホットな仕事をC++で真似をしたら・・・・
とんでもないコストがかさむ。
Seasar2の真似事をするにしてもSpringの真似事をするにしてもJSFやStruts
の真似事をするにしても多大な苦労とコストとデスマーチ地獄が待っている。
賢い人間ならJavaでできることすべてをC++だけでやるだなんて言わない。
816:仕様書無しさん
06/05/21 13:49:25
>>813
DIとかORMとかやるくれえだったら素直にJavaとかC#つかうんだよ馬鹿。
だから事実上つってんだろうが。
817:仕様書無しさん
06/05/21 14:05:46
>C++の時と比べて無駄な短調作業が経る
この作業時間の見積は
C++が全くできないJava厨さんの見積です。
優秀なるC++guyはとてつもなく仕事が速い人が多いです。
818:仕様書無しさん
06/05/21 14:09:06
無駄な単調作業は優秀で仕事が速くてもやっぱりあるんだよ。
むしろ優秀であればあるほどこの割合が高くなる。
819:仕様書無しさん
06/05/21 14:12:08
なんでJava厨とC++マスターを比べてんのよ。
むしろどう考えてもJavaマスターとC厨の方が生産性の差は歴然だろ。
820:仕様書無しさん
06/05/21 14:14:07
単純作業発生率
カーネル、サービス 3%
・
・
・
ビジネスロジック 100%
821:仕様書無しさん
06/05/21 14:14:14
>>816
> だから事実上つってんだろうが。
だから、真性バカだって言われてんだよ。
822:仕様書無しさん
06/05/21 14:15:02
CPU時間の占有率みたいな比率になった。
823:仕様書無しさん
06/05/21 14:17:12
簡単に間違いなく作れるJavaって
工場で流れるラインの一部みたいだな。
フレームワークの隙間のビジネスロジックって
ラインのねじ止め単純作業みたいだもんな。
824:仕様書無しさん
06/05/21 14:20:49
>>821
ならお前Cの案件で一人でDI使って炉や。
825:仕様書無しさん
06/05/21 14:23:09
同じ仕事では、優秀であればあるほど、単位時間内にコードを
打ち込む量が多くなるんだよ。
ずっと悩んで手が進まない奴が仕事が速いわけないだろう。
826:仕様書無しさん
06/05/21 14:27:14
>>823
同じことやるなら簡単に出来たほうがいいだろ。
というより、Javaのどこが簡単に間違いなく作れるんだよ。
被害妄想もいい加減にしとけや。
827:仕様書無しさん
06/05/21 14:28:29
できることが増えてるんじゃなくて、他人がやってくれることが増えているだけだな。
828:仕様書無しさん
06/05/21 14:31:23
他人が作ってくれた仕様のフレームを
使って意気揚々としているJavaちゅんたん。
829:仕様書無しさん
06/05/21 14:34:26
おめえはOSから自作しとけや。
830:仕様書無しさん
06/05/21 14:36:09
>>817
> C++の時と比べて無駄な短調作業が経る
> この作業時間の見積は
> C++が全くできないJava厨さんの見積です。
> 優秀なるC++guyはとてつもなく仕事が速い人が多いです。
ならその証拠を見せて。
ついでに言い出しっぺのお前の能力がどれだけのものか
見てみたいものだw
831:仕様書無しさん
06/05/21 14:37:02
VMから自作できないからってそんなにファビよるなよ
832:仕様書無しさん
06/05/21 14:38:50
>>823
> 簡単に間違いなく作れるJavaって
> 工場で流れるラインの一部みたいだな。
設計をする人間はそんなくだらないことをやる必要がないので
Javaをそういう喩えにするのはかなりネタだな。
C++だと工場で流れるラインの一部の仕事が実に多い。
> ラインのねじ止め単純作業みたいだもんな。
それがC++だな。Javaではそういう単純作業は
大幅に自動化されており、人間がやる必要がない。
C++だとくだらないネジ止め単純作業ですら人間が
やらないといけないため非効率。
833:仕様書無しさん
06/05/21 14:39:44
>>828
アセンブラ厨が作った言語の上で意気揚々よしている
C厨たんw
834:仕様書無しさん
06/05/21 14:39:53
>>823
Javaを使っても間違いは多いよ。
簡単にもならん。
835:仕様書無しさん
06/05/21 14:39:56
>>831
おめえは煽りかたがおかしいんだよ。
JavaもC#も触ったことがないのがもろバレで、C++使いの品位すら貶める。
836:仕様書無しさん
06/05/21 14:39:59
>>831
じゃ、お前がVM作ってみて
837:仕様書無しさん
06/05/21 14:40:22
C言語厨はさすがにビッグマウス。
VM自作できると言い張って実は何も作れない。