Javaは遅いという奴は遅れたバブル世代じゃね？
さ、語れ。Javaよりも遅い脳みそを持つ人々について
Javaよりも重たい(思考回路が遅い)バブル世代が立てたスレ
Javaって重くね？ その２
http://pc8.2ch.net/test/read.cgi/prog/1136359572/
関連スレ
先があるのはC++とJavaのどっち？
http://pc8.2ch.net/test/read.cgi/prog/1132157362/
Javaよりも重たい(思考回路が遅い)バブル世代が立てたスレ
Javaって重くね？ その２
http://pc8.2ch.net/test/read.cgi/prog/1136359572/
関連スレ
先があるのはC++とJavaのどっち？
http://pc8.2ch.net/test/read.cgi/prog/1132157362/
|
|
|
バブル世代はなぜか頭が硬い。
バブル世代はバブル時代に遊んでばかりいたことを必死に隠そうとしているアフォが多いw
10年前で思考停止している
バブル世代はバブル時代に遊んでばかりいたことを必死に隠そうとしているアフォが多いw
10年前で思考停止している
3 ：仕様書無しさん：2006/01/05(木) 13:13:30
Javaよりも重たい?
それは全宇宙でJavaが一番重たいと思うよ
チャンチャン
それは全宇宙でJavaが一番重たいと思うよ
チャンチャン
それはJavaとは言わないよ
チャンチャン
チャンチャン
5 ：仕様書無しさん：2006/01/05(木) 13:43:32
ネイティブコードより遅くなるのは当たり前だろ
当たり前ではないよ。条件によって違う。
最終的にネイティブで実行されるのに、どうやったらそれより速くなるんだよ。
Java厨がC++より速いとする根拠は提灯記事だろ。
むしろ現実を直視していないのはJava厨の方じゃないのかなあ。
むしろ現実を直視していないのはJava厨の方じゃないのかなあ。
>>7
そんな風に考えていた（ｒｙ
もう繰り返し説明したくないが、実行時最適化。
ただ、Java 使いには程度の低い奴が多いのと
(連中に、ハヤリモノに群がる習性がある所為で
Java の所為ではないが)
実行時コンパイラ自体がうすらでかくてスワップ
し放題な為に、目に見えて早くなる事が非常に稀。
そんな風に考えていた（ｒｙ
もう繰り返し説明したくないが、実行時最適化。
ただ、Java 使いには程度の低い奴が多いのと
(連中に、ハヤリモノに群がる習性がある所為で
Java の所為ではないが)
実行時コンパイラ自体がうすらでかくてスワップ
し放題な為に、目に見えて早くなる事が非常に稀。
ぅぁぁ
×早くなる
○速くなる
×早くなる
○速くなる
11 ：仕様書無しさん：2006/01/05(木) 17:19:44
バブル楽しかったなあ。
いくら使っても使い切れんほどの金が
次から次へと流れ込んで来たっけ。
いくら使っても使い切れんほどの金が
次から次へと流れ込んで来たっけ。
>>9
Javaはネイティブコードにはコンパイルしてないだろ
Javaはネイティブコードにはコンパイルしてないだろ
13 ：仕様書無しさん：2006/01/05(木) 18:13:54
小さいプログラムならJavaよりもC++のほうが速いが
プログラムが巨大化してくるとC++だけで速度を
コントロールすることが徐々に難しくなってくるわけだ。
プログラムが複雑化するにつれて
どこでメモリ解放すべきかを見極めるのが非常に困難になってくる。
どんなにC++に精通していてもコンピュータのメモリ解放判断力には
人間は勝てず。
その結果、二人のプログラマに、片方はJava、もう片方にはC++
でプログラミングさせた結果、同じアルゴリズム、同じクラス設計である
にも関わらずなぜかJavaのほうが速いという減少がおこってしまう。
それはOSとかJavaVMの問題だよね
Java自体が速いわけじゃない
Java自体が速いわけじゃない
15 ：仕様書無しさん：2006/01/05(木) 18:25:48
バブル世代には何をいっても無駄だよ
体感的に遅いと感じなくても使い物にならないと
いう決めつけで自分の立場を必死に守ろうとしている哀れな連中だから
体感的に遅いと感じなくても使い物にならないと
いう決めつけで自分の立場を必死に守ろうとしている哀れな連中だから
>>9
> >>7
> そんな風に考えていた（ｒｙ
> もう繰り返し説明したくないが、実行時最適化。
>
> ただ、Java 使いには程度の低い奴が多いのと
バブル世代のキミに根拠もなくそんな発言をする権利は無いよ。
> (連中に、ハヤリモノに群がる習性がある所為で
バブル世代のキミに根拠もなくそんな発言をする権利は無いよ。
> >>7
> そんな風に考えていた（ｒｙ
> もう繰り返し説明したくないが、実行時最適化。
>
> ただ、Java 使いには程度の低い奴が多いのと
バブル世代のキミに根拠もなくそんな発言をする権利は無いよ。
> (連中に、ハヤリモノに群がる習性がある所為で
バブル世代のキミに根拠もなくそんな発言をする権利は無いよ。
わけわからん理屈だなｗ
19 ：仕様書無しさん：2006/01/05(木) 18:28:36
>体感的に遅いと感じなくても
あの起動が3分以上かかるDB管理ツールを楽しく使っていると
神経が麻痺するんだなJava厨
あの起動が3分以上かかるDB管理ツールを楽しく使っていると
神経が麻痺するんだなJava厨
20 ：仕様書無しさん：2006/01/05(木) 18:32:31
バブル世代のオッサンども死ねやオリャーーーw
おまいら若造はマシンパワーに頼りすぎですよ
22 ：仕様書無しさん：2006/01/05(木) 18:42:27
23 ：仕様書無しさん：2006/01/05(木) 18:43:03
>>21
お前のつかってるマシンはバブルマシンだろﾋｬｰｯﾋｬｯﾋｬｯﾋｬｯﾋｬｯﾋｬｯﾋｬｯﾋｬｰ
お前のつかってるマシンはバブルマシンだろﾋｬｰｯﾋｬｯﾋｬｯﾋｬｯﾋｬｯﾋｬｯﾋｬｯﾋｬｰ
バブルC++
若造が壊れた模様
バブル・スタジオ・ドトニート
>>25 ← バブル世代の言い訳w
そーいやバブルの時代はメモリも高かったなー
>>12
君、話にならんわ。
>>13
>どこでメモリ解放すべきかを見極めるのが非常に困難になってくる。
それを把握できないのはコード書いてる人間の能力の所為。
適当な事をそれっぽく言えばいいってモンじゃないだろうに。
>>17
>バブル世代のキミに
いや、オイルショック世代。
>>20
バブル世代がオッサンなら、俺はジジイなのか…
君、話にならんわ。
>>13
>どこでメモリ解放すべきかを見極めるのが非常に困難になってくる。
それを把握できないのはコード書いてる人間の能力の所為。
適当な事をそれっぽく言えばいいってモンじゃないだろうに。
>>17
>バブル世代のキミに
いや、オイルショック世代。
>>20
バブル世代がオッサンなら、俺はジジイなのか…
結論：Javaは遅いと言うことでファイナルアンサー？
メモリ1MB一万円時代のころからPCを使い始めた。
あのころはJavaもなかった。
あのころはJavaもなかった。
>>29
> >>13
> >どこでメモリ解放すべきかを見極めるのが非常に困難になってくる。
> それを把握できないのはコード書いてる人間の能力の所為。
> 適当な事をそれっぽく言えばいいってモンじゃないだろうに。
お前よりも頭の硬そうな白髪の50代のC言語厨のオッサンが
そんなアフォなことを言っていたよ。
何もかもすべて一人で開発しているわけではなかろうに。
誰かが書いたコードと自分の書いたコードを融合すると
既存のコードのメモリ解放のタイミングを考え直して
書き直さないといけない場面が出てくる。
コード量が多くなり複雑度が増せばメモリ解放ヶ所を謝るだけで
かえってJavaよりも重たくなる。それをわかっていないで
Javaを批判している馬鹿が多いもんだぜ。
> >>13
> >どこでメモリ解放すべきかを見極めるのが非常に困難になってくる。
> それを把握できないのはコード書いてる人間の能力の所為。
> 適当な事をそれっぽく言えばいいってモンじゃないだろうに。
お前よりも頭の硬そうな白髪の50代のC言語厨のオッサンが
そんなアフォなことを言っていたよ。
何もかもすべて一人で開発しているわけではなかろうに。
誰かが書いたコードと自分の書いたコードを融合すると
既存のコードのメモリ解放のタイミングを考え直して
書き直さないといけない場面が出てくる。
コード量が多くなり複雑度が増せばメモリ解放ヶ所を謝るだけで
かえってJavaよりも重たくなる。それをわかっていないで
Javaを批判している馬鹿が多いもんだぜ。
だからそれはOSとかJavaVMの問題だろうと
34 ：仕様書無しさん：2006/01/05(木) 19:03:18
>>33
.NETもそうだが、Javaや.NETはランタイム込みの環境を指す
.NETもそうだが、Javaや.NETはランタイム込みの環境を指す
>>32
>何もかもすべて一人で開発しているわけではなかろうに。
「現実問題、プロジェクトには能力の劣った人間も居る」と言う意味ならば
同意の上、以下は無視して欲しい。
>既存のコードのメモリ解放のタイミングを考え直して
これ、設計段階で失敗しているとしか思えないんだが。
構造化どころか、モジュールすら分割出来ていないのでは？
>メモリ解放ヶ所を謝るだけで
>かえってJavaよりも重たくなる。
C/C++ の多くの実装では、メモリ解放に掛かる時間は
無視出来るほど小さい。唯一の例外はスワップが大量発生
している場合だが、そこまで大きな領域を使用するなら
BSS に置くか、或いはプロセス終了まで解放しないのが定石。
>何もかもすべて一人で開発しているわけではなかろうに。
「現実問題、プロジェクトには能力の劣った人間も居る」と言う意味ならば
同意の上、以下は無視して欲しい。
>既存のコードのメモリ解放のタイミングを考え直して
これ、設計段階で失敗しているとしか思えないんだが。
構造化どころか、モジュールすら分割出来ていないのでは？
>メモリ解放ヶ所を謝るだけで
>かえってJavaよりも重たくなる。
C/C++ の多くの実装では、メモリ解放に掛かる時間は
無視出来るほど小さい。唯一の例外はスワップが大量発生
している場合だが、そこまで大きな領域を使用するなら
BSS に置くか、或いはプロセス終了まで解放しないのが定石。
37 ：仕様書無しさん：2006/01/05(木) 20:02:01
Java衷はインスタンスを使い回すから、解放が広域に拡散して、意味不明なことをくちばしる。
いらなくなったらさっさと捨てろ。
いらなくなったらさっさと捨てろ。
>>37
設計的には美しくても、それは無駄なコストを増やすだけ。lispと同じ原理主義だ。
広い机に、資料広げまくってお手伝いさんに適宜片付けてもらう。
それでいいんだよ。
わざわざ本棚からとってきた本を本棚に返してまた本棚からとってくるなんて無駄。
設計的には美しくても、それは無駄なコストを増やすだけ。lispと同じ原理主義だ。
広い机に、資料広げまくってお手伝いさんに適宜片付けてもらう。
それでいいんだよ。
わざわざ本棚からとってきた本を本棚に返してまた本棚からとってくるなんて無駄。
39 ：仕様書無しさん：2006/01/05(木) 20:13:15
>>1
お前の脳みそがなｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
お前の脳みそがなｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
>>15
ゴミを即効殺してやるなよｗｗｗｗｗｗｗかわいそうじゃんｗ
ゴミを即効殺してやるなよｗｗｗｗｗｗｗかわいそうじゃんｗ
41 ：仕様書無しさん：2006/01/05(木) 20:16:09
問題はその本が散らかってる状態で、
本が誰も読んでないかどうか監視するためだけに
CPU様が汗を流していることだな。
だから負担にならないように同じ本(ノート？)を
使い回す必要が生まれるわけだ
本が誰も読んでないかどうか監視するためだけに
CPU様が汗を流していることだな。
だから負担にならないように同じ本(ノート？)を
使い回す必要が生まれるわけだ
42 ：仕様書無しさん：2006/01/05(木) 20:19:46
やはりISAPIが最強
このリサイクルの時代に資源の無駄遣いをするなよな
44 ：仕様書無しさん：2006/01/05(木) 20:26:57
ゆとり世代のﾊﾟｰは後片付けもできません。
45 ：仕様書無しさん：2006/01/05(木) 20:35:49
現実にISAPIの案件なんかどこにあるんだよ？
聞いたことねえぞ
調べてみろ。Javaばかりだ。
聞いたことねえぞ
調べてみろ。Javaばかりだ。
JAVAっ低脳！
47 ：仕様書無しさん：2006/01/05(木) 20:44:17
爺氏ね
まともにレス出来てるの41だけじゃん…
確かにCPU様が汗を流してるから、最近はPauselessGCということもあろうに
ハードウェアでそれを肩代わりしようという悪魔の発想のGCアルゴリズムも出てきた。
自分でメモリの取得・開放ってのは規模が大きくなるにつれて
プログラマが神の知性を持っていなければ破綻するものなんだよな。
俺も昔は自前で取得・開放派だったけど、最近は
「人間様はそんな複雑なことできねぇから遅くなっていいからGCで頼むよ」
って感じだ。
ちなみに人間のDNA(塩基配列？)は4ビットのプログラムになってて、
ものすごいスパゲッティコードなんだそうだ。
オブジェクト指向とか、そんな構造何それって感じで何億年もかけた
個体によっては100年以上もつ自己拡張無停止システム。
おまえら、そんなの制御するコード書けるか？無理だろ。だから多少の工夫が必要なんだよ。
確かにCPU様が汗を流してるから、最近はPauselessGCということもあろうに
ハードウェアでそれを肩代わりしようという悪魔の発想のGCアルゴリズムも出てきた。
自分でメモリの取得・開放ってのは規模が大きくなるにつれて
プログラマが神の知性を持っていなければ破綻するものなんだよな。
俺も昔は自前で取得・開放派だったけど、最近は
「人間様はそんな複雑なことできねぇから遅くなっていいからGCで頼むよ」
って感じだ。
ちなみに人間のDNA(塩基配列？)は4ビットのプログラムになってて、
ものすごいスパゲッティコードなんだそうだ。
オブジェクト指向とか、そんな構造何それって感じで何億年もかけた
個体によっては100年以上もつ自己拡張無停止システム。
おまえら、そんなの制御するコード書けるか？無理だろ。だから多少の工夫が必要なんだよ。
A-T-G-Cだから２ビットな
C++ではGC作れないのか。
ttp://blackshadow.seesaa.net/article/7465794.html
すまん、↑のエントリみて4進数ってのが4bitに脳内置換されてたようだ。
>>50
作れるだろ。ってか、Cでもライブラリなかった？
すまん、↑のエントリみて4進数ってのが4bitに脳内置換されてたようだ。
>>50
作れるだろ。ってか、Cでもライブラリなかった？
JavaにGCがなければ良い言語だと思う。
53 ：仕様書無しさん：2006/01/05(木) 21:38:56
GCがなくてネイティブトランスレータがあれば最強かも
というかJava以降でGCのない言語ってでてきたっけ?
GCJ使っとけ
GCはあっても、明示的に開放する手段があればいいだけじゃね？
そしたらGC否定派も満足するし、GC肯定派は今までどうり使えばいい。
もっともそうなりゃGC否定派がまだ利用するオブジェクトを開放して、ぬるぽ出しまくり。
そしたらGC否定派も満足するし、GC肯定派は今までどうり使えばいい。
もっともそうなりゃGC否定派がまだ利用するオブジェクトを開放して、ぬるぽ出しまくり。
いや、開放する手段があるだけだと、インスタンスが増えた時に
遅くなる点に対応出来ない。そうならないためにJavaPGはインスタンスを
使いまわすという概念上のスコープをぶち壊すことをしつつ、オブジェクト
思考と喜んでいるんだよ。
頭悪っ！ｗｗｗｗｗ
遅くなる点に対応出来ない。そうならないためにJavaPGはインスタンスを
使いまわすという概念上のスコープをぶち壊すことをしつつ、オブジェクト
思考と喜んでいるんだよ。
頭悪っ！ｗｗｗｗｗ
58 ：69式フリーPG ◆hND3Lufios ：2006/01/05(木) 22:02:02
携帯の着メロをバナナラマにしている俺様が来ましたよ。
>>48
言っておくがコンピュータは複雑な問題は苦手だよ。
規模が大きくなるにつれて問題は複雑になり、万能な解決方法はなくなってくる。
多分、規模が大きくなるほど人間によるチューニングよりコンピュータまかせのGCは遅くなるはずだ。
言っておくがコンピュータは複雑な問題は苦手だよ。
規模が大きくなるにつれて問題は複雑になり、万能な解決方法はなくなってくる。
多分、規模が大きくなるほど人間によるチューニングよりコンピュータまかせのGCは遅くなるはずだ。
だから、インスタンスは可能な限り狭いスコープの範囲で確保して
解放するのが正解なんだな。
関数（メソッド）にしろ、構造体にしろクラスにしろ、本来はそのようにして
スコープを構造的に構築するために設けられたものなんだ。
ところが、インスタンスを大量に確保するとガベコレのパフォーマンスが
物凄い勢いで劣化するというJavaの特性のために、Javaはインスタンスを
使いまわすことでインスタンス数の爆発を防ぎ、パフォーマンスの低下を
防ぐ手法が一般化した。
これは、ソフトウェアエンジニアリングが半世紀かかって構築してきた
スコープという範囲を限定することで単純化し、人間の頭でも理解できるように
するという原則を根本から破壊している。
だから、俺はJavaの仕事をしない。あんなものはVB以下。N88-BASIC以下だ。
デスマになって当然。
解放するのが正解なんだな。
関数（メソッド）にしろ、構造体にしろクラスにしろ、本来はそのようにして
スコープを構造的に構築するために設けられたものなんだ。
ところが、インスタンスを大量に確保するとガベコレのパフォーマンスが
物凄い勢いで劣化するというJavaの特性のために、Javaはインスタンスを
使いまわすことでインスタンス数の爆発を防ぎ、パフォーマンスの低下を
防ぐ手法が一般化した。
これは、ソフトウェアエンジニアリングが半世紀かかって構築してきた
スコープという範囲を限定することで単純化し、人間の頭でも理解できるように
するという原則を根本から破壊している。
だから、俺はJavaの仕事をしない。あんなものはVB以下。N88-BASIC以下だ。
デスマになって当然。
>>59
確かに、すでに広大なメモリ空間をGCする際にStopTheWorld式のGCは限界だ。
スループットがでかくても、停止時間が十数秒とか発生してる状況で
Webサービスに最適！なんていってるのは、もう言説からして破綻している。
しかし、そこでPauselessGCですよ。
とりあえず、俺はもう人間は信用したくない。
int hoge;//おまじない
とか見たくない。
確かに、すでに広大なメモリ空間をGCする際にStopTheWorld式のGCは限界だ。
スループットがでかくても、停止時間が十数秒とか発生してる状況で
Webサービスに最適！なんていってるのは、もう言説からして破綻している。
しかし、そこでPauselessGCですよ。
とりあえず、俺はもう人間は信用したくない。
int hoge;//おまじない
とか見たくない。
>>60
その意見にうなずけるものもあるが、オブジェクトのプーリングや共有は
結局オブジェクトを取り巻く「環境」までオブジェクトにマッピングしようとしたときに
発生するインピーダンスを解消する次善の策だから、必要悪と思うしかない。
オブジェクト指向と現実世界の、避けがたい闇だな。
アスペクト指向とかで何とかしようという奴らも居るが、あんまりやりすぎると不毛な気はおれもしている。
その意見にうなずけるものもあるが、オブジェクトのプーリングや共有は
結局オブジェクトを取り巻く「環境」までオブジェクトにマッピングしようとしたときに
発生するインピーダンスを解消する次善の策だから、必要悪と思うしかない。
オブジェクト指向と現実世界の、避けがたい闇だな。
アスペクト指向とかで何とかしようという奴らも居るが、あんまりやりすぎると不毛な気はおれもしている。
63 ：仕様書無しさん：2006/01/05(木) 22:21:24
N88-BASICって辺りが加齢臭
リークってさ、ホントはPGのポカで生じるもんでしょ？
そのポカをフォローするため装置としてのGCは大げさすぎるような気がする。
その結果招いた欠点を取り繕うために、もっと複雑なことをしていないか？
そのポカをフォローするため装置としてのGCは大げさすぎるような気がする。
その結果招いた欠点を取り繕うために、もっと複雑なことをしていないか？
66 ：仕様書無しさん：2006/01/05(木) 23:06:45
なるほど。
Java厨はスコープをぶち壊しているから、１メソッドコピペで1万行なんて
コードが書けるんですね！
Java厨はスコープをぶち壊しているから、１メソッドコピペで1万行なんて
コードが書けるんですね！
GCあってもぽかってます
68 ：仕様書無しさん：2006/01/05(木) 23:08:53
>>56
C++/CLI がそれに一番近い現実解かなあ。
C++/CLI がそれに一番近い現実解かなあ。
69 ：仕様書無しさん：2006/01/05(木) 23:42:42
爺しね
70 ：仕様書無しさん：2006/01/05(木) 23:46:58
Javaとデスマは関係ない。デスマはもっとずっと前の段階に原因がある。
71 ：仕様書無しさん：2006/01/05(木) 23:49:47
>>71
遅い
遅い
73 ：仕様書無しさん：2006/01/06(金) 00:07:35
気がつくと以外にもこんなにスレが伸びているとは。
こんなにバブル反応があるとは思わなかったぜw
こんなにバブル反応があるとは思わなかったぜw
世代は関係無く、Javaが糞だからだろｗ
Javaの先進性についていけない爺が多いことだけはわかった。
先進性ならC#だろ
>>36
> >>32
> >メモリ解放ヶ所を謝るだけで
> >かえってJavaよりも重たくなる。
> C/C++ の多くの実装では、メモリ解放に掛かる時間は
> 無視出来るほど小さい。唯一の例外はスワップが大量発生
> している場合だが、そこまで大きな領域を使用するなら
ある調査で、C++とJavaとのメモリ解放速度を比較したベンチマークってのがあって
読んでみたんだが、短いプログラムでは確かにC++のほうが速かった。
だが巨大なプログラムになると様子は若干変わっていた。
メモリを解放する量を少なめにした場合はC++のほうが速いが
解放する量を多めに設定するとC++もJavaもさほど変わらないことがわかった。
複雑大規模になるとどの程度の量を解放するかが難しい。
デザインパターンを徹底的に駆使してListの中にListをいくつも入れ子に
しているようなオブジェクトや数珠繋ぎのように大量に他のオブジェクトを参照している
オブジェクトを解放するときはどのように解放すべきかを考えることは、さぞや大変なことだろう。
> BSS に置くか、或いはプロセス終了まで解放しないのが定石。
それじゃ莫大なメモリが必要じゃないかw
> >>32
> >メモリ解放ヶ所を謝るだけで
> >かえってJavaよりも重たくなる。
> C/C++ の多くの実装では、メモリ解放に掛かる時間は
> 無視出来るほど小さい。唯一の例外はスワップが大量発生
> している場合だが、そこまで大きな領域を使用するなら
ある調査で、C++とJavaとのメモリ解放速度を比較したベンチマークってのがあって
読んでみたんだが、短いプログラムでは確かにC++のほうが速かった。
だが巨大なプログラムになると様子は若干変わっていた。
メモリを解放する量を少なめにした場合はC++のほうが速いが
解放する量を多めに設定するとC++もJavaもさほど変わらないことがわかった。
複雑大規模になるとどの程度の量を解放するかが難しい。
デザインパターンを徹底的に駆使してListの中にListをいくつも入れ子に
しているようなオブジェクトや数珠繋ぎのように大量に他のオブジェクトを参照している
オブジェクトを解放するときはどのように解放すべきかを考えることは、さぞや大変なことだろう。
> BSS に置くか、或いはプロセス終了まで解放しないのが定石。
それじゃ莫大なメモリが必要じゃないかw
開発者はともかく利用者にはまったく利益が無いんだよね。
えっ？Javaなら安くなるって？ ﾌﾟﾌﾟﾌﾟ
えっ？Javaなら安くなるって？ ﾌﾟﾌﾟﾌﾟ
80 ：仕様書無しさん：2006/01/06(金) 00:18:25
＞デザインパターンを徹底的に駆使してListの中にListをいくつも入れ子に
＞しているようなオブジェクトや数珠繋ぎのように大量に他のオブジェクトを参照している
＞オブジェクトを解放するときはどのように解放すべきかを考えることは、さぞや大変なことだろう。
最近のプログラマは分割統治という言葉も知らんのか？
そういう処理こそクラス設計をうまいことやって、単純な処理に落とし込んでいくんだよ。
＞しているようなオブジェクトや数珠繋ぎのように大量に他のオブジェクトを参照している
＞オブジェクトを解放するときはどのように解放すべきかを考えることは、さぞや大変なことだろう。
最近のプログラマは分割統治という言葉も知らんのか？
そういう処理こそクラス設計をうまいことやって、単純な処理に落とし込んでいくんだよ。
爺のしったかは泣けてくるね
そうか、今は冬休みか
どうみてもVB後継のﾄﾞｶﾀ言語です。
本当にありがとうございました。
本当にありがとうございました。
>>クラス設計をうまいことやって
一番重要なところを曖昧にすっ飛ばしすぎだろ、ジジイｗｗｗｗｗｗｗｗｗｗｗ
一番重要なところを曖昧にすっ飛ばしすぎだろ、ジジイｗｗｗｗｗｗｗｗｗｗｗ
上手く設計しろよ
86 ：仕様書無しさん：2006/01/06(金) 00:29:45
つか、C++ でも boost::scoped_ptr やら boost::shared_ptr を使えば、
自分で明示的に delete を書くことってほとんど無くならね？
自分で明示的に delete を書くことってほとんど無くならね？
どれどれ、Javaで良いコードを書くコツを爺が教えてしんぜようかの。
それはな。
小さいソフトを組むことじゃ。
元々家電の組み込み用。大規模で複雑なことをさせたら破綻するのじゃ。
炊飯器のスイッチをいれるとか、何分間蒸らすとか、そういう単純なことだけを
させれば、Javaは完璧に動く。よいかな？
それはな。
小さいソフトを組むことじゃ。
元々家電の組み込み用。大規模で複雑なことをさせたら破綻するのじゃ。
炊飯器のスイッチをいれるとか、何分間蒸らすとか、そういう単純なことだけを
させれば、Javaは完璧に動く。よいかな？
あ。書いちゃった。
Javaアプレットも今やFlashに置き換わり
90 ：仕様書無しさん：2006/01/06(金) 00:36:09
いっそのこと、携帯Javaみたくクラス自体を作らないというのはどうだろうか。
かなり速くなりそうだのが。
かなり速くなりそうだのが。
main メソッドもいらねーや。
ソースコードの先頭から順に実行でいいじゃん。
ソースコードの先頭から順に実行でいいじゃん。
関数の宣言順序によって実行できなかったりするんだな。Cじゃん。
javaって、もう無くなっていく言語なんでしょ。
熱くならなくったっていいじゃん。
熱くならなくったっていいじゃん。
.NETがクロスになればなぁ....
そうすりゃJAVAなんか3年で絶滅させられるのに。
そうすりゃJAVAなんか3年で絶滅させられるのに。
95 ：仕様書無しさん：2006/01/06(金) 00:52:08
>>93
そんな糞言語を擁護する厨を馬鹿にする一連のすれなのだ
そんな糞言語を擁護する厨を馬鹿にする一連のすれなのだ
NHKでやってたロボコンだかソフコンだか、生徒はC#で作ってたな。
97 ：仕様書無しさん：2006/01/06(金) 01:05:21
>>94
もう虫の息だからだいじょうぶだ
もう虫の息だからだいじょうぶだ
>>94
いくらクロスになっても3年で絶滅は無理。
C#ではもう間に合わんよ。
C++とは異なる言語として新しい言語Javaだ！
っていうインパクトがC#にはないと無理。
C#は、Javaとは異なる斬新な言語とはとても言えないからね。
もっと斬新な言語を作らなければJavaに対する勝ち目はもう無い。
Javaにたいして対抗意識を燃やすより、
Javaをベースとして数多くのフレームワークやAPI
やプロダクトを大量に作って自分のクリエイト魂を燃やしたほうが
効率が良いしためになる。
その例としてEclipseが恒例。
もう今更独自のIDEなんか作るのは非常に効率が悪い。
そこでEclipseベースのIDEを作って配布または販売するというビジネスが
最近流行っている。オープンソースソフトウェアの上位版は有料にして
うまいぐあいにユーザを集めやすくしている。
そのほうが何かと都合が良いからね。
いくらクロスになっても3年で絶滅は無理。
C#ではもう間に合わんよ。
C++とは異なる言語として新しい言語Javaだ！
っていうインパクトがC#にはないと無理。
C#は、Javaとは異なる斬新な言語とはとても言えないからね。
もっと斬新な言語を作らなければJavaに対する勝ち目はもう無い。
Javaにたいして対抗意識を燃やすより、
Javaをベースとして数多くのフレームワークやAPI
やプロダクトを大量に作って自分のクリエイト魂を燃やしたほうが
効率が良いしためになる。
その例としてEclipseが恒例。
もう今更独自のIDEなんか作るのは非常に効率が悪い。
そこでEclipseベースのIDEを作って配布または販売するというビジネスが
最近流行っている。オープンソースソフトウェアの上位版は有料にして
うまいぐあいにユーザを集めやすくしている。
そのほうが何かと都合が良いからね。
好例
101 ：仕様書無しさん：2006/01/06(金) 01:15:01
NEET予備軍バブル世代のための統合開発環境が無償で入手可能！！
バブリシャスC++ドットNEET Express 2005!!!!
バブリシャスC++ドットNEET Express 2005!!!!
どうせ Java でもファイルやネットワーク接続とかは自前で close しないと
いけないぢゃん。
ところで、Java の try-finally よりも C# の using よりも、
実は C++ の RAII イディオムのほうがスマートだったりするな。
いけないぢゃん。
ところで、Java の try-finally よりも C# の using よりも、
実は C++ の RAII イディオムのほうがスマートだったりするな。
その新しいものこそすばらしいという考え方こそダメダメだな。
Visual C++でISAPI。
これができる技術者はWin32でexeやdll、COMをバリバリ開発していた
技術者だけ。
Javaの低品質人海戦術ﾄﾞｶﾀ開発から、高品質少数精鋭開発へ。
景気が好転しつつある昨今、元来が高品質・コンパクトなものを好む
国民性が現れ、状況が変わると思う。
Visual C++でISAPI。
これができる技術者はWin32でexeやdll、COMをバリバリ開発していた
技術者だけ。
Javaの低品質人海戦術ﾄﾞｶﾀ開発から、高品質少数精鋭開発へ。
景気が好転しつつある昨今、元来が高品質・コンパクトなものを好む
国民性が現れ、状況が変わると思う。
そもそもJavaとVCじゃ用途が違うじゃん。実際のところ。
105 ：仕様書無しさん：2006/01/06(金) 01:29:54
VC、サービスからWeb、コンポーネント、SOAPその他なんでもできる
Java、糞の役にも立たない
Java、糞の役にも立たない
これからはISAPI
107 ：69式フリーPG ◆hND3Lufios ：2006/01/06(金) 01:35:04
うーん。Javaって教育用にはいいんじゃないか？
なんて考えてたら、バブル世代のオイラ達は、大学でPascalを習ったことを思い出した。
で、いまさらなんだけど、Javaって、UCSD Pascalみたいなんだよな。
あの当時は完全な教育用途で、ネィティブ化され、改良されまくったTurboPascalで
やっと実用性が出たわけだけど。
http://ja.wikipedia.org/wiki/UCSD_Pascal
なんて考えてたら、バブル世代のオイラ達は、大学でPascalを習ったことを思い出した。
で、いまさらなんだけど、Javaって、UCSD Pascalみたいなんだよな。
あの当時は完全な教育用途で、ネィティブ化され、改良されまくったTurboPascalで
やっと実用性が出たわけだけど。
http://ja.wikipedia.org/wiki/UCSD_Pascal
実装可能であることと使えるかどうかは別なんだけど。
109 ：仕様書無しさん：2006/01/06(金) 03:03:39
110 ：仕様書無しさん：2006/01/06(金) 07:55:14
最近はちょっと使えるJavaの派遣プログラマは、だいたい月100万らしい。
（会社対会社の金額ね）。ほかは60〜80くらいがふつうなんで、すごく高い。
ナンデカ？
１．Javaは衰退しているのでプログラマの絶対数が不足。希少価値が高い。
２．Javaの仕事がまだまだ増え続けている。かつ難易度が高く、技術者不足。
実はこれからJavaを勉強してみようかとも考えているおれ．．．
（会社対会社の金額ね）。ほかは60〜80くらいがふつうなんで、すごく高い。
ナンデカ？
１．Javaは衰退しているのでプログラマの絶対数が不足。希少価値が高い。
２．Javaの仕事がまだまだ増え続けている。かつ難易度が高く、技術者不足。
実はこれからJavaを勉強してみようかとも考えているおれ．．．
111 ：仕様書無しさん：2006/01/06(金) 12:05:00
あれだな。高級羽毛布団なC++だと速くて軽くて快適なんだが
Javaだと薄っぺらで保温性に劣る安布団をたくさんかけるんだよな
重くてくどいだけで性能が悪い
Javaだと薄っぺらで保温性に劣る安布団をたくさんかけるんだよな
重くてくどいだけで性能が悪い
112 ：仕様書無しさん：2006/01/06(金) 12:23:10
Javaの仕事って、どんなの？
単価高いなら勉強しようかな
単価高いなら勉強しようかな
＞Javaは遅い
お前らのPCスペックが糞なだけ
お前らのPCスペックが糞なだけ
>>112
Javaの利点はスケーラビリティーという一語に要約できる。
言語の在り方としてもそうなんだけど、その開発者に対しても同じ事が言える。
CでもPerlでも、シェルスクリプトだって構わない、とにかく何らかのコンピュー
タ言語が扱える人間なら、極限定された部分ではあっても一定の役割を負う
事ができる。
未経験者は年齢が命。文法だけサラっと学んだら足を棒にして働き口を捜せ。
ある一定のレベルに達するまでは、実務こそが最高の勉強場なんだから、独
学なんか時間の無駄。
仮に独学でどんなに高い技術を身に付けても、雇い手が居なきゃ持ち腐れだ。
とにかく就職して、それから死ぬ気で努力しろ。
就職してからの努力は必ず報われる。どうせ努力するなら報われる努力の方
がいいだろ？
Javaの利点はスケーラビリティーという一語に要約できる。
言語の在り方としてもそうなんだけど、その開発者に対しても同じ事が言える。
CでもPerlでも、シェルスクリプトだって構わない、とにかく何らかのコンピュー
タ言語が扱える人間なら、極限定された部分ではあっても一定の役割を負う
事ができる。
未経験者は年齢が命。文法だけサラっと学んだら足を棒にして働き口を捜せ。
ある一定のレベルに達するまでは、実務こそが最高の勉強場なんだから、独
学なんか時間の無駄。
仮に独学でどんなに高い技術を身に付けても、雇い手が居なきゃ持ち腐れだ。
とにかく就職して、それから死ぬ気で努力しろ。
就職してからの努力は必ず報われる。どうせ努力するなら報われる努力の方
がいいだろ？
>>112
ついでに、単価は自分が担える実務の範囲とその量に比例する。
ついでに、単価は自分が担える実務の範囲とその量に比例する。
技術面での評価とは無関係に、
ニーズが増加すればシーズがそれに呼応するのは市場の原則らしいねｗ
ニーズが増加すればシーズがそれに呼応するのは市場の原則らしいねｗ
118 ：仕様書無しさん：2006/01/06(金) 16:41:26
妥協の時代は終焉を迎えるぞ
こんどは本物の時代だ
こんどは本物の時代だ
119 ：仕様書無しさん：2006/01/06(金) 16:52:40
昔は皆丁寧につくりこんでいたもんだ。
低単価・人海戦術のやっつけ仕事で、
かろうじて動いているようなシステムを納め、
クレームとトラブルに追われる毎日は終りにしないか
低単価・人海戦術のやっつけ仕事で、
かろうじて動いているようなシステムを納め、
クレームとトラブルに追われる毎日は終りにしないか
かろうじて動くようなシステムを廉価に求める客がいるかぎり無理な気が
廉価なら廉価らしく工数のかからないものでさくっと組んで納めればいいのだ。
問題は、手のかかるものを廉価で受注しそれをマンパワーで何とかしようと
している点にある。
問題は、手のかかるものを廉価で受注しそれをマンパワーで何とかしようと
している点にある。
122 ：仕様書無しさん：2006/01/06(金) 19:01:41
COBOLでいいだろ。
123 ：仕様書無しさん：2006/01/06(金) 20:37:05
>>112
Javaは単価が安かろうと高かろうと
勉強する価値はある。
数年前に名門大学で授業に使う言語がC++からJavaに
変わるという事件が起きたほどだ。
習得しやすさのほか応用性も高い。
名門大学で採用されたくらいだから一気に勢力が拡大した。
すると企業もJavaを標準プログラミング言語にせざるを得なくなってしまう。
Javaは単価が安かろうと高かろうと
勉強する価値はある。
数年前に名門大学で授業に使う言語がC++からJavaに
変わるという事件が起きたほどだ。
習得しやすさのほか応用性も高い。
名門大学で採用されたくらいだから一気に勢力が拡大した。
すると企業もJavaを標準プログラミング言語にせざるを得なくなってしまう。
企業が大学で教えてる言語なんかで左右されるかよ。
大学出は基本的に役に立たないんだから基礎理論だけ教えとけ
大学出は基本的に役に立たないんだから基礎理論だけ教えとけ
125 ：仕様書無しさん：2006/01/06(金) 20:48:37
と、専門学校卒が申しております。
126 ：仕様書無しさん：2006/01/06(金) 21:33:09
javaは読めりゃいいや。
OOPやAOPの勉強用。
OOPやAOPの勉強用。
おっさん達おかしいよ。
128 ：高校生：2006/01/06(金) 21:42:35
「今こんなにホームレスが多いのは『バブルが崩壊した』のが原因」
みたいな事を学校の先生から学んだんだけど、具体的に
「なんでバブル（好景気）になったの？」とか、
「なんでバブルが崩壊したの？」
と質問すると「・・・銀行が貸し渋りをするようになって・・・・」
とか・・・言って
具体的な事をまったく教えてくれません。
と、言うか教師自体が理解しきれてないようです。
「なんで銀行が貸し渋りするようになったの？」
とか質問してたら、
「だまって話を聞け」
みたいに叱られて、黙って聞いてたら
「その時代は豊かで良かった」とか「今不景気なのはその時代が原因」とか・・・・
結局同じところをたらい回しにされて具体的なことを教えてくれなかった・・・
その教師は大学院から直に教師になったらしく、（その辺の事情は良く解りませんが・・・
社会の荒波にもまれる事もなく、学生から公務員と言う道のりを歩んだ人らしいので、
バブル経済の深い事なんぞ解らないのも無理がないんですけどね・・・
こんな人が教師をやってるので、その下で学ぶ私たち学生がバブルのことなんて解るはずありません。
バブルを知らない「今の少年」である私に、
当時のバブル世代の方、具体的に教えていただけないでしょうか？
是非、お願いします。
みたいな事を学校の先生から学んだんだけど、具体的に
「なんでバブル（好景気）になったの？」とか、
「なんでバブルが崩壊したの？」
と質問すると「・・・銀行が貸し渋りをするようになって・・・・」
とか・・・言って
具体的な事をまったく教えてくれません。
と、言うか教師自体が理解しきれてないようです。
「なんで銀行が貸し渋りするようになったの？」
とか質問してたら、
「だまって話を聞け」
みたいに叱られて、黙って聞いてたら
「その時代は豊かで良かった」とか「今不景気なのはその時代が原因」とか・・・・
結局同じところをたらい回しにされて具体的なことを教えてくれなかった・・・
その教師は大学院から直に教師になったらしく、（その辺の事情は良く解りませんが・・・
社会の荒波にもまれる事もなく、学生から公務員と言う道のりを歩んだ人らしいので、
バブル経済の深い事なんぞ解らないのも無理がないんですけどね・・・
こんな人が教師をやってるので、その下で学ぶ私たち学生がバブルのことなんて解るはずありません。
バブルを知らない「今の少年」である私に、
当時のバブル世代の方、具体的に教えていただけないでしょうか？
是非、お願いします。
板違いにも程があるぞ高校生
130 ：高校生：2006/01/06(金) 21:52:22
ごめんなさい、
検索でそれっぽいのが引っかかったので「いいかなー」と思いました・・・
やっぱ板違いだったのか・・・OTZ
検索でそれっぽいのが引っかかったので「いいかなー」と思いました・・・
やっぱ板違いだったのか・・・OTZ
>>123
大学の情報系の教員は得てして Lisp や Prolog みたいなマイナー言語厨が
多いから困る。
某 Q 大では、一時マジで新入生向けプログラミング授業の題材が Scheme に
なりかけたｗ
大学の情報系の教員は得てして Lisp や Prolog みたいなマイナー言語厨が
多いから困る。
某 Q 大では、一時マジで新入生向けプログラミング授業の題材が Scheme に
なりかけたｗ
>>90
Cよりカスじゃんｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
Cよりカスじゃんｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
大学は（俺様言語を作るぐらいが）元気でよろしい
大学でライブラリの使い方教えられてもね
夏季特別講習が今でも行われていれば隠れLispファンが
毎年3人ぐらい増えたかもしれないのに
毎年3人ぐらい増えたかもしれないのに
138 ：仕様書無しさん：2006/01/07(土) 00:04:48
>>124
> 企業が大学で教えてる言語なんかで左右されるかよ。
何をいっているんだ、今まで多くの企業が散々C言語に左右されてきただろう。
大学はC言語をメインに教えて来た。
大学では、プログラミング言語といえばC言語だったのだ。
そして世界で最もシェアが高い言語にまでなった。
大学による影響力は強い。大学教授がこれがいいと言えばそれに皆従う。
そしてC言語やJavaが普及した。
> 大学出は基本的に役に立たないんだから基礎理論だけ教えとけ
おまえは専門卒か高卒か？ 学歴があるからといって能力があるとか
仕事ができるとは限らないことは確かに事実だが大学にいかないほうがいい
のか？ といえばそうともいえないし大卒＝高卒より使えないという根拠もない。逆も然り
> 企業が大学で教えてる言語なんかで左右されるかよ。
何をいっているんだ、今まで多くの企業が散々C言語に左右されてきただろう。
大学はC言語をメインに教えて来た。
大学では、プログラミング言語といえばC言語だったのだ。
そして世界で最もシェアが高い言語にまでなった。
大学による影響力は強い。大学教授がこれがいいと言えばそれに皆従う。
そしてC言語やJavaが普及した。
> 大学出は基本的に役に立たないんだから基礎理論だけ教えとけ
おまえは専門卒か高卒か？ 学歴があるからといって能力があるとか
仕事ができるとは限らないことは確かに事実だが大学にいかないほうがいい
のか？ といえばそうともいえないし大卒＝高卒より使えないという根拠もない。逆も然り
>>138
俺は大卒。フォートランとCとJavaとSmalltalkを大学で習ったが、
一番ためになったのはSmalltalkと計算機の基礎理論。
今思えばlispもやっておきたかった。
シェアとか関係なしに構造として美しい言語を採用できる機関ってのは
大学だけだと思ってるし、プログラマ人生の初期の段階でさまざまな言語の
思想や設計を教えてもらえれば今後のプログラム人生にもよい影響がある事は
明らかなのではないかと思うんだがどうだろう？
まぁ、俺の大学にもそんなことよりも就職！高給！知名度！みたいな
がっつく学生が居て俺はそういうや面よりも多少おっとりしてたなとも思うが。
俺は大卒。フォートランとCとJavaとSmalltalkを大学で習ったが、
一番ためになったのはSmalltalkと計算機の基礎理論。
今思えばlispもやっておきたかった。
シェアとか関係なしに構造として美しい言語を採用できる機関ってのは
大学だけだと思ってるし、プログラマ人生の初期の段階でさまざまな言語の
思想や設計を教えてもらえれば今後のプログラム人生にもよい影響がある事は
明らかなのではないかと思うんだがどうだろう？
まぁ、俺の大学にもそんなことよりも就職！高給！知名度！みたいな
がっつく学生が居て俺はそういうや面よりも多少おっとりしてたなとも思うが。
>>138
> 大学出は基本的に役に立たないんだから基礎理論だけ教えとけ
ごめんごめんこれは
大学出は→大学での勉強は
に置き換えてくれ。
ミスタイプをそのまま書き込んで放置してたんだ。
どうせ実戦で即使える奴なんて殆ど居ないんだから素養だけでも
身につけさせておいたほうがいいんじゃないかという考え方。
> 大学出は基本的に役に立たないんだから基礎理論だけ教えとけ
ごめんごめんこれは
大学出は→大学での勉強は
に置き換えてくれ。
ミスタイプをそのまま書き込んで放置してたんだ。
どうせ実戦で即使える奴なんて殆ど居ないんだから素養だけでも
身につけさせておいたほうがいいんじゃないかという考え方。
>>140
> >>138
> > 大学出は基本的に役に立たないんだから基礎理論だけ教えとけ
>
> ごめんごめんこれは
> 大学出は→大学での勉強は
> に置き換えてくれ。
それは職種にもよる。
そんなことばかりいってると
嫉み深い高卒の顧客や上司に、能力ある大卒に仕事を与えない
という不利な口実になってしまう恐れがあるぞ。
実際、堀江貴文も大学なんていらないとかいって中退しているしな。
「大学＝役に立たない」という式を勝手に広めることは
能力のある高卒にとっては悪いことではないが
能力の無い高卒をのさばらせるだけだ。
「大学＝時と場合によっては役に立たないこともある」
というだけで全く役に立たないというのは大きな誤解を生む。
それに大学の存在価値そのものを否定することはやめておけ。
堀江みたいに大学なんていらないとか調子こいたことをいう馬鹿が現れる。
職種にとっては役立つこともかなり多いわけだし
独学で学ぶ処理も教え方がうまい教官のもとで学んだほうが
学習速度ははるかに効率がよい。教え方が下手な奴もいることは確かだが
それでも何か新しいことを学ぼうとするヒントを得やすいという利点が大学にはある。
大学は本来の研究教育目的の場としては機能しにくくなってきていることは確かだが、
どこの先進国の大学もサークル、恋愛、人間関係などで人生経験を積む場所としても機能している。
だが、大学院に行く者達の考え方はほとんど違うと思っても良い。大学院に行かない者は就職の
ことを考えた方がいいと、最近ではどこの研究室の教官も放置プレイになっている。
大学院ではそうはいかない。大学院生は大学で教わったことのほぼ全てが自分の将来で役に立てている。
最近では、残念なことに、大学院修士課程の学生の中には、卒論生と同じ事しかできない者も増えてきてはいるが。
>>128
> 「だまって話を聞け」
> みたいに叱られて、黙って聞いてたら
> 「その時代は豊かで良かった」とか「今不景気なのはその時代が原因」とか・・・・
> 結局同じところをたらい回しにされて具体的なことを教えてくれなかった・・・
> その教師は大学院から直に教師になったらしく、（その辺の事情は良く解りませんが・・・
その教師の大学院での専攻は何だった？
どうせ経済学部じゃないところだろ。
大学院というところはより専門的な研究をするところだ。
金融や経済のことは金融や経済の専門のほうが詳しくて
そうでない者が詳しくないのは当たり前。
確かに、今まで、大学院行って助手になってから教授になった者よりも
一度社会人を経験してから教授になった者のほうが話が分かる教官が多く
知ったかぶりも少なく、態度もでかくなく、人格もまともな傾向はあったが、
それは過去の事例だ。今でも大学院行って威張ってるアホは確かにいる。
コネに必死にしがみついてゴマ擦ってる奴とかがたまにいる。
院生や院卒の印象が悪くなるのでそういう連中は同じ大学院生としてムカツクがな。
君の教官(高校教師)も口先だけのムカツクタイプのやつかもしれんな。
大学以外の組織に就職したことも無い教授に「これができなきゃ社会に出てから困るぞ」
と偉そうなことを言われて俺もウザイと思ったことがある。それで彼らに怒ってもろくなことはないし
権力を振りかざして単位を落とされてしまうがな。
> 「だまって話を聞け」
> みたいに叱られて、黙って聞いてたら
> 「その時代は豊かで良かった」とか「今不景気なのはその時代が原因」とか・・・・
> 結局同じところをたらい回しにされて具体的なことを教えてくれなかった・・・
> その教師は大学院から直に教師になったらしく、（その辺の事情は良く解りませんが・・・
その教師の大学院での専攻は何だった？
どうせ経済学部じゃないところだろ。
大学院というところはより専門的な研究をするところだ。
金融や経済のことは金融や経済の専門のほうが詳しくて
そうでない者が詳しくないのは当たり前。
確かに、今まで、大学院行って助手になってから教授になった者よりも
一度社会人を経験してから教授になった者のほうが話が分かる教官が多く
知ったかぶりも少なく、態度もでかくなく、人格もまともな傾向はあったが、
それは過去の事例だ。今でも大学院行って威張ってるアホは確かにいる。
コネに必死にしがみついてゴマ擦ってる奴とかがたまにいる。
院生や院卒の印象が悪くなるのでそういう連中は同じ大学院生としてムカツクがな。
君の教官(高校教師)も口先だけのムカツクタイプのやつかもしれんな。
大学以外の組織に就職したことも無い教授に「これができなきゃ社会に出てから困るぞ」
と偉そうなことを言われて俺もウザイと思ったことがある。それで彼らに怒ってもろくなことはないし
権力を振りかざして単位を落とされてしまうがな。
> 社会の荒波にもまれる事もなく、学生から公務員と言う道のりを歩んだ人らしいので、
> バブル経済の深い事なんぞ解らないのも無理がないんですけどね・・・
大学院＝社会の荒波にもまれる事がないという偏見はいかがなものか。
転職を繰り返す機会が無く一社に凝り固まる香具師らには会社というものがどういうところなのか、
実感がわかないものだろうがな。
> こんな人が教師をやってるので、その下で学ぶ私たち学生がバブルのことなんて解るはずありません。
> バブルを知らない「今の少年」である私に、
何の教科を教えている教師だ？ 俺はバブル時代に小学生だったので
俺もなぜバブル崩壊になったか詳しく正確に答えることができない。正確に答えが出るものだとは思えないが。
駅弁大学に行って一番役立ったのは、同じクラスの友人たちが主要メーカーに
就職したことだな。得がたい人脈になった。
就職したことだな。得がたい人脈になった。
>>141
確かに職種にもよるだろうけど、
Javaみたいにフレームワークの流行り廃りが激しい業界においては
やっぱり大学でそこまでサポートすることは不可能なんだし、
もうちょい基礎のレイヤを教えるべきだろ。
どうも、おまいは大卒は役立たずって言葉に過剰反応してるみたいだけど、
俺の周りには尊敬できる専門卒が居るからこそそういう考え方ができるのかもしれないな。
俺の周りは専門卒は大卒をひがまないし大卒は専門卒を尊敬している奴らばかりだ。
もっとも、俺の見立てによると
専門卒→実装技術・効率にこだわる。秀丸が主。
大学卒→ロジックにこだわる。emacs,vi上がりのeclipse。
院卒→はさらに上の抽象レイヤで語りたがるが残念ながら話が独善的になりがちで、
彼の知性に対する信奉者が居ないと実現が難しい事をよく言う。意外とテストとかは適当。
excel,powerpoint
っていう傾向が多々見受けられる。
確かに職種にもよるだろうけど、
Javaみたいにフレームワークの流行り廃りが激しい業界においては
やっぱり大学でそこまでサポートすることは不可能なんだし、
もうちょい基礎のレイヤを教えるべきだろ。
どうも、おまいは大卒は役立たずって言葉に過剰反応してるみたいだけど、
俺の周りには尊敬できる専門卒が居るからこそそういう考え方ができるのかもしれないな。
俺の周りは専門卒は大卒をひがまないし大卒は専門卒を尊敬している奴らばかりだ。
もっとも、俺の見立てによると
専門卒→実装技術・効率にこだわる。秀丸が主。
大学卒→ロジックにこだわる。emacs,vi上がりのeclipse。
院卒→はさらに上の抽象レイヤで語りたがるが残念ながら話が独善的になりがちで、
彼の知性に対する信奉者が居ないと実現が難しい事をよく言う。意外とテストとかは適当。
excel,powerpoint
っていう傾向が多々見受けられる。
大学でCやJava教えたのが、業界で流行った理由にされてる。。。。
148 ：仕様書無しさん：2006/01/07(土) 01:15:38
だいたい大学の情報系学部でプログラムを教えるのは、研究室に入ったときに
困らないようにするというのがメインの理由だろ。
学生が研究室に配属されたりしないような大学ではどうかは知らないけど。
困らないようにするというのがメインの理由だろ。
学生が研究室に配属されたりしないような大学ではどうかは知らないけど。
>>147
nanncyattekundakarane
nanncyattekundakarane
150 ：仕様書無しさん：2006/01/07(土) 05:39:10
それなんてエロゲ？
151 ：仕様書無しさん：2006/01/07(土) 08:06:45
Javaは重い。全然使えない。
本気であれを納める気なんだろうか。
逃げたい
本気であれを納める気なんだろうか。
逃げたい
152 ：仕様書無しさん：2006/01/07(土) 10:38:25
>>151
どのぐらい遅いか実例で示してくださいな
どのぐらい遅いか実例で示してくださいな
>>146
> やっぱり大学でそこまでサポートすることは不可能なんだし、
> もうちょい基礎のレイヤを教えるべきだろ。
大学は基礎しか教えないところだと聞いているが。
フレームワークのことを教えている大学なんて聞いたことがない。
フレームワークの研究をしている者ならいないことはないが。
> 専門卒→実装技術・効率にこだわる。秀丸が主。
> 大学卒→ロジックにこだわる。emacs,vi上がりのeclipse。
> 院卒→はさらに上の抽象レイヤで語りたがるが残念ながら話が独善的になりがちで、
> 彼の知性に対する信奉者が居ないと実現が難しい事をよく言う。意外とテストとかは適当。
おいおい、博士号取得者を除いて院卒と大卒っていったってたった二年ほどの差しかないだろ。
それにすべての院卒がソフトウェア工学を専攻していたとは限らない。
画像工学にやたらと詳しい奴がいるかと思えばネットワークのことにやたらと詳しい、
と思えば他の奴はセキュリティのことに詳しい、
(で、それぞれは自分の分野以外についてはほとんどまったくしらないというケース)
とかそういう専門領域に特化した香具師が多いと思った方がいいぞ。研究室の先生に厳しく扱かれて
研究している香具師が多いからな。
> やっぱり大学でそこまでサポートすることは不可能なんだし、
> もうちょい基礎のレイヤを教えるべきだろ。
大学は基礎しか教えないところだと聞いているが。
フレームワークのことを教えている大学なんて聞いたことがない。
フレームワークの研究をしている者ならいないことはないが。
> 専門卒→実装技術・効率にこだわる。秀丸が主。
> 大学卒→ロジックにこだわる。emacs,vi上がりのeclipse。
> 院卒→はさらに上の抽象レイヤで語りたがるが残念ながら話が独善的になりがちで、
> 彼の知性に対する信奉者が居ないと実現が難しい事をよく言う。意外とテストとかは適当。
おいおい、博士号取得者を除いて院卒と大卒っていったってたった二年ほどの差しかないだろ。
それにすべての院卒がソフトウェア工学を専攻していたとは限らない。
画像工学にやたらと詳しい奴がいるかと思えばネットワークのことにやたらと詳しい、
と思えば他の奴はセキュリティのことに詳しい、
(で、それぞれは自分の分野以外についてはほとんどまったくしらないというケース)
とかそういう専門領域に特化した香具師が多いと思った方がいいぞ。研究室の先生に厳しく扱かれて
研究している香具師が多いからな。
154 ：仕様書無しさん：2006/01/07(土) 12:47:38
Javaで遅いプログラム作る奴はCとかアセンブリでも遅いプログラム作るな
そもそも組めません
> excel,powerpoint
何が言いたいのか？
>>146
> >>141
> 専門卒→実装技術・効率にこだわる。秀丸が主。
秀丸は極端だなw Emacs使った方がまだまだ開発効率よさげに見えるが。
> 大学卒→ロジックにこだわる。emacs,vi上がりのeclipse。
viとEclipseとじゃまったくものが違うだろう。
viからEclipseに移行したばかりというならそいつはほとんどEclipseを
使いこなしていない可能性があるわな。
うちのとこの研究室じゃEmacsどころかEclipseすら知らない香具師らが多いがな。
MATLABという言語を使っているだけだからな。
> >>141
> 専門卒→実装技術・効率にこだわる。秀丸が主。
秀丸は極端だなw Emacs使った方がまだまだ開発効率よさげに見えるが。
> 大学卒→ロジックにこだわる。emacs,vi上がりのeclipse。
viとEclipseとじゃまったくものが違うだろう。
viからEclipseに移行したばかりというならそいつはほとんどEclipseを
使いこなしていない可能性があるわな。
うちのとこの研究室じゃEmacsどころかEclipseすら知らない香具師らが多いがな。
MATLABという言語を使っているだけだからな。
158 ：仕様書無しさん：2006/01/07(土) 12:56:41
> 院卒→はさらに上の抽象レイヤで語りたがるが残念ながら話が独善的になりがちで、
その院卒はいったいどんな専攻でどんな研究をして来た香具師なんだ。
院卒でなくても独善的な香具師はいくらでもいる。
院卒をかたくなに否定するのではなく
まずそいつがどんな学会にどんな論文を書いてきたかを良く見ることだ。
それでその院卒の評価を詳しく知ることができる。
> 彼の知性に対する信奉者が居ないと実現が難しい事をよく言う。意外とテストとかは適当。
大学じゃテストなんて教わらないからな。
もう独学しかない。必死にアジャイル開発やeXtreme Programming、JUnit, Cactusなどの本を読みあさった。
大学は研究室によってはソフトウェア工学のことなんかろくに考えていないところが多い。
なぜなら、ただデータの解析が目的だからな。デジタル信号処理をつかってるところなんてそんなもんだ。
ただただひたすら畳み込み、フーリエ変換などを使ってフィルタを作っているだけだ。
学会に論文を出すことを最重要視している者が多い。数学だけはできるがソフトウェアのことは
ろくに知らないと言う香具師が多い。まず彼らにオブジェクト指向といってもさっぱり理解できないだろう。
159 ：仕様書無しさん：2006/01/07(土) 13:47:14
誤解のないように言っておきたいが、
俺は高卒や大卒や院卒をランク分けや否定してるわけじゃないぞ。
あくまで俺の職場では出身でそのような傾向があると言いたいだけだ。
>>158
>> 院卒→はさらに上の抽象レイヤで語りたがるが残念ながら話が独善的になりがちで、
>その院卒はいったいどんな専攻でどんな研究をして来た香具師なんだ。
さぁ？専門までは知らないよ。ただ、人間的にそういう奴が多いってだけ。
一つのジャンルに対して造詣があるだけで自分を万能視してしまう傾向があるのかな。
院卒は確かにエレガントな設計をする奴が多いんだが
「待ってくれ、実装メンバーの知性ももう少し考慮してくれ('A`)」
という状況によく陥るんだ。
俺は高卒や大卒や院卒をランク分けや否定してるわけじゃないぞ。
あくまで俺の職場では出身でそのような傾向があると言いたいだけだ。
>>158
>> 院卒→はさらに上の抽象レイヤで語りたがるが残念ながら話が独善的になりがちで、
>その院卒はいったいどんな専攻でどんな研究をして来た香具師なんだ。
さぁ？専門までは知らないよ。ただ、人間的にそういう奴が多いってだけ。
一つのジャンルに対して造詣があるだけで自分を万能視してしまう傾向があるのかな。
院卒は確かにエレガントな設計をする奴が多いんだが
「待ってくれ、実装メンバーの知性ももう少し考慮してくれ('A`)」
という状況によく陥るんだ。
161 ：仕様書無しさん：2006/01/07(土) 14:31:34
今の若者に技術者はいない
163 ：仕様書無しさん：2006/01/07(土) 14:53:16
エレガントと独善を混同しているでそ
>>161
まぁ、確かにそうなんだけどね…。
「ここはストラテジパタンで状態を保持して、
ここはこのインタフェイスを導入してどのクラスも透過的に扱えるように…」
とか言い出すと、うちの新人PGは
( ﾟДﾟ)ﾎﾟｶｰﾝ
ってなる。理解できる奴も居ることは居るんだができない奴も居る。
はっきり言って、向上心のないPGには辞めて欲しい気もするが
向上心あふれるPGはなんか他人に対する態度が高圧的で、こいつらだけだと…って感じ。
まぁ、確かにそうなんだけどね…。
「ここはストラテジパタンで状態を保持して、
ここはこのインタフェイスを導入してどのクラスも透過的に扱えるように…」
とか言い出すと、うちの新人PGは
( ﾟДﾟ)ﾎﾟｶｰﾝ
ってなる。理解できる奴も居ることは居るんだができない奴も居る。
はっきり言って、向上心のないPGには辞めて欲しい気もするが
向上心あふれるPGはなんか他人に対する態度が高圧的で、こいつらだけだと…って感じ。
そりゃまたパープリンな会社だな
ちゃんと世話してやれ。
デザパタが理解できりゃある程度使い物になるだろう。
デザパタが理解できりゃある程度使い物になるだろう。
>>163
「この先進的な設計で作るのが最適なんだ！分らん奴は勉強しろ」
↑エレガントかつ独善な設計。設計意図が十分に伝わらずデスマに突入。
「みんながそんな複雑なコード読めるわけじゃないから多少のコピペは許してあげようね」
↑みんな仲良く協調的にデスマに突入。
「この先進的な設計で作るのが最適なんだ！分らん奴は勉強しろ」
↑エレガントかつ独善な設計。設計意図が十分に伝わらずデスマに突入。
「みんながそんな複雑なコード読めるわけじゃないから多少のコピペは許してあげようね」
↑みんな仲良く協調的にデスマに突入。
コピペがデスマを産むわけではないぞ。
デスマがコピペを産むのは間違いないが。
デスマがコピペを産むのは間違いないが。
ウチのJavaマンセーPLはバブル世代です。
デザパタのせいでJavaは遅い
>>170
それはないと思う
それはないと思う
ﾁﾝｸﾞﾙﾄﾝ最強伝説
クラス名はWorld
シングルトンは唯一DQNでも理解可能だというだけであれだけ広まったと思える。
シングルトン使う奴はやばい
じゃ、代わりに何使うよ。
デザパタなど覚えずともよいソフトは作れる
178 ：仕様書無しさん：2006/01/07(土) 17:45:44
つか、デザパタ知らなくても、センスのあるプログラマなら自然と
デザパタそっくりなイディオムをいつの間にか自分で編み出して
使っていたりするものだ。
デザパタそっくりなイディオムをいつの間にか自分で編み出して
使っていたりするものだ。
>>102
> どうせ Java でもファイルやネットワーク接続とかは自前で close しないと
> いけないぢゃん。
データソース使え。
それからJakarta Commons DbUtilsも使え。
> どうせ Java でもファイルやネットワーク接続とかは自前で close しないと
> いけないぢゃん。
データソース使え。
それからJakarta Commons DbUtilsも使え。
181 ：仕様書無しさん：2006/01/07(土) 18:13:52
デザパタの意義がわかってない椰子ほど
デザパタをくさすのはなんでだろうな
デザパタをくさすのはなんでだろうな
自分でちょっと効率いい実装考えたら思いつくことだからだろ
>>160
> >>158
> >> 院卒→はさらに上の抽象レイヤで語りたがるが残念ながら話が独善的になりがちで、
> >その院卒はいったいどんな専攻でどんな研究をして来た香具師なんだ。
> さぁ？専門までは知らないよ。ただ、人間的にそういう奴が多いってだけ。
> 一つのジャンルに対して造詣があるだけで自分を万能視してしまう傾向があるのかな。
っていかなめんなよお前。院卒をまとめて皆そんな「独善的」で自惚れた奴と一緒にするな。
その偏見がムカツクわい。
> 院卒は確かにエレガントな設計をする奴が多いんだが
> 「待ってくれ、実装メンバーの知性ももう少し考慮してくれ('A`)」
> という状況によく陥るんだ。
やっぱり否定してるんじゃないか。
実装メンバーの知性？ ようは馬鹿にもわかりやすくしろってことだな。
院卒でも本当に賢い奴はちゃんと馬鹿にもわかりやすいようにことを説明することができる。
それを勘違いして専門用語がちょっとでただけで逆ギレする変わった奴もいるがな。
逆ギレしないでその場で質問をすればいいだけのことなんだがそれができない奴が
院生や院卒に対して必死に牙をむけようとする。
自分は学生をやめて就職せざるをえなかったのに院生や院卒が、今でも
学生を続けていられることを羨ましく思って噛みついてくる馬鹿社員もいるがな。
> >>158
> >> 院卒→はさらに上の抽象レイヤで語りたがるが残念ながら話が独善的になりがちで、
> >その院卒はいったいどんな専攻でどんな研究をして来た香具師なんだ。
> さぁ？専門までは知らないよ。ただ、人間的にそういう奴が多いってだけ。
> 一つのジャンルに対して造詣があるだけで自分を万能視してしまう傾向があるのかな。
っていかなめんなよお前。院卒をまとめて皆そんな「独善的」で自惚れた奴と一緒にするな。
その偏見がムカツクわい。
> 院卒は確かにエレガントな設計をする奴が多いんだが
> 「待ってくれ、実装メンバーの知性ももう少し考慮してくれ('A`)」
> という状況によく陥るんだ。
やっぱり否定してるんじゃないか。
実装メンバーの知性？ ようは馬鹿にもわかりやすくしろってことだな。
院卒でも本当に賢い奴はちゃんと馬鹿にもわかりやすいようにことを説明することができる。
それを勘違いして専門用語がちょっとでただけで逆ギレする変わった奴もいるがな。
逆ギレしないでその場で質問をすればいいだけのことなんだがそれができない奴が
院生や院卒に対して必死に牙をむけようとする。
自分は学生をやめて就職せざるをえなかったのに院生や院卒が、今でも
学生を続けていられることを羨ましく思って噛みついてくる馬鹿社員もいるがな。
>>164
> 向上心あふれるPGはなんか他人に対する態度が高圧的で、こいつらだけだと…って感じ。
だったら新人をちゃんと教育すればいいだろうが。
高圧的？ 大学の研究室の教官が非常に高圧的だと
それに合わせてその研究室の学生も自然と高圧的な性格になるという
現象はよく起こっている。だがそこで新人が専門知識があるやつを
恨んでも物事は先には進まん。「わからないことがあったら即聞け」これだ。
新人はわからないことがあってもろくに聞くことができずわかったフリをする傾向があるので
不満があるならそれをしっかりとお前が教育しろ。
> 向上心あふれるPGはなんか他人に対する態度が高圧的で、こいつらだけだと…って感じ。
だったら新人をちゃんと教育すればいいだろうが。
高圧的？ 大学の研究室の教官が非常に高圧的だと
それに合わせてその研究室の学生も自然と高圧的な性格になるという
現象はよく起こっている。だがそこで新人が専門知識があるやつを
恨んでも物事は先には進まん。「わからないことがあったら即聞け」これだ。
新人はわからないことがあってもろくに聞くことができずわかったフリをする傾向があるので
不満があるならそれをしっかりとお前が教育しろ。
>>167
> >>163
> 「この先進的な設計で作るのが最適なんだ！分らん奴は勉強しろ」
> ↑エレガントかつ独善な設計。設計意図が十分に伝わらずデスマに突入。
>
> 「みんながそんな複雑なコード読めるわけじゃないから多少のコピペは許してあげようね」
> ↑みんな仲良く協調的にデスマに突入。
どっちも最悪じゃねえか。
前者を理由にすべての院卒を否定して偏見を持つのはどうかと思うが。
本当に能力がある奴はわからない奴にもわかるように説明する。
そんな高圧的なことはしない。大学の教官には高圧的な者が多く
そこで厳しく教授に叱られながらしごかれてきた院生が少なからずいるのは確かだが。
> >>163
> 「この先進的な設計で作るのが最適なんだ！分らん奴は勉強しろ」
> ↑エレガントかつ独善な設計。設計意図が十分に伝わらずデスマに突入。
>
> 「みんながそんな複雑なコード読めるわけじゃないから多少のコピペは許してあげようね」
> ↑みんな仲良く協調的にデスマに突入。
どっちも最悪じゃねえか。
前者を理由にすべての院卒を否定して偏見を持つのはどうかと思うが。
本当に能力がある奴はわからない奴にもわかるように説明する。
そんな高圧的なことはしない。大学の教官には高圧的な者が多く
そこで厳しく教授に叱られながらしごかれてきた院生が少なからずいるのは確かだが。
>>159
たしかにそういう卑怯な手をつかっておいしいおもいをした馬鹿は多い。
そういう奴は就職してもうまくいかないもんだ。
プログラマなんて向いていない。
それ以外の仕事も向いていない。
カンニングや自分の仕事を他人にばかりやらせるような奴には
どんな仕事も向いていないわな。
たしかにそういう卑怯な手をつかっておいしいおもいをした馬鹿は多い。
そういう奴は就職してもうまくいかないもんだ。
プログラマなんて向いていない。
それ以外の仕事も向いていない。
カンニングや自分の仕事を他人にばかりやらせるような奴には
どんな仕事も向いていないわな。
しかし、バブル世代って聞くと
「ハッハー、どんな重いプログラムもハイスペックでごり押せば動くさ！」
みたいな物量作戦なJavaがぴったりに思えるんだが、そうでもないのかな。
「ハッハー、どんな重いプログラムもハイスペックでごり押せば動くさ！」
みたいな物量作戦なJavaがぴったりに思えるんだが、そうでもないのかな。
バブル世代はそんな重いコーディングはしないぞ
バブル世代が大学生だった頃はC言語がブームだった。
雑誌は、各メーカのコンパイラのベンチマークをし、出力するアセンブル
ソースをみて優劣を競ってた。
最適化性能がゴージャスなCコンパイラは望むが、肥満体の言語は好まない。
雑誌は、各メーカのコンパイラのベンチマークをし、出力するアセンブル
ソースをみて優劣を競ってた。
最適化性能がゴージャスなCコンパイラは望むが、肥満体の言語は好まない。
LispやSmalltalkですら実用的なWebアプリが作れる時代にJavaがそんなに遅いわけねーだろ。
マシンが速くなったからJavaが速いなどという勘違いをする。
まぁ、問題がおきないならそれでいいじゃん。
OracleのインストーラだのDB管理ツールだのは、アフォみたいにもっさり
してるけどな。
あれって、Javaが糞なの？それとも設計？
してるけどな。
あれって、Javaが糞なの？それとも設計？
あれはどうみても設計
そこらのJava厨が作ってもあそこまでもっさりにはなかなかできない
Oracleはよほどひどいところに外注したね
そこらのJava厨が作ってもあそこまでもっさりにはなかなかできない
Oracleはよほどひどいところに外注したね
あれ自社開発じゃなくて外注なんだ。
意外にSunが作ってたりしてなｗ
意外にSunが作ってたりしてなｗ
Judeとかハイスペックマシンでもめちゃくちゃ重くないか？
最初スパイウェアでも入っているのかと思った。
最初スパイウェアでも入っているのかと思った。
197 ：仕様書無しさん：2006/01/09(月) 16:21:10
あれでJavaクライアントは使えないって評価が一気に広がったしな。
Oracle8付属のJVMはPen4で使えなかったり、Oracleは無茶苦茶。
Oracle8付属のJVMはPen4で使えなかったり、Oracleは無茶苦茶。
198 ：仕様書無しさん：2006/01/09(月) 16:30:26
おいおい、そこらのJava厨が作ったら起動が明日までかかっちゃうぜw
>>198
Oracleの人？乙です
Oracleの人？乙です
>>198
そんならまず設計を疑えよｗ
そんならまず設計を疑えよｗ
>>200
その前にJavaを疑ってみてはどうだろうか？
その前にJavaを疑ってみてはどうだろうか？
Java厨は、Javaは多少は遅いことを認めればいいと思う。
アンチJava厨は、Javaでも設計次第ではそれなりに
速く動くことを認めればいいと思う。
アンチJava厨は、Javaでも設計次第ではそれなりに
速く動くことを認めればいいと思う。
お前バカだろ？
何でわかった？
VM間に挟んでる時点で他に一歩劣るのはしょうがなくね？
特に直接のUI書く必要あるならお呼びじゃない
C++？自分でメモリ開放しないといけないような低級言語もお呼びじゃない。
Javaでネイティブコードを作れるとかって記事をどこかで見た気がするんだがどこいったんだろ？
やっぱ現実的じゃないのか？
特に直接のUI書く必要あるならお呼びじゃない
C++？自分でメモリ開放しないといけないような低級言語もお呼びじゃない。
Javaでネイティブコードを作れるとかって記事をどこかで見た気がするんだがどこいったんだろ？
やっぱ現実的じゃないのか？
>>205 みたいなのは無知の無知、とでもいうのだろうか。
むっちむちなんだよ！
208 ：仕様書無しさん：2006/01/15(日) 12:35:29
JNI のオーバーヘッドは考えなくていいのかしら。
Javaってバブル期の産物じゃね？
>>208
JETとか、GCJとかを言ってるんじゃないのか？
JETとか、GCJとかを言ってるんじゃないのか？
212 ：仕様書無しさん：2006/01/15(日) 17:13:10
ネイティブでコンパイルされた言語と比べたら、オーバーヘッドあるのは当たり前
むしろJavaにそこまで求める事自体間違ってる
むしろJavaにそこまで求める事自体間違ってる
いや、だからC/C++とJavaは土俵が違うと言ってるのに、わかってない厨がいるから
土俵が同じだったらどっちか片方はもう無くなってるだろ
言語の数だけ土俵があるんだと思うぞ
言語の数だけ土俵があるんだと思うぞ
そそ。pascalみたいに。
このまえJETでネイティブなSWTアプリ作ったけど、
簡易なものだったので取り立てて重さは感じなかった。
Swingだとさすがに、ひっかかるような重さを感じる。
簡易なものだったので取り立てて重さは感じなかった。
Swingだとさすがに、ひっかかるような重さを感じる。
アセンブラが殆ど使われなかったのもCとかぶったからだよな。
プロセッサの処理能力が低かった頃は最終チューニング手段としてまだ
残ってたけど、今の処理能力じゃぶっちゃけ不要。
PICとかH8ならまだ必要かもだけど。
プロセッサの処理能力が低かった頃は最終チューニング手段としてまだ
残ってたけど、今の処理能力じゃぶっちゃけ不要。
PICとかH8ならまだ必要かもだけど。
10年以上前の話しだが、知り合いがパフォーマンスあげる為に
Cからアセンブラ出力して、一生懸命手動で最適化していた姿を思い出した。
Cからアセンブラ出力して、一生懸命手動で最適化していた姿を思い出した。
て言うか仕事があるならJavaでもVBでもなんでもいいじゃん
て言うか仕事があるならRubyでもHSPでもなんでもいいじゃん
RubyやPerlやHSPはメンテが嫌だな
メンテは統合開発環境次第な気もするな
224 ：仕様書無しさん：2006/01/21(土) 18:44:24
225 ：仕様書無しさん：2006/01/21(土) 18:48:09
>>210
Javaは日本で生まれたものではありません。
よってバブル期の産物ではありません。
残念でした。
バブル期の産物とはバブル世代が生み出した偏った思考、
偏見、未だに捨てきれない過去の執着、つまり最適化厨のことです。
バブルは最適化厨を生み出してしまった。
最適化厨は無駄に極度に最適化することにこだわり
一ヶ所を修正すると他所にまで悪影響を与える。
そんな程度の人間なのです。
Javaは日本で生まれたものではありません。
よってバブル期の産物ではありません。
残念でした。
バブル期の産物とはバブル世代が生み出した偏った思考、
偏見、未だに捨てきれない過去の執着、つまり最適化厨のことです。
バブルは最適化厨を生み出してしまった。
最適化厨は無駄に極度に最適化することにこだわり
一ヶ所を修正すると他所にまで悪影響を与える。
そんな程度の人間なのです。
226 ：仕様書無しさん：2006/01/21(土) 18:49:49
227 ：仕様書無しさん：2006/01/21(土) 19:04:24
>>223
型の概念がアバウトな言語はメンテナンスがしづらい。
とくにオブジェクト指向言語になってない言語はメンテナンスがしずらい。
それから「オブジェクト指向設計の原則」「Design by Contract(契約による設計)」
を守ることができない言語もメンテナンスがしずらい。
もちろん、オブジェクト指向言語であってもオブジェクト指向の特性を
生かし切れていないコードのメンテナンスはしずらいのは確かだが。
だがJavaのような言語は他人のコードをリファクタリングしやすい。
他人が書いたコードを訂正し重複した無駄な変数やメソッド、クラスを
除去して整理整頓ともいえることを行うことも容易。
型の概念がアバウトな言語はメンテナンスがしづらい。
とくにオブジェクト指向言語になってない言語はメンテナンスがしずらい。
それから「オブジェクト指向設計の原則」「Design by Contract(契約による設計)」
を守ることができない言語もメンテナンスがしずらい。
もちろん、オブジェクト指向言語であってもオブジェクト指向の特性を
生かし切れていないコードのメンテナンスはしずらいのは確かだが。
だがJavaのような言語は他人のコードをリファクタリングしやすい。
他人が書いたコードを訂正し重複した無駄な変数やメソッド、クラスを
除去して整理整頓ともいえることを行うことも容易。
なんで？
229 ：仕様書無しさん：2006/01/21(土) 20:29:12
もうっこうなったらバブル世代を更生して根性をたたき直すしかないな。
時代遅れなあの連中どもにしっかりとJava教育を施してやらなければならん
時代遅れなあの連中どもにしっかりとJava教育を施してやらなければならん
ｳﾙｾｴ小僧。
つーか、バブル世代がJavaに乗った口じゃないの？
入社コボル→Javaに逝こう。
入社コボル→Javaに逝こう。
COBOLはもっと上の世代だろ
>>229
別に叩き落さなくてもJavaを馬鹿にしている連中は勝手に落ちていくでしょ。
生産性って彼らには全然理解できない概念かもしれないけど開発効率はアップするから勝手に実績で差がついていくだけだ。
別に叩き落さなくてもJavaを馬鹿にしている連中は勝手に落ちていくでしょ。
生産性って彼らには全然理解できない概念かもしれないけど開発効率はアップするから勝手に実績で差がついていくだけだ。
開発効率が良いというけど、なんか無茶なユーザ要求に対応しきれなくなって
開発効率がハゲ落ちたというケースをがあるねえ。
開発効率がハゲ落ちたというケースをがあるねえ。
>>235
無論可能な限り避けるべきだけど、蛮勇を奮ってやらにゃならん時があるんだが、
その辺りの空気読まずに流して、結局ユーザに切られると。
・・・というか、最近元々Javaの案件だけど仕様変わらず別言語ってケース多いの気のせい？
Java→VBが多いので最近はVBも馬鹿にできないなってオモットル。
無論可能な限り避けるべきだけど、蛮勇を奮ってやらにゃならん時があるんだが、
その辺りの空気読まずに流して、結局ユーザに切られると。
・・・というか、最近元々Javaの案件だけど仕様変わらず別言語ってケース多いの気のせい？
Java→VBが多いので最近はVBも馬鹿にできないなってオモットル。
つまり影響度としては
プロジェクトの開発効率＞＞＞＞＞言語の開発効率ということだな。
233が主張するように「勝手に実績で差がついていく」状態には
到底ならないだろうと推測出来る。
プロジェクトの開発効率＞＞＞＞＞言語の開発効率ということだな。
233が主張するように「勝手に実績で差がついていく」状態には
到底ならないだろうと推測出来る。
238 ：仕様書無しさん：2006/01/21(土) 22:41:19
またJAVA厨があほな事いってるのかw
Javaが切られるケースとして、古手のオペレータの
おばちゃんの一言「使い勝手がねぇ・・・」というケースがある。
最近、NT４→XP移行時期でそういう声が多い。
正直JavaのUIってそんな悪い？
おばちゃんの一言「使い勝手がねぇ・・・」というケースがある。
最近、NT４→XP移行時期でそういう声が多い。
正直JavaのUIってそんな悪い？
webだからね
241 ：仕様書無しさん：2006/01/21(土) 23:08:49
いまどきスマートクライアントじゃないとねー
GISみたいなのははなから不可能だけどな
VBというかC#だな
VB6.0はもう終わった言語だよ
VB6.0はもう終わった言語だよ
オフコンのシステムをWebでリプレースするのは正直、評判が悪い。
操作性が変わりすぎる。
VBのC/Sもそういうところに苦労したのだけど、なんせあっちのほうが柔軟性が
あるだけに顧客の要望に応じるのは比べ物にならないほど楽。
操作性が変わりすぎる。
VBのC/Sもそういうところに苦労したのだけど、なんせあっちのほうが柔軟性が
あるだけに顧客の要望に応じるのは比べ物にならないほど楽。
そういうところをWebでリプレースしようとするほうが間違いだろ
>>245
なんでリプレース後のシステムアーキテクチャでいまだに
Webアプリベースが採用されるのか、よくわかりません。
日本の上流SEは前例主義のアホしかいないっつーことでしょうか。
東証とNY証の比較とか、銀行システムのダウン騒ぎとか、最近大手SE
の開発成果って恥かしいのばっかりだけど、多分個々の技術者が拝金主義
無責任無思考になっているんじゃねーかと思う今日この頃。
なんでリプレース後のシステムアーキテクチャでいまだに
Webアプリベースが採用されるのか、よくわかりません。
日本の上流SEは前例主義のアホしかいないっつーことでしょうか。
東証とNY証の比較とか、銀行システムのダウン騒ぎとか、最近大手SE
の開発成果って恥かしいのばっかりだけど、多分個々の技術者が拝金主義
無責任無思考になっているんじゃねーかと思う今日この頃。
結局、見栄えなんだよな。
中身はよほどアホやらなきゃ実際はそんな開発効率の差は無い。
あったとしてもそれなりに経験積めばあっさり埋めれる。
顧客の要望もWardやExcelを引用して言ってくるんで結局VBとかC♯の
方がやりやすい。
中身はよほどアホやらなきゃ実際はそんな開発効率の差は無い。
あったとしてもそれなりに経験積めばあっさり埋めれる。
顧客の要望もWardやExcelを引用して言ってくるんで結局VBとかC♯の
方がやりやすい。
249 ：69式フリーPG ◆hND3Lufios ：2006/01/21(土) 23:32:27
凄腕オペレータがいて、キー操作が身体になじんでたりするのよ。
もう、本当に凄まじく速い。
ぶっちゃけ、おいらも"delete"キーでキャンセル操作するアプリを組んだことあります。
（前のオフコンがその辺りのキーでやってたらしい。）
もう、本当に凄まじく速い。
ぶっちゃけ、おいらも"delete"キーでキャンセル操作するアプリを組んだことあります。
（前のオフコンがその辺りのキーでやってたらしい。）
いつのまにか比較対象がC++からVB、C#に移行している件について
C++との格付けはもう済んだからね
252 ：仕様書無しさん：2006/01/22(日) 00:12:45
おれ、Javaから入って、未だにC言語系やったことないんだが、そんなにスピードがちがうもんなのか？？？？？
>>247
マの技量のランク付けがなされてないのも一因かも。
個々のPMの頭の中では、誰が優秀か、誰がその案件に精通しているのかって
のはあるんだろけど、それが業界としてシステム化されていない。
だから、人月神話がいつまでものさばり続けるし、でかいプロジェクトでは「質」
も考えずにただ人数ばかり投入するから、穴がぼこぼこ開いちまう。
マの技量のランク付けがなされてないのも一因かも。
個々のPMの頭の中では、誰が優秀か、誰がその案件に精通しているのかって
のはあるんだろけど、それが業界としてシステム化されていない。
だから、人月神話がいつまでものさばり続けるし、でかいプロジェクトでは「質」
も考えずにただ人数ばかり投入するから、穴がぼこぼこ開いちまう。
255 ：仕様書無しさん：2006/01/22(日) 00:37:06
>>252
ＢＣＣでもダウンロードして使ってみたら？
俺はJavaもCもやるけど、Javaはやっぱり遅い。
Javaは言語としては綺麗でライブラリや情報も多くていいけど遅い。
これで速度さえ速ければいいんだけどな〜。
ＢＣＣでもダウンロードして使ってみたら？
俺はJavaもCもやるけど、Javaはやっぱり遅い。
Javaは言語としては綺麗でライブラリや情報も多くていいけど遅い。
これで速度さえ速ければいいんだけどな〜。
遅くねえよ。バカ
低脳乙
258 ：仕様書無しさん：2006/01/22(日) 00:44:14
>>255
ある意味トレードオフだからな。
Java は確かに言語仕様が綺麗だが、それは機械がそのぶんがんがっているということの
裏返しでもあるから。
逆に C/C++ はエレガントさを多少犠牲にする代わりに、深いところを直接いじくり回せる
メリットが出てくる。
ある意味トレードオフだからな。
Java は確かに言語仕様が綺麗だが、それは機械がそのぶんがんがっているということの
裏返しでもあるから。
逆に C/C++ はエレガントさを多少犠牲にする代わりに、深いところを直接いじくり回せる
メリットが出てくる。
配列の範囲をOverしてアクセスするバグを出す癖が直らない同僚が
いるんだが、彼のようなPGがたくさんいることを考えるとJavaで
安全性が高いアプリを組む、というメリットはあるかもな。
言語に守られているPGというのもやだけど。
いるんだが、彼のようなPGがたくさんいることを考えるとJavaで
安全性が高いアプリを組む、というメリットはあるかもな。
言語に守られているPGというのもやだけど。
大規模なシステムで使うTPモニタなどの分野では未だにネイティブで走る
ミドルウェアに圧倒的に負けてると思う。
ミドルウェアに圧倒的に負けてると思う。
最近久し振りにシェルプログラミングをやる羽目になったんだけど、
例外処理機構ないと、異常系考慮するプログラムってとたんに書き
ずらくなるんだと再認識した。
別にJavaでなくてもいいけど、例外処理機構重要ですよ、と。
例外処理機構ないと、異常系考慮するプログラムってとたんに書き
ずらくなるんだと再認識した。
別にJavaでなくてもいいけど、例外処理機構重要ですよ、と。
Javaって勉強しないほうがいいんだろ？
Javaなんかできてもできませんって言っておいたほうがいいんだろ？
Javaなんかできてもできませんって言っておいたほうがいいんだろ？
覚えなくて言い言語は基本的に無いぞ
むしろ色々な言語を知ることで仕事の幅は確実に広がる
むしろ色々な言語を知ることで仕事の幅は確実に広がる
264 ：仕様書無しさん：2006/01/22(日) 13:16:39
265 ：仕様書無しさん：2006/01/22(日) 13:20:41
いろいろな言語、それもできれば Java と Lisp とアセンブラみたいに、
できるだけそれぞれのパラダイムが乖離したものを覚えるとよいな。
プログラミングという行為を一段高いところから見れるようになる。
高校や大学で数学を勉強すると、小学校や中学校で習った簡単な算数や数学が
違った風に見えてきた経験はだれにでもあるでしょ。それに似た感覚。
できるだけそれぞれのパラダイムが乖離したものを覚えるとよいな。
プログラミングという行為を一段高いところから見れるようになる。
高校や大学で数学を勉強すると、小学校や中学校で習った簡単な算数や数学が
違った風に見えてきた経験はだれにでもあるでしょ。それに似た感覚。
Java厨はJava以外勉強しなくていい。
他の言語の速さを知ったら、もうJavaには戻れなくなるから。
他の言語の速さを知ったら、もうJavaには戻れなくなるから。
>>266
大学でOcamlを勉強したけど就職してJavaを使っている俺が来ましたよ
大学でOcamlを勉強したけど就職してJavaを使っている俺が来ましたよ
>>265
そういうことを大学にいるうちにやるべきなんだけどな。
なんかみんなC/C++だけあればいいやってなっちゃうんだよな。
関数型言語とかSmalltalkとか実用じゃないけど覚えたほうがいいものはあるのにな。
そういうことを大学にいるうちにやるべきなんだけどな。
なんかみんなC/C++だけあればいいやってなっちゃうんだよな。
関数型言語とかSmalltalkとか実用じゃないけど覚えたほうがいいものはあるのにな。
javaだけやってろよ
>>270
C++で実作業して、C♯で接着してJavaで・・・何するの？
C++で実作業して、C♯で接着してJavaで・・・何するの？
JAVA厨を演じて遊ぶのです＞＜
まぁ、仕事以外でJavaを役立てるのは難しいなぁ。
C++の案件が減ってきて、Java案件ばかりにまわされるのは辛い。
C++の案件が減ってきて、Java案件ばかりにまわされるのは辛い。
ついでに
VB(6orA)・・・中小企業向け業務アプリ
DBを管理するんじゃなくほぼ単なる保管場所として使う場合なんかだとAccsess+VBAは楽よ
サーバー1台クライアント3台1営業所とか
VB.NETはこのままC#に飲まれたほうが幸せだと思う俺がいる
VB(6orA)・・・中小企業向け業務アプリ
DBを管理するんじゃなくほぼ単なる保管場所として使う場合なんかだとAccsess+VBAは楽よ
サーバー1台クライアント3台1営業所とか
VB.NETはこのままC#に飲まれたほうが幸せだと思う俺がいる
>>227
>型の概念がアバウトな言語はメンテナンスがしづらい。
●疎結合なWebサービスに遅れを取るjava
>とくにオブジェクト指向言語になってない言語はメンテナンスがしずらい。
●XMLサービスはOO+コンポーネント分散協調にも遅れをとるjava
>それから「オブジェクト指向設計の原則」「Design by Contract(契約による設計)」
>を守ることができない言語もメンテナンスがしずらい。
●オブジェクト指向で組むのは今更当たり前なのになぜかjava厨は自分たちしかOOを
●やっていないと勘違いしているのでまた遅れを取るjava
●javaのOOはもうかなり古いのにそれに気づいていなのが痛い
>もちろん、オブジェクト指向言語であってもオブジェクト指向の特性を
>生かし切れていないコードのメンテナンスはしずらいのは確かだが。
●やっつけ派遣業務のコーダさんがすばらしいクラス設計ができるわけがない
●だからメンテしづらいコードばかなのが当たり前なのに何を言ってるのか？
>だがJavaのような言語は他人のコードをリファクタリングしやすい。
●ツールでちゃらっとやるだけで全体を見据えた本質的な解決にはならないんだよ。
●君の言うリファクタリングはそう、エディタでの検索・置換程度
>他人が書いたコードを訂正し重複した無駄な変数やメソッド、クラスを
>除去して整理整頓ともいえることを行うことも容易。
●除去してパフォーマンスが3倍速くなるのであれば君の苦労も報われるのだが
●骨折損のくたびれもうけになるからやめたほうが良いと思うよ。
>型の概念がアバウトな言語はメンテナンスがしづらい。
●疎結合なWebサービスに遅れを取るjava
>とくにオブジェクト指向言語になってない言語はメンテナンスがしずらい。
●XMLサービスはOO+コンポーネント分散協調にも遅れをとるjava
>それから「オブジェクト指向設計の原則」「Design by Contract(契約による設計)」
>を守ることができない言語もメンテナンスがしずらい。
●オブジェクト指向で組むのは今更当たり前なのになぜかjava厨は自分たちしかOOを
●やっていないと勘違いしているのでまた遅れを取るjava
●javaのOOはもうかなり古いのにそれに気づいていなのが痛い
>もちろん、オブジェクト指向言語であってもオブジェクト指向の特性を
>生かし切れていないコードのメンテナンスはしずらいのは確かだが。
●やっつけ派遣業務のコーダさんがすばらしいクラス設計ができるわけがない
●だからメンテしづらいコードばかなのが当たり前なのに何を言ってるのか？
>だがJavaのような言語は他人のコードをリファクタリングしやすい。
●ツールでちゃらっとやるだけで全体を見据えた本質的な解決にはならないんだよ。
●君の言うリファクタリングはそう、エディタでの検索・置換程度
>他人が書いたコードを訂正し重複した無駄な変数やメソッド、クラスを
>除去して整理整頓ともいえることを行うことも容易。
●除去してパフォーマンスが3倍速くなるのであれば君の苦労も報われるのだが
●骨折損のくたびれもうけになるからやめたほうが良いと思うよ。
へくりぷす使ってりゃ考えんでも作れるからな
低脳が増えるわけだ
低脳が増えるわけだ
なんだろう、とても痛い
お前の胸がか
また具体性に欠ける反論だねぇ
どれ
>>276はDIコンテナの必要性を叫んでいるのか？
淘汰されて消えていったと思ってたVB(しかできない)厨が
どこへいったかと思ったらこんなところにいたか
まぁ、確かに開発環境そろえりゃ考えずに作れるからなぁ
Java厨は用意されてないものはできないと言い
C厨は用意されてるものまで無駄に自分で作ろうとする
実際に現場の先輩から聞いた言葉だ
なんつーか「あぁ、なるほど」と思ってしまったよ。
どこへいったかと思ったらこんなところにいたか
まぁ、確かに開発環境そろえりゃ考えずに作れるからなぁ
Java厨は用意されてないものはできないと言い
C厨は用意されてるものまで無駄に自分で作ろうとする
実際に現場の先輩から聞いた言葉だ
なんつーか「あぁ、なるほど」と思ってしまったよ。
>>276
アンチJavaによる凄い妄想だな。
Javaのオブジェクト指向が古い？
あれで古いなら他の原語のオブジェクト指向は
もっと古いわけだが。
Spring Frameworkの話題がちょっと前に出てきて
最近人気があるが、あのフレームワークは
最近では。ＮＥＴ版やPHP版なども登場している。
最初に誰かがJavaで作ってから、他の言語を使っているものが
Javaで作られたフレームワークを真似して自分の使っている
言語に取り入れるというケースが頻発しているぞ。
XMLサービスが遅れをとるって何だw ドトネト厨がよく使う言葉だなw
XMLやWS-BPELはすでにJavaではかなり広く使われているんだが。
アンチJavaによる凄い妄想だな。
Javaのオブジェクト指向が古い？
あれで古いなら他の原語のオブジェクト指向は
もっと古いわけだが。
Spring Frameworkの話題がちょっと前に出てきて
最近人気があるが、あのフレームワークは
最近では。ＮＥＴ版やPHP版なども登場している。
最初に誰かがJavaで作ってから、他の言語を使っているものが
Javaで作られたフレームワークを真似して自分の使っている
言語に取り入れるというケースが頻発しているぞ。
XMLサービスが遅れをとるって何だw ドトネト厨がよく使う言葉だなw
XMLやWS-BPELはすでにJavaではかなり広く使われているんだが。
285 ：仕様書無しさん：2006/02/22(水) 00:58:26
>>283
> 淘汰されて消えていったと思ってたVB(しかできない)厨が
> どこへいったかと思ったらこんなところにいたか
> まぁ、確かに開発環境そろえりゃ考えずに作れるからなぁ
>
> Java厨は用意されてないものはできないと言い
アフォだろお前。Java屋は用意されていなくてもできるものはできるぞ。
さすが誰か見下す対象を作りたがるバブル世代のオッサン的妄想だなw
Apache AntやApache Mavenを自分でダウンロードし、自分でインストールし
自分でbuild.xmlを自作し、自分でpom.xmlを自作して開発効率を高めることができる。
お前はそんなこともわからないのか。
> 淘汰されて消えていったと思ってたVB(しかできない)厨が
> どこへいったかと思ったらこんなところにいたか
> まぁ、確かに開発環境そろえりゃ考えずに作れるからなぁ
>
> Java厨は用意されてないものはできないと言い
アフォだろお前。Java屋は用意されていなくてもできるものはできるぞ。
さすが誰か見下す対象を作りたがるバブル世代のオッサン的妄想だなw
Apache AntやApache Mavenを自分でダウンロードし、自分でインストールし
自分でbuild.xmlを自作し、自分でpom.xmlを自作して開発効率を高めることができる。
お前はそんなこともわからないのか。
286 ：仕様書無しさん：2006/02/22(水) 01:11:13
あんまり読んでないけど、
Java厨とJava屋は別物じゃん。
あと、自分の否定したいものには
とりあえず「厨」つけとけばいいやとでも思ってんのかこのウスラハゲ野郎。
Java厨とJava屋は別物じゃん。
あと、自分の否定したいものには
とりあえず「厨」つけとけばいいやとでも思ってんのかこのウスラハゲ野郎。
Javaはむしろ用意された環境の方がやりにくい罠
正直JDevでやれとか言われると泣きたくなる
正直JDevでやれとか言われると泣きたくなる
288 ：仕様書無しさん：2006/02/22(水) 02:26:54
言語といったらやっぱ日本語ベーシックだよな。
289 ：仕様書無しさん：2006/02/22(水) 05:41:41
っていうか、どっちも使いこなせて月100万稼げれば別にどうでもいいじゃん。
何を無駄に争っているんだあんたらは。
何を無駄に争っているんだあんたらは。
290 ：仕様書無しさん：2006/02/22(水) 08:54:58
>>289
「○○と××どっちが強いか？（偉いか？）」と議論したがるのは男の脳の習性らしいね
vi対Emacs、Java対C#、Linux対FreeBSD、GNOME対KDE…みんなそう。
どっちも使いこなせるのが一番偉いに決まってるじゃないか、
という正論は言っても無駄なのさ
「○○と××どっちが強いか？（偉いか？）」と議論したがるのは男の脳の習性らしいね
vi対Emacs、Java対C#、Linux対FreeBSD、GNOME対KDE…みんなそう。
どっちも使いこなせるのが一番偉いに決まってるじゃないか、
という正論は言っても無駄なのさ
292 ：仕様書無しさん：2006/02/22(水) 12:34:59
>C厨は用意されてるものまで無駄に自分で作ろうとする
これは当たりだなｗ
既存のものより自分で作ったもののほうが優れているはずと
みんな思っているｗ
これは当たりだなｗ
既存のものより自分で作ったもののほうが優れているはずと
みんな思っているｗ
293 ：仕様書無しさん：2006/02/22(水) 13:09:56
>>292
その結果発生する生産性の低さをC言語が高等な技術を要する為と勘違いしてるんだよな
その結果発生する生産性の低さをC言語が高等な技術を要する為と勘違いしてるんだよな
294 ：仕様書無しさん：2006/02/22(水) 13:17:29
デジタルドカタ
295 ：仕様書無しさん：2006/02/22(水) 13:47:58
296 ：仕様書無しさん：2006/02/22(水) 13:53:11
DOSやSunOS時代からの俺様ライブラリの蓄積があるから。
＞あと、自分の否定したいものには
＞とりあえず「厨」つけとけばいいやとでも思ってんのかこのウスラハゲ野郎。
厨でないなら反応しなければいいだけのことだ。
＞とりあえず「厨」つけとけばいいやとでも思ってんのかこのウスラハゲ野郎。
厨でないなら反応しなければいいだけのことだ。
Java厨屋
>>298
派遣企業のことか？ｗ
派遣企業のことか？ｗ
最近のJavaって軽くね？
http://pc8.2ch.net/test/read.cgi/prog/1137836570/
http://pc8.2ch.net/test/read.cgi/prog/1137836570/
Java屋はエンタープライズ屋だ
302 ：仕様書無しさん：2006/02/22(水) 15:55:25
いやビジネスロジック屋だ
ちゃう大規模開発屋だ
304 ：仕様書無しさん：2006/02/22(水) 23:40:45
Javaはほとんどの用途で作りやすいからいいものが作れる
Cは速いものが作れるからピンポイントで使いたい
しかしCで作れるものというのは、そのほとんどが車輪の再開発なんだよな
まとまった規模のものはCでもオブジェクト指向チックになったりするし
Cは速いものが作れるからピンポイントで使いたい
しかしCで作れるものというのは、そのほとんどが車輪の再開発なんだよな
まとまった規模のものはCでもオブジェクト指向チックになったりするし
＞Javaはほとんどの用途で作りやすいからいいものが作れる
はあああああああああああああああああああああああああああああああああああああああ
307 ：仕様書無しさん：2006/02/22(水) 23:58:58
うりゃああああああああああああああああああああああああああああああああああああああああ
308 ：仕様書無しさん：2006/02/23(木) 00:53:21
>>305
事実だが何か？
事実だが何か？
Javaは遅いということでFA？
はいはい、Javaは遅いですね
良かったですね
良かったですね
とても良い事ですよ
312 ：仕様書無しさん：2006/02/23(木) 20:12:22
javaアプレットはとてもいいものです
ブラウザがOSになるんですよ。
この業界の人はね、ガンダム世代なんだよ。
十分に教育受けないうちに戦場に駆り出されて、OJTという自学自習強いられて
ろくでもない大人の確執と世間の矛盾だけ見せ付けられて、
３０にならないうちに世を去っていく。
小理屈より表面的な事実のほうが重いよ。
十分に教育受けないうちに戦場に駆り出されて、OJTという自学自習強いられて
ろくでもない大人の確執と世間の矛盾だけ見せ付けられて、
３０にならないうちに世を去っていく。
小理屈より表面的な事実のほうが重いよ。
315 ：仕様書無しさん：2006/02/25(土) 15:18:13
それちょーうぜーガンヲタやん
ガンヲタのくせにJavaは遅いとかアフォなこと
いってんじゃねえよクソジジイども！
ガンヲタのくせにJavaは遅いとかアフォなこと
いってんじゃねえよクソジジイども！
316 ：仕様書無しさん：2006/02/25(土) 18:46:42
その点、生粋のJava使いはEVA世代だよね。
317 ：仕様書無しさん：2006/02/26(日) 09:57:30
JAVAでDBとアクセスする場合どうしてるの？ JDBC-ODBCブリッチ？orz
318 ：仕様書無しさん：2006/02/26(日) 13:48:05
319 ：仕様書無しさん：2006/02/26(日) 13:49:17
>>317
JDBCのことよくわかってなさそうだな。
Windows限定でAccessにしか接続しないならそのタイプのドライバでもいいが、
OracleやPostgreSQLなどのドライバでは違うタイプのものが必要。
JDBCのことよくわかってなさそうだな。
Windows限定でAccessにしか接続しないならそのタイプのドライバでもいいが、
OracleやPostgreSQLなどのドライバでは違うタイプのものが必要。
OracleやPostgreならJDBCドライバ普通にあるだろ
322 ：仕様書無しさん：2006/02/26(日) 23:40:02
JDBC-ODBCの使い方を忘れてしまったくらいマイナーな機能になりさがったな
323 ：仕様書無しさん：2006/02/27(月) 02:23:22
Javaは遅いままでいい。そのうちコンピュータ自体が速くなるから。
Perlはそれで救われた。
Perlはそれで救われた。
JDBC-ODBCはdbfとかのアクセスにも使えるぞ
まあ、そんなファイルを今時見ることも無いがな
まあ、そんなファイルを今時見ることも無いがな
326 ：仕様書無しさん：2006/02/27(月) 23:57:10
パール
パーラー
パーレスト
パーラー
パーレスト
327 ：仕様書無しさん：2006/03/02(木) 18:38:35
Javaは確かに起動は遅い。
起動した後は最適化されててさいこー。
起動した後は最適化されててさいこー。
328 ：仕様書無しさん：2006/03/02(木) 22:52:08
ぷ
ぷりんとごっこ
こ
こ
330 ：仕様書無しさん：2006/03/02(木) 22:55:47
こまったおそさ
さいじゃく
く
く
くさい○んこ
こ
こ
今度は団塊ジュニア世代がどうだこうだっていわれるときがやってくるのかな
なんで急にそんな話になるんだ
だ
だ
335 ：仕様書無しさん：2006/03/03(金) 13:18:43
>>323
JavaにはコンパイラとJVMがあるから
それらを改変するだけでも高速化を望める。
Javaコンパイラ/JVM開発のスタイルは
まず先に使いやすさを重視して開発し
最適化は後回しにしているって感じだろう。
今までJava標準APIの様子や、今まで遅かった
Mathクラスが突然早くなったこと、1.4.2からぬるぽ処理が
早くなったことからその様子がわかる。
PerlもParrotによってさらに救われるだろおうけど
Perl6の開発の現状があれでは、先が思いやられる。
JavaにはコンパイラとJVMがあるから
それらを改変するだけでも高速化を望める。
Javaコンパイラ/JVM開発のスタイルは
まず先に使いやすさを重視して開発し
最適化は後回しにしているって感じだろう。
今までJava標準APIの様子や、今まで遅かった
Mathクラスが突然早くなったこと、1.4.2からぬるぽ処理が
早くなったことからその様子がわかる。
PerlもParrotによってさらに救われるだろおうけど
Perl6の開発の現状があれでは、先が思いやられる。
以前のバージョンと比較して速い速いといわれてもな
ネイティブには永久にかなわないわけで、
遅い環境をわざわざ使う理由がどこにある？
ネイティブには永久にかなわないわけで、
遅い環境をわざわざ使う理由がどこにある？
337 ：仕様書無しさん：2006/03/03(金) 14:57:07
組み込み系は例外として
最近のコンピュータでは
体感速度ではnativeとかわらないことが
まだわからないのか。
C/C++が従来、最高時速100kmで
Javaが従来、最高時速50kmだったとする。
それが今ではC/C++は最高時速が200km
Javaは最高時速が199.999999kmになった。
たしかに今でもC/C++で作った方が速いが、
時速199.999999kmと時速200kmとで体感速度に
どんな違いがあるというのか。
(そもそもそんなにスピードを出すのはスピード違反だが。)
この程度の違い敷かなければ顧客はもはやJavaでも
満足しているのが現実だ。
何年も前から2chでこういう話が堂々巡りになっているのは
Javaの進化を認めたくないことの現れか？
最近のコンピュータでは
体感速度ではnativeとかわらないことが
まだわからないのか。
C/C++が従来、最高時速100kmで
Javaが従来、最高時速50kmだったとする。
それが今ではC/C++は最高時速が200km
Javaは最高時速が199.999999kmになった。
たしかに今でもC/C++で作った方が速いが、
時速199.999999kmと時速200kmとで体感速度に
どんな違いがあるというのか。
(そもそもそんなにスピードを出すのはスピード違反だが。)
この程度の違い敷かなければ顧客はもはやJavaでも
満足しているのが現実だ。
何年も前から2chでこういう話が堂々巡りになっているのは
Javaの進化を認めたくないことの現れか？
>>337
>何年も前から2chでこういう話が堂々巡りになっているのは
やってみないまま「遅い」としか言わない阿呆と
「場合によっては」とは意図的に言わずにただ「僅差だ」と主張する阿呆が
いるからじゃね？
>何年も前から2chでこういう話が堂々巡りになっているのは
やってみないまま「遅い」としか言わない阿呆と
「場合によっては」とは意図的に言わずにただ「僅差だ」と主張する阿呆が
いるからじゃね？
そのループが楽しい
340 ：仕様書無しさん：2006/03/03(金) 15:12:58
WDMでの記事から
doubleの四則演算
C++ 0.13 秒
Java 2.50秒
19.23倍C++が速い
200kmと
199kmは大嘘
doubleの四則演算
C++ 0.13 秒
Java 2.50秒
19.23倍C++が速い
200kmと
199kmは大嘘
341 ：仕様書無しさん：2006/03/03(金) 15:24:38
>>340
そういう例よりもさ、
より多くの人に利用されているwebアプリを
例にしたほうがいいんじゃないかな。
たとえばブラウザで銀行口座を照会でき、
振り込みできるサービスでよくある○○ダイレクト(○○に入るのは銀行名)。
たとえばみずほダイレクトとか三菱東京UFJダイレクトとか、りそなダイレクトとか
三井住友ダイレクトとかさ。
そういうシステムには主にJava(KStruts)が使われているんだけど、
三井住友ダイレクトを使った感じでは特に不満を感じないね。
果たして、こういうシステムでJava以外の言語を使えば
さらにパフォーマンスが上がって快適になるので銀行利用者が
増えて銀行にとって利益になると銀行が考えるだろうか？
そういうことを考えないと、
ただのパフォーマンス原理主義者になってしまうよ>>336
そういう例よりもさ、
より多くの人に利用されているwebアプリを
例にしたほうがいいんじゃないかな。
たとえばブラウザで銀行口座を照会でき、
振り込みできるサービスでよくある○○ダイレクト(○○に入るのは銀行名)。
たとえばみずほダイレクトとか三菱東京UFJダイレクトとか、りそなダイレクトとか
三井住友ダイレクトとかさ。
そういうシステムには主にJava(KStruts)が使われているんだけど、
三井住友ダイレクトを使った感じでは特に不満を感じないね。
果たして、こういうシステムでJava以外の言語を使えば
さらにパフォーマンスが上がって快適になるので銀行利用者が
増えて銀行にとって利益になると銀行が考えるだろうか？
そういうことを考えないと、
ただのパフォーマンス原理主義者になってしまうよ>>336
342 ：仕様書無しさん：2006/03/03(金) 15:31:41
C/C++いっさいなし、Javaだけで開発されたOS - JNode
http://pcweb.mycom.co.jp/news/2006/03/03/341.html
あははははははははははははははっははははははっははは！！！！！！
http://pcweb.mycom.co.jp/news/2006/03/03/341.html
あははははははははははははははっははははははっははは！！！！！！
343 ：仕様書無しさん：2006/03/03(金) 15:46:07
344 ：仕様書無しさん：2006/03/03(金) 16:04:16
枝番レビジョンに苦労するのか。。
>体感速度ではnativeとかわらないことが
>まだわからないのか。
評価とか効果とかも測ることしないんだろうな。
いいなあ、こんなヌルイこと言ってられるのかJavaのお仕事って。
>まだわからないのか。
評価とか効果とかも測ることしないんだろうな。
いいなあ、こんなヌルイこと言ってられるのかJavaのお仕事って。
もうあれだよ。lessとかgrepとかよく使うコマンドも全部Javaにしちゃおうよ。
>>345
すでに測定済みだが何か
すでに測定済みだが何か
測定した結果、
200kmと199.999999km
だったのです。
200kmと199.999999km
だったのです。
Java屋の俺が言うのもあれだが、それは嘘だろｗ＜200kmが199.9...km
体感的には2倍遅延くらいじゃないかな
しかしグラフィクス処理は速いよ、OS標準APIじゃ相手にならんだろうね
Firefoxや一部Linuxも将来的にはJavaと同じで
レンダリングをビデオカードに頼る方針を固めたほど高い成果をあげている
6.0からはさらに高速化するらしいから期待大
体感的には2倍遅延くらいじゃないかな
しかしグラフィクス処理は速いよ、OS標準APIじゃ相手にならんだろうね
Firefoxや一部Linuxも将来的にはJavaと同じで
レンダリングをビデオカードに頼る方針を固めたほど高い成果をあげている
6.0からはさらに高速化するらしいから期待大
しかしclientモードでないとSwingは動きがカクカクするから
秀丸のような高性能エディタみたいなのは流石に無理かなぁ
アノテーションとかあのへんで
一部機能をserverモードでみたいに出来るようになれば別だけど
秀丸のような高性能エディタみたいなのは流石に無理かなぁ
アノテーションとかあのへんで
一部機能をserverモードでみたいに出来るようになれば別だけど
>>349
Javaが遅くなる原因
・繰り返し処理で使い捨てnewオブジェクトがやたらと多い
・同期処理が不要な部分でHashtableやVectorを使っている
・synchronizedがやたらと多い
・gcを呼び出しまくっている
これらに該当しないプログラムならかなり高速
実際、数値演算のみならネイティブコンパイル言語のフル最適化オプションととほぼ同等で、
CPU毎に最適化されていない場合はJavaの方が早かったりすることもあるくらいだしな
例えばx86系ではネイティブコンパイル言語の殆どがIntelに最適化されたコードを
吐き出す為、AMD系のCPUだとJavaの方が早かったりする
Javaが遅くなる原因
・繰り返し処理で使い捨てnewオブジェクトがやたらと多い
・同期処理が不要な部分でHashtableやVectorを使っている
・synchronizedがやたらと多い
・gcを呼び出しまくっている
これらに該当しないプログラムならかなり高速
実際、数値演算のみならネイティブコンパイル言語のフル最適化オプションととほぼ同等で、
CPU毎に最適化されていない場合はJavaの方が早かったりすることもあるくらいだしな
例えばx86系ではネイティブコンパイル言語の殆どがIntelに最適化されたコードを
吐き出す為、AMD系のCPUだとJavaの方が早かったりする
>>351
>・繰り返し処理で使い捨てnewオブジェクトがやたらと多い
>・同期処理が不要な部分でHashtableやVectorを使っている
>・synchronizedがやたらと多い
>・gcを呼び出しまくっている
今時、こんな奴居るのかｗ
JavaとC++の比較にベンチマーク持ち出す奴が居るがソースを晒さずに何を言ってるのやらって感じだな
ベンチマークほど恣意的な結果を出しやすい物は無いのに
>・繰り返し処理で使い捨てnewオブジェクトがやたらと多い
>・同期処理が不要な部分でHashtableやVectorを使っている
>・synchronizedがやたらと多い
>・gcを呼び出しまくっている
今時、こんな奴居るのかｗ
JavaとC++の比較にベンチマーク持ち出す奴が居るがソースを晒さずに何を言ってるのやらって感じだな
ベンチマークほど恣意的な結果を出しやすい物は無いのに
どっかのスレで出してたな
>>352
C言語厨がJavaをやるとそうなるケースが多い。
とくにSystem.gc()なんかそう。
それから、
・古いJavaしか知らない奴はHashtableやVector, Enumeration, Stackを使いたがる。
・初心者はループ内で無駄にnewするこードを大量に書く傾向にある。
staticにすべきところでせずしなないほうがいいところでstaticに
するのもJava初心者やC言語厨にありがちな特徴。
SingletonパターンやFlyweightパターン、
Lazy Loadingを知らないために無駄にnewして重たくする初心者が多い。
C言語厨がJavaをやるとそうなるケースが多い。
とくにSystem.gc()なんかそう。
それから、
・古いJavaしか知らない奴はHashtableやVector, Enumeration, Stackを使いたがる。
・初心者はループ内で無駄にnewするこードを大量に書く傾向にある。
staticにすべきところでせずしなないほうがいいところでstaticに
するのもJava初心者やC言語厨にありがちな特徴。
SingletonパターンやFlyweightパターン、
Lazy Loadingを知らないために無駄にnewして重たくする初心者が多い。
newがまともに使用できないことをそんなに自慢しなくても。
懸命に語るよなー
ドンだけレベル低い奴やねん
ドンだけレベル低い奴やねん
>>355
おまえが書くソースコードってどんなだろうな。
メモリ食いまくりだろうなw
class A {
Obj obj;
public A(){
if(obj == null ){
pbj = new Obj();
}
}
}
おまえこういうテクニック知らないだろ
おまえが書くソースコードってどんなだろうな。
メモリ食いまくりだろうなw
class A {
Obj obj;
public A(){
if(obj == null ){
pbj = new Obj();
}
}
}
おまえこういうテクニック知らないだろ
んだな
valueOf()
とかgetInstance()とか
に使うのが普通
valueOf()
とかgetInstance()とか
に使うのが普通
361 ：仕様書無しさん：2006/03/04(土) 19:13:26
馬鹿の見本市ですね。
もう一人見本が増えたようです。
わろた、そんなテクニックは知らない。
すっかりブームは終わったよな
365 ：仕様書無しさん：2006/03/05(日) 13:16:55
ｱﾝﾁ君が論破されちゃったからな
いそがし過ぎてアンチできないこのつらさ。
これもJavaが遅いお陰。感謝。
これもJavaが遅いお陰。感謝。
はいはい。遅い遅い。よかったね。
もう、「Javaは重い？だからどうした？」路線で行こうと思う。
重くてもJavaを愛し続ける事ができるJava厨
不細工な妻を愛し続ける事ができるいい人なのかもしれない。。。
不細工な妻を愛し続ける事ができるいい人なのかもしれない。。。
372 ：仕様書無しさん：2006/03/05(日) 13:20:21
不細工ってこれの事？
VBX, DDE（Win3.1or3.0 1993)
↓
NET DDE (Win3.1 1994)
↓
埋め込みしたいなぁ．．．
↓
OLE1.0（DDE使用）
↓
OLE2.0=COM ただし目的はインプレースドキュメント。しかしその背景には本質としてバイナリオブジェクト標準あんどオブジェクト通信の思想あり。この辺で名慮or迷著 InsideOLEあんどIsideOLE2。死者多数。
部品としてVB用のVBX (VB2.0からVB4.0 1995あたり)
↓
COMを使ったOCX (1996あたり）結局コンポーネントビジネスはやんなかったな...
ゲイツがインターネットに熱上げあんどJAVA Appletはやる (1995）
↓
COMつかってActiveX(1996)
だんだんオブジェクトはやってくる。 （UMLなど1997）オブジェクトもでるとしてCOMの宣伝開始 DCOMなどCORBAとがっぷり。この辺でMTSではじめ
↓
マーケティングてきなWindowsDNA 。MTS2.0それなりに使えそう。つか使った。DCOM糞。(1999)
↓
COM+ （Win2000､2000）In-MemoryDBどこいったゴラァ
COM Runtimeの情報漏れ始め (2000〜)
↓
セキュリティ→ファイアーウォールのためCOM全滅。しばらくしてから.NETとしてCOMじゃないものに．．．
↓
.NET流行らず(〜2006)
↓
WinFX完成(2007)
↓
オブジェクトベースプログラミングにより、OSは関数コールに戻る(2008)
WinFX下位互換へ
VBX, DDE（Win3.1or3.0 1993)
↓
NET DDE (Win3.1 1994)
↓
埋め込みしたいなぁ．．．
↓
OLE1.0（DDE使用）
↓
OLE2.0=COM ただし目的はインプレースドキュメント。しかしその背景には本質としてバイナリオブジェクト標準あんどオブジェクト通信の思想あり。この辺で名慮or迷著 InsideOLEあんどIsideOLE2。死者多数。
部品としてVB用のVBX (VB2.0からVB4.0 1995あたり)
↓
COMを使ったOCX (1996あたり）結局コンポーネントビジネスはやんなかったな...
ゲイツがインターネットに熱上げあんどJAVA Appletはやる (1995）
↓
COMつかってActiveX(1996)
だんだんオブジェクトはやってくる。 （UMLなど1997）オブジェクトもでるとしてCOMの宣伝開始 DCOMなどCORBAとがっぷり。この辺でMTSではじめ
↓
マーケティングてきなWindowsDNA 。MTS2.0それなりに使えそう。つか使った。DCOM糞。(1999)
↓
COM+ （Win2000､2000）In-MemoryDBどこいったゴラァ
COM Runtimeの情報漏れ始め (2000〜)
↓
セキュリティ→ファイアーウォールのためCOM全滅。しばらくしてから.NETとしてCOMじゃないものに．．．
↓
.NET流行らず(〜2006)
↓
WinFX完成(2007)
↓
オブジェクトベースプログラミングにより、OSは関数コールに戻る(2008)
WinFX下位互換へ
不細工とか美人とか関係ない
速さだ！
コンピュータ使ってるのに遅かったら意味なし！
速さだ！
コンピュータ使ってるのに遅かったら意味なし！
374 ：仕様書無しさん：2006/03/05(日) 13:20:49
44 名前：仕様書無しさん[] 投稿日：2006/02/27(月) 22:55:42
遅いだと？
だからどうした！！
これがグローバルスタンダードだ。
45 名前：仕様書無しさん[] 投稿日：2006/02/27(月) 23:00:00
まあお前らPC屋に大規模開発の醍醐味はわかろうはずもない！！
46 名前：仕様書無しさん[] 投稿日：2006/02/27(月) 23:01:55
人生はビジネスロジックだ！！
47 名前：仕様書無しさん[sage] 投稿日：2006/02/27(月) 23:03:10
独りで書き込むのは寂しいだろうから俺も書いてやる
48 名前：仕様書無しさん[] 投稿日：2006/02/27(月) 23:20:17
>>44-46
つまらん自作自演だなC言語orドトネト厨
遅いだと？
だからどうした！！
これがグローバルスタンダードだ。
45 名前：仕様書無しさん[] 投稿日：2006/02/27(月) 23:00:00
まあお前らPC屋に大規模開発の醍醐味はわかろうはずもない！！
46 名前：仕様書無しさん[] 投稿日：2006/02/27(月) 23:01:55
人生はビジネスロジックだ！！
47 名前：仕様書無しさん[sage] 投稿日：2006/02/27(月) 23:03:10
独りで書き込むのは寂しいだろうから俺も書いてやる
48 名前：仕様書無しさん[] 投稿日：2006/02/27(月) 23:20:17
>>44-46
つまらん自作自演だなC言語orドトネト厨
Javaが重いんじゃなくてJavaの上に乗っかろうと
邪魔をしているＣ言語厨がデブなキモヲタで重たいだけなんだよ。
邪魔をしているＣ言語厨がデブなキモヲタで重たいだけなんだよ。
実際、世の中にはサーバーがNT4だったりするところも沢山あるわけで、
それにぶら下がってるクライアントもNT
JAVAはメモリが１G有れば早いとか言われてもね。＾＾；
JAVAの遅さは我慢できても、資源の食いすぎは我慢ならない。
JAVAは早い段階でソースコード共通とか無駄な事をやめて、
各OSごとにネイティブコードを作るべきだとおもう。
ミドルウエァの部分を（JAVAの為に）他の言語で作らなければならないなら
最初からその言語で全部作ったほうが、見通しが良い。無駄なDLLを作らなくてもいい。
それから基地外のように、ゲッターセッター用意しろというのも首をかしげる。
必要なメンバだけに取り付けるものだろう。
とにかくJAVAは無駄が多い。 もっとシンプルになって欲しいものだ。
56 名前：仕様書無しさん[sage] 投稿日：2006/03/01(水) 00:59:28
>各OSごとにネイティブコードを作るべきだとおもう。
ほんとにJava解ってるんだろか?こいつ。
>無駄なDLLを作らなくてもいい。
どっかで見た、JavaからWinのAPI呼べないとか言ってた奴に似てる。
それにぶら下がってるクライアントもNT
JAVAはメモリが１G有れば早いとか言われてもね。＾＾；
JAVAの遅さは我慢できても、資源の食いすぎは我慢ならない。
JAVAは早い段階でソースコード共通とか無駄な事をやめて、
各OSごとにネイティブコードを作るべきだとおもう。
ミドルウエァの部分を（JAVAの為に）他の言語で作らなければならないなら
最初からその言語で全部作ったほうが、見通しが良い。無駄なDLLを作らなくてもいい。
それから基地外のように、ゲッターセッター用意しろというのも首をかしげる。
必要なメンバだけに取り付けるものだろう。
とにかくJAVAは無駄が多い。 もっとシンプルになって欲しいものだ。
56 名前：仕様書無しさん[sage] 投稿日：2006/03/01(水) 00:59:28
>各OSごとにネイティブコードを作るべきだとおもう。
ほんとにJava解ってるんだろか?こいつ。
>無駄なDLLを作らなくてもいい。
どっかで見た、JavaからWinのAPI呼べないとか言ってた奴に似てる。
>>372
Javaの方がひどすぎ・・・
Javaの方がひどすぎ・・・
7.0までは高速化路線だろうからメモリはさらに食い続けるだろうね
それ以降は省エネ化にも力を入れて欲しい -compact みたいなコマンドラインで
それ以降は省エネ化にも力を入れて欲しい -compact みたいなコマンドラインで
>各OSごとにネイティブコードを作るべきだとおもう。
IBMの作ったSWTがそれだね。
IBMの作ったSWTがそれだね。
>>378
具体的に言ってみな、バブル世代さん
具体的に言ってみな、バブル世代さん
59 名前：仕様書無しさん[sage] 投稿日：2006/03/01(水) 01:05:21
まあ細かいとこはSunじゃなくてもいいので、リッチなIBMさんあたりに
お願いしたい。
60 名前：仕様書無しさん[sage] 投稿日：2006/03/01(水) 01:17:05
7.0ではXMLが直接Javaコードとして記述できるらしい。
どんどんきもくなっていくこれからのJavaに期待
61 名前：仕様書無しさん[] 投稿日：2006/03/01(水) 01:29:58
x.0 では DIVISION という概念が導入され
IDENTIFICATION DIVISION
ENVIRONMENT DIVISION
などといった記述が必須になるらしい（嘘
62 名前：仕様書無しさん[sage] 投稿日：2006/03/01(水) 01:32:11
>>61
幻と消えたHTML4とか一時期のSQLを彷彿とさせるな
まあ細かいとこはSunじゃなくてもいいので、リッチなIBMさんあたりに
お願いしたい。
60 名前：仕様書無しさん[sage] 投稿日：2006/03/01(水) 01:17:05
7.0ではXMLが直接Javaコードとして記述できるらしい。
どんどんきもくなっていくこれからのJavaに期待
61 名前：仕様書無しさん[] 投稿日：2006/03/01(水) 01:29:58
x.0 では DIVISION という概念が導入され
IDENTIFICATION DIVISION
ENVIRONMENT DIVISION
などといった記述が必須になるらしい（嘘
62 名前：仕様書無しさん[sage] 投稿日：2006/03/01(水) 01:32:11
>>61
幻と消えたHTML4とか一時期のSQLを彷彿とさせるな
>>382
ヒント J2EE までへの至る道、これからの道。
ヒント J2EE までへの至る道、これからの道。
http://www.itmedia.co.jp/enterprise/articles/0603/01/news043.html
Java携帯を狙う初のマルウェア、ロシアに登場
J2ME（Java 2 Mobile Edition）が動作する携帯電話を狙って感染するトロイの木馬が発見された。
2006年03月01日 14時19分 更新
J2ME（Java 2 Mobile Edition）が動作する携帯電話を狙って感染するトロイの木馬が発見された。
このトロイの木馬「RedBrowser」を報告したロシアのKaspersky Labによると、まだ「コンセプト実証」
段階のものに過ぎないが、これをベースに新たな亜種が登場する恐れもある。
Kaspersky Labは2月28日付で、スマートフォンだけでなくJ2MEアプリケーションが動作する
携帯電話をターゲットにしたマルウェア、RedBrowserを発見したことを明らかにした。
このトロイの木馬は、「redbrowser.jar」というJAR形式のアーカイブとなっている。
「WAP接続を用いずにWAPサイトにアクセスでき、割安に通信できるプログラム」という説明で
ユーザーを騙し、Bluetooth接続やインターネット接続で端末にダウンロードさせるよう仕組む。
もし感染してしまうと、1メッセージ当たり5〜6ドルが課金される高価なSMSサービスにメッセージを
送信しようとする。ちょうど、PC上で勝手に国際電話をかけ、高額な通話料を請求する「ダイヤラー」
のような動作だ。
Java携帯を狙う初のマルウェア、ロシアに登場
J2ME（Java 2 Mobile Edition）が動作する携帯電話を狙って感染するトロイの木馬が発見された。
2006年03月01日 14時19分 更新
J2ME（Java 2 Mobile Edition）が動作する携帯電話を狙って感染するトロイの木馬が発見された。
このトロイの木馬「RedBrowser」を報告したロシアのKaspersky Labによると、まだ「コンセプト実証」
段階のものに過ぎないが、これをベースに新たな亜種が登場する恐れもある。
Kaspersky Labは2月28日付で、スマートフォンだけでなくJ2MEアプリケーションが動作する
携帯電話をターゲットにしたマルウェア、RedBrowserを発見したことを明らかにした。
このトロイの木馬は、「redbrowser.jar」というJAR形式のアーカイブとなっている。
「WAP接続を用いずにWAPサイトにアクセスでき、割安に通信できるプログラム」という説明で
ユーザーを騙し、Bluetooth接続やインターネット接続で端末にダウンロードさせるよう仕組む。
もし感染してしまうと、1メッセージ当たり5〜6ドルが課金される高価なSMSサービスにメッセージを
送信しようとする。ちょうど、PC上で勝手に国際電話をかけ、高額な通話料を請求する「ダイヤラー」
のような動作だ。
78 名前：仕様書無しさん[sage] 投稿日：2006/03/02(木) 12:18:23
>>55
> 実際、世の中にはサーバーがNT4だったりするところも沢山あるわけで、
> それにぶら下がってるクライアントもNT
>
> JAVAはメモリが１G有れば早いとか言われてもね。＾＾；
↑
この顔文字を使うところがJavaを否定したがる
バブル世代以降の
オッサン臭ぇなあw
当時はパソコン通信が流行ってたからなw
> JAVAの遅さは我慢できても、資源の食いすぎは我慢ならない。
今どき我慢するのは組み込み系だけだろうがw
サーバはリソースがたっぷりあろうだろう。
>>55
> 実際、世の中にはサーバーがNT4だったりするところも沢山あるわけで、
> それにぶら下がってるクライアントもNT
>
> JAVAはメモリが１G有れば早いとか言われてもね。＾＾；
↑
この顔文字を使うところがJavaを否定したがる
バブル世代以降の
オッサン臭ぇなあw
当時はパソコン通信が流行ってたからなw
> JAVAの遅さは我慢できても、資源の食いすぎは我慢ならない。
今どき我慢するのは組み込み系だけだろうがw
サーバはリソースがたっぷりあろうだろう。
>>55
> JAVAは早い段階でソースコード共通とか無駄な事をやめて、
> 各OSごとにネイティブコードを作るべきだとおもう。
毎回バージョンアップするたびにネイティブコードに無き直すのかw
効率が悪いな。気がついたら糞NTOS専用になって新しいOSや他のOS, Linuxや
Solarisなどに対応できず苦しむぞ。世の中のサーバNT4しかないという
根拠も無いしな。Javaサーバ系の仕事ではどこもUnix系Linus系ばかりだ。
そこでネイティブに拘ってたら自滅するぞ。
> ミドルウエァの部分を（JAVAの為に）他の言語で作らなければならないなら
> 最初からその言語で全部作ったほうが、見通しが良い。無駄なDLLを作らなくてもいい。
それはOSがNT4限定という話だよな。サーバを突然Linuxに置き換えます
とか言われたら慌てふためくぞ。
> それから基地外のように、ゲッターセッター用意しろというのも首をかしげる。
> 必要なメンバだけに取り付けるものだろう。
無駄が多いとかアホなことをいってるようだが、getter/setterの意味わかってないな。
Javaに限らずネイティブコンパイラ言語でも当たり前のように使うわけだがw
> JAVAは早い段階でソースコード共通とか無駄な事をやめて、
> 各OSごとにネイティブコードを作るべきだとおもう。
毎回バージョンアップするたびにネイティブコードに無き直すのかw
効率が悪いな。気がついたら糞NTOS専用になって新しいOSや他のOS, Linuxや
Solarisなどに対応できず苦しむぞ。世の中のサーバNT4しかないという
根拠も無いしな。Javaサーバ系の仕事ではどこもUnix系Linus系ばかりだ。
そこでネイティブに拘ってたら自滅するぞ。
> ミドルウエァの部分を（JAVAの為に）他の言語で作らなければならないなら
> 最初からその言語で全部作ったほうが、見通しが良い。無駄なDLLを作らなくてもいい。
それはOSがNT4限定という話だよな。サーバを突然Linuxに置き換えます
とか言われたら慌てふためくぞ。
> それから基地外のように、ゲッターセッター用意しろというのも首をかしげる。
> 必要なメンバだけに取り付けるものだろう。
無駄が多いとかアホなことをいってるようだが、getter/setterの意味わかってないな。
Javaに限らずネイティブコンパイラ言語でも当たり前のように使うわけだがw
名前：仕様書無しさん[] 投稿日：2006/03/02(木) 12:21:33
>>65
大半のドカタが消えれば
開発効率は大幅に高まるしな。
さっそく、Tomcatも4.1から5.5に
アップグレードしてドカタを殲滅しようw
>>65
大半のドカタが消えれば
開発効率は大幅に高まるしな。
さっそく、Tomcatも4.1から5.5に
アップグレードしてドカタを殲滅しようw
81 名前：仕様書無しさん[] 投稿日：2006/03/02(木) 12:24:14
C言語やVBからJavaに入ってきたドカタは
古くさい文化をJavaに持ち込んできてウザイから
さっさとJava5を導入して新しい文化で奴らを
蹴散らすか洗脳するかしないとJava開発効率は
一向に向上しねえな。
Spring FrameworkのこともろくにわからんC言語ドカタ
は仕事の邪魔でウザイからこの業界から出て行ってくんねえかな？
C言語やVBからJavaに入ってきたドカタは
古くさい文化をJavaに持ち込んできてウザイから
さっさとJava5を導入して新しい文化で奴らを
蹴散らすか洗脳するかしないとJava開発効率は
一向に向上しねえな。
Spring FrameworkのこともろくにわからんC言語ドカタ
は仕事の邪魔でウザイからこの業界から出て行ってくんねえかな？
83 名前：仕様書無しさん[] 投稿日：2006/03/02(木) 12:47:53
>Spring Framework
あれダサいよね、いかにもJava的ｗ
.netならばドラッグで済む話がくどくどとクラスをインプリするｗ
84 名前：仕様書無しさん[sage] 投稿日：2006/03/02(木) 14:06:30
（ﾟДﾟ）ﾊｧ? ダサいのはお前だろ。
Nspring やSpring.NETの存在も知らないのか
それをドラッグですむとは次元に低い話に持ち出して
話がまったく噛み合ってないな。ドトネト厨は
>Spring Framework
あれダサいよね、いかにもJava的ｗ
.netならばドラッグで済む話がくどくどとクラスをインプリするｗ
84 名前：仕様書無しさん[sage] 投稿日：2006/03/02(木) 14:06:30
（ﾟДﾟ）ﾊｧ? ダサいのはお前だろ。
Nspring やSpring.NETの存在も知らないのか
それをドラッグですむとは次元に低い話に持ち出して
話がまったく噛み合ってないな。ドトネト厨は
85 名前：仕様書無しさん[sage] 投稿日：2006/03/02(木) 14:37:41
API War
ttp://www.radiumsoftware.com/0406.html#040629
ttp://itpro.nikkeibp.co.jp/article/NEWS/20060301/231341/
梅田氏 Bill Gatesはあちら側にはなれないと思います。なぜならその出発点がこちら側にあるから。
Googleの重要性についてMicrosoftが気付くまで驚くほど時間がかかった。
遅すぎたんです。相変わらず「あちら側」の本質が何なのか，体では理解できなかったのでしょう。
API War
ttp://www.radiumsoftware.com/0406.html#040629
ttp://itpro.nikkeibp.co.jp/article/NEWS/20060301/231341/
梅田氏 Bill Gatesはあちら側にはなれないと思います。なぜならその出発点がこちら側にあるから。
Googleの重要性についてMicrosoftが気付くまで驚くほど時間がかかった。
遅すぎたんです。相変わらず「あちら側」の本質が何なのか，体では理解できなかったのでしょう。
86 名前：仕様書無しさん[] 投稿日：2006/03/03(金) 00:51:38
>>79
サーバーを新しくしてくれると助かるのはこちら。
多くは「客の都合でNT4」なのですよ。
サーバーをLinuxにしてくれれば、仕事が発生しますので何も慌てません。
昔から顧客を持ってるソフトに関して言えば、結局JAVAで開発するメリットが見えてこない。
あと端末を、鬼のごとく高速に叩いて動かす客がいる以上、JAVAは無理ｗ
印刷レスポンスに1秒以上かかったらクレームが来る。＜組み込みではないよ。
あとJAVAが話題になってるところでは、メタフレームの話はあまり見かけないね。
こちらでは東京のサーバルームから、全国の印刷端末への速度を3秒以下にする事が必要。
こういう仕様要求に耐えられるようになったら、JAVAも検討する。
そもそもクロスプラットホームなんてのは、作り手の都合だから。
客にはあんまり関心なかったりする。
>>79
サーバーを新しくしてくれると助かるのはこちら。
多くは「客の都合でNT4」なのですよ。
サーバーをLinuxにしてくれれば、仕事が発生しますので何も慌てません。
昔から顧客を持ってるソフトに関して言えば、結局JAVAで開発するメリットが見えてこない。
あと端末を、鬼のごとく高速に叩いて動かす客がいる以上、JAVAは無理ｗ
印刷レスポンスに1秒以上かかったらクレームが来る。＜組み込みではないよ。
あとJAVAが話題になってるところでは、メタフレームの話はあまり見かけないね。
こちらでは東京のサーバルームから、全国の印刷端末への速度を3秒以下にする事が必要。
こういう仕様要求に耐えられるようになったら、JAVAも検討する。
そもそもクロスプラットホームなんてのは、作り手の都合だから。
客にはあんまり関心なかったりする。
87 名前：仕様書無しさん[sage] 投稿日：2006/03/03(金) 01:34:41 ?
多くは客の都合でNT4と言う話は
内のバイト先のマネージャからは聞かないですね。
PHPの案件が非常に多くJavaの案件は少ないですが、
Javaの案件は成功すればPHPよりもおっきな金が入ってくるみたいですね。
しかしPHPよりもかなりの開発力や経験、ノウハウが必要で
ただ人を寄せ集めただけの小さい会社はJavaの案件を引き受ける
のは難しいみたいですね。
必ずしもJavaのプラットフォーム非依存が作り手の都合とは言い切れず、
他のサーバへの移植や、異なるOSやCPUを復讐所持しているサーバを保有
している場合などで手間が省けるという運用者の都合でJavaを
選ぶ顧客がいることも否定できないようです。
多くは客の都合でNT4と言う話は
内のバイト先のマネージャからは聞かないですね。
PHPの案件が非常に多くJavaの案件は少ないですが、
Javaの案件は成功すればPHPよりもおっきな金が入ってくるみたいですね。
しかしPHPよりもかなりの開発力や経験、ノウハウが必要で
ただ人を寄せ集めただけの小さい会社はJavaの案件を引き受ける
のは難しいみたいですね。
必ずしもJavaのプラットフォーム非依存が作り手の都合とは言い切れず、
他のサーバへの移植や、異なるOSやCPUを復讐所持しているサーバを保有
している場合などで手間が省けるという運用者の都合でJavaを
選ぶ顧客がいることも否定できないようです。
88 名前：仕様書無しさん[] 投稿日：2006/03/03(金) 01:52:06
>>87
客の都合＞予算が通らない＞現状で（客は）困っていない。困るのはハードが壊れた時...
書き込みをから判断すると、WEB系のお仕事のようですね。
WEB系ではまた状況が違うのでしょう。
5年前に納品したサーバー＆クライアントのセットが、NT4構成というのは良くあります。
さすがに「新規案件」でNTの指定はありません。
>>87
客の都合＞予算が通らない＞現状で（客は）困っていない。困るのはハードが壊れた時...
書き込みをから判断すると、WEB系のお仕事のようですね。
WEB系ではまた状況が違うのでしょう。
5年前に納品したサーバー＆クライアントのセットが、NT4構成というのは良くあります。
さすがに「新規案件」でNTの指定はありません。
89 名前：仕様書無しさん[sage] 投稿日：2006/03/03(金) 02:05:20
WebでNTってどうなの？もうパッチも出てないだろ
それともMSに金積んでサポートしてもらってるのか？
WebでNTってどうなの？もうパッチも出てないだろ
それともMSに金積んでサポートしてもらってるのか？
94 名前：仕様書無しさん[sage] 投稿日：2006/03/03(金) 12:25:13
まあ今年はＰＨＰ対応フレームワークの全盛期に
なるかもしれないと言われている。
名前空間も使えない貧弱な言語ＰＨＰで
JavaやRuby on Railsのフレームワークを
パクッタところで、どの程度実用的に使いこなせるか
今年は見物の年でもあるが。
Perl6がさっさと出ればね、PHPはまともな言語に進化できたかも
しれないわけだが。あの仕様じゃ、Javaより開発しづらく、
PHPばかりってのじゃいずれ寿命が尽きる罠。
PHPで作られたwebアプリを再利用しろっていわれても、
Javaで作られたアプリを再利用することと比べたら苦になる
点があまりにも多すぎるからね。数年で衰退する罠。
まあ今年はＰＨＰ対応フレームワークの全盛期に
なるかもしれないと言われている。
名前空間も使えない貧弱な言語ＰＨＰで
JavaやRuby on Railsのフレームワークを
パクッタところで、どの程度実用的に使いこなせるか
今年は見物の年でもあるが。
Perl6がさっさと出ればね、PHPはまともな言語に進化できたかも
しれないわけだが。あの仕様じゃ、Javaより開発しづらく、
PHPばかりってのじゃいずれ寿命が尽きる罠。
PHPで作られたwebアプリを再利用しろっていわれても、
Javaで作られたアプリを再利用することと比べたら苦になる
点があまりにも多すぎるからね。数年で衰退する罠。
97 名前：仕様書無しさん[] 投稿日：2006/03/03(金) 14:14:26
馬鹿だなWebアプリは終わってる。
スマートクライアントでJavaは大沈没。
GUIが貧弱なJavaでは波に乗れない。
99 名前：仕様書無しさん[sage] 投稿日：2006/03/03(金) 14:28:05
＞馬鹿だなWebアプリは終わってる。
終ったらググルも尼損も使えないということだお。
絶対困る。
103 名前：仕様書無しさん[sage] 投稿日：2006/03/03(金) 14:40:52
>>100
＞それはアプリじゃねーだろう。単にインターネットだろう。
Webアプリという言葉をご存知無い？
＞ググルのサービスはアプリに取り込めるのは事実としてあるけどさ。
それ理想のウェブAPIじゃん。
馬鹿だなWebアプリは終わってる。
スマートクライアントでJavaは大沈没。
GUIが貧弱なJavaでは波に乗れない。
99 名前：仕様書無しさん[sage] 投稿日：2006/03/03(金) 14:28:05
＞馬鹿だなWebアプリは終わってる。
終ったらググルも尼損も使えないということだお。
絶対困る。
103 名前：仕様書無しさん[sage] 投稿日：2006/03/03(金) 14:40:52
>>100
＞それはアプリじゃねーだろう。単にインターネットだろう。
Webアプリという言葉をご存知無い？
＞ググルのサービスはアプリに取り込めるのは事実としてあるけどさ。
それ理想のウェブAPIじゃん。
107 名前：仕様書無しさん[sage] 投稿日：2006/03/03(金) 14:51:42
>>104
うっせえ、使えればサーバーがJavaだろうと何だろうと構わんのだよ。
しかし、ドトネトノータッチデプロイは超カンベン。
>>104
うっせえ、使えればサーバーがJavaだろうと何だろうと構わんのだよ。
しかし、ドトネトノータッチデプロイは超カンベン。
109 名前：仕様書無しさん[sage] 投稿日：2006/03/03(金) 15:10:05
>>97
じゃあさ今ホットな分野は何か説明してくれ
サービス指向アーキティチャにＤＩコンテナ、Ruby on Rails, Ajaxと
きた。これでwebが終わってるとでも言い切れると？
>>97
じゃあさ今ホットな分野は何か説明してくれ
サービス指向アーキティチャにＤＩコンテナ、Ruby on Rails, Ajaxと
きた。これでwebが終わってるとでも言い切れると？
110 名前：仕様書無しさん[sage] 投稿日：2006/03/03(金) 15:11:14
>>100
Googleの各種APIは思いっきりWeb系なのだが。
Ajaxバリバリだしな。
マイクロソフトもGoogleの波に乗ることができなかった。
今後はGoogleが世界を制する。
>>100
Googleの各種APIは思いっきりWeb系なのだが。
Ajaxバリバリだしな。
マイクロソフトもGoogleの波に乗ることができなかった。
今後はGoogleが世界を制する。
111 名前：仕様書無しさん[sage] 投稿日：2006/03/03(金) 15:12:39
そもそも流行技術を追うという態度こそ改められるべきだと思う。
そもそも流行技術を追うという態度こそ改められるべきだと思う。
流行技術ってこういうやつ？
DDE（Win3.1or3.0 1993)
↓
NET DDE (Win3.1 1994)
↓
埋め込みしたいなぁ．．．
↓
OLE1.0（DDE使用）
↓
OLE2.0=COM ただし目的はインプレースドキュメント。しかしその背景には本質としてバイナリオブジェクト標準あんどオブジェクト通信の思想あり。この辺で名慮or迷著 InsideOLEあんどIsideOLE2。死者多数。
部品としてVB用のVBX (VB2.0からVB4.0 1995あたり)
↓
COMを使ったOCX (1996あたり）結局コンポーネントビジネスはやんなかったな...
ゲイツがインターネットに熱上げあんどJAVA Appletはやる (1995）
↓
COMつかってActiveX(1996)
だんだんオブジェクトはやってくる。 （UMLなど1997）オブジェクトもでるとしてCOMの宣伝開始 DCOMなどCORBAとがっぷり。この辺でMTSではじめ
↓
マーケティングてきなWindowsDNA 。MTS2.0それなりに使えそう。つか使った。DCOM糞。(1999)
↓
COM+ （Win2000､2000）In-MemoryDBどこいったゴラァ
COM Runtimeの情報漏れ始め (2000〜)
↓
セキュリティ→ファイアーウォールのためCOM全滅。しばらくしてから.NETとしてCOMじゃないものに．．．
↓
.NET流行らず(〜2006)
↓
WinFX完成(2007)
↓
オブジェクトベースプログラミングにより、OSは関数コールに戻る(2008)
WinFX下位互換へ
DDE（Win3.1or3.0 1993)
↓
NET DDE (Win3.1 1994)
↓
埋め込みしたいなぁ．．．
↓
OLE1.0（DDE使用）
↓
OLE2.0=COM ただし目的はインプレースドキュメント。しかしその背景には本質としてバイナリオブジェクト標準あんどオブジェクト通信の思想あり。この辺で名慮or迷著 InsideOLEあんどIsideOLE2。死者多数。
部品としてVB用のVBX (VB2.0からVB4.0 1995あたり)
↓
COMを使ったOCX (1996あたり）結局コンポーネントビジネスはやんなかったな...
ゲイツがインターネットに熱上げあんどJAVA Appletはやる (1995）
↓
COMつかってActiveX(1996)
だんだんオブジェクトはやってくる。 （UMLなど1997）オブジェクトもでるとしてCOMの宣伝開始 DCOMなどCORBAとがっぷり。この辺でMTSではじめ
↓
マーケティングてきなWindowsDNA 。MTS2.0それなりに使えそう。つか使った。DCOM糞。(1999)
↓
COM+ （Win2000､2000）In-MemoryDBどこいったゴラァ
COM Runtimeの情報漏れ始め (2000〜)
↓
セキュリティ→ファイアーウォールのためCOM全滅。しばらくしてから.NETとしてCOMじゃないものに．．．
↓
.NET流行らず(〜2006)
↓
WinFX完成(2007)
↓
オブジェクトベースプログラミングにより、OSは関数コールに戻る(2008)
WinFX下位互換へ
そもそも、Unixのコマンドもろくにうごかん
WindowsNTサーバでアプリを動かす？
アホらしくてやってられんｗ
笑い飛ばすしかねえなw
WindowsNTサーバでアプリを動かす？
アホらしくてやってられんｗ
笑い飛ばすしかねえなw
405 ：仕様書無しさん：2006/03/05(日) 15:53:58
_ ∩
( ﾟ∀ﾟ)彡 パソコン！パソコン！
⊂彡
( ﾟ∀ﾟ)彡 パソコン！パソコン！
⊂彡
>>403
Javaの方がひどすぎ・・・
Javaの方がひどすぎ・・・
408 ：仕様書無しさん：2006/03/05(日) 17:12:09
いや。枝番プラグインダウンロードや環境構築は得意なはず。
409 ：仕様書無しさん：2006/03/05(日) 19:18:38
ところで>>341に対する回答ﾏﾀﾞｰ?
みずほも東京三菱も遅いじゃん。
こういうのは実際の処理は汎用機がやってるわけでWebはただのUIだ。
しかもアクセス数はyahoo等と比べればはるかに少ないのにあのレスポンス。
遅いと思わない？
こういうのは実際の処理は汎用機がやってるわけでWebはただのUIだ。
しかもアクセス数はyahoo等と比べればはるかに少ないのにあのレスポンス。
遅いと思わない？
411 ：仕様書無しさん：2006/03/05(日) 22:40:35
Yahoo銀行なんてあったっけ？
話の意図読めてるかな？
そういう比較対象がないと意味がないんだけど。
Yahooと比較するならちゃんと銀行系サービスを示さなきゃ
話の意図読めてるかな？
そういう比較対象がないと意味がないんだけど。
Yahooと比較するならちゃんと銀行系サービスを示さなきゃ
ジャパンネットバンクじゃね？
そう言われたら遅い気がする。。。
ジャパンネットバンク速いよな。レスポンスも速いけど。処理も早い。
向かいのコンビニで下ろして帰宅したら引き出し通知メールがとっくに届いてる。
向かいのコンビニで下ろして帰宅したら引き出し通知メールがとっくに届いてる。
でさ、ジャパンネットバンクって何でできてるの？
416 ：仕様書無しさん：2006/03/05(日) 22:49:36
Javaだろ？
■Javaが使われている銀行
●イーバンク
●三井住友銀行
●みずほ銀行
●三菱東京UFJ銀行
●イーバンク
●三井住友銀行
●みずほ銀行
●三菱東京UFJ銀行
■Javaが使われている銀行
●イーバンク
●三井住友銀行
●みずほ銀行
●三菱東京UFJ銀行
●ジャパンネットバンク
●イーバンク
●三井住友銀行
●みずほ銀行
●三菱東京UFJ銀行
●ジャパンネットバンク
違う。
JNBは新興なので、化石のような汎用機のシステムと連携を取る必要が無く、最適化できるから。
JNBは新興なので、化石のような汎用機のシステムと連携を取る必要が無く、最適化できるから。
ええ！ジャパンネットバンクもJavaなの？
422 ：くくく：2006/03/05(日) 22:55:05
ってかリアルにＪＡＶＡ遅くねｗ
普通にみずほは遅いだろ。>>341は麻痺してるんじゃね？
URLはcgi-binになってるぞ。＜JNB
こんなただのUIのようなページでそんなに差がでるかぁ？？
何かおかしくないか？
何かおかしくないか？
顧客数の問題もあるだろ
顧客数やアクセス数ならジャパンネットがダントツだろ。ネット専業なんだから。
どういう理屈だ。
Java使ってるって、ひょっとしてASTERIAを使ってるという意味じゃないの？
>>426
画面遷移部分は顧客数は関係ないぞ。
三井住友ダイレクトの画面遷移は
早いが、AjaxやJavaScriptを使っておらず
一旦サーバにリクエストを送ってからServletで
処理しているが速い。
画面遷移部分は顧客数は関係ないぞ。
三井住友ダイレクトの画面遷移は
早いが、AjaxやJavaScriptを使っておらず
一旦サーバにリクエストを送ってからServletで
処理しているが速い。
431 ：仕様書無しさん：2006/03/06(月) 00:57:52
Javaが速くなったことを認められない
馬鹿が多いみたいだな
馬鹿が多いみたいだな
×Javaが速くなった
○マシンが速くなった
○マシンが速くなった
同じマシンでもJVMも1.0の頃と比べ倍速くなったんだが。
昔のJVMと今のKVMをと比べたベンチマーク取って皆よ
昔のJVMと今のKVMをと比べたベンチマーク取って皆よ
>>433
昔のマシンでとってね。
昔のマシンでとってね。
435 ：仕様書無しさん：2006/03/07(火) 00:12:49
といっても古すぎるマシンだとメモリが足りなくなるからな
加減を考えないとな。
JavaOne Tokyo 2005で初期のJVMと比べ
今のJVMはパフォーマンスが
倍になったって報告があった
加減を考えないとな。
JavaOne Tokyo 2005で初期のJVMと比べ
今のJVMはパフォーマンスが
倍になったって報告があった
436 ：仕様書無しさん：2006/03/07(火) 00:13:58
携帯電話のiアプリiBisブラウザはJavaで作られてるのに
めっちゃ速いな
あの滑らかなスクロールでAmazonにアクセスできることにびっくり
めっちゃ速いな
あの滑らかなスクロールでAmazonにアクセスできることにびっくり
たしかに速度面ではかなり改善されてきてるらしいよ。
でも所詮JAVAだから。
でも所詮JAVAだから。
何年かかって今の速度になったんだよｗ
439 ：仕様書無しさん：2006/03/07(火) 04:23:34
97年頃最強だったPentiumPro200MHz/256MBにJava5を載せたら、当時の倍の速度で動きますか？
全然だめだろ
全然だめだろ
440 ：仕様書無しさん：2006/03/07(火) 04:32:10
必要なメモリは二倍以上
441 ：仕様書無しさん：2006/03/07(火) 04:36:26
メモリ増設しろよｗ
443 ：仕様書無しさん：2006/03/07(火) 04:47:24
Javaがもてはやされて、アプレットが流行しかころの最強ハードだぞ。
無理なわけないだろバカ
無理なわけないだろバカ
Java5なんて存在しないものを批判してどーする
×Javaが速くなった
○マシンが速くなった
○マシンが速くなった
メモリ容量が増え、マシンCPUもJVMもどちらも高速化して
Javaは速くなったと
それで結論がでいるね。
もうJavaは遅くない。
Javaは速くなったと
それで結論がでいるね。
もうJavaは遅くない。
でいねーよ。
比較対象がJavaだから単なるオナーニよ。
比較対象がJavaだから単なるオナーニよ。
VMで起動させてる時点で比較対象にならない。
最近のは一旦起動したら二度と起動しなくても良いわけだし
Javaアプリを起動するたびに
VMを起動してメモリを無駄に消費するという
問題は解決されてるしねえ
Javaアプリを起動するたびに
VMを起動してメモリを無駄に消費するという
問題は解決されてるしねえ
Java叩きは文系に多いことがよくわかった
455 ：仕様書無しさん：2006/03/09(木) 02:09:39
しかも根拠もないアホで高卒な奴
456 ：仕様書無しさん：2006/03/09(木) 08:42:36
速いって言ってるのは、マシン１台Javaのみで占有してるサーバー機の時の話だろう？
457 ：仕様書無しさん：2006/03/09(木) 08:45:15
Javaのみのわけないだろ。素人
458 ：仕様書無しさん：2006/03/09(木) 10:46:46
C言語厨はWindowsしか使いこなせずUnixやLinuxを使いこなせない。
だからJava屋を嫉む
だからJava屋を嫉む
('A`)・・・
>458
Java厨はUnixに強いのか？
環境がUnixになっただけであたふた狼狽して
ツールのインストールすらできずにいるJava厨しかみたことないぞ
Java厨はUnixに強いのか？
環境がUnixになっただけであたふた狼狽して
ツールのインストールすらできずにいるJava厨しかみたことないぞ
そうか？
Visual C++しか使えないC言語厨が
環境がUnixに変わっただけであたふたして狼狽して
種種のツールのインストールやrpmやaptすら使いこなせずに
いるC厨しか見たことがないぞ。
Visual C++しか使えないC言語厨が
環境がUnixに変わっただけであたふたして狼狽して
種種のツールのインストールやrpmやaptすら使いこなせずに
いるC厨しか見たことがないぞ。
462 ：仕様書無しさん：2006/03/09(木) 12:14:34
だいたい、Visual C++を持っているだけで
C++を使いこなせると勘違いしてるアホC言語厨が多いんだよねｌ。
M$様のケツを舐めることしかできないアホというか。
C++を使いこなせると勘違いしてるアホC言語厨が多いんだよねｌ。
M$様のケツを舐めることしかできないアホというか。
464 ：仕様書無しさん：2006/03/09(木) 12:46:55
>>463
ITドカタ乙！
ITドカタ乙！
いまさら当たり前なことをいって今更何をいっているのか。
というか>>463はインストールもできないとは無能だな。
インストール専用担当に任せたって
まともな設定方法もろくに知らんばかがいるから
かえって効率が悪くて仕方がない。
とくにオープンソース系のサーバソフトウェアの
インストールではインストール専門部隊など役に立ちやしない。
やつらにroot権限でサーバアプリのディレクトリをアクセスの
邪魔をされてはたまったもんじゃない。
というか>>463はインストールもできないとは無能だな。
インストール専用担当に任せたって
まともな設定方法もろくに知らんばかがいるから
かえって効率が悪くて仕方がない。
とくにオープンソース系のサーバソフトウェアの
インストールではインストール専門部隊など役に立ちやしない。
やつらにroot権限でサーバアプリのディレクトリをアクセスの
邪魔をされてはたまったもんじゃない。
サーバがroot権限で走ってるんだ？ヘェー
467 ：仕様書無しさん：2006/03/09(木) 13:00:15
俺様サーバですからｗ
>サーバがroot権限で走ってるんだ？
そこはなんと言ってもJava厨ですから
シビアな管理なんてできっこないわけですよ
そこはなんと言ってもJava厨ですから
シビアな管理なんてできっこないわけですよ
469 ：仕様書無しさん：2006/03/09(木) 16:44:43
おそらくJava厨がアカウント管理しだすと
Well Knownサービスがことごとく使えなくなっちゃうぞｗ。
Well Knownサービスがことごとく使えなくなっちゃうぞｗ。
470 ：仕様書無しさん：2006/03/09(木) 21:14:47
Oracle のツールがjre の1.1 とか1.3 とか引きこんでるせいで
eclipse が動かない件について。
あるいはODBC をインストールしようとしたら、5.0 環境では 9iの
インストーラが動作しなくて、8用のRDBC をインストールして
Object Browser を使っている件について。
eclipse が動かない件について。
あるいはODBC をインストールしようとしたら、5.0 環境では 9iの
インストーラが動作しなくて、8用のRDBC をインストールして
Object Browser を使っている件について。
471 ：仕様書無しさん：2006/03/09(木) 21:28:44
ワロタ
472 ：仕様書無しさん：2006/03/09(木) 22:00:00
糞だなJava
474 ：仕様書無しさん：2006/03/09(木) 22:22:37
475 ：仕様書無しさん：2006/03/09(木) 22:23:37
恐怖の枝番動作不全
Oracleが糞なんだと思ってください・・・
477 ：仕様書無しさん：2006/03/09(木) 22:36:13
Oracleは悪くない、Javaが糞
478 ：仕様書無しさん：2006/03/09(木) 23:11:00
>>466==>>468
日本語読めないのか自作自演C言語厨バブル世代のオッサン君
組み込み開発しかやることが能が無い癖に
シビアな管理ができないとC言語厨が主張しているって？
餓鬼の癖に言い度胸だよなw
日本語読めないのか自作自演C言語厨バブル世代のオッサン君
組み込み開発しかやることが能が無い癖に
シビアな管理ができないとC言語厨が主張しているって？
餓鬼の癖に言い度胸だよなw
479 ：仕様書無しさん：2006/03/09(木) 23:12:12
バブル世代の組み込み系しか能力が無い
高卒のC言語厨オッサンが必死にJavaを叩く
いい年した30過ぎの癖に哀れでまるで餓鬼みたいですねﾌﾟﾌﾟﾌﾟ
高卒のC言語厨オッサンが必死にJavaを叩く
いい年した30過ぎの癖に哀れでまるで餓鬼みたいですねﾌﾟﾌﾟﾌﾟ
このスレってさ・・・・・・・・・２人の発言が全体の大半を占めてるよね？ｗ
482 ：おJAVA様：2006/03/09(木) 23:46:21
http://hp.vector.co.jp/authors/VA015862/index.html#essay
私は、頭の体操といった意味で、時々、企業や団体の懸賞論文に応募することがあります。
だいたいは選外で戻ってくるものなのですが、あとあと考えると、早すぎた天才かなあ、と自分で納得することが多いです。そういったものを集めてみました。
Javaでオブジェクト指向バッチ処理
1999年のＩＢＭユーザー研究会応募作品です。これは見事佳作でした。
オブジェクト指向はどうしてもＧＵＩのためのものと思われるけど、バッチ処理にも有効だよ、という長年の主張を書いたものです。
まあ、目新しさを出すためにJavaを使ってみました。書き始めた当時はJavaの速度を他の言語と比較したものは無かったのでそれもやってみました。オブジェクト指向的にデザインを一致させてDelphiの６６％の速度。なかなかの腕でしょう。
私は、頭の体操といった意味で、時々、企業や団体の懸賞論文に応募することがあります。
だいたいは選外で戻ってくるものなのですが、あとあと考えると、早すぎた天才かなあ、と自分で納得することが多いです。そういったものを集めてみました。
Javaでオブジェクト指向バッチ処理
1999年のＩＢＭユーザー研究会応募作品です。これは見事佳作でした。
オブジェクト指向はどうしてもＧＵＩのためのものと思われるけど、バッチ処理にも有効だよ、という長年の主張を書いたものです。
まあ、目新しさを出すためにJavaを使ってみました。書き始めた当時はJavaの速度を他の言語と比較したものは無かったのでそれもやってみました。オブジェクト指向的にデザインを一致させてDelphiの６６％の速度。なかなかの腕でしょう。
>>481
うん。
うん。
バッチ処理ならAntを使って書きたくなってくる。
あれも内部でJavaを使ってはいるが。
あれも内部でJavaを使ってはいるが。
>>481
4人はいそうだ
4人はいそうだ
487 ：仕様書無しさん：2006/03/10(金) 00:04:23
488 ：Mb：2006/03/10(金) 00:05:33
> 私は、頭の体操といった意味で、時々、企業や団体の懸賞論文に
> 応募することがあります。
そうか、「企業や団体の懸賞論文」が「頭の体操」になるとは
思ってはいなかった。己の不見識を恥じざるを得ない。
漏れは（現在休刊中だが）“bit”の『ナノピコ教室』（入選二回）と
“数学セミナー”の「エレガントな解答を求む」（入選一回）といった、
「非商用」というか“金にならない”世界でしか評価された経験しか
ないので、「企業や団体の懸賞論文」のような「ビジネスの世界」で
評価されたお偉い人に対しては、畏れ奉るしかない。
そんな高貴なお方が「２ちゃんねる」のような下衆な世界の、
こんな下衆なスレに投稿して下さるとは……
ああ、ありがたやもったいなやかたじけなや。
> 応募することがあります。
そうか、「企業や団体の懸賞論文」が「頭の体操」になるとは
思ってはいなかった。己の不見識を恥じざるを得ない。
漏れは（現在休刊中だが）“bit”の『ナノピコ教室』（入選二回）と
“数学セミナー”の「エレガントな解答を求む」（入選一回）といった、
「非商用」というか“金にならない”世界でしか評価された経験しか
ないので、「企業や団体の懸賞論文」のような「ビジネスの世界」で
評価されたお偉い人に対しては、畏れ奉るしかない。
そんな高貴なお方が「２ちゃんねる」のような下衆な世界の、
こんな下衆なスレに投稿して下さるとは……
ああ、ありがたやもったいなやかたじけなや。
489 ：仕様書無しさん：2006/03/10(金) 00:15:14
さりげなくお自慢
490 ：仕様書無しさん：2006/03/10(金) 00:28:31
バカルタジャパキャット
491 ：仕様書無しさん：2006/03/10(金) 08:44:39
Javaで書かれたデータベースソフトって無いのか？素人ども
つ PointBase
つ Cloudscape
つ HSQLDB
まだあるかもしれない
つ Cloudscape
つ HSQLDB
まだあるかもしれない
494 ：仕様書無しさん：2006/03/10(金) 11:27:29
C言語厨はものづくりの精神がないから必死にJavaを批判しているんだよね。
だらしないっていうか情けないって言うかそういう集団の集まりだよねどう見ても。
だらしないっていうか情けないって言うかそういう集団の集まりだよねどう見ても。
Java言語厨はものづくりの精神がないから必死にCを批判しているんだよね。
できあいのものひっつけたりくっつけたりしてるだけ。
だらしないっていうか情けないって言うかそういう集団の集まりだよねどう見ても。
できあいのものひっつけたりくっつけたりしてるだけ。
だらしないっていうか情けないって言うかそういう集団の集まりだよねどう見ても。
496 ：仕様書無しさん：2006/03/10(金) 13:15:25
C言語厨はものづくりの精神がないから必死にJavaを批判しているんだよね。
C言厨は朝鮮人のように車輪の再発名しかできないだけ。
だらしないっていうか情けないって言うかそういう集団の集まりだよねどう見ても。
C言厨は朝鮮人のように車輪の再発名しかできないだけ。
だらしないっていうか情けないって言うかそういう集団の集まりだよねどう見ても。
497 ：仕様書無しさん：2006/03/10(金) 13:29:46
javaが速いって、何と比較してだ？
basicか？
仮にCと比較したとして、そのマシンのCPUに最適化された実行コードを
吐き出す・・・あー書くのが面倒くせえ。
java速いって言ってる連中は、javaがどうやってOS上で動作しているか
分かってねーんだろ。
basicか？
仮にCと比較したとして、そのマシンのCPUに最適化された実行コードを
吐き出す・・・あー書くのが面倒くせえ。
java速いって言ってる連中は、javaがどうやってOS上で動作しているか
分かってねーんだろ。
498 ：仕様書無しさん：2006/03/10(金) 13:34:59
>>497
時速50kmの乗り物Javaが199kmになった
時速100kmの乗り物C++が時速200kmになった。
スピード違反しないと発揮できない
その速度差を気にしている人間がどれだけいるのか？
よく考えてごらん。
時速50kmの乗り物Javaが199kmになった
時速100kmの乗り物C++が時速200kmになった。
スピード違反しないと発揮できない
その速度差を気にしている人間がどれだけいるのか？
よく考えてごらん。
499 ：仕様書無しさん：2006/03/10(金) 13:42:27
(C/C++)AMG高級ベンツはセダン最高速ギネスを持つ。
オーナーは大いなる速度と安全のゆとりを心に
100kmでクルーズする。本気を出せば(Java)軽自動車は
はるか後方の視界から消え去る。
オーナーは大いなる速度と安全のゆとりを心に
100kmでクルーズする。本気を出せば(Java)軽自動車は
はるか後方の視界から消え去る。
498は真性のですね
得意満面で間抜け発言
さすがJava厨
おみそれしました
得意満面で間抜け発言
さすがJava厨
おみそれしました
501 ：仕様書無しさん：2006/03/10(金) 14:05:10
(C/C++)AMGベンシを駐車場にとめた。
隣に駐車していた(Java)汚い軽自動車に乗ったデブおたくが
濁った目つきをしている。うらやましいんだな。かわいそうに。
漏れは静かにその場を立ち去った。
隣に駐車していた(Java)汚い軽自動車に乗ったデブおたくが
濁った目つきをしている。うらやましいんだな。かわいそうに。
漏れは静かにその場を立ち去った。
502 ：仕様書無しさん：2006/03/10(金) 14:44:10
軽量なC/C++が軽自動車で重量なJavaがAMGベンシならわかるんだが
どちらにしてもオタクが考えそうなくだらない例えだな
どちらにしてもオタクが考えそうなくだらない例えだな
503 ：仕様書無しさん：2006/03/10(金) 14:53:06
俺はバリバリにチューンしたケータハムスーパー７(C/C++)で峠を攻めまくる。
「こいつは年代物で手がかかるがきちんとメンテしてやればすごい性能を発揮するぜ」
最近、峠にゃユーノスロードスター（Java)が増えた。
あいつら、ロータスをパクリって作った車でオープンスポーツなんて言ってるがダセーやつ等だ。
あいつらが華麗に走り去る俺を羨望の眼差しで見ているのを感じつつ、俺はアクセルを踏み込んだ。
・・・くそ、オーバーヒートだ。今日はご機嫌斜めらしいな。
「こいつは手がかかるがきちんとメンテしてやればすごい性能を発揮するぜ。」
俺はそうつぶやきながら車を降りてボンネットを開けた。
その脇をユーノスロードスター（Java)がちんたらと走り抜ける。
「けっ、どうせ日本車乗りにはメカいじりなんて出来ないんだろ？」
快調に走り去るやつ等を鼻で笑い、俺はエンジンの調整に取り掛かった。
雨が降ってきた・・・夜までに帰れればいいなぁ・・・・
「こいつは年代物で手がかかるがきちんとメンテしてやればすごい性能を発揮するぜ」
最近、峠にゃユーノスロードスター（Java)が増えた。
あいつら、ロータスをパクリって作った車でオープンスポーツなんて言ってるがダセーやつ等だ。
あいつらが華麗に走り去る俺を羨望の眼差しで見ているのを感じつつ、俺はアクセルを踏み込んだ。
・・・くそ、オーバーヒートだ。今日はご機嫌斜めらしいな。
「こいつは手がかかるがきちんとメンテしてやればすごい性能を発揮するぜ。」
俺はそうつぶやきながら車を降りてボンネットを開けた。
その脇をユーノスロードスター（Java)がちんたらと走り抜ける。
「けっ、どうせ日本車乗りにはメカいじりなんて出来ないんだろ？」
快調に走り去るやつ等を鼻で笑い、俺はエンジンの調整に取り掛かった。
雨が降ってきた・・・夜までに帰れればいいなぁ・・・・
504 ：仕様書無しさん：2006/03/10(金) 14:57:17
暇なオタクだなｗｗｗ
505 ：仕様書無しさん：2006/03/10(金) 15:15:31
いや、20年前の高級セダンに糞パーツをつぎはぎにした
DQN VIPがJavaだろう。まともなものが本体、パーツともに全くない。
DQN VIPがJavaだろう。まともなものが本体、パーツともに全くない。
Java厨ねぇ。。。。
どっちかというと、ど遅いくせに思い込みで速いと信じて、壊れまくりなのにそれを
悦に逝ってるようなアルファ乗り（それも古いGTAとか）って感じじゃね？
どっちかというと、ど遅いくせに思い込みで速いと信じて、壊れまくりなのにそれを
悦に逝ってるようなアルファ乗り（それも古いGTAとか）って感じじゃね？
【バブル世代】必殺！思考停止！！【今北産業】
508 ：仕様書無しさん：2006/03/10(金) 20:01:49
>>506 そこを壊れないように性能を引き出すのが真のエンスージアスト
エンスーという表現は他の言語厨のほうがお似合い。
Javaの仕事が圧倒的に多い。
Javaの仕事が圧倒的に多い。
適材適所でいいでないの？って一般論は何度となく言われてるんだろうな
Javaに適所が見当たらないってこと。今のところ携帯ぐらいか。
速度が求められるソフトでなければ作るのが簡単な言語が一番いいだろ。
別にそれがC++とJavaならJavaかな。
オレならRubyでやるが。
別にそれがC++とJavaならJavaかな。
オレならRubyでやるが。
wxWigetsとJavaどっちがいい？って聞かれたらJavaを取る
出来ないことも多いけど、それを無視できるくらいJavaは使いやすい
出来ないことも多いけど、それを無視できるくらいJavaは使いやすい
514 ：仕様書無しさん：2006/03/10(金) 22:39:24
俺にとってはC++がなによりも簡単。そしてなんでも出来るパワフルさ。
そして速度も出るのでJavaは選択範囲外。Java嫌いって俺みたいなやつの事?
別に嫌いでもなんでもなくてただ遅くてダサくて使えねえって相手にしてね
だけなんだけどね。そこがJava昼さんには面白くないのかな。
そして速度も出るのでJavaは選択範囲外。Java嫌いって俺みたいなやつの事?
別に嫌いでもなんでもなくてただ遅くてダサくて使えねえって相手にしてね
だけなんだけどね。そこがJava昼さんには面白くないのかな。
相手にしてないという割りに4行びっしり
気になって気になって仕方ないのかｗ
気になって気になって仕方ないのかｗ
516 ：仕様書無しさん：2006/03/10(金) 22:46:43
いやね、閑散としているこのスレもすこしは盛り上げてやろうと思ってな。
相手にしてないのに盛り上げる？？？
授業でC++習ってその気になっちゃったのかな、このお子様ｗ
授業でC++習ってその気になっちゃったのかな、このお子様ｗ
518 ：仕様書無しさん：2006/03/10(金) 22:53:02
無印大学卒の低脳君 頭か高いぞよ
ぼくたんはちょうがくちぇいのてんちゃいC++ぷろぐらまだぞ
ぼくたんはちょうがくちぇいのてんちゃいC++ぷろぐらまだぞ
C++なんか遅くて使えねぇよ。
言語と言えばCだ、C。
オブジェクト指向な処理が必要なときも、そこを含めてCでコーディングしてやればいいだろが。
言語と言えばCだ、C。
オブジェクト指向な処理が必要なときも、そこを含めてCでコーディングしてやればいいだろが。
Cなんか遅くて使えねぇよ。
全ての言語は最終的に機械語に変換されて動いてんだ。
それなら最初から機械語で書くのが一番効率いいだろが。
全ての言語は最終的に機械語に変換されて動いてんだ。
それなら最初から機械語で書くのが一番効率いいだろが。
ぶっちゃけJNI作るときはC++じゃなくてC使うな
D言語もCを呼び出せるのにC++はダメだったり
D言語もCを呼び出せるのにC++はダメだったり
>>499
ベンツが実用性あるとでも？
ベンツが実用性あるとでも？
結局C++はマニュアル車でJavaはオートマってとこか。
で、オレ車乗らないんだがお前らどっち乗ってんだ？
で、オレ車乗らないんだがお前らどっち乗ってんだ？
オートマ。おやじのトラック借りるときだけマニュアル
免許はマニュアルで車はオートマだな
で、C++/Java/C#使いな俺
で、C++/Java/C#使いな俺
別に車に例えんでもええんよ。
スレタイが「Javaは遅いという奴は遅れたバブル世代じゃね？」だから
それについて語ればいい。
ただ語るにあたっての問題として、Javaの処理速度を何と比較して
遅いというのかを、知障の>>1が明示していないからスレが混沌とするんだ。
おら！>>1出て来い。
何と比較してんのか、ハッキリしてくれよ。頼むから。
CPUレベルでJavaVMの手厚いサポートをしない限り、CPUネイティブコード
を出力できるアセンブラやCには勝てないってことだ。
ハッキリ言って、JavaはCPUネイティブコードを実行できない以上
その点について語るとBasicと全く変わらん。
スレタイが「Javaは遅いという奴は遅れたバブル世代じゃね？」だから
それについて語ればいい。
ただ語るにあたっての問題として、Javaの処理速度を何と比較して
遅いというのかを、知障の>>1が明示していないからスレが混沌とするんだ。
おら！>>1出て来い。
何と比較してんのか、ハッキリしてくれよ。頼むから。
CPUレベルでJavaVMの手厚いサポートをしない限り、CPUネイティブコード
を出力できるアセンブラやCには勝てないってことだ。
ハッキリ言って、JavaはCPUネイティブコードを実行できない以上
その点について語るとBasicと全く変わらん。
531 ：仕様書無しさん：2006/03/11(土) 19:14:46
おいおい、BASICですらVB6やQuickBASICはネィティブコードを吐くぞ。それも結構速い。
だから何だと。
533 ：仕様書無しさん：2006/03/11(土) 19:32:00
何言ってもだめだよ。ここの>>1はあの有名な「大規模開発君」だから
なんだスピードの事か。
他の言語じゃセキュリティ考慮して作るのは困難だから、Javaのかわりには
ならないよ。
他の言語じゃセキュリティ考慮して作るのは困難だから、Javaのかわりには
ならないよ。
>>535
おまいさ、今の今までスピードがテーマになってるって気づかなかったの？ｗｗｗ
マジで？絶対、PGに向いてないな。いや、他の仕事にも向いてないよ。
リアルドカタでも注意不足で怪我したり同僚に怪我させたりで無理だと思うよ。
おまいさ、今の今までスピードがテーマになってるって気づかなかったの？ｗｗｗ
マジで？絶対、PGに向いてないな。いや、他の仕事にも向いてないよ。
リアルドカタでも注意不足で怪我したり同僚に怪我させたりで無理だと思うよ。
>>536
２ch依存症のお前より数倍マシw
２ch依存症のお前より数倍マシw
>>535
>なんだスピードの事か。
うん。そうそう。
処理速度の話してんのよ。
>他の言語じゃセキュリティ考慮して作るのは困難だから、Javaのかわりには
>ならないよ。
おまいｗ。
処理速度の話って事で理解してるのに、次の行でその理解を覆してどーすんのよ？
記憶障害？
>なんだスピードの事か。
うん。そうそう。
処理速度の話してんのよ。
>他の言語じゃセキュリティ考慮して作るのは困難だから、Javaのかわりには
>ならないよ。
おまいｗ。
処理速度の話って事で理解してるのに、次の行でその理解を覆してどーすんのよ？
記憶障害？
とりあえず、>>537はｽﾚﾀｲを30回声出して読め。
他言語の厨房の皆さんは、スピード以外は誇れるものが無いという理解であってますか?
>>539
イ ヤ だ w
イ ヤ だ w
542 ：仕様書無しさん：2006/03/11(土) 19:52:44
なんだか、このスレおもしれーなwwwwwwww
お気に入りに追加っと。
言語言語っていう割には、Java厨はスレタイの日本語も読めないヤツばっかりか
お気に入りに追加っと。
言語言語っていう割には、Java厨はスレタイの日本語も読めないヤツばっかりか
Javaはセキュリティに完璧な言語ってスレ立てるか？
546 ：仕様書無しさん：2006/03/11(土) 19:56:28
>>544
残念ながら今はJavaやってないので厨とは言いがたい
残念ながら今はJavaやってないので厨とは言いがたい
548 ：仕様書無しさん：2006/03/11(土) 19:56:53
おい、大規模開発==>>1
漏れのお陰で人気が出てきたじゃねーかｗ
漏れのお陰で人気が出てきたじゃねーかｗ
>>548
きみイタイね。
きみイタイね。
550 ：仕様書無しさん：2006/03/11(土) 19:58:22
日本語読めないJava厨が暴れていると聞いて飛んできますた。
必死にageちゃうところが可愛いな。
なんだかオラ、ワクワクしてきたぞ。
>>1はどこ〜？
>>1はどこ〜？
さあ、盛り上がってきました！
爺どもうざすぎ
>>530
そもそも、Javaの速度に不満があるからJavaよりもC/C++の
ほうがいいっていうならさ、C/C++の仕事はまだまだたっぷりあるはずなんだけど。
それなのに、仕事は少なくJavaが圧倒的だし
最近じゃC/C++の価値が認められなくなってきている。
だから今更Javaは遅いとグダグダ文句言っても無駄なんじゃいかね。
体感的にもJavaで作られたものが遅いと感じる場面も減ってきた。
数値では差が出てももう誤差の範囲内でだれも気にしない。
Javaの速度を気にしているのはJavaが斬らない人やJavaの仕事が増えると
困る人たちだけでしょうな。そういう人たちが「Javaって重くね」みたいな
スレを立てて愚痴を零している。かれらもろくに数値を出さないから信用されてないけどね。
そもそも、Javaの速度に不満があるからJavaよりもC/C++の
ほうがいいっていうならさ、C/C++の仕事はまだまだたっぷりあるはずなんだけど。
それなのに、仕事は少なくJavaが圧倒的だし
最近じゃC/C++の価値が認められなくなってきている。
だから今更Javaは遅いとグダグダ文句言っても無駄なんじゃいかね。
体感的にもJavaで作られたものが遅いと感じる場面も減ってきた。
数値では差が出てももう誤差の範囲内でだれも気にしない。
Javaの速度を気にしているのはJavaが斬らない人やJavaの仕事が増えると
困る人たちだけでしょうな。そういう人たちが「Javaって重くね」みたいな
スレを立てて愚痴を零している。かれらもろくに数値を出さないから信用されてないけどね。
Java擁護派は、ようやくスレタイの内容を理解したのか
姿を見せなくなったぞ。
この議題だと、どうやってもJavaの優位性はないからな。
Javaのメリットなんか、ホストOSを選ばずに同じバイナリを
実行できる(予定)だけだもんな。
まぁゲイツ様に横槍いれられておかしくなったが。
姿を見せなくなったぞ。
この議題だと、どうやってもJavaの優位性はないからな。
Javaのメリットなんか、ホストOSを選ばずに同じバイナリを
実行できる(予定)だけだもんな。
まぁゲイツ様に横槍いれられておかしくなったが。
C++の仕事ならいくらでもありまっせ。ドカタには門前払いなだけで。
つうか、ドカタがもらえるのは一山いくらのドカタ仕事しかないから、派遣会社に溢れてるような
状況じゃないと困るんだろうけどな。
つうか、ドカタがもらえるのは一山いくらのドカタ仕事しかないから、派遣会社に溢れてるような
状況じゃないと困るんだろうけどな。
>>536
このスレの趣旨はスピードがテーマなんじゃなくて
なぜバブル世代以降はJavaが遅いといつまで経っても
虚しく叫び続けるのかってことじゃないかと。
俺の結論としては、Java系に仕事が奪われて
愚痴を零している人たちがJavaを槍玉に挙げて重たいだの
なんだのとFUD攻撃を仕掛けているだけだと見ている。
MicrosoftがLinuxやオープンソースをFUB攻撃するように、
彼らはJavaに対してFUD攻撃をしている。
このスレの趣旨はスピードがテーマなんじゃなくて
なぜバブル世代以降はJavaが遅いといつまで経っても
虚しく叫び続けるのかってことじゃないかと。
俺の結論としては、Java系に仕事が奪われて
愚痴を零している人たちがJavaを槍玉に挙げて重たいだの
なんだのとFUD攻撃を仕掛けているだけだと見ている。
MicrosoftがLinuxやオープンソースをFUB攻撃するように、
彼らはJavaに対してFUD攻撃をしている。
↑妄想
Javaの案件ってWebしかないやん
実はおれ、javaもc(はずいぶん前にやめた)もやってないんだよ。
今はphp+mysqlでしかやってない。
ブラウザさえあればどうにかなるってアプリが最高だよ。
ただ、javaの処理速度について議論している不思議連中がいるから
ちょっとツッコミをと・・・。
javaは処理速度とか言う点について狙った言語じゃねーだろと。
今はphp+mysqlでしかやってない。
ブラウザさえあればどうにかなるってアプリが最高だよ。
ただ、javaの処理速度について議論している不思議連中がいるから
ちょっとツッコミをと・・・。
javaは処理速度とか言う点について狙った言語じゃねーだろと。
>>564
お前の脳内ではたぶん、その通りだろう。
お前の脳内ではたぶん、その通りだろう。
Webならphp
釣れた！
>>562
それが妄想であるという科学的根拠を述べてみよ
それが妄想であるという科学的根拠を述べてみよ
575 ：仕様書無しさん：2006/03/11(土) 20:15:27
Javaは早い
>>566
> 実はおれ、javaもc(はずいぶん前にやめた)もやってないんだよ。
> 今はphp+mysqlでしかやってない。
おいおいw PHPごときでJavaに刃向かうとは蟻が像に喧嘩を売ってるようなもんだぞw
> 実はおれ、javaもc(はずいぶん前にやめた)もやってないんだよ。
> 今はphp+mysqlでしかやってない。
おいおいw PHPごときでJavaに刃向かうとは蟻が像に喧嘩を売ってるようなもんだぞw
オィイイイィィィィ！
話が曲がってる、曲がってるヨォォオオオォオ。
結局、このスレは何についてカキコすればいい訳？
java遅いっていう連中をバカにするスレ？
それとも
スレタイは何の言語と比較して遅いのか語り合うスレ？
話が曲がってる、曲がってるヨォォオオオォオ。
結局、このスレは何についてカキコすればいい訳？
java遅いっていう連中をバカにするスレ？
それとも
スレタイは何の言語と比較して遅いのか語り合うスレ？
>>569
結論としてはJavaとCとでは速度差はさほど変わらなくなったってことだよ。
その結論も、もうすでに5年以上前からでているけどね。
それも、J2SE 1.3が出た時点でさ。
Java SE 5になってからさらに高速化しているけれどもね。
結論としてはJavaとCとでは速度差はさほど変わらなくなったってことだよ。
その結論も、もうすでに5年以上前からでているけどね。
それも、J2SE 1.3が出た時点でさ。
Java SE 5になってからさらに高速化しているけれどもね。
C言語厨は逃亡しますたｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
>>577
両方。
バブル世代以降の頭が堅い連中は
完了みたいで
Javaが気に入らなくてどうしてもJavaの仕事をする者を
C/C++の仕事をする者よりも低く見立てたいらしい。
そうでないと自分の立場がなくなるってことなんだろう
両方。
バブル世代以降の頭が堅い連中は
完了みたいで
Javaが気に入らなくてどうしてもJavaの仕事をする者を
C/C++の仕事をする者よりも低く見立てたいらしい。
そうでないと自分の立場がなくなるってことなんだろう
いや、わざわざ見せなくても実際低いし。
>>576
だから〜。
言語には得手不得手があるでしょ。
phpのメリットはクライアントにブラウザがありさえすれば機種を問わないこと。
それを考えたら、javaはphpよりえらいってことはないよ。
っちうか、もーjavaじゃなくて、.netでいいや。
だから〜。
言語には得手不得手があるでしょ。
phpのメリットはクライアントにブラウザがありさえすれば機種を問わないこと。
それを考えたら、javaはphpよりえらいってことはないよ。
っちうか、もーjavaじゃなくて、.netでいいや。
素朴な疑問。
携帯のファームをCで組んでる奴と携帯アプリをJavaで組んでる奴ってどっちが上なの？
携帯のファームをCで組んでる奴と携帯アプリをJavaで組んでる奴ってどっちが上なの？
C言語厨の愚痴も一気に収まった。
仕事が無くて困ってると見た。
もしくは、C/C++は組み込み系の仕事ばっかで
昔全盛期だったVC++を使ったスタンドアロンアプリ開発の
仕事が無くなってがっくりきてる連中なんだろう。
仕事が無くて困ってると見た。
もしくは、C/C++は組み込み系の仕事ばっかで
昔全盛期だったVC++を使ったスタンドアロンアプリ開発の
仕事が無くなってがっくりきてる連中なんだろう。
>>583
携帯電話開発をやってる時点でどっちも下。
メモリ容量が増えれば増えるほどJava系がゆ優位にたてることは間違いないけど。
メモリ容量が限られてくると設計しづらくなるのでC/C++が優位ってことかな。
携帯電話開発をやってる時点でどっちも下。
メモリ容量が増えれば増えるほどJava系がゆ優位にたてることは間違いないけど。
メモリ容量が限られてくると設計しづらくなるのでC/C++が優位ってことかな。
php結構お仕事あるじょ。ウフフ。
結構どころか去年の後半から明らかにJavaを食ってる。＜php
Javaは汎用的過ぎるんだよ。
アプレットがフラッシュに完敗したように、サーバササイドでもそれに特化した言語に破れるだろう。
アプレットがフラッシュに完敗したように、サーバササイドでもそれに特化した言語に破れるだろう。
フロントエンドは、他ので構わないという結論は
Javaの開発陣営がすでに出しているみたいよ。
Javaの開発陣営がすでに出しているみたいよ。
バックエンドもコボルで構いません。
オレ的には、php+java script+mysqlで事足りるっす。
やっぱお客の環境に追加インストール不要で動くアプリってのが
ウケがいいよね！
議題と違うって怒られるかな・・・？
やっぱお客の環境に追加インストール不要で動くアプリってのが
ウケがいいよね！
議題と違うって怒られるかな・・・？
592 ：仕様書無しさん：2006/03/11(土) 20:31:30
mysqlって素人用の玩具だろ。エンタープライズ用途に使えるか。バカ
>>591
お前は、その構成で一生幸せに暮らせばいいんじゃね?
お前は、その構成で一生幸せに暮らせばいいんじゃね?
エンタープライズ用途ならCOBOLだ。これだけは間違いない。
>>588
お前は、Javaを破る言語が出てくるまで待ってればいいんじゃね?
お前は、Javaを破る言語が出てくるまで待ってればいいんじゃね?
597 ：仕様書無しさん：2006/03/11(土) 20:35:22
Javaって遅いの？
>>597
もうね、市になさい
もうね、市になさい
>>599
ついでに、市になさい
ついでに、市になさい
>>600
おれもか〜〜〜
おれもか〜〜〜
>>586
ちっちゃい仕事がね。
最近はJavaより目立ってきたけど
EJB関係だとちょっと弱いな。
Javaでたっぷり金を稼ぐならEJB関係
ちょっと金を稼ぐなら非EJBなるJava(POJO)またはPHP(Lamp)ってところかね。
ちっちゃい仕事がね。
最近はJavaより目立ってきたけど
EJB関係だとちょっと弱いな。
Javaでたっぷり金を稼ぐならEJB関係
ちょっと金を稼ぐなら非EJBなるJava(POJO)またはPHP(Lamp)ってところかね。
ＥＪＢって本当に使いものにならないよな。
Sunが見捨てるくらいに。
Sunが見捨てるくらいに。
>>588
アプレットは当時は重たかったから流行らなかったのと
MSJVMの影響があったことに起因するよ。
Flashプラグインとくらべ自動インストールもしづらかったってのもあるけど。
それも、今じゃ、Java Web Startで代替してるってところかね。
大学や研究機関ではApplet使ってるところが多く論文でもApplet
使ったサンプルが多いけどね。
アプレットは当時は重たかったから流行らなかったのと
MSJVMの影響があったことに起因するよ。
Flashプラグインとくらべ自動インストールもしづらかったってのもあるけど。
それも、今じゃ、Java Web Startで代替してるってところかね。
大学や研究機関ではApplet使ってるところが多く論文でもApplet
使ったサンプルが多いけどね。
>>591
> オレ的には、php+java script+mysqlで事足りるっす。
> やっぱお客の環境に追加インストール不要で動くアプリってのが
> ウケがいいよね！
追加インストールの自動化だったらJavaでもできる。
そえれと、そこにあるJava ScriptというのはAjaxってところか。
Ajaxの開発はちと大変かと思うが。情報が少なすぎてGoogle Mapsの
真似をするには慣れがいる。
> オレ的には、php+java script+mysqlで事足りるっす。
> やっぱお客の環境に追加インストール不要で動くアプリってのが
> ウケがいいよね！
追加インストールの自動化だったらJavaでもできる。
そえれと、そこにあるJava ScriptというのはAjaxってところか。
Ajaxの開発はちと大変かと思うが。情報が少なすぎてGoogle Mapsの
真似をするには慣れがいる。
ﾜﾗﾀ
規模の問題ってのもあるよね。
たいていの場合は社員スケジュール&勤怠管理システムとかいって
安価なサーバと一緒にお客に買ってもらう。
こんなんにoracleとかmssqlとかいらなくて、php+mysqlとかで
安価に済ませることができる。
一回作ってしまえば、同じシステムをいろいろなお客に売ることができて
結構いいカセギ
確かにイイ金もらって、そのお客専用のアプリを売るってのもやり方だけど
こういうのもいいぞう。
たいていの場合は社員スケジュール&勤怠管理システムとかいって
安価なサーバと一緒にお客に買ってもらう。
こんなんにoracleとかmssqlとかいらなくて、php+mysqlとかで
安価に済ませることができる。
一回作ってしまえば、同じシステムをいろいろなお客に売ることができて
結構いいカセギ
確かにイイ金もらって、そのお客専用のアプリを売るってのもやり方だけど
こういうのもいいぞう。
本当はソフトウェアはそうあるべきなんだよ。製造コストがかからないのだから。
顧客の我侭に徹底的に付き合って、作業に応じて請求する業務系のスタイルはドカタそのもの。
顧客の我侭に徹底的に付き合って、作業に応じて請求する業務系のスタイルはドカタそのもの。
>>594
Java関係の仕事で、 JBossとサーバ製品とを
セットにしたほうが売れるっていうのがあって、
POJOよりもJBoss(EJB)のほうがたっぷりと金が入ってくる。
PHPの仕事は一件多そうに見えるけど、
今話題になってるのはJava関係のSeasar2とSpring Frameworkと
Ruby on Rails, Ajaxだね。
PHPではJava対応フレームワークのPHP化が進むだろうって話題が出ているけど、
PHPは名前空間が使えないからフレームワークの機能性の限界があるかもしれない。
それにデバッグしにくい。PHPは巨大化すればするほど不利になる。
PHP自体の言語仕様をどうにか改善しない限りなにもかも
フレームワークだけPHPやJavaの真似ばかりしてもJavaに勝るのは苦しい。
Perlの案件をPHPに置き換えるという仕事としては最適だろうけど。
PHPの案件はお金のない顧客から多く来るので多少はしばらくPHPだけで食っていけるかも知れないね。
お金のある顧客からはJavaの案件をとれる。といった感じ。
とりあえず、今プログラマとして金に困らなくするにはPHPとJavaを覚えておくってところかね。
それからPerlも知っておいた方が良いね。
Java関係の仕事で、 JBossとサーバ製品とを
セットにしたほうが売れるっていうのがあって、
POJOよりもJBoss(EJB)のほうがたっぷりと金が入ってくる。
PHPの仕事は一件多そうに見えるけど、
今話題になってるのはJava関係のSeasar2とSpring Frameworkと
Ruby on Rails, Ajaxだね。
PHPではJava対応フレームワークのPHP化が進むだろうって話題が出ているけど、
PHPは名前空間が使えないからフレームワークの機能性の限界があるかもしれない。
それにデバッグしにくい。PHPは巨大化すればするほど不利になる。
PHP自体の言語仕様をどうにか改善しない限りなにもかも
フレームワークだけPHPやJavaの真似ばかりしてもJavaに勝るのは苦しい。
Perlの案件をPHPに置き換えるという仕事としては最適だろうけど。
PHPの案件はお金のない顧客から多く来るので多少はしばらくPHPだけで食っていけるかも知れないね。
お金のある顧客からはJavaの案件をとれる。といった感じ。
とりあえず、今プログラマとして金に困らなくするにはPHPとJavaを覚えておくってところかね。
それからPerlも知っておいた方が良いね。
ZendのIDE知ってる？
>>603
だから最新版ＥＪＢでは使いやすくなるんだよ。
JBossはすでにアノテーションが使えるようになってかなり使いやすくなった。
Java SE5のアノテーションとPOJOの影響を受けてEJBもかなり進化したよ。
Seasar2やJSFと組み合わせればかなり効率よくスムーズに開発できる。
だから最新版ＥＪＢでは使いやすくなるんだよ。
JBossはすでにアノテーションが使えるようになってかなり使いやすくなった。
Java SE5のアノテーションとPOJOの影響を受けてEJBもかなり進化したよ。
Seasar2やJSFと組み合わせればかなり効率よくスムーズに開発できる。
もう騙されないよ
やっぱasp.netが一番開発効率いいね。
>>607
最近じゃEJBがついてないものは価値がないと見る企業が多くて
POJO(Plain Old Java Opject (EJB不使用))やLamp(Linus + Apache + MySQL + PHP)
だけじゃJavaエンジニアとして商売しづらい。
最近じゃEJBがついてないものは価値がないと見る企業が多くて
POJO(Plain Old Java Opject (EJB不使用))やLamp(Linus + Apache + MySQL + PHP)
だけじゃJavaエンジニアとして商売しづらい。
>>610
Zend Studioは金がかかるからイマイチだと思う。
PHP Editorのほうが世下げに見える。
もれはPHPEclipse使ってるけど。
Java開発だってタダってところは多いしね。
Zend Studioは金がかかるからイマイチだと思う。
PHP Editorのほうが世下げに見える。
もれはPHPEclipse使ってるけど。
Java開発だってタダってところは多いしね。
>>613
悪いが、いまどきASP.NET単体でやるなんてちょっと終わってると思う。
JavaだってJSP + Servletという組み合わせだけでなく
StrutsやJSFと組み合わせている。それだけでなくＤＩコンテナの
Seasar2やSpring Frameworkを組み合わせている。
それにHibernateを組み合わせたものも。
それに、POJOではないEJBが使えるJBossにはSpringとHibernateが入っている。
ASP.ＮＥＴはC#でGenericsが使えないとちょっとねえ。
それにApacheでまともに動く環境がまずないと。
それに、.NETの世界だって.NETに対応したSpring FrameworkのDI(Dependency Injection)の影響を
受けてSpring.NETやNSpringなるものが開発されている。
悪いが、いまどきASP.NET単体でやるなんてちょっと終わってると思う。
JavaだってJSP + Servletという組み合わせだけでなく
StrutsやJSFと組み合わせている。それだけでなくＤＩコンテナの
Seasar2やSpring Frameworkを組み合わせている。
それにHibernateを組み合わせたものも。
それに、POJOではないEJBが使えるJBossにはSpringとHibernateが入っている。
ASP.ＮＥＴはC#でGenericsが使えないとちょっとねえ。
それにApacheでまともに動く環境がまずないと。
それに、.NETの世界だって.NETに対応したSpring FrameworkのDI(Dependency Injection)の影響を
受けてSpring.NETやNSpringなるものが開発されている。
C言語厨の出る幕が無くなったねw
今話題になってるのはC言語厨にとって非常に都合の悪い分野だからw
webのこともDIコンテナのことも名前を聞きかじっただけで
C言語厨には全然わかんないでしょうw
今話題になってるのはC言語厨にとって非常に都合の悪い分野だからw
webのこともDIコンテナのことも名前を聞きかじっただけで
C言語厨には全然わかんないでしょうw
618 ：仕様書無しさん：2006/03/11(土) 21:07:09
もうO/Rマッピングが実用になるとは誰も思ってないよ。
>>617
それは言わないのが大人の対応
それは言わないのが大人の対応
＞StrutsやJSFと組み合わせている。それだけでなくＤＩコンテナの
＞Seasar2やSpring Frameworkを組み合わせている。
＞それにHibernateを組み合わせたものも。
そしてどこも火を吹いているｗ
＞Seasar2やSpring Frameworkを組み合わせている。
＞それにHibernateを組み合わせたものも。
そしてどこも火を吹いているｗ
>>620
成功事例が極端に少ないね。もっとアピールしてもらわないと。
成功事例が極端に少ないね。もっとアピールしてもらわないと。
Java案件が火を噴く原因として、常に新しいものを取り込んでいくから技術者がずっと未成熟
だからというのがある。ここにもそれがわかってないバカがいる。
だからというのがある。ここにもそれがわかってないバカがいる。
紺猿がそれを謳い文句に売り込んでいく。それはJavaの宿命
>>613
いや、RoR最強でしょ？
うちの内製バグトラッカーがRoR製なんだけど、初出まで2人x3日。
これは速いよ、驚異的。
そこから実用に持っていくまでにはそれなりの時間が掛ってるけ
ど、こりゃスゲーなと思ったよ。
いや、RoR最強でしょ？
うちの内製バグトラッカーがRoR製なんだけど、初出まで2人x3日。
これは速いよ、驚異的。
そこから実用に持っていくまでにはそれなりの時間が掛ってるけ
ど、こりゃスゲーなと思ったよ。
Ruby(笑
実際のとこ、使えるのはServletだけでそ。
ASP.ＮＥＴはC#でGenericsが使えないとちょっとねえ。
それにApacheでまともに動く環境がまずないと。
それに、.NETの世界だって.NETに対応したSpring FrameworkのDI(Dependency Injection)の影響を
受けてSpring.NETやNSpringなるものが開発されている。
実際に活用してみてASP.NET単体じゃ終わってるって事を分かりやすく説明してくれよ。
それにApacheでまともに動く環境がまずないと。
それに、.NETの世界だって.NETに対応したSpring FrameworkのDI(Dependency Injection)の影響を
受けてSpring.NETやNSpringなるものが開発されている。
実際に活用してみてASP.NET単体じゃ終わってるって事を分かりやすく説明してくれよ。
ここだけの話Velocityはかなり融通がきく
注文・請求メール、メルマガ、Webサイト、その他文書整形全般
いろんなことに使い回しが可能だからリソースの集約に役立つ
注文・請求メール、メルマガ、Webサイト、その他文書整形全般
いろんなことに使い回しが可能だからリソースの集約に役立つ
そういや最近聞かなくなったな＜velocity
技術が枯れると話題も枯れるのがJavaの世界だな
再利用可能コンポーネントの側面から見て
枯れるというのは歓迎すべきことなのに
再利用可能コンポーネントの側面から見て
枯れるというのは歓迎すべきことなのに
ちょっと流行に弱い人が集ってるよな。
633 ：仕様書無しさん：2006/03/11(土) 22:18:25
もし枯れたとしら
パフォーマンスの不満とかリファクタリングの必然がぞろぞろ出てきて
ごちゃごちゃいじらなきゃならないほどダサいからじゃね
パフォーマンスの不満とかリファクタリングの必然がぞろぞろ出てきて
ごちゃごちゃいじらなきゃならないほどダサいからじゃね
>>632
なにげなﾏｶｰな人が多いところとかアンチM$な人が多いところとかそんな感じ。
なにげなﾏｶｰな人が多いところとかアンチM$な人が多いところとかそんな感じ。
>>634
そりゃ自分のことじゃないのか?
そりゃ自分のことじゃないのか?
当たり前だけど、CはデフォでJavaよか早い。
でもJavaも条件次第ではCよりも早いっつー話なんだけど、
どういう条件。実体験で聞きたいんだが。
でもJavaも条件次第ではCよりも早いっつー話なんだけど、
どういう条件。実体験で聞きたいんだが。
Javaで作られたサーバはリブート要らずだから
そういう長期運用の意味で最後まで最初の頃と同じ速度って意味では？
ハードウェアのメンテまで頬って置ける
そういう長期運用の意味で最後まで最初の頃と同じ速度って意味では？
ハードウェアのメンテまで頬って置ける
いや、そうじゃなくロジックによってはホントに速くなることがある。
稀だがな。
実行速度はさておき、Javaなら速く作れる、というのではダメなのか？
稀だがな。
実行速度はさておき、Javaなら速く作れる、というのではダメなのか？
それはIntelCCなら見逃さないが、GCCなら見逃すみたいな部分を
たまたまJVM JITCCが見逃さなかったからとか、そういう理由なんだろうな
たまたまJVM JITCCが見逃さなかったからとか、そういう理由なんだろうな
古いJavaソースコードも、
J2SE1.4以降から登場したBufferクラスを使って
全てのプリミティブ型配列をBufferオブジェクトに変換して処理すれば
速くなる。配列の要素を全てヒープ領域外に置くことで
C/C++と全く同じ速さで配列を処理できるから。
J2SE1.4以降から登場したBufferクラスを使って
全てのプリミティブ型配列をBufferオブジェクトに変換して処理すれば
速くなる。配列の要素を全てヒープ領域外に置くことで
C/C++と全く同じ速さで配列を処理できるから。
>>621
Hibernate使った成功事例なら国際特許検索システムがある。
Seasar2のことなら「ひがやすを」でぐぐれ。
それにしてもJavaの新技術について知らない奴が随分と多いものだよ。
未だにTomcatの設定もろくに解ってない奴多いし。
知ってる奴はかなりJavaに精通した人間に限られている。
JavaOneやデブサミなどのイベントに参加していれば嫌でも最新情報と
その技術の魅力を知ることになるがそういう情報を得ていない人間は
いつまで経っても古い知識に拘り続けてデスマーチになる。
C言語厨が、Javaが進化していることに気づかず未だに遅い遅いと言ってるみたいにな。
Hibernate使った成功事例なら国際特許検索システムがある。
Seasar2のことなら「ひがやすを」でぐぐれ。
それにしてもJavaの新技術について知らない奴が随分と多いものだよ。
未だにTomcatの設定もろくに解ってない奴多いし。
知ってる奴はかなりJavaに精通した人間に限られている。
JavaOneやデブサミなどのイベントに参加していれば嫌でも最新情報と
その技術の魅力を知ることになるがそういう情報を得ていない人間は
いつまで経っても古い知識に拘り続けてデスマーチになる。
C言語厨が、Javaが進化していることに気づかず未だに遅い遅いと言ってるみたいにな。
>>629-630
うちではVelocityを使ったプログラムをよく書いている。
しかし周りの奴らの技術力が低すぎ。
CやC++やPerlに詳しい奴がいてもJavaの最新技術を知らない馬鹿が
多すぎてXDocletやHibernateを使っても「なぜそんなものが必要なのか理解できない」
と言い張る人間が多すぎる。馬鹿相手に説明するのに非常に苦労する。
素人の顧客相手に説明したほうがはるかに楽だと思えるくらいに。
Cやってた人間は頭が堅い者が多い。古い知識にとらわれすぎて、
Javaのソースコードをちょっと弄っただけでとんでもない事が起きるんじゃないかと
警戒している。たしかにCではそういうことがよくあるが、Java言語の特性を
知っていればちょっと弄ったくらいではとんでもないことが起きる事態も非常に少ない。
「文字列は16ビットだから全角文字を使うときは２文字づつ進めないといけない」とか
「ローカル変数は必ずメソッド内の戦闘で宣言しないといけない」
「ここを弄ったら他は一切弄っては行けない」
「(他社のプログラマ)X氏にソースコードを渡すときに行番号がずれるからimport宣言は弄るな」
「設定ファイルのパスは必ずすべて絶対パスで記述しろ」
変な事ばかり言う。
検索キーワードになるコメントちゃんと書いていれば行番号がずれても
(他社のプログラマ)X氏にコードを渡しても行番号を知らせずにキーワードだけ伝えれば
いいはずなのだが。融通が効かない。
設定ファイルとクラスパスとの関係もわかってないし、web.xmlをXDocletで自動生成
する方法もわかってないので開発するのに非常に疲れる。
馬鹿と一緒に仕事すると開発効率が非常に悪くなる。
もはやC言語病だ。
連中にはせめてJUnitやMaven2やAntくらいは使いこなせるようになってほしい。
うちではVelocityを使ったプログラムをよく書いている。
しかし周りの奴らの技術力が低すぎ。
CやC++やPerlに詳しい奴がいてもJavaの最新技術を知らない馬鹿が
多すぎてXDocletやHibernateを使っても「なぜそんなものが必要なのか理解できない」
と言い張る人間が多すぎる。馬鹿相手に説明するのに非常に苦労する。
素人の顧客相手に説明したほうがはるかに楽だと思えるくらいに。
Cやってた人間は頭が堅い者が多い。古い知識にとらわれすぎて、
Javaのソースコードをちょっと弄っただけでとんでもない事が起きるんじゃないかと
警戒している。たしかにCではそういうことがよくあるが、Java言語の特性を
知っていればちょっと弄ったくらいではとんでもないことが起きる事態も非常に少ない。
「文字列は16ビットだから全角文字を使うときは２文字づつ進めないといけない」とか
「ローカル変数は必ずメソッド内の戦闘で宣言しないといけない」
「ここを弄ったら他は一切弄っては行けない」
「(他社のプログラマ)X氏にソースコードを渡すときに行番号がずれるからimport宣言は弄るな」
「設定ファイルのパスは必ずすべて絶対パスで記述しろ」
変な事ばかり言う。
検索キーワードになるコメントちゃんと書いていれば行番号がずれても
(他社のプログラマ)X氏にコードを渡しても行番号を知らせずにキーワードだけ伝えれば
いいはずなのだが。融通が効かない。
設定ファイルとクラスパスとの関係もわかってないし、web.xmlをXDocletで自動生成
する方法もわかってないので開発するのに非常に疲れる。
馬鹿と一緒に仕事すると開発効率が非常に悪くなる。
もはやC言語病だ。
連中にはせめてJUnitやMaven2やAntくらいは使いこなせるようになってほしい。
>>631
いや、知らない馬鹿が多すぎるだけだよ。
Javaは簡単だといってタカをくくっていると
Javaに精通したライバル企業に先を越される。
今そんな状態が各地で怒っている。
Java Swingは遅いと言われていたが今じゃ、Swing製のNetBeansは
SWTで作られたEclipseよりも速い。
その速さをよく見てみてくれ。
「Javaは遅い遅い」と油断しているととんでもないことになる。
Tomcatしか知らず、StrutsもJSFもHibernateもSpreing FrameworkもMaven知らないで
「Javaなんて簡単だ」なんて言い張るC言語厨はモグリだ。
いや、知らない馬鹿が多すぎるだけだよ。
Javaは簡単だといってタカをくくっていると
Javaに精通したライバル企業に先を越される。
今そんな状態が各地で怒っている。
Java Swingは遅いと言われていたが今じゃ、Swing製のNetBeansは
SWTで作られたEclipseよりも速い。
その速さをよく見てみてくれ。
「Javaは遅い遅い」と油断しているととんでもないことになる。
Tomcatしか知らず、StrutsもJSFもHibernateもSpreing FrameworkもMaven知らないで
「Javaなんて簡単だ」なんて言い張るC言語厨はモグリだ。
Eclipseの遅さはSWTに起因するものじゃないだろう。
647 ：仕様書無しさん：2006/03/12(日) 08:49:02
>>643
長文乙
長文乙
>>644
>「Javaなんて簡単だ」なんて言い張るC言語厨はモグリだ。
えーと、｢簡単｣をキーワードに見た所、少なくともスレでそんな事書いていないのですが・・・。
言語厨であればあるほど、他言語に対する理解が少ないので｢簡単｣って言い張りません。
そもそも経験が少ないからJavaにいわれない事言ってる人が自分の経験論
に基づいて言ってる最中に｢Javaなんて簡単だ｣なんていいますか？
この場合、この業界じゃあ、｢じゃ、Javaで先ほど言った方法でやってくださいね｣
って言うのがデフォルトじゃありませんか？
その程度のことも言えないのなら、低劣なのかお上品な現場
なのかわかりませんけれど、あまり現実的な現場じゃありませんね。
とりあえず馬鹿のプログラマーであればあるほどそういった言っちゃいけないキーワードは
言わないはずですから。
あなたの妄想ですね。
正直この文面から勉強家だけど、組むのは苦手(でもややこしい処理が得意)で、
微妙に多言語に対するコンプレックス(というか優越感)があると見受けられます。
ウザイ奴で、現場で他人の足引っ張る姿を幻視してしまいますね。
>「Javaなんて簡単だ」なんて言い張るC言語厨はモグリだ。
えーと、｢簡単｣をキーワードに見た所、少なくともスレでそんな事書いていないのですが・・・。
言語厨であればあるほど、他言語に対する理解が少ないので｢簡単｣って言い張りません。
そもそも経験が少ないからJavaにいわれない事言ってる人が自分の経験論
に基づいて言ってる最中に｢Javaなんて簡単だ｣なんていいますか？
この場合、この業界じゃあ、｢じゃ、Javaで先ほど言った方法でやってくださいね｣
って言うのがデフォルトじゃありませんか？
その程度のことも言えないのなら、低劣なのかお上品な現場
なのかわかりませんけれど、あまり現実的な現場じゃありませんね。
とりあえず馬鹿のプログラマーであればあるほどそういった言っちゃいけないキーワードは
言わないはずですから。
あなたの妄想ですね。
正直この文面から勉強家だけど、組むのは苦手(でもややこしい処理が得意)で、
微妙に多言語に対するコンプレックス(というか優越感)があると見受けられます。
ウザイ奴で、現場で他人の足引っ張る姿を幻視してしまいますね。
649 ：仕様書無しさん：2006/03/12(日) 09:52:29
650 ：621：2006/03/12(日) 10:18:41
JAVAにはできない領域がある。
それは多の言語で作るしかない。
それは多の言語で作るしかない。
651 ：仕様書無しさん：2006/03/12(日) 10:19:14
>650 多＞他
文章長い奴は信用するなと、うちのじいちゃんが言ってた。
ってか開発に使う言語なんて自分で決められないから全部使えるようにしておくのがいいかと…
そんな私が最初に C という言語に出会った時は、「Cでプログラムを書くのは素人だけだ。
本当のプログラマーはアセンブラだ。それも１６進のマシン語を直接書けなきゃだめだ」
などと生意気なことを言っていたものである。しかし、大学に入ってから作った Candy を
ディスプレイドライバーを除いて全てCで書いたのも私である。
C++ にも最初は抵抗があった。当初はコンパイラの性能も低かったので、とんでもない
コードを生成していたし（コンパイラの吐き出したマシン語を読まずにはいられないたち
であった）、「オブジェクト指向の本質は言語ではない、プログラミングスタイルだ」
（どこかで聞いたことがある）と言いながらあえて C でVTalbleを作ってCOMのプログラミング
をしていたものである（Windows95 には私がCで実装したCOMオブジェクトが複数ある）。
C++ にやっと慣れたころに普及し始めた Java にはもっと抵抗があった。今となっては
笑い話だが、「プログラマー自身がメモリの管理をしないで効率の良いプログラムが
書けるわけがない」と真っ先に批判したのも私である。
本当のプログラマーはアセンブラだ。それも１６進のマシン語を直接書けなきゃだめだ」
などと生意気なことを言っていたものである。しかし、大学に入ってから作った Candy を
ディスプレイドライバーを除いて全てCで書いたのも私である。
C++ にも最初は抵抗があった。当初はコンパイラの性能も低かったので、とんでもない
コードを生成していたし（コンパイラの吐き出したマシン語を読まずにはいられないたち
であった）、「オブジェクト指向の本質は言語ではない、プログラミングスタイルだ」
（どこかで聞いたことがある）と言いながらあえて C でVTalbleを作ってCOMのプログラミング
をしていたものである（Windows95 には私がCで実装したCOMオブジェクトが複数ある）。
C++ にやっと慣れたころに普及し始めた Java にはもっと抵抗があった。今となっては
笑い話だが、「プログラマー自身がメモリの管理をしないで効率の良いプログラムが
書けるわけがない」と真っ先に批判したのも私である。
>655
ちんぽから膿でてねぇ？
ちんぽから膿でてねぇ？
>>650
Javaだけじゃなく全ての言語に言えることだな
>>652
信じちゃいけねぇｗｗｗｗｗｗｗｗｗｗｗ
>>654
常識。
今時、休日PGはそれがわからんのです。
>>655
>由美子のマソコに俺のイチモツが
まで読んだ
Javaだけじゃなく全ての言語に言えることだな
>>652
信じちゃいけねぇｗｗｗｗｗｗｗｗｗｗｗ
>>654
常識。
今時、休日PGはそれがわからんのです。
>>655
>由美子のマソコに俺のイチモツが
まで読んだ
658 ：仕様書無しさん：2006/03/13(月) 11:18:30
おまいらJavaVMってどの言語で実装されているか知ってるの？
Javaのバイトコードってその上で動くんだよ？
Javaが速いならJavaVMを書いている言語はもっと速いよな？
Javaのバイトコードってその上で動くんだよ？
Javaが速いならJavaVMを書いている言語はもっと速いよな？
JavaVMはPascalで書かれてるよ
660 ：仕様書無しさん：2006/03/13(月) 11:27:26
>>658
F1カーを作っている人たちは世界で一番早く走れるんだな
F1カーを作っている人たちは世界で一番早く走れるんだな
661 ：仕様書無しさん：2006/03/13(月) 11:45:45
>>648
> >>644
> >「Javaなんて簡単だ」なんて言い張るC言語厨はモグリだ。
> えーと、｢簡単｣をキーワードに見た所、少なくともスレでそんな事書いていないのですが・・・。
簡単というか馬鹿でもできるとかドカタや素人でもできると
煽ってる厨がいるんだろ。dat落ちした記事を検索すると
そういう煽りレスがみつかることがあると思う。
> >>644
> >「Javaなんて簡単だ」なんて言い張るC言語厨はモグリだ。
> えーと、｢簡単｣をキーワードに見た所、少なくともスレでそんな事書いていないのですが・・・。
簡単というか馬鹿でもできるとかドカタや素人でもできると
煽ってる厨がいるんだろ。dat落ちした記事を検索すると
そういう煽りレスがみつかることがあると思う。
>>648
> そもそも経験が少ないからJavaにいわれない事言ってる人が自分の経験論
> に基づいて言ってる最中に｢Javaなんて簡単だ｣なんていいますか？
> とりあえず馬鹿のプログラマーであればあるほどそういった言っちゃいけないキーワードは
> 言わないはずですから。
馬鹿ほどハッタリかまして見栄を張るために簡単だって言う傾向があると思うけど。
言っちゃ行けないっといっても言う馬鹿はいるんだからw
Java嫌いな奴ほどよく言う。
> そもそも経験が少ないからJavaにいわれない事言ってる人が自分の経験論
> に基づいて言ってる最中に｢Javaなんて簡単だ｣なんていいますか？
> とりあえず馬鹿のプログラマーであればあるほどそういった言っちゃいけないキーワードは
> 言わないはずですから。
馬鹿ほどハッタリかまして見栄を張るために簡単だって言う傾向があると思うけど。
言っちゃ行けないっといっても言う馬鹿はいるんだからw
Java嫌いな奴ほどよく言う。
>>649
> あれなんだなあ、>>643は最大公約数って知らないんだなあ。
> 分数の分母をそろえないで必死に計算するタイプなんだよなあ。
おいおい、分母をそろえないでどうやって精度を維持して計算できるって
いうんだw 運良く割り切れればいいけどよw
喩えのセンスが悪いぞ。XDocletが割ってから桁落ち誤差が生じた
値を加減するようないい加減な糞ツールと一緒にしているお前の方が
かなり痛い。XDocletにそんな副作用なんか一切無いわけだが。
知ったかぶり小僧はこの程度かね。
そもそもお前はXDocletを使ったことがあるのかと。
無いだろ。知ってる奴が実際少ないしな。
使いもしない、使ったこともない知りもしない癖にXDocletを糞ツール
と言い切るお前は、まだまだってところだね。
> あれなんだなあ、>>643は最大公約数って知らないんだなあ。
> 分数の分母をそろえないで必死に計算するタイプなんだよなあ。
おいおい、分母をそろえないでどうやって精度を維持して計算できるって
いうんだw 運良く割り切れればいいけどよw
喩えのセンスが悪いぞ。XDocletが割ってから桁落ち誤差が生じた
値を加減するようないい加減な糞ツールと一緒にしているお前の方が
かなり痛い。XDocletにそんな副作用なんか一切無いわけだが。
知ったかぶり小僧はこの程度かね。
そもそもお前はXDocletを使ったことがあるのかと。
無いだろ。知ってる奴が実際少ないしな。
使いもしない、使ったこともない知りもしない癖にXDocletを糞ツール
と言い切るお前は、まだまだってところだね。
>>655
面白い例だ。
アセンブラ屋がCを批判し、
C屋がJavaを批判する。
そんな構図か。
>>655は反省しているようだが、まだまだ反省もせず
パラダイムシフトできない輩はJavaを勉強しようとせず
いつまでも批判ばかりしている哀れな連中だ。
面白い例だ。
アセンブラ屋がCを批判し、
C屋がJavaを批判する。
そんな構図か。
>>655は反省しているようだが、まだまだ反省もせず
パラダイムシフトできない輩はJavaを勉強しようとせず
いつまでも批判ばかりしている哀れな連中だ。
>>658
そんなことは既に解っているが、
Javaの標準APIのソースコードには
nativeというキーワードがあることは知っているな？
Mathクラスや>>641が示したBufferクラスはnativeキーワードを
使ってリソース外のメモリ上に
配列を配置して計算する。
よって実質Cと同じ速さで計算することができる。
だからCで作ればJavaより確実に速くなるとは限らないということだ。
そんなことは既に解っているが、
Javaの標準APIのソースコードには
nativeというキーワードがあることは知っているな？
Mathクラスや>>641が示したBufferクラスはnativeキーワードを
使ってリソース外のメモリ上に
配列を配置して計算する。
よって実質Cと同じ速さで計算することができる。
だからCで作ればJavaより確実に速くなるとは限らないということだ。
>>662
そりゃ、乱立しているJavaのスレみりゃあるだろう。
このスレは一応初代(のれんわけされた初代だけど)な
わけで、このスレの罵り合いにJavaもCもお互いに
簡単だとは言っていない。
>>663
だから、言ったなら
>この場合、この業界じゃあ、｢じゃ、Javaで先ほど言った方法でやってくださいね｣
>って言うのがデフォルトじゃありませんか？
と言えば良い。言えなかったやつはこの業界止めた方が良い性格的に向いていないからね。
そりゃ、乱立しているJavaのスレみりゃあるだろう。
このスレは一応初代(のれんわけされた初代だけど)な
わけで、このスレの罵り合いにJavaもCもお互いに
簡単だとは言っていない。
>>663
だから、言ったなら
>この場合、この業界じゃあ、｢じゃ、Javaで先ほど言った方法でやってくださいね｣
>って言うのがデフォルトじゃありませんか？
と言えば良い。言えなかったやつはこの業界止めた方が良い性格的に向いていないからね。
671 ：仕様書無しさん：2006/03/13(月) 16:06:24
>>645
> ソースコードが古いままというのは問題だが
> interfaceが同じまま機能改善が行われる古い歴史を持つAPIってのは大切だ
> >>641のような改善はされてしかるべきで、埋もれさせてはならない
言っておくがパフォーマンス原理主義者のC言語厨よ。
水を差して悪いが、Bufferクラスは使い方を誤るとメモリリークを起こすからな。
お前みたいな安直なC言語厨には扱わないことをお勧めする。
> ソースコードが古いままというのは問題だが
> interfaceが同じまま機能改善が行われる古い歴史を持つAPIってのは大切だ
> >>641のような改善はされてしかるべきで、埋もれさせてはならない
言っておくがパフォーマンス原理主義者のC言語厨よ。
水を差して悪いが、Bufferクラスは使い方を誤るとメモリリークを起こすからな。
お前みたいな安直なC言語厨には扱わないことをお勧めする。
>>670
具体的に意見を言わないとは。
反論は無いんだな？
「ここまで>>670が見透かされていたとは思わなかったよ。
VB厨よりはましかと思ってたんだか･･･
ヌケサクはおまえだけであることを祈るよ。」
と言い換えされて欲しいか？
具体的に意見を言わないとは。
反論は無いんだな？
「ここまで>>670が見透かされていたとは思わなかったよ。
VB厨よりはましかと思ってたんだか･･･
ヌケサクはおまえだけであることを祈るよ。」
と言い換えされて欲しいか？
C：団塊の世代
Java：バブル世代
Java：バブル世代
>672
>配列を配置して計算する。
>よって実質Cと同じ速さで計算することができる。
はぁ？
その配列の確保、アクセスしての計算･･･
何手かかるんだよ･･･
どこをどう考えたらたらCより速いと思えるんだ？
>配列を配置して計算する。
>よって実質Cと同じ速さで計算することができる。
はぁ？
その配列の確保、アクセスしての計算･･･
何手かかるんだよ･･･
どこをどう考えたらたらCより速いと思えるんだ？
JavaVMなんて、ファミコンエミュレータみたいなもん。
Javaで作ったプログラムは、そのROMファイル。
同じ結果を出すプログラムで、エミュレータ上で動くJavaプログラムと
ホストOS上で直接動くプログラムは、どっちが実行速度が速いか
考えなくても分かるだろ？
Javaのメリットは、理想的には実行するプラットフォームを選ばない
それでいいじゃないか。
Javaで作ったプログラムは、そのROMファイル。
同じ結果を出すプログラムで、エミュレータ上で動くJavaプログラムと
ホストOS上で直接動くプログラムは、どっちが実行速度が速いか
考えなくても分かるだろ？
Javaのメリットは、理想的には実行するプラットフォームを選ばない
それでいいじゃないか。
>>673
> C：団塊の世代
> Java：バブル世代
スレタイ読めてない。
というか団塊系はJavaのほう。団塊ではないがw
C；新人類世代(40代), バブル世代(30代後半)
C++：バブル世代(30代後半 : 実際の所C言語レベル)
VB：バブル世代(30代後半)、偽団塊ジュニア世代(30代前半)
Java：偽団塊ジュニア世代(30代前半)、真性団塊ジュニア世代(20代後半)
D言語, VB:やる気のない世代(20代前半)
アセンブラ, PL/I, COBOL70： 団塊の世代以降(50代-60代前半), 新人類シニア世代(60代以降)
新生COBOL：新人類世代（４０代)
> C：団塊の世代
> Java：バブル世代
スレタイ読めてない。
というか団塊系はJavaのほう。団塊ではないがw
C；新人類世代(40代), バブル世代(30代後半)
C++：バブル世代(30代後半 : 実際の所C言語レベル)
VB：バブル世代(30代後半)、偽団塊ジュニア世代(30代前半)
Java：偽団塊ジュニア世代(30代前半)、真性団塊ジュニア世代(20代後半)
D言語, VB:やる気のない世代(20代前半)
アセンブラ, PL/I, COBOL70： 団塊の世代以降(50代-60代前半), 新人類シニア世代(60代以降)
新生COBOL：新人類世代（４０代)
677 ：仕様書無しさん：2006/03/13(月) 20:20:17
まとめると、
va：バブル世代
スレタイ読めてない。
というか団塊系はJavaのほう。団塊ではないがw
新人類シニア世代(60代以降) : アセンブラ, PL/I, COBOL70
団塊の世代(50代-60代前半) : アセンブラ, PL/I, COBOL70
新人類世代（４０代) : 新生COBOL, C
バブル世代(30代後半) : C, C++(実際の所C言語レベルが大半), VB, Perl
偽団塊ジュニア世代(30代前半) : C, C++, VB, Perl, PHP
真性団塊ジュニア世代(20代後半) : C++, Java, Perl, PHP, AspectX (Xはそれぞれ適した言語)
やる気のない世代(20代前半) : D言語, VB, C++, Java, Perl, PHP, AspectX(Xはそれぞれ適した言語)
va：バブル世代
スレタイ読めてない。
というか団塊系はJavaのほう。団塊ではないがw
新人類シニア世代(60代以降) : アセンブラ, PL/I, COBOL70
団塊の世代(50代-60代前半) : アセンブラ, PL/I, COBOL70
新人類世代（４０代) : 新生COBOL, C
バブル世代(30代後半) : C, C++(実際の所C言語レベルが大半), VB, Perl
偽団塊ジュニア世代(30代前半) : C, C++, VB, Perl, PHP
真性団塊ジュニア世代(20代後半) : C++, Java, Perl, PHP, AspectX (Xはそれぞれ適した言語)
やる気のない世代(20代前半) : D言語, VB, C++, Java, Perl, PHP, AspectX(Xはそれぞれ適した言語)
新人類シニア世代(60代以降) : アセンブラ, PL/I, COBOL70
団塊の世代(50代-60代前半) : アセンブラ, PL/I, COBOL70
新人類世代（４０代) : 新生COBOL, C
バブル世代(30代後半) : C, C++(実際の所C言語レベルが大半), VB, Perl
偽団塊ジュニア世代(30代前半) : C, C++, VB, Perl, PHP
真性団塊ジュニア世代(20代後半) : C++, Java, Perl, PHP, AspectX (Xはそれぞれ適した言語)
やる気のない世代(20代前半) : D言語, VB, C++, Java, Perl, PHP, AspectX(Xはそれぞれ適した言語)
団塊の世代(50代-60代前半) : アセンブラ, PL/I, COBOL70
新人類世代（４０代) : 新生COBOL, C
バブル世代(30代後半) : C, C++(実際の所C言語レベルが大半), VB, Perl
偽団塊ジュニア世代(30代前半) : C, C++, VB, Perl, PHP
真性団塊ジュニア世代(20代後半) : C++, Java, Perl, PHP, AspectX (Xはそれぞれ適した言語)
やる気のない世代(20代前半) : D言語, VB, C++, Java, Perl, PHP, AspectX(Xはそれぞれ適した言語)
680 ：仕様書無しさん：2006/03/13(月) 20:42:13
あげ
D言語が加わってるだけでも嬉しいｗ
世代分けについて
他のスレでも意見を聞いてみよう
他のスレでも意見を聞いてみよう
C++と同じ文法だったら使ってあげる…orz
684 ：仕様書無しさん：2006/03/13(月) 21:14:50
みんなここでおれにJavaを教えれるわけだ。
ｊａｖａに関しては俺に任せろ∠（￣へ￣）
http://pc8.2ch.net/test/read.cgi/prog/1142118755/
南京虐殺が嘘だと分かったいま、時代はおれにJavaを覚えてネットで戦えと言ってる希ガス。
そこで今後は、君たちがおれにJavaを教えることは大事なわけ。
ｊａｖａに関しては俺に任せろ∠（￣へ￣）
http://pc8.2ch.net/test/read.cgi/prog/1142118755/
南京虐殺が嘘だと分かったいま、時代はおれにJavaを覚えてネットで戦えと言ってる希ガス。
そこで今後は、君たちがおれにJavaを教えることは大事なわけ。
685 ：仕様書無しさん：2006/03/14(火) 00:12:20
Javaももう飽きてきちゃった。
C/C++以外でJavaより難しい言語ない？
習得に少し時間のかかるやつがいいんだけど。
C/C++以外でJavaより難しい言語ない？
習得に少し時間のかかるやつがいいんだけど。
HSPがあるじゃないか
>>685
そんなにやる気と時間がある方は全言語を習得すべき！！
そんなにやる気と時間がある方は全言語を習得すべき！！
Lispでいいんじゃね？
>>685
そんなやる気たっぷりなお前様にはAdaしかない
そんなやる気たっぷりなお前様にはAdaしかない
691 ：仕様書無しさん：2006/03/14(火) 10:14:13
人間の言語は苦手なんだよな、言った通りに動かないから。
使わない言語もあまり覚える気にならないんだよな、すでにいっぱい持ってるから。
使わない言語もあまり覚える気にならないんだよな、すでにいっぱい持ってるから。
692 ：仕様書無しさん：2006/03/14(火) 22:40:31
>655
おいおい 人の文を引用したらちゃんと引用したと書きなさい。
おいおい 人の文を引用したらちゃんと引用したと書きなさい。
BOOST C++ >>>>>>>>>>>> JAVA > C
あんな馬鹿でかいバイナリ作るだけで既にバグだと思うが・・・
696 ：仕様書無しさん：2006/03/17(金) 05:19:04
スレのテンプレートが気に入ったw
このナイスなフレーズ！
よって挙げ。
さ、語れ。Javaよりも遅い脳みそを持つ人々について
Javaよりも重たい(思考回路が遅い)バブル世代が立てたスレ
Javaって重くね？ その２
http://pc8.2ch.net/test/read.cgi/prog/1136359572/
関連スレ
先があるのはC++とJavaのどっち？
http://pc8.2ch.net/test/read.cgi/prog/1132157362/
このナイスなフレーズ！
よって挙げ。
さ、語れ。Javaよりも遅い脳みそを持つ人々について
Javaよりも重たい(思考回路が遅い)バブル世代が立てたスレ
Javaって重くね？ その２
http://pc8.2ch.net/test/read.cgi/prog/1136359572/
関連スレ
先があるのはC++とJavaのどっち？
http://pc8.2ch.net/test/read.cgi/prog/1132157362/
2 名前：デフォルトの名無しさん[sage] 投稿日：2006/01/05(木) 18:41:33
javaなんて3日で覚えたし
3 名前：デフォルトの名無しさん[sage] 投稿日：2006/01/05(木) 18:55:43
>>2
神
まだC勉強中だが次はJAVAだな
4 名前：デフォルトの名無しさん[sage] 投稿日：2006/01/05(木) 19:01:02
>>2-3
堀江の発言に騙されているぞお前ら。
Cしかできない奴がJavaを三日で覚えても
経験からいって
まったく即戦力にならない。
まったく酷いスパゲティコードしか書けないことは
目に見えている。
Teach Yourself Programming in Ten Years 日本語訳
"プログラミングを独習するには10年かかる"
http://www.yamdas.org/column/technique/21-daysj.html
5 名前：デフォルトの名無しさん[sage] 投稿日：2006/01/05(木) 19:01:39
言語仕様だけなら3日あれば充分だけどな。
6 名前：デフォルトの名無しさん[sage] 投稿日：2006/01/05(木) 19:20:01
仕様だけ理解したところでプログラミングなんてできないわけで。
javaなんて3日で覚えたし
3 名前：デフォルトの名無しさん[sage] 投稿日：2006/01/05(木) 18:55:43
>>2
神
まだC勉強中だが次はJAVAだな
4 名前：デフォルトの名無しさん[sage] 投稿日：2006/01/05(木) 19:01:02
>>2-3
堀江の発言に騙されているぞお前ら。
Cしかできない奴がJavaを三日で覚えても
経験からいって
まったく即戦力にならない。
まったく酷いスパゲティコードしか書けないことは
目に見えている。
Teach Yourself Programming in Ten Years 日本語訳
"プログラミングを独習するには10年かかる"
http://www.yamdas.org/column/technique/21-daysj.html
5 名前：デフォルトの名無しさん[sage] 投稿日：2006/01/05(木) 19:01:39
言語仕様だけなら3日あれば充分だけどな。
6 名前：デフォルトの名無しさん[sage] 投稿日：2006/01/05(木) 19:20:01
仕様だけ理解したところでプログラミングなんてできないわけで。
7 名前：デフォルトの名無しさん[sage] 投稿日：2006/01/05(木) 20:39:03
勉強したことないけど、オブジェクト指向とかデザインパターンの本を読んでたら
自然に覚えた。
8 名前：デフォルトの名無しさん[sage] 投稿日：2006/01/05(木) 21:33:42
っていうかなぜC？C++ではなく？
今時Cしか知らないやつなんているのか。
9 名前：デフォルトの名無しさん[sage] 投稿日：2006/01/05(木) 22:52:46
大学にいけばそういう残党勢力はかなりいるよ。
業界によってはシステム開発系やデジタル信号処理系なんかに多いだろう
10 名前：デフォルトの名無しさん[sage] 投稿日：2006/01/05(木) 23:24:49
ぎくっ
11 名前：デフォルトの名無しさん[sage] 投稿日：2006/01/06(金) 00:05:11
げげげ
勉強したことないけど、オブジェクト指向とかデザインパターンの本を読んでたら
自然に覚えた。
8 名前：デフォルトの名無しさん[sage] 投稿日：2006/01/05(木) 21:33:42
っていうかなぜC？C++ではなく？
今時Cしか知らないやつなんているのか。
9 名前：デフォルトの名無しさん[sage] 投稿日：2006/01/05(木) 22:52:46
大学にいけばそういう残党勢力はかなりいるよ。
業界によってはシステム開発系やデジタル信号処理系なんかに多いだろう
10 名前：デフォルトの名無しさん[sage] 投稿日：2006/01/05(木) 23:24:49
ぎくっ
11 名前：デフォルトの名無しさん[sage] 投稿日：2006/01/06(金) 00:05:11
げげげ
699 ：仕様書無しさん：2006/03/18(土) 11:35:39
12 名前：デフォルトの名無しさん[] 投稿日：2006/01/06(金) 00:24:20
まあ最近では大学では授業につかうプログラミング言語を
CからJavaに変更しているところも増えてきた感じだ。
全世界的に。名門大学でJavaが使われれば
三流大学でもJavaを余儀なく使わされる。
↓
すると企業でもJavaを使うところが増える。
↓
Javaを研修に使うところが増える。
↓
Javaの仕事が増える。
そういう構図ができあがって見事にそれが具現化してしまったわけだ。
これが以前はJavaではなくC言語であったわけだが
Javaに置き換えられた。そこでCからJavaに移行
するものも出てくるわけだ。
まあ最近では大学では授業につかうプログラミング言語を
CからJavaに変更しているところも増えてきた感じだ。
全世界的に。名門大学でJavaが使われれば
三流大学でもJavaを余儀なく使わされる。
↓
すると企業でもJavaを使うところが増える。
↓
Javaを研修に使うところが増える。
↓
Javaの仕事が増える。
そういう構図ができあがって見事にそれが具現化してしまったわけだ。
これが以前はJavaではなくC言語であったわけだが
Javaに置き換えられた。そこでCからJavaに移行
するものも出てくるわけだ。
700 ：仕様書無しさん：2006/03/18(土) 19:15:16
紀伊国屋のプログラミングコーナーで
一番広いスペースを使っているのはJavaだ
次がVB
一番広いスペースを使っているのはJavaだ
次がVB
C#は泣きたくなるくらいスペースが無いな。
C/C++に混じってたり、VBに混じってたりで単独のスペースが無い。
酷い本屋になると両方にバラバラに配置されてたりする。
C/C++に混じってたり、VBに混じってたりで単独のスペースが無い。
酷い本屋になると両方にバラバラに配置されてたりする。
さて、80年代の大学では教育用としてPascalを使っていたわけだが。
企業でのスタンダードはPascalだったわけですね！
なんかJava派のスレってつまんねえんだよな
一目で見て分かるが、C++派スレは寒いくらいつまらんよ
706 ：仕様書無しさん：2006/03/19(日) 02:42:33
>>704
Javaが嫌いな人にはつまらんかもしれないね。
Javaが嫌いな人にはつまらんかもしれないね。
707 ：仕様書無しさん：2006/03/19(日) 02:44:09
708 ：仕様書無しさん：2006/03/19(日) 10:19:12
過去の栄光って何？
709 ：仕様書無しさん：2006/03/19(日) 12:11:03
Javaの遅さは可変長のデータの多さにあると思うな。
言語が変な機能万歳なおかげで糞遅い処理なのに最適化のしようがないように
見えてしまうのが問題なんだろうな。
特に可変長文字列・配列の領域の再確保には注意。
for(i=0;i<1000;i++){
str_temp += "うんこ";
}
って感じの注意な。
プラスするたびに確保→コピー→解放が行われてる。
大きめのデータを扱うときはあらかじめ領域を確保して・・・ってそれじゃＣ言語とかわらんやんけｗ
言語が変な機能万歳なおかげで糞遅い処理なのに最適化のしようがないように
見えてしまうのが問題なんだろうな。
特に可変長文字列・配列の領域の再確保には注意。
for(i=0;i<1000;i++){
str_temp += "うんこ";
}
って感じの注意な。
プラスするたびに確保→コピー→解放が行われてる。
大きめのデータを扱うときはあらかじめ領域を確保して・・・ってそれじゃＣ言語とかわらんやんけｗ
結局、安定性・速度向上は先にメモリー確保・使いまわし・終了時に解放な
わけで、それはどの言語でも変わらない。
前から思ってたんだが、参照されている限りメモリーの確保が行われるって・・・
結局明示的な解放の方が最終的なバグ発生が減るような気がするんだが。
まあこれは慣れの問題だけどね。
わけで、それはどの言語でも変わらない。
前から思ってたんだが、参照されている限りメモリーの確保が行われるって・・・
結局明示的な解放の方が最終的なバグ発生が減るような気がするんだが。
まあこれは慣れの問題だけどね。
711 ：仕様書無しさん：2006/03/19(日) 12:40:24
>>710
そうだな。俺も同意。
結局、参照っていったってプログラムを組む人間が意識したものでなければ
その動作はバグそのものだと思う。
参照が切れるまで保持し続けるってのはただ落ちないだけでバグってることには代わりない。
偶然生かされてるものを頼りに次のを積み重ねるからさらにバグが増える。
そうだな。俺も同意。
結局、参照っていったってプログラムを組む人間が意識したものでなければ
その動作はバグそのものだと思う。
参照が切れるまで保持し続けるってのはただ落ちないだけでバグってることには代わりない。
偶然生かされてるものを頼りに次のを積み重ねるからさらにバグが増える。
712 ：仕様書無しさん：2006/03/19(日) 13:33:02
>>709
> for(i=0;i<1000;i++){
> str_temp += "うんこ";
> }
> って感じの注意な。
文字列連結にStringBuilder#append()を使わずに
+=を使うなんておまえはほんとに"うんこ"だよ
> for(i=0;i<1000;i++){
> str_temp += "うんこ";
> }
> って感じの注意な。
文字列連結にStringBuilder#append()を使わずに
+=を使うなんておまえはほんとに"うんこ"だよ
713 ：仕様書無しさん：2006/03/19(日) 13:38:35
>>709
> Javaの遅さは可変長のデータの多さにあると思うな。
そこでBufferの出番ですが。
BufferクラスはCと変わらない速さで
配列をネイティブ領域に確保できる。
> 言語が変な機能万歳なおかげで糞遅い処理なのに最適化のしようがないように
> 見えてしまうのが問題なんだろうな。
今じゃコンパイラがかなりの部分を最適化してくれますが。
> 特に可変長文字列・配列の領域の再確保には注意。
> for(i=0;i<1000;i++){
> str_temp += "うんこ";
> }
> って感じの注意な。
> プラスするたびに確保→コピー→解放が行われてる。
こっちのほうが速いですよ。
private static final String UNKO = "うんこ";
// (ry
StringBuilder str_temp = new StringBuilder();
for(int i = 0 ; i < 100 < i++){
str_temp.append(UNKO);
}
String result = str_temp.toString();
> 大きめのデータを扱うときはあらかじめ領域を確保して・・・ってそれじゃＣ言語とかわらんやんけｗ
そこでNew I/OのChannelクラスを使うわけですが。
> Javaの遅さは可変長のデータの多さにあると思うな。
そこでBufferの出番ですが。
BufferクラスはCと変わらない速さで
配列をネイティブ領域に確保できる。
> 言語が変な機能万歳なおかげで糞遅い処理なのに最適化のしようがないように
> 見えてしまうのが問題なんだろうな。
今じゃコンパイラがかなりの部分を最適化してくれますが。
> 特に可変長文字列・配列の領域の再確保には注意。
> for(i=0;i<1000;i++){
> str_temp += "うんこ";
> }
> って感じの注意な。
> プラスするたびに確保→コピー→解放が行われてる。
こっちのほうが速いですよ。
private static final String UNKO = "うんこ";
// (ry
StringBuilder str_temp = new StringBuilder();
for(int i = 0 ; i < 100 < i++){
str_temp.append(UNKO);
}
String result = str_temp.toString();
> 大きめのデータを扱うときはあらかじめ領域を確保して・・・ってそれじゃＣ言語とかわらんやんけｗ
そこでNew I/OのChannelクラスを使うわけですが。
714 ：仕様書無しさん：2006/03/19(日) 13:41:29
>>710
> 結局、安定性・速度向上は先にメモリー確保・使いまわし・終了時に解放な
> わけで、それはどの言語でも変わらない。
> 前から思ってたんだが、参照されている限りメモリーの確保が行われるって・・・
> 結局明示的な解放の方が最終的なバグ発生が減るような気がするんだが。
そこで java.lang.ref.SoftReferenceを用いてオブジェクトのガベコレ候補優先度を
高めることでリソース/パフォーマンスを改善できるわけですが。
> 結局、安定性・速度向上は先にメモリー確保・使いまわし・終了時に解放な
> わけで、それはどの言語でも変わらない。
> 前から思ってたんだが、参照されている限りメモリーの確保が行われるって・・・
> 結局明示的な解放の方が最終的なバグ発生が減るような気がするんだが。
そこで java.lang.ref.SoftReferenceを用いてオブジェクトのガベコレ候補優先度を
高めることでリソース/パフォーマンスを改善できるわけですが。
715 ：仕様書無しさん：2006/03/19(日) 13:58:52
別のスレに投稿したが回答なしなのですみません。
みなさんデプロイには時間かかりませんか！
いま長いと３０分ぐらい掛かっています。
全システムを４分轄して個別にデプロイしているのですが
そもそもサブシステム別にＷａｒファイルを作るか
場合によては画面で分轄しても良いのではと思うのですが？
みなさんデプロイには時間かかりませんか！
いま長いと３０分ぐらい掛かっています。
全システムを４分轄して個別にデプロイしているのですが
そもそもサブシステム別にＷａｒファイルを作るか
場合によては画面で分轄しても良いのではと思うのですが？
717 ：仕様書無しさん：2006/03/19(日) 14:07:56
あれれ、うんこなJava教室になっちゃったのw
WARだけのデプロイで30分もかかるのけ？
EJB含んでると、スタブ作ったりとかで時間かかることもあるが。
EJB含んでると、スタブ作ったりとかで時間かかることもあるが。
つテストファースト＋デイリービルド
721 ：仕様書無しさん：2006/03/19(日) 16:33:55
>>713
それ、ホントに速くなるの？
つか、俺のいったこと理解してる？
str_tempにとっては"うんこ"を1000回突っ込んでみるまで全体のサイズは測れないでしょ？
やるなら
StringBuilder str_temp = new StringBuilder("うんこ"１０００個分);
とか必要だって俺はいってるんだけど。
それ、ホントに速くなるの？
つか、俺のいったこと理解してる？
str_tempにとっては"うんこ"を1000回突っ込んでみるまで全体のサイズは測れないでしょ？
やるなら
StringBuilder str_temp = new StringBuilder("うんこ"１０００個分);
とか必要だって俺はいってるんだけど。
>>723
StringBuilder(String)コンストラクタを使う必要があるのは何で？
不定なバッファを扱うなら、文字そのものじゃなくてバッファのサイズで生成するだろ。
StringBulder(int)でそれが出来ると言ってるの。
StringBuilder(String)を使うことなんて現実にはレアケースだよ
StringBuilder(String)コンストラクタを使う必要があるのは何で？
不定なバッファを扱うなら、文字そのものじゃなくてバッファのサイズで生成するだろ。
StringBulder(int)でそれが出来ると言ってるの。
StringBuilder(String)を使うことなんて現実にはレアケースだよ
>>724
え？つかって無いけど？
え？つかって無いけど？
ああ、
StringBuilder str_temp = new StringBuilder("うんこ"１０００個分);
これをStringBuilder(String)だと思ったのね
StringBuilder("うんこ"１０００個分のサイズ);
こういいたかった。
StringBuilder str_temp = new StringBuilder("うんこ"１０００個分);
これをStringBuilder(String)だと思ったのね
StringBuilder("うんこ"１０００個分のサイズ);
こういいたかった。
>>727
お前が何をしたいのかをはっきりさせろ
・文字列を連結させたい
・文字列の総lengthを求めたい
・両方
そして何故
> str_tempにとっては"うんこ"を1000回突っ込んでみるまで全体のサイズは測れない
のか
図れないケースはどんな時？
そしてそれはどうしてCなら解決できるの？
お前が何をしたいのかをはっきりさせろ
・文字列を連結させたい
・文字列の総lengthを求めたい
・両方
そして何故
> str_tempにとっては"うんこ"を1000回突っ込んでみるまで全体のサイズは測れない
のか
図れないケースはどんな時？
そしてそれはどうしてCなら解決できるの？
>>729
で、mallocさんはそれがどうやって分かるの？
で、mallocさんはそれがどうやって分かるの？
>>730
sizeofで×1000するんじゃね？
sizeofで×1000するんじゃね？
"うんこ".length * 1000で終わりか
質問者は自分が何を質問してるのか分からないまま言語を叩いてたと
質問者は自分が何を質問してるのか分からないまま言語を叩いてたと
つか、俺、質問してねーしｗ
勝手に誰かが噛み付いてきただけだよ。
勝手に誰かが噛み付いてきただけだよ。
このレス（>>721）が何を言いたかったのか、それは誰にも分からない。
735 ：仕様書無しさん：2006/03/19(日) 18:40:03
736 ：仕様書無しさん：2006/03/19(日) 18:42:14
>>735
FlyWeightパターンっていいたいだけちゃうんかと
FlyWeightパターンっていいたいだけちゃうんかと
739 ：仕様書無しさん：2006/03/19(日) 18:44:09
>>734
>>721は馬鹿なんだよ。
最初は +=で文字列連結すると遅いと主張したのに
大してStringBuilderを使えと反論されて。
しかもString型が不変クラスであることもわかってないし。
それで+=で結ぼうとした。
馬鹿としか言いようがない。
>>721は馬鹿なんだよ。
最初は +=で文字列連結すると遅いと主張したのに
大してStringBuilderを使えと反論されて。
しかもString型が不変クラスであることもわかってないし。
それで+=で結ぼうとした。
馬鹿としか言いようがない。
743 ：仕様書無しさん：2006/03/19(日) 18:52:37
>>709
> Javaの遅さは可変長のデータの多さにあると思うな。
> 言語が変な機能万歳なおかげで糞遅い処理なのに最適化のしようがないように
> 見えてしまうのが問題なんだろうな。
> 特に可変長文字列・配列の領域の再確保には注意。
> for(i=0;i<1000;i++){
> str_temp += "うんこ";
> }
> って感じの注意な。
> プラスするたびに確保→コピー→解放が行われてる。
>>709はこんなことを言っている。
+=を使って文字列を連結するとどれだけコストが増大するかわかってない。
しかもstr_tmpはStringオブジェクトだしな。
これと同じ事をStringBuilderでやってもエラーになるわけだが。
> Javaの遅さは可変長のデータの多さにあると思うな。
> 言語が変な機能万歳なおかげで糞遅い処理なのに最適化のしようがないように
> 見えてしまうのが問題なんだろうな。
> 特に可変長文字列・配列の領域の再確保には注意。
> for(i=0;i<1000;i++){
> str_temp += "うんこ";
> }
> って感じの注意な。
> プラスするたびに確保→コピー→解放が行われてる。
>>709はこんなことを言っている。
+=を使って文字列を連結するとどれだけコストが増大するかわかってない。
しかもstr_tmpはStringオブジェクトだしな。
これと同じ事をStringBuilderでやってもエラーになるわけだが。
744 ：仕様書無しさん：2006/03/19(日) 18:55:18
>>743
途中参加でよくわからないけど、いいじゃん。あってんじゃん。
途中参加でよくわからないけど、いいじゃん。あってんじゃん。
>>709はEclipseのByteCode OutLineプラグインで
+=を使ったコードとStringBuilder#append()を使ったコードとで
どちらがコストがかかるかを確認した方が良い。
逆アセンブルすると+=を使ったコードは
Stringオブジェクトを一旦StringBufferオブジェクトに変換するわけだが。
+=を使ったコードとStringBuilder#append()を使ったコードとで
どちらがコストがかかるかを確認した方が良い。
逆アセンブルすると+=を使ったコードは
Stringオブジェクトを一旦StringBufferオブジェクトに変換するわけだが。
まぁ、StringBuilder#toString()するから、実際は倍のメモリを食うわけですが。
つーか、文字列が多い場合は場合は先に余裕持たせてメモリ確保
するのが当然だと思ってたんだが・・・。
するのが当然だと思ってたんだが・・・。
>>747
appendすればいらないらしい。
appendすればいらないらしい。
バッファの拡張のためには
新しいバッファの確保、及び新しいバッファへの
現在のバッファの内容のコピーが必要となる。
自動でそれをやるってだけで要らないわけがない
新しいバッファの確保、及び新しいバッファへの
現在のバッファの内容のコピーが必要となる。
自動でそれをやるってだけで要らないわけがない
>>745
コンパイラに任せるとString = new StringBuilder().append()してしまう。
ループ内で使うと非常に効率が悪い。
str1 = str2 + str3 + str4 + str5という単発のコードならコンパイラに任
せてしまって問題ないが、str1 += str2; str1 += str3; str1 += str4;とい
う繰り返しでは任せると無駄が多い。
コンパイラに任せるとString = new StringBuilder().append()してしまう。
ループ内で使うと非常に効率が悪い。
str1 = str2 + str3 + str4 + str5という単発のコードならコンパイラに任
せてしまって問題ないが、str1 += str2; str1 += str3; str1 += str4;とい
う繰り返しでは任せると無駄が多い。
誰か最速のコードを書いてくれ。
>>751
__
>>751 ｌ￣／. ＿__
↓ / /. / ___ﾉ
＿＿/ /＿／ /
糞レベルが！ Y人, ' ',人⌒ヽ､, '
Y⌒ヽ）⌒ヽ､ 人,ヽ）人'､, '
へ, --- ､ ﾉ￣ ::::::::::::::::::::::）
/￣￣￣ ､____＼ （ ::::::::::::::;;;;;;;;;;;;ノ
/ _/￣「~|＼ ＿＿ ＼ ／￣―――――￣￣::::::::＼
| | | | （ ､ Ａ , ＼ミｿ （ :::::::::::::::::::::::::::::::::）
し' し' と∨￣∨ ＼＿＿::::::::::::::::::;;;;;;;;;;;;;;;;;;;;;;;;ノ
__
>>751 ｌ￣／. ＿__
↓ / /. / ___ﾉ
＿＿/ /＿／ /
糞レベルが！ Y人, ' ',人⌒ヽ､, '
Y⌒ヽ）⌒ヽ､ 人,ヽ）人'､, '
へ, --- ､ ﾉ￣ ::::::::::::::::::::::）
/￣￣￣ ､____＼ （ ::::::::::::::;;;;;;;;;;;;ノ
/ _/￣「~|＼ ＿＿ ＼ ／￣―――――￣￣::::::::＼
| | | | （ ､ Ａ , ＼ミｿ （ :::::::::::::::::::::::::::::::::）
し' し' と∨￣∨ ＼＿＿::::::::::::::::::;;;;;;;;;;;;;;;;;;;;;;;;ノ
753 ：仕様書無しさん：2006/03/19(日) 20:09:44
>>747
new StringBuilder(1024)
みたいなことしておけば確保できる。
それに不満があるなら
java.io.StringWriter + java.nio.Channelを使えばいい。
new StringBuilder(1024)
みたいなことしておけば確保できる。
それに不満があるなら
java.io.StringWriter + java.nio.Channelを使えばいい。
754 ：仕様書無しさん：2006/03/19(日) 20:11:24
Stringの替わりに
java.nio.CharBuffer使えば高速化するだろうw
C言語と同じ速さになるw
java.nio.CharBuffer使えば高速化するだろうw
C言語と同じ速さになるw
そうは思わんが、どうしてそう思っちゃったのかな？
ねぇ。append使えばそれなりに早いよね。
>>754
バッファに文字列を任意回数追加するコード書いてみたんだけど、
StringBuilderの方がCharBufferより速いってのは何か間違えてる？
public static void main(String[] args) {
long s = System.nanoTime();
strbuf("うんこ", 10000000);
// charbuf("うんこ", 10000000);
long e = System.nanoTime();
System.out.println((e-s)/1000000d+"ms");
}
static CharSequence strbuf(CharSequence cs, int num) {
StringBuilder sb = new StringBuilder(cs.length() * num);
for(int i=0; i<num; i++) sb.append(cs);
return sb;
}
static CharSequence charbuf(CharSequence cs, int num) {
CharBuffer cb = CharBuffer.allocate(cs.length() * num);
// CharBuffer cb = ByteBuffer.allocateDirect(cs.length() * 2 * num).asCharBuffer();
for(int i=0; i<num; i++) cb.append(cs);
cb.flip();
return cb;
}
バッファに文字列を任意回数追加するコード書いてみたんだけど、
StringBuilderの方がCharBufferより速いってのは何か間違えてる？
public static void main(String[] args) {
long s = System.nanoTime();
strbuf("うんこ", 10000000);
// charbuf("うんこ", 10000000);
long e = System.nanoTime();
System.out.println((e-s)/1000000d+"ms");
}
static CharSequence strbuf(CharSequence cs, int num) {
StringBuilder sb = new StringBuilder(cs.length() * num);
for(int i=0; i<num; i++) sb.append(cs);
return sb;
}
static CharSequence charbuf(CharSequence cs, int num) {
CharBuffer cb = CharBuffer.allocate(cs.length() * num);
// CharBuffer cb = ByteBuffer.allocateDirect(cs.length() * 2 * num).asCharBuffer();
for(int i=0; i<num; i++) cb.append(cs);
cb.flip();
return cb;
}
>>758
strbufが約250ms charbufが約450msでした。
strbufが約250ms charbufが約450msでした。
>>757
もう１つ頼む！
StringBuilder sb = new StringBuilder(cs.length() * num);
を
StringBuilder sb = new StringBuilder();
で、
やってみてくれ。
俺の環境だと大して差がでないんだ。
もう１つ頼む！
StringBuilder sb = new StringBuilder(cs.length() * num);
を
StringBuilder sb = new StringBuilder();
で、
やってみてくれ。
俺の環境だと大して差がでないんだ。
>>761
約850ms…さすがに拡張が入ると遅くなる
約850ms…さすがに拡張が入ると遅くなる
764 ：仕様書無しさん：2006/03/20(月) 00:12:10
環境でばらつく糞Java
765 ：仕様書無しさん：2006/03/20(月) 07:21:05
.NETは？？
766 ：仕様書無しさん：2006/03/20(月) 10:00:17
内部の構造もろくに知らないで糞と言ってる奴は
そいつの人格が糞
そいつの人格が糞
内部の構造もろくに知らないで
内部の構造もろくに知らないで糞と言ってる奴は
そいつの人格が糞
と言ってる奴は そいつの人格が糞
内部の構造もろくに知らないで糞と言ってる奴は
そいつの人格が糞
と言ってる奴は そいつの人格が糞
768 ：仕様書無しさん：2006/03/20(月) 10:26:06
と言うJava厨もネイティブ脱落者の集合だから
内部仕様は全く理解していないと思う。
内部仕様は全く理解していないと思う。
769 ：仕様書無しさん：2006/03/20(月) 10:50:23
771 ：仕様書無しさん：2006/03/20(月) 12:45:44
たかが文字列操作に百ミリオーダーだなんてマジで遅いな。
そこはJavaですから･･･
しかしJava厨はリッチなPG、速いとか遅いとか小さいことは気にしません。
動けばいいのですよ。
しかしJava厨はリッチなPG、速いとか遅いとか小さいことは気にしません。
動けばいいのですよ。
773 ：Mb：2006/03/20(月) 21:26:59
藻前らLisp やらProlog やらのAppend でFreeCell 領域の
消費に苦しんでいた先人の苦労について慮ったことがあるのか？
いまどきマシンパワーなんぞ余りまくっとるんだから、
可変長データを扱ってなおワイルドポインタだのメモリリークだの
とかいった心配をしなくていい環境を享受すりゃええんじゃ！
非数値処理っつーのはそういうもんなんじゃ。
BASIC みたいな鬱陶しい環境以外で、文字列処理ができるっつーだけで、
漏れは満足じゃ。
消費に苦しんでいた先人の苦労について慮ったことがあるのか？
いまどきマシンパワーなんぞ余りまくっとるんだから、
可変長データを扱ってなおワイルドポインタだのメモリリークだの
とかいった心配をしなくていい環境を享受すりゃええんじゃ！
非数値処理っつーのはそういうもんなんじゃ。
BASIC みたいな鬱陶しい環境以外で、文字列処理ができるっつーだけで、
漏れは満足じゃ。
>>774
将来的には実際何とかしてくれるんだけどな。
将来的には実際何とかしてくれるんだけどな。
776 ：仕様書無しさん：2006/03/21(火) 00:21:29
電子の速度には限度がある。
10GHzは物理的に不可能。
実際、3G越えた辺りで頭打ちになった。
10GHzは物理的に不可能。
実際、3G越えた辺りで頭打ちになった。
並列化と突っ込んでおく
778 ：仕様書無しさん：2006/03/21(火) 00:42:39
>>770
高級小倉餡であったかつみためがウンコ
で匂いがおいしければ問題なし。
実際、うんこみたいな形してる、かりんとう、
かなりおいしいし。
高級小倉餡であったかつみためがウンコ
でかつ匂いがウンコ？
ありえぬよ。それは表面に実際にウンコを塗装している
んだろう。でないと匂いまでウンコにならない。
それはJavaの喩えとして適切じゃない。
高級小倉餡であったかつみためがウンコ
で匂いがおいしければ問題なし。
実際、うんこみたいな形してる、かりんとう、
かなりおいしいし。
高級小倉餡であったかつみためがウンコ
でかつ匂いがウンコ？
ありえぬよ。それは表面に実際にウンコを塗装している
んだろう。でないと匂いまでウンコにならない。
それはJavaの喩えとして適切じゃない。
779 ：仕様書無しさん：2006/03/21(火) 00:43:14
780 ：仕様書無しさん：2006/03/21(火) 00:43:49
>>774
お前もChannelについて調べろアフォ
お前もChannelについて調べろアフォ
781 ：仕様書無しさん：2006/03/21(火) 00:45:16
それからStringWriter, BufferdWriterについても調べろ
おまいら。
StringBuilderだけで足りないという前に
これらとChannelクラスを組み合わせて高速化する方法に
ついて調べればかども。
いつもいつも、相変わらず
C言語厨はレベルが低すぎるんだよ。
おまいら。
StringBuilderだけで足りないという前に
これらとChannelクラスを組み合わせて高速化する方法に
ついて調べればかども。
いつもいつも、相変わらず
C言語厨はレベルが低すぎるんだよ。
CにはCのチューニングがあるわけで
そんなローカル技術語られても普通で速いCからすれば
はぁ？
そんなローカル技術語られても普通で速いCからすれば
はぁ？
784 ：仕様書無しさん：2006/03/21(火) 08:13:53
そんなに悩ませるなら、もういっそcharでやりたい・・・orz
Javaは遅い。だが安全だ。これでどう？
>>785
いや、早くしようと思えばその方法があるだけにそうとも言い切れない。
ただ、それが内部の処理が見えないってだけですげーむかつく。
これが問題にならない微妙な差ならいいけど、動作にダイレクトに影響するからたまったモンじゃない。
いや、早くしようと思えばその方法があるだけにそうとも言い切れない。
ただ、それが内部の処理が見えないってだけですげーむかつく。
これが問題にならない微妙な差ならいいけど、動作にダイレクトに影響するからたまったモンじゃない。
＞電子の速度
あははははははは
あははははははは
>>777
現状では並列化はあまり意味無いだろうとつっこんで置く。
現状では並列化はあまり意味無いだろうとつっこんで置く。
並列化ってなに？
790 ：仕様書無しさん：2006/03/21(火) 09:30:35
いくらマルチコアで並列化したところで、Javaのstop the worldでは全然意味無し。
むしろ他のアプリとの並列化をはかれよな。
stop the worldなのは自分だけでＣＰＵを占有するからだろ？
stop the worldなのは自分だけでＣＰＵを占有するからだろ？
欧米か！
very very slowly
クロック数を大きくすることだけが処理速度を上げる術ではない。
今、クロック数を上げる競争は収まりを見せたが、それでも処理速度は上がり続けている。
今、クロック数を上げる競争は収まりを見せたが、それでも処理速度は上がり続けている。
795 ：仕様書無しさん：2006/03/21(火) 13:28:08
>>782-783
ヒント ： 行列演算で用いるピボット(pivot)操作
ヒント ： 行列演算で用いるピボット(pivot)操作
796 ：仕様書無しさん：2006/03/21(火) 13:28:38
>>786
> >>785
> いや、早くしようと思えばその方法があるだけにそうとも言い切れない。
> ただ、それが内部の処理が見えないってだけですげーむかつく。
EclipseのBytecode Outlineプラグインを使え。
> これが問題にならない微妙な差ならいいけど、動作にダイレクトに影響するからたまったモンじゃない。
> >>785
> いや、早くしようと思えばその方法があるだけにそうとも言い切れない。
> ただ、それが内部の処理が見えないってだけですげーむかつく。
EclipseのBytecode Outlineプラグインを使え。
> これが問題にならない微妙な差ならいいけど、動作にダイレクトに影響するからたまったモンじゃない。
797 ：仕様書無しさん：2006/03/21(火) 13:29:49
798 ：仕様書無しさん：2006/03/21(火) 14:09:38
糞重いIIOP
糞遅くて使えないWSDL
なんで？Javaは糞糞じゃんｗ
糞遅くて使えないWSDL
なんで？Javaは糞糞じゃんｗ
>>798
2chで叫んでも現実は変わらないよ。
2chで叫んでも現実は変わらないよ。
>>776
それは熱の問題。
それは熱の問題。
801 ：仕様書無しさん：2006/03/21(火) 14:36:25
SMPによる恩恵はJavaじゃうけられないよ。
Linuxもダメダメ。
Linuxもダメダメ。
じゃあMPPでよろ。
803 ：仕様書無しさん：2006/03/21(火) 15:28:11
IIOPとWSDLがJava専用だと勘違いしている>>798は糞ですね
804 ：仕様書無しさん：2006/03/21(火) 15:30:13
専用ではないのは承知。Javaで実装するWSDLが糞
なくなればいいよJavaのWSDL
なくなればいいよJavaのWSDL
gSOAP爆速だよね。Javaとは比較になんね。
806 ：仕様書無しさん：2006/03/21(火) 15:58:10
Java厨のSOAP関連のネタふっても技術的な話は
全く返ってこないから笑える
全く返ってこないから笑える
.NETなんか「使われて無い」の一言で瞬殺。
そりゃな、汎用言語と専用ライブラリを比較するわけだしな
だからといってSOAPだけ語っても意味ないな
だからといってSOAPだけ語っても意味ないな
て言うか、ここでマジネタ書く気しない。
どうせ１行レスで流されるし、レス付いても長文乙くらいだしｗ
どうせ１行レスで流されるし、レス付いても長文乙くらいだしｗ
マジネタを1行で書けばいいじゃん
ウザイ流れの時は連投して流してしまえばいい。
他所板(別スレ程度だとコピペがばれる)から微妙に関係ありそうなネタを
引っ張ってきてコピペ爆撃という手もある。
元スレの投稿時間を参考に投稿間隔を調整すると文体も違うし投稿時間
も不揃いになるから自演ぽくも見えない。
プログラムを使って自動投稿すれば２ちゃんに張り付く必要もない。
強制IDのない板でスレ潰すのは簡単。
他所板(別スレ程度だとコピペがばれる)から微妙に関係ありそうなネタを
引っ張ってきてコピペ爆撃という手もある。
元スレの投稿時間を参考に投稿間隔を調整すると文体も違うし投稿時間
も不揃いになるから自演ぽくも見えない。
プログラムを使って自動投稿すれば２ちゃんに張り付く必要もない。
強制IDのない板でスレ潰すのは簡単。
そこまでするほどJavaを愛しているのですね。感動しました。
814 ：仕様書無しさん：2006/03/21(火) 19:27:27
言い訳はできるが技術的な話は出てこないｗ
815 ：仕様書無しさん：2006/03/21(火) 19:38:05
816 ：仕様書無しさん：2006/03/21(火) 19:39:16
厨房どうしで喧嘩すんな。
819 ：仕様書無しさん：2006/03/21(火) 22:57:37
820 ：仕様書無しさん：2006/03/21(火) 22:59:58
■Java厨過去名言集
No.1 Javaのソケットにはポートは使わない
No.2(赤丸↑) そんな速さに拘りたければSOAP使えばいい
No.3 ビジネスロジック
No.4 大規模開発
No.5 PC屋には理解できないサーバ
>>820
No.3と4は何が名言なんだ？くすりともできない。
No.3と4は何が名言なんだ？くすりともできない。
822 ：仕様書無しさん：2006/03/21(火) 23:35:23
823 ：仕様書無しさん：2006/03/21(火) 23:37:46
C言語信者ってもう古くね CMMIレベル2
http://pc8.2ch.net/test/read.cgi/tech/1142950975/
http://pc8.2ch.net/test/read.cgi/tech/1142950975/
826 ：仕様書無しさん：2006/03/22(水) 10:26:30
Java→C#.NETコンバータがあれば問題ない
JUMP to .NET
なんてあったけど使いもんになんなかったねえ。
外部のAPIを使っていると
なおさらつかいもんになんない。
っていうかC#に移行したってパフォーマンスは
変わらないんだが。
むしろ遅くなるケースもある。
なんてあったけど使いもんになんなかったねえ。
外部のAPIを使っていると
なおさらつかいもんになんない。
っていうかC#に移行したってパフォーマンスは
変わらないんだが。
むしろ遅くなるケースもある。
828 ：仕様書無しさん：2006/03/22(水) 15:40:17
Javaは金のかからない理想的な実装実験用言語。
Javaが速いならSolarisはKernelからJavaで書いても良さそうなもんだが。
Javaが速いならSolarisはKernelからJavaで書いても良さそうなもんだが。
829 ：仕様書無しさん：2006/03/22(水) 16:25:55
それをいうならアセンブラで書かれている
コードをCで書いてもよさそうなんだが、
と言ってるのと同じレベル。
コードをCで書いてもよさそうなんだが、
と言ってるのと同じレベル。
Cを一切使っていないJavaで作られたOSって
すでにあるんだけど。
コアの部分だけアセンブラになってるけれども。
それに今更金かけてまでSolarisをJavaで書き直すメリットがあるのかどうか
って問題があるわけだが。
すでにあるんだけど。
コアの部分だけアセンブラになってるけれども。
それに今更金かけてまでSolarisをJavaで書き直すメリットがあるのかどうか
って問題があるわけだが。
831 ：仕様書無しさん：2006/03/23(木) 09:21:32
＞それをいうならアセンブラで書かれている
＞コードをCで書いてもよさそうなんだが、
＞と言ってるのと同じレベル。
4.3BSDはすべてCで書かれてたみたいですな。
付属のCコンパイラもCで書かれてたような。
＞Cを一切使っていないJavaで作られたOSって
＞すでにあるんだけど。
Javaは理想的な実装実験用言語と書いたし、そりゃシーズだけで作るのはありありだろう。で、実用性や特定用途利便性はあるの？名前出せないようなOS？
次はJavaで作られたデータベースソフトでも紹介してくだされ。
＞それに今更金かけてまでSolarisをJavaで書き直すメリットがあるのかどうか
＞って問題があるわけだが。
逆にJavaはわざわざSolarisを書き直すほどの有用性は持ってないってことだ。
＞コードをCで書いてもよさそうなんだが、
＞と言ってるのと同じレベル。
4.3BSDはすべてCで書かれてたみたいですな。
付属のCコンパイラもCで書かれてたような。
＞Cを一切使っていないJavaで作られたOSって
＞すでにあるんだけど。
Javaは理想的な実装実験用言語と書いたし、そりゃシーズだけで作るのはありありだろう。で、実用性や特定用途利便性はあるの？名前出せないようなOS？
次はJavaで作られたデータベースソフトでも紹介してくだされ。
＞それに今更金かけてまでSolarisをJavaで書き直すメリットがあるのかどうか
＞って問題があるわけだが。
逆にJavaはわざわざSolarisを書き直すほどの有用性は持ってないってことだ。
832 ：仕様書無しさん：2006/03/23(木) 10:13:12
JVMがCで書かれてたりしてｗ
833 ：仕様書無しさん：2006/03/23(木) 10:14:12
>>831
> ＞それをいうならアセンブラで書かれている
> ＞コードをCで書いてもよさそうなんだが、
> ＞と言ってるのと同じレベル。
> 4.3BSDはすべてCで書かれてたみたいですな。
> 付属のCコンパイラもCで書かれてたような。
中にportsで附属してるパッケージは100%PureC言語じゃないぞ。
> ＞それをいうならアセンブラで書かれている
> ＞コードをCで書いてもよさそうなんだが、
> ＞と言ってるのと同じレベル。
> 4.3BSDはすべてCで書かれてたみたいですな。
> 付属のCコンパイラもCで書かれてたような。
中にportsで附属してるパッケージは100%PureC言語じゃないぞ。
834 ：仕様書無しさん：2006/03/23(木) 10:16:08
>>831
> ＞Cを一切使っていないJavaで作られたOSって
> ＞すでにあるんだけど。
> Javaは理想的な実装実験用言語と書いたし、そりゃシーズだけで作るのはありありだろう。で、実用性や特定用途利便性はあるの？名前出せないようなOS？
前スレあたりで誰かが紹介していたMYCOMでぐぐれ。
> 次はJavaで作られたデータベースソフトでも紹介してくだされ。
それだったらすでにあるぞ。HyperSonicSQL, Apache Derbyを知らないのか？
OSよりも簡単に作れるはずだろう。
> ＞Cを一切使っていないJavaで作られたOSって
> ＞すでにあるんだけど。
> Javaは理想的な実装実験用言語と書いたし、そりゃシーズだけで作るのはありありだろう。で、実用性や特定用途利便性はあるの？名前出せないようなOS？
前スレあたりで誰かが紹介していたMYCOMでぐぐれ。
> 次はJavaで作られたデータベースソフトでも紹介してくだされ。
それだったらすでにあるぞ。HyperSonicSQL, Apache Derbyを知らないのか？
OSよりも簡単に作れるはずだろう。
>>833
Javaで書かれたやつはあるの？
Javaで書かれたやつはあるの？
836 ：仕様書無しさん：2006/03/23(木) 10:16:48
>>831
> ＞それに今更金かけてまでSolarisをJavaで書き直すメリットがあるのかどうか
> ＞って問題があるわけだが。
> 逆にJavaはわざわざSolarisを書き直すほどの有用性は持ってないってことだ。
お前はナイフでナイフを斬るような愚かなことを求めてどうするんだ？
> ＞それに今更金かけてまでSolarisをJavaで書き直すメリットがあるのかどうか
> ＞って問題があるわけだが。
> 逆にJavaはわざわざSolarisを書き直すほどの有用性は持ってないってことだ。
お前はナイフでナイフを斬るような愚かなことを求めてどうするんだ？
837 ：仕様書無しさん：2006/03/23(木) 10:19:43
ナイフというか、アホでも使える、刃の折れるカッターナイフってとこか
838 ：仕様書無しさん：2006/03/23(木) 10:29:39
839 ：仕様書無しさん：2006/03/23(木) 10:59:51
＞中にportsで附属してるパッケージは100%PureC言語じゃないぞ。
FreeBSDとかNetBSDとかの話じゃないぞ。4.3BSDだ。ミニコン用しかなかった当時の話。ちょうどCがJavaみたいな扱いになってた頃だ。
＞それだったらすでにあるぞ。HyperSonicSQL, Apache Derbyを知らないのか？
＞OSよりも簡単に作れるはずだろう。
論点はそこには無いってば。
実装実験用言語ってことだから、何があっても当たり前。実験だからな。
Javaで書かれたそれらが実用に耐えうるのか？実験以外にニーズはあるのか？
ってことだよ。
FreeBSDとかNetBSDとかの話じゃないぞ。4.3BSDだ。ミニコン用しかなかった当時の話。ちょうどCがJavaみたいな扱いになってた頃だ。
＞それだったらすでにあるぞ。HyperSonicSQL, Apache Derbyを知らないのか？
＞OSよりも簡単に作れるはずだろう。
論点はそこには無いってば。
実装実験用言語ってことだから、何があっても当たり前。実験だからな。
Javaで書かれたそれらが実用に耐えうるのか？実験以外にニーズはあるのか？
ってことだよ。
840 ：仕様書無しさん：2006/03/23(木) 11:26:51
お前ホントに何も知らないんだな。
HSQLDBもApache Derbyも実験用でもなく
実用化されているわけだが。
JBossには標準でHSQLDBがバンドルされている。
インメモリモードによってHSQLDBはメモリ上にテーブルを作成することができる
軽量RDBMSだ。だからAppletやデスクトップJavaアプリでも気軽に利用することが可能だ。
DerbyはIBMのバックアップによって普及し始めている。
HSQLDBもApache Derbyも実験用でもなく
実用化されているわけだが。
JBossには標準でHSQLDBがバンドルされている。
インメモリモードによってHSQLDBはメモリ上にテーブルを作成することができる
軽量RDBMSだ。だからAppletやデスクトップJavaアプリでも気軽に利用することが可能だ。
DerbyはIBMのバックアップによって普及し始めている。
842 ：仕様書無しさん：2006/03/23(木) 12:14:20
JBossに使われているのだが。
大雑把に言うと
HSQLDBは小規模向けでMySQL似で
Apache Derbyは大規模向けでPostgreSQLやOracle似で
という感じ
大雑把に言うと
HSQLDBは小規模向けでMySQL似で
Apache Derbyは大規模向けでPostgreSQLやOracle似で
という感じ
>>842
JBossでもOracleを使うわけだが。
JBossでもOracleを使うわけだが。
844 ：仕様書無しさん：2006/03/23(木) 12:49:11
JBOSSやTOMCATがメガバンクのバックボーンに使われているはずがない
845 ：仕様書無しさん：2006/03/23(木) 13:38:51
ひどいのはテーブルにプライマリキーが一つもないこと
テーブル同士の関連が定義されてないこと
NOT NULLが定義されてないこと
テーブルが正規化されてないこと
40歳のC言語しかできないド素人がＤＢ設計すると
ろくなことねえな。
後生にまでずるずる糞テーブルを引きヅラれるのは
超ウザ。
O-Rマッピングもつかってくれないから
ソースコードとDBテーブルとが密接に依存し合って
むかつきます。
テーブル同士の関連が定義されてないこと
NOT NULLが定義されてないこと
テーブルが正規化されてないこと
40歳のC言語しかできないド素人がＤＢ設計すると
ろくなことねえな。
後生にまでずるずる糞テーブルを引きヅラれるのは
超ウザ。
O-Rマッピングもつかってくれないから
ソースコードとDBテーブルとが密接に依存し合って
むかつきます。
846 ：仕様書無しさん：2006/03/23(木) 21:02:18
なんでプライマリキーがないと困るんだ？
ループで1レコードごと処理するつもりなのか？
ループで1レコードごと処理するつもりなのか？
格言保守スレ？
例えばある製品の受注状態を格納するテーブルがあるとして、
その売上額が発注会社によって決められた基本レートとドル円の為替レートによって決まり、
受注状態の変化（見積→受注→請求）もその都度記録する場合に、
そのテーブルにプライマリキーがつくメリットある？
その売上額が発注会社によって決められた基本レートとドル円の為替レートによって決まり、
受注状態の変化（見積→受注→請求）もその都度記録する場合に、
そのテーブルにプライマリキーがつくメリットある？
>>848
その場合、受注ID及びその状態の2カラムが主キーになるな
その場合、受注ID及びその状態の2カラムが主キーになるな
850 ：仕様書無しさん：2006/03/23(木) 21:33:25
見積もりの取り直しもあって、受注は１件だけど２回に分けて請求とかある場合は？
枝番つくだけじゃないの？
> 受注は１件だけど２回に分けて請求とかある
明確な要件定義があるんだから、テーブル分けるでしょ
明確な要件定義があるんだから、テーブル分けるでしょ
853 ：69式フリーPG ◆hND3Lufios ：2006/03/23(木) 21:46:22
受注テーブルと受注詳細テーブルで1対nかな。
854 ：仕様書無しさん：2006/03/23(木) 21:48:51
月次売り上げ集計を見積もり金額ベース、受注金額ベース、請求金額ベースで計算したり、
それらを製品ごとに集計して表示したり、それらを会社ベースで計算したりするときに、
テーブルをずらずらjoinしなきゃなんないよね？
それらを製品ごとに集計して表示したり、それらを会社ベースで計算したりするときに、
テーブルをずらずらjoinしなきゃなんないよね？
855 ：仕様書無しさん：2006/03/23(木) 21:49:29
>>848がつくるテーブルは冗長すぎて酷いテーブルだな。
ログを記録するためだけにDBを使ってるのか。
だったら一つのテーブルに一度にINSERTしようとせず
複数のテーブルと関連づけてINSERTしたほうが冗長な
データをカットできて容量節約とパフォーマンス向上につながるぞ。
ログを記録するためだけにDBを使ってるのか。
だったら一つのテーブルに一度にINSERTしようとせず
複数のテーブルと関連づけてINSERTしたほうが冗長な
データをカットできて容量節約とパフォーマンス向上につながるぞ。
856 ：仕様書無しさん：2006/03/23(木) 21:51:37
プライマリキーいらないとか言ってる馬鹿な
奴が作ったテーブルを再構築するために
やっぱりO-Rマッピングは必要だな。
テーブルが変わればソースコードも変えないと逝けないので
やっぱりO-Rマッピングは重宝する。
奴が作ったテーブルを再構築するために
やっぱりO-Rマッピングは必要だな。
テーブルが変わればソースコードも変えないと逝けないので
やっぱりO-Rマッピングは重宝する。
857 ：仕様書無しさん：2006/03/23(木) 21:52:06
おおビジネスロジック満開
O-Rマッピングで854みたいな処理できるの？
結局SQL書くんでしょ？
結局SQL書くんでしょ？
859 ：仕様書無しさん：2006/03/23(木) 21:57:34
Java厨なら素直にOODB使えや。EJBも使いこなせんやつには無理だろうけど。
860 ：仕様書無しさん：2006/03/23(木) 21:59:59
OODBの製品ってあんの？
性別とか年号テーブル作ってるの見ると、なぜか和む。
全角一文字分しか確保してないけど、0は男で1が女とか決まってるのに意味あるのかな。
全角一文字分しか確保してないけど、0は男で1が女とか決まってるのに意味あるのかな。
862 ：仕様書無しさん：2006/03/23(木) 22:15:44
しかし、リテラルでソースに埋めるのもどうかな。
そういうのはたいていプロパティファイルから読み込むだろ
コード定義書こそが真のマスタテーブルって感じだな
コード定義書こそが真のマスタテーブルって感じだな
プロパティをDBに入れてそのDBアクセスのためにリテラルでソースに埋め込むｗ
とてもjavaらしい動作
866 ：仕様書無しさん：2006/03/23(木) 22:26:34
867 ：仕様書無しさん：2006/03/23(木) 22:28:11
>>858
> O-Rマッピングで854みたいな処理できるの？
できる。
> 結局SQL書くんでしょ？
かかなくてもいいようにできる。
っていうかO-Rマッピングを使えばテーブル名の変更などによる
依存度は大幅にへる。
っていうかモジュール間の関係を疎にすることが
O-Rマッピングの目的の一つだから。
> O-Rマッピングで854みたいな処理できるの？
できる。
> 結局SQL書くんでしょ？
かかなくてもいいようにできる。
っていうかO-Rマッピングを使えばテーブル名の変更などによる
依存度は大幅にへる。
っていうかモジュール間の関係を疎にすることが
O-Rマッピングの目的の一つだから。
管理ページもうけて、そっから定数更新要求を出したときだけ、
コード値をメモリに展開しなおすって方法はダメな方法なの？
再起動はぜったいにしないぞって感じでやりたいのだが
コード値をメモリに展開しなおすって方法はダメな方法なの？
再起動はぜったいにしないぞって感じでやりたいのだが
結局1テーブルまるごとビーンズにしただけのものが使われるのがO-Rマッピングです。
870 ：仕様書無しさん：2006/03/23(木) 22:29:56
871 ：仕様書無しさん：2006/03/23(木) 22:30:37
>>865
全然。ResourceBundleやSpringを使っちゃ悪いのか？
全然。ResourceBundleやSpringを使っちゃ悪いのか？
872 ：仕様書無しさん：2006/03/23(木) 22:31:24
873 ：仕様書無しさん：2006/03/23(木) 22:31:44
874 ：仕様書無しさん：2006/03/23(木) 22:32:26
>>868
つHSQLDB - インメモリモード
つHSQLDB - インメモリモード
875 ：仕様書無しさん：2006/03/23(木) 22:33:31
O/Rマッパにキャッシュ機構がついているのも
どうしても遅いから
つまりメモリに展開しているだけｗ
どうしても遅いから
つまりメモリに展開しているだけｗ
878 ：69式フリーPG ◆hND3Lufios ：2006/03/23(木) 22:37:25
つiniファイル
879 ：仕様書無しさん：2006/03/24(金) 02:23:16
880 ：仕様書無しさん：2006/03/24(金) 02:24:12
881 ：仕様書無しさん：2006/03/24(金) 02:25:24
observerってあほか、ほんとにそんな場面で使うのか？
883 ：仕様書無しさん：2006/03/24(金) 09:10:24
スレッドでwhile()で常に監視して
更新を通知する
更新を通知する
>883
Java厨っぽくていいね
君仕事できるでしょ
Java厨っぽくていいね
君仕事できるでしょ
885 ：仕様書無しさん：2006/03/25(土) 09:55:41
それでなぜ厨になるのか理解できない
WinでC使う場合は、
>スレッドでwhile()で常に監視して
という手法は、基本的にパワーが必要で他に
アプリケーションが無いと言う前提のゲーム系
で使われる手法。悪くは無いが良くは無い。
漏れはループ処理はユーザインターフェーススレッド
のアイドルでやる。
>スレッドでwhile()で常に監視して
という手法は、基本的にパワーが必要で他に
アプリケーションが無いと言う前提のゲーム系
で使われる手法。悪くは無いが良くは無い。
漏れはループ処理はユーザインターフェーススレッド
のアイドルでやる。
887 ：仕様書無しさん：2006/03/25(土) 10:48:35
じゃ、Timerクラスで数時間おきに監視する。
>885
ポーリングで監視してるから厨なんだよ
非同期で作れないやつはクズ
ポーリングで監視してるから厨なんだよ
非同期で作れないやつはクズ
>>888
ｋｗｓｋ
ｋｗｓｋ
890 ：仕様書無しさん：2006/03/25(土) 13:12:56
彼は厨であってもJava中ではない
非同期で監視する根っこの部分はどうやるんですか？
>>886
UIがないアプリではどうすればよいでしょうか？
UIがないアプリではどうすればよいでしょうか？
893 ：仕様書無しさん：2006/03/26(日) 15:55:32
Javaにはミューテックスやセマフォはないんですか？
894 ：仕様書無しさん：2006/03/27(月) 00:02:34
895 ：仕様書無しさん：2006/03/27(月) 10:47:37
JAVA厨って低レベルな話にはついてこれないのね
あっ、できあいのもひっつけたりくっつけたりが仕事だったね
無いものは誰かが作るまでひたすらまって、
世にでてきたらまるで自分が作ったかのように解説しはじめるだけだもんね
解説といっても中身は全く知らないから上っ面だけってのも凄いね
あっ、できあいのもひっつけたりくっつけたりが仕事だったね
無いものは誰かが作るまでひたすらまって、
世にでてきたらまるで自分が作ったかのように解説しはじめるだけだもんね
解説といっても中身は全く知らないから上っ面だけってのも凄いね
896 ：仕様書無しさん：2006/03/27(月) 10:49:20
>>894
古いバージョンは？
古いバージョンは？
897 ：仕様書無しさん：2006/03/27(月) 11:03:52
898 ：仕様書無しさん：2006/03/27(月) 11:34:09
>無いものは誰かが作るまでひたすらまって、
>世にでてきたらまるで自分が作ったかのように解説しはじめるだけだもんね
ﾜﾗﾀ
>世にでてきたらまるで自分が作ったかのように解説しはじめるだけだもんね
ﾜﾗﾀ
899 ：仕様書無しさん：2006/03/27(月) 11:43:25
900 ：仕様書無しさん：2006/03/27(月) 12:34:25
901 ：仕様書無しさん：2006/03/27(月) 12:36:42
これこそがJava厨ですよ！
まさにJava厨の真骨頂！
とくと899の発言をご覧あれ！
まさにJava厨の真骨頂！
とくと899の発言をご覧あれ！
902 ：仕様書無しさん：2006/03/27(月) 12:43:14
こんどは逆襲で
ツールのスキルを長々と列挙してくるぞ。ｗ
ツールのスキルを長々と列挙してくるぞ。ｗ
903 ：仕様書無しさん：2006/03/27(月) 12:51:44
低級言語で低レベルなコード組んでろ。
>ツールのスキルを長々と列挙してくるぞ。
もちろん誰かが作ったものだろｗ
人のふんどしで相撲取らせたら最強だからな
もちろん誰かが作ったものだろｗ
人のふんどしで相撲取らせたら最強だからな
905 ：仕様書無しさん：2006/03/27(月) 14:08:39
899のIQに驚愕！！
906 ：仕様書無しさん：2006/03/27(月) 14:32:47
あの長々と列挙してくるところなんて
長年Javaにはenumさえ無かった怨念としか言えないな。
長年Javaにはenumさえ無かった怨念としか言えないな。
907 ：仕様書無しさん：2006/03/27(月) 14:36:20
約一名のバブル世代が必死に自作自演して暴れているようです。
908 ：仕様書無しさん：2006/03/27(月) 14:38:11
C言語厨痛いな
朝鮮人みたいに捏造話ばかりで
朝鮮人みたいに捏造話ばかりで
910 ：名無しさん＠お腹いっぱい。：2006/03/27(月) 14:49:09
Java厨には908のレスが精一杯らしいなｗ
ちょっといじめすぎたかな？
泣いちゃった？
ごめんよ
ちょっといじめすぎたかな？
泣いちゃった？
ごめんよ
>>907-908
また中二病患者か。
また中二病患者か。
913 ：仕様書無しさん：2006/03/27(月) 14:53:42
C言語厨は妄想乙だなw
バカみたいにくだらないことに無駄なエネルギーを
費やすのがC言語厨の特徴
バカみたいにくだらないことに無駄なエネルギーを
費やすのがC言語厨の特徴
バブル社員のC言語厨があばれてるようです。
915 ：仕様書無しさん：2006/03/27(月) 14:54:45
ほぃっ！ バブル！ バブル！ バブル！ バブル！
さんはいっ！
ほぃっ！ バブル！ バブル！ バブル！ バブル！
ほぃっ！ バブル！ バブル！ バブル！ バブル！
ほぃっ！ バブル！ バブル！ バブル！ バブル！
さんはいっ！
ほぃっ！ バブル！ バブル！ バブル！ バブル！
ほぃっ！ バブル！ バブル！ バブル！ バブル！
ほぃっ！ バブル！ バブル！ バブル！ バブル！
916 ：仕様書無しさん：2006/03/27(月) 14:55:03
バブルC言語厨
917 ：仕様書無しさん：2006/03/27(月) 14:55:19
バブリーC言語
918 ：仕様書無しさん：2006/03/27(月) 14:55:33
ビジュアルCバブル
Ｃ言語厨のバブルが崩壊したようですね
920 ：仕様書無しさん：2006/03/27(月) 15:11:59
仕事がなくなりニートになったC言語厨が
月曜の昼からハロワにも行かずに
暴れていると聞いて飛んできますた。
月曜の昼からハロワにも行かずに
暴れていると聞いて飛んできますた。
921 ：仕様書無しさん：2006/03/27(月) 15:23:43
Cゲンゲンゴチューは必死ですね
922 ：仕様書無しさん：2006/03/27(月) 15:27:04
あんな事でこれだけ悔しがるジャワ注ってｗ
923 ：仕様書無しさん：2006/03/27(月) 19:10:32
ニートの自作自演
924 ：仕様書無しさん：2006/03/27(月) 19:11:57
ジャワ注？
ジャワカレーを注ぐのか？
まあいいかC言語厨はカレーがたべたいらしい
ジャワカレーを注ぐのか？
まあいいかC言語厨はカレーがたべたいらしい
925 ：仕様書無しさん：2006/03/27(月) 19:12:02
Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.4
http://pc8.2ch.net/test/read.cgi/tech/1134701684/
http://pc8.2ch.net/test/read.cgi/tech/1134701684/
ﾌﾟﾌﾟ C言語厨にカレーを食わせてやれよ
927 ：69式フリーPG ◆hND3Lufios ：2006/03/27(月) 20:13:20
すみません。質問です。
どなたかJavaでfork()する方法をご教授下さい。
よろしくお願いします。m(__)m
どなたかJavaでfork()する方法をご教授下さい。
よろしくお願いします。m(__)m
928 ：仕様書無しさん：2006/03/27(月) 21:25:54
929 ：仕様書無しさん：2006/03/27(月) 21:27:45
おっさんおっさんおっさん
930 ：仕様書無しさん：2006/03/27(月) 21:45:25
もまいら、とりあえず、JavaもCも使えるようにしとけ。
Cしか書けないやつはLinuxのオープンソースコミュニティにでも貢献しろ。
Javaしか書けないやつはホラ吹き設計者になって下流を苦しませる前に氏ね。
Cしか書けないやつはLinuxのオープンソースコミュニティにでも貢献しろ。
Javaしか書けないやつはホラ吹き設計者になって下流を苦しませる前に氏ね。
なんでLinuxなんだよｗ
Javaﾗｰが低レベルな話をできないのはその通り。
単なる役割分担だけどな。
正直言ってJavaﾗｰなオレとしてはC使い達がドライバ作ったりしてるの見て
うらやましく思うよ。
でも今からあえてCを学ぶための時間を割くかどうかは悩んでる。
単なる役割分担だけどな。
正直言ってJavaﾗｰなオレとしてはC使い達がドライバ作ったりしてるの見て
うらやましく思うよ。
でも今からあえてCを学ぶための時間を割くかどうかは悩んでる。
933 ：仕様書無しさん：2006/03/27(月) 22:32:41
> なんでLinuxなんだよｗ
“UNIX”は日本マランツの登録商標です。
“UNIX”はAT&T ベル研究所が開発したオペレーティングシステムの
名称です。
“UNIX”は日本マランツの登録商標です。
“UNIX”はAT&T ベル研究所が開発したオペレーティングシステムの
名称です。
はぁ？
BSD差別かよ、心の狭い人間だ
BSD差別かよ、心の狭い人間だ
Cか、、リハビリ必要だな
いまさらクラスのない世界で組めるかどうか自身なし
いまさらクラスのない世界で組めるかどうか自身なし
クラスのあるなしは問題ないが
Javaの豊富なAPIに慣れすぎて一から組む気になれない
困った・・・ｗ
Javaの豊富なAPIに慣れすぎて一から組む気になれない
困った・・・ｗ
>>930
Javaしか書けない奴はクラスライブラリ統一に貢献させろ
Javaしか書けない奴はクラスライブラリ統一に貢献させろ
なんだかしおらしくなったな。
>>937
クラスライブラリ統一に関しちゃドトネトしか書けないやつの方が向いていると思う。
Javaしか書けないやつに任せると実装の末端コードを見た目だけシンプルに書くためにフレームワークやクラスライブラリを複雑に書きすぎてその全貌を知らないと目的のシンプルなコードを理解できないという一種のトートロジーに陥る悪寒。
そんなもんあいつらの趣味で何世代も回されたらかなわん。
クラスライブラリ統一に関しちゃドトネトしか書けないやつの方が向いていると思う。
Javaしか書けないやつに任せると実装の末端コードを見た目だけシンプルに書くためにフレームワークやクラスライブラリを複雑に書きすぎてその全貌を知らないと目的のシンプルなコードを理解できないという一種のトートロジーに陥る悪寒。
そんなもんあいつらの趣味で何世代も回されたらかなわん。
つかよう、Cしか出来ないおっさんなんてマジでいると思う？
Java位できるよ。出来ると公言すると、アホ仕事を押し付けられるから出来ないことにしてるだけ。
Java位できるよ。出来ると公言すると、アホ仕事を押し付けられるから出来ないことにしてるだけ。
Java厨に何人デザパタ理解して使いこなしている人がいる？
そんなやつらがまともなフレームワークどころか、
フレームワークじたい書けるか怪しいもんだ。
そんなJava厨房に任せたら糞クラスを大量生産して結局使えなくてすべて捨てるのが目に見えてるよｗ
そんなやつらがまともなフレームワークどころか、
フレームワークじたい書けるか怪しいもんだ。
そんなJava厨房に任せたら糞クラスを大量生産して結局使えなくてすべて捨てるのが目に見えてるよｗ
動的バインディングがコンピュータにとってどれくらい負担になるか。
そういう感覚が無い奴にライブラリやフレームワークのような基盤を作るのは無理。
他人のコードを支えるコードを舐めてはいけない。
そういう感覚が無い奴にライブラリやフレームワークのような基盤を作るのは無理。
他人のコードを支えるコードを舐めてはいけない。
Javaは使いこなそうとしたらそもそもがコンストラクタ軽視になるんだよな
てかGC積んだOO言語は全部そういう傾向になる
てかGC積んだOO言語は全部そういう傾向になる
デザインパターンの説明はできてもその実装ができないおっさんを知っている。
デザインパターンの裏に流れる思想みたいなモノをまるで理解していない。
そういえばあいつはデザインパターンとか以前にセンチネルすら使えなかったな。
デザインパターンの裏に流れる思想みたいなモノをまるで理解していない。
そういえばあいつはデザインパターンとか以前にセンチネルすら使えなかったな。
>>944
フレームワークの類はnewが埋もれてく傾向がある
フレームワークの類はnewが埋もれてく傾向がある
フレームワークは設計の幅を制約する。
基盤は知識や美意識だけでは作れない。
バランス感覚と経験が必須。
バランス感覚と経験が必須。
hibernateは失敗だったと思う
何あれ？対応するXML探さないとテーブルも特定できないじゃないか
何あれ？対応するXML探さないとテーブルも特定できないじゃないか
Jakartaは美意識に振りすぎてるよな。
951 ：仕様書無しさん：2006/03/28(火) 00:10:16
JavaとXMLの関係って失敗しているな。
AxisのクライアントXML解析しかり、
しょせんTomcatのコンフィグレーション用途しか使えてない。
AxisのクライアントXML解析しかり、
しょせんTomcatのコンフィグレーション用途しか使えてない。
そういえばaxisって重くね？
953 ：仕様書無しさん：2006/03/28(火) 00:12:29
おっさんへのfork()の回答は絶対でないに1000万java
954 ：仕様書無しさん：2006/03/28(火) 00:13:51
axis最悪。糞糞重い。
がJava厨は最新のaxis 2.0などインストールもできず
使ってないからレスは絶対でない。
がJava厨は最新のaxis 2.0などインストールもできず
使ってないからレスは絶対でない。
955 ：仕様書無しさん：2006/03/28(火) 00:15:05
axisがXMLパースしていると時間がかかりすぎて
TCPタイムアウチになっちゃよ。
TCPタイムアウチになっちゃよ。
XMLパーサーなんて速度命だろうニアホみたいだよな。
MSXMLの足元にも及ばない糞ライブラリ。それがaxis
MSXMLの足元にも及ばない糞ライブラリ。それがaxis
957 ：仕様書無しさん：2006/03/28(火) 00:16:25
MSXMLは確かに速いからな。サーバサービスを
ローカルサービスのような速度で使わせてくれる。
ローカルサービスのような速度で使わせてくれる。
958 ：仕様書無しさん：2006/03/28(火) 00:21:48
Javaはforkなんて出来ません。
仮に出来たとしても、プロセス生成にとんでもない時間がかかってしまいます。
↑ほれ回答。
仮に出来たとしても、プロセス生成にとんでもない時間がかかってしまいます。
↑ほれ回答。
XMLのパースってコストの掛かることなの？
ブランクの圧縮ルールとかは確かにコストが高そうだけど
他はすんなりとパースできる気がする
ブランクの圧縮ルールとかは確かにコストが高そうだけど
他はすんなりとパースできる気がする
antだmavenだ、FindBugsだCheckStyleだ！
っていう糞厨はどこにいった？
っていう糞厨はどこにいった？
ISAPI厨とIOCP厨も最近見ないなｗ
xdoclet厨もみないぞ
お葬儀ですか？
sage
966 ：仕様書無しさん：2006/03/28(火) 10:35:20
>>927
Apache Antを使え
Apache Antを使え
967 ：仕様書無しさん：2006/03/28(火) 10:36:06
968 ：仕様書無しさん：2006/03/28(火) 10:37:18
>>932
> Javaﾗｰが低レベルな話をできないのはその通り。
> 単なる役割分担だけどな。
> 正直言ってJavaﾗｰなオレとしてはC使い達がドライバ作ったりしてるの見て
> うらやましく思うよ。
自演乙。残念ながらJavaでもドライバ作れるようになってきている。
> でも今からあえてCを学ぶための時間を割くかどうかは悩んでる。
Javaができるならポインタのことはすでにわかっているはずだ。
clone()で悩まされた経験があるならすぐに理解できる。
> Javaﾗｰが低レベルな話をできないのはその通り。
> 単なる役割分担だけどな。
> 正直言ってJavaﾗｰなオレとしてはC使い達がドライバ作ったりしてるの見て
> うらやましく思うよ。
自演乙。残念ながらJavaでもドライバ作れるようになってきている。
> でも今からあえてCを学ぶための時間を割くかどうかは悩んでる。
Javaができるならポインタのことはすでにわかっているはずだ。
clone()で悩まされた経験があるならすぐに理解できる。
969 ：仕様書無しさん：2006/03/28(火) 10:37:49
>>934
BSDは最新のJavaのライセンスを受けていないので糞に近い。
BSDは最新のJavaのライセンスを受けていないので糞に近い。
970 ：仕様書無しさん：2006/03/28(火) 10:38:35
>>936
> クラスのあるなしは問題ないが
> Javaの豊富なAPIに慣れすぎて一から組む気になれない
> 困った・・・ｗ
自演乙。一から組み立てる必要になることはJavaでも良くある。
無駄に「車輪の再発明」をしない程度にやらないとバカ呼ばわりされるだけだが。
> クラスのあるなしは問題ないが
> Javaの豊富なAPIに慣れすぎて一から組む気になれない
> 困った・・・ｗ
自演乙。一から組み立てる必要になることはJavaでも良くある。
無駄に「車輪の再発明」をしない程度にやらないとバカ呼ばわりされるだけだが。
971 ：仕様書無しさん：2006/03/28(火) 10:40:01
>>937
Javaしか賭けない奴がそんなことができるわけがない。
できたと思っても統一感がない。
なぜならデータベースのこともServletの仕組みすらもわかってないからだ。
それにリファクタリングとはなんぞや？と聞かれてもJavaしか
知らないために答えられないからだ。
そんな奴にライブラリの管理は任せられない。
Javaしか賭けない奴がそんなことができるわけがない。
できたと思っても統一感がない。
なぜならデータベースのこともServletの仕組みすらもわかってないからだ。
それにリファクタリングとはなんぞや？と聞かれてもJavaしか
知らないために答えられないからだ。
そんな奴にライブラリの管理は任せられない。
972 ：仕様書無しさん：2006/03/28(火) 10:41:16
>>939
> >>937
> クラスライブラリ統一に関しちゃドトネトしか書けないやつの方が向いていると思う。
> Javaしか書けないやつに任せると実装の末端コードを見た目だけシンプルに書くためにフレームワークやクラスライブラリを複雑に書きすぎてその全貌を知らないと目的のシンプルなコードを理解できないという一種のトートロジーに陥る悪寒。
Javaしか賭けない奴がフレームワークを知っているわけがないだろう。
Javaしか書けないということはTomcatやStrutsも使いこなせないと言う
意味なんだからな。そんなんでは近頃のJavaの仕事なんていっこうに勤まらんが。
> >>937
> クラスライブラリ統一に関しちゃドトネトしか書けないやつの方が向いていると思う。
> Javaしか書けないやつに任せると実装の末端コードを見た目だけシンプルに書くためにフレームワークやクラスライブラリを複雑に書きすぎてその全貌を知らないと目的のシンプルなコードを理解できないという一種のトートロジーに陥る悪寒。
Javaしか賭けない奴がフレームワークを知っているわけがないだろう。
Javaしか書けないということはTomcatやStrutsも使いこなせないと言う
意味なんだからな。そんなんでは近頃のJavaの仕事なんていっこうに勤まらんが。
973 ：仕様書無しさん：2006/03/28(火) 10:42:09
>>941
> Java厨に何人デザパタ理解して使いこなしている人がいる？
まず「Java厨」の定義は一体なんだ？
もう一度「Java厨」を再定義し直せ。
さもないとここで議論してもえんえんと堂々巡りになるだけだ。
> Java厨に何人デザパタ理解して使いこなしている人がいる？
まず「Java厨」の定義は一体なんだ？
もう一度「Java厨」を再定義し直せ。
さもないとここで議論してもえんえんと堂々巡りになるだけだ。
974 ：仕様書無しさん：2006/03/28(火) 10:44:27
>>943
> Javaは使いこなそうとしたらそもそもがコンストラクタ軽視になるんだよな
> てかGC積んだOO言語は全部そういう傾向になる
コンストラクタ軽視になる理由を具体的に詳しく書いてくれ。
初心者で無駄にコンストラクタのオーバーロードをするバカがいることは
確かだが。this()のことも知らない。staticメソッドを用いたテクニックgetInstance()やvalueOf()
を使ってインスタンスを生成する方法も知らなで負荷をかけるバカもいるが。
> Javaは使いこなそうとしたらそもそもがコンストラクタ軽視になるんだよな
> てかGC積んだOO言語は全部そういう傾向になる
コンストラクタ軽視になる理由を具体的に詳しく書いてくれ。
初心者で無駄にコンストラクタのオーバーロードをするバカがいることは
確かだが。this()のことも知らない。staticメソッドを用いたテクニックgetInstance()やvalueOf()
を使ってインスタンスを生成する方法も知らなで負荷をかけるバカもいるが。
975 ：仕様書無しさん：2006/03/28(火) 10:46:28
>>946
> >>944
> フレームワークの類はnewが埋もれてく傾向がある
たとえばどういうフレームワークだ？
Decoratorパターンを使っただけのフレームワークか？
そりゃnewだらけだな。だがnewにしたら＝重たくなると
考えるのはせっかちだ。よくソースコードを見ろ。
レイジーローディングパターンを使っているものがあるなら
newを使っても軽くなる。
それから上で示した getInstance()やvalueOf()を使うテクニックで
インスタンスを生成する負担を軽くする方法もある。
Factory Methodパターンだが。
> >>944
> フレームワークの類はnewが埋もれてく傾向がある
たとえばどういうフレームワークだ？
Decoratorパターンを使っただけのフレームワークか？
そりゃnewだらけだな。だがnewにしたら＝重たくなると
考えるのはせっかちだ。よくソースコードを見ろ。
レイジーローディングパターンを使っているものがあるなら
newを使っても軽くなる。
それから上で示した getInstance()やvalueOf()を使うテクニックで
インスタンスを生成する負担を軽くする方法もある。
Factory Methodパターンだが。
976 ：仕様書無しさん：2006/03/28(火) 10:47:56
>>949
> hibernateは失敗だったと思う
> 何あれ？対応するXML探さないとテーブルも特定できないじゃないか
Hibernateは多目的に使えるわけだが。
テーブルからXMLファイルやJavaコード自動生成だけでなく
XMLファイルまたはJavaコードのXDocletコメントまたはアノテーションから
テーブルを自動生成することもできる。
具体的に何が失敗だといいたいのか？
> hibernateは失敗だったと思う
> 何あれ？対応するXML探さないとテーブルも特定できないじゃないか
Hibernateは多目的に使えるわけだが。
テーブルからXMLファイルやJavaコード自動生成だけでなく
XMLファイルまたはJavaコードのXDocletコメントまたはアノテーションから
テーブルを自動生成することもできる。
具体的に何が失敗だといいたいのか？
977 ：仕様書無しさん：2006/03/28(火) 10:48:47
>>951
> JavaとXMLの関係って失敗しているな。
> AxisのクライアントXML解析しかり、
> しょせんTomcatのコンフィグレーション用途しか使えてない。
具体的に詳しく。
まさか、かわりに.NETのXMLとの関係なら成功とでも。不毛な議論だ。
> JavaとXMLの関係って失敗しているな。
> AxisのクライアントXML解析しかり、
> しょせんTomcatのコンフィグレーション用途しか使えてない。
具体的に詳しく。
まさか、かわりに.NETのXMLとの関係なら成功とでも。不毛な議論だ。
978 ：仕様書無しさん：2006/03/28(火) 10:49:28
979 ：仕様書無しさん：2006/03/28(火) 10:50:10
>>963
CheckstyleのかわりにFindBugsのほうが重宝する
CheckstyleのかわりにFindBugsのほうが重宝する
980 ：仕様書無しさん：2006/03/28(火) 10:51:48
981 ：仕様書無しさん：2006/03/28(火) 12:10:06
長文様に手も足も出ないC言語厨
982 ：仕様書無しさん：2006/03/28(火) 12:57:29
黄昏の短文C言語厨
983 ：仕様書無しさん：2006/03/28(火) 13:01:40
やっぱりC++が最強だな
984 ：仕様書無しさん：2006/03/28(火) 13:06:26
黄昏れるC++厨
その間に遅れをとってしまったC++厨
その間に遅れをとってしまったC++厨
985 ：名無しさん＠お腹いっぱい。：2006/03/28(火) 15:10:55
いつまでたっても他力本願Java厨
自分達でなんとかしようって気はねーのか？
ちょっとはてめぇで作れよ
自分達でなんとかしようって気はねーのか？
ちょっとはてめぇで作れよ
986 ：仕様書無しさん：2006/03/28(火) 15:31:53
やっぱC++が最強だな
987 ：仕様書無しさん：2006/03/28(火) 15:34:29
いつまでたっても他力本願C++厨
自分達でなんとかしようって気はねーのか？
ちょっとはてめぇで作れよ
自分達でなんとかしようって気はねーのか？
ちょっとはてめぇで作れよ
988 ：名無しさん＠お腹いっぱい。：2006/03/28(火) 15:40:51
今こそDelphiですよ、みなさん
Java､C、C++の問題点を全て解決に導いてくれること必至です
Java､C、C++の問題点を全て解決に導いてくれること必至です
>>969
JVM高いんだよ、手前実装するしかないが性能に期待できないし
JVM高いんだよ、手前実装するしかないが性能に期待できないし
あれだ、C++厨が仕様を元にJVM作ってオプソで公開すればいんじゃね？ｗ
kaffeのことか？
992 ：仕様書無しさん：2006/03/28(火) 21:25:16
993 ：仕様書無しさん：2006/03/28(火) 21:32:02
車輪の再発明ですね！
994 ：仕様書無しさん：2006/03/28(火) 21:47:24
オープンソース化しろという動きに答えて
Java SE6は一部ソースコードが公開されているわけだが。
へたに類似品を作ってもVJ++事件のM$ように裁判で
訴えられるだけ。
Java SE6は一部ソースコードが公開されているわけだが。
へたに類似品を作ってもVJ++事件のM$ように裁判で
訴えられるだけ。
Java厨が息巻いてるが、理論はいいから実装を示せよ。
失敗してないって言うなら成功してるモノ(は無理か)、せめて例ぐらい具体的に示してみ？
たぶんどっかで別の理由で破綻してるだろうけどな。
失敗してないって言うなら成功してるモノ(は無理か)、せめて例ぐらい具体的に示してみ？
たぶんどっかで別の理由で破綻してるだろうけどな。
996 ：仕様書無しさん：2006/03/28(火) 22:54:44
> 失敗してないって言うなら成功してるモノ(は無理か)、せめて例ぐらい
> 具体的に示してみ？
> たぶんどっかで別の理由で破綻してるだろうけどな。
cat を C で書くとせいぜい三十行前後（ファイル一個）だが、
真面目にJava で書いたら、合計で下手すると三百行以上（ファイル七個とか
八個とか）になる。
そのかわり、ちょっと新しいプログラムを書こうというときに、C だと
丸ごとコピって似たようなプログラムが一本できあがるが、
Java だと「必要な部分だけコピって追加」ができて、しかも（初期の
設計がよくできていれば）大規模化したときに破綻しにくい。
C で書いたシステムを拡張しようとしてC++ を使って失敗し、結局
Java で書く羽目になる。Perl で書いたシステムを格調しようとして
Ruby や PHP を使って失敗し、結局 Java で書く羽目になる。
Java に「成功した」プロダクトはない（なにより“遅い”）。失敗
しなかったプロダクトが存在するだけだ。
> 具体的に示してみ？
> たぶんどっかで別の理由で破綻してるだろうけどな。
cat を C で書くとせいぜい三十行前後（ファイル一個）だが、
真面目にJava で書いたら、合計で下手すると三百行以上（ファイル七個とか
八個とか）になる。
そのかわり、ちょっと新しいプログラムを書こうというときに、C だと
丸ごとコピって似たようなプログラムが一本できあがるが、
Java だと「必要な部分だけコピって追加」ができて、しかも（初期の
設計がよくできていれば）大規模化したときに破綻しにくい。
C で書いたシステムを拡張しようとしてC++ を使って失敗し、結局
Java で書く羽目になる。Perl で書いたシステムを格調しようとして
Ruby や PHP を使って失敗し、結局 Java で書く羽目になる。
Java に「成功した」プロダクトはない（なにより“遅い”）。失敗
しなかったプロダクトが存在するだけだ。
997 ：仕様書無しさん：2006/03/28(火) 22:55:54
はぁ？
998 ：仕様書無しさん：2006/03/28(火) 23:16:19
＞Java に「成功した」プロダクトはない（なにより“遅い”）。
ここだけでいいよ
ここだけでいいよ
catならCだろうがJavaだろうが大差ないだろ？
1000とっていい？
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。