先があるのはC++とJavaのどっち？
1 ：ピカチュー：
どっちを勉強した方が得でしょうか？
ご意見を聞かせてください。
ご意見を聞かせてください。
|
|
|
>1
英語
英語
VB
4 ：仕様書無しさん：2005/11/17(木) 01:22:34
先にC言語だな
どっちとか言う香具師は糞。
両方やれっての。
どっちが先があるとか、それこそアホ丸出し。
どっちも先はある。分野が違う。
両方やれっての。
どっちが先があるとか、それこそアホ丸出し。
どっちも先はある。分野が違う。
COBOL
7 ：仕様書無しさん：2005/11/17(木) 01:27:58
PHP
8 ：69式フリーPG ◆hND3Lufios ：2005/11/17(木) 01:38:34
WebPGならJava
それ以外ならC++
それ以外ならC++
9 ：仕様書無しさん：2005/11/17(木) 01:43:42
>>1
お前ピカチューだろ！！
お前ピカチューだろ！！
>>2
英語が出来る人間はプログラムが出来る人間より圧倒的に多いぞ
英語が出来る人間はプログラムが出来る人間より圧倒的に多いぞ
莫迦ほど、こんなｽﾚばっか勃てるな…
もう死ねよ面倒臭ぇ。>>1
もう死ねよ面倒臭ぇ。>>1
英語が出来ても金にならん
英語とC++とJava全部できれば何も問題ないだろ。例えば俺。
まあ、君はそうなんだろうね。
C++がまともに使えるなら、Javaも自動的に使えるはずだが。
Javaは一時の流行。将来は、一部の分野を残して廃れるだろう。
理由は「遅いから」。
携帯の基本操作やｉアプリの、あの遅さを見れば一目瞭然。
一度組めばプラットフォームを替えてもそのまま動くなんて、
エンドユーザーから見れば、知ったこっちゃない。
理由は「遅いから」。
携帯の基本操作やｉアプリの、あの遅さを見れば一目瞭然。
一度組めばプラットフォームを替えてもそのまま動くなんて、
エンドユーザーから見れば、知ったこっちゃない。
Java自体は遅くないと思う。
色々試したけど、C++でCOMをやるのと同等の速度は出てる。
遅いのは、Java厨が遅いコードを書くからだと思う。
連中は、処理の重さとか気にせずにコーディングするから。
色々試したけど、C++でCOMをやるのと同等の速度は出てる。
遅いのは、Java厨が遅いコードを書くからだと思う。
連中は、処理の重さとか気にせずにコーディングするから。
>>20
処理の重い、軽いがソースで一目瞭然なのはC系だろう
処理の重い、軽いがソースで一目瞭然なのはC系だろう
>>21
組み込みでその水準になるのはいつなんだよ
組み込みでその水準になるのはいつなんだよ
24 ：ピカチュー：2005/11/18(金) 22:45:48
みなさんありがとうございます。
１９あたりから建設的な議論になってきました。私もどちらも最終的には
学ぶつもりですが、Cが一通り仕上がった時点で次にどっちをやったほうが
いいか疑問に思ったのでスレ立ててみました。
いろんな会社の中途採用のページを見ると、C/C++を使うところが多いようです。
Javaの求人というのは少ないですね。引き続きお願いします。
１９あたりから建設的な議論になってきました。私もどちらも最終的には
学ぶつもりですが、Cが一通り仕上がった時点で次にどっちをやったほうが
いいか疑問に思ったのでスレ立ててみました。
いろんな会社の中途採用のページを見ると、C/C++を使うところが多いようです。
Javaの求人というのは少ないですね。引き続きお願いします。
Ｊａｖａは一時期ほど話題にならなくなったよね。
26 ：仕様書無しさん：2005/11/18(金) 23:02:27
マシンが高性能になれば Java プログラムも高速に動作するようになるが、
そのマシンで C プログラムを走らせればもっと高速に動作する。
そのマシンで C プログラムを走らせればもっと高速に動作する。
27 ：ガボッシュ ◆iyx/0deoUw ：2005/11/18(金) 23:07:32
引き続きお願いします、って(ry
言いたいこと判るかね？？？？？？？？？？？？？？？？？？？
つ【糸冬了】
言いたいこと判るかね？？？？？？？？？？？？？？？？？？？
つ【糸冬了】
プラットフォームの違いは「ライブラリー」が
吸収できれば何の問題も無い訳だけど
そうは行かないのが、現実か・・
吸収できれば何の問題も無い訳だけど
そうは行かないのが、現実か・・
C/C++自体は速くはないよ。
C/C++で書かれたプログラムが速いのは、微妙に処理を端折っているから。
Javaと同じことをやれば、同じくらい遅くなるか、むしろJavaよりも遅くなる。
C/C++で書かれたプログラムが速いのは、微妙に処理を端折っているから。
Javaと同じことをやれば、同じくらい遅くなるか、むしろJavaよりも遅くなる。
30 ：仕様書無しさん：2005/11/19(土) 00:07:46
>>29
だったらJavaも端折って欲しいもんだな。
だったらJavaも端折って欲しいもんだな。
php最強だろ。
javaは過渡期の技術だったね。
javaは過渡期の技術だったね。
ArrayListでIteratorでアクセスしたり
LinkedListでランダムアクセスしたり（get(i)でのループとか）
無意味にMapを避けたりすると遅くなる。
LinkedListでランダムアクセスしたり（get(i)でのループとか）
無意味にMapを避けたりすると遅くなる。
34 ：仕様書無しさん：2005/11/19(土) 21:34:47
Javaだとラベル gotoですら使うのに気が引ける。
使うけど。
使うけど。
36 ：仕様書無しさん：2005/11/19(土) 21:44:51
そこでPerlですよ。
端折りたいのに端折れないのがJava
すべてを人間に任されてるのがC
すべてを人間に任されてるのがC
>>37
超多重for文で。
超多重for文で。
forが三重超えたらそこで試合終了ですよ
>>39
アホナ設計してるというわけですね。
アホナ設計してるというわけですね。
>>41
俺のせーじゃないやい
俺のせーじゃないやい
>>33 は一見理想的な方式に思えるが、実際には難しい。
ヒントは技術者の教育。
ヒントは技術者の教育。
>>43
つか既にあるソースの改造じゃないの?
つか既にあるソースの改造じゃないの?
>>35
goto文使わないかわりにthrow new Exceptionってやってる奴がいる
goto文使わないかわりにthrow new Exceptionってやってる奴がいる
try-catch-finallyは生成コストが高いから多用するなとあれほど・・・
48 ：仕様書無しさん：2005/11/20(日) 01:02:32
>>8 69式フリーPG ◆hND3Lufios よ
お前はいつもバカ発言をするのだろうな。
JavaがWeb専用言語だと思いこんでいるとしたら
それは大きな勘違いだ。JavaはPHPやPerlなどとは違う言語なのだ。
JavaはプロトコルがHTTP(Web)だけとは限らずに
ネットワーク開発が可能だ。
それに組み込み、車載機器、工場の生産管理にも使える。
すでにJ2MEは携帯電話だけでなく工場の生産管理に応用されている。
ほかに、JavaCardというFericaに似たシステムを持ったカードも存在する。
セキュリティに強いJavaという利点を生かしたFericaのJava版カードだ。
Javaは携帯電話だけでなく火星探査機のコントローラにもすでに使われている。
これでJavaがWeb系限定だと言い切れると思うか？
Write Once, Work Anywhere.という言葉がある。
Javaを知っていればどこでも働けるということだ。今Javaはまさにその影響を受けている。
リアルタイムJavaも確立しつつある、あとはモバイル機器のRAMメモリの消費電力が
軽くなればモバイル機器のメモリ容量が増大し、
組み込みJavaももの凄いｊ速さで浸透してゆくだろう。
さらに燃料電池によってJavaの組み込み機器への浸透はさらに加速するだろう。
お前はいつもバカ発言をするのだろうな。
JavaがWeb専用言語だと思いこんでいるとしたら
それは大きな勘違いだ。JavaはPHPやPerlなどとは違う言語なのだ。
JavaはプロトコルがHTTP(Web)だけとは限らずに
ネットワーク開発が可能だ。
それに組み込み、車載機器、工場の生産管理にも使える。
すでにJ2MEは携帯電話だけでなく工場の生産管理に応用されている。
ほかに、JavaCardというFericaに似たシステムを持ったカードも存在する。
セキュリティに強いJavaという利点を生かしたFericaのJava版カードだ。
Javaは携帯電話だけでなく火星探査機のコントローラにもすでに使われている。
これでJavaがWeb系限定だと言い切れると思うか？
Write Once, Work Anywhere.という言葉がある。
Javaを知っていればどこでも働けるということだ。今Javaはまさにその影響を受けている。
リアルタイムJavaも確立しつつある、あとはモバイル機器のRAMメモリの消費電力が
軽くなればモバイル機器のメモリ容量が増大し、
組み込みJavaももの凄いｊ速さで浸透してゆくだろう。
さらに燃料電池によってJavaの組み込み機器への浸透はさらに加速するだろう。
49 ：仕様書無しさん：2005/11/20(日) 01:06:07
必死の断末魔だな
>>20
> Java自体は遅くないと思う。
> 色々試したけど、C++でCOMをやるのと同等の速度は出てる。
>
> 遅いのは、Java厨が遅いコードを書くからだと思う。
> 連中は、処理の重さとか気にせずにコーディングするから。
どうかな。それはどうみても偏見だろう。
今となっては最適化が進んできたJavaでもCやC++よりも
高速に動くコードを書きやすくなった。
今となっては、JavaよりもＣやC++で、どんな場面でも常に「Javaより高速」を
維持できるコードを書くことが難しくなってくる。
よくJavaではクラスをfinalにすれば高速化するとか
不要になったオブジェクトにnullを代入すれば高速化すると言われた時期もあったは
それは、finalに関しては今では無意味であり、まったくパフォーマンスに好影響を与えない。
オブジェクトにnullを代入すれば高速化するというのも非常にあてにならない。
nullを代入することによって、返ってパフォーマンスに悪影響を与えることもあるからだ。
それからfinalize()メソッドを勝手にオーバライドすることもお勧めしない。
これをいじれば高速化するだろうという誤解をする者がいるが、これも大きな間違いだ。
ガーベッジコレクタの動きを良く知らない者がこのfinalize()の不用意なオーバライドをしたがる。
> Java自体は遅くないと思う。
> 色々試したけど、C++でCOMをやるのと同等の速度は出てる。
>
> 遅いのは、Java厨が遅いコードを書くからだと思う。
> 連中は、処理の重さとか気にせずにコーディングするから。
どうかな。それはどうみても偏見だろう。
今となっては最適化が進んできたJavaでもCやC++よりも
高速に動くコードを書きやすくなった。
今となっては、JavaよりもＣやC++で、どんな場面でも常に「Javaより高速」を
維持できるコードを書くことが難しくなってくる。
よくJavaではクラスをfinalにすれば高速化するとか
不要になったオブジェクトにnullを代入すれば高速化すると言われた時期もあったは
それは、finalに関しては今では無意味であり、まったくパフォーマンスに好影響を与えない。
オブジェクトにnullを代入すれば高速化するというのも非常にあてにならない。
nullを代入することによって、返ってパフォーマンスに悪影響を与えることもあるからだ。
それからfinalize()メソッドを勝手にオーバライドすることもお勧めしない。
これをいじれば高速化するだろうという誤解をする者がいるが、これも大きな間違いだ。
ガーベッジコレクタの動きを良く知らない者がこのfinalize()の不用意なオーバライドをしたがる。
>>19
> Javaは一時の流行。将来は、一部の分野を残して廃れるだろう。
> 理由は「遅いから」。
もうJavaが既に遅いということを問題にしている奴は
組み込み機器業界でもほとんどいない。
メモリ容量を増やすとRAMメモリの消費電力量が異常に高いから
メモリを大量消費するJava開発がうまくいっていないだけであって
RAMメモリの消費電力が激減し、さらに燃料電池が普及すれば
結局JavaはCやC++の代わりの言語として
ソフトウェア業界だけでなくハードウェア業界にも浸透してゆくことができる。
なにせ、C,C++よりもセキュリティに強い言語だからな。
このセキュリティの強みがなければ確かに一時の流行に留まるに
過ぎなかっただろう。だが、Javaを作ったエキスパート達は
Javaを家電製品を制御するために作ることを想定していたため
セュリティに対する意識はかなり強く、Javaで分散やグリッドコンピューティングを
する方法やネットワーキングできる方法をすでに前もって準備していた。
> Javaは一時の流行。将来は、一部の分野を残して廃れるだろう。
> 理由は「遅いから」。
もうJavaが既に遅いということを問題にしている奴は
組み込み機器業界でもほとんどいない。
メモリ容量を増やすとRAMメモリの消費電力量が異常に高いから
メモリを大量消費するJava開発がうまくいっていないだけであって
RAMメモリの消費電力が激減し、さらに燃料電池が普及すれば
結局JavaはCやC++の代わりの言語として
ソフトウェア業界だけでなくハードウェア業界にも浸透してゆくことができる。
なにせ、C,C++よりもセキュリティに強い言語だからな。
このセキュリティの強みがなければ確かに一時の流行に留まるに
過ぎなかっただろう。だが、Javaを作ったエキスパート達は
Javaを家電製品を制御するために作ることを想定していたため
セュリティに対する意識はかなり強く、Javaで分散やグリッドコンピューティングを
する方法やネットワーキングできる方法をすでに前もって準備していた。
> 携帯の基本操作やｉアプリの、あの遅さを見れば一目瞭然。
> 一度組めばプラットフォームを替えてもそのまま動くなんて、
> エンドユーザーから見れば、知ったこっちゃない。
そのエンドユーザとやらが消費能力も少ないくだらないゲームしかできない
若者だったりしては商売にならんな。
Javaで商売するならユーザは金をたっぷり持ってる企業。
くだらないゲームを作っているよりもサーバ系のほうが仕事をしていて誇りを感じることもできるし
学べる事も多い。その反面、携帯電話開発は地位が低く開発環境もメモリが少ない問題から
依然として最悪で学べることも少ない。それがBREWだろうとJavaだろうと。
サーバ系はネットワークのこと、データベースのこと、サーバOS、Linux, Solarisなどの
ことについて理解が深まるので金になるほかにいい勉強と経験になり一石二鳥。
>>22
> >>20
> 処理の重い、軽いがソースで一目瞭然なのはC系だろう
それも今となっては昔の話。
20世紀という旧世代の世界ではJavaは遅いと感じていたこともあったろうが、
現代の21世紀の環境ではCもJavaもどちらも体感速度はもはや変わらない。
> >>20
> 処理の重い、軽いがソースで一目瞭然なのはC系だろう
それも今となっては昔の話。
20世紀という旧世代の世界ではJavaは遅いと感じていたこともあったろうが、
現代の21世紀の環境ではCもJavaもどちらも体感速度はもはや変わらない。
55 ：仕様書無しさん：2005/11/20(日) 01:20:39
>>24
> みなさんありがとうございます。
> １９あたりから建設的な議論になってきました。私もどちらも最終的には
> 学ぶつもりですが、Cが一通り仕上がった時点で次にどっちをやったほうが
> いいか疑問に思ったのでスレ立ててみました。
> いろんな会社の中途採用のページを見ると、C/C++を使うところが多いようです。
> Javaの求人というのは少ないですね。引き続きお願いします。
それは初耳だな。リクナビをちゃんとみているのかな？ どこの求人情報サイトだろうかな？
求人情報をみてもどう見ても検索でヒットするのはC/C++よりも
Java系が圧倒的に多いのだが。
> みなさんありがとうございます。
> １９あたりから建設的な議論になってきました。私もどちらも最終的には
> 学ぶつもりですが、Cが一通り仕上がった時点で次にどっちをやったほうが
> いいか疑問に思ったのでスレ立ててみました。
> いろんな会社の中途採用のページを見ると、C/C++を使うところが多いようです。
> Javaの求人というのは少ないですね。引き続きお願いします。
それは初耳だな。リクナビをちゃんとみているのかな？ どこの求人情報サイトだろうかな？
求人情報をみてもどう見ても検索でヒットするのはC/C++よりも
Java系が圧倒的に多いのだが。
56 ：仕様書無しさん：2005/11/20(日) 01:21:07
さあ盛り上がってきますた
C++が劣勢なのは言うまでも無いがそう必死になられてもなぁ・・・
まぁ最後にC++に止めを刺すのはD言語かな。学者ではなくコンパイラ屋が作る新機軸のOOPだ。
まぁ最後にC++に止めを刺すのはD言語かな。学者ではなくコンパイラ屋が作る新機軸のOOPだ。
58 ：仕様書無しさん：2005/11/20(日) 01:22:10
>>26
> マシンが高性能になれば Java プログラムも高速に動作するようになるが、
> そのマシンで C プログラムを走らせればもっと高速に動作する。
そこでいまどきCを使うならC++を使った方がいいともいえるが、
組み込み機器ではセキュリティの問題上、C/C++言語を使うことは
好ましくないとされている。
それにC/C++でJavaよりも、「常に高速」であることを維持するのは非常に難しい。
> マシンが高性能になれば Java プログラムも高速に動作するようになるが、
> そのマシンで C プログラムを走らせればもっと高速に動作する。
そこでいまどきCを使うならC++を使った方がいいともいえるが、
組み込み機器ではセキュリティの問題上、C/C++言語を使うことは
好ましくないとされている。
それにC/C++でJavaよりも、「常に高速」であることを維持するのは非常に難しい。
60 ：仕様書無しさん：2005/11/20(日) 01:23:43
J厨様降臨あげ
俺はデバッガなしに安全なコード書きたいからC++じゃなくてCを使うな。
クラスが必要なほど構造が複雑なら、そんときはJavaにしてる。
最近はポトペタができて楽チンだぁ
クラスが必要なほど構造が複雑なら、そんときはJavaにしてる。
最近はポトペタができて楽チンだぁ
>>31
> php最強だろ。
>
> javaは過渡期の技術だったね。
あんな名前空間の無いPHP言語のどこが最強なんだ。
C++にもJavaにもあるものがPHPになければ
PHPは最強とはいえん。
PHPは型が曖昧で銀行システムには
あぶなっかしすぎてとても使えたもんじゃない。
それにPHPが組み込み系で使えるというなら見てみたいもんだ。
俺が金融系の客だったら金融システムには絶対使いたくない言語だね。
PHPは汎用性が薄い言語として問題があるってことをよく理解するんだな。
> php最強だろ。
>
> javaは過渡期の技術だったね。
あんな名前空間の無いPHP言語のどこが最強なんだ。
C++にもJavaにもあるものがPHPになければ
PHPは最強とはいえん。
PHPは型が曖昧で銀行システムには
あぶなっかしすぎてとても使えたもんじゃない。
それにPHPが組み込み系で使えるというなら見てみたいもんだ。
俺が金融系の客だったら金融システムには絶対使いたくない言語だね。
PHPは汎用性が薄い言語として問題があるってことをよく理解するんだな。
>>25
> Ｊａｖａは一時期ほど話題にならなくなったよね。
それは今ﾄﾞﾄﾞﾈﾄがそういう感じだ。
というか話題になってる言語なんてある？
今はJavaを使った技術、
Javaと併用して使われる技術が話題になってるのが多いが。
> Ｊａｖａは一時期ほど話題にならなくなったよね。
それは今ﾄﾞﾄﾞﾈﾄがそういう感じだ。
というか話題になってる言語なんてある？
今はJavaを使った技術、
Javaと併用して使われる技術が話題になってるのが多いが。
>>33
> >>29
> 端折れば早いんだろ？なら、
> 端折ってＯＫな部分はＣでつくり、
> 端折ってダメな部分はＪＡＶＡでつくる感じでＦＡだな
>
そのやり方はBREWなどでやろうとしているみたいだが、
そう簡単にはうまくいかない。
複数の言語を組み合わせるとアダプタも決めないと行けない。
これは一つの言語を使って開発するよりもコストと手間と時間がかかる。
大抵は、既存の古いシステムと相互運用するときに複数言語を使うわけだが、
新規に作る、リプレースとなるとわざわざ複数のプログラミング言語を
混在させるということは極力避けるようにすべきだ。
> >>29
> 端折れば早いんだろ？なら、
> 端折ってＯＫな部分はＣでつくり、
> 端折ってダメな部分はＪＡＶＡでつくる感じでＦＡだな
>
そのやり方はBREWなどでやろうとしているみたいだが、
そう簡単にはうまくいかない。
複数の言語を組み合わせるとアダプタも決めないと行けない。
これは一つの言語を使って開発するよりもコストと手間と時間がかかる。
大抵は、既存の古いシステムと相互運用するときに複数言語を使うわけだが、
新規に作る、リプレースとなるとわざわざ複数のプログラミング言語を
混在させるということは極力避けるようにすべきだ。
67 ：仕様書無しさん：2005/11/20(日) 01:32:01
flexとか
>>68
コンピュータの中のカテゴリさ
コンピュータの中のカテゴリさ
70 ：仕様書無しさん：2005/11/20(日) 01:36:45
デスクトップアプリに関しては、あの独特の UI がなあ・・・。
OS ネイティブな UI を直接使わせてくれよ。
SWT があるにはあるが所詮亜流だし。
Swing もたとえば Windows「風」Look&Feel にできるけど、なんか
パチモン臭くて好きになれん。
OS ネイティブな UI を直接使わせてくれよ。
SWT があるにはあるが所詮亜流だし。
Swing もたとえば Windows「風」Look&Feel にできるけど、なんか
パチモン臭くて好きになれん。
NetBeansってSwingでしょ？俺は気にならないけど･･･
>>71
ばーか、Open Laszloが本命だよ。普及に失敗って言ってるけどRAI市場はWeb市場の1/4を占めてたぞ。
ばーか、Open Laszloが本命だよ。普及に失敗って言ってるけどRAI市場はWeb市場の1/4を占めてたぞ。
74 ：仕様書無しさん：2005/11/20(日) 01:41:20
サーバサイドと携帯ゲームしか使われてないじゃん
>>70
> デスクトップアプリに関しては、あの独特の UI がなあ・・・。
おまいはJavaでWindowsXPのLunaスキンが使えることを知らんのか。
Mustangを使ってみろ。かなり進化してるからな。
まったく、>>70のような
未だに頭の中がJDK1.2時代の思考で止まってる奴がまだいるもんだな。やれやれ。
Java SE 6 Mustang じゃじゃ馬馴らし
http://www.javainthebox.net/laboratory/JavaSE6/
> デスクトップアプリに関しては、あの独特の UI がなあ・・・。
おまいはJavaでWindowsXPのLunaスキンが使えることを知らんのか。
Mustangを使ってみろ。かなり進化してるからな。
まったく、>>70のような
未だに頭の中がJDK1.2時代の思考で止まってる奴がまだいるもんだな。やれやれ。
Java SE 6 Mustang じゃじゃ馬馴らし
http://www.javainthebox.net/laboratory/JavaSE6/
>>76
だからJavaよりどの言語が話題になっているのかって聞いているんだ
だからJavaよりどの言語が話題になっているのかって聞いているんだ
？？？話題になっている言語はないって言ったからあるよって答えたんじゃん。
75=78はうざいから他所行ってくれ。
81 ：仕様書無しさん：2005/11/20(日) 01:51:35
うるせーばか
圧倒的優位性が真の意味で理解できていないから、そんなに必死になるんだよ。
GoogleだってSUNを快く子分にしてくれたじゃないか。
GoogleだってSUNを快く子分にしてくれたじゃないか。
そこで、GCJでつよ。
最近、結構早くなってきたと聞くが...
最近、結構早くなってきたと聞くが...
84 ：仕様書無しさん：2005/11/20(日) 01:57:54
>>77
いや、その Luna スキンがいかにもパチモンだと言ってるわけだが・・・。
ちなみに J2SE5 の時点のやつね。
しかし、Windows 95 が出て 10 年以上たってやっと Java はタスクトレイアイコンに
対応ですか（ｗ
いや、その Luna スキンがいかにもパチモンだと言ってるわけだが・・・。
ちなみに J2SE5 の時点のやつね。
しかし、Windows 95 が出て 10 年以上たってやっと Java はタスクトレイアイコンに
対応ですか（ｗ
85 ：仕様書無しさん：2005/11/20(日) 01:58:56
他のOSの都合ってもんがあるからね。最大公約数言語ってことさ。
>>85
RIAの間違いに決まってるだろ。心にダムを持てとあんちゃんが言ってた。
RIAの間違いに決まってるだろ。心にダムを持てとあんちゃんが言ってた。
>>84
タスクトレイが一般化していないと意味がないだろ。
Linuxにもまったく同じ仕様のものがあれば
即座に準備できるんだろうけど
そういうことはJavaCommunityProcessで議論しながら作られる。
別に標準言語仕様に含まれなくても外部のものが
すでに似たようなものを作ってはいると思うが。
タスクトレイが一般化していないと意味がないだろ。
Linuxにもまったく同じ仕様のものがあれば
即座に準備できるんだろうけど
そういうことはJavaCommunityProcessで議論しながら作られる。
別に標準言語仕様に含まれなくても外部のものが
すでに似たようなものを作ってはいると思うが。
JavaがCやC++と変わらない速さを出せるという調査、比較をしてるサイトってあります?
91 ：仕様書無しさん：2005/11/20(日) 02:04:05
>>89
うん。だから、Windows Vista でも UI が大幅に変更されるみたいだけど、
そういう最新機能を積極的に使ったデスクトップアプリを作ろうとすれば、
結局選択肢は C/C++ （もしくは .NET 系言語）しかなくなる。
うん。だから、Windows Vista でも UI が大幅に変更されるみたいだけど、
そういう最新機能を積極的に使ったデスクトップアプリを作ろうとすれば、
結局選択肢は C/C++ （もしくは .NET 系言語）しかなくなる。
>>88
微妙だな。
MacrimediaがリッチクライアントでJavaを越えるには
サーバ絡みも洗練させないといけないな。
ただGUIだけが優れているだけではリッチクライアントは
うまく実現できまいて。
Javaなどの他の言語との連携を考えているんだろうけど。
JavaにはJavaWebStartが、
他の言語ではCurl, Ajax, ドトネトのノータッチデプロイメントが。
そこでflexで対抗するのはまだまだってところだね。
Flexは見た目は綺麗だが技術的にはどれだけ優れているか
微妙だな。
MacrimediaがリッチクライアントでJavaを越えるには
サーバ絡みも洗練させないといけないな。
ただGUIだけが優れているだけではリッチクライアントは
うまく実現できまいて。
Javaなどの他の言語との連携を考えているんだろうけど。
JavaにはJavaWebStartが、
他の言語ではCurl, Ajax, ドトネトのノータッチデプロイメントが。
そこでflexで対抗するのはまだまだってところだね。
Flexは見た目は綺麗だが技術的にはどれだけ優れているか
>>90
体感速度の意味わかってる？
誤差の範囲内になったっていうこと。
それからJavaは同じコードでもVMやバイトコードをコンパイルした
コンパイラのバージョンによって随分と速さが異なる。
そこをよく見るといい。
体感速度の意味わかってる？
誤差の範囲内になったっていうこと。
それからJavaは同じコードでもVMやバイトコードをコンパイルした
コンパイラのバージョンによって随分と速さが異なる。
そこをよく見るといい。
96 ：仕様書無しさん：2005/11/20(日) 02:09:02
>>83
GCJはJavaの特性を破壊するルールを適用できるから
お勧めしない。
平気でArrayIndexOutPfBoundsExceptionを無視したり
パフォーマンスのためとはいえ配列のバッファオーバーフローを
許容するプログラミングを許すことは危険だ。
GCJはJavaの特性を破壊するルールを適用できるから
お勧めしない。
平気でArrayIndexOutPfBoundsExceptionを無視したり
パフォーマンスのためとはいえ配列のバッファオーバーフローを
許容するプログラミングを許すことは危険だ。
100 ：仕様書無しさん：2005/11/20(日) 02:14:02
>>97
> >>92
> WebGUI市場でJavaじゃFlashには勝てんよ。
> 普及度があまりにも違いすぎる。
そのWebってのが経済力も消費力も無い個人のオナニー趣味で
普及しているクライアントサイド限定ならな。
だが経済力のある企業で普及しているサーバサイドとなると
Javaのほうが圧倒的強さを誇る。
MacromediaのColdFusionなんてろくに普及してない。
クライアントサイドではドトネト、Flashだが
結局サーバではJava, PHP, Perl,
という棲み分けになる。
> >>92
> WebGUI市場でJavaじゃFlashには勝てんよ。
> 普及度があまりにも違いすぎる。
そのWebってのが経済力も消費力も無い個人のオナニー趣味で
普及しているクライアントサイド限定ならな。
だが経済力のある企業で普及しているサーバサイドとなると
Javaのほうが圧倒的強さを誇る。
MacromediaのColdFusionなんてろくに普及してない。
クライアントサイドではドトネト、Flashだが
結局サーバではJava, PHP, Perl,
という棲み分けになる。
101 ：仕様書無しさん：2005/11/20(日) 02:14:45
>>93
結局、Java は Run anywhere の恩恵がある一方、その裏返しとしていろいろな
デスクトップ環境の最大公約数的な機能しか使えないという弱点を構造的に
持っているんだよな。
MS みたいなところが最新の OS の機能を最大限活用したアプリを次々繰り出してくる。
それなのになんでおたくのアプリはタスクトレイに格納することすらできないの？と
聞かれて、いや Java ですから・・・と答えたところで一般のユーザーに
とってはそんなプログラマの事情なんて知ったことじゃない。
今は Windows の UI に KDE や Gnome が追随しているような感じだけど、
もしこれらが全く別々の道を歩むようになったら、Java はどれに
ついて行くのだろう。Motif かなｗ
結局、Java は Run anywhere の恩恵がある一方、その裏返しとしていろいろな
デスクトップ環境の最大公約数的な機能しか使えないという弱点を構造的に
持っているんだよな。
MS みたいなところが最新の OS の機能を最大限活用したアプリを次々繰り出してくる。
それなのになんでおたくのアプリはタスクトレイに格納することすらできないの？と
聞かれて、いや Java ですから・・・と答えたところで一般のユーザーに
とってはそんなプログラマの事情なんて知ったことじゃない。
今は Windows の UI に KDE や Gnome が追随しているような感じだけど、
もしこれらが全く別々の道を歩むようになったら、Java はどれに
ついて行くのだろう。Motif かなｗ
>>95
体感速度が誤差の許容範囲になったというだけで、Cより早いという結果はやっぱどこにもないんですか…。
Javaなら誰でも書けるからJavaにして外注に投げたかったけど、遅いんじゃやっぱCなのか…。
体感速度が誤差の許容範囲になったというだけで、Cより早いという結果はやっぱどこにもないんですか…。
Javaなら誰でも書けるからJavaにして外注に投げたかったけど、遅いんじゃやっぱCなのか…。
>>47
> try-catch-finallyは生成コストが高いから多用するなとあれほど・・・
携帯電話開発ではな。
だがサーバやデスクトップではさほど変わりない。
昔はループ文内でtry-catchを書くことは
パフォーマンスを低下させる原因として
やるげきではないとされていたが、
それは今では都市伝説(Myth)となってしまった。
JVM、Javaコンパイラの進化により
ループ内でtry-catchを書いてもパフォーマンス上は
まったく変化が無くなった。
JavaOne Tpkyo 2005でとあるセッションで見たことだ。
セッションタイトルにMyth(都市伝説)という言葉が含まれているセッションだ。
> try-catch-finallyは生成コストが高いから多用するなとあれほど・・・
携帯電話開発ではな。
だがサーバやデスクトップではさほど変わりない。
昔はループ文内でtry-catchを書くことは
パフォーマンスを低下させる原因として
やるげきではないとされていたが、
それは今では都市伝説(Myth)となってしまった。
JVM、Javaコンパイラの進化により
ループ内でtry-catchを書いてもパフォーマンス上は
まったく変化が無くなった。
JavaOne Tpkyo 2005でとあるセッションで見たことだ。
セッションタイトルにMyth(都市伝説)という言葉が含まれているセッションだ。
Javaは飲んでも飲まれるな。
Javaのおいしさは分かるが危険な子がひとり混じってるな。
Javaのおいしさは分かるが危険な子がひとり混じってるな。
Javaギークさんに聞きたいんだけど
Javaの通信ってkqueueとかepollとか上手く隠して共通化する予定ない？
Javaの通信ってkqueueとかepollとか上手く隠して共通化する予定ない？
>>101
> >>93
> 結局、Java は Run anywhere の恩恵がある一方、その裏返しとしていろいろな
> デスクトップ環境の最大公約数的な機能しか使えないという弱点を構造的に
> 持っているんだよな。
それはM$が次々とOSに独自仕様を追加してゆくから(ry
InternetExplorerもそれでNetscapeがやられた。
その弱点はタスクトレイに関しては問題にならない。
というかそういうのを弱点とは言わない。それはどの言語でやっても
結果は同じだから。M$や他のＯＳメーカーがもの凄い速さで独自機能を追加したら
どうにもならない。その独自機能が『デファクト標準』であるかどうかも即座にはわかりづらい。
今それで問題になっているのは組み込みのほう。
こっちのほうが痛い。ドコモが独自のAPI作ったりCDCやCLDCやらで(ry
大容量RAMメモリの消費電力が少なければこんなことにはならないのだが。
> >>93
> 結局、Java は Run anywhere の恩恵がある一方、その裏返しとしていろいろな
> デスクトップ環境の最大公約数的な機能しか使えないという弱点を構造的に
> 持っているんだよな。
それはM$が次々とOSに独自仕様を追加してゆくから(ry
InternetExplorerもそれでNetscapeがやられた。
その弱点はタスクトレイに関しては問題にならない。
というかそういうのを弱点とは言わない。それはどの言語でやっても
結果は同じだから。M$や他のＯＳメーカーがもの凄い速さで独自機能を追加したら
どうにもならない。その独自機能が『デファクト標準』であるかどうかも即座にはわかりづらい。
今それで問題になっているのは組み込みのほう。
こっちのほうが痛い。ドコモが独自のAPI作ったりCDCやCLDCやらで(ry
大容量RAMメモリの消費電力が少なければこんなことにはならないのだが。
JavaServletがレンタル鯖で普及しないのは
JVM内のリソース監視ができないってのが大きな理由らしいけど
そういうのはいつ改善されるの？
JVM内のリソース監視ができないってのが大きな理由らしいけど
そういうのはいつ改善されるの？
Write Once, Run Anywhereの恩恵は開発者がCPUなどハードウェアやコアの部分で受ける部分だ。
タスクトレイなんてハードウェアからあまりにも遠くにかけ離れてそんなところに
Write Once, Run Anywhereを求めることに拘るのはどうかと思うが。
組み込み系のほにできるかぎりWrite Once, Run Anywhereを現実に近づけるほうが大事。
それから、Write Once, Run Anywhereは、そうなると開発しやすいというだけであって、徹底的に
Write Once, Run Anywhereにならないと困るということは少ない。
> MS みたいなところが最新の OS の機能を最大限活用したアプリを次々繰り出してくる。
> それなのになんでおたくのアプリはタスクトレイに格納することすらできないの？と
> 聞かれて、いや Java ですから・・・と答えたところで一般のユーザーに
> とってはそんなプログラマの事情なんて知ったことじゃない。
そういうものはJava標準言語仕様で無理して求める必要はないし
後から追加で実装することもできる。
第一、「物理層」からあまりにも遠くかけ離れた位置にあるものだ。
Javaで作れないなら他の言語で作ればいいことだけだ。
そこで
> それなのになんでおたくのアプリはタスクトレイに格納することすらできないの？と
なんて発言をすることは愚問としか言いようが無い。くだらない発言と見なされるだけだ。
タスクトレイくらい簡単に実装できる。
Javaでないと作れないものではない。
110 ：仕様書無しさん：2005/11/20(日) 02:31:25
>>107
なんか、すべての OS、プラットフォームはみな共通の機能を持つべきだ、
みたいな考えが見え隠れしますな。
しかしプラットフォームのメーカーの立場にしてみれば、他のプラットフォームと
いかに違う機能を付けて差別化するかという点も重要なわけで。
なんか、すべての OS、プラットフォームはみな共通の機能を持つべきだ、
みたいな考えが見え隠れしますな。
しかしプラットフォームのメーカーの立場にしてみれば、他のプラットフォームと
いかに違う機能を付けて差別化するかという点も重要なわけで。
>>108
メモリだろ。
っていうかレンタル鯖なんてイラネだろ。
自前でサーバくらい用意できるスキルくらい身に着けろ。
Javaに詳しくなるんだったらLinuxでルータやファイアウォール
作って自宅サーバ構築くらいできないと駄目だ。
メモリだろ。
っていうかレンタル鯖なんてイラネだろ。
自前でサーバくらい用意できるスキルくらい身に着けろ。
Javaに詳しくなるんだったらLinuxでルータやファイアウォール
作って自宅サーバ構築くらいできないと駄目だ。
メモリ？それよりCPUだろ
スキルってかコストの問題だろ。
月1000円でWebページが維持できるんだ
わざわざ無駄な投資する必要は無い
月1000円でWebページが維持できるんだ
わざわざ無駄な投資する必要は無い
>>110
> >>107
> なんか、すべての OS、プラットフォームはみな共通の機能を持つべきだ、
> みたいな考えが見え隠れしますな。
それはおまいの思いこみ激しすぎ。
Javaの目的は組み込み機器やセキュリティ強化と、
ソフトを極力長く使えるようにすることであって
タスクトレイごときでブーブー文句垂れる奴をいちいち相手にする価値は無い。
そんなところにフォーカスを絞ることは次元が低いし
タスクトレイを必要としない人間にとっては価値がない話題だ。
本質は、GUIよりもシステムだ。GUIの見た目、表面上の部分が
いくらしっかりしていてもシステムがしっかりしていなければ駄目だ。
高層ビルを立てるときに、部屋の間取り、机やテーブルの配置を先に
考えるバカが何処にいる？
タスクトレイの事ばかりに拘ることは、高層ビルを建設する前に、
部屋の間取り、机やテーブルの配置のことばかり考えているバカと一緒だ。
> >>107
> なんか、すべての OS、プラットフォームはみな共通の機能を持つべきだ、
> みたいな考えが見え隠れしますな。
それはおまいの思いこみ激しすぎ。
Javaの目的は組み込み機器やセキュリティ強化と、
ソフトを極力長く使えるようにすることであって
タスクトレイごときでブーブー文句垂れる奴をいちいち相手にする価値は無い。
そんなところにフォーカスを絞ることは次元が低いし
タスクトレイを必要としない人間にとっては価値がない話題だ。
本質は、GUIよりもシステムだ。GUIの見た目、表面上の部分が
いくらしっかりしていてもシステムがしっかりしていなければ駄目だ。
高層ビルを立てるときに、部屋の間取り、机やテーブルの配置を先に
考えるバカが何処にいる？
タスクトレイの事ばかりに拘ることは、高層ビルを建設する前に、
部屋の間取り、机やテーブルの配置のことばかり考えているバカと一緒だ。
便利だからと同じビルやプレハブ押し付けられてもうざいだけだよ。
GUIも本質のひとつだ。
GUIも本質のひとつだ。
116 ：仕様書無しさん：2005/11/20(日) 02:41:23
>>112
速度は今ではとくに問題ない。大した問題ではないからだ。
CPUというかCPUリソースの問題。
メモリの問題も重要。JavaはPHPとくらべメモリ消費量が馬鹿ならない。
PHPはがPerlで作ったものよりもメモリ消費量が驚くほど少ないのが売り。
複数人のユーザに使わせたらあっというまにリソースが無くなる。
だからASPもASP.NETも個人ではなかなか流行らない。
>>113
Webしかやらんやつには自宅サーバは高すぎるだろうな。
だが俺みたいに、Subversionでバージョン管理、
データベース弄り、でっかいファイルを出し入れするFTPサーバ、
メールサーバ、DNSサーバ、ファイルサーバSamba、
ルータとしても兼ねて使う場合は
全然安いもんだ。
レンタルサーバだと容量制限が厳しいし
ブログやるにしてもカスタマイズしづらい。
それにsendmailが使えないところも多い。
データベースが使えても各カラムのデータ型サイズに
制限があったりバイナリを補完できないとか容量制限が厳しすぎるとか
細かいカスタマイズができないとかでやりづらい。
速度は今ではとくに問題ない。大した問題ではないからだ。
CPUというかCPUリソースの問題。
メモリの問題も重要。JavaはPHPとくらべメモリ消費量が馬鹿ならない。
PHPはがPerlで作ったものよりもメモリ消費量が驚くほど少ないのが売り。
複数人のユーザに使わせたらあっというまにリソースが無くなる。
だからASPもASP.NETも個人ではなかなか流行らない。
>>113
Webしかやらんやつには自宅サーバは高すぎるだろうな。
だが俺みたいに、Subversionでバージョン管理、
データベース弄り、でっかいファイルを出し入れするFTPサーバ、
メールサーバ、DNSサーバ、ファイルサーバSamba、
ルータとしても兼ねて使う場合は
全然安いもんだ。
レンタルサーバだと容量制限が厳しいし
ブログやるにしてもカスタマイズしづらい。
それにsendmailが使えないところも多い。
データベースが使えても各カラムのデータ型サイズに
制限があったりバイナリを補完できないとか容量制限が厳しすぎるとか
細かいカスタマイズができないとかでやりづらい。
117のような人間よりレンタル鯖使ってWebだけって方が多いと思うんだけど。
家でmail、DNS立ててるやつなんてあまりいないよ。
でもそういうことやる時間が取れるというのはうらやましい…。
家でmail、DNS立ててるやつなんてあまりいないよ。
でもそういうことやる時間が取れるというのはうらやましい…。
JSP+ELとかVelocityとかでWebやりたい。
これらはなんつーか、Perlの香りがしていいんだな。
これらはなんつーか、Perlの香りがしていいんだな。
121 ：仕様書無しさん：2005/11/20(日) 02:50:53
携帯もiアプリだけじゃなく全部javaにすればいいのに
122 ：仕様書無しさん：2005/11/20(日) 02:52:54
＞ちなみに、メモリ使用量は、データ量が3万個の場合は、C言語版が656kバイト、
＞JVMクライアント用が9212kバイト、JVMサーバ用が11284kバイトだった。
＞JavaがC言語版よりも10倍以上メモリを使うのはあいかわらずの傾向だが、
＞JVMのサーバ用とクライアント用のメモリ消費量の違いは、実行速度の差を
＞考えれば許してあげられる程度の差だと思う。
処理速度が遅いのは待てばいいだけだが、確保できるメモリが 1 バイトでも
足りない場合はプログラムは正常に動きすらしないですぞ・・・。
＞JVMクライアント用が9212kバイト、JVMサーバ用が11284kバイトだった。
＞JavaがC言語版よりも10倍以上メモリを使うのはあいかわらずの傾向だが、
＞JVMのサーバ用とクライアント用のメモリ消費量の違いは、実行速度の差を
＞考えれば許してあげられる程度の差だと思う。
処理速度が遅いのは待てばいいだけだが、確保できるメモリが 1 バイトでも
足りない場合はプログラムは正常に動きすらしないですぞ・・・。
>>94を見る限りではJavaもまだまだだな。
かといって速度で天下とるJavaてのはあんま想像できないし面白みも無い。
かといって速度で天下とるJavaてのはあんま想像できないし面白みも無い。
124 ：仕様書無しさん：2005/11/20(日) 02:54:55
メモリ管理のスピードは今では
C++よりJavaのほうが早くなってしまっている！
やはりIBMの研究者恐るべし！
IBM dW:Javaの理論と実践:パフォーマンスに関する都市伝説を再検証する - Japan
http://www-06.ibm.com/jp/developerworks/java/051104/j_j-jtp09275.shtml
"ちょっとしたクイズがあります。生のアロケーション・パフォーマンスとして速いのは、
Java言語でしょうか、それともC/C++でしょうか。この答えに、多くの人は驚くでしょう。
最近のJVMのアロケーションは、最高パフォーマンスのmalloc実装よりも、ずっと高速
なのです。
HotSpot 1.4.2以降でのnew Object() 用の一般的なコード・パスは、約10マシン命令
（Sun提供のデータより。参考文献を参照）ですが、Cで最高パフォーマンスのmalloc
実装では、1つのコールあたり平均60から100の命令が必要です（Detlefsなどのデータ
による。参考文献を参照）。しかもアロケーションのパフォーマンスは、全体的なパフォ
ーマンスのコンポーネントとして小さなものではありません。
ベンチマークによると、PerlやGhostscriptなど実世界でのCプログラムやC++プログラム
では、実行時間全体の20％から30%がmallocやfreeに費やされています。
これは、健全なJavaアプリケーションでのアロケーションやガーベジ・コレクションの
オーバーヘッドよりも、はるかに大きな数字です。"
↑↑↑↑↑↑↑↑↑これが大半のC/C++プログラマの現実なんだよね・・・。
C++よりJavaのほうが早くなってしまっている！
やはりIBMの研究者恐るべし！
IBM dW:Javaの理論と実践:パフォーマンスに関する都市伝説を再検証する - Japan
http://www-06.ibm.com/jp/developerworks/java/051104/j_j-jtp09275.shtml
"ちょっとしたクイズがあります。生のアロケーション・パフォーマンスとして速いのは、
Java言語でしょうか、それともC/C++でしょうか。この答えに、多くの人は驚くでしょう。
最近のJVMのアロケーションは、最高パフォーマンスのmalloc実装よりも、ずっと高速
なのです。
HotSpot 1.4.2以降でのnew Object() 用の一般的なコード・パスは、約10マシン命令
（Sun提供のデータより。参考文献を参照）ですが、Cで最高パフォーマンスのmalloc
実装では、1つのコールあたり平均60から100の命令が必要です（Detlefsなどのデータ
による。参考文献を参照）。しかもアロケーションのパフォーマンスは、全体的なパフォ
ーマンスのコンポーネントとして小さなものではありません。
ベンチマークによると、PerlやGhostscriptなど実世界でのCプログラムやC++プログラム
では、実行時間全体の20％から30%がmallocやfreeに費やされています。
これは、健全なJavaアプリケーションでのアロケーションやガーベジ・コレクションの
オーバーヘッドよりも、はるかに大きな数字です。"
↑↑↑↑↑↑↑↑↑これが大半のC/C++プログラマの現実なんだよね・・・。
Mustangのスクリプト対応はいいな。
俺は常々Rhinoを設定ファイル代わりに使いたいと思ってたんだ。
同じ発想の奴が提案したに違いない。
俺は常々Rhinoを設定ファイル代わりに使いたいと思ってたんだ。
同じ発想の奴が提案したに違いない。
>>118
JavaによるWebアプリ開発は個人ではPHPほどそんなに普及していないよ。
企業では圧倒的に普及しているけど。
Javaは個人のおもちゃやオナニーのために作られた言語じゃないからね。
初めてJava Appletが登場したときはFlashのようなおもちゃ(といっちゃ悪いかもしれないが)
を作るための言語だと思いこんでいる人がかなりいたようだ。
だが、実際にはJavaというのは家電製品を制御するために生まれた言語であり
ネットワークとの親和性が高く、拡張性汎用性メンテナンス性も高く
セキュリティに強く、Javaで作ったアプリは10年経っても使い続ける可能性が強い言語なのだ。
JavaによるWebアプリ開発は個人ではPHPほどそんなに普及していないよ。
企業では圧倒的に普及しているけど。
Javaは個人のおもちゃやオナニーのために作られた言語じゃないからね。
初めてJava Appletが登場したときはFlashのようなおもちゃ(といっちゃ悪いかもしれないが)
を作るための言語だと思いこんでいる人がかなりいたようだ。
だが、実際にはJavaというのは家電製品を制御するために生まれた言語であり
ネットワークとの親和性が高く、拡張性汎用性メンテナンス性も高く
セキュリティに強く、Javaで作ったアプリは10年経っても使い続ける可能性が強い言語なのだ。
>>126
とりあえずPHPもJavaScriptも使えるのでPHP厨にはうってつけかも。
ほかにもGroovyなどの言語にも対応する予定なんだとさ。
そのうちCurlやPerl, Ruby, ActionScriptなど言語にも対応するのかな
とりあえずPHPもJavaScriptも使えるのでPHP厨にはうってつけかも。
ほかにもGroovyなどの言語にも対応する予定なんだとさ。
そのうちCurlやPerl, Ruby, ActionScriptなど言語にも対応するのかな
>>124
じゃあそのJavaVMは何を使って実装してるの？
じゃあそのJavaVMは何を使って実装してるの？
130 ：仕様書無しさん：2005/11/20(日) 03:03:28
>>118
大学の研究室でサーバ管理任されると
そういうことが簡単にできてしまう。
まずは自作ＰＣ経験がある奴でないとサーバ構築はやりにくい。
それからLinuxのインストールくらいはできないと当然駄目。
Javaを使いこなせる香具師はこれくらいできて当たり前なのさ。
大学の研究室でサーバ管理任されると
そういうことが簡単にできてしまう。
まずは自作ＰＣ経験がある奴でないとサーバ構築はやりにくい。
それからLinuxのインストールくらいはできないと当然駄目。
Javaを使いこなせる香具師はこれくらいできて当たり前なのさ。
>>129
C/C++が要らないとはだれも言っていないんだが。
開発効率の問題を言っているだけなんだけど。
Javaで済むところをC/C++でやっても意味が無いと言うこと。
その逆も然り。
それをどうやって見分けるかの基準としてIBMのdeveloper worksも
参考になるよってこと。
今言えることは、C++開発は昔ほど人気がないということ。
デスクトップ開発では無理してJavaを選ぶ必要はないが、
かといってそこで無理してC++を選ぶ必要も徐々になくなりつつある。
デスクトップではＣ＃が浸透しつつある。
そのうちD言語も普及するかもしれないね。
C/C++が要らないとはだれも言っていないんだが。
開発効率の問題を言っているだけなんだけど。
Javaで済むところをC/C++でやっても意味が無いと言うこと。
その逆も然り。
それをどうやって見分けるかの基準としてIBMのdeveloper worksも
参考になるよってこと。
今言えることは、C++開発は昔ほど人気がないということ。
デスクトップ開発では無理してJavaを選ぶ必要はないが、
かといってそこで無理してC++を選ぶ必要も徐々になくなりつつある。
デスクトップではＣ＃が浸透しつつある。
そのうちD言語も普及するかもしれないね。
133 ：仕様書無しさん：2005/11/20(日) 03:07:05
134 ：仕様書無しさん：2005/11/20(日) 03:07:54
で、ハードウェアではまだまだC/C++を使う場面があるということも付け加えておこう。
少なくとも、C++が万能で最強だとは限らないということだけは注意しなければならない。
少なくとも、C++が万能で最強だとは限らないということだけは注意しなければならない。
Flashがおもちゃって言ってる時点でスケーラビリティに弱いな
鯖系を支えてるのがWebなら、Webを支えてるのは広告だぜ
鯖系を支えてるのがWebなら、Webを支えてるのは広告だぜ
>>125
今の大学生はそうなんですね…。今度学生来たら面接のときにでも聞いてみよ。
今の大学生はそうなんですね…。今度学生来たら面接のときにでも聞いてみよ。
>>133
はて本当に無意味かな？
どこでfree()やdeleteを使うか考えるのも大変なコストだ。
メモリを解放するタイミングを間違えると
Javaよりもパフォーマンスが落ちる。
それに加え、喩えどんなにC++プログラマとしての腕が上がっても
手動によるパフォーマンス改善は限度ってものがある。
Javaではjava.lang.ref.SoftReferenceによってパフォーマンスを
改善することができる。こいつは凄い。こいつを上手に使えば
nullを代入してからSystem.gc()を実行するという馬鹿なことをしなくて済むし、
ソースコードは綺麗になる。しかもSystem.gc()を無闇に使うよりも
パフォーマンスを上げやすい。
言いたいことは、手動で細かくメモリ管理しないといけないところが減って開発効率が
上がったと言うこと。ある程度自動化するということは結構重要なことさ。
はて本当に無意味かな？
どこでfree()やdeleteを使うか考えるのも大変なコストだ。
メモリを解放するタイミングを間違えると
Javaよりもパフォーマンスが落ちる。
それに加え、喩えどんなにC++プログラマとしての腕が上がっても
手動によるパフォーマンス改善は限度ってものがある。
Javaではjava.lang.ref.SoftReferenceによってパフォーマンスを
改善することができる。こいつは凄い。こいつを上手に使えば
nullを代入してからSystem.gc()を実行するという馬鹿なことをしなくて済むし、
ソースコードは綺麗になる。しかもSystem.gc()を無闇に使うよりも
パフォーマンスを上げやすい。
言いたいことは、手動で細かくメモリ管理しないといけないところが減って開発効率が
上がったと言うこと。ある程度自動化するということは結構重要なことさ。
138 ：仕様書無しさん：2005/11/20(日) 03:15:58
>>132
C# って本当に浸透しつつあるのかな・・・。
某ライターは、C# に昔は期待してたけど、雑誌の記事依頼が
なぜかさっぱり来ないと嘆いてるみたいだけど・・・。
ちなみに、こんなの見つけた。
C++: .NET Framework プログラミング最良の言語
http://www.microsoft.com/japan/msdn/vs05/visualc/VS05Cplus.asp
C# って本当に浸透しつつあるのかな・・・。
某ライターは、C# に昔は期待してたけど、雑誌の記事依頼が
なぜかさっぱり来ないと嘆いてるみたいだけど・・・。
ちなみに、こんなの見つけた。
C++: .NET Framework プログラミング最良の言語
http://www.microsoft.com/japan/msdn/vs05/visualc/VS05Cplus.asp
139 ：仕様書無しさん：2005/11/20(日) 03:18:53
>>137
だから、Java のメモリ管理アルゴリズムがそんなに優秀なら、C/C++ にもそれと
同じ仕組みを実装しちゃえばいいわけで。
たとえば C++/CLI （のメモリ管理が実際に優秀かは知らないけど）みたいな
形でもいいし。
だから、Java のメモリ管理アルゴリズムがそんなに優秀なら、C/C++ にもそれと
同じ仕組みを実装しちゃえばいいわけで。
たとえば C++/CLI （のメモリ管理が実際に優秀かは知らないけど）みたいな
形でもいいし。
140 ：仕様書無しさん：2005/11/20(日) 03:19:04
C++なら、クラスをヒープにもスタックにもとれるし、静的にも取れる。
なんでもかんでもどんな単純なクラスでもヒープにとるしかないJavaと単純に比較されてもなー
なんでもかんでもどんな単純なクラスでもヒープにとるしかないJavaと単純に比較されてもなー
本当にアホだなおまえら。
こんな議論自体無意味だろ？
生き残った方を使うし、どっちも今はあるが、先はわからん。
だがとりあえず、どっちも飯の種になる。
だいたい、C++とJavaじゃ、両方使えて当たり前じゃねーか。
こんな議論自体無意味だろ？
生き残った方を使うし、どっちも今はあるが、先はわからん。
だがとりあえず、どっちも飯の種になる。
だいたい、C++とJavaじゃ、両方使えて当たり前じゃねーか。
Javaの処理速度はJavaVMに依存する
そのJavaVMを作っているのはC/C++だ
だとしたらC/C++で同じ速度は出せるのではないか？
そのJavaVMを作っているのはC/C++だ
だとしたらC/C++で同じ速度は出せるのではないか？
言語は使えて当たり前だろうが周辺も習得するとなると量的に膨大
どちらも習得するというわけにはいかない
どちらも習得するというわけにはいかない
まぁ結局は141のように両方使えて当たり前、両方使えりゃ困ることはないんだから、もう寝よう。
ソフトウェア開発技術者まで取っておきながらCのコンパイル環境の構築すらできない奴ならみたことある。
あんなんでもVSならインスコできるんだろうな。
あんなんでもVSならインスコできるんだろうな。
>>136
> >>125
> 今の大学生はそうなんですね…。今度学生来たら面接のときにでも聞いてみよ。
サーバ管理は一人の人間がやるのでできる奴はその中でも実は少なかったりする。
大学院生ならサーバ管理している可能性は高い。
それから、最近の学生はレベルが下がっているのでどうも怪しい、とだけ言っておこう。
毎年来る卒論生の能力から明らかにそれがわかる。
面接では限られた時間しか無いので全てを聞くことはできないかもしれないが、
できるやつはとことんできる。できるやつとできない奴との差は異常に激しい、とも言っておこう。
できない奴は、代わりに数学や物理、数値計算などの授業で教わった内容に詳しい
傾向にある、とも言っておこう。
それから、昔はPerlを使いこなすだけでもUNIXのコマンドchmodなどを理解する必要があったけど
(おれは大学にインストールされていたSolaris + Perlで公開できるウェブページから
Linuxに対する興味を広げた)
今じゃその必要もなく、レンタルサーバで簡単にできるし、PHPというPerlより簡単な言語も
出てきてしまったからな。
> >>125
> 今の大学生はそうなんですね…。今度学生来たら面接のときにでも聞いてみよ。
サーバ管理は一人の人間がやるのでできる奴はその中でも実は少なかったりする。
大学院生ならサーバ管理している可能性は高い。
それから、最近の学生はレベルが下がっているのでどうも怪しい、とだけ言っておこう。
毎年来る卒論生の能力から明らかにそれがわかる。
面接では限られた時間しか無いので全てを聞くことはできないかもしれないが、
できるやつはとことんできる。できるやつとできない奴との差は異常に激しい、とも言っておこう。
できない奴は、代わりに数学や物理、数値計算などの授業で教わった内容に詳しい
傾向にある、とも言っておこう。
それから、昔はPerlを使いこなすだけでもUNIXのコマンドchmodなどを理解する必要があったけど
(おれは大学にインストールされていたSolaris + Perlで公開できるウェブページから
Linuxに対する興味を広げた)
今じゃその必要もなく、レンタルサーバで簡単にできるし、PHPというPerlより簡単な言語も
出てきてしまったからな。
>>125
だがJavaができる大学生は昔よりも確実に増えている。
なぜなら授業でJavaを教えているところが増えたからだ。
昔は東大くらいでしか教えておらずほとんどの大学がC言語ばかりだった。
それが今ではJavaに切り替わっている。ム板のJava質問スレはやたらと
大学生や新人社会人かと思われるレスが目立ちスレの消費も激しい。
情報工学科の大学生の大半はサーバ管理も構築もできるスキルは無いが
熱烈なJava信者なら大抵サーバ構築やLinux, Unixのコマンドくらいは使いこなせる。
それから俺の時代は、情報工学科の学生よりも電気工学科、電子工学科、機械工学科の
学生のほうが異様に自作PCやサーバ、プログラミングに詳しいというおかしな事態が目立った。
大抵、他学科は授業で教えてくれるが情報工学科は自分でできると見なされて
独学以外では習得できないケースが多い。本当は大学教授が新技術についてつけないだけなのだが・・
だがJavaができる大学生は昔よりも確実に増えている。
なぜなら授業でJavaを教えているところが増えたからだ。
昔は東大くらいでしか教えておらずほとんどの大学がC言語ばかりだった。
それが今ではJavaに切り替わっている。ム板のJava質問スレはやたらと
大学生や新人社会人かと思われるレスが目立ちスレの消費も激しい。
情報工学科の大学生の大半はサーバ管理も構築もできるスキルは無いが
熱烈なJava信者なら大抵サーバ構築やLinux, Unixのコマンドくらいは使いこなせる。
それから俺の時代は、情報工学科の学生よりも電気工学科、電子工学科、機械工学科の
学生のほうが異様に自作PCやサーバ、プログラミングに詳しいというおかしな事態が目立った。
大抵、他学科は授業で教えてくれるが情報工学科は自分でできると見なされて
独学以外では習得できないケースが多い。本当は大学教授が新技術についてつけないだけなのだが・・
>>139
つまり、JVM実装をパクって新しいC++Boostを作ってくれるのを待てばいいということか
つまり、JVM実装をパクって新しいC++Boostを作ってくれるのを待てばいいということか
>>39
break とか continue では、うまくないの?
break とか continue では、うまくないの?
大学で教えるのは枯れた知識のみ
新しいのが知りたかったら専門学校行ってくれ
そもそも大学なんて授業はオマケ、研究するところなんだから
新しいのが知りたかったら専門学校行ってくれ
そもそも大学なんて授業はオマケ、研究するところなんだから
>>150
Javaのラベルジャンプってswitchとループ文しかないじゃん。
Javaのラベルジャンプってswitchとループ文しかないじゃん。
>>151
専門でもロクなこと教えて無いよ
どっちみち独学で習得するなら、
時間が有り余る大学の方が有利なんじゃないかと漏れは思う
ちなみに>>148の
>情報工学科の大学生の大半はサーバ管理も構築もできるスキルは無いが
>熱烈なJava信者なら大抵サーバ構築やLinux, Unixのコマンドくらいは使いこなせる。
がやけに友人達に当てはまっていて笑えた
お前は俺の友人ｼﾞｬﾏｲｶ
専門でもロクなこと教えて無いよ
どっちみち独学で習得するなら、
時間が有り余る大学の方が有利なんじゃないかと漏れは思う
ちなみに>>148の
>情報工学科の大学生の大半はサーバ管理も構築もできるスキルは無いが
>熱烈なJava信者なら大抵サーバ構築やLinux, Unixのコマンドくらいは使いこなせる。
がやけに友人達に当てはまっていて笑えた
お前は俺の友人ｼﾞｬﾏｲｶ
BEAのBare Metalが凄いらしいぞ。ベイパーにならなければ。
>>151
> 大学で教えるのは枯れた知識のみ
> 新しいのが知りたかったら専門学校行ってくれ
> そもそも大学なんて授業はオマケ、研究するところなんだから
研究に携われば、新しいことを知るチャンスはいくらでもあるぞ。
情報処理学会とか、電子情報通信学会、IEEEとかにいけばな。
研究室に新しいことをやっている奴がいるとそいつから
新しい情報を得るチャンスもある。
それも大学教授次第。
教授がワンマンタイプだと新しいんんだか古いんだか
よく解らないこともある。
> 大学で教えるのは枯れた知識のみ
> 新しいのが知りたかったら専門学校行ってくれ
> そもそも大学なんて授業はオマケ、研究するところなんだから
研究に携われば、新しいことを知るチャンスはいくらでもあるぞ。
情報処理学会とか、電子情報通信学会、IEEEとかにいけばな。
研究室に新しいことをやっている奴がいるとそいつから
新しい情報を得るチャンスもある。
それも大学教授次第。
教授がワンマンタイプだと新しいんんだか古いんだか
よく解らないこともある。
専門学校行くんだったら
ゲーム専門学校がお勧め。
ゲーム作ることに興味がそれほどないなら
大学のほうがまし。
ゲーム専門学校がお勧め。
ゲーム作ることに興味がそれほどないなら
大学のほうがまし。
157 ：仕様書無しさん：2005/11/20(日) 16:07:31
未だにこんな古い記事を掲載している
会社もみっともないな。
C++とJavaの比較 1
"C++とJavaの比較(本文)"
http://www.infotek.co.jp/java/c_j1.html
今となってはすでに解決しているもの、
都市伝説になっているものが多いだけに
会社もみっともないな。
C++とJavaの比較 1
"C++とJavaの比較(本文)"
http://www.infotek.co.jp/java/c_j1.html
今となってはすでに解決しているもの、
都市伝説になっているものが多いだけに
158 ：仕様書無しさん：2005/11/20(日) 18:41:36
Java の文字列の扱いは中途半端な char のせいで C/C++ よりも
ややこしくなってるな。
ややこしくなってるな。
159 ：幼女 ◆T/br3aeaBg ：2005/11/20(日) 20:31:56
なんでゲーム作るときはC言語なの？
Javaだとパッドとかに対応しないから。
161 ：仕様書無しさん：2005/11/20(日) 20:48:48
どっちでも、極めれば飯が食える
Javaだと実行できない環境があるんだよ
さらにJavaのランタイム入れてる奴は少ない
VB6や.NETのほうがまだ多いぐらいだ
さらにJavaのランタイム入れてる奴は少ない
VB6や.NETのほうがまだ多いぐらいだ
> Javaだと実行できない環境があるんだよ
そんな環境だとCだってちゃちなゲームしか動かないだろ
> さらにJavaのランタイム入れてる奴は少ない
簡単に入れられるから問題なし。
そんな環境だとCだってちゃちなゲームしか動かないだろ
> さらにJavaのランタイム入れてる奴は少ない
簡単に入れられるから問題なし。
ていうかどっちか使えれば
結構もんだいなく一方も使えなくね？
結構もんだいなく一方も使えなくね？
C++→Javaの方向なら、自由度は低くなるが安全性は高くなる。
ライブラリの知識がない為、それを把握できるまでは力業コードになりがち。
使えなくはないが、Javaに慣れている人間とは比べられない。
Java→C++の方向なら、自由度は上がるが安全性は下がる。
Javaで手抜きすることに慣れているので、メモリ解放忘れなど、
クラッシュ原因になるバグを大量生産する可能性あり。
やっぱり使えなくはないと思うが、C++に慣れている人間とは論外なくらい比べられない。
ライブラリの知識がない為、それを把握できるまでは力業コードになりがち。
使えなくはないが、Javaに慣れている人間とは比べられない。
Java→C++の方向なら、自由度は上がるが安全性は下がる。
Javaで手抜きすることに慣れているので、メモリ解放忘れなど、
クラッシュ原因になるバグを大量生産する可能性あり。
やっぱり使えなくはないと思うが、C++に慣れている人間とは論外なくらい比べられない。
>>158
static char* str = "abc";
より
String str = "abc";
のほうが楽なんだけどな。
文字列の連結とか長さ取得とかもかなり楽でさ。
C++にもstring型あるけど中途半端すぎてcstringとか外部のに
たよらないと行けない始末。それがまた
自作クラスのメソッド引数に指定するときに足かせになって悪循環。
static char* str = "abc";
より
String str = "abc";
のほうが楽なんだけどな。
文字列の連結とか長さ取得とかもかなり楽でさ。
C++にもstring型あるけど中途半端すぎてcstringとか外部のに
たよらないと行けない始末。それがまた
自作クラスのメソッド引数に指定するときに足かせになって悪循環。
>>160
パッドって何をさすもの？
パッドって何をさすもの？
>>162
> Javaだと実行できない環境があるんだよ
> さらにJavaのランタイム入れてる奴は少ない
> VB6や.NETのほうがまだ多いぐらいだ
JavaWebStartで動くように開発すれば
JREは入れなくても
自動ダウンロード、自動インストールが始まるので問題なし。
当然ネットにつないでいる必要があるが。
ブラウザから拡張子jnlpファイルをクリックすると
JavaWebStartが起動してアプリをダウンロードし動き出す。
JavaWebStartっていうけど、中身はただJavaアプリケーションを
起動しやすいようにリンクしているだけ。
Java製のSwingやAWTで作られたGUIクライアントアプリケーション
を起動しやすくしている。
もしJavaWebStartがインストールされていないときは
その自動ダウンロード、自動インストールが始まる。
もしJRE(Java Runtime Environment)がインストールされていないときは
その自動ダウンロード、自動インストールが始まる。
そしてJavaWebStartが起動すると、
JavaWebStart対応アプリケーションを起動する準備が
始まり、まず、サーバにそのアプリの最新版があるかどうかを
確認し、最新版があればアプリを最新版にアップデートすべく
自動でアプリのダウンロード、インストールが始まる。
こういうところが凄いところだね。
ドトネトもこれの真似をしてノータッチデプロイメントというものを作ってはいるけど。
このJavaWebStart対応アプリ、結構早い。
昔は遅かったSwingもめっちゃくちゃ早くなったからね。
> Javaだと実行できない環境があるんだよ
> さらにJavaのランタイム入れてる奴は少ない
> VB6や.NETのほうがまだ多いぐらいだ
JavaWebStartで動くように開発すれば
JREは入れなくても
自動ダウンロード、自動インストールが始まるので問題なし。
当然ネットにつないでいる必要があるが。
ブラウザから拡張子jnlpファイルをクリックすると
JavaWebStartが起動してアプリをダウンロードし動き出す。
JavaWebStartっていうけど、中身はただJavaアプリケーションを
起動しやすいようにリンクしているだけ。
Java製のSwingやAWTで作られたGUIクライアントアプリケーション
を起動しやすくしている。
もしJavaWebStartがインストールされていないときは
その自動ダウンロード、自動インストールが始まる。
もしJRE(Java Runtime Environment)がインストールされていないときは
その自動ダウンロード、自動インストールが始まる。
そしてJavaWebStartが起動すると、
JavaWebStart対応アプリケーションを起動する準備が
始まり、まず、サーバにそのアプリの最新版があるかどうかを
確認し、最新版があればアプリを最新版にアップデートすべく
自動でアプリのダウンロード、インストールが始まる。
こういうところが凄いところだね。
ドトネトもこれの真似をしてノータッチデプロイメントというものを作ってはいるけど。
このJavaWebStart対応アプリ、結構早い。
昔は遅かったSwingもめっちゃくちゃ早くなったからね。
170 ：仕様書無しさん：2005/11/22(火) 00:59:36
171 ：仕様書無しさん：2005/11/22(火) 01:08:51
C/C++ なら、gcc だと wchar_t=32bit だから UCS-4 を直接ぶち込める。
メモリが惜しければ char に UTF-8 を入れるという選択もできる。
メモリが惜しければ char に UTF-8 を入れるという選択もできる。
>>170
言っておくが、J2SE バージョン 5.0 では Stringは
すでにUnicode 4.0 をサポートしているぞ。
それ以前のバージョンでも日本語は問題なく動いたし
日本語文字列から日本語文字一文字を取り出すメソッドを
実行しても問題がなかったわけだが。
JavaのStringクラスもCharacterクラスもchar型も
問題なくU+FFFF を越える32bits文字を扱うことができる。
言っておくが、J2SE バージョン 5.0 では Stringは
すでにUnicode 4.0 をサポートしているぞ。
それ以前のバージョンでも日本語は問題なく動いたし
日本語文字列から日本語文字一文字を取り出すメソッドを
実行しても問題がなかったわけだが。
JavaのStringクラスもCharacterクラスもchar型も
問題なくU+FFFF を越える32bits文字を扱うことができる。
昔、JDK1.3時代の同時多発テロが起きる前の2001年のときの話だが、
職場でC言語厨がJavaを初めて使ったとき、
C言語厨は「Javaのchar型は16bitsまでしかあつかえないから以下は41を返す」と主張した。
ところが実際に実行してみると21を返したとさ。
String str = "日本語表示あいうえお";
String result = str + "a" + str;
System.out.println(" length = " + result.length());
そんな話があるくらいだ。実際に動かしてみないとどうなるかわからないもんだから
16bitsしかあつかえないと思いこまない方が良い。
サロゲートペアを使っていることは確かだが、char型もCharacterクラスもStringクラスも
今まで通り問題なく使うことができる。
職場でC言語厨がJavaを初めて使ったとき、
C言語厨は「Javaのchar型は16bitsまでしかあつかえないから以下は41を返す」と主張した。
ところが実際に実行してみると21を返したとさ。
String str = "日本語表示あいうえお";
String result = str + "a" + str;
System.out.println(" length = " + result.length());
そんな話があるくらいだ。実際に動かしてみないとどうなるかわからないもんだから
16bitsしかあつかえないと思いこまない方が良い。
サロゲートペアを使っていることは確かだが、char型もCharacterクラスもStringクラスも
今まで通り問題なく使うことができる。
174 ：仕様書無しさん：2005/11/22(火) 22:21:06
>>172
いにしえの Java 厨は ASCII だろうが感じだろうが 1 文字あたりの
バイト数が固定長で表現できると自慢してた。
しかし、結局今の Java は可変長のバイト数で 1 文字を表現することに
なっている。
だったら char==1バイトな C のほうがよほどシンプルじゃん。
char==2バイトという意義が薄れつつある。
いにしえの Java 厨は ASCII だろうが感じだろうが 1 文字あたりの
バイト数が固定長で表現できると自慢してた。
しかし、結局今の Java は可変長のバイト数で 1 文字を表現することに
なっている。
だったら char==1バイトな C のほうがよほどシンプルじゃん。
char==2バイトという意義が薄れつつある。
175 ：仕様書無しさん：2005/11/22(火) 23:30:08
176 ：仕様書無しさん：2005/11/22(火) 23:31:06
それが出来ないで使えないとか言ってる時点で終わってるね。
178 ：仕様書無しさん：2005/11/23(水) 00:14:47
大体、マイクロソフトのCStringなんて糞なのは百も承知だ。
ただ、C++の世界はこれらのヘンテコなクラスを主体として
捉えて欲しくないと言っているのだ。
ただ、C++の世界はこれらのヘンテコなクラスを主体として
捉えて欲しくないと言っているのだ。
179 ：仕様書無しさん：2005/11/23(水) 00:16:55
設計者によって、拡張性は無限に広がる。
設計者がヘボなら、題材もヘボくなる。
設計者がヘボなら、題材もヘボくなる。
よってこのｽﾚは
=================終了==================
=================終了==================
>>174
> >>172
> いにしえの Java 厨は ASCII だろうが感じだろうが 1 文字あたりの
それ誰だ？ 有名な香具師か？
> だったら char==1バイトな C のほうがよほどシンプルじゃん。
> char==2バイトという意義が薄れつつある。
使いにくいぞ。マシンによってintが16bitsになったり32bitsになったり64bitsになったり
こりゃ問題有り。
それにおまいはJavaで文字や文字列操作を行ったことがあるのだろうか。
それでいてＣのほうが使いやすいといえる根拠を示してみてくれ。
> >>172
> いにしえの Java 厨は ASCII だろうが感じだろうが 1 文字あたりの
それ誰だ？ 有名な香具師か？
> だったら char==1バイトな C のほうがよほどシンプルじゃん。
> char==2バイトという意義が薄れつつある。
使いにくいぞ。マシンによってintが16bitsになったり32bitsになったり64bitsになったり
こりゃ問題有り。
それにおまいはJavaで文字や文字列操作を行ったことがあるのだろうか。
それでいてＣのほうが使いやすいといえる根拠を示してみてくれ。
>>181
なんかいかにも最近Java始めましたって感じだな。
なんかいかにも最近Java始めましたって感じだな。
>>181
そんなレベルの話はしてないだろ。
C++ なら std::string でも CString でも QString でも自由に選べばよい。
C だって所詮は char/wchar_t の配列だ。配列としてそのまま扱えばよい。
そんなレベルの話はしてないだろ。
C++ なら std::string でも CString でも QString でも自由に選べばよい。
C だって所詮は char/wchar_t の配列だ。配列としてそのまま扱えばよい。
184 ：仕様書無しさん：2005/11/23(水) 02:00:16
大体、ハンガリー記法なんてものは、VC++の中で提唱された勝手に決められた
手法であり、これに従って全ての記述をおこなわなければならないわけではない。
C++は、フリーフォーマットであり、こんな拘りを持たせたでしゃばりな設計者は、
ハッキリ言って邪魔者に等しい。
手法であり、これに従って全ての記述をおこなわなければならないわけではない。
C++は、フリーフォーマットであり、こんな拘りを持たせたでしゃばりな設計者は、
ハッキリ言って邪魔者に等しい。
185 ：仕様書無しさん：2005/11/23(水) 02:31:50
D&E 読むとびゃーねﾀｿは結構な自由主義者っぽいな。
弘法筆を選ばず。
それはさておき、C++から派生した言語がわんさか出てる昨今、
既にJavaかC++なんていってる時代ではないと思ふ。
それはさておき、C++から派生した言語がわんさか出てる昨今、
既にJavaかC++なんていってる時代ではないと思ふ。
ハンガリアン記法はVC++登場以前からあるよ。
188 ：めかる ◆ESz/5bpU46 ：2005/11/23(水) 09:21:27
スレタイからして宗教なのな(´ー｀)教義も教祖も違うんだからどっちも誰かにとってはいいものだ
しかしC++を選ぶヽ(´ー｀)ノ開発機がセレ500というちょう個人的理由での現実解
しかしC++を選ぶヽ(´ー｀)ノ開発機がセレ500というちょう個人的理由での現実解
しょーもない宗教論争が勃発しているヴァカスレはここですか。
まぁ、アプリ開発に限定すれば、M$がMFCをばっさり切り捨てて、
.NETに逝っちゃたから、C++には未来はないはな。
あきらめてC#でもはじめとけ。
それが嫌ならJavaで喰ってくか、人間やめるかだな。
所詮、SE/PGなんてそんな程度の存在でしかないんじゃね。
まぁ、アプリ開発に限定すれば、M$がMFCをばっさり切り捨てて、
.NETに逝っちゃたから、C++には未来はないはな。
あきらめてC#でもはじめとけ。
それが嫌ならJavaで喰ってくか、人間やめるかだな。
所詮、SE/PGなんてそんな程度の存在でしかないんじゃね。
じゃあなんでXPSP２で.net載らなかったの
191 ：仕様書無しさん：2005/11/23(水) 14:23:13
>>190
MSの本気は3.0からで今はまだ本気モード入ってないから
MSの本気は3.0からで今はまだ本気モード入ってないから
192 ：仕様書無しさん：2005/11/23(水) 14:27:21
C++/CLIはどうなのよ。
あれ見る限りC#の出番は少なくなりそうな気がするけど。
あとSystemCを使う分野で働いている人はここにはいる?
あれ見る限りC#の出番は少なくなりそうな気がするけど。
あとSystemCを使う分野で働いている人はここにはいる?
VISTAは.net2.0がデフォで入ってるらしいが
あるいは製品版だとバージョン違うのかもな
あるいは製品版だとバージョン違うのかもな
194 ：仕様書無しさん：2005/11/23(水) 14:57:21
Windows Vista も当初は .net ベースの WinFX がネイティブ API になると
宣伝されていたが、結局は Win32 API が主力として生きながらえることに
なりますた・・・。
というわけで、Windows のクライアントアプリに関しては、少なくとも
あと 5 年はナマの C/C++ も安泰だなｗ
>>192
VS2005 も C++/CLI が一番力入ってる感じ。
宣伝されていたが、結局は Win32 API が主力として生きながらえることに
なりますた・・・。
というわけで、Windows のクライアントアプリに関しては、少なくとも
あと 5 年はナマの C/C++ も安泰だなｗ
>>192
VS2005 も C++/CLI が一番力入ってる感じ。
195 ：仕様書無しさん：2005/11/23(水) 15:46:31
現状が把握できない>>189が居るのはこのスレでつか？
>>186
> 弘法筆を選ばず。
それは実際のところ幻想で
本当は結構選ぶんだよね。
世の中で大成功している億万長者は
しっかりと筆を選んでいるわけだが。
> それはさておき、C++から派生した言語がわんさか出てる昨今、
どうかな。
Cから派生した言語に比べたらC++から派生した言語は数知れず
> 弘法筆を選ばず。
それは実際のところ幻想で
本当は結構選ぶんだよね。
世の中で大成功している億万長者は
しっかりと筆を選んでいるわけだが。
> それはさておき、C++から派生した言語がわんさか出てる昨今、
どうかな。
Cから派生した言語に比べたらC++から派生した言語は数知れず
199 ：仕様書無しさん：2005/11/23(水) 16:50:23
C++ で D&E 本といったら The Design and Evolution of C++ のこと。
覚える順で言うならJava→C++だけど
コードの質を考えるならC++→Javaというルートもいい
不安定さに慣れてからJavaに入るとコード品質が格段に良くなる
早い話が両方やっとけ
コードの質を考えるならC++→Javaというルートもいい
不安定さに慣れてからJavaに入るとコード品質が格段に良くなる
早い話が両方やっとけ
201 ：仕様書無しさん：2005/11/24(木) 00:55:54
Java→Ｃ＋＋が良い。
C++から入ると膨大な言語仕様に惑わされる。
Javaから入ると、C++のオブジェクト指向な機能を使う＆Ｃの下っ端な機能
で良いから、移行がスムーズ。
更に、Javaで煩雑だったコードがC/C++で鍛えられ、スキルアップ間違いなし。
ここまで来たら、プログラミングの勉強は止めてよし。
C++から入ると膨大な言語仕様に惑わされる。
Javaから入ると、C++のオブジェクト指向な機能を使う＆Ｃの下っ端な機能
で良いから、移行がスムーズ。
更に、Javaで煩雑だったコードがC/C++で鍛えられ、スキルアップ間違いなし。
ここまで来たら、プログラミングの勉強は止めてよし。
Javaをやってる奴がJavaのコードをよくしたいならC++をやると効果的。
C++をやってる奴がC++のコードをよくしたいならJavaをやると効果的。
C++をやってる奴がC++のコードをよくしたいならJavaをやると効果的。
Javaは携帯でだけ生き残りそうだな。
Web系はPHPやRubyが圧倒的に楽だ。
特にRubyやってるとJavaの糞な言語仕様に戻れないし
Web系はPHPやRubyが圧倒的に楽だ。
特にRubyやってるとJavaの糞な言語仕様に戻れないし
204 ：仕様書無しさん：2005/11/24(木) 01:33:02
C++とJavaどっちにも先はあるだろうが、主力として生き残る分野が違ってくると思う。
デスクトップアプリならばやはり今のところJavaは主力足り得ない。
理由は簡単で各OSにとって最高に使い勝手のよいUIをJavaだと提供するのが難しいからだ。
ただ、JavaのUIに対する意識がどう変わるかによってはこの分野をJavaが侵食する時もくるかもしれない。
逆にUIのデメリットが存在しない実行環境（例えば携帯電話）だと開発サイクル全体のコスト対効果でJavaが優位に立つ。
AUがBREW上でJVMを構築し携帯アプリ開発の主戦場をもう一度Javaに戻そうとているのがいい例。
またJavaVM（やオープンソースプロダクト）が各種OSやデバイス、プロトコルの不整合性を強力に吸収してくれるため
相手先が不特定であるようなネットワークアプリはJavaが圧倒的に優位になる。
ハードウェアレベルの制御を行う必要性がある分野では言うまでも無くJavaはありえない。
CやC++の独壇場だ。
後は自分の経験からだが真剣なフレームワークやプラットフォームを新規に構築仕様とした場合、
staticに対してポリモーフィズムをサポートしていないというJavaの言語的制限がきつい。
クラス記述を見ただけで設計者の意図がプログラマーに伝わるようなオブジェクトライブラリを作成しにくい。
また、メモリ消費効率も格段に悪くなってしまうケースが多々あるためJavaはオススメできない。
この分野でもC++の方が優位な立場にあると思う。
デスクトップアプリならばやはり今のところJavaは主力足り得ない。
理由は簡単で各OSにとって最高に使い勝手のよいUIをJavaだと提供するのが難しいからだ。
ただ、JavaのUIに対する意識がどう変わるかによってはこの分野をJavaが侵食する時もくるかもしれない。
逆にUIのデメリットが存在しない実行環境（例えば携帯電話）だと開発サイクル全体のコスト対効果でJavaが優位に立つ。
AUがBREW上でJVMを構築し携帯アプリ開発の主戦場をもう一度Javaに戻そうとているのがいい例。
またJavaVM（やオープンソースプロダクト）が各種OSやデバイス、プロトコルの不整合性を強力に吸収してくれるため
相手先が不特定であるようなネットワークアプリはJavaが圧倒的に優位になる。
ハードウェアレベルの制御を行う必要性がある分野では言うまでも無くJavaはありえない。
CやC++の独壇場だ。
後は自分の経験からだが真剣なフレームワークやプラットフォームを新規に構築仕様とした場合、
staticに対してポリモーフィズムをサポートしていないというJavaの言語的制限がきつい。
クラス記述を見ただけで設計者の意図がプログラマーに伝わるようなオブジェクトライブラリを作成しにくい。
また、メモリ消費効率も格段に悪くなってしまうケースが多々あるためJavaはオススメできない。
この分野でもC++の方が優位な立場にあると思う。
Javaって何か５年後残ってる気がしないんだよね
> staticに対してポリモーフィズムをサポートしていない
これどういう意味？
これどういう意味？
207 ：仕様書無しさん：2005/11/24(木) 04:21:27
>205
10年前も同じことが言われてた。でも今そういう言葉を聞けるとは思わなかった。
たった5年で今利用されてるJavaの資産が捨て去られるはずない。むしろ拡張されるだろう。
>206
クラスメソッドに対して実行時に有効であるようなオーバーライドができないということだ。C++ならvirtual前飾子とスコープ解決演算子で簡単に実現できる。
通常のアプリ作成ではほとんど利用しない機能だから気にする必要ないよ。
10年前も同じことが言われてた。でも今そういう言葉を聞けるとは思わなかった。
たった5年で今利用されてるJavaの資産が捨て去られるはずない。むしろ拡張されるだろう。
>206
クラスメソッドに対して実行時に有効であるようなオーバーライドができないということだ。C++ならvirtual前飾子とスコープ解決演算子で簡単に実現できる。
通常のアプリ作成ではほとんど利用しない機能だから気にする必要ないよ。
5年後も携帯アプリとWebアプリのみ。
寿命はCOBOLより短いかもな。
2005年にCOBOLが死滅するとは思えないが、携帯やWebは代替言語で
あっというまにリプレースされる可能性がある。
寿命はCOBOLより短いかもな。
2005年にCOBOLが死滅するとは思えないが、携帯やWebは代替言語で
あっというまにリプレースされる可能性がある。
それにくらべて、C++の寿命はすごい長いね。
かれこれ、２０年近くか...
どちらが足掻こうが結局C言語様を崇め奉ってることには変わりがないんだけどな
213 ：仕様書無しさん：2005/11/24(木) 23:17:31
C も C++ も言語仕様が比較的安定してて、安心してコードを書けるからな。
それに比べると Java はまだ発展途上なのか、処理系のバージョンが上がるたびに
言語仕様そのものが変わってゆく。
ひところの Visual Basic を見ているようだ。
それに比べると Java はまだ発展途上なのか、処理系のバージョンが上がるたびに
言語仕様そのものが変わってゆく。
ひところの Visual Basic を見ているようだ。
下手するとVBより短いかもな。
215 ：仕様書無しさん：2005/11/24(木) 23:27:33
C言語は新たな適応分野として
ハードウェア記述言語としても普及していくだろうからまだまだ
無くなりそうに無いね。
ハードウェア記述言語としても普及していくだろうからまだまだ
無くなりそうに無いね。
そもそもプログラマには先が無い
>>216
禁句って言葉知ってる？goto使いさん。
禁句って言葉知ってる？goto使いさん。
Javaの案件って意外と安いよな
そりゃWebと携帯（アプリ）だもの。
そもそも金がとれない。
そもそも金がとれない。
220 ：仕様書無しさん：2005/11/25(金) 00:23:41
ママ、素人が何かほざいてるスレってここ？
のほほんジャワ原人がのさばってるスレはここでつか？
俺、Webと携帯しかやってないよ・・・orz
なにやればたくさんお金貰える？
なにやればたくさんお金貰える？
Javaで金がそこそこっていうと、Webとか携帯とかじゃなくて、
大型案件に客先常駐で、とかだろうな…。
Javaの場合、人材がある程度飽和してきているってのもあるだろ。
まぁ実際に意味のあるものを作れるとは限らんのだけど。
大型案件に客先常駐で、とかだろうな…。
Javaの場合、人材がある程度飽和してきているってのもあるだろ。
まぁ実際に意味のあるものを作れるとは限らんのだけど。
>>210
> それにくらべて、C++の寿命はすごい長いね。
互換性があやしいところだけど
JavaのようにJava Comminuty Proceessによる
監視がないから仕様が乱立してコンパイラも乱立して
同じソースコードでもコンパイラが変わると
コンパイルすらできないという欠点を抱えているからね。
寿命が凄く長いって言うけど
昔のC++と今のC++は全然違う。
ものが違いすぎる。昔のC++は既に死んでいて
今のC++は昔のC++とは全く異なる。
昔のC++で書いたコードすべてが今のC++コンパイラ
で確実にコンパイルできる保証はないわけだし。
> それにくらべて、C++の寿命はすごい長いね。
互換性があやしいところだけど
JavaのようにJava Comminuty Proceessによる
監視がないから仕様が乱立してコンパイラも乱立して
同じソースコードでもコンパイラが変わると
コンパイルすらできないという欠点を抱えているからね。
寿命が凄く長いって言うけど
昔のC++と今のC++は全然違う。
ものが違いすぎる。昔のC++は既に死んでいて
今のC++は昔のC++とは全く異なる。
昔のC++で書いたコードすべてが今のC++コンパイラ
で確実にコンパイルできる保証はないわけだし。
JVMもそのうちスクラッチから作り直すんだろ？
DirectXみたいにバージョン番号でエンジン切り替えたりするようになるって。
DirectXみたいにバージョン番号でエンジン切り替えたりするようになるって。
226 ：仕様書無しさん：2005/11/26(土) 00:04:03
>>224
ANSI C や ISO C++ に準拠して書いとけば、よほど古いコンパイラでも
無い限り、困った経験は無いが・・・。
GUI のライブラリなんかは処理系によって全然違うけど、これは
プラットフォーム自体の違いが理由として多いから仕方ない。
ANSI C や ISO C++ に準拠して書いとけば、よほど古いコンパイラでも
無い限り、困った経験は無いが・・・。
GUI のライブラリなんかは処理系によって全然違うけど、これは
プラットフォーム自体の違いが理由として多いから仕方ない。
>>225
VMはひとつのマシンに複数入れれるからどうころんでも大丈夫かと
VMはひとつのマシンに複数入れれるからどうころんでも大丈夫かと
C++に決まってんじゃん
Java使いって頭も技もないくせに屁理屈ばっか
Java使いって頭も技もないくせに屁理屈ばっか
JavaVMは、エミュレータとなんか違いがあるのかね？
どのマシンでも動くって15年前はインパクトあったけど、
今ではVMを経由する分、無駄が多くて、そもそも電力の無駄。
地球温暖化にも悪影響。
これだけバージョンも乱立するとちょっとねえ。
WINXP、SP2には入ってないし、マイクロソフトVMは、インストール手順が素人には
簡単じゃない。面倒くさいからSUNの入れがち。すると常駐してもっとうざくなる。
あと言語仕様もエラーハンドリングが複雑になりがちだし、
未だにセッターゲッターなんて仕様も健在。
JSPにいたっては、テストするにもコンパイル/反映に時間がかかりうざい。
運用上もバージョンアップが面倒でうざい。他言語への移植も面倒。
品質の悪いソースだとACCESS以上に移植困難と思う。
早く廃れてほしい。
VMなんて無くても、それぞれのプラットフォーム向けにコンパイルできれば十分。
どのマシンでも動くって15年前はインパクトあったけど、
今ではVMを経由する分、無駄が多くて、そもそも電力の無駄。
地球温暖化にも悪影響。
これだけバージョンも乱立するとちょっとねえ。
WINXP、SP2には入ってないし、マイクロソフトVMは、インストール手順が素人には
簡単じゃない。面倒くさいからSUNの入れがち。すると常駐してもっとうざくなる。
あと言語仕様もエラーハンドリングが複雑になりがちだし、
未だにセッターゲッターなんて仕様も健在。
JSPにいたっては、テストするにもコンパイル/反映に時間がかかりうざい。
運用上もバージョンアップが面倒でうざい。他言語への移植も面倒。
品質の悪いソースだとACCESS以上に移植困難と思う。
早く廃れてほしい。
VMなんて無くても、それぞれのプラットフォーム向けにコンパイルできれば十分。
>>230
> JavaVMは、エミュレータとなんか違いがあるのかね？
VMWareやVirtualPCはOSのエミュレータであって
CPUのエミュレータでは無いぞ。
> どのマシンでも動くって15年前はインパクトあったけど、
> 今ではVMを経由する分、無駄が多くて、そもそも電力の無駄。
> 地球温暖化にも悪影響。
屁理屈がどうこうという話があったが、
こういう地球温暖化がどうこうとか何も考えずに言いだす方が
かなり屁理屈だな。
VMを経由しないC++ではその分自分で手動で
OS非依存アプリになるように多大な苦労をして開発
しなきゃいけない分、無駄が多くてその分地球温暖化に
悪影響をあたえるともいえるんだけどね。
大抵、バージョンアップとかOSやコンパイラに
変化があるたびにコンパイルし直し、作り直しとか、
バグが見つかりやすい言語仕様のためにバグを取るために
無駄に時間を費やすことがよくあるわけだけど、
それこそ地球温暖化だよね。
> JavaVMは、エミュレータとなんか違いがあるのかね？
VMWareやVirtualPCはOSのエミュレータであって
CPUのエミュレータでは無いぞ。
> どのマシンでも動くって15年前はインパクトあったけど、
> 今ではVMを経由する分、無駄が多くて、そもそも電力の無駄。
> 地球温暖化にも悪影響。
屁理屈がどうこうという話があったが、
こういう地球温暖化がどうこうとか何も考えずに言いだす方が
かなり屁理屈だな。
VMを経由しないC++ではその分自分で手動で
OS非依存アプリになるように多大な苦労をして開発
しなきゃいけない分、無駄が多くてその分地球温暖化に
悪影響をあたえるともいえるんだけどね。
大抵、バージョンアップとかOSやコンパイラに
変化があるたびにコンパイルし直し、作り直しとか、
バグが見つかりやすい言語仕様のためにバグを取るために
無駄に時間を費やすことがよくあるわけだけど、
それこそ地球温暖化だよね。
> これだけバージョンも乱立するとちょっとねえ。
バージョン乱立といっても互換性はあるし。
C++コンパイラ乱立は酷いしかも下位互換性も上位互換性が
ないものばかり。それにCPUやOSがことなれば動かなくなることも。
乱立するCPUやOSと比べ、VMの乱立などたいしたことがない。
VMの乱立とくらべたらその乱立数ははかりしれないし
ちょっとコンパイラやCPU環境が違うとよく動かなくなる。
バージョン乱立といっても互換性はあるし。
C++コンパイラ乱立は酷いしかも下位互換性も上位互換性が
ないものばかり。それにCPUやOSがことなれば動かなくなることも。
乱立するCPUやOSと比べ、VMの乱立などたいしたことがない。
VMの乱立とくらべたらその乱立数ははかりしれないし
ちょっとコンパイラやCPU環境が違うとよく動かなくなる。
>>230
> WINXP、SP2には入ってないし、マイクロソフトVMは、インストール手順が素人には
> 簡単じゃない。面倒くさいからSUNの入れがち。すると常駐してもっとうざくなる。
マイクロソフトのVMはセキュリティ上問題があるし
裁判で入れるなという話にもなっている。
最近ではSun純正JVMもメーカー製PCならメーカーが入れているから問題ないんだけど。
アップデートも自動でやってくれるし。
それにインストールもJavaWebStartを使って自動でやってくれるので簡単だし。
> WINXP、SP2には入ってないし、マイクロソフトVMは、インストール手順が素人には
> 簡単じゃない。面倒くさいからSUNの入れがち。すると常駐してもっとうざくなる。
マイクロソフトのVMはセキュリティ上問題があるし
裁判で入れるなという話にもなっている。
最近ではSun純正JVMもメーカー製PCならメーカーが入れているから問題ないんだけど。
アップデートも自動でやってくれるし。
それにインストールもJavaWebStartを使って自動でやってくれるので簡単だし。
>>230
> あと言語仕様もエラーハンドリングが複雑になりがちだし、
それはC++でも同じことなんだけど。むしろC++の例外仕様は欠陥だらけだし。
finallyが無いのはどうみても欠陥でどうしようもないね。
> 未だにセッターゲッターなんて仕様も健在。
他の言語にもあるんだけど。C++でもそれくらいやるし。
自動生成ツールでsetter/getterなんて簡単に作れるし。
> あと言語仕様もエラーハンドリングが複雑になりがちだし、
それはC++でも同じことなんだけど。むしろC++の例外仕様は欠陥だらけだし。
finallyが無いのはどうみても欠陥でどうしようもないね。
> 未だにセッターゲッターなんて仕様も健在。
他の言語にもあるんだけど。C++でもそれくらいやるし。
自動生成ツールでsetter/getterなんて簡単に作れるし。
>>230
> JSPにいたっては、テストするにもコンパイル/反映に時間がかかりうざい。
そんなに時間がかからないんだけど。どういう環境ですか？
IDE使うか、Tomcatなどの設定を弄ればJSPファイルを保存すると同時に
Servletソースに変換、コンパイルみたいなことを自動でやってくれるよ。
それにApache Antを使えばデプロイも簡単だし
server.xmlでホットデプロイを有効にしておけばTomcatの再起動の手間も
かからないし。え？ もしかして知らなかった？ そりゃあご愁傷様w
> JSPにいたっては、テストするにもコンパイル/反映に時間がかかりうざい。
そんなに時間がかからないんだけど。どういう環境ですか？
IDE使うか、Tomcatなどの設定を弄ればJSPファイルを保存すると同時に
Servletソースに変換、コンパイルみたいなことを自動でやってくれるよ。
それにApache Antを使えばデプロイも簡単だし
server.xmlでホットデプロイを有効にしておけばTomcatの再起動の手間も
かからないし。え？ もしかして知らなかった？ そりゃあご愁傷様w
237 ：仕様書無しさん：2005/11/27(日) 14:39:07
>>230
> 運用上もバージョンアップが面倒でうざい。他言語への移植も面倒。
それはどの言語でも同じはずだけど。
VMのバージョンアップは自動化されているから問題ないんだけど。
それからプログラムのバージョンアップも一つのJARファイル、WARファイル、EAR
ファイルを更新するだけでいいんですけど。
デスクトップアプリならJavaWebStartを
使えば自動的に起動時に最新バージョンがあるかどうかチェックしてくれるんですけど。
TomcatならデプロイツールやApache Antを使えばホットデプロイ機能により、
Tomcat起動中でも簡単にWARのアップデートができるんですけど。
もしかして、知らなかったんですか？ 知らないでブツブツ文句を言っていたんですかw
というか、C++からJavaへの移植と比べたらJavaから他言語への移植なんて全然楽なんだけどw
> 運用上もバージョンアップが面倒でうざい。他言語への移植も面倒。
それはどの言語でも同じはずだけど。
VMのバージョンアップは自動化されているから問題ないんだけど。
それからプログラムのバージョンアップも一つのJARファイル、WARファイル、EAR
ファイルを更新するだけでいいんですけど。
デスクトップアプリならJavaWebStartを
使えば自動的に起動時に最新バージョンがあるかどうかチェックしてくれるんですけど。
TomcatならデプロイツールやApache Antを使えばホットデプロイ機能により、
Tomcat起動中でも簡単にWARのアップデートができるんですけど。
もしかして、知らなかったんですか？ 知らないでブツブツ文句を言っていたんですかw
というか、C++からJavaへの移植と比べたらJavaから他言語への移植なんて全然楽なんだけどw
238 ：仕様書無しさん：2005/11/27(日) 14:39:37
>>230
> 品質の悪いソースだとACCESS以上に移植困難と思う。
ACCESSって言語ですかw 比較対象を間違えていませんか？
C++のほうが品質の悪いソースを作りやすいんですけど。
> 早く廃れてほしい。
ましばらくは無理でしょうな。仮に廃れてもJava似の言語がでて
キミはまた同じ事を言って気がつけば、キミ自身がまさに時代遅れな「廃人」になるよw
> 品質の悪いソースだとACCESS以上に移植困難と思う。
ACCESSって言語ですかw 比較対象を間違えていませんか？
C++のほうが品質の悪いソースを作りやすいんですけど。
> 早く廃れてほしい。
ましばらくは無理でしょうな。仮に廃れてもJava似の言語がでて
キミはまた同じ事を言って気がつけば、キミ自身がまさに時代遅れな「廃人」になるよw
239 ：仕様書無しさん：2005/11/27(日) 14:39:58
>>230
> VMなんて無くても、それぞれのプラットフォーム向けにコンパイルできれば十分。
それぞれのプラットフォーム向けにコンパイルする手間がどれだけかかるかわかっているかな。
それぞれのプラットフォーム向けにコンパイルできないときが多いんだし、
それぞれのプラットフォーム向けにコンパイルできるように注意して
プログラミングするのはコンパイラではなく人間がやることだし。
それに、それぞれのプラットフォームを自分の手元に高い金を出して用意しないと逝けない欠点もある。
その負担、コストを考えるとそれぞれのプラットフォーム向けにコンパイル
するコストはかなりでかいもんだよ。
> VMなんて無くても、それぞれのプラットフォーム向けにコンパイルできれば十分。
それぞれのプラットフォーム向けにコンパイルする手間がどれだけかかるかわかっているかな。
それぞれのプラットフォーム向けにコンパイルできないときが多いんだし、
それぞれのプラットフォーム向けにコンパイルできるように注意して
プログラミングするのはコンパイラではなく人間がやることだし。
それに、それぞれのプラットフォームを自分の手元に高い金を出して用意しないと逝けない欠点もある。
その負担、コストを考えるとそれぞれのプラットフォーム向けにコンパイル
するコストはかなりでかいもんだよ。
なんかこのやり取り眺めてるとjavaは先がないんだなぁと感じてしまう
逆だろ？C++に先が無いから発展し続けるJavaをやっかんでるだけじゃん。
Windowsを叩きまくってた頃のLinux厨と同じ光景だな。
Windowsを叩きまくってた頃のLinux厨と同じ光景だな。
VM,.NET,C++,Java,C#どれも面倒で煩わしい。
GCができてもリソースリークはある。クローズし忘れはある。
C++は早くBoostを標準にしろよ。auto_ptrなんて氏ね。
早く便利な言語が出来ないかな。
GCができてもリソースリークはある。クローズし忘れはある。
C++は早くBoostを標準にしろよ。auto_ptrなんて氏ね。
早く便利な言語が出来ないかな。
そう？
構図的にはC++を叩きまくってるjava厨って感じに見えるけど
構図的にはC++を叩きまくってるjava厨って感じに見えるけど
何に使うかにもよるだろ。業務アプリならJavaで十分。
言語仕様はダサいけど、そのぶん猿でも理解できる。
一般大衆のための言語なんだよ、Javaは
言語仕様はダサいけど、そのぶん猿でも理解できる。
一般大衆のための言語なんだよ、Javaは
VB並みのRAD開発を手に入れたJavaに滅亡などありはせんよ。
業務アプリもJava化が進み、OSもLinuxで十分となってきた。
ゲームとかも繊細なチューニングが必要な分野はC++がいいと思う。
俺も流石にJNI使ってまでJavaに拘る気はないしな。今のJavaじゃパッドとか対応してないし。
業務アプリもJava化が進み、OSもLinuxで十分となってきた。
ゲームとかも繊細なチューニングが必要な分野はC++がいいと思う。
俺も流石にJNI使ってまでJavaに拘る気はないしな。今のJavaじゃパッドとか対応してないし。
247 ：仕様書無しさん：2005/11/27(日) 17:15:14
Web系とニッチなアプリ、そして一部の組み込みや携帯の分野ではJavaが
これからも発展する。
それ以外はC/C++の領域。これでいいだろ。
これからも発展する。
それ以外はC/C++の領域。これでいいだろ。
形態でもノキアの７０２NKのSymbian はすごいよ。
C++で普通に開発もできる。
携帯独自の機能を利用したアプリ作るには、
独自のAPIとか覚えなくちゃならないから敷居はかなり高いけど。
Symbianのアプリは、JAVAアプリとか格が違うよ。
JAVAが猿でも理解できるってのは
開発している業務システムのレベルがその程度なだけなんじゃないか？
JAVAは、いろんな会社の作ったプロジェクトのソース見ると
構造がバラバラなこと多いよ。これはかつてのVBみたいに簡単な言語じゃないってこと。
C++でも言えることかもしれないけど・・・。
単純な業務システムのレベルと比較して、JAVAもC++も高級じゃないかな
と思う今日このごろ。
（申し込み処理とか、データ閲覧とかだけのWEBアプリを前提に話をしてます）
C++で普通に開発もできる。
携帯独自の機能を利用したアプリ作るには、
独自のAPIとか覚えなくちゃならないから敷居はかなり高いけど。
Symbianのアプリは、JAVAアプリとか格が違うよ。
JAVAが猿でも理解できるってのは
開発している業務システムのレベルがその程度なだけなんじゃないか？
JAVAは、いろんな会社の作ったプロジェクトのソース見ると
構造がバラバラなこと多いよ。これはかつてのVBみたいに簡単な言語じゃないってこと。
C++でも言えることかもしれないけど・・・。
単純な業務システムのレベルと比較して、JAVAもC++も高級じゃないかな
と思う今日このごろ。
（申し込み処理とか、データ閲覧とかだけのWEBアプリを前提に話をしてます）
249 ：仕様書無しさん：2005/11/27(日) 20:06:37
>>235
C++ に finally はそもそも要らん。
finally の主な用途のリソース解放などは通常は別のイディオムで実現する。
それでも finally がいいと言うのなら、finally と同等の働きをする
マクロも作れるよ。
C++ に finally はそもそも要らん。
finally の主な用途のリソース解放などは通常は別のイディオムで実現する。
それでも finally がいいと言うのなら、finally と同等の働きをする
マクロも作れるよ。
デストラクタにでも開放させようってんだろうか？ｗ
finallyほしい
頻繁に使うというわけじゃないが
あったらいいと思う
頻繁に使うというわけじゃないが
あったらいいと思う
つauto_ptr、scoped_ptr
つauto_ptr、scoped_ptr
try-finnalyというコンビネーションも可能だしな
ガンガンreturn文を書けるというのは楽でいい
ガンガンreturn文を書けるというのは楽でいい
>>255
いやだから、Java で try-finally の try 節でガンガン return するような
コードと同等のコードは C++ でも書けるって。
まあ、このへんは Java と C++ で大きく言語仕様が異なる部分だから、
C++ を知らない人にはピンと来ないだろうけど・・・。
いやだから、Java で try-finally の try 節でガンガン return するような
コードと同等のコードは C++ でも書けるって。
まあ、このへんは Java と C++ で大きく言語仕様が異なる部分だから、
C++ を知らない人にはピンと来ないだろうけど・・・。
>>256
finnalyを別のクラスに委譲するんだろ？面土居。
finnalyを別のクラスに委譲するんだろ？面土居。
finnalyはいただけない。
>>253
スマートポインタではfds等の管理は出来ないよん。
スマートポインタではfds等の管理は出来ないよん。
260 ：ピカチュー：2005/11/27(日) 20:57:03
予想以上に盛り上がりましたね。
web系と組み込みの一部ではJava、それ以外ではC/C++といったところでしょうか。
メーカの求人を見てるとやはりC/C++が多いですね。ソニーとか松下とか。
まずはC++を勉強したいと思います。
web系と組み込みの一部ではJava、それ以外ではC/C++といったところでしょうか。
メーカの求人を見てるとやはりC/C++が多いですね。ソニーとか松下とか。
まずはC++を勉強したいと思います。
261 ：仕様書無しさん：2005/11/27(日) 21:10:57
ソニーや松下に「まともな」C++のソースがあると思っているのか（ｗ
262 ：仕様書無しさん：2005/11/27(日) 21:29:10
じゃあ言うが。C++版のfinallyをここに書いてみろよ。
評価してやるから。
評価してやるから。
組込の一部というか、携帯アプリな。
あれを組込と呼んでいいのか知らないが
あれを組込と呼んでいいのか知らないが
Finally finalizer(resource);
~Finally() {
resource->close();
}
どうせこんなんだろ
~Finally() {
resource->close();
}
どうせこんなんだろ
メーカーはいいぞお。生涯賃金３億円
@ITフォーラムで、Javaっていつのまにかずいぶんと下になってしまったよな。
267 ：仕様書無しさん：2005/11/27(日) 22:10:26
デストラクタでリソース解放することを「finally」って言うんだ？
へー。初めて知った。馬鹿じゃない？
へー。初めて知った。馬鹿じゃない？
結局互換性を維持しながら積極的に仕様を洗練させようと努力しているJavaはすげーってこったな。
デストラクタを使ったfinallyはローカル変数にアクセスできないのでちょっと面倒。
要工夫・・・・できるかなぁ？
誰か考えれ
要工夫・・・・できるかなぁ？
誰か考えれ
>>269
friend
friend
finallyはC++でも新規追加したほうがいいかも試練
結構便利だしメタプログラミングしようとするとちょっと無理ありすぎ。
結構便利だしメタプログラミングしようとするとちょっと無理ありすぎ。
D言語でいいじゃん。
273 ：仕様書無しさん：2005/11/27(日) 22:32:22
JVMって、MAMEみたいなの？
finally相当かは知らないけど、後処理のパターンとしてModern C++ Designに
載ってたような気がする。
ただ難解すぎてサンプルコードすら追えなかったから、記憶があやふやだけどorz
理屈は知らなくても、とにかくこう書けばこうなると暗記してしまえば問題ないの
かもしれないけど、なんか気分悪い。
てか、読むと凹むの確実なんで、家には置きたくない書籍だｗ
載ってたような気がする。
ただ難解すぎてサンプルコードすら追えなかったから、記憶があやふやだけどorz
理屈は知らなくても、とにかくこう書けばこうなると暗記してしまえば問題ないの
かもしれないけど、なんか気分悪い。
てか、読むと凹むの確実なんで、家には置きたくない書籍だｗ
俺のまわりもJavaの案件が殆どだ
279 ：情報学生：2005/11/27(日) 23:42:55
就活にそなえて、javaだけじゃなくてC++も勉強した方がいいのかな…
てか、PGになるのが恐い…
ただですらメンヘラなのに…
てか、PGになるのが恐い…
ただですらメンヘラなのに…
280 ：仕様書無しさん：2005/11/27(日) 23:44:57
>>279
メンタル面で不安があるなら、言語覚えるよりも、
対人のHowToを覚えた方が良いよ。ついでに対人のWhｙも覚えろ。
言語は気楽に覚えろ。言語知ってるからって持てはやされるわけじゃないから。
メンタル面で不安があるなら、言語覚えるよりも、
対人のHowToを覚えた方が良いよ。ついでに対人のWhｙも覚えろ。
言語は気楽に覚えろ。言語知ってるからって持てはやされるわけじゃないから。
281 ：情報学生：2005/11/27(日) 23:47:44
そっか…
親とすらまともに話せないおれは死ぬしかないみたいだ…
親とすらまともに話せないおれは死ぬしかないみたいだ…
282 ：情報学生：2005/11/27(日) 23:48:41
研究職とかだったら対人関係少なくてすむかな…orz
SEがｺﾐｭﾆｹｰｼｮﾝ能力必要なのは聞くけど、PGもそんな能力いるの？？
284 ：仕様書無しさん：2005/11/27(日) 23:53:00
社会人はみんなコミュニケーション能力必要だよ。
PGだからって甘く考えてると痛い目に遭う。
PGだからって甘く考えてると痛い目に遭う。
285 ：仕様書無しさん：2005/11/27(日) 23:55:05
完全に独りで仕事して稼ごうと考えているのなら
コミュニケーション能力とか考えなくて良いんじゃない？
本当に独りで仕事するのならね。
独りと言っても、どこかからか仕事もらったり、取ってくる必要があり、
そこでコミュニケーション能力が必要になってくる。
会社で雇われＰＧするにしても、プロジェクトに配属され、
チームで仕事するのだから、コミュニケーション能力が必要になってくる。
報告なし、連絡なし、相談なしで仕事がまわるほど楽な仕組みではない。
人間がやってることを忘れるな。
コミュニケーション能力とか考えなくて良いんじゃない？
本当に独りで仕事するのならね。
独りと言っても、どこかからか仕事もらったり、取ってくる必要があり、
そこでコミュニケーション能力が必要になってくる。
会社で雇われＰＧするにしても、プロジェクトに配属され、
チームで仕事するのだから、コミュニケーション能力が必要になってくる。
報告なし、連絡なし、相談なしで仕事がまわるほど楽な仕組みではない。
人間がやってることを忘れるな。
どうやら本当に死ぬしかなさそうだ
練炭買ってくる
あとちょっとのとこでいつも一歩踏み出せなかった
決意させてくれてありがとう
練炭買ってくる
あとちょっとのとこでいつも一歩踏み出せなかった
決意させてくれてありがとう
>>283
具象的になるほど文書化の度合いは落ちていく。
これは、ソフトウェアは変化するものだから、文書によって具象を
表現するほどソースコードと乖離していくという考え方からきてる
(具象的な文書はソースコードの変化に着いて行けない)。
何が言いたいかって言うと、新人に割り振られる仕事は粒度の小
さいより具象的なコーディングである場合が多い。
だから、要求が文書化されてる事を期待できない。よって、要求
を聞き出す能力が必要になるってこと。
そして、今度は自分が仕事を割り振る側に回ると、要求を伝える
能力が必要になる。
現在のプログラミングという作業は、コミュニケーションの塊だよ。
具象的になるほど文書化の度合いは落ちていく。
これは、ソフトウェアは変化するものだから、文書によって具象を
表現するほどソースコードと乖離していくという考え方からきてる
(具象的な文書はソースコードの変化に着いて行けない)。
何が言いたいかって言うと、新人に割り振られる仕事は粒度の小
さいより具象的なコーディングである場合が多い。
だから、要求が文書化されてる事を期待できない。よって、要求
を聞き出す能力が必要になるってこと。
そして、今度は自分が仕事を割り振る側に回ると、要求を伝える
能力が必要になる。
現在のプログラミングという作業は、コミュニケーションの塊だよ。
288 ：仕様書無しさん：2005/11/28(月) 00:15:38
電話番号の整合性チェックをする←これが仕様
文字種のチェック、桁数のチェック←これが実装
ここまではよしとしよう。
じゃぁ、携帯は？フリーダイヤルは？許容するのか弾くのか、その指定が無い。
そういうときは素直に直属のリーダーに聞かなきゃならない。
まぁ、この手のはほかっておいても仕様のせいって言っちゃえるけどｗ
文字種のチェック、桁数のチェック←これが実装
ここまではよしとしよう。
じゃぁ、携帯は？フリーダイヤルは？許容するのか弾くのか、その指定が無い。
そういうときは素直に直属のリーダーに聞かなきゃならない。
まぁ、この手のはほかっておいても仕様のせいって言っちゃえるけどｗ
290 ：仕様書無しさん：2005/11/28(月) 00:34:29
上司に質問したりだとか、報告したりだとか、
そういったことって日常会話ぐらいのｺﾐｭﾆｹｰｼｮﾝ能力があれば
大丈夫なんだろうか？
そういったことって日常会話ぐらいのｺﾐｭﾆｹｰｼｮﾝ能力があれば
大丈夫なんだろうか？
292 ：仕様書無しさん：2005/11/28(月) 00:38:15
ｺﾐｭﾆｹｰｼｮﾝ能力の意味が今ｲﾁわからんな…
ちゃんと理論だった会話や説明ができる能力ってこと？
それとも、営業みたいに好印象を持たれるような会話ができる能力ってこと？
ちゃんと理論だった会話や説明ができる能力ってこと？
それとも、営業みたいに好印象を持たれるような会話ができる能力ってこと？
294 ：仕様書無しさん：2005/11/28(月) 00:44:46
明るく元気に、くっ喋ることを コミュニケーション だと
勘違いしてる若者が多い。
仕事で必要なコミュニケーションだよ。意思疎通するための
キャッチボール。何が必要で、何が不要かくらいわかるだろ。
ま、自分も相手も人間だから、たまには雑談でもして
和ませる余裕も必要だけど。
勘違いしてる若者が多い。
仕事で必要なコミュニケーションだよ。意思疎通するための
キャッチボール。何が必要で、何が不要かくらいわかるだろ。
ま、自分も相手も人間だから、たまには雑談でもして
和ませる余裕も必要だけど。
295 ：仕様書無しさん：2005/11/28(月) 00:49:51
ぶっちゃけて言うと、
利害関係を排除したところで、どんな会話ができるのか。
がポイント。
利害関係を排除したところで、どんな会話ができるのか。
がポイント。
>>294
と、わかったようなこと言ってる本人がコミュニケーションで一番悩んでると見た。（ﾌﾟｹﾞﾗ
と、わかったようなこと言ってる本人がコミュニケーションで一番悩んでると見た。（ﾌﾟｹﾞﾗ
>>293
両方必要だと思う。
親切に答えてもらえる人も居れば、邪険に扱われる人も居る。
この親切と邪険の境界が、技術的(論理的)な差だけとは思えない
例を何度も見てきた。
質問は事前に内容を纏めてから聞くとか、そういうのは当たり前と
して、それとは別に好印象を持たれる聞き方ってのはあるんじゃな
いかな？
両方必要だと思う。
親切に答えてもらえる人も居れば、邪険に扱われる人も居る。
この親切と邪険の境界が、技術的(論理的)な差だけとは思えない
例を何度も見てきた。
質問は事前に内容を纏めてから聞くとか、そういうのは当たり前と
して、それとは別に好印象を持たれる聞き方ってのはあるんじゃな
いかな？
>明るく元気に、くっ喋ることを コミュニケーション だと
>勘違いしてる若者が多い。
>仕事で必要なコミュニケーションだよ。意思疎通するための
>キャッチボール。何が必要で、何が不要かくらいわかるだろ。
よかった…。漏れはてっきり明るく元気にしゃべる能力のことだとｵﾓﾀ。
根暗で友達少ないおれはコミュニケーション能力ゼロで死ぬしかないとｵﾓﾃました。
>勘違いしてる若者が多い。
>仕事で必要なコミュニケーションだよ。意思疎通するための
>キャッチボール。何が必要で、何が不要かくらいわかるだろ。
よかった…。漏れはてっきり明るく元気にしゃべる能力のことだとｵﾓﾀ。
根暗で友達少ないおれはコミュニケーション能力ゼロで死ぬしかないとｵﾓﾃました。
299 ：仕様書無しさん：2005/11/28(月) 00:56:52
営業みたいな接待能力とはまた違うものなのかな？
説明能力ってことなのか
301 ：仕様書無しさん：2005/11/28(月) 01:00:40
ニッポン人の得意な空気嫁だよ
303 ：仕様書無しさん：2005/11/28(月) 01:09:33
>>298
学生時代に根暗だった奴が、社会の荒波に揉まれて、
同窓会などで一見「明るくなったか？」と思わせられるような場面はあるよ。
別に明るくなったわけじゃなくて、必要に迫られてそうなってるんだよ。
そんな心配しなくても良いよ。フツーにやってれば、君の今悩んでることを
自然に解決されてる。（10年かかるかもしれないけど）
30歳になるまでは、肩の力を抜いて、思うように振る舞うのが一番だよ。
いまいくつ？22歳だとしたら、後8年もゆっくりできるじゃん。
学生時代に根暗だった奴が、社会の荒波に揉まれて、
同窓会などで一見「明るくなったか？」と思わせられるような場面はあるよ。
別に明るくなったわけじゃなくて、必要に迫られてそうなってるんだよ。
そんな心配しなくても良いよ。フツーにやってれば、君の今悩んでることを
自然に解決されてる。（10年かかるかもしれないけど）
30歳になるまでは、肩の力を抜いて、思うように振る舞うのが一番だよ。
いまいくつ？22歳だとしたら、後8年もゆっくりできるじゃん。
暗いよりは明るいほうが言いに決まってるw
305 ：仕様書無しさん：2005/11/28(月) 02:34:07
先輩。
発声が不明瞭で何をおっしゃってるのかわかりません。
発声が不明瞭で何をおっしゃってるのかわかりません。
>>294
> 明るく元気に、くっ喋ることを コミュニケーション だと
> 勘違いしてる若者が多い。
そういうふうに押しつける会社の上司が
結構いたりするんだよな。
これからは「コミュニケーションだコミュニケーションだ」
とかいって具体的にどうすればいいかをうまく説明できない
馬鹿が多く、結果的にそうなってしまったわけだ。
> 仕事で必要なコミュニケーションだよ。意思疎通するための
そういう説明がだめなんだよ。
具体的に何がいけないか、どうすればいいかと
ちゃんと説明できないと解決策は見えてこない。
> 明るく元気に、くっ喋ることを コミュニケーション だと
> 勘違いしてる若者が多い。
そういうふうに押しつける会社の上司が
結構いたりするんだよな。
これからは「コミュニケーションだコミュニケーションだ」
とかいって具体的にどうすればいいかをうまく説明できない
馬鹿が多く、結果的にそうなってしまったわけだ。
> 仕事で必要なコミュニケーションだよ。意思疎通するための
そういう説明がだめなんだよ。
具体的に何がいけないか、どうすればいいかと
ちゃんと説明できないと解決策は見えてこない。
論理的思考能力を養う
関係の本で
論理的コミュニケーション
という言葉が出てきた。
でさ、この本をみて思った。
某学生派遣会社のD社の社長が
変なことを言っていてさかちんときたんだが、
「技術者ってのはコミュニケーション能力がない」
とかいいやがってさ。その社長の経歴を見ると文系だったんだ。
理系に対する偏見もってる匂いを感じたよ。
あれ以来からやたらと「コミュニケーションコミュニケーション」連呼する奴が
信用できなくなった。まるで宗教みたいで、具体的にどうするかなんていいやしないし
あの会社は理系というだけで勝手にコミュニケーション能力がないから
仕事を与えないとかわけわからないこといったりして最悪だった。
関係の本で
論理的コミュニケーション
という言葉が出てきた。
でさ、この本をみて思った。
某学生派遣会社のD社の社長が
変なことを言っていてさかちんときたんだが、
「技術者ってのはコミュニケーション能力がない」
とかいいやがってさ。その社長の経歴を見ると文系だったんだ。
理系に対する偏見もってる匂いを感じたよ。
あれ以来からやたらと「コミュニケーションコミュニケーション」連呼する奴が
信用できなくなった。まるで宗教みたいで、具体的にどうするかなんていいやしないし
あの会社は理系というだけで勝手にコミュニケーション能力がないから
仕事を与えないとかわけわからないこといったりして最悪だった。
そこで思ったのはそのＤ社の社長は
論理的コミュニケーション能力がないとともった。
その社長のとりまきや営業とかも。
順序立てて説明するよりもとにかく見た目や雰囲気さえ
よければそれだけでコミュニケーション能力があると
見なす風潮にかなり呆れ、その会社の派遣アルバイトを
しばらく辞めてほかのところのアルバイト求人から募集することにした。
論理的コミュニケーション能力がないとともった。
その社長のとりまきや営業とかも。
順序立てて説明するよりもとにかく見た目や雰囲気さえ
よければそれだけでコミュニケーション能力があると
見なす風潮にかなり呆れ、その会社の派遣アルバイトを
しばらく辞めてほかのところのアルバイト求人から募集することにした。
>>301
> ニッポン人の得意な空気嫁だよ
その某学生派遣会社D社の社長はまさにこの
>>301みたいは発言を刷る香具師だった。
最悪だった。
意味不明だしなーなーでやってる感じだし
いい加減すぎてウンザリだった。
> ニッポン人の得意な空気嫁だよ
その某学生派遣会社D社の社長はまさにこの
>>301みたいは発言を刷る香具師だった。
最悪だった。
意味不明だしなーなーでやってる感じだし
いい加減すぎてウンザリだった。
絵空事を実現可能であるかのように話せちゃうヤツが最強なのです
312 ：仕様書無しさん：2005/11/28(月) 18:41:41
>>302
まさか顔の表情を読みとる能力のみがコミュニケーション能力
だとか思ってないよな？
多少は重要だが、顔だけで判断するなんて限度があるし
顔だけで相手が言いたいことやりたいことがすべて100%わかるなんて
エスパーみたいなのはいないし。
それをわかってないでそれがコミュニケーションだとか勘違いしているのが
いてちょっとむかついたことがあります。
論理的じゃないし、
論理的に話せというと理屈っぽいとか言いだすしな。
連中は「論理的思考能力＝理屈っぽい」というおかしな恒等式を
立てようとする。可笑しいんだよな。
論理的じゃなくいい加減に話していたらまるで宗教やオカルトだし
朝○新聞の捏造記事となんらかわらないしそっちのほうが本当に理屈っぽい。
それをわかってないで理系＝理屈っぽい屁理屈を言う＝コミュニケーション能力がない
とか言いだす文系に殺意を覚えたことがある。
ああいういい加減な考え方が幹部や営業、人事、文系の連中には流布して欲しくは
ないな、と思ったよ。
まさか顔の表情を読みとる能力のみがコミュニケーション能力
だとか思ってないよな？
多少は重要だが、顔だけで判断するなんて限度があるし
顔だけで相手が言いたいことやりたいことがすべて100%わかるなんて
エスパーみたいなのはいないし。
それをわかってないでそれがコミュニケーションだとか勘違いしているのが
いてちょっとむかついたことがあります。
論理的じゃないし、
論理的に話せというと理屈っぽいとか言いだすしな。
連中は「論理的思考能力＝理屈っぽい」というおかしな恒等式を
立てようとする。可笑しいんだよな。
論理的じゃなくいい加減に話していたらまるで宗教やオカルトだし
朝○新聞の捏造記事となんらかわらないしそっちのほうが本当に理屈っぽい。
それをわかってないで理系＝理屈っぽい屁理屈を言う＝コミュニケーション能力がない
とか言いだす文系に殺意を覚えたことがある。
ああいういい加減な考え方が幹部や営業、人事、文系の連中には流布して欲しくは
ないな、と思ったよ。
>>311
> 絵空事を実現可能であるかのように話せちゃうヤツが最強なのです
あぶないな。ただの山師じゃないか。
むしろ、
成功したら山師
失敗したら詐欺師
そんな山師みたいな勘だけで行動するのが
コミュニケーション能力だって言い切れるか？
あぶなっかしくてやってられない。
俺的には真のコミュニケーション能力は論理的思考能力に尽きると思う。
目的を定義するときには論理にこだわっる必要が無いが、
定められた目的が責任ある仕事。小さな失敗も
ゆるされない仕事だったら安直なのや山師みたいな行為は危険だし
人の命や自分だけでなく会社の将来にも悪影響をあたえかねない。
「論理的思考能力＝「(悪い意味での)理屈っぽい」
というふうに解釈する人は信用すべきじゃないし
そういう考えを持つ人は悪徳商法の勧誘などによく見られる。
> 絵空事を実現可能であるかのように話せちゃうヤツが最強なのです
あぶないな。ただの山師じゃないか。
むしろ、
成功したら山師
失敗したら詐欺師
そんな山師みたいな勘だけで行動するのが
コミュニケーション能力だって言い切れるか？
あぶなっかしくてやってられない。
俺的には真のコミュニケーション能力は論理的思考能力に尽きると思う。
目的を定義するときには論理にこだわっる必要が無いが、
定められた目的が責任ある仕事。小さな失敗も
ゆるされない仕事だったら安直なのや山師みたいな行為は危険だし
人の命や自分だけでなく会社の将来にも悪影響をあたえかねない。
「論理的思考能力＝「(悪い意味での)理屈っぽい」
というふうに解釈する人は信用すべきじゃないし
そういう考えを持つ人は悪徳商法の勧誘などによく見られる。
コミュニケーション能力
・相手の考えを判る事
・自分の考えを判らせる事
この二つに尽きる。
特に後者。会話の中で、相手が本当に判ってるかどうかを
探れるぐらいにならないといけない。
というか、これが出来ない人間は、無用なトラブルを
あちこちで起こすタイプなわけだが、原因が相手にあるとしか
考えないからタチが悪い。
・相手の考えを判る事
・自分の考えを判らせる事
この二つに尽きる。
特に後者。会話の中で、相手が本当に判ってるかどうかを
探れるぐらいにならないといけない。
というか、これが出来ない人間は、無用なトラブルを
あちこちで起こすタイプなわけだが、原因が相手にあるとしか
考えないからタチが悪い。
>>257
それだけじゃうまくいかない。
C++ではcatch節とcatch終わったところに
finallyの内容を全部書く方法になってしまう。
効率がわるい。例外が発生してもしなくてもfinallyを
必ず実行できるような綺麗なコードをC++でかくことは容易ではない。
それだけじゃうまくいかない。
C++ではcatch節とcatch終わったところに
finallyの内容を全部書く方法になってしまう。
効率がわるい。例外が発生してもしなくてもfinallyを
必ず実行できるような綺麗なコードをC++でかくことは容易ではない。
>>248
> 形態でもノキアの７０２NKのSymbian はすごいよ。
> C++で普通に開発もできる。
BREWか？ CPに検証かけないといけないしそれにも金かかるし
セュリティを意識してプログラミングしないといけないし。
KDDIのサーバにしかアプリ置けないし
> 形態でもノキアの７０２NKのSymbian はすごいよ。
> C++で普通に開発もできる。
BREWか？ CPに検証かけないといけないしそれにも金かかるし
セュリティを意識してプログラミングしないといけないし。
KDDIのサーバにしかアプリ置けないし
>>244
> 何に使うかにもよるだろ。業務アプリならJavaで十分。
> 言語仕様はダサいけど、そのぶん猿でも理解できる。
> 一般大衆のための言語なんだよ、Javaは
一般大衆が理解できるのは基本部分だけだよ。
エンタープライズとなるとそうはいかない。
C++よりも難しく、侮れない。
Javaを極めるためにはデータベース、ネットワーク、
セキュリティ、サーバOS管理などのスキルが必要だ。
それは一般大衆には無理。
> 何に使うかにもよるだろ。業務アプリならJavaで十分。
> 言語仕様はダサいけど、そのぶん猿でも理解できる。
> 一般大衆のための言語なんだよ、Javaは
一般大衆が理解できるのは基本部分だけだよ。
エンタープライズとなるとそうはいかない。
C++よりも難しく、侮れない。
Javaを極めるためにはデータベース、ネットワーク、
セキュリティ、サーバOS管理などのスキルが必要だ。
それは一般大衆には無理。
>>249
基幹系業務はそこいらの業務システムとは
くらべものにならないほど難易度が高いぞ。
サルでも理解できるのは基本文法のみ
実際にはEJBやSOAとかなるとかなりのスキルを
要求されることは間違いない。
例外処理の扱い方を理解できない人間は未だに
多いしApache AntやMaven, JUnitなどを
使いこなせる人間、クラスを正しく設計できる
人間は少ないし。これらをきちっとしっかり
理解している人間は意外と少ない。
現状ではそれらをきちっと理解している人間が
少ないためにプログラムに欠陥がでたりする。
基幹系業務はそこいらの業務システムとは
くらべものにならないほど難易度が高いぞ。
サルでも理解できるのは基本文法のみ
実際にはEJBやSOAとかなるとかなりのスキルを
要求されることは間違いない。
例外処理の扱い方を理解できない人間は未だに
多いしApache AntやMaven, JUnitなどを
使いこなせる人間、クラスを正しく設計できる
人間は少ないし。これらをきちっとしっかり
理解している人間は意外と少ない。
現状ではそれらをきちっと理解している人間が
少ないためにプログラムに欠陥がでたりする。
319 ：仕様書無しさん：2005/11/28(月) 18:59:07
>>318のいるところはレベル低そうだなｗ
>例外処理の扱い方を理解できない人間は未だに多いし
>Apache AntやMaven, JUnitなどを使いこなせる人間
イタイ
>Apache AntやMaven, JUnitなどを使いこなせる人間
イタイ
Javaが簡単だってのは基本文法が簡単なのとライブラリ・ツールがそろっているから。
でもちょっと難しいこと、たとえばリフレクションさえ知ってる奴は少ない。
でもちょっと難しいこと、たとえばリフレクションさえ知ってる奴は少ない。
> ライブラリ・ツールがそろっている
重要だな
重要だな
疑問があるんだが、C++使ってるヤシならtry-catch構文は出来るだけ使わない様に
するのが基本じゃね？
まあ、新しい仕様になればなるほどtry-catch使うことになるんだが。
するのが基本じゃね？
まあ、新しい仕様になればなるほどtry-catch使うことになるんだが。
そうはいっても、標準ライブラリや言語自身が std::exception 系を
どんどん投げてくるからなあ。
どんどん投げてくるからなあ。
328 ：仕様書無しさん：2005/11/29(火) 00:53:43
>>318
またお前かよ。以前もどこかのスレで言ってたよね？
基幹業務基幹業務ってまじウゼーよ。それしか言えんのか？
歯車の一部になってることを、そんなに誇りに思ってるのか？
しかも、論点違うし。基幹業務って言いたいだけだろ？
基幹業務システムの世界は、お前が言うように理解できて
ない奴がうじゃうじゃいるよ。なにせデカイんだから知らなくて良いこと
が多い。
とはいえ、お前が言ってるようなことは、フツーに誰でも理解できてますよ？
視野狭すぎじゃない？
そもそもそもそも、お前の言うツールを使いこなすにはそんなにスキルを
必要としない。言うようにスキルを伴い難解なツールなら流行らないし、
そういうツールを作るプロダクトは、一般人でも理解できるように考えられている。
またお前かよ。以前もどこかのスレで言ってたよね？
基幹業務基幹業務ってまじウゼーよ。それしか言えんのか？
歯車の一部になってることを、そんなに誇りに思ってるのか？
しかも、論点違うし。基幹業務って言いたいだけだろ？
基幹業務システムの世界は、お前が言うように理解できて
ない奴がうじゃうじゃいるよ。なにせデカイんだから知らなくて良いこと
が多い。
とはいえ、お前が言ってるようなことは、フツーに誰でも理解できてますよ？
視野狭すぎじゃない？
そもそもそもそも、お前の言うツールを使いこなすにはそんなにスキルを
必要としない。言うようにスキルを伴い難解なツールなら流行らないし、
そういうツールを作るプロダクトは、一般人でも理解できるように考えられている。
>>317
> Javaを極めるためにはデータベース、ネットワーク、
> セキュリティ、サーバOS管理などのスキルが必要だ。
>>244は言語仕様の事を言っているんだろ。
それなら、ネットワーク、データベース、セキュリティ、サーバOS管理のスキルなんぞ必要ない。
> Javaを極めるためにはデータベース、ネットワーク、
> セキュリティ、サーバOS管理などのスキルが必要だ。
>>244は言語仕様の事を言っているんだろ。
それなら、ネットワーク、データベース、セキュリティ、サーバOS管理のスキルなんぞ必要ない。
Java言語とJava関連技術を混同してない？
前者と後者では求められる物が違うわけで。
Java言語仕様通りにコーディングするのは難しくない。
関連技術について言ってるのなら、確かにJavaプログラマが
覚えないといけないことは多岐にわたる。
でも、その関連技術それぞれが専門的なことなので、
単にJavaプログラマだけの立場なら「利用」することだけを
考えれば良い。責任範囲が違うから。
前者と後者では求められる物が違うわけで。
Java言語仕様通りにコーディングするのは難しくない。
関連技術について言ってるのなら、確かにJavaプログラマが
覚えないといけないことは多岐にわたる。
でも、その関連技術それぞれが専門的なことなので、
単にJavaプログラマだけの立場なら「利用」することだけを
考えれば良い。責任範囲が違うから。
>>317の論理で物事を考えると、C/C++プログラマは
Javaプログラマのそれよりも覚えることが膨大にある。
なにせUNIXはC言語で出来ている。今現在で価値のある
多くのミドルウェアはC/C++で実装されており、そのAPIも
C/C++であることが多い。
ネットワークならば、物理層レベルからC/C++が利用されており、
その範囲はアプリケーション層にまで及ぶ。セキュリティもまたしかり。
どうだ？その論理で考えるとJavaプログラマがいかに
覚えることが少なくて楽なのか分かるだろ？ｗ
Javaプログラマのそれよりも覚えることが膨大にある。
なにせUNIXはC言語で出来ている。今現在で価値のある
多くのミドルウェアはC/C++で実装されており、そのAPIも
C/C++であることが多い。
ネットワークならば、物理層レベルからC/C++が利用されており、
その範囲はアプリケーション層にまで及ぶ。セキュリティもまたしかり。
どうだ？その論理で考えるとJavaプログラマがいかに
覚えることが少なくて楽なのか分かるだろ？ｗ
別に楽だから悪って考えがないから、Javaは普通に好きだ。
そんな馬鹿なこだわりに縛られるのはオタクだけだよ。
あとJavaから他の言語に移ると滅茶苦茶吸収が早い。
CからC++へ行くと面倒が増えるだけでうざい思いがしたが
Javaから行くともともとCの下地がある分見事に融和した。
CとJavaを覚えるのがオールラウンダーへの近道だと思う。
そんな馬鹿なこだわりに縛られるのはオタクだけだよ。
あとJavaから他の言語に移ると滅茶苦茶吸収が早い。
CからC++へ行くと面倒が増えるだけでうざい思いがしたが
Javaから行くともともとCの下地がある分見事に融和した。
CとJavaを覚えるのがオールラウンダーへの近道だと思う。
経験は必然性を教えない
Javaで参照を引数に渡しても
メソッド内で生成できないってやつだな
メソッド内で生成できないってやつだな
>>328
> そもそもそもそも、お前の言うツールを使いこなすにはそんなにスキルを
> 必要としない。言うようにスキルを伴い難解なツールなら流行らないし、
> そういうツールを作るプロダクトは、一般人でも理解できるように考えられている。
そのくせ理解できない奴が多いのは一体どういうことだろうか？
古い考え方に捕らわれているのか、古い社内体制に縛られて実践できないから何だろうか。
新しいツールを使うとその分だけテストにかかる負担が増えるから新しいツールや
ライブラリは使いたくないと言いだすのがいるし。
> そもそもそもそも、お前の言うツールを使いこなすにはそんなにスキルを
> 必要としない。言うようにスキルを伴い難解なツールなら流行らないし、
> そういうツールを作るプロダクトは、一般人でも理解できるように考えられている。
そのくせ理解できない奴が多いのは一体どういうことだろうか？
古い考え方に捕らわれているのか、古い社内体制に縛られて実践できないから何だろうか。
新しいツールを使うとその分だけテストにかかる負担が増えるから新しいツールや
ライブラリは使いたくないと言いだすのがいるし。
>>333
> Java言語とJava関連技術を混同してない？
> 前者と後者では求められる物が違うわけで。
> Java言語仕様通りにコーディングするのは難しくない。
> 関連技術について言ってるのなら、確かにJavaプログラマが
> 覚えないといけないことは多岐にわたる。
> でも、その関連技術それぞれが専門的なことなので、
> 単にJavaプログラマだけの立場なら「利用」することだけを
> 考えれば良い。責任範囲が違うから。
それを「利用」することがどれだけ大変なのかわかってない。
っていうかおれがいいたかったことは
Javaは馬鹿でもできるとかいって高をくくっている奴が
いたからそれに対する警告として言ってみただけ。
> Java言語とJava関連技術を混同してない？
> 前者と後者では求められる物が違うわけで。
> Java言語仕様通りにコーディングするのは難しくない。
> 関連技術について言ってるのなら、確かにJavaプログラマが
> 覚えないといけないことは多岐にわたる。
> でも、その関連技術それぞれが専門的なことなので、
> 単にJavaプログラマだけの立場なら「利用」することだけを
> 考えれば良い。責任範囲が違うから。
それを「利用」することがどれだけ大変なのかわかってない。
っていうかおれがいいたかったことは
Javaは馬鹿でもできるとかいって高をくくっている奴が
いたからそれに対する警告として言ってみただけ。
>>332
> >>317
> >>244は言語仕様の事を言っているんだろ。
> それなら、ネットワーク、データベース、セキュリティ、サーバOS管理のスキルなんぞ必要ない。
いまどきネットワークもデータベースもセキュリティも
サーバ管理能力もない奴にはJavaプログラマなんて勤まらないぞ。
Tomcatを使ったサービスの開発が多い中、
UNIXのコマンドはいくつか知ってないとJavaを使った仕事はまずできないし。
だから「Javaは馬鹿でもできる」とか「大衆向け言語」だとか思いこむのは
危険だと言ってみたんだよ。そういう誤解を生んだ結果デスマーチになったプロジェクトを
よくみてきたもんだ。馬鹿でもできるとタカをくくった、CとPerlのスペシャリストが
Javaを使ってオークションサイトを開発しようとしたがやはりServletのことがわからず、
JDBCのこともわからず、納期は半年以上遅れた。彼はSolaris, Linuxを
使いこなすことに関してはプロフェッショナルに近かったが、オブジェクト指向の
ことをよくわかていなかった。superやthisというキーワードがわからない、オーバライドも
わからない。Object#equals(Object)の挙動と==の挙動との違いもわからない、
そんな状態がしばらく続いたなかで彼はプロジェクトにリーダを努めた。例外処理の
使い方もいい加減でデバッグは大変だった。それで徹夜ばかりが続いた。
だからお前らや初心者に警告しておく、Javaを「馬鹿でもできる言語」などと甘く見ない方がいい。
> >>317
> >>244は言語仕様の事を言っているんだろ。
> それなら、ネットワーク、データベース、セキュリティ、サーバOS管理のスキルなんぞ必要ない。
いまどきネットワークもデータベースもセキュリティも
サーバ管理能力もない奴にはJavaプログラマなんて勤まらないぞ。
Tomcatを使ったサービスの開発が多い中、
UNIXのコマンドはいくつか知ってないとJavaを使った仕事はまずできないし。
だから「Javaは馬鹿でもできる」とか「大衆向け言語」だとか思いこむのは
危険だと言ってみたんだよ。そういう誤解を生んだ結果デスマーチになったプロジェクトを
よくみてきたもんだ。馬鹿でもできるとタカをくくった、CとPerlのスペシャリストが
Javaを使ってオークションサイトを開発しようとしたがやはりServletのことがわからず、
JDBCのこともわからず、納期は半年以上遅れた。彼はSolaris, Linuxを
使いこなすことに関してはプロフェッショナルに近かったが、オブジェクト指向の
ことをよくわかていなかった。superやthisというキーワードがわからない、オーバライドも
わからない。Object#equals(Object)の挙動と==の挙動との違いもわからない、
そんな状態がしばらく続いたなかで彼はプロジェクトにリーダを努めた。例外処理の
使い方もいい加減でデバッグは大変だった。それで徹夜ばかりが続いた。
だからお前らや初心者に警告しておく、Javaを「馬鹿でもできる言語」などと甘く見ない方がいい。
>>334
随分とおかしな論理だな。
大半のC++プログラマですら覚えなくてもいいことばかりじゃないか。
車輪の再発名をするわけではないんだし。
Javaの登場によって新たなパラダイム、新たな考え方が生まれ、
そこから新たに覚えないといけないことが増えた。
従来通りのやり方であればJavaでの開発は「馬鹿でもできる」れべるだろう。
だが社会はJavaに大してもっと大きなことを期待している。
折角良い言語があるならそれを有効利用したいと誰もが考えるはずだ。
Javaの登場によって今まで人間がやらなければならなかったことを
コンピュータに任せることができるようになった。するとJavaエンジニアは
その余裕ができた分だけもっと大事な他のことに自分の力を注ぐ
ことができるようになったというわけだ。スタイルの一身だ。
新たに部下を雇えば経営者は自分の負担が減る。
だからといって仕事が減って職に困ってしまうわけではない。
自分のすべきもっと大事な仕事に専念しやすくなるということだ。
Javaによって、今まで忙しくて手をつけられなかった未開拓領域に
手を出しやすくなったということだ。陸から海へ上がる、地球から宇宙へ飛び立つように。
随分とおかしな論理だな。
大半のC++プログラマですら覚えなくてもいいことばかりじゃないか。
車輪の再発名をするわけではないんだし。
Javaの登場によって新たなパラダイム、新たな考え方が生まれ、
そこから新たに覚えないといけないことが増えた。
従来通りのやり方であればJavaでの開発は「馬鹿でもできる」れべるだろう。
だが社会はJavaに大してもっと大きなことを期待している。
折角良い言語があるならそれを有効利用したいと誰もが考えるはずだ。
Javaの登場によって今まで人間がやらなければならなかったことを
コンピュータに任せることができるようになった。するとJavaエンジニアは
その余裕ができた分だけもっと大事な他のことに自分の力を注ぐ
ことができるようになったというわけだ。スタイルの一身だ。
新たに部下を雇えば経営者は自分の負担が減る。
だからといって仕事が減って職に困ってしまうわけではない。
自分のすべきもっと大事な仕事に専念しやすくなるということだ。
Javaによって、今まで忙しくて手をつけられなかった未開拓領域に
手を出しやすくなったということだ。陸から海へ上がる、地球から宇宙へ飛び立つように。
>>342
> Tomcatを使ったサービスの開発が多い中、
> UNIXのコマンドはいくつか知ってないとJavaを使った仕事はまずできないし。
だから、UNIXのコマンドをいくつか知ってれば、十分でしょ？
だいたい、ネットワーク、データベース、セキュリティ、サーバ管理能力ってどれぐらいのレベルの事を言っているんだ？
Javaだけをやってきた人間でBSDやSystemVに詳しい奴なんぞ一人も見た事が無い。
下手すれば、「BSDって何？」って言う奴さえいる。
Javaプログラマに限った話ではないが、ネットワークには詳しいがデータベースは駄目、もしくはその逆の奴にしか俺は出会ったことが無い。
また、セキュリティはともかく、サーバ管理能力が求められる事なんて一度として無い。
> だから「Javaは馬鹿でもできる」とか「大衆向け言語」だとか思いこむのは
> 危険だと言ってみたんだよ。そういう誤解を生んだ結果デスマーチになったプロジェクトを
> よくみてきたもんだ。
デスマーチになるのはただ単にプロジェクトの見積もりが甘いからだろ？
半年も納期が遅れるなんて技術以前の問題だよ。
> Tomcatを使ったサービスの開発が多い中、
> UNIXのコマンドはいくつか知ってないとJavaを使った仕事はまずできないし。
だから、UNIXのコマンドをいくつか知ってれば、十分でしょ？
だいたい、ネットワーク、データベース、セキュリティ、サーバ管理能力ってどれぐらいのレベルの事を言っているんだ？
Javaだけをやってきた人間でBSDやSystemVに詳しい奴なんぞ一人も見た事が無い。
下手すれば、「BSDって何？」って言う奴さえいる。
Javaプログラマに限った話ではないが、ネットワークには詳しいがデータベースは駄目、もしくはその逆の奴にしか俺は出会ったことが無い。
また、セキュリティはともかく、サーバ管理能力が求められる事なんて一度として無い。
> だから「Javaは馬鹿でもできる」とか「大衆向け言語」だとか思いこむのは
> 危険だと言ってみたんだよ。そういう誤解を生んだ結果デスマーチになったプロジェクトを
> よくみてきたもんだ。
デスマーチになるのはただ単にプロジェクトの見積もりが甘いからだろ？
半年も納期が遅れるなんて技術以前の問題だよ。
Java プログラマには Tomcat 云々の知識が必要とか言いきってる時点で、
要するに Java にはそういう用途しか期待されてないことを言いたいわけ？
別にソフトウェアというのはサーバサイドでデータベースを使うものだけじゃ
ないんだが。
要するに Java にはそういう用途しか期待されてないことを言いたいわけ？
別にソフトウェアというのはサーバサイドでデータベースを使うものだけじゃ
ないんだが。
>>339
ポインタと参照の違いが分からん奴を結構、見てきたよ。俺は。
ポインタと参照の違いが分からん奴を結構、見てきたよ。俺は。
だからさ、自分の周りのレベルが低すぎるんだって気づけよw
漏れも職業プログラマとして飯を食ってるが、ぶっちゃけサーバ関係や DB の
知識なんぞこれっぽっちもいらん。そもそも使ってないし。
その代わり確率統計などの数学の知識が必要で、それがないとプログラム中の
処理の流れを追うことすら難しい。
ただそれは Java で実装しようが C++ で実装しようが同じで、特に言語に
依存するようなことでもない。
知識なんぞこれっぽっちもいらん。そもそも使ってないし。
その代わり確率統計などの数学の知識が必要で、それがないとプログラム中の
処理の流れを追うことすら難しい。
ただそれは Java で実装しようが C++ で実装しようが同じで、特に言語に
依存するようなことでもない。
>>342に出てくる「スペシャリスト」やら「プロフェッショナル」ってのは
相当レベルが低い。というか、「経歴を捏造された派遣社員」に近い気がするのだが・・。
あと、>>343の後半は同意。
仮にC++に比べて制限があったとしても、刷新・整理されたライブラリや仕様は
生産性アップの大きな力になるだろう。
相当レベルが低い。というか、「経歴を捏造された派遣社員」に近い気がするのだが・・。
あと、>>343の後半は同意。
仮にC++に比べて制限があったとしても、刷新・整理されたライブラリや仕様は
生産性アップの大きな力になるだろう。
>>327
そうだった(恥)。
でも、基本的にDBとかファイル位だろ
CとC++でtry-catch構文使うのは
みんな、newするときにも必ずtry-catch構文使う？
try-catch構文でうんだらこうたらって言っている
感覚が逆にわからん。
エラー回避処理って、んな入れ込んで作れる程ハイレベル
な仕様で皆さん作ってるの？
>>349
CとPerlとSolarisとLinuxだろ？
C++に強いやつじゃなくて・・・。
Cにthisとかオーバライドあったっけ？
(↑ちょっと自信なし)
そうだった(恥)。
でも、基本的にDBとかファイル位だろ
CとC++でtry-catch構文使うのは
みんな、newするときにも必ずtry-catch構文使う？
try-catch構文でうんだらこうたらって言っている
感覚が逆にわからん。
エラー回避処理って、んな入れ込んで作れる程ハイレベル
な仕様で皆さん作ってるの？
>>349
CとPerlとSolarisとLinuxだろ？
C++に強いやつじゃなくて・・・。
Cにthisとかオーバライドあったっけ？
(↑ちょっと自信なし)
ところで、オーバーライドとオーバーロードって、どっちが偉いの？
C++用語がオーバーロードでJava用語がオーバーライドだっけ？
言語によって呼び名が違うだけだったかと
言語によって呼び名が違うだけだったかと
オーバーオールが一番えらい
オーバーライドは関数上書き。
オーバーロードは引数変更。
オーバーロードは引数変更。
オーバーロードのほうが偉い。
オーバーライドは下手したらタダの設計ミス
オーバーライドは下手したらタダの設計ミス
356 ：仕様書無しさん：2005/11/29(火) 21:49:54
>>356
ん？エスパってみるが、abstractならいいよ。
ん？エスパってみるが、abstractならいいよ。
>>344
> >>342
> > Tomcatを使ったサービスの開発が多い中、
> > UNIXのコマンドはいくつか知ってないとJavaを使った仕事はまずできないし。
> だから、UNIXのコマンドをいくつか知ってれば、十分でしょ？
それだけじゃ甘いよ。makeの使い方を知らないと駄目だしhostsの設定、proftpd, sshd, bind,telnetd,
iptablesの設定は知ってて当然だし。シェルスクリプトも書けないといけない。代わりにApache Antを
使う手もあるが。PostgreSQLの設定なども必要だろうし、製品によってはメールサーバ
を構築する必要もでてくる。ほかに、開発効率をたかめるためにCVS, Subversionサーバを
構築する必要も出てくる。
> だいたい、ネットワーク、データベース、セキュリティ、サーバ管理能力ってどれぐらいのレベルの事を言っているんだ？
> Javaだけをやってきた人間でBSDやSystemVに詳しい奴なんぞ一人も見た事が無い。
> 下手すれば、「BSDって何？」って言う奴さえいる。
さすがにいないな。そういうのは大学出たばかりの新人くらいだろうね。
> Javaプログラマに限った話ではないが、ネットワークには詳しいがデータベースは駄目、もしくはその逆の奴にしか俺は出会ったことが無い。
> また、セキュリティはともかく、サーバ管理能力が求められる事なんて一度として無い。
Javaを自力で習得すると、必然的にサーバ構築能力が要求される。
おれも学生時代からServletを初めて習得したときはUNIXについていろいろと学ばされた。
何度も試行錯誤を繰り返してやっとTomcatとApacheとPostgreSQLの使い方を覚えたくらいだ。
自宅でサーバを構築しServletで作ったサイトを世界に公開し発信するにはどうすればいいか
始めは何もわからなかったものだ。
> >>342
> > Tomcatを使ったサービスの開発が多い中、
> > UNIXのコマンドはいくつか知ってないとJavaを使った仕事はまずできないし。
> だから、UNIXのコマンドをいくつか知ってれば、十分でしょ？
それだけじゃ甘いよ。makeの使い方を知らないと駄目だしhostsの設定、proftpd, sshd, bind,telnetd,
iptablesの設定は知ってて当然だし。シェルスクリプトも書けないといけない。代わりにApache Antを
使う手もあるが。PostgreSQLの設定なども必要だろうし、製品によってはメールサーバ
を構築する必要もでてくる。ほかに、開発効率をたかめるためにCVS, Subversionサーバを
構築する必要も出てくる。
> だいたい、ネットワーク、データベース、セキュリティ、サーバ管理能力ってどれぐらいのレベルの事を言っているんだ？
> Javaだけをやってきた人間でBSDやSystemVに詳しい奴なんぞ一人も見た事が無い。
> 下手すれば、「BSDって何？」って言う奴さえいる。
さすがにいないな。そういうのは大学出たばかりの新人くらいだろうね。
> Javaプログラマに限った話ではないが、ネットワークには詳しいがデータベースは駄目、もしくはその逆の奴にしか俺は出会ったことが無い。
> また、セキュリティはともかく、サーバ管理能力が求められる事なんて一度として無い。
Javaを自力で習得すると、必然的にサーバ構築能力が要求される。
おれも学生時代からServletを初めて習得したときはUNIXについていろいろと学ばされた。
何度も試行錯誤を繰り返してやっとTomcatとApacheとPostgreSQLの使い方を覚えたくらいだ。
自宅でサーバを構築しServletで作ったサイトを世界に公開し発信するにはどうすればいいか
始めは何もわからなかったものだ。
> > だから「Javaは馬鹿でもできる」とか「大衆向け言語」だとか思いこむのは
> > 危険だと言ってみたんだよ。そういう誤解を生んだ結果デスマーチになったプロジェクトを
> > よくみてきたもんだ。
> デスマーチになるのはただ単にプロジェクトの見積もりが甘いからだろ？
> 半年も納期が遅れるなんて技術以前の問題だよ。
実際遅れることは多いもんだあれから4年経ったいまでも納期が3ヶ月以上はおくれることが
よくある。営業の腕が悪いからそうなってしまっているんだと言われたらそれまでだが。
360 ：仕様書無しさん：2005/11/29(火) 23:35:27
なんでJavaをC++と比較するのん？
同じ土俵に居るのはPerlとかPHPとかどとねとーでしょ？
同じ土俵に居るのはPerlとかPHPとかどとねとーでしょ？
>>345
Javaの仕事といったら大抵はServlet + RDBMS
っていう仕事があまりにも多く
デスクトップJava開発や携帯電話開発に比べ
少ないってことを言いたいだけだよ。
今じゃJBossやHibernate, Spring Frameworkのことも
知らないといけないけれどもね。
Javaの仕事といったら大抵はServlet + RDBMS
っていう仕事があまりにも多く
デスクトップJava開発や携帯電話開発に比べ
少ないってことを言いたいだけだよ。
今じゃJBossやHibernate, Spring Frameworkのことも
知らないといけないけれどもね。
>>350
> >>327
> そうだった(恥)。
まてまて、それはC++に限った話だという主張だよな？
Javaでもそうしろという話は初耳なのだが。
> でも、基本的にDBとかファイル位だろ
> CとC++でtry-catch構文使うのは
> みんな、newするときにも必ずtry-catch構文使う？
> try-catch構文でうんだらこうたらって言っている
> 感覚が逆にわからん。
> エラー回避処理って、んな入れ込んで作れる程ハイレベル
> な仕様で皆さん作ってるの？
Javaだと嫌でもtry-catchまたはthrowsを使わされる機会が多いってことだよ。
標準APIにそういうものが多いために。
> >>327
> そうだった(恥)。
まてまて、それはC++に限った話だという主張だよな？
Javaでもそうしろという話は初耳なのだが。
> でも、基本的にDBとかファイル位だろ
> CとC++でtry-catch構文使うのは
> みんな、newするときにも必ずtry-catch構文使う？
> try-catch構文でうんだらこうたらって言っている
> 感覚が逆にわからん。
> エラー回避処理って、んな入れ込んで作れる程ハイレベル
> な仕様で皆さん作ってるの？
Javaだと嫌でもtry-catchまたはthrowsを使わされる機会が多いってことだよ。
標準APIにそういうものが多いために。
>>349
> >>342に出てくる「スペシャリスト」やら「プロフェッショナル」ってのは
> 相当レベルが低い。というか、「経歴を捏造された派遣社員」に近い気がするのだが・・。
SolarisとPerl, Cに関してはかなりの使い手だが、
頭が堅く、当時古い考え方に縛られていたのでJavaを初めて使うときに
そういうところが露呈してしまったっていうところだろうか。
それでもリーダだった。体格は大柄で、プライドがかなり高かったが。
Linuxのことをけっこう馬鹿にしていたような。Solarisに慣れていたので
bashシェルが嫌いでcshを好んで使っているそうだ。しかも熱狂的vi信者。
Emacsを使いたいというと vi しか使えない環境に犯されることもあるのでEmacsは
入れない、と言っていた。マ板やUNIX板にいるvi信者に非常にそっくりだ。
あれから4年経った今だったら彼もJavaを問題なく使いこなしていることだろう。
> >>342に出てくる「スペシャリスト」やら「プロフェッショナル」ってのは
> 相当レベルが低い。というか、「経歴を捏造された派遣社員」に近い気がするのだが・・。
SolarisとPerl, Cに関してはかなりの使い手だが、
頭が堅く、当時古い考え方に縛られていたのでJavaを初めて使うときに
そういうところが露呈してしまったっていうところだろうか。
それでもリーダだった。体格は大柄で、プライドがかなり高かったが。
Linuxのことをけっこう馬鹿にしていたような。Solarisに慣れていたので
bashシェルが嫌いでcshを好んで使っているそうだ。しかも熱狂的vi信者。
Emacsを使いたいというと vi しか使えない環境に犯されることもあるのでEmacsは
入れない、と言っていた。マ板やUNIX板にいるvi信者に非常にそっくりだ。
あれから4年経った今だったら彼もJavaを問題なく使いこなしていることだろう。
業務系 Web 系：Java、COBOL、PHP、Perl、Ruby
デスクトップ系：C、C++、C#、VB
業務系同士、デスクトップ同士で比較するならまだ分かるが、
もともと主用途が違うモノ同士を比較しても、水掛け論にしかならんだろ。
デスクトップ系：C、C++、C#、VB
業務系同士、デスクトップ同士で比較するならまだ分かるが、
もともと主用途が違うモノ同士を比較しても、水掛け論にしかならんだろ。
>>360
言語仕様としてJavaはC++に非常によく似ているから。
どちらも、Perl, PHPと違ってWebに
限らずあらゆる分野で利用することができ汎用的な言語。
しかもJavaはC++を参考にして作られた言語だ。
だからよく比較対象にされる。
言語仕様としてJavaはC++に非常によく似ているから。
どちらも、Perl, PHPと違ってWebに
限らずあらゆる分野で利用することができ汎用的な言語。
しかもJavaはC++を参考にして作られた言語だ。
だからよく比較対象にされる。
WebPGならJava
それ以外ならC++
それ以外ならC++
>>366
いや、実際ほとんどWebアプリでしか使われて無いでしょ。Javaって。
携帯アプリもあるこたあるけど、ありゃJavaを愛してやまない皆さんが
見たら発狂しそうな糞ソースだよ。マジで。
それ以外の分野では皆無だし。
いや、実際ほとんどWebアプリでしか使われて無いでしょ。Javaって。
携帯アプリもあるこたあるけど、ありゃJavaを愛してやまない皆さんが
見たら発狂しそうな糞ソースだよ。マジで。
それ以外の分野では皆無だし。
C#も業務系web系で使われることもあるんだけど。
確かにJavaと比べたら非常に少ないけど。
もともとJavaに対抗するために作られた言語だし
確かにJavaと比べたら非常に少ないけど。
もともとJavaに対抗するために作られた言語だし
>>366
いくら Java の言語仕様自体が汎用的でも業務系にしか使われないんじゃなあ。
ライブラリ類もサーバサイド向けは異様に発達してるけど、その他の分野は
さっぱりだろ。
逆に C/C++ は MFC だの WTL だの VCL だの Qt だの GTK+ だのといった
デスクトップ系のライブラリは発達してるけど、サーバサイド系はさっぱり。
いくら Java の言語仕様自体が汎用的でも業務系にしか使われないんじゃなあ。
ライブラリ類もサーバサイド向けは異様に発達してるけど、その他の分野は
さっぱりだろ。
逆に C/C++ は MFC だの WTL だの VCL だの Qt だの GTK+ だのといった
デスクトップ系のライブラリは発達してるけど、サーバサイド系はさっぱり。
>>369
今のところ携帯電話ではどうしようもない
自体がまだ続いているが
容量がメガ単位まででかくなってきて前よりはましな状況に
はなってきた感がある。
デスクトップではJava SE 5 Tigerによって
Java Swing APIがさらに高速化しているので
再び息を吹き返す可能性がある。
最近Javaの統合開発環境といえばEclipseだが
NetBeansというSunが作ったIDEも少少しずつ人気を
増している。GUIアプリケーションの開発が
EclipseのVisualEditorプラグインよりも楽ということで。
さらにJava SE 6 MustangからはさらにJavaが高速化され
一度ロードしたJavaアプリケーションは
２回目以降に起動するとネイティブアプリケーションとして
機能するようになる。
ここからアプレットで昔失敗したデスクトップJavaが
再び復活するのではないかと見ている。
Swing APIもかなり進化してきてIBMが作ったEclipse
に使われているSWTよりも高速化できる点が多くなってきて
今後かなりの大きな期待ができそうだ。
今のところ携帯電話ではどうしようもない
自体がまだ続いているが
容量がメガ単位まででかくなってきて前よりはましな状況に
はなってきた感がある。
デスクトップではJava SE 5 Tigerによって
Java Swing APIがさらに高速化しているので
再び息を吹き返す可能性がある。
最近Javaの統合開発環境といえばEclipseだが
NetBeansというSunが作ったIDEも少少しずつ人気を
増している。GUIアプリケーションの開発が
EclipseのVisualEditorプラグインよりも楽ということで。
さらにJava SE 6 MustangからはさらにJavaが高速化され
一度ロードしたJavaアプリケーションは
２回目以降に起動するとネイティブアプリケーションとして
機能するようになる。
ここからアプレットで昔失敗したデスクトップJavaが
再び復活するのではないかと見ている。
Swing APIもかなり進化してきてIBMが作ったEclipse
に使われているSWTよりも高速化できる点が多くなってきて
今後かなりの大きな期待ができそうだ。
373 ：69式フリーPG ◆hND3Lufios ：2005/11/29(火) 23:57:59
Javaの売りというか特徴として、フリーのフレームワークが豊富なことが
あると思うんだけど、デスクトップ用途や携帯用途のフリーフレームワークって
聞かないなぁ。Webアプリ用はたくさんあるのに。
あると思うんだけど、デスクトップ用途や携帯用途のフリーフレームワークって
聞かないなぁ。Webアプリ用はたくさんあるのに。
>>372
Java でデスクトップアプリが云々という話は、Swing が登場したときも
1.4 で Swing が高速化されたときにもさんざん聞かされたけど、
結局未だに実現してないやん・・・。
ヨドバシカメラのパソコンソフト売場や窓の杜の掲載ソフトが Java 一色に
染まるのは一体いつになるんだろうねｗ
Java でデスクトップアプリが云々という話は、Swing が登場したときも
1.4 で Swing が高速化されたときにもさんざん聞かされたけど、
結局未だに実現してないやん・・・。
ヨドバシカメラのパソコンソフト売場や窓の杜の掲載ソフトが Java 一色に
染まるのは一体いつになるんだろうねｗ
375 ：仕様書無しさん：2005/11/30(水) 00:00:32
＞一度ロードしたJavaアプリケーションは
＞２回目以降に起動するとネイティブアプリケーションとして
＞機能するようになる
えーーーーーー。
これっていまだにそうなってないの？？？２回目以降もバイトコードを
せっせと解釈実行してるなんてあほ過ぎ。
マジで駄目じゃん。知らなかった。
＞２回目以降に起動するとネイティブアプリケーションとして
＞機能するようになる
えーーーーーー。
これっていまだにそうなってないの？？？２回目以降もバイトコードを
せっせと解釈実行してるなんてあほ過ぎ。
マジで駄目じゃん。知らなかった。
>>371
> >>366
> いくら Java の言語仕様自体が汎用的でも業務系にしか使われないんじゃなあ。
おいおい、「しか」ってなんだ。さすがに「しか」ってことはない。
> ライブラリ類もサーバサイド向けは異様に発達してるけど、その他の分野は
> さっぱりだろ。
XMLやネットワーク関連は確かに充実しているが、
デスクトップ用ではSwing APIは発達しているし
JFreeChartというグラフ生成も発達しているし
ひそかに進化してきている。
たしかにC++とくらべたらまだまだだが。Java SE 6 Mustangの動きが気になって。
デスクトップ開発に必要な部品などが進化しているようだ。
高速化もしているし。
> >>366
> いくら Java の言語仕様自体が汎用的でも業務系にしか使われないんじゃなあ。
おいおい、「しか」ってなんだ。さすがに「しか」ってことはない。
> ライブラリ類もサーバサイド向けは異様に発達してるけど、その他の分野は
> さっぱりだろ。
XMLやネットワーク関連は確かに充実しているが、
デスクトップ用ではSwing APIは発達しているし
JFreeChartというグラフ生成も発達しているし
ひそかに進化してきている。
たしかにC++とくらべたらまだまだだが。Java SE 6 Mustangの動きが気になって。
デスクトップ開発に必要な部品などが進化しているようだ。
高速化もしているし。
WebPGとDocomo用ゲームプログラマーならJava
それ以外ならC++
それ以外ならC++
>>374
> >>372
> Java でデスクトップアプリが云々という話は、Swing が登場したときも
> 1.4 で Swing が高速化されたときにもさんざん聞かされたけど、
> 結局未だに実現してないやん・・・。
実現していない？ 確かにマシンスペックは2GHz以上、メモリ512MG以上
という前提が大きいがTigerで作られたSwingアプリはかなりはやい。
Javaとは思えない。
>
> ヨドバシカメラのパソコンソフト売場や窓の杜の掲載ソフトが Java 一色に
> 染まるのは一体いつになるんだろうねｗ
まず今、そういうスタンドアロンアプリの売上げは昔と比べ低迷しているよ。
インターネットがあるんだからそれに遭わせたアプリを使った方が安くて
かつ便利なわけで、そりゃスタンドアロンアプリの売上げは低迷するわけだ。
そんななかでわざわざいまさらスタンドアロンアプリを有償で店頭に並べて
販売することに拘ることはまだ必要ないとおもう。
大抵Javaで作られたソフトはタダで配布する形式がまだまだ主流になるだろう。
リッチクライアント製品として。デスクトップアプリはブラウザよりも
使いやすく、サーバに負担をかけない補助的なツールに過ぎず、実際
にはあくまでサーバアプリがメインであると。
> >>372
> Java でデスクトップアプリが云々という話は、Swing が登場したときも
> 1.4 で Swing が高速化されたときにもさんざん聞かされたけど、
> 結局未だに実現してないやん・・・。
実現していない？ 確かにマシンスペックは2GHz以上、メモリ512MG以上
という前提が大きいがTigerで作られたSwingアプリはかなりはやい。
Javaとは思えない。
>
> ヨドバシカメラのパソコンソフト売場や窓の杜の掲載ソフトが Java 一色に
> 染まるのは一体いつになるんだろうねｗ
まず今、そういうスタンドアロンアプリの売上げは昔と比べ低迷しているよ。
インターネットがあるんだからそれに遭わせたアプリを使った方が安くて
かつ便利なわけで、そりゃスタンドアロンアプリの売上げは低迷するわけだ。
そんななかでわざわざいまさらスタンドアロンアプリを有償で店頭に並べて
販売することに拘ることはまだ必要ないとおもう。
大抵Javaで作られたソフトはタダで配布する形式がまだまだ主流になるだろう。
リッチクライアント製品として。デスクトップアプリはブラウザよりも
使いやすく、サーバに負担をかけない補助的なツールに過ぎず、実際
にはあくまでサーバアプリがメインであると。
379 ：仕様書無しさん：2005/11/30(水) 00:07:47
そういえば、Java版の一太郎とかなかったっけ？
>>375
セキュリティ上の問題があったから
それをどういう仕様で解決するかを考えないと
同じアプリでも他のOSとは挙動が異なったり
動かなかったりしてJavaの特性を生かせなくなるという
問題が懸念されていたため即座にはやらなかったんだと思う。
この機能はおそらくC#のPreJITのパクリだと思う。
セキュリティ上の問題があったから
それをどういう仕様で解決するかを考えないと
同じアプリでも他のOSとは挙動が異なったり
動かなかったりしてJavaの特性を生かせなくなるという
問題が懸念されていたため即座にはやらなかったんだと思う。
この機能はおそらくC#のPreJITのパクリだと思う。
C#/VBはインストール時にネィティブ変換出来るのだが・・・
>>378 みたいな香具師がデスクトップアプリを設計すると FSK みたいなのが
出来上がったりするのかな・・・。
だいたいﾌｫﾄｼｮとかﾜｰﾄﾞｴｸｾﾙとか、そこでやる作業自体はネットワークと
たいして関係ないやん。
作業してるデータの内容によってはネットワークに垂れ流したくない場合も
あるし。
出来上がったりするのかな・・・。
だいたいﾌｫﾄｼｮとかﾜｰﾄﾞｴｸｾﾙとか、そこでやる作業自体はネットワークと
たいして関係ないやん。
作業してるデータの内容によってはネットワークに垂れ流したくない場合も
あるし。
ある意味、非常にマ板っぽいスレだなw
>>372
>一度ロードしたJavaアプリケーションは
>２回目以降に起動するとネイティブアプリケーションとして
>機能するようになる。
これは、機能することが可能ということか？
それともそうなってしまうってことか？
弊害が多くて萎えそうだな。Javaも終わりか。
しかもJavaで構築したアプリの"2回目移行の実行"をJVMがどうやって
判断するんだよ。
それとも何か？クラスローダの挙動のことを言ってる？
2回目のクラスのロードは判断可能と思うけど、ネイティブになる＝JVMと等価なレベル
になるんだよね。矛盾してないか？そもそもJavaってVMがなけりゃただのアホだろ。
>一度ロードしたJavaアプリケーションは
>２回目以降に起動するとネイティブアプリケーションとして
>機能するようになる。
これは、機能することが可能ということか？
それともそうなってしまうってことか？
弊害が多くて萎えそうだな。Javaも終わりか。
しかもJavaで構築したアプリの"2回目移行の実行"をJVMがどうやって
判断するんだよ。
それとも何か？クラスローダの挙動のことを言ってる？
2回目のクラスのロードは判断可能と思うけど、ネイティブになる＝JVMと等価なレベル
になるんだよね。矛盾してないか？そもそもJavaってVMがなけりゃただのアホだろ。
GUI系はだめでしょ。
AWTやらSwingやらSWTやその他、C++ネイティブアプリなら
話題にも上らないような当然の機能ですら、
形態を変えながら何度も実装して・・。
せめて本当にWrite Once, Run Anywhereを実現してくれるなら
救いようもあるのだが。
逆にロジックに集中したいときは、C++のように余計な事を
考えなくてすむから、適していると言えるかも。
AWTやらSwingやらSWTやその他、C++ネイティブアプリなら
話題にも上らないような当然の機能ですら、
形態を変えながら何度も実装して・・。
せめて本当にWrite Once, Run Anywhereを実現してくれるなら
救いようもあるのだが。
逆にロジックに集中したいときは、C++のように余計な事を
考えなくてすむから、適していると言えるかも。
>まてまて、それはC++に限った話だという主張だよな？
>Javaでもそうしろという話は初耳なのだが。
そうです。
Javaは学生時代に２，３時間触った位です。
でもJavaScriptは普通にテストツールとして使っています。
>Javaだと嫌でもtry-catchまたはthrowsを使わされる機会が多いってことだよ。
>標準APIにそういうものが多いために。
だとしたら、上の方の論争は意味が無いのでは？
極端な話try-catchを使わないでも組めるC++と使う機会が多い
Javaではtry-catchを語るべき土俵が違うのでは？
Java批判になってしまいますが、try-catchって結局はGoto文であり、
その否定から始まった構造化プログラミングでそれを多用するのは
いかがなものかと、機能が多くて使いでがあるのは良いことですが・・・。
>Javaでもそうしろという話は初耳なのだが。
そうです。
Javaは学生時代に２，３時間触った位です。
でもJavaScriptは普通にテストツールとして使っています。
>Javaだと嫌でもtry-catchまたはthrowsを使わされる機会が多いってことだよ。
>標準APIにそういうものが多いために。
だとしたら、上の方の論争は意味が無いのでは？
極端な話try-catchを使わないでも組めるC++と使う機会が多い
Javaではtry-catchを語るべき土俵が違うのでは？
Java批判になってしまいますが、try-catchって結局はGoto文であり、
その否定から始まった構造化プログラミングでそれを多用するのは
いかがなものかと、機能が多くて使いでがあるのは良いことですが・・・。
>try-catchって結局はGoto文
・・・本当にそうかな？
・・・本当にそうかな？
>>385
> GUI系はだめでしょ。
> AWTやらSwingやらSWTやその他、C++ネイティブアプリなら
> 話題にも上らないような当然の機能ですら、
> 形態を変えながら何度も実装して・・。
まてまてJava周りのGUIのことをよくわかってないな。
SWTはIBMが作ったもので部分的にネイティブに依存する。
以前はAWTやSwingより早いと言われたが
今ではJava SE 5 Tigerの登場により、動作によっては
SWTのほうがSwingより重たくなることもある。
TigerからSwingも随分と進化してきたし。
それからSwingはAWTから形式を変えながらなんども
実装しているのではない。SwingはAWTに依存しているのだ。
AWTに存在していたいくつかのクラスはそれらのクラス名に
Jがついたクラスとして実装できる。
> せめて本当にWrite Once, Run Anywhereを実現してくれるなら
100%それを確実に求めるにはハードウェアメーカーやOSメーカーの
努力も必要。すくなくともC++よりは開発効率が高いことは確実。
> GUI系はだめでしょ。
> AWTやらSwingやらSWTやその他、C++ネイティブアプリなら
> 話題にも上らないような当然の機能ですら、
> 形態を変えながら何度も実装して・・。
まてまてJava周りのGUIのことをよくわかってないな。
SWTはIBMが作ったもので部分的にネイティブに依存する。
以前はAWTやSwingより早いと言われたが
今ではJava SE 5 Tigerの登場により、動作によっては
SWTのほうがSwingより重たくなることもある。
TigerからSwingも随分と進化してきたし。
それからSwingはAWTから形式を変えながらなんども
実装しているのではない。SwingはAWTに依存しているのだ。
AWTに存在していたいくつかのクラスはそれらのクラス名に
Jがついたクラスとして実装できる。
> せめて本当にWrite Once, Run Anywhereを実現してくれるなら
100%それを確実に求めるにはハードウェアメーカーやOSメーカーの
努力も必要。すくなくともC++よりは開発効率が高いことは確実。
>>386
> >まてまて、それはC++に限った話だという主張だよな？
> >Javaでもそうしろという話は初耳なのだが。
> そうです。
> Javaは学生時代に２，３時間触った位です。
> でもJavaScriptは普通にテストツールとして使っています。
JavaのこともJavaScriptのこともろくにわかってないな。
いきなりJavaScriptのことを話題に挙げるということは、
JavaとJavaScriptとの違いをろくにわかってないのではなかろうか。
> >まてまて、それはC++に限った話だという主張だよな？
> >Javaでもそうしろという話は初耳なのだが。
> そうです。
> Javaは学生時代に２，３時間触った位です。
> でもJavaScriptは普通にテストツールとして使っています。
JavaのこともJavaScriptのこともろくにわかってないな。
いきなりJavaScriptのことを話題に挙げるということは、
JavaとJavaScriptとの違いをろくにわかってないのではなかろうか。
> >Javaだと嫌でもtry-catchまたはthrowsを使わされる機会が多いってことだよ。
> >標準APIにそういうものが多いために。
> だとしたら、上の方の論争は意味が無いのでは？
> 極端な話try-catchを使わないでも組めるC++と使う機会が多い
> Javaではtry-catchを語るべき土俵が違うのでは？
C++はJavaでは守るべき原則を守らなくてもプログラミングできてしまうから
バグを生み出しやすい、という点では議論する意味もなくもない。
> Java批判になってしまいますが、try-catchって結局はGoto文であり、
> その否定から始まった構造化プログラミングでそれを多用するのは
> いかがなものかと、機能が多くて使いでがあるのは良いことですが・・・。
やっぱり例外処理のことをよく解ってないな。goto文のように機能するが
昔よく語られていた、構造化手法を発案したダイクストラが指摘した
goto文による弊害は起きない。
従来のgoto文の使い方が悪であって、try-catchがgoto文のように機能するといっても
ダイクストラが否定したがるようなことは起きないように設計されている。
しかもC++では未だにgoto文が使える。Javaではそれを制限し、ラベル付きbreak, continue
文のみでしか使えないようにしている。
goto==悪とタダ単純に考えるのではなく、goto文の使い方が悪いのだ。
だがJavaでは悪い使い方ができないように設計されているから君が心配してるようなことはおきない。
君は目的と手段との違いをよく考えたほうがいい。
>C++はJavaでは守るべき原則を守らなくてもプログラミングできてしまうから
>バグを生み出しやすい、という点では議論する意味もなくもない。
Javaの守るべき原則って聞く限りでは言語仕様よかエンジンの欠点を
取り繕うのが多いと思うんですが、結局言語仕様に問題ががあるC++と
逆なだけだと思うんですが？いかがでしょうか？
>昔よく語られていた、構造化手法を発案したダイクストラが指摘した
>goto文による弊害は起きない。
なんで弊害が起きないのか教えていただけませんか？
別の所から飛んで来るだけ十分可読性が落ちると思うのですが、
それが個人的に一番大きな問題だと認識しているのですか？
>バグを生み出しやすい、という点では議論する意味もなくもない。
Javaの守るべき原則って聞く限りでは言語仕様よかエンジンの欠点を
取り繕うのが多いと思うんですが、結局言語仕様に問題ががあるC++と
逆なだけだと思うんですが？いかがでしょうか？
>昔よく語られていた、構造化手法を発案したダイクストラが指摘した
>goto文による弊害は起きない。
なんで弊害が起きないのか教えていただけませんか？
別の所から飛んで来るだけ十分可読性が落ちると思うのですが、
それが個人的に一番大きな問題だと認識しているのですか？
>>393
Javaに限らずノウハウはどの言語にもあるよ。
Javaは簡素な言語仕様で大規模多人数開発を常とするから、特に明文化された
ノウハウが多いというだけ。
OODの原則なんかは別にJava専用じゃないし、これは文字通りオブジェクト指向
設計の原則だから、当然C++も含まれる。
ただC++はその使われ方に幅がある(このスレではC++をC＋αとして使う事に否
定的な雰囲気があるけど、別に目的を達成できればそれをどう使おうと問題じゃ
ない)から、Javaほど必須だ厳守だと騒ぎ立てる人が居ないというだけ。
Javaに限らずノウハウはどの言語にもあるよ。
Javaは簡素な言語仕様で大規模多人数開発を常とするから、特に明文化された
ノウハウが多いというだけ。
OODの原則なんかは別にJava専用じゃないし、これは文字通りオブジェクト指向
設計の原則だから、当然C++も含まれる。
ただC++はその使われ方に幅がある(このスレではC++をC＋αとして使う事に否
定的な雰囲気があるけど、別に目的を達成できればそれをどう使おうと問題じゃ
ない)から、Javaほど必須だ厳守だと騒ぎ立てる人が居ないというだけ。
Javaは既にVBの変わりとしても有用だから鯖ばかりというわけではない
業務系という意味では壷にはまりまくった言語だな
C++はめんどいからいらん。
業務系という意味では壷にはまりまくった言語だな
C++はめんどいからいらん。
C++ は意図的に選択肢を多くしてあるからな。
オブジェクト指向プログラミングをするのもジェネリックプログラミングをするのも
ただの better C として使うのもプログラマの自由。
とにかく特定の決まりごとを押しつけるというのが、ビャーネたんは
大嫌いみたい。D&E にはくどいくらい書いてあるｗ
オブジェクト指向プログラミングをするのもジェネリックプログラミングをするのも
ただの better C として使うのもプログラマの自由。
とにかく特定の決まりごとを押しつけるというのが、ビャーネたんは
大嫌いみたい。D&E にはくどいくらい書いてあるｗ
>>396
Pythonなんて触ったら発狂しそうだな
Pythonなんて触ったら発狂しそうだな
Javaのシンプルなのは言語仕様だけで、周辺がでかいんだよな。
ライブラリの覚えやすさはダントツだと思うよ
C++ってドキュメントで損してる感がある。
C++ってドキュメントで損してる感がある。
うーん。フレームワークがね。。。。
C++ もオプソ系は最近は Doxygen が普及してきたけどな。
MS のライブラリに代表されるプロプラ系のドキュメントは、基本的にカネを
出してオンラインドキュメントを購読するか本を買うかするのが主流だけど。
あと、言語仕様の確認とかも基本的には K&R 本 や Stroustrap 本を
買って読むのがメインだな。
MS のライブラリに代表されるプロプラ系のドキュメントは、基本的にカネを
出してオンラインドキュメントを購読するか本を買うかするのが主流だけど。
あと、言語仕様の確認とかも基本的には K&R 本 や Stroustrap 本を
買って読むのがメインだな。
＞基本的にカネを出してオンラインドキュメントを購読するか
MSDNって金が要るの？
MSDNって金が要るの？
明確にどの本を買えばいいのか分かってるからいいんだよ。
ネットから拾ってこないといけないってのは、貧民にはありがたいかもしれないかも
しれないが、忙しい身としてはめんどくせ。
ネットから拾ってこないといけないってのは、貧民にはありがたいかもしれないかも
しれないが、忙しい身としてはめんどくせ。
>>402
MS のサイトでも見れるけど、購読もできる。
購読すると専用のツールでオフラインで見れるし、開発環境や OS、ツール類も
付属してくる（つか、最近はこっち目当ての香具師が多いみたいだけど）。
MS のサイトでも見れるけど、購読もできる。
購読すると専用のツールでオフラインで見れるし、開発環境や OS、ツール類も
付属してくる（つか、最近はこっち目当ての香具師が多いみたいだけど）。
>>403
Javaのフレームワークはサンプルで使い方覚えたら
あとはほとんど必ず付属するJava共通のAPIヘルプでライブラリの詳細が分かるから無料でいい。
Javaそのもののために最初に一冊なんか買う位でいいのでは？
Javaのフレームワークはサンプルで使い方覚えたら
あとはほとんど必ず付属するJava共通のAPIヘルプでライブラリの詳細が分かるから無料でいい。
Javaそのもののために最初に一冊なんか買う位でいいのでは？
つーか、Win環境下で純粋にC++だけで書くヤシってどれ位いる？
VC6.0だとMFCでスケルトンだけ貰って、STLとATLで外枠つくって
中身の関数は概ねAPIで書いてるんだが・・・。
C++といえるのはクラス作ってる時だけだなあと思っちまう。
お前らODBC接続をAPIで書いた事ありますか？
VC6.0だとMFCでスケルトンだけ貰って、STLとATLで外枠つくって
中身の関数は概ねAPIで書いてるんだが・・・。
C++といえるのはクラス作ってる時だけだなあと思っちまう。
お前らODBC接続をAPIで書いた事ありますか？
407 ：仕様書無しさん：2005/12/01(木) 19:15:23
C++/CLI >>>>>>> 超えられない壁 >>>>>>>>> Java
Javaがデスクトップ方面に強くなくても、
今のところ食っていけるから別にいいよ。
デスクトップ方面の方は当分趣味で触るだけで十分だ漏れは。
今のところ食っていけるから別にいいよ。
デスクトップ方面の方は当分趣味で触るだけで十分だ漏れは。
>>410
>Java だって標準 API
無知さらすようで悪いが、それってWin32Apiとかじゃないよね。
ネイティブアプリで言うApiとJavaは違うと思うんだけど・・・
(.Netは比較対象に入れるとややこしくなるのでパス)
>Java だって標準 API
無知さらすようで悪いが、それってWin32Apiとかじゃないよね。
ネイティブアプリで言うApiとJavaは違うと思うんだけど・・・
(.Netは比較対象に入れるとややこしくなるのでパス)
>>411
C/C++ で言うところの標準ライブラリのことを Java では API と呼んでいる。
（C/C++ では MFC その他で提供されるような機能も含んでたりするけど）
http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/overview-summary.html
C/C++ で言うところの標準ライブラリのことを Java では API と呼んでいる。
（C/C++ では MFC その他で提供されるような機能も含んでたりするけど）
http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/overview-summary.html
>>412
つーかそれを“API”っていうこと事態がおかしくね？
まあ、解釈の違いなんだろけど。
でも、自分の解釈ではネイティブ系の開発環境でAPIを直接叩くのって、
Javaでの標準API使うのと全然別の意味合いがあると思うんだが。
つーかそれを“API”っていうこと事態がおかしくね？
まあ、解釈の違いなんだろけど。
でも、自分の解釈ではネイティブ系の開発環境でAPIを直接叩くのって、
Javaでの標準API使うのと全然別の意味合いがあると思うんだが。
Application を Programming するための Interface なら、レイヤーの深さはどうであれ
API でいいと思うよ。
むしろ OS の機能を直接呼び出すための関数群はシステムコールと呼んだ方が
しっくりくる・・・。もともとサンマイクロも UNIX 作ってる会社だしね。
API でいいと思うよ。
むしろ OS の機能を直接呼び出すための関数群はシステムコールと呼んだ方が
しっくりくる・・・。もともとサンマイクロも UNIX 作ってる会社だしね。
414はいい先輩になれそうだな。
415はいい後輩になれそうだな。
>>414
オイラの先輩になってください。
オイラの先輩になってください。
でもこないだJDBCでバグがあったんだよな・・・それもソラリスで・・・。
パッチ当ててようやくまともに動いたYO
パッチ当ててようやくまともに動いたYO
オイラの兄貴になってください。
>>405
オイラの奴隷となってオイラに教えろ
オイラの奴隷となってオイラに教えろ
JAVAって遅いかな？
コマンドプロンプトでゲーム作ったけどほぼ一瞬で流れるよ
コンパイルは遅かったけど
コマンドプロンプトでゲーム作ったけどほぼ一瞬で流れるよ
コンパイルは遅かったけど
>>421
コマンドプロンプトでコマンド名を打って Enter 押して、それから一瞬間が
あるだろ。Java 製アプリの場合はもっさりと起動する感じ。
C 製アプリとかだとそれがないんだよな。Enter を押した瞬間に起動して、
単純なものならそれこそミリ秒単位の時間で終了する。
たとえば make と ant とを比べるとそんなことを感じる。
コマンドプロンプトでコマンド名を打って Enter 押して、それから一瞬間が
あるだろ。Java 製アプリの場合はもっさりと起動する感じ。
C 製アプリとかだとそれがないんだよな。Enter を押した瞬間に起動して、
単純なものならそれこそミリ秒単位の時間で終了する。
たとえば make と ant とを比べるとそんなことを感じる。
遅いよ。
携帯の貧弱VMのゲームやって、
702NKのSymbianOSネイティブアプリのゲームやると
その差を愕然と感じたよ。
例えるなら、ファミコンベーシックで作ったゲームとPSPくらいに違ったよ。
携帯の貧弱VMのゲームやって、
702NKのSymbianOSネイティブアプリのゲームやると
その差を愕然と感じたよ。
例えるなら、ファミコンベーシックで作ったゲームとPSPくらいに違ったよ。
>>423
年がばれるぞｗｗ
年がばれるぞｗｗ
425 ：仕様書無しさん：2005/12/04(日) 01:01:07
426 ：仕様書無しさん：2005/12/04(日) 01:06:54
>>393
> >C++はJavaでは守るべき原則を守らなくてもプログラミングできてしまうから
> >バグを生み出しやすい、という点では議論する意味もなくもない。
>
> Javaの守るべき原則って聞く限りでは言語仕様よかエンジンの欠点を
> 取り繕うのが多いと思うんですが、結局言語仕様に問題ががあるC++と
> 逆なだけだと思うんですが？いかがでしょうか？
ちょいと違うな。ロバート・Ｃ・マーティンの「アジャイルソフトウェア開発の奥義」
を読んでみるといいかな。
> >昔よく語られていた、構造化手法を発案したダイクストラが指摘した
> >goto文による弊害は起きない。
>
> なんで弊害が起きないのか教えていただけませんか？
> 別の所から飛んで来るだけ十分可読性が落ちると思うのですが、
> それが個人的に一番大きな問題だと認識しているのですか？
C++のgoto文は飛ぶ場所がわかりにくい。
Javaのtry-catchやラベル付きcontinue, breakは
飛ぶ場所がはっきりとわかっており利用ヶ所も限定されていて
continue, breakの場合はfor, while文の外側に出る以外に飛ぶところがない。
try-catchの場合はcatchかfinallyのところか、そのあとにしか飛ばないことが
はっきりわかっている。どっからどこへ飛んでゆくのかはっきりと分かる点が違う。
しかも可読性はほとんど落ちない。可読性が落ちるようなラベル付きbreak, continueの
使い方、try-catchの使い方なんて滅多にできないし、熟練してくると
可読性が落ちるようなコードを自然に書かなくて済むようになってくる。
そもそもcatch文やfinally文の中が膨大なばかでかさに
なることなんてあると思うかね？
実際にJavaでプログラミングしてみれば例外処理がgotoのようであっても問題ないことがよくわかるぞ。
> >C++はJavaでは守るべき原則を守らなくてもプログラミングできてしまうから
> >バグを生み出しやすい、という点では議論する意味もなくもない。
>
> Javaの守るべき原則って聞く限りでは言語仕様よかエンジンの欠点を
> 取り繕うのが多いと思うんですが、結局言語仕様に問題ががあるC++と
> 逆なだけだと思うんですが？いかがでしょうか？
ちょいと違うな。ロバート・Ｃ・マーティンの「アジャイルソフトウェア開発の奥義」
を読んでみるといいかな。
> >昔よく語られていた、構造化手法を発案したダイクストラが指摘した
> >goto文による弊害は起きない。
>
> なんで弊害が起きないのか教えていただけませんか？
> 別の所から飛んで来るだけ十分可読性が落ちると思うのですが、
> それが個人的に一番大きな問題だと認識しているのですか？
C++のgoto文は飛ぶ場所がわかりにくい。
Javaのtry-catchやラベル付きcontinue, breakは
飛ぶ場所がはっきりとわかっており利用ヶ所も限定されていて
continue, breakの場合はfor, while文の外側に出る以外に飛ぶところがない。
try-catchの場合はcatchかfinallyのところか、そのあとにしか飛ばないことが
はっきりわかっている。どっからどこへ飛んでゆくのかはっきりと分かる点が違う。
しかも可読性はほとんど落ちない。可読性が落ちるようなラベル付きbreak, continueの
使い方、try-catchの使い方なんて滅多にできないし、熟練してくると
可読性が落ちるようなコードを自然に書かなくて済むようになってくる。
そもそもcatch文やfinally文の中が膨大なばかでかさに
なることなんてあると思うかね？
実際にJavaでプログラミングしてみれば例外処理がgotoのようであっても問題ないことがよくわかるぞ。
427 ：仕様書無しさん：2005/12/04(日) 01:09:23
>>401
> C++ もオプソ系は最近は Doxygen が普及してきたけどな。
>
> MS のライブラリに代表されるプロプラ系のドキュメントは、基本的にカネを
> 出してオンラインドキュメントを購読するか本を買うかするのが主流だけど。
>
> あと、言語仕様の確認とかも基本的には K&R 本 や Stroustrap 本を
> 買って読むのがメインだな。
そこがオープンソースの考え方に反するところだな。
だからC++の人気が下がってしまったんだと思うのだ。
> C++ もオプソ系は最近は Doxygen が普及してきたけどな。
>
> MS のライブラリに代表されるプロプラ系のドキュメントは、基本的にカネを
> 出してオンラインドキュメントを購読するか本を買うかするのが主流だけど。
>
> あと、言語仕様の確認とかも基本的には K&R 本 や Stroustrap 本を
> 買って読むのがメインだな。
そこがオープンソースの考え方に反するところだな。
だからC++の人気が下がってしまったんだと思うのだ。
>425
簡単なデスクトップアプリさくっと作るなら、
今だってVBとかVBAでしょ。
業務のPGだけ淡々とやってればイイなら必要無いけど
職場の業務効率を良くするためのツールとか作る必要があるのでね。
それをJAVAで作ろうなんて、効率悪すぎてやる気になりませんが何か・・・
簡単なデスクトップアプリさくっと作るなら、
今だってVBとかVBAでしょ。
業務のPGだけ淡々とやってればイイなら必要無いけど
職場の業務効率を良くするためのツールとか作る必要があるのでね。
それをJAVAで作ろうなんて、効率悪すぎてやる気になりませんが何か・・・
NetBeansは既にVBに追い付いてるしなぁ。
後は言語やライブラリのパワーが行かせるから作りやすい。
後は言語やライブラリのパワーが行かせるから作りやすい。
Java6.0からはECMAScriptも標準実装されるから
マクロ対応アプリも作れるようになる。
ものさえ出されたら後はVBAが勝つかJavaScriptが勝つかって感じだな。
手ごろな標的としてAccessあたりが狙われると思う。
マクロ対応アプリも作れるようになる。
ものさえ出されたら後はVBAが勝つかJavaScriptが勝つかって感じだな。
手ごろな標的としてAccessあたりが狙われると思う。
可能かどうかなんか誰も聞いてねえったの。アフォだなJava厨は。
実際に使われてるかどうかの話だろ。
実際に使われてるかどうかの話だろ。
使われてるっての。アフォだないつも。
433 ：仕様書無しさん：2005/12/04(日) 03:33:25
業務系アプリで世界中で使われまくってますが何か？
VBなんか過去の遺物、汚物。
VBなんか過去の遺物、汚物。
Java厨はVBAも使いこなせませんw
>>427
ネットだけで全部すますのもよいが、ノウハウ系に関しては Java だって
Effectiveなんちゃら系みたいに本でしか読めないやつとかあるだろ。
そのへんは Java も C/C++ もどっこいどっこいだよ。
あと言語仕様くらいは本買ってやれｗ
あとオプソといえば、Linux やら GNU ツールやら Apache やら、実際に
世界中の人々に広く活用されているものは、むしろ C/C++ が幅を
きかせてるんだけどなあ。
ネットだけで全部すますのもよいが、ノウハウ系に関しては Java だって
Effectiveなんちゃら系みたいに本でしか読めないやつとかあるだろ。
そのへんは Java も C/C++ もどっこいどっこいだよ。
あと言語仕様くらいは本買ってやれｗ
あとオプソといえば、Linux やら GNU ツールやら Apache やら、実際に
世界中の人々に広く活用されているものは、むしろ C/C++ が幅を
きかせてるんだけどなあ。
436 ：仕様書無しさん：2005/12/04(日) 11:41:18
ほんとにJAVA厨は消えてほちいね
実際にとか言って既成事実化させようとしてるよｗ
腹痛ぇーーーｗｗｗ
腹痛ぇーーーｗｗｗ
>435
うちのサーバーは、.netなんですが何か・・・
うちのサーバーは、.netなんですが何か・・・
>430
あの〜 ExcelとかAccessとかWindowsアプリなのですが、
それを無理やりJAVAで実現されても嬉しくも何とも無いと感じるのですが何か・・・。
あの〜 ExcelとかAccessとかWindowsアプリなのですが、
それを無理やりJAVAで実現されても嬉しくも何とも無いと感じるのですが何か・・・。
440 ：仕様書無しさん：2005/12/04(日) 13:01:01
Java厨にとっては、無料であることが最重要で、ソフトも書籍も彼等に買わせることはできない。
憐れなのはSunである。
憐れなのはSunである。
>>430
> Java6.0からはECMAScriptも標準実装されるから
> マクロ対応アプリも作れるようになる。
その表現はかなり大きな誤解を生んで
アンチJava厨が鬼の首を取ったように喜びそうだな。
標準実装なんて大嘘だし。
ただECMAScriptファイルの読み込みや
Stringリテラル内でECMAScriptコードを書けるようになっただけなんだけどね。
> Java6.0からはECMAScriptも標準実装されるから
> マクロ対応アプリも作れるようになる。
その表現はかなり大きな誤解を生んで
アンチJava厨が鬼の首を取ったように喜びそうだな。
標準実装なんて大嘘だし。
ただECMAScriptファイルの読み込みや
Stringリテラル内でECMAScriptコードを書けるようになっただけなんだけどね。
442 ：仕様書無しさん：2005/12/04(日) 13:06:58
>>434
VBAすらも使いこなせないのはC言語厨のほうだろw
VBAすらも使いこなせないのはC言語厨のほうだろw
>>435
> >>427
> ネットだけで全部すますのもよいが、ノウハウ系に関しては Java だって
> Effectiveなんちゃら系みたいに本でしか読めないやつとかあるだろ。
> そのへんは Java も C/C++ もどっこいどっこいだよ。
> あと言語仕様くらいは本買ってやれｗ
何の言語仕様の何の本を買ってやれって？
言ってる意味がわからないな。ちゃんと日本語しゃべれよC言語厨。
M$製品買わないと何もできないお前はM$製品に依存しているという点で、
VB厨と同類だよ。
> あとオプソといえば、Linux やら GNU ツールやら Apache やら、実際に
> 世界中の人々に広く活用されているものは、むしろ C/C++ が幅を
> きかせてるんだけどなあ。
Cしかできない癖にC++マンセーしてる厨はオープンソース製品なんて
ろくに使いこなせずM$製品やWin32 APIやMFCなどごちゃごちゃAPIにすがりついているんだがな。
最近ではApacheプロジェクトはほとんどJava系だしな。
GNUもJava関係が増えてきている。オープンソースソフトウェアを直接開発
したことも無い癖にC/C++が幅をきかせているなんていっても
まったく説得力がないんだがなあ。
> >>427
> ネットだけで全部すますのもよいが、ノウハウ系に関しては Java だって
> Effectiveなんちゃら系みたいに本でしか読めないやつとかあるだろ。
> そのへんは Java も C/C++ もどっこいどっこいだよ。
> あと言語仕様くらいは本買ってやれｗ
何の言語仕様の何の本を買ってやれって？
言ってる意味がわからないな。ちゃんと日本語しゃべれよC言語厨。
M$製品買わないと何もできないお前はM$製品に依存しているという点で、
VB厨と同類だよ。
> あとオプソといえば、Linux やら GNU ツールやら Apache やら、実際に
> 世界中の人々に広く活用されているものは、むしろ C/C++ が幅を
> きかせてるんだけどなあ。
Cしかできない癖にC++マンセーしてる厨はオープンソース製品なんて
ろくに使いこなせずM$製品やWin32 APIやMFCなどごちゃごちゃAPIにすがりついているんだがな。
最近ではApacheプロジェクトはほとんどJava系だしな。
GNUもJava関係が増えてきている。オープンソースソフトウェアを直接開発
したことも無い癖にC/C++が幅をきかせているなんていっても
まったく説得力がないんだがなあ。
446 ：仕様書無しさん：2005/12/04(日) 13:14:07
まあJavaの方が習得が簡単なので↑みたいな馬鹿を含む割合が高いのは事実かな。
447 ：仕様書無しさん：2005/12/04(日) 13:16:25
とにかくJava厨に何を言っても無駄なのは
むかちからずっとおなじ
むかちからずっとおなじ
>>439
ExcelやWord？ それだけか
リッチクライアントアプリケーションを作りたいとは
一度も思ったことはないのかね？
それから、拡張性あるアプリケーション。
プラグインフレームワークを使ってな。
それ以外にもまだ作れるものはいくらでもあるだろう。
OpenOffice対応アプリに期待したいところだな。
ExcelやWord？ それだけか
リッチクライアントアプリケーションを作りたいとは
一度も思ったことはないのかね？
それから、拡張性あるアプリケーション。
プラグインフレームワークを使ってな。
それ以外にもまだ作れるものはいくらでもあるだろう。
OpenOffice対応アプリに期待したいところだな。
449 ：仕様書無しさん：2005/12/04(日) 13:18:38
そういや Sun が中心となって作ってる OOo の一部に Java コードが
含まれただけで非難囂々だったのは皮肉なもんだ。
含まれただけで非難囂々だったのは皮肉なもんだ。
>>447
それはC言語厨も同類。
いやそれ以上。頭が堅く20年前の思考でとまってるからね。
ああいうのをまさに ★『化石』★ というんだよね
C言語厨は30代以降のオッサン世代が多いからそういう思考になってしまうんだろうね。
それはC言語厨も同類。
いやそれ以上。頭が堅く20年前の思考でとまってるからね。
ああいうのをまさに ★『化石』★ というんだよね
C言語厨は30代以降のオッサン世代が多いからそういう思考になってしまうんだろうね。
PDAにもJavaScriptが埋め込める時代だしJavaはやはり目の付け所が違うな
金になるとこを考えてバージョンアップしている
金になるとこを考えてバージョンアップしている
>>440
> Java厨にとっては、無料であることが最重要で、ソフトも書籍も彼等に買わせることはできない。
周りのJavaエンジニアはみんな買ってるんだけど。
Java厨より給料が安いのが多いC言語厨はもっと買わせる余裕すらなさそうだね。
> 憐れなのはSunである。
SunとJavaとの関係はもう段々薄くなっているよ。
特にSunとJava開発者との関係なんか。
> Java厨にとっては、無料であることが最重要で、ソフトも書籍も彼等に買わせることはできない。
周りのJavaエンジニアはみんな買ってるんだけど。
Java厨より給料が安いのが多いC言語厨はもっと買わせる余裕すらなさそうだね。
> 憐れなのはSunである。
SunとJavaとの関係はもう段々薄くなっているよ。
特にSunとJava開発者との関係なんか。
454 ：仕様書無しさん：2005/12/04(日) 13:23:59
>>446
> まあJavaの方が習得が簡単なので↑みたいな馬鹿を含む割合が高いのは事実かな。
その「↑」ってのは>>445のことだと？
意味がわからないな。妄想かね。
CよりJavaのほうが習得が簡単だなんて大嘘。
このスレを>>1から全部読み返してみなよ。
現実がよくわかるぜ。
習得が簡単なのは最初だけで途中から徐々に難易度があがってく。
とくに大規模開発では覚えるべきこと、理解すべき事が多い。
サーバサイド、データベース、ネットワーク、セキュリティ分野となると
もはやC言語厨には太刀打ちできまい。
ゆえにJava熟練者の割合は少ない
> まあJavaの方が習得が簡単なので↑みたいな馬鹿を含む割合が高いのは事実かな。
その「↑」ってのは>>445のことだと？
意味がわからないな。妄想かね。
CよりJavaのほうが習得が簡単だなんて大嘘。
このスレを>>1から全部読み返してみなよ。
現実がよくわかるぜ。
習得が簡単なのは最初だけで途中から徐々に難易度があがってく。
とくに大規模開発では覚えるべきこと、理解すべき事が多い。
サーバサイド、データベース、ネットワーク、セキュリティ分野となると
もはやC言語厨には太刀打ちできまい。
ゆえにJava熟練者の割合は少ない
>>446
馬鹿はお前だよ
馬鹿はお前だよ
>>455
あのC言語厨の馬鹿発言はどうみても釣りだろ
あのC言語厨の馬鹿発言はどうみても釣りだろ
ECMAScript≒JavaScriptだろ、無知過ぎる奴の相手は疲れるな(´д｀)
やっぱさ、Ｃ言語厨は頑固オヤジばかりで馬鹿だよ
どのスレみても馬鹿頑固オヤジばっかだ
どのスレみても馬鹿頑固オヤジばっかだ
俺はJava厨でC厨なんだが・・・
C++だけだろ未来が無いのは
C++だけだろ未来が無いのは
465 ：仕様書無しさん：2005/12/04(日) 13:30:37
JavaとJavaScriptとの違いも未だにわからない馬鹿もいるけど
VBScriptとJScriptとJavaScriptとECMAScriptとの違いも解らない
馬鹿はもっと重傷だな。
このスレに約一名いるわけだが。Cなんとか厨とかいう
VBScriptとJScriptとJavaScriptとECMAScriptとの違いも解らない
馬鹿はもっと重傷だな。
このスレに約一名いるわけだが。Cなんとか厨とかいう
>>463
GNU製JVM使えるようにすれば問題ないって感じで
利用者には堂でもいい話だな。
大半の開発者にとてもどうでもいいことだしな。
ＪＶＭの切り替えさえできれば問題なしと。
ＧＮＵだってJava製APIを作って公開しているんだし
GNU製JVM使えるようにすれば問題ないって感じで
利用者には堂でもいい話だな。
大半の開発者にとてもどうでもいいことだしな。
ＪＶＭの切り替えさえできれば問題なしと。
ＧＮＵだってJava製APIを作って公開しているんだし
>>463
相変わらずストールマンは偉そうな態度だなｗ
相変わらずストールマンは偉そうな態度だなｗ
Java厨は使ったことも無い言語を伝聞だけで批判するから笑えるw
デスクトップの業務アプリを本気でJavaだけで組みたいらしいww
デスクトップの業務アプリを本気でJavaだけで組みたいらしいww
C++って超本気アプリのときにしか使わないだろ
大手ソフト会社の基幹商品で使われるくらいだ
大手ソフト会社の基幹商品で使われるくらいだ
大手ソフト会社の本気アプリ＝C++
中小ソフト会社のやっつけアプリ＝Java
中小ソフト会社のやっつけアプリ＝Java
473 ：仕様書無しさん：2005/12/04(日) 15:50:04
C++の方が先がある。
JavaオンリーだとJavaの範囲内でしか物事を考えられなくなる。
その点、C++ならばメモリの問題から細かい低レベルな挙動まで
抑えてないと正しく実装できない。
今後のプログラマ人生を考えると、C++を覚えてた方が良い。
Javaを5,6年やった後にC++を覚えるのは苦痛でしかない。
年齢にして30歳くらいだぞ。頭がついていかない。
逆だとスムーズに移行できる。
JavaオンリーだとJavaの範囲内でしか物事を考えられなくなる。
その点、C++ならばメモリの問題から細かい低レベルな挙動まで
抑えてないと正しく実装できない。
今後のプログラマ人生を考えると、C++を覚えてた方が良い。
Javaを5,6年やった後にC++を覚えるのは苦痛でしかない。
年齢にして30歳くらいだぞ。頭がついていかない。
逆だとスムーズに移行できる。
C++はいずれD言語に食われるかも知れんからなんとも。
1.0が登場してそれが有償じゃなかったらかなりの部分で食われるね。
言語の食わず嫌いをしない俺が言うんだから間違いない。
1.0が登場してそれが有償じゃなかったらかなりの部分で食われるね。
言語の食わず嫌いをしない俺が言うんだから間違いない。
475 ：仕様書無しさん：2005/12/04(日) 15:56:38
＞C++はいずれD言語に食われるかも知れんからなんとも
寝言はとりあえずVer1.0が出てからいえや。
寝言はとりあえずVer1.0が出てからいえや。
>>473
>その点、C++ならばメモリの問題から細かい低レベルな挙動まで
>抑えてないと正しく実装できない。
JavaだってWebアプリ用のデータ詰め替えしかやってない低脳ゴミコード
ではなくて、いっぱしのものを作ろうと思えば、VMの挙動だの実行時の
メモリ配置だの低レベルを理解する必要あるんだけどな。
>その点、C++ならばメモリの問題から細かい低レベルな挙動まで
>抑えてないと正しく実装できない。
JavaだってWebアプリ用のデータ詰め替えしかやってない低脳ゴミコード
ではなくて、いっぱしのものを作ろうと思えば、VMの挙動だの実行時の
メモリ配置だの低レベルを理解する必要あるんだけどな。
今のところJAVAはWEBアプリと携帯アプリだけだろ？
実用的なのは・・・。
WEBアプリなら、PHPの方が手軽だし、携帯アプリなんて
たいしたマーケットじゃないし・・・。
無線LAN受信型の携帯PDAが飛躍的に拡大するとしたらスカイプだろうけど
それが普及する頃には、JAVAアプリなんて余計なお世話なアプリという認識になるのが
目に見えて分かる。
実用的なのは・・・。
WEBアプリなら、PHPの方が手軽だし、携帯アプリなんて
たいしたマーケットじゃないし・・・。
無線LAN受信型の携帯PDAが飛躍的に拡大するとしたらスカイプだろうけど
それが普及する頃には、JAVAアプリなんて余計なお世話なアプリという認識になるのが
目に見えて分かる。
478 ：仕様書無しさん：2005/12/04(日) 19:54:36
479 ：仕様書無しさん：2005/12/04(日) 21:58:44
480 ：仕様書無しさん：2005/12/04(日) 22:01:40
>>435
C++が幅をきかせてるとは思えん…
C++が幅をきかせてるとは思えん…
483 ：仕様書無しさん：2005/12/04(日) 22:16:44
飯食ってうんこするのは容易いこと。
でも、うんこを肛門に戻したところで飯にはならん。
C++とJavaの関係ってそんなところだろ。
でも、うんこを肛門に戻したところで飯にはならん。
C++とJavaの関係ってそんなところだろ。
484 ：仕様書無しさん：2005/12/04(日) 22:46:54
>>483
全然意味わからんｗｗｗ
全然意味わからんｗｗｗ
不可逆だ、と？
なんで、汚い物に例えるのか理解できない。
そんなもんに例えなきゃいけない理由があるのか？
そんなもんに例えなきゃいけない理由があるのか？
場を和ませる発言に、なんで真面目にレスするのか理解できない。
そんなに真面目にレスしなきゃいけない理由があるのか？
そんなに真面目にレスしなきゃいけない理由があるのか？
う〜んjavaに一票と行きたいけど。優劣付けがたい…。
言語仕様がC++から昇華されたJavaがあるんだから
いまさらC++なんて使おうと思う奴はうんこってことだろ
いまさらC++なんて使おうと思う奴はうんこってことだろ
つまりJava開発者はうんこと。
つまりお前はうんこと。
お前はしっこだ。
おれはめくそ
494 ：仕様書無しさん：2005/12/05(月) 19:46:54
言語には将来があるかも知れない。
使ってる奴らに将来など無い。マジだ。
使ってる奴らに将来など無い。マジだ。
ぶっちゃけ、言うと双方未来がなくて双方とも後継言語
Java++（仮）とかC++++（仮）に将来性がある。
つーか、ネイティブ言語の需要は絶対無くならんし。
Javaの潮流は今更止まらんだろう。
Java++（仮）とかC++++（仮）に将来性がある。
つーか、ネイティブ言語の需要は絶対無くならんし。
Javaの潮流は今更止まらんだろう。
496 ：仕様書無しさん：2005/12/07(水) 02:13:57
人類を守るセキュリティ対策のためにC言語厨/C++厨に対し、 ！警告！
●プリプロセッサを使用禁止しろ！
●定数は必ずconstで押さえろ！
●不変クラスにする必要があるものはできるかぎり不変クラスにしろ！
●実装メソッドがあるクラスの多重継承を禁止しろ！
●グローバル変数、グローバル関数を使用禁止にしろ！
●構造体、共用体の使用を禁止しろ！
●関数ポインタの使用を禁止しろ！
●演算子オーバーロードを使うな！
●typedef使用禁止！
●もしこれらの鉄則を遵守しなければC++厨もC言語厨も
このソフトウェア業界から出て行け！！！！！！！！！！！！！！！！
！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
さもなければ、氏ねｪｪｪｪｪｪｪｪｪｪｪｪｪｪｪｪーーーーーーーーーーーーーーーーーーーーーーーーィ！！！！！
ﾌﾞｼｭｯ！ ｸﾞｻﾞｧｯ! ｸﾞｳｫｧ！(聖なる裁きにより、C言語厨、C++厨が斬り刻まれる効果音)
「うぐぁぁぁぁ！だずげでぐれぇぇぇぇ！がぁぁぁ！…ぐぶっ………」(C言語厨、C++厨が死ぬ直前に発する最後の断末魔)
●プリプロセッサを使用禁止しろ！
●定数は必ずconstで押さえろ！
●不変クラスにする必要があるものはできるかぎり不変クラスにしろ！
●実装メソッドがあるクラスの多重継承を禁止しろ！
●グローバル変数、グローバル関数を使用禁止にしろ！
●構造体、共用体の使用を禁止しろ！
●関数ポインタの使用を禁止しろ！
●演算子オーバーロードを使うな！
●typedef使用禁止！
●もしこれらの鉄則を遵守しなければC++厨もC言語厨も
このソフトウェア業界から出て行け！！！！！！！！！！！！！！！！
！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
さもなければ、氏ねｪｪｪｪｪｪｪｪｪｪｪｪｪｪｪｪーーーーーーーーーーーーーーーーーーーーーーーーィ！！！！！
ﾌﾞｼｭｯ！ ｸﾞｻﾞｧｯ! ｸﾞｳｫｧ！(聖なる裁きにより、C言語厨、C++厨が斬り刻まれる効果音)
「うぐぁぁぁぁ！だずげでぐれぇぇぇぇ！がぁぁぁ！…ぐぶっ………」(C言語厨、C++厨が死ぬ直前に発する最後の断末魔)
●構造体、共用体の使用を禁止しろ
●関数ポインタの使用を禁止しろ！
●typedef使用禁止！
ここらへんが意味分からん。
単なる素敵機能じゃないか。
●関数ポインタの使用を禁止しろ！
●typedef使用禁止！
ここらへんが意味分からん。
単なる素敵機能じゃないか。
標準ライブラリ禁止?
499 ：仕様書無しさん：2005/12/07(水) 20:14:19
例えて言うなら、足し算しか分からない小学生が、掛け算使ったら僕が分からないじゃないか。
そんな誰にも理解されないような計算するなぁぁぁあ！！！！
って言ってるようなもんでよ
そんな誰にも理解されないような計算するなぁぁぁあ！！！！
って言ってるようなもんでよ
>●プリプロセッサを使用禁止しろ！
>●演算子オーバーロードを使うな！
えー便利だおー。
他のも初心者には必須じゃないか。
>●演算子オーバーロードを使うな！
えー便利だおー。
他のも初心者には必須じゃないか。
501 ：仕様書無しさん：2005/12/07(水) 20:22:31
Javaにも#ifdefが欲しい。
5.0で@ifdefとかアノテーション付ければよかったのに。
5.0で@ifdefとかアノテーション付ければよかったのに。
502 ：仕様書無しさん：2005/12/07(水) 21:30:27
Javaは馬鹿用の言語としては良く出来てる。
503 ：仕様書無しさん：2005/12/07(水) 21:33:07
>496
つまり結局、Javaを使えって事ですね。
つまり結局、Javaを使えって事ですね。
おれはプリプロセッサには反対だな
#ifdefを駆使するのは構わんがマクロ化するのはダメだと思う。
標準のものはよしとするけど
#ifdefを駆使するのは構わんがマクロ化するのはダメだと思う。
標準のものはよしとするけど
506 ：仕様書無しさん：2005/12/08(木) 07:56:35
507 ：仕様書無しさん：2005/12/08(木) 08:25:19
サーバサイドならJavaだな。
SQLに気をつければ、「HP-UX+ORACLE」って構成から「Linux+Postgres」って構成まで、
ほとんどソースを変えずに出来るんだぞ。これはすごい事だよ。
顧客の予算に合わせて提案しやすくなるんだ。
SQLに気をつければ、「HP-UX+ORACLE」って構成から「Linux+Postgres」って構成まで、
ほとんどソースを変えずに出来るんだぞ。これはすごい事だよ。
顧客の予算に合わせて提案しやすくなるんだ。
508 ：仕様書無しさん：2005/12/08(木) 12:46:16
顧客から言わせてもらえば
もう少しレスポンスよくならんのか？
もう少しレスポンスよくならんのか？
ざっとでは、
サーバサイドでWEB＋DBとかのいわゆるWEBアプリとかならJava
パッケージのツールとかゲームとかならC++
ってところか
同じ「オブジェクト指向」でもそういうふうにすみわけされてる。
根本的には、速度どうこうもあるけど
それ以上にNativeなところたたくかたたかないかっていうところが
あるんで、結局両方やれ。
Javaやってても結局C++やりたくなるぞ。
サーバサイドでWEB＋DBとかのいわゆるWEBアプリとかならJava
パッケージのツールとかゲームとかならC++
ってところか
同じ「オブジェクト指向」でもそういうふうにすみわけされてる。
根本的には、速度どうこうもあるけど
それ以上にNativeなところたたくかたたかないかっていうところが
あるんで、結局両方やれ。
Javaやってても結局C++やりたくなるぞ。
510 ：仕様書無しさん：2005/12/08(木) 17:10:57
javaはＣ＋＋のサブセットじゃん。悩む余地あるのか？
>>508
貴様の出した金ではその性能が限界だ！
貴様の出した金ではその性能が限界だ！
>>510
会話に参加する前に、最低限どっちか一方でもやっとけ。
会話に参加する前に、最低限どっちか一方でもやっとけ。
513 ：仕様書無しさん：2005/12/08(木) 18:00:59
組み込みにもjavaが使われはじめてるぞ！
もともと家電用につくらるた言語だから、やっとって感じだが
intent乗せればメモリも気にしなくて平気だし・・・いろいろ問題がないわけでもないが
もともと家電用につくらるた言語だから、やっとって感じだが
intent乗せればメモリも気にしなくて平気だし・・・いろいろ問題がないわけでもないが
514 ：仕様書無しさん：2005/12/08(木) 18:45:50
TRON協会の最新の調査報告書によれば
ttp://www.assoc.tron.org/jpn/research/index.html
組み込みシステムに使用したプログラミング言語のうち
Java言語は2%だそうです
この数字を多いと見るか少ないと見るかは意見の分かれるところと思われるが
おそらくこの2%のほとんどが、ケータイ開発がらみと思われ
ttp://www.assoc.tron.org/jpn/research/index.html
組み込みシステムに使用したプログラミング言語のうち
Java言語は2%だそうです
この数字を多いと見るか少ないと見るかは意見の分かれるところと思われるが
おそらくこの2%のほとんどが、ケータイ開発がらみと思われ
515 ：仕様書無しさん：2005/12/08(木) 21:39:38
やっとIDにc+が・・
516 ：仕様書無しさん：2005/12/08(木) 22:28:31
>>471-472
Javaでやっつけでやってもろくなもんがつくれないわだが。
それにJavaは大抵大手企業で使われているのだが。
C++のほうは過去の遺産があるから仕方が無く
使っていると言うだけで。
しかも今C++の仕事は少ない。
いくら超本気だといっても開発コストが無駄にかさんでしまっては本末転倒。
スパゲティコードを簡単に生成できてしまう言語には限界というものがあるわけだよ。
しかも大手ソフト会社の基幹商品で使われるのはC++よりもJavaのほうが多い。
C++は今となっては現代のアセンブラに過ぎないのだよ。
Javaでやっつけでやってもろくなもんがつくれないわだが。
それにJavaは大抵大手企業で使われているのだが。
C++のほうは過去の遺産があるから仕方が無く
使っていると言うだけで。
しかも今C++の仕事は少ない。
いくら超本気だといっても開発コストが無駄にかさんでしまっては本末転倒。
スパゲティコードを簡単に生成できてしまう言語には限界というものがあるわけだよ。
しかも大手ソフト会社の基幹商品で使われるのはC++よりもJavaのほうが多い。
C++は今となっては現代のアセンブラに過ぎないのだよ。
517 ：仕様書無しさん：2005/12/08(木) 22:42:00
うーんとJavaってぶっちゃけ乗せると資源倍以上食うよね。組み込みだと
Java乗せたものが、あとで完全放棄してネイティブに帰った例も山ほどある。
携帯電話は特殊例だし、ネットとDB絡まないものなら重いだけで扱い困るんじゃね？
Java乗せたものが、あとで完全放棄してネイティブに帰った例も山ほどある。
携帯電話は特殊例だし、ネットとDB絡まないものなら重いだけで扱い困るんじゃね？
Googleは検索エンジンがC++
Googleメールなどの外部サービスがJava
超本気の場合はどうしたってC++になる
Googleメールなどの外部サービスがJava
超本気の場合はどうしたってC++になる
>>516
C++しかサポートされていない場合どうすればよいのでしょうか？
A○○○○〜。矜持あるのは分かったからいい加減M○と手打ちしてくれ。
M○もそっちは本位じゃないしコスト掛かるんだから、受け入れてやれよ〜。
C++しかサポートされていない場合どうすればよいのでしょうか？
A○○○○〜。矜持あるのは分かったからいい加減M○と手打ちしてくれ。
M○もそっちは本位じゃないしコスト掛かるんだから、受け入れてやれよ〜。
>>514
まだまだメモリ容量の限界があるから少ないってのがありそうだな。
その2%という数値は携帯電話などの小型の組み込み機器は
電池がすぐになくなってしまうから仕方がなく少ないメモリに
しなければならない理由からJavaが使いにくい、だからその小型の
組み込み機器ではJavaの需要が少ないのではないかと見た。
しかし大型の組み込み機器、小型でもすぐ充電可能な組み込み機器、
小型でも常にACアダプタなどで電源を供給できる組み込み機器ならば
大容量メモリによって電池がすぐになくなってしまう心配も少ない。
まだまだメモリ容量の限界があるから少ないってのがありそうだな。
その2%という数値は携帯電話などの小型の組み込み機器は
電池がすぐになくなってしまうから仕方がなく少ないメモリに
しなければならない理由からJavaが使いにくい、だからその小型の
組み込み機器ではJavaの需要が少ないのではないかと見た。
しかし大型の組み込み機器、小型でもすぐ充電可能な組み込み機器、
小型でも常にACアダプタなどで電源を供給できる組み込み機器ならば
大容量メモリによって電池がすぐになくなってしまう心配も少ない。
>>519
> >>516
> C++しかサポートされていない場合どうすればよいのでしょうか？
どういう会社？
JNIやJavaのRuntimeクラスなど使ってJavaと連携してみたら？
> A○○○○〜。矜持あるのは分かったからいい加減M○と手打ちしてくれ。
どこの団体だ？伏せ字が多すぎて想像できないな。
> M○もそっちは本位じゃないしコスト掛かるんだから、受け入れてやれよ〜。
M$くらいいちいち伏せ字にしなくてもいいだろ。
> >>516
> C++しかサポートされていない場合どうすればよいのでしょうか？
どういう会社？
JNIやJavaのRuntimeクラスなど使ってJavaと連携してみたら？
> A○○○○〜。矜持あるのは分かったからいい加減M○と手打ちしてくれ。
どこの団体だ？伏せ字が多すぎて想像できないな。
> M○もそっちは本位じゃないしコスト掛かるんだから、受け入れてやれよ〜。
M$くらいいちいち伏せ字にしなくてもいいだろ。
組み込みではまだJavaきついだろー。
今後増えていきそうな気はするがそれまで俺生きてる気がしねえや。
デスマ続きで死にそう。
今後増えていきそうな気はするがそれまで俺生きてる気がしねえや。
デスマ続きで死にそう。
>>518
> Googleは検索エンジンがC++
> Googleメールなどの外部サービスがJava
> 超本気の場合はどうしたってC++になる
Googleの一例を例にあげたからといって
「超本気」の場合はどうしたってC++になるというのは
おかしな話だな。
速度やリソース節約が本気になっただじゃないのか？
> Googleは検索エンジンがC++
> Googleメールなどの外部サービスがJava
> 超本気の場合はどうしたってC++になる
Googleの一例を例にあげたからといって
「超本気」の場合はどうしたってC++になるというのは
おかしな話だな。
速度やリソース節約が本気になっただじゃないのか？
525 ：仕様書無しさん：2005/12/08(木) 23:18:53
組み込み機器でJavaを普及させるには
専用APIでJava SE 5 Tigerのすべてを使えること、
組み込み機器のメモリは100MBあって当たり前
でないといけない。
専用APIでJava SE 5 Tigerのすべてを使えること、
組み込み機器のメモリは100MBあって当たり前
でないといけない。
数億のJava案件だが、ソースの質は3流だぞ。
大規模すぎるってのもあるが、それにしちゃ異常だ。
大規模すぎるってのもあるが、それにしちゃ異常だ。
>>509
そんなとき
Javaのキーワード、nativeをつかって
速度に不満があるところだけ
JNIを使ってみるがよろしいかと。
と、いうが、その前に、
Javaでもパフォーマンスを揚げられる方法はあるぞ。
無駄なロジックを書いてないか？
Javaが遅いからC++にすると言う前に
『Effective Java』やIBMのDeveloper Worksを読んでパフォーマンスを
上げる方法を勉強したか？
ますそういった情報を調べてからC++に手を出した方が良い。
下手にC++に依存しすぎるとデバッグが大変だ。
そんなとき
Javaのキーワード、nativeをつかって
速度に不満があるところだけ
JNIを使ってみるがよろしいかと。
と、いうが、その前に、
Javaでもパフォーマンスを揚げられる方法はあるぞ。
無駄なロジックを書いてないか？
Javaが遅いからC++にすると言う前に
『Effective Java』やIBMのDeveloper Worksを読んでパフォーマンスを
上げる方法を勉強したか？
ますそういった情報を調べてからC++に手を出した方が良い。
下手にC++に依存しすぎるとデバッグが大変だ。
>>526
3流なのはそこの案件を引き受けた会社の馬鹿が
3流スパゲティコードしかかけないだけで
Java自体が三流ってことはない。
大規模開発にはそれなりに経験がいるし、
Javaでやったらソースの質が三流だったからといって
じゃ、C++でやれば一流二流になるか？
って話だ。Javaで(もC++でも)三流ソースしか
書けない奴はC++で(もJavaでも)書いても三流ソースしか書けない。
『アジャイルソフトウェア開発の奥義』や『EffectiveJava』『Javaの格言』
『Javaの鉄則』『Javaの落とし穴』といった本を
読んで実践すれば三流ソースになる可能性は非常に低い。
それはC++にも同じようなことがいえる。
3流なのはそこの案件を引き受けた会社の馬鹿が
3流スパゲティコードしかかけないだけで
Java自体が三流ってことはない。
大規模開発にはそれなりに経験がいるし、
Javaでやったらソースの質が三流だったからといって
じゃ、C++でやれば一流二流になるか？
って話だ。Javaで(もC++でも)三流ソースしか
書けない奴はC++で(もJavaでも)書いても三流ソースしか書けない。
『アジャイルソフトウェア開発の奥義』や『EffectiveJava』『Javaの格言』
『Javaの鉄則』『Javaの落とし穴』といった本を
読んで実践すれば三流ソースになる可能性は非常に低い。
それはC++にも同じようなことがいえる。
>>527
C++でパフォーマンス稼げてるんなら、わざわざJavaでやる必要ないじゃんｗ
C++でパフォーマンス稼げてるんなら、わざわざJavaでやる必要ないじゃんｗ
>>517
今Javaは重たくないぞ。
資源を食うのはCPU資源ではなく
リソース資源だけだ。
メモリさえ512MB程度積んでいれば
どってことはない。
ハードディスクは大容量すぎて問題ないし
あとは電力供給だ。だからこそ燃料電池だ。
燃料電池が一般化すれば携帯電話に
ハードディスクを搭載できる。
ハードディスクを搭載できるほどの電池パワーがあれば
もうJ2MEは不要(厳密には不要とはいえないものがある)で
J2SEの機能、APIを携帯電話でフルに使えるときがやってくるだろう。
今Javaは重たくないぞ。
資源を食うのはCPU資源ではなく
リソース資源だけだ。
メモリさえ512MB程度積んでいれば
どってことはない。
ハードディスクは大容量すぎて問題ないし
あとは電力供給だ。だからこそ燃料電池だ。
燃料電池が一般化すれば携帯電話に
ハードディスクを搭載できる。
ハードディスクを搭載できるほどの電池パワーがあれば
もうJ2MEは不要(厳密には不要とはいえないものがある)で
J2SEの機能、APIを携帯電話でフルに使えるときがやってくるだろう。
ゲーム作るならC++。もはや疑う余地なし。
>>497
構造体はクラスがあれば不要。
むしろ構造体はカプセル化ができず、
型安全性が保証されないので使うべきではない。
共用体で一つのメモリ領域に複数の型やenum型を持たせること
はポリモーフィズムで代用できる。
むしろそんなことにために共用体は使うべきではない。
これも型安全性が保証されないほか、
一つのメモリ領域に複数の型をもたせたいなら
JavaではInteger.valueOf()や
Integer,toHexString()などを使って解決できる。
またenum型で切り替えるために使いたければ
ポリモーフィズムでサブクラスを繰り替えればいい。
typedefは要らない。これも演算子オーバーロードと
同じく副作用が大きい。Javaではラッパークラスや継承、interfaceを
使うことでtypedefの代わりの役目を果たすことができる。
構造体はクラスがあれば不要。
むしろ構造体はカプセル化ができず、
型安全性が保証されないので使うべきではない。
共用体で一つのメモリ領域に複数の型やenum型を持たせること
はポリモーフィズムで代用できる。
むしろそんなことにために共用体は使うべきではない。
これも型安全性が保証されないほか、
一つのメモリ領域に複数の型をもたせたいなら
JavaではInteger.valueOf()や
Integer,toHexString()などを使って解決できる。
またenum型で切り替えるために使いたければ
ポリモーフィズムでサブクラスを繰り替えればいい。
typedefは要らない。これも演算子オーバーロードと
同じく副作用が大きい。Javaではラッパークラスや継承、interfaceを
使うことでtypedefの代わりの役目を果たすことができる。
534 ：仕様書無しさん：2005/12/08(木) 23:42:34
>>500
初心者には必須というだけで
演算子オーバロードは使わない方がいい。
ちゃんとルールを定めないと酷い目に遭う。
というかすで多くのプロジェクトが過去に何度も
酷い目にあっている。
チーム間どうしで勝手な演算子の定義を
したので同じ演算子でもプログラムが違うと
まったく異なる演算をしてしまい、とんでもないことになるわけだ。
しかも演算子の優先順位もバラバラになるし混乱の元だよ。
そのプロジェクトはもう徹夜だよ。デスマ。
初心者には必須というだけで
演算子オーバロードは使わない方がいい。
ちゃんとルールを定めないと酷い目に遭う。
というかすで多くのプロジェクトが過去に何度も
酷い目にあっている。
チーム間どうしで勝手な演算子の定義を
したので同じ演算子でもプログラムが違うと
まったく異なる演算をしてしまい、とんでもないことになるわけだ。
しかも演算子の優先順位もバラバラになるし混乱の元だよ。
そのプロジェクトはもう徹夜だよ。デスマ。
>>532
BREWだったらな。
複雑な機能をもつアクションゲームとかもな。
ちょっとしたシミュレーションゲームや
懐かしのレトロゲームを移植するんだったらJavaでも
問題なし。っていうか昔のゲームがJavaAppletや携帯Javaに
移植されたっていうものは数多くある。
BREWだったらな。
複雑な機能をもつアクションゲームとかもな。
ちょっとしたシミュレーションゲームや
懐かしのレトロゲームを移植するんだったらJavaでも
問題なし。っていうか昔のゲームがJavaAppletや携帯Javaに
移植されたっていうものは数多くある。
>>499
それはどうかな。
上の例は、
そろばんはできるが計算機の使い方が解らない小学生(C++側)が
コンピュータ(Javaのリフレクション、EJB)使ったら僕が分からないじゃないか。
そんな誰にも理解されないような装置使うなぁぁぁあ！！！！
って言ってるようなもんでよ
それはどうかな。
上の例は、
そろばんはできるが計算機の使い方が解らない小学生(C++側)が
コンピュータ(Javaのリフレクション、EJB)使ったら僕が分からないじゃないか。
そんな誰にも理解されないような装置使うなぁぁぁあ！！！！
って言ってるようなもんでよ
>>509
今速度の問題だけでJavaよりもC++を選択
するというのは現実解ではなくなった。
Java SE 5 Tigerの登場により
Javaは十分高速化し、C++との速度差もきにしなくてよくなった。
今Javaが抱えている問題は速度ではなく、
このスレでも散々言われているように、組み込み機器の
メモリ容量が小さすぎること。これに尽きる。
これが解決できればJavaも問題なく使うことができ
そのときこそ、JavaがC++の代わりとしての役目を
ほとんど果たしてしまうことになるだろう。
今速度の問題だけでJavaよりもC++を選択
するというのは現実解ではなくなった。
Java SE 5 Tigerの登場により
Javaは十分高速化し、C++との速度差もきにしなくてよくなった。
今Javaが抱えている問題は速度ではなく、
このスレでも散々言われているように、組み込み機器の
メモリ容量が小さすぎること。これに尽きる。
これが解決できればJavaも問題なく使うことができ
そのときこそ、JavaがC++の代わりとしての役目を
ほとんど果たしてしまうことになるだろう。
ポリモフィズムが共用体の変わり？？？
意味が分からない。詳しく。
意味が分からない。詳しく。
>>470
このスレの先頭のほうや、他のC系Java系スレでは
JavaをろくにしらないのにJavaをやたらと批判して
知ったかぶりだったと悟られて墓穴を掘ってるC厨を
よくみかけるのだが。語尾にwwwとかたくさんつけた奴が。
このスレの先頭のほうや、他のC系Java系スレでは
JavaをろくにしらないのにJavaをやたらと批判して
知ったかぶりだったと悟られて墓穴を掘ってるC厨を
よくみかけるのだが。語尾にwwwとかたくさんつけた奴が。
>>526
数億の案件になると実装レベルではピンからキリまでの複数社が
絡むから当たり前。
寧ろそういう状況でも完成まで漕ぎ着けるという辺りにJavaが利用
されてる理由がある。
C++で同じ規模のものを書こうとすると途方もないコストが掛かる。
Googleの検索エンジンが云々とは図らずもよい対比になってる。
数億の案件になると実装レベルではピンからキリまでの複数社が
絡むから当たり前。
寧ろそういう状況でも完成まで漕ぎ着けるという辺りにJavaが利用
されてる理由がある。
C++で同じ規模のものを書こうとすると途方もないコストが掛かる。
Googleの検索エンジンが云々とは図らずもよい対比になってる。
>>473
> C++の方が先がある。
> JavaオンリーだとJavaの範囲内でしか物事を考えられなくなる。
それはおまいだけじゃないのか？
っていうかJavaオンリーなんてありえねえよ。
おまいはC++オンリーなんだろうがな。
Javaを極めた奴はJava以外の分野にも詳しくなってる。
> その点、C++ならばメモリの問題から細かい低レベルな挙動まで
Javaでもメモリ管理はできるぞ。番地指定ができないだけで
メモリを節約したり解放するテクニックはあるぞ。たたnullをポイント
するという単純なものとかじゃないぜ。staticをうまく使ったり
直列化したりSoftReferenceでガベコレにかかりやすくしたりとな。
>>473
> 抑えてないと正しく実装できない。
> 今後のプログラマ人生を考えると、C++を覚えてた方が良い。
> Javaを5,6年やった後にC++を覚えるのは苦痛でしかない。
そうでもないな。大抵CをやってからJavaをやる者が多いので
苦痛も少ない。JavaをやってからC++ではなく代わりにCをやると
かなり苦痛だというのはよくわかるがw
> 年齢にして30歳くらいだぞ。頭がついていかない。
おれみたいに学生時代からやってるなら30にはならんな。
> 逆だとスムーズに移行できる。
そうとも言い切れなかったりするんだな。
周りにいるC++厨やC言語厨を見ていると
「いまさらJavaはやりたくない、覚えるのが面倒くさい」
「(実装の)多重継承ができないのがなじまない」
という香具師が多い。これ本当。大抵、MFCやWin32APIを
無駄に一生懸命覚えてしまった結果起きた弊害なのだろうが。
ほかにも、C++とは考え方がことなる点やすぐコンパイルエラーがでる点
で慣れないというのが彼らにはあるようだ。
> 抑えてないと正しく実装できない。
> 今後のプログラマ人生を考えると、C++を覚えてた方が良い。
> Javaを5,6年やった後にC++を覚えるのは苦痛でしかない。
そうでもないな。大抵CをやってからJavaをやる者が多いので
苦痛も少ない。JavaをやってからC++ではなく代わりにCをやると
かなり苦痛だというのはよくわかるがw
> 年齢にして30歳くらいだぞ。頭がついていかない。
おれみたいに学生時代からやってるなら30にはならんな。
> 逆だとスムーズに移行できる。
そうとも言い切れなかったりするんだな。
周りにいるC++厨やC言語厨を見ていると
「いまさらJavaはやりたくない、覚えるのが面倒くさい」
「(実装の)多重継承ができないのがなじまない」
という香具師が多い。これ本当。大抵、MFCやWin32APIを
無駄に一生懸命覚えてしまった結果起きた弊害なのだろうが。
ほかにも、C++とは考え方がことなる点やすぐコンパイルエラーがでる点
で慣れないというのが彼らにはあるようだ。
>>539
Effective Javaを読めばわかる。
Effective Javaを読めばわかる。
共用体っていうかタグ付き共用体が
ポリモーフィズムっていうか
クラス階層で置き換えられるってことだろ
ポリモーフィズムっていうか
クラス階層で置き換えられるってことだろ
>>530
>リソース資源だけだ。
ゆえにWinXPだと怖いわけだが、Win2000以前だとなんてことない
プログラムがXPだと落ちまくる。落ちた理由は簡単で、ファイルやDB
接続のハンドルとかののリソース部分が原因で、結局NT時代から５年間
ほったらかした所をODBCAPIレベルで手いれる羽目にになった。
リソース資源確保・解放部分でWindowsXPになって
から問題おきてネエか？C++・Javaに限らず。
そもそも、ハンドル解放しようとして落ちるのって何事よ。
>リソース資源だけだ。
ゆえにWinXPだと怖いわけだが、Win2000以前だとなんてことない
プログラムがXPだと落ちまくる。落ちた理由は簡単で、ファイルやDB
接続のハンドルとかののリソース部分が原因で、結局NT時代から５年間
ほったらかした所をODBCAPIレベルで手いれる羽目にになった。
リソース資源確保・解放部分でWindowsXPになって
から問題おきてネエか？C++・Javaに限らず。
そもそも、ハンドル解放しようとして落ちるのって何事よ。
共用体云々はモアパワーモアメモリーを前提にしてるって事を
省略するから噛み合わないんじゃないかな？
基本的にトレードオフの世界だから、何かを得れば何かを失う。
ただ、現在のPC上ではモアパワーモアメモリーを要求する方
がコスト的に安いという話の流れでしょ？
そして、これが組込になると関係が逆転するから、今のところ
Javaの利用範囲が制限されてると、そんな感じ？
省略するから噛み合わないんじゃないかな？
基本的にトレードオフの世界だから、何かを得れば何かを失う。
ただ、現在のPC上ではモアパワーモアメモリーを要求する方
がコスト的に安いという話の流れでしょ？
そして、これが組込になると関係が逆転するから、今のところ
Javaの利用範囲が制限されてると、そんな感じ？
Javaであるバッチ処理が糞重くて、JNIにする？って話が出ている。
>>514
言われてみればケータイとサーバーサイド以外でのJavaの採用は殆ど聞かないな
言われてみればケータイとサーバーサイド以外でのJavaの採用は殆ど聞かないな
551 ：仕様書無しさん：2005/12/09(金) 01:21:40
Ｃ＋＋とＪａｖａならＪａｖａ。
なぜなら、Ｊａｖａは方向性はそのままに進化し続けるが、Ｃ＋＋はＣ＃に見られるように、非常にＪａｖａ的な進化の方向に進んでいるから。
つまるところそれはＪａｖａに近づこうとするあまり、Ｃ＋＋的な要素の相当部分を放棄しなければならず、それはもはやＣ＋＋の後継と呼べるものではない。
ある意味、一種の新種である。
そしてＣ＃がＪａｖａを駆逐できるかといったらいささか疑問が残る。
Ｃ＋＋ユーザーがＣ＋＋の遺産を残しながらＪａｖａ的なプログラミングもやりたいのならば、今のところＣ＋＋とＣ＃を併用することが当面の間は一番賢明な選択ということになるだろう。
もしもＣ＋＋があくまでＣ＋＋の延長線上に発展していこうとすれば、それはＣ＃ではなくＤ言語的なものになるだろう。
しかるにＭＳには今のところそういう動きはないようだ。
どうもＭＳは方向性を誤ったように思えてならない。
なぜなら、Ｊａｖａは方向性はそのままに進化し続けるが、Ｃ＋＋はＣ＃に見られるように、非常にＪａｖａ的な進化の方向に進んでいるから。
つまるところそれはＪａｖａに近づこうとするあまり、Ｃ＋＋的な要素の相当部分を放棄しなければならず、それはもはやＣ＋＋の後継と呼べるものではない。
ある意味、一種の新種である。
そしてＣ＃がＪａｖａを駆逐できるかといったらいささか疑問が残る。
Ｃ＋＋ユーザーがＣ＋＋の遺産を残しながらＪａｖａ的なプログラミングもやりたいのならば、今のところＣ＋＋とＣ＃を併用することが当面の間は一番賢明な選択ということになるだろう。
もしもＣ＋＋があくまでＣ＋＋の延長線上に発展していこうとすれば、それはＣ＃ではなくＤ言語的なものになるだろう。
しかるにＭＳには今のところそういう動きはないようだ。
どうもＭＳは方向性を誤ったように思えてならない。
なんでこの話の流れでC#がでてきたのか不思議だ
553 ：仕様書無しさん：2005/12/09(金) 01:58:04
C#はC++/CLIに駆逐されるのは間違いない >>551
C#は、MSの独断で開発したものだから
どっちか選びたがる奴は、例外なくカスだな。
当分どっちも使われるでしょ。
当分どっちも使われるでしょ。
>>550
細かいことまではシラネ
細かいことまではシラネ
558 ：仕様書無しさん：2005/12/09(金) 03:24:49
>>551
定期燃料投下乙
定期燃料投下乙
559 ：仕様書無しさん：2005/12/09(金) 08:12:37
>『アジャイルソフトウェア開発の奥義』や『EffectiveJava』『Javaの格言』
>『Javaの鉄則』『Javaの落とし穴』といった本を
>読んで実践すれば三流ソースになる可能性は非常に低い。
2流の下まではこれでできるだろうが
一流のコードは汎用書籍には載ってないぞ
>『Javaの鉄則』『Javaの落とし穴』といった本を
>読んで実践すれば三流ソースになる可能性は非常に低い。
2流の下まではこれでできるだろうが
一流のコードは汎用書籍には載ってないぞ
ほんとにおまいら、同じ議論を何度も繰り返すの好きだな
>>560
だから！どこがｷﾞﾛﾝになってるのかと！何度も！何度も！
だから！どこがｷﾞﾛﾝになってるのかと！何度も！何度も！
563 ：仕様書無しさん：2005/12/10(土) 16:00:59
Javaなのはドコモのiアプリだろ。
組込みとか言うとOSまで全部と勘違いするバカがいるよ
組込みとか言うとOSまで全部と勘違いするバカがいるよ
565 ：仕様書無しさん：2005/12/10(土) 20:40:11
シーがいいと思います
Integer.toString()とかだな
普通の人が書いたら絶対ぷぎゃーとか言われる
標準だと何故か許される、そんな世界のコード
普通の人が書いたら絶対ぷぎゃーとか言われる
標準だと何故か許される、そんな世界のコード
568 ：仕様書無しさん：2005/12/11(日) 03:18:33
JavaPGって、パフォーマンスに疎いよな。
コードで得るパフォーマンスより、デザパタとか美しさにこだわる。
とろくさくて話にならないからコードレビューして指摘してやりゃハードのせい。
コボラ以下だぜ。あのゴミども
コードで得るパフォーマンスより、デザパタとか美しさにこだわる。
とろくさくて話にならないからコードレビューして指摘してやりゃハードのせい。
コボラ以下だぜ。あのゴミども
569 ：仕様書無しさん：2005/12/11(日) 04:45:04
ニートや主婦の株売買が激増した昨今、オンライントレードのチューニングに
追われるJava PGの皆様、乙であります！
追われるJava PGの皆様、乙であります！
570 ：仕様書無しさん：2005/12/11(日) 06:09:42
>>568
トリッキーコード馬鹿は死んでしまえ。癌だ。
トリッキーコード馬鹿は死んでしまえ。癌だ。
571 ：仕様書無しさん：2005/12/11(日) 06:11:30
>>568
それにそれに、パフォーマンスの問題はコーディングじゃなくて
設計の問題ですが何か？コーダーにパフォーマンス求められてもなぁ。
コーダーは美しさに拘って吉だぞ。
無論、デザパタは設計者の責任だからコーダーは口出し無用。
それにそれに、パフォーマンスの問題はコーディングじゃなくて
設計の問題ですが何か？コーダーにパフォーマンス求められてもなぁ。
コーダーは美しさに拘って吉だぞ。
無論、デザパタは設計者の責任だからコーダーは口出し無用。
572 ：仕様書無しさん：2005/12/11(日) 07:07:38
573 ：仕様書無しさん：2005/12/11(日) 09:51:46
も前らみたいなアンチサービス指向な古臭いOO馬鹿は時代遅れ
Javaプログラマがパフォーマンスチューニングに疎いのは確かだが
コードレビューによる指摘は意味がない。
Javaでは先ずプロファイリングする事が第一で、その後のチューニ
ングはコードに留まらず、ハードウェアの構成からミドルウェアの設
定、バックエンドの選択から最適化までを含めたトータルチューニン
グになる。
そして、これを担当するエンジニアは非常に特殊なポジションをとる。
どれくらい特殊かって言うと、これ一本で食ってるコンサルや外注さ
んが居るくらい特殊ｗ
何故JavaではXPが持て囃されるのか？って話とも絡むんだけど
まぁ、どうでもいいかｗ
コードレビューによる指摘は意味がない。
Javaでは先ずプロファイリングする事が第一で、その後のチューニ
ングはコードに留まらず、ハードウェアの構成からミドルウェアの設
定、バックエンドの選択から最適化までを含めたトータルチューニン
グになる。
そして、これを担当するエンジニアは非常に特殊なポジションをとる。
どれくらい特殊かって言うと、これ一本で食ってるコンサルや外注さ
んが居るくらい特殊ｗ
何故JavaではXPが持て囃されるのか？って話とも絡むんだけど
まぁ、どうでもいいかｗ
ハードも含めてチューニングするの？
ハードは要求定義時に決まるもんだろ？
運用始めてパフォーマンスが出ないからってハードウェアを追加するってそんなアホな！
ハードは要求定義時に決まるもんだろ？
運用始めてパフォーマンスが出ないからってハードウェアを追加するってそんなアホな！
576 ：69式フリーPG ◆hND3Lufios ：2005/12/11(日) 10:29:22
10年位前はOracle関連でそういうので食ってる香具師がいたな。
>>575
これ、再利用云々でも触れたんだけど、要はコストの話なんだわ。
修正するのが困難なんだけど、既存コードを捨てて書き直すのは是か非か？
って、修正するより書き直す方がコスト安なら書き直せばいいじゃないって話。
それが最も安価な解決策であるなら、ハードウェアの構成見直しどころか丸
ごと変更したって別に構わない。
>>576
DB職人は侮れない。て言うか、WEBアプリではDB職人さんの腕次第で体感
的なパフォーマンスに雲泥の差がつく。
これ、再利用云々でも触れたんだけど、要はコストの話なんだわ。
修正するのが困難なんだけど、既存コードを捨てて書き直すのは是か非か？
って、修正するより書き直す方がコスト安なら書き直せばいいじゃないって話。
それが最も安価な解決策であるなら、ハードウェアの構成見直しどころか丸
ごと変更したって別に構わない。
>>576
DB職人は侮れない。て言うか、WEBアプリではDB職人さんの腕次第で体感
的なパフォーマンスに雲泥の差がつく。
>>576, >>577
問題はそういうことが習慣になってしまっていて、パフォーマンス問題に
なったときにコードやDB設計を見直そうとすらせず（むしろ自分の責任に
なるから頑なに拒否）、一方的に環境にするアホが蔓延してるってことだよな。
問題はそういうことが習慣になってしまっていて、パフォーマンス問題に
なったときにコードやDB設計を見直そうとすらせず（むしろ自分の責任に
なるから頑なに拒否）、一方的に環境にするアホが蔓延してるってことだよな。
だからバカぞろいと言われる。VB厨・コボラ以下。それがJAVA厨
最初から要件を満たすコードを書けば良いじゃない。
581 ：仕様書無しさん：2005/12/11(日) 11:40:38
要件を満たすコード?
アジャイルで馬鹿な顧客のいいなりでただでさえ遅いパフォーマンスが
さらに遅くなり顧客と喧嘩になるのがJAVA厨
アジャイルで馬鹿な顧客のいいなりでただでさえ遅いパフォーマンスが
さらに遅くなり顧客と喧嘩になるのがJAVA厨
582 ：仕様書無しさん：2005/12/11(日) 11:42:40
デザパタとかアジャイルとかいいつつ、追加・削除が多いコレクションに
アレイを使う。そして遅いのはハードのせい。
それがJAVA厨クオリティ
アレイを使う。そして遅いのはハードのせい。
それがJAVA厨クオリティ
修正するよりハードを買い直したほうが安いくらいの糞コード。
ハードが売れてサンもIBMも大喜びってことでＦＡ。
ハードが売れてサンもIBMも大喜びってことでＦＡ。
>>578
習慣になってるというか、それもノウハウなんだがな。
大規模なプロジェクトではDB設計はJavaプログラマの範疇外。
DB周りはハードウェアやDBそのものの選定まで絡むから、専門家の仕事。
#どうも２ちゃんではDB職人て小馬鹿にされてる印象があるが、アーキテク
#ト寄りの仕事で顧客との折衝にも参加するし、当然設計にも深く関与する
#し、現場サイドでは先生扱いだし、導入時は指揮者権限だし、そういう存在
#だぞ？＞DB職人
コード(ロジック)レベルでの最適化は修正がパッケージの外へ及ばなくなっ
てからで、これも基本的にはある程度経験を積んだプログラマが担当する。
ピンからキリまで複数のプログラマでレビューする段階ではパフォーマンス
よりも分かり易さが優先される。
冗長である事を否としないというより、コメントが無くても何やってるか分かる
くらい冗長である事を是とする。
この方が変更に対しては強いコードになるというノウハウのうちの一つ。
習慣になってるというか、それもノウハウなんだがな。
大規模なプロジェクトではDB設計はJavaプログラマの範疇外。
DB周りはハードウェアやDBそのものの選定まで絡むから、専門家の仕事。
#どうも２ちゃんではDB職人て小馬鹿にされてる印象があるが、アーキテク
#ト寄りの仕事で顧客との折衝にも参加するし、当然設計にも深く関与する
#し、現場サイドでは先生扱いだし、導入時は指揮者権限だし、そういう存在
#だぞ？＞DB職人
コード(ロジック)レベルでの最適化は修正がパッケージの外へ及ばなくなっ
てからで、これも基本的にはある程度経験を積んだプログラマが担当する。
ピンからキリまで複数のプログラマでレビューする段階ではパフォーマンス
よりも分かり易さが優先される。
冗長である事を否としないというより、コメントが無くても何やってるか分かる
くらい冗長である事を是とする。
この方が変更に対しては強いコードになるというノウハウのうちの一つ。
指摘がコードに及びそうになると金切り声上げるのなんでだろ〜
586 ：仕様書無しさん：2005/12/11(日) 12:32:26
>>584
顧客の金使って勝手な事言ってらー。
分かりやすつーても顧客にはどー意味不明。そういう話は内緒にしとけな。
パフォーマンス向上は、仮説立てて検証しながらやるもんだ。
どんなに経験を積んだ神業プログラマーでも、初期のバージョンで
パフォーマンス要件を満たす設計・実装を編み出すのは至難の技さ。
机上の空論で「理論的にこのやり方が早いはず！」と言っても誰も
信用しないぜ。「単に作りたいように作るだけだろお前」って心の中で
つぶやいてるぜ。
機能外要求は、顧客との話し合いで解決するものでプログラマーの出る幕
はないんよ。もし、問われたら、「実際に測定できるソフトウェアが完成
するまではなんとも言えません。ただ、最低限の考慮はしますし、敢えて
遅いコードを書く事はしませんのでご安心下さい。」くらいが落としどころ
だろう。
「初めは、わかりやすさのためパフォーマンスを犠牲にします。」とは
口が裂けてもいえない。
顧客の金使って勝手な事言ってらー。
分かりやすつーても顧客にはどー意味不明。そういう話は内緒にしとけな。
パフォーマンス向上は、仮説立てて検証しながらやるもんだ。
どんなに経験を積んだ神業プログラマーでも、初期のバージョンで
パフォーマンス要件を満たす設計・実装を編み出すのは至難の技さ。
机上の空論で「理論的にこのやり方が早いはず！」と言っても誰も
信用しないぜ。「単に作りたいように作るだけだろお前」って心の中で
つぶやいてるぜ。
機能外要求は、顧客との話し合いで解決するものでプログラマーの出る幕
はないんよ。もし、問われたら、「実際に測定できるソフトウェアが完成
するまではなんとも言えません。ただ、最低限の考慮はしますし、敢えて
遅いコードを書く事はしませんのでご安心下さい。」くらいが落としどころ
だろう。
「初めは、わかりやすさのためパフォーマンスを犠牲にします。」とは
口が裂けてもいえない。
>>586
そりゃ言わんさｗ
顧客にとって重要なのは納品物で、そこに至るまでの過程は問題じゃない。
どういう指針で開発してるかを態々説明したりはしないし、その必要もない。
>どんなに経験を積んだ神業プログラマーでも、初期のバージョンで
>パフォーマンス要件を満たす設計・実装を編み出すのは至難の技さ。
だからこそ、「プロファイリングする事が第一」と最初に書いた。
パフォーマンス優先のコーディングなんてやっても、変更に対して硬くなる
だけで効果薄いんだよな。
測定して問題点を局所化してから最適化する方が低コストで効果を期待で
きる。だからこそ、これもまたノウハウのうちの一つなんだと言ってるわけな
んだが・・・・・・
そりゃ言わんさｗ
顧客にとって重要なのは納品物で、そこに至るまでの過程は問題じゃない。
どういう指針で開発してるかを態々説明したりはしないし、その必要もない。
>どんなに経験を積んだ神業プログラマーでも、初期のバージョンで
>パフォーマンス要件を満たす設計・実装を編み出すのは至難の技さ。
だからこそ、「プロファイリングする事が第一」と最初に書いた。
パフォーマンス優先のコーディングなんてやっても、変更に対して硬くなる
だけで効果薄いんだよな。
測定して問題点を局所化してから最適化する方が低コストで効果を期待で
きる。だからこそ、これもまたノウハウのうちの一つなんだと言ってるわけな
んだが・・・・・・
588 ：仕様書無しさん：2005/12/11(日) 12:44:37
うちの会社じゃＤＢは、比較的若い技術者がやってるぜ。
ＤＢは技術者共通の知識なんで、いざというときヘルプが入るし。
仕様書書きやすいからな。
データ指向な考え方が得意な日本人からするとＤＢは特に難しい
ものじゃない。日本では、軽く見られがちだね。
農耕民族は、共有財産をやりくりするのがうまいんよ。
ＤＢは技術者共通の知識なんで、いざというときヘルプが入るし。
仕様書書きやすいからな。
データ指向な考え方が得意な日本人からするとＤＢは特に難しい
ものじゃない。日本では、軽く見られがちだね。
農耕民族は、共有財産をやりくりするのがうまいんよ。
そういや某所でドノーマルのオラクルだと普通のパフォーマンスなのに、
現場だと30秒位かかるケースがあったなあ。
当然、パフォーマンスアップはお願いしたんですけど無駄でした。
しょうがないので複数のテーブルみるの止めて、それぞれのテーブルから
一行づつ取るようにした。
DBチュウニーングの重要性を感じた一件でした。
現場だと30秒位かかるケースがあったなあ。
当然、パフォーマンスアップはお願いしたんですけど無駄でした。
しょうがないので複数のテーブルみるの止めて、それぞれのテーブルから
一行づつ取るようにした。
DBチュウニーングの重要性を感じた一件でした。
590 ：仕様書無しさん：2005/12/11(日) 13:09:53
>>587
ちゃんとした事言ってるからソコソコの経験をつんだソフト屋なんだろ？
プロファイル云々をノウハウって言うなって。当たり前だからさ。
ただ、顧客やソフト音痴は、このやり方を理解しないもんなんよ。
回りくどくて、直感的じゃないからだろうな・・・・。
（プロファイルって言う未知の用語使った時点でじんましんが出る連中
を相手にしてるもんで・・・。）
折れの今の仕事、世界一高速が要件なんだぜ。顧客からしたら理屈
じゃなくて作ったソフトでどうやって儲けるかが重要らしいが、
折れ世界一のソフト屋じゃないんですけど・・・（少なくても
世界一の給料はもらってない）。
大規模なソフトなら、リスクのある箇所をピックアップして、
優秀なスタッフに先行開発させチューニングを早々に開始させるだろ。
問題箇所の絞込みは、コード書く以前（プロファイルなし）でやらないと
やっぱいけないわけ。顧客の要求も定まらないうちに、凄い短期間で
プロファイルできるところまで持っていってチューニングしなきゃならない。
このチューニングもシンプルパターンしかやらんから、本格的な開発が
始まってから、遅い事に気づく事も良くある。その頃には、チューニング
済みソースで万人に読めないコードになってるんよね。。。。
ちゃんとした事言ってるからソコソコの経験をつんだソフト屋なんだろ？
プロファイル云々をノウハウって言うなって。当たり前だからさ。
ただ、顧客やソフト音痴は、このやり方を理解しないもんなんよ。
回りくどくて、直感的じゃないからだろうな・・・・。
（プロファイルって言う未知の用語使った時点でじんましんが出る連中
を相手にしてるもんで・・・。）
折れの今の仕事、世界一高速が要件なんだぜ。顧客からしたら理屈
じゃなくて作ったソフトでどうやって儲けるかが重要らしいが、
折れ世界一のソフト屋じゃないんですけど・・・（少なくても
世界一の給料はもらってない）。
大規模なソフトなら、リスクのある箇所をピックアップして、
優秀なスタッフに先行開発させチューニングを早々に開始させるだろ。
問題箇所の絞込みは、コード書く以前（プロファイルなし）でやらないと
やっぱいけないわけ。顧客の要求も定まらないうちに、凄い短期間で
プロファイルできるところまで持っていってチューニングしなきゃならない。
このチューニングもシンプルパターンしかやらんから、本格的な開発が
始まってから、遅い事に気づく事も良くある。その頃には、チューニング
済みソースで万人に読めないコードになってるんよね。。。。
自称DB職人も怪しいの多いけどな。
おっそろしく削除がとろいので文句言ったら、RAIDがどーのとか、ファイルの配置が
どうのとか言ってハードを買わせようとする。
何の事は無い、SELECTで使いもしないインデックスをいくつもつけてるだけだったり。
非ソフトウェア会社のSEに指摘されて、声が裏返り将来をみこしてつけただの
俺の知らないところで底辺プログラマが勝手につけただの言い訳しまくり。
おっそろしく削除がとろいので文句言ったら、RAIDがどーのとか、ファイルの配置が
どうのとか言ってハードを買わせようとする。
何の事は無い、SELECTで使いもしないインデックスをいくつもつけてるだけだったり。
非ソフトウェア会社のSEに指摘されて、声が裏返り将来をみこしてつけただの
俺の知らないところで底辺プログラマが勝手につけただの言い訳しまくり。
パフォーマンスが要求に入ってたら、完全にアウトじゃん。
あふぉだなお前ら
あふぉだなお前ら
593 ：仕様書無しさん：2005/12/11(日) 13:35:58
「リプレース前はPentium100MHzのNetWareにOracle7でもちゃんと動いてたよ？
どうして遅くなるの？使いものにならないから持って帰って。」
どうして遅くなるの？使いものにならないから持って帰って。」
594 ：仕様書無しさん：2005/12/11(日) 13:45:46
>>592
機能的要求と非機能的要求とをごっちゃにしてるな。
この２つの（場合によっては相反する）要求は、大抵は
別に処理されるの。
システムを横断する事項とコンポーネントに封じ込められる
事項を混在して考えるからアウトだって思える。
「残念ですが、パフォーマンス要件を満たすには、
この機能を落とさざるを得ませんね。。。
パフォーマンスと機能どちらを優先させましょうか？」
顧客の要求を全て呑むから、世のソフトウェア開発の大半が
失敗に終わるという事実がある。ぼちぼち業界も気づき始めてるよ。
機能的要求と非機能的要求とをごっちゃにしてるな。
この２つの（場合によっては相反する）要求は、大抵は
別に処理されるの。
システムを横断する事項とコンポーネントに封じ込められる
事項を混在して考えるからアウトだって思える。
「残念ですが、パフォーマンス要件を満たすには、
この機能を落とさざるを得ませんね。。。
パフォーマンスと機能どちらを優先させましょうか？」
顧客の要求を全て呑むから、世のソフトウェア開発の大半が
失敗に終わるという事実がある。ぼちぼち業界も気づき始めてるよ。
Javaが重いということだけはよくわかった。
Javaは実質業務系の仕事ばかりということもよくわかった。
597 ：仕様書無しさん：2005/12/11(日) 13:53:41
DB設計こそがDB使うプロジェクトの命。
つても、テーブル設計な。
これがデブってしまうアホ設計が多すぎ。
贅肉そぎ落として、美しいボディを仕上げる事が
DB設計の最重要事項。
ハード選びなんてその後データ容量算出した後に
客のパフォーマンス要求を加味してやるもんだ。
請求がその後、ならな・・・
つても、テーブル設計な。
これがデブってしまうアホ設計が多すぎ。
贅肉そぎ落として、美しいボディを仕上げる事が
DB設計の最重要事項。
ハード選びなんてその後データ容量算出した後に
客のパフォーマンス要求を加味してやるもんだ。
請求がその後、ならな・・・
つーか、最近のサーバならエントリレベルでもDB設計がきちんとしてれば
パフォーマンスが問題になることはそうないっしょ。
ハード選定はパフォーマンスというより保全性や安定性で行われるのが現代だよ。
パフォーマンスが問題になることはそうないっしょ。
ハード選定はパフォーマンスというより保全性や安定性で行われるのが現代だよ。
599 ：仕様書無しさん：2005/12/11(日) 14:25:26
600 ：仕様書無しさん：2005/12/11(日) 14:34:43
ＨＰのラックマウントも平気で壊れるよ。内緒だけど。
いくらするとおもってんだー。テメー。
ファンが回ってないとかメモリが逝ってるとか・・・。
サポート体制が整ってるだけで、壊れやすさは大差ない
んじゃねーかと思える。
いくらするとおもってんだー。テメー。
ファンが回ってないとかメモリが逝ってるとか・・・。
サポート体制が整ってるだけで、壊れやすさは大差ない
んじゃねーかと思える。
>>590
局所的にパフォーマンス上の悪が残っていても、そこにその他の利点があ
り全体的に要求を満たせるなら、それは是であるという考え方は目から鱗と
いうか、やはり俺的には新しいノウハウの臭い(Java臭とも言えるかもなｗ)
を感じてしまう。
うちの場合、最初のイテレーションが回りきるまではコードチューニングは
行わない。て言うか、プロファイリングがイテレーションの末尾に付いてる
から、そこまでは来ないとできない。
それに、あまり早い段階でコードチューニングしてしまうと、そこがブラック
ボックス化してリファクタリングと相性悪くなるし、折角チューニングしても
変更で切り捨てられると惜しいから。
まぁ、世界一高速が要件なんて仕事は請けた事がないから、あくまで一
般的な業務システムが前提の話。
局所的にパフォーマンス上の悪が残っていても、そこにその他の利点があ
り全体的に要求を満たせるなら、それは是であるという考え方は目から鱗と
いうか、やはり俺的には新しいノウハウの臭い(Java臭とも言えるかもなｗ)
を感じてしまう。
うちの場合、最初のイテレーションが回りきるまではコードチューニングは
行わない。て言うか、プロファイリングがイテレーションの末尾に付いてる
から、そこまでは来ないとできない。
それに、あまり早い段階でコードチューニングしてしまうと、そこがブラック
ボックス化してリファクタリングと相性悪くなるし、折角チューニングしても
変更で切り捨てられると惜しいから。
まぁ、世界一高速が要件なんて仕事は請けた事がないから、あくまで一
般的な業務システムが前提の話。
602 ：69式フリーPG ◆hND3Lufios ：2005/12/11(日) 14:41:18
COMPAQの腐れサーバも良く壊れたなｗ
ソーテックが10万くらいで4CPU鯖とか出したら買うか？
コード上のだめだめな部分がDBアクセスなら最初にそこを見直すべき。
そうしないと、他をどういじってもパフォーマンスは上がりません。
そうしないと、他をどういじってもパフォーマンスは上がりません。
Java厨はソース改変を嫌がります。
>>597
DBが重要な位置を占めてるのは俺もそう思うけど、テーブル設計とか以前
に・・・・・・何だろ？存在感というか上手く言えないけど、DB職人さんはオー
ラが重要だと思う。
要求を正しく引き出すところから始めて、ハードウェアやソフトウェアの選定
からネットワークの構成、果ては予算の見積もりまで、どこにでも首を突っ
込んで口を出す。
たとえ喧嘩になってもガンガン要求してくる様な文字通りの職人気質的を持
ったDB職人さんの存在そのものが重要ではないかと・・・・・・
俺としては最初にいい顔して何でもホイホイ引き請けるDB屋は逆に信頼で
きないんだよな。
DBが重要な位置を占めてるのは俺もそう思うけど、テーブル設計とか以前
に・・・・・・何だろ？存在感というか上手く言えないけど、DB職人さんはオー
ラが重要だと思う。
要求を正しく引き出すところから始めて、ハードウェアやソフトウェアの選定
からネットワークの構成、果ては予算の見積もりまで、どこにでも首を突っ
込んで口を出す。
たとえ喧嘩になってもガンガン要求してくる様な文字通りの職人気質的を持
ったDB職人さんの存在そのものが重要ではないかと・・・・・・
俺としては最初にいい顔して何でもホイホイ引き請けるDB屋は逆に信頼で
きないんだよな。
更新系テーブルが日々膨らんでいくDBと（ｒｙ
608 ：69式フリーPG ◆hND3Lufios ：2005/12/11(日) 15:17:52
日付日時順に挿入されていくだけのテーブルにクラスタが付いてなくて
月報作成に何十分も待たされるとか
月報作成に何十分も待たされるとか
609 ：仕様書無しさん：2005/12/11(日) 15:25:19
エクセルみたいなもんだと思ってる奴が一番タチ悪い。
ちょっとこのDBマスターっていう名前がついたテーブルいっぱいあるのに
外部キーがひとつも設定されてねぇじゃんｗｗｗアホかｗｗｗｗ
とか・・・
ちょっとこのDBマスターっていう名前がついたテーブルいっぱいあるのに
外部キーがひとつも設定されてねぇじゃんｗｗｗアホかｗｗｗｗ
とか・・・
JAVA屋がDB触るとおかしなものができあがる
餅は餅屋、DBはDB屋、これ業界の鉄則
餅は餅屋、DBはDB屋、これ業界の鉄則
コボラがDBを触るコードを書くと１行１行舐めるコードを書くようなもんだなｗ
613 ：仕様書無しさん：2005/12/11(日) 15:43:30
俺なんか１行１行ループしながら削除してるアホJAVA厨見たことあるぞ。
614 ：仕様書無しさん：2005/12/11(日) 15:48:17
>>613
ワラタ
ワラタ
615 ：仕様書無しさん：2005/12/11(日) 16:44:11
そんなお前らは、プロらしく、ちゃんと東プレのキーボード使ってるか？
ALPS白軸なメカニカルだな。
打ってる本人は気持ちいいが、周りはウルサいだろうなｗ
打ってる本人は気持ちいいが、周りはウルサいだろうなｗ
617 ：仕様書無しさん：2005/12/11(日) 17:16:41
メカニカルはうるさい・・・ｗ
自宅でやってるなら本人の自由だから何も言わないけど
オフィスでオナニーするかのようにメカニカル叩いて自己満足するのだけは
止めて欲しい。
最近流行のパンタグラフと比べれば、東プレも十分にうるさい部類に入る
んだけどね。オフィスでMyキーボード持ち込んで使うのはマニア？
自宅でやってるなら本人の自由だから何も言わないけど
オフィスでオナニーするかのようにメカニカル叩いて自己満足するのだけは
止めて欲しい。
最近流行のパンタグラフと比べれば、東プレも十分にうるさい部類に入る
んだけどね。オフィスでMyキーボード持ち込んで使うのはマニア？
DBとかどうでもいいから、どっちのほうが先あるんだ？
どっちもとか無しな。
どっちもとか無しな。
どっちもあるさ、C++の案件は減るだろうが無くならない。CでOOPするなら必要だからな。
時々金融・証券の仕事しているけど、C++でやってるよ。
つーかJAVAって見たこと無い。
複数の業者入るので、複数のアプリ連携しなきゃなんない。
プロセス間通信の事考えるとソケット通信しかないんで逆に
忌避されているようなんだが・・・。
つーかJAVAって見たこと無い。
複数の業者入るので、複数のアプリ連携しなきゃなんない。
プロセス間通信の事考えるとソケット通信しかないんで逆に
忌避されているようなんだが・・・。
621 ：仕様書無しさん：2005/12/11(日) 20:13:40
はっきりいえるのは、Java、C++とか言語の完成度や能力は、先が有る無し
には関係が無い。
JavaやC++ともに適材適所に使えばいいというのが現場の考えだろうが、
バックにいる企業や団体は、それぞれの思惑で動いてる。
企業の戦略や競争（戦争）でどっちが勝つかさ。
言語にとらわれると足元すくわれるぜ。
結局、プロは言語選べないんよ。顧客の要望に合わせるだけ。
金儲けしたけりゃ両方やれ。
右も左もわからない学生がとりあえず勉強するには、教材がそろってる
Ｊａｖａがお勧めだが。ソフトで食っていくには、一通り全ての言語を
使えるようにしとけよ。若者よ。
には関係が無い。
JavaやC++ともに適材適所に使えばいいというのが現場の考えだろうが、
バックにいる企業や団体は、それぞれの思惑で動いてる。
企業の戦略や競争（戦争）でどっちが勝つかさ。
言語にとらわれると足元すくわれるぜ。
結局、プロは言語選べないんよ。顧客の要望に合わせるだけ。
金儲けしたけりゃ両方やれ。
右も左もわからない学生がとりあえず勉強するには、教材がそろってる
Ｊａｖａがお勧めだが。ソフトで食っていくには、一通り全ての言語を
使えるようにしとけよ。若者よ。
622 ：仕様書無しさん：2005/12/11(日) 20:22:40
>>621
つまらん正論言わないで煽りあえよ
つまらん正論言わないで煽りあえよ
623 ：仕様書無しさん：2005/12/11(日) 20:27:19
煽りあってるうちに、次の言語が生まれてしまうぜ。
D言語完成遅すぎ
Digital Mars貧乏過ぎだよ
Digital Mars貧乏過ぎだよ
625 ：69式フリーPG ◆hND3Lufios ：2005/12/11(日) 20:49:47
どうでもいいけど、DigitalMarsのおっさんこそ渡り鳥だよな
コンパイラ屋がC++のコンパイラ作ってて｢無駄多すぎヽ(`Д´)ﾉ｣って切れて作ってるのがD言語
みずほ証券の問題で
東証システムに不具合があったのはC++のような不安定な言語を使ったからである。
C++言語を金融システムで使用禁止にすべきだ。
東証システムに不具合があったのはC++のような不安定な言語を使ったからである。
C++言語を金融システムで使用禁止にすべきだ。
alertが表示されたらしつこく繰り返し確認を取るシステムにすればよい。
629 ：仕様書無しさん：2005/12/11(日) 21:07:53
alert を、連打で閉じる癖があったらなにをやっても同じさ
630 ：仕様書無しさん：2005/12/11(日) 21:13:14
折れの周りは、Java と C++。
生産性はJavaの圧勝、品質はC++の圧勝ということで、
話はついてる。
作る側のスキルは置いといて・・・。
ただ、Java 使いよりC++使いの方がスキルが高い（うちの場合）
から、C++の方がちょっと良いものができるので印象が良い。
生産性はJavaの圧勝、品質はC++の圧勝ということで、
話はついてる。
作る側のスキルは置いといて・・・。
ただ、Java 使いよりC++使いの方がスキルが高い（うちの場合）
から、C++の方がちょっと良いものができるので印象が良い。
多少おつむが弱くても使え、生産性の高い言語と、高品質だが危険性も高く
高スキルを要求される言語が並んで標準つうのは、いつの時代だってそうだよな。
米軍戦闘機のハイローミックスみたいなもんかｗ
高スキルを要求される言語が並んで標準つうのは、いつの時代だってそうだよな。
米軍戦闘機のハイローミックスみたいなもんかｗ
Java = N88-BASIC
C++ = マシン語
C++ = マシン語
633 ：仕様書無しさん：2005/12/11(日) 22:31:57
とにかく、この歳でJavaだろうがC++だろうが実装なんてしたくねーな。
>>567
> Integer.toString()とかだな
> 普通の人が書いたら絶対ぷぎゃーとか言われる
> 標準だと何故か許される、そんな世界のコード
それが一流？ そしてそれ以外が一流ではないと言い切る？
Effective Java読んだか
Integer,valueOf()がある正当な理由を知らないだろ。
> Integer.toString()とかだな
> 普通の人が書いたら絶対ぷぎゃーとか言われる
> 標準だと何故か許される、そんな世界のコード
それが一流？ そしてそれ以外が一流ではないと言い切る？
Effective Java読んだか
Integer,valueOf()がある正当な理由を知らないだろ。
>>573
サービス指向ってものをよくわかってなさそうだな。
サービス指向がオブジェクト指向の代わりに
置き換えるものだと思いこんでいるなら
お前は某記者の嘘記事に騙されているぞ。
お前もその記者もアスペクト指向があればオブジェクト指向は
いらないと言ってる馬鹿と同じ。
サービス指向ってものをよくわかってなさそうだな。
サービス指向がオブジェクト指向の代わりに
置き換えるものだと思いこんでいるなら
お前は某記者の嘘記事に騙されているぞ。
お前もその記者もアスペクト指向があればオブジェクト指向は
いらないと言ってる馬鹿と同じ。
>>568
> JavaPGって、パフォーマンスに疎いよな。
> コードで得るパフォーマンスより、デザパタとか美しさにこだわる。
> とろくさくて話にならないからコードレビューして指摘してやりゃハードのせい。
> コボラ以下だぜ。あのゴミども
随分と偏見が多いな。
Javaでもチューニングすることはできる。
またその手法もある。パフォーマンスチューニングよりも
問題なのはメモリ節約のほうだ。
それにjava.lang.refパッケージをよくみてみろ。
ガーベッジコレクタがオブジェクトを解放する優先度を変えてくれるクラスがある。
これでパフォーマンスチューニングもできる。
staticキーワードを上手に使うこともパフォーマンスチューニングの一つ。
それから、デザインパターンを使えばパフォーマンスに疎くなるというのも
>>567がまだまだデザインパターンのことを良く知らない証拠だ。
デザインパターンには、パフォーマンスを高めるためにあるものもある。
FlyWeightパターン、Proxyパターンをよく見てみろ。
これらはパフォーマンスを高めるために作られた。
> JavaPGって、パフォーマンスに疎いよな。
> コードで得るパフォーマンスより、デザパタとか美しさにこだわる。
> とろくさくて話にならないからコードレビューして指摘してやりゃハードのせい。
> コボラ以下だぜ。あのゴミども
随分と偏見が多いな。
Javaでもチューニングすることはできる。
またその手法もある。パフォーマンスチューニングよりも
問題なのはメモリ節約のほうだ。
それにjava.lang.refパッケージをよくみてみろ。
ガーベッジコレクタがオブジェクトを解放する優先度を変えてくれるクラスがある。
これでパフォーマンスチューニングもできる。
staticキーワードを上手に使うこともパフォーマンスチューニングの一つ。
それから、デザインパターンを使えばパフォーマンスに疎くなるというのも
>>567がまだまだデザインパターンのことを良く知らない証拠だ。
デザインパターンには、パフォーマンスを高めるためにあるものもある。
FlyWeightパターン、Proxyパターンをよく見てみろ。
これらはパフォーマンスを高めるために作られた。
>>582
> デザパタとかアジャイルとかいいつつ、追加・削除が多いコレクションに
> アレイを使う。そして遅いのはハードのせい。
JavaのList, ArrayList, LinkedListクラスはアレイの一種だろう。
わかってないな。これらのクラスは有名なデザインパターンがしっかりつかわれている。
C++のSTLそっくりにね。Iteratorパターン、TemplateMethodパターンなど当たり前のようにね。
> デザパタとかアジャイルとかいいつつ、追加・削除が多いコレクションに
> アレイを使う。そして遅いのはハードのせい。
JavaのList, ArrayList, LinkedListクラスはアレイの一種だろう。
わかってないな。これらのクラスは有名なデザインパターンがしっかりつかわれている。
C++のSTLそっくりにね。Iteratorパターン、TemplateMethodパターンなど当たり前のようにね。
>>584
> >>578
> 習慣になってるというか、それもノウハウなんだがな。
>
> 大規模なプロジェクトではDB設計はJavaプログラマの範疇外。
そうでもないな。Javaの仕事やってると、
DBの再設計をすることもよくある。
クエリの変更だけでなく
カラムやテーブルの追加は普通にある。
最初に設計するのも肝心だが、最近ではHibernate + XDocletにより、
JavaソースコードのJavadocコメントから
データベースのテーブル、クエリを自動生成する開発手法も流行っている。
> DB周りはハードウェアやDBそのものの選定まで絡むから、専門家の仕事。
> #どうも２ちゃんではDB職人て小馬鹿にされてる印象があるが、アーキテク
馬鹿にされるんだったら何でデータベースの仕事やってる香具師らは組み込み
系の香具師らよりも金持ちが多いんだ？
もし2chでDB系が馬鹿にされているというなら、それは僻みや嫉みと
同じじゃないかね？
> >>578
> 習慣になってるというか、それもノウハウなんだがな。
>
> 大規模なプロジェクトではDB設計はJavaプログラマの範疇外。
そうでもないな。Javaの仕事やってると、
DBの再設計をすることもよくある。
クエリの変更だけでなく
カラムやテーブルの追加は普通にある。
最初に設計するのも肝心だが、最近ではHibernate + XDocletにより、
JavaソースコードのJavadocコメントから
データベースのテーブル、クエリを自動生成する開発手法も流行っている。
> DB周りはハードウェアやDBそのものの選定まで絡むから、専門家の仕事。
> #どうも２ちゃんではDB職人て小馬鹿にされてる印象があるが、アーキテク
馬鹿にされるんだったら何でデータベースの仕事やってる香具師らは組み込み
系の香具師らよりも金持ちが多いんだ？
もし2chでDB系が馬鹿にされているというなら、それは僻みや嫉みと
同じじゃないかね？
>>586
> >>584
> 顧客の金使って勝手な事言ってらー。
> 分かりやすつーても顧客にはどー意味不明。そういう話は内緒にしとけな。
>
> パフォーマンス向上は、仮説立てて検証しながらやるもんだ。
> どんなに経験を積んだ神業プログラマーでも、初期のバージョンで
> パフォーマンス要件を満たす設計・実装を編み出すのは至難の技さ。
> 机上の空論で「理論的にこのやり方が早いはず！」と言っても誰も
> 信用しないぜ。「単に作りたいように作るだけだろお前」って心の中で
> つぶやいてるぜ。
>
> 機能外要求は、顧客との話し合いで解決するものでプログラマーの出る幕
> はないんよ。もし、問われたら、「実際に測定できるソフトウェアが完成
> するまではなんとも言えません。ただ、最低限の考慮はしますし、敢えて
実際に個々の部品を作り替えたらどれだけパフォーマンスに
変化が現れるかテストする筈だろう。
パフォーマンスに関してはJavaでも種種の様々なテクニックがある。
知らない人は多いが。
> >>584
> 顧客の金使って勝手な事言ってらー。
> 分かりやすつーても顧客にはどー意味不明。そういう話は内緒にしとけな。
>
> パフォーマンス向上は、仮説立てて検証しながらやるもんだ。
> どんなに経験を積んだ神業プログラマーでも、初期のバージョンで
> パフォーマンス要件を満たす設計・実装を編み出すのは至難の技さ。
> 机上の空論で「理論的にこのやり方が早いはず！」と言っても誰も
> 信用しないぜ。「単に作りたいように作るだけだろお前」って心の中で
> つぶやいてるぜ。
>
> 機能外要求は、顧客との話し合いで解決するものでプログラマーの出る幕
> はないんよ。もし、問われたら、「実際に測定できるソフトウェアが完成
> するまではなんとも言えません。ただ、最低限の考慮はしますし、敢えて
実際に個々の部品を作り替えたらどれだけパフォーマンスに
変化が現れるかテストする筈だろう。
パフォーマンスに関してはJavaでも種種の様々なテクニックがある。
知らない人は多いが。
>>588
> うちの会社じゃＤＢは、比較的若い技術者がやってるぜ。
> ＤＢは技術者共通の知識なんで、いざというときヘルプが入るし。
> 仕様書書きやすいからな。
>
> データ指向な考え方が得意な日本人からするとＤＢは特に難しい
> ものじゃない。日本では、軽く見られがちだね。
とてもそうとは思えないな。
どちらかというと関数的な入力があったら出力があって
「状態」という概念が考えられない日本人が欧米人より
多すぎてならないな。機能ばかりにこだわりすぎて
クラスを作らせるととりあえず入力と出力だけがはっきりと
わかる「機能」だけに重点を置いたstatic属性(staticメソッド, staticメンバ関数)
の塊だけのものができあがり、
クラス内には操作(フィールド、メンバ変数)が一切ないという
Cの関数だけとかわらないクラスを作る香具師が多いこと多いこと。
これはデータ指向では非常に重要なのだが。
とくにシステムプログラミング系、信号処理系にああいうのが多い。
かれらには「状態保持」という概念がないのさ。「応答」とか「対話形式」
という言葉は大好きなようだが。
> 農耕民族は、共有財産をやりくりするのがうまいんよ。
それはstaticなクラス変数を複数のオブジェクトが共有するって
いうだけのレベルだったら笑えるぞ。
> うちの会社じゃＤＢは、比較的若い技術者がやってるぜ。
> ＤＢは技術者共通の知識なんで、いざというときヘルプが入るし。
> 仕様書書きやすいからな。
>
> データ指向な考え方が得意な日本人からするとＤＢは特に難しい
> ものじゃない。日本では、軽く見られがちだね。
とてもそうとは思えないな。
どちらかというと関数的な入力があったら出力があって
「状態」という概念が考えられない日本人が欧米人より
多すぎてならないな。機能ばかりにこだわりすぎて
クラスを作らせるととりあえず入力と出力だけがはっきりと
わかる「機能」だけに重点を置いたstatic属性(staticメソッド, staticメンバ関数)
の塊だけのものができあがり、
クラス内には操作(フィールド、メンバ変数)が一切ないという
Cの関数だけとかわらないクラスを作る香具師が多いこと多いこと。
これはデータ指向では非常に重要なのだが。
とくにシステムプログラミング系、信号処理系にああいうのが多い。
かれらには「状態保持」という概念がないのさ。「応答」とか「対話形式」
という言葉は大好きなようだが。
> 農耕民族は、共有財産をやりくりするのがうまいんよ。
それはstaticなクラス変数を複数のオブジェクトが共有するって
いうだけのレベルだったら笑えるぞ。
>>591
おまいのＳＥＬＥＣＴ文自体に問題がある
こともあるんだがな。
やたらと副問い合わせを使いたがる、
やたらとINを使いたがる
やたらとORを使いたがる
やたらとJOINを使いたがる
こいつはパフォーマンス劣化の原因だぜ。
小間委が作るSELECT文の設計次第で
速くもなれば遅くもなるわけだが。
DB屋に愚だ部だ文句や愚痴を零す前にそのことをよく理解しような。
おまいのＳＥＬＥＣＴ文自体に問題がある
こともあるんだがな。
やたらと副問い合わせを使いたがる、
やたらとINを使いたがる
やたらとORを使いたがる
やたらとJOINを使いたがる
こいつはパフォーマンス劣化の原因だぜ。
小間委が作るSELECT文の設計次第で
速くもなれば遅くもなるわけだが。
DB屋に愚だ部だ文句や愚痴を零す前にそのことをよく理解しような。
>>591
それからＲＡＩＤやファイルシステムについてよく勉強した方が良いぞ。
ファイルシステムの違い、RAIDの違いでも
パフォーマンスに影響が出る。
自作PCやってたりLinuxや*ＢＳＤインストールして
ファイルシステムいじくり回してる経験があるなら
それらの違いによってパフォーマンスに影響がでることは
よくわかるはずだが。
パフォーマンス向上目的でそれから新しいハードを買わせるのは
ファイルシステム変更やディスクが壊れたとかだと思われるが。
「俺の知らないところで底辺プログラマが勝手につけた」
って、お前の会社は変更前のコードをちゃんと管理してないのか？
バージョン管理システムちゃんと使えや。
それからＲＡＩＤやファイルシステムについてよく勉強した方が良いぞ。
ファイルシステムの違い、RAIDの違いでも
パフォーマンスに影響が出る。
自作PCやってたりLinuxや*ＢＳＤインストールして
ファイルシステムいじくり回してる経験があるなら
それらの違いによってパフォーマンスに影響がでることは
よくわかるはずだが。
パフォーマンス向上目的でそれから新しいハードを買わせるのは
ファイルシステム変更やディスクが壊れたとかだと思われるが。
「俺の知らないところで底辺プログラマが勝手につけた」
って、お前の会社は変更前のコードをちゃんと管理してないのか？
バージョン管理システムちゃんと使えや。
>>599
お前、DB設計をろくにやったことがなさそうだな。
テーブル内のカラムを分割するだけで冗長なデータがコンパクトに
収まるとかよくあるんだが。
正規標準系とか知らないのか？
データベース理論の本を読めばそういうことがよく書いてあるぜ。
それからビュー表作成とか。
データ定義を変更してテーブルを作り直してパフォーマンスあげることもできる。
お前、DB設計をろくにやったことがなさそうだな。
テーブル内のカラムを分割するだけで冗長なデータがコンパクトに
収まるとかよくあるんだが。
正規標準系とか知らないのか？
データベース理論の本を読めばそういうことがよく書いてあるぜ。
それからビュー表作成とか。
データ定義を変更してテーブルを作り直してパフォーマンスあげることもできる。
>>610
でもないな。
オブジェクト指向を知っていると
どうすれば冗長なデータをまとめられるかがわかってくる。
RDBMSとオブジェクト指向との間にはデータ型の直接の互換性
はないがテーブルどうしの関係、クラスどうしの関係は
よく似ているため、DB設計にもオブジェクト指向の知識が
役立つ。通常のRDBMSは
オブジェクト指向データベースのようにはいかないが。
HibernateやCayenneのようなO-Rマッピングツールのように
JavaソースコードからDBテーブルを
自動でCREATEすることもできるんだから。
でもないな。
オブジェクト指向を知っていると
どうすれば冗長なデータをまとめられるかがわかってくる。
RDBMSとオブジェクト指向との間にはデータ型の直接の互換性
はないがテーブルどうしの関係、クラスどうしの関係は
よく似ているため、DB設計にもオブジェクト指向の知識が
役立つ。通常のRDBMSは
オブジェクト指向データベースのようにはいかないが。
HibernateやCayenneのようなO-Rマッピングツールのように
JavaソースコードからDBテーブルを
自動でCREATEすることもできるんだから。
>>621
ただただ言語を習得するときに単純に言語選ぶと言うより
プロダクトを作るときにどの言語を選べばいいか
という選定基準のほうが重要。
どっちがいいかは実際に両方の言語を使ってみて
経験してみないとわからないことだし。
問題なのはプロダクトを一度作ってしまうと
それをすべて捨ててしまうことが勿体ないと感じてしまうことだ。
だからJavaとC++両方の言語を覚えることが苦には
ならなくても両方の言語を使って開発をすることは
設計次第でかなり苦になる。
C++は汚いスパゲティを書きやすいし
バッファオーバフローや型チェックの甘さなど信頼性としての品質も落ちやすい。
Javaはちょっとしたことですぐにコンパイルエラーが出るので
Java経験の浅い初心者が使うとクラス設計の仕方が
解らないことに起因するスパゲティが出やすくなる。
それが、>>630のようなJavaのほうがなぜかスキルが低くて質の悪いものを
作る人が多いことになってしまう。
C++だったらエラーがでないのにJavaだと出てしまう、というものがよくある。
それが、C++のときと同じ考えでJavaをやろうとするとうまくいかない、ということにつながる。
初心者はまずはCから始めてそれからJavaをやったほうがいいともいえる。
ただただ言語を習得するときに単純に言語選ぶと言うより
プロダクトを作るときにどの言語を選べばいいか
という選定基準のほうが重要。
どっちがいいかは実際に両方の言語を使ってみて
経験してみないとわからないことだし。
問題なのはプロダクトを一度作ってしまうと
それをすべて捨ててしまうことが勿体ないと感じてしまうことだ。
だからJavaとC++両方の言語を覚えることが苦には
ならなくても両方の言語を使って開発をすることは
設計次第でかなり苦になる。
C++は汚いスパゲティを書きやすいし
バッファオーバフローや型チェックの甘さなど信頼性としての品質も落ちやすい。
Javaはちょっとしたことですぐにコンパイルエラーが出るので
Java経験の浅い初心者が使うとクラス設計の仕方が
解らないことに起因するスパゲティが出やすくなる。
それが、>>630のようなJavaのほうがなぜかスキルが低くて質の悪いものを
作る人が多いことになってしまう。
C++だったらエラーがでないのにJavaだと出てしまう、というものがよくある。
それが、C++のときと同じ考えでJavaをやろうとするとうまくいかない、ということにつながる。
初心者はまずはCから始めてそれからJavaをやったほうがいいともいえる。
>>620
> 時々金融・証券の仕事しているけど、C++でやってるよ。
> つーかJAVAって見たこと無い。
自分の周りだけがたまたまそうなってるから
そう見えるだけともいえる。
自分の会社ではC#を使っていてJavaの仕事は見たことがない、
と言う人がいるかと思えば他の会社の人にあうと、
うちの会社はJavaばかりでC++やCの仕事は一切無い。
という人もいる。そういう世界
> 時々金融・証券の仕事しているけど、C++でやってるよ。
> つーかJAVAって見たこと無い。
自分の周りだけがたまたまそうなってるから
そう見えるだけともいえる。
自分の会社ではC#を使っていてJavaの仕事は見たことがない、
と言う人がいるかと思えば他の会社の人にあうと、
うちの会社はJavaばかりでC++やCの仕事は一切無い。
という人もいる。そういう世界
649 ：仕様書無しさん：2005/12/12(月) 02:35:10
>>630
> 折れの周りは、Java と C++。
> 生産性はJavaの圧勝、品質はC++の圧勝ということで、
> 話はついてる。
C++で作った方が品質が圧勝ってな。
普通はJavaのほうが品質が高いはず。
Javaに熟練した香具師が少ないだけだろうな。
C++は例外処理がアバウト、配列のバッファオーバフロー
メモリリークが発生しやすい、セキュリティ管理に弱い、
顧客の信頼性を下げる危険なコードを簡単に書けてしまう、
拡張性や再利用性、メンテナンス性を下げるコードが簡単に
書けてしまう、
とか質が低くなる原因をC++はJavaよりも作りやすい。
それでももしJavaのほうが質が低いというなら、
それはまだまだオブジェクト指向のことをよく
わかっていないために品質が悪くなっているだけじゃないかな。
> 折れの周りは、Java と C++。
> 生産性はJavaの圧勝、品質はC++の圧勝ということで、
> 話はついてる。
C++で作った方が品質が圧勝ってな。
普通はJavaのほうが品質が高いはず。
Javaに熟練した香具師が少ないだけだろうな。
C++は例外処理がアバウト、配列のバッファオーバフロー
メモリリークが発生しやすい、セキュリティ管理に弱い、
顧客の信頼性を下げる危険なコードを簡単に書けてしまう、
拡張性や再利用性、メンテナンス性を下げるコードが簡単に
書けてしまう、
とか質が低くなる原因をC++はJavaよりも作りやすい。
それでももしJavaのほうが質が低いというなら、
それはまだまだオブジェクト指向のことをよく
わかっていないために品質が悪くなっているだけじゃないかな。
乙でした
うるせーよ、Javaが先がある。 これでもういいだろ？
終わりにしようぜこんな議論
終わりにしようぜこんな議論
654 ：仕様書無しさん：2005/12/12(月) 23:35:20
>> 641
個々の部品がパフォーマンスに与える影響よりも、
アーキテクチャがパフォーマンスに与える影響の方が深刻さ。
テクニックはいくらでもある。万能ナイフなんて無いんだから、
結局リスクが付きまとう。他人の財布なんで、勝手な事は
できないわけよ。
個々の部品がパフォーマンスに与える影響よりも、
アーキテクチャがパフォーマンスに与える影響の方が深刻さ。
テクニックはいくらでもある。万能ナイフなんて無いんだから、
結局リスクが付きまとう。他人の財布なんで、勝手な事は
できないわけよ。
>>654
アンカーもまともに付けられないキミは2ch初心者か？
アンカーもまともに付けられないキミは2ch初心者か？
656 ：仕様書無しさん：2005/12/13(火) 14:16:41
しかしJAVA厨はSOAPも使うばっかりで実装する骨のある椰子はいないよな。
まあJAVAで遅いサービスを公開されても迷惑だからいいんだけどなw
まあJAVAで遅いサービスを公開されても迷惑だからいいんだけどなw
>>657
人月単価はどれくらいだ？
人月単価はどれくらいだ？
嵐依頼にも値段交渉か
世知辛い世の中になったなあ
世知辛い世の中になったなあ
御宅のデスクトップOSでJavaを活用する時代は来ません。
>>659
世知辛いって言うか、マ板に依頼する時点でどうかと思うわけで。ｗ
世知辛いって言うか、マ板に依頼する時点でどうかと思うわけで。ｗ
662 ：仕様書無しさん：2005/12/14(水) 19:54:50
>>654
> 個々の部品がパフォーマンスに与える影響よりも、
> アーキテクチャがパフォーマンスに与える影響の方が深刻さ。
> テクニックはいくらでもある。万能ナイフなんて無いんだから、
> 結局リスクが付きまとう。他人の財布なんで、勝手な事は
> できないわけよ。
テストして証明すればいいわけだが。
単体テストだ。テストサーバもちゃんと用意してな。
考えられるリスクはハードコーディングによってソースコードが
汚れてしまうこと。
Javaは比較的リファクタリングしやすい言語だ。
EclipseのようなIDEをうまく使えばリファクタリングによる最適化も
他の言語と比べ比較的容易。
Java開発ではCheckStyleプラグインや
FindBugsプラグインは必須アイテム。
プロファイラ、メトリクスプラグインを使ってボトルネックを探すことも重要。
つぎからつぎへとコードを継ぎ足すような書き方をしたソースコードは
重複部分が多く、リファクタリングし甲斐がある。し甲斐も無いコードもあるが。
コードをリファクタリングしたほうがコードを解析しやすくなるというのもある。
Subversionなどのバージョン管理システムを使わないと
とんでもないことになってしまうが。
> 個々の部品がパフォーマンスに与える影響よりも、
> アーキテクチャがパフォーマンスに与える影響の方が深刻さ。
> テクニックはいくらでもある。万能ナイフなんて無いんだから、
> 結局リスクが付きまとう。他人の財布なんで、勝手な事は
> できないわけよ。
テストして証明すればいいわけだが。
単体テストだ。テストサーバもちゃんと用意してな。
考えられるリスクはハードコーディングによってソースコードが
汚れてしまうこと。
Javaは比較的リファクタリングしやすい言語だ。
EclipseのようなIDEをうまく使えばリファクタリングによる最適化も
他の言語と比べ比較的容易。
Java開発ではCheckStyleプラグインや
FindBugsプラグインは必須アイテム。
プロファイラ、メトリクスプラグインを使ってボトルネックを探すことも重要。
つぎからつぎへとコードを継ぎ足すような書き方をしたソースコードは
重複部分が多く、リファクタリングし甲斐がある。し甲斐も無いコードもあるが。
コードをリファクタリングしたほうがコードを解析しやすくなるというのもある。
Subversionなどのバージョン管理システムを使わないと
とんでもないことになってしまうが。
665 ：仕様書無しさん：2005/12/15(木) 00:39:54
×
考えられるリスクはハードコーディングによってソースコードが
汚れてしまうこと。
○
考えられるリスクは、ハードコーディングによってソースコードが
汚れてしまっており、環境依存度が高くなって
テスト用サーバを構築しにくい、テストしづらいコードになっていること。
酷い人のコードはテスト用クラスを同じパッケージ内に配置し
それを本番環境でもそのまま入れていること。
もっと酷いのは同じクラスの中にテスト用メソッドを大量に
入れていること。その分だけリソースを無駄に食うし、
引き継ぎ人からすれば、どれが不要でどれが必要な
コードであるかわかりづらく非常に良い迷惑だし。
考えられるリスクはハードコーディングによってソースコードが
汚れてしまうこと。
○
考えられるリスクは、ハードコーディングによってソースコードが
汚れてしまっており、環境依存度が高くなって
テスト用サーバを構築しにくい、テストしづらいコードになっていること。
酷い人のコードはテスト用クラスを同じパッケージ内に配置し
それを本番環境でもそのまま入れていること。
もっと酷いのは同じクラスの中にテスト用メソッドを大量に
入れていること。その分だけリソースを無駄に食うし、
引き継ぎ人からすれば、どれが不要でどれが必要な
コードであるかわかりづらく非常に良い迷惑だし。
>>656はSOAとSOAPとが同じものだと勘違いしているオチではないだろな？
grep知ってるのに正規表現しらない先輩がいる
ただの検索コマンドでしかないんだろうな・・・
ただの検索コマンドでしかないんだろうな・・・
いいよーいいよー
java厨とＣ＋＋厨の臭いがプンプンする。
java厨とＣ＋＋厨の臭いがプンプンする。
deleteを覚えられないJava使い
C++は先に進みすぎている
コンパイラが追いついていない
Javaは言語としては枯れているので安心か
コンパイラが追いついていない
Javaは言語としては枯れているので安心か
JavaはPGがついていけていない。厨だらけで。
672 ：名無しさん＠編集中：2005/12/16(金) 01:19:47
C++使える人はちゃんと理工系でてそうだけど、JAVAだけ使える厨って
高卒から文系私大卒とかいろいろバラエティに富んでるねｗ流行だからだろうけど、
言語の質というより、人の質に差がでてそうなんだけど。C++使える人は
JAVA余裕でマスターできるしね。
高卒から文系私大卒とかいろいろバラエティに富んでるねｗ流行だからだろうけど、
言語の質というより、人の質に差がでてそうなんだけど。C++使える人は
JAVA余裕でマスターできるしね。
C++もJavaも言語仕様はシンプルだから覚えやすい。
JavaはともかくC++は大いに異議あり
->は欠陥に思えてならないのはGCにべったりのJavaに慣れてしまったからだろうか・・・
676 ：仕様書無しさん：2005/12/16(金) 06:20:48
早くD言語が広まってC++がなくなることを祈ってます
677 ：仕様書無しさん：2005/12/16(金) 07:26:20
英語の駄目な専門学校卒の業務系ドカタにJavaは無理。
Jakartaのドキュメントすら原文で読めない
Jakartaのドキュメントすら原文で読めない
678 ：仕様書無しさん：2005/12/16(金) 07:28:09
ハードウエアがわからない
アセンブラはさっぱりだ
Cは難しい、OOPできねー
これからはC++だ ←C++厨の現在
単一継承にして；；
Javaまんせー ←Java厨の現在
アセンブラはさっぱりだ
Cは難しい、OOPできねー
これからはC++だ ←C++厨の現在
単一継承にして；；
Javaまんせー ←Java厨の現在
C++の仕様が膨大だってのは、どこのこといってるの？
いまいち理解できん。
いまいち理解できん。
テンプレートのことかな
多重継承可能なとこだろ
ModernC++Designまでいくと理解不能な人増えると思うが、多重継承もテンプレートも複雑なことなかろうもん。
多重継承のダイヤモンド継承とかはどうかと思うが。
多重継承のダイヤモンド継承とかはどうかと思うが。
コードでdeleteしないと開放されないところとか、配列のインデックスを
チェックされないところとかかな
チェックされないところとかかな
*.hと*.cppとファイルが二つあるところ
むしろJavaのほうが覚えることは膨大じゃね？
makeを捨ててantとかいうビルドツールを使わなければいけないらしいぞ。
makeを捨ててantとかいうビルドツールを使わなければいけないらしいぞ。
686 ：仕様書無しさん：2005/12/16(金) 23:13:12
言語仕様の複雑さは C++ > Java > C だが、
ライブラリの複雑さは Java > C++ > C
ライブラリの複雑さは Java > C++ > C
たぶんライブラリと呼んでる部分はOSや環境にべったりな部分のことであろう。
そんなもんCでも変わらん。
そんなもんCでも変わらん。
javadocが使い易すぎる
690 ：仕様書無しさん：2005/12/17(土) 11:21:24
爺がいつまでmakeなんか使ってるんだよ。eclipseがあればそんなのｲﾗﾈ
692 ：仕様書無しさん：2005/12/17(土) 13:05:43
>>690
make も autoconf/automake つかえばラク。
テキストファイルに数行書くだけで、コンパイル、テスト、配布用アーカイブ生成とかを
やってくれる Makefile を自動生成してくれる。
まあこのへんは ant で Maven 使うのと一緒だけど。
make も autoconf/automake つかえばラク。
テキストファイルに数行書くだけで、コンパイル、テスト、配布用アーカイブ生成とかを
やってくれる Makefile を自動生成してくれる。
まあこのへんは ant で Maven 使うのと一緒だけど。
>>672
そういう発言するお前自身が文系の匂いがするぞ。
その発言に根拠がないからな。
根拠もなく憶測で「Javaには高卒文系が多い」とか言いだす輩は
理系人間じゃない。浅はかで文系的。
学会でJavaに関する研究、Javaを使った研究論文、
サブジェクトにJavaと名が付く論文がどれだけ
でているのか>>672はよくわかってないみたいだな。
情報処理学会、電子情報通信学会、IEEE学会など
数多くの学会でJavaを使った研究論文が投稿されている。
そういう発言するお前自身が文系の匂いがするぞ。
その発言に根拠がないからな。
根拠もなく憶測で「Javaには高卒文系が多い」とか言いだす輩は
理系人間じゃない。浅はかで文系的。
学会でJavaに関する研究、Javaを使った研究論文、
サブジェクトにJavaと名が付く論文がどれだけ
でているのか>>672はよくわかってないみたいだな。
情報処理学会、電子情報通信学会、IEEE学会など
数多くの学会でJavaを使った研究論文が投稿されている。
そもそも10年経ったJavaという言語を未だに流行といってる奴の
質が悪い。歴史的経緯も知らずに浅はかなことを言うのは文系的
質が悪い。歴史的経緯も知らずに浅はかなことを言うのは文系的
>>677
つか、Jakartaの英文ドキュメントすら
使いこなせないようではJavaもろくに使いこなせないだろ。
Jakarta Commonsの多くは翻訳されないままのが多いんだし。
HibernateやJBoss, Springだってまだまだ日本語ドキュメントが少ない。
英語読めないと最先端を行くことができないのはJavaでも同じ。
つか、Jakartaの英文ドキュメントすら
使いこなせないようではJavaもろくに使いこなせないだろ。
Jakarta Commonsの多くは翻訳されないままのが多いんだし。
HibernateやJBoss, Springだってまだまだ日本語ドキュメントが少ない。
英語読めないと最先端を行くことができないのはJavaでも同じ。
697 ：仕様書無しさん：2005/12/17(土) 13:21:05
>>685
antなんてmakeより簡単だろ
XMLなので冗長度が増してコード量が増えるが。
それよりもJavaを使いこなすためには
とにかく自動化ツールを使いこなせないと逝けないのが難点。
DBの設定、ネットワークの設定それらの設定ファイルを自動で
配備するにはAntやApache Mavenなどの自動化ツールを
つかいこなせないといけない。他にもHibernateやXDocletといった
自動化ツールも使いこなす必要がある。
テストの自動化を行うJUnit, Jakarta Cactus,
開発効率を高めるオープンソースIDE Eclipse とそれに使える数多くの膨大なプラグイン。
殆どのJavaの仕事ではこれらの技術を必要としている。
バージョン管理システムCVS, Subversionの使い方を覚える必要もある。
だがこれらの自動化ツールを使わずに手動で効率の悪いやり方で
Servlet開発をしているのが大半の会社のプロジェクトの現状。
未だにStrutsの使い方が解らない連中やO-Rマッピングって何？
テスト駆動開発って何？ JUnitって何？
って連中が多い。マネージャクラスの連中ですらそんなのばかり。
自動化ツールを使うだけでデスマーチは納期遅れは大幅に防げるのだが。
antなんてmakeより簡単だろ
XMLなので冗長度が増してコード量が増えるが。
それよりもJavaを使いこなすためには
とにかく自動化ツールを使いこなせないと逝けないのが難点。
DBの設定、ネットワークの設定それらの設定ファイルを自動で
配備するにはAntやApache Mavenなどの自動化ツールを
つかいこなせないといけない。他にもHibernateやXDocletといった
自動化ツールも使いこなす必要がある。
テストの自動化を行うJUnit, Jakarta Cactus,
開発効率を高めるオープンソースIDE Eclipse とそれに使える数多くの膨大なプラグイン。
殆どのJavaの仕事ではこれらの技術を必要としている。
バージョン管理システムCVS, Subversionの使い方を覚える必要もある。
だがこれらの自動化ツールを使わずに手動で効率の悪いやり方で
Servlet開発をしているのが大半の会社のプロジェクトの現状。
未だにStrutsの使い方が解らない連中やO-Rマッピングって何？
テスト駆動開発って何？ JUnitって何？
って連中が多い。マネージャクラスの連中ですらそんなのばかり。
自動化ツールを使うだけでデスマーチは納期遅れは大幅に防げるのだが。
うんんにゃ、殆どはそれ以前の問題の糞コード
699 ：仕様書無しさん：2005/12/17(土) 13:27:20
だいたい自動化ツールつかわなきゃならんほど
基本的な環境が整理されていないのが問題
鉄筋が少ないビルに無理やりつめこうもとするJAVAはあぼ
基本的な環境が整理されていないのが問題
鉄筋が少ないビルに無理やりつめこうもとするJAVAはあぼ
700 ：仕様書無しさん：2005/12/17(土) 13:28:08
ツールの使い方で悩むぐらいならMSのツール買った方が遙かに効率いいのは不具合なのか？
自動化ツールなのに「使いこなす必要がある」のがおかしい。
合理化のためのツールの習得、設定が合理的でないという不思議なツール
合理化のためのツールの習得、設定が合理的でないという不思議なツール
Visual J++が最強だな
703 ：仕様書無しさん：2005/12/17(土) 13:33:49
自動化ツールもJDKに含めれば問題ないと思うにょ
XDocletとCactusはいらないな
Hibernate、Springはまだ荒削りな印象。もう少し洗練されればいいんだが
JSTLあればStrutsは使わなくても問題ない
Hibernate、Springはまだ荒削りな印象。もう少し洗練されればいいんだが
JSTLあればStrutsは使わなくても問題ない
705 ：仕様書無しさん：2005/12/17(土) 13:38:49
しょうがないから教えてやる。
http://www-6.ibm.com/jp/domino04/software/ecatalog.nsf/byCategory/F85C097FE0B4E02B49256F42002547DF
これが真の商用版。
http://www-6.ibm.com/jp/domino04/software/ecatalog.nsf/byCategory/F85C097FE0B4E02B49256F42002547DF
これが真の商用版。
706 ：仕様書無しさん：2005/12/17(土) 13:39:34
当然買えない香具師らはおとなしくMS教に入信汁。
>>703
そんなものを含める含めないは言語仕様とは関係ない
そんなものを含める含めないは言語仕様とは関係ない
また全レスjava厨がきたのか
遷移マップをxmlに切り出す必要性って薄い気がする。
手間の割りに。初期ロードも遅くなるし。
複数のアクションからひとつのビューにマップされるのは非常に便利だと思うんだが、
ひとつのアクションから複数のビューにマップされる場合は、
結局そのアクションの中の処理に依存するんだから、
アクションの中にそれぞれ遷移先の情報があっていいような気がする。
というわけで、俺もStruts不要説提唱。
手間の割りに。初期ロードも遅くなるし。
複数のアクションからひとつのビューにマップされるのは非常に便利だと思うんだが、
ひとつのアクションから複数のビューにマップされる場合は、
結局そのアクションの中の処理に依存するんだから、
アクションの中にそれぞれ遷移先の情報があっていいような気がする。
というわけで、俺もStruts不要説提唱。
713 ：仕様書無しさん：2005/12/17(土) 14:27:28
>>708 あのさー、いまどきMakeMakeわめいてるのは時代錯誤で先祖返りなのよわかる？
いまやIDE全盛、テストまで自動化しようってご時世だよ？
あ、1970年代のUNIXに帰りたい方でしたか＾＾しつれいしますたｗ
あなたの仕事はIDE使ってるアシスタントのおねーちゃんにお願いしましたからお引き取りを＾＾
いまやIDE全盛、テストまで自動化しようってご時世だよ？
あ、1970年代のUNIXに帰りたい方でしたか＾＾しつれいしますたｗ
あなたの仕事はIDE使ってるアシスタントのおねーちゃんにお願いしましたからお引き取りを＾＾
714 ：仕様書無しさん：2005/12/17(土) 14:33:04
＞自動化ツールを使うだけでデスマーチは納期遅れは大幅に防げるのだが。
甘過ぎ。
雑誌読み齧っただけなのがバレバレだな（ｗ
甘過ぎ。
雑誌読み齧っただけなのがバレバレだな（ｗ
デスマの要因の殆どはコーディング以前にあるんだよ。
ﾄﾞｶﾀは無関係だから、知らなくても無理ないか・・・・
ﾄﾞｶﾀは無関係だから、知らなくても無理ないか・・・・
むしろドカタこそそれを痛感してるだろ。
原因を知らずに痛感だけするのさ・・・
業務系乙
今日本でもApache Mavenを使いこなせる香具師は少ない。
情報が少ないからな。
根気よく英語を読んで使いこなす以外に方法はない。
英文解説を読むことはヒアリングと比べればそんなに難しいものでもないと思うが。
情報が少ないからな。
根気よく英語を読んで使いこなす以外に方法はない。
英文解説を読むことはヒアリングと比べればそんなに難しいものでもないと思うが。
720 ：仕様書無しさん：2005/12/17(土) 17:03:03
>>713
っていうかおまえM$Build使ったことないの？
あれもApache Antの影響を受けて作られたNantを改良した
makeのXML版なんだけど。
IDEで足りない機能はああいうツールを使って補うのが当たり前なの。
M$様が作った作ったIDEが万能のツールだったら
わざわざ外部ツールやmake系ビルドツールなんて使わないって言うの。
っていうかおまえM$Build使ったことないの？
あれもApache Antの影響を受けて作られたNantを改良した
makeのXML版なんだけど。
IDEで足りない機能はああいうツールを使って補うのが当たり前なの。
M$様が作った作ったIDEが万能のツールだったら
わざわざ外部ツールやmake系ビルドツールなんて使わないって言うの。
MSBuildは最強です。
722 ：仕様書無しさん：2005/12/17(土) 17:58:41
>>720 はぁ？Ant系と古式ゆかしきGNU-MAKEを同列に扱う気？
AutoｃonfやAutomakeに慣れた連中がツールにはき出させてるスクリプトをそのまま解読して
悦に入ってる厨のことを言ったんだけどわかんないの？
ま、AntはJavaないと動かないから嫌いだったりするわけだがなｗｗｗ
AutoｃonfやAutomakeに慣れた連中がツールにはき出させてるスクリプトをそのまま解読して
悦に入ってる厨のことを言ったんだけどわかんないの？
ま、AntはJavaないと動かないから嫌いだったりするわけだがなｗｗｗ
Javaで動くものは何でも嫌いか
知らず知らずのうちにJavaで動く製品を使っていることにも気づかずに
最後の最後まで負け惜しみを口にするお前が哀れ
知らず知らずのうちにJavaで動く製品を使っていることにも気づかずに
最後の最後まで負け惜しみを口にするお前が哀れ
726 ：仕様書無しさん：2005/12/17(土) 18:46:43
Javaが嫌いつうか、そらJava考案して実際に動かしてきたSunのエンジニアは神だろ。
でもいわゆるJava厨房は単に糞^23ぐらいの単なる伝道師だからな。
貧乏人に優しくない、そういってみれば零戦しか作れる乗れるリソース無いのに
無理矢理B29動かすリソースないとまともに動かないJava持ってきて
先進性があるんだの移植性が優れてるの抜かされてもねえ・・・・。
そしていくところは発注ミス＞デイトレーダーうまーだものな。
さぞ応答性に難があったんだろうなｗｗ
でもいわゆるJava厨房は単に糞^23ぐらいの単なる伝道師だからな。
貧乏人に優しくない、そういってみれば零戦しか作れる乗れるリソース無いのに
無理矢理B29動かすリソースないとまともに動かないJava持ってきて
先進性があるんだの移植性が優れてるの抜かされてもねえ・・・・。
そしていくところは発注ミス＞デイトレーダーうまーだものな。
さぞ応答性に難があったんだろうなｗｗ
727 ：仕様書無しさん：2005/12/17(土) 18:50:59
MSBuildが最強なのは当たり前。MS様は世界中の技術をどん欲に取り込み、咀嚼したあげく
骨抜きにして同化するのが信条だからな。それに自社のぶっ飛んだ技術組み合わせるんだから
他の追随するところじゃなかろ。
というわけで、この先は・・・数量ベースで
PC系だったら VB＞＞C#＞＞C++＞＞果てしなく深い溝＞＞JAVAってことになるんだろうな。
Java厨房は携帯機器やらに流れてひたすら特殊化と分化の歴史をたどる運命だ。
そして滅亡する。間違いない。
骨抜きにして同化するのが信条だからな。それに自社のぶっ飛んだ技術組み合わせるんだから
他の追随するところじゃなかろ。
というわけで、この先は・・・数量ベースで
PC系だったら VB＞＞C#＞＞C++＞＞果てしなく深い溝＞＞JAVAってことになるんだろうな。
Java厨房は携帯機器やらに流れてひたすら特殊化と分化の歴史をたどる運命だ。
そして滅亡する。間違いない。
どうしたらJavaが滅亡できるのか727の筋書きを見てみたいよ。
729 ：仕様書無しさん：2005/12/17(土) 19:02:33
簡単だな、Sunが業績悪化のあげく、アップルと同じくMSの軍門に下るんだよ。
そして骨抜き。Javaは特殊用途向けにますます特殊化の道へ
Javaというなの何か、になると思われる。
そして骨抜き。Javaは特殊用途向けにますます特殊化の道へ
Javaというなの何か、になると思われる。
来日して何ヶ月ですか？
>>729
.netでVSがJava化したのがそんなに腹に据えかねるのか！？
.netでVSがJava化したのがそんなに腹に据えかねるのか！？
732 ：仕様書無しさん：2005/12/17(土) 19:13:13
まあ、ここでぐだぐだ言ってるJava厨も間違いなく半数以上は１０年以内に淘汰されるわけで。
後の半数が１０年後なにのたまわってるか是非拝聴したいものだがなｗ
後の半数が１０年後なにのたまわってるか是非拝聴したいものだがなｗ
Unix畑のハッカーもPG技術の習得にはJavaを勧めてるし
なくなるこたねーよ、20年先は過疎ってるかもしれんがね
なくなるこたねーよ、20年先は過疎ってるかもしれんがね
彼らの推薦はあくまでも習得であって、その後にC/C++があるのが前提だ。
おまいリアル馬鹿だな。
おまいリアル馬鹿だな。
実際問題、ここ数年は常にJavaにリードされてそのほかの言語がついて来てる感じはあるな。
まあ、Javaで開発が出来れば大抵の開発は出来るからな。
VSべったりのカタワPGとは出来がちがわ。
まあ、Javaで開発が出来れば大抵の開発は出来るからな。
VSべったりのカタワPGとは出来がちがわ。
Windows＋VC++の世界とLinux＋C++の世界って全然別物だよな？
Windows＋VC++でOOD原則とかデザパタを意識した事ある人って居る？
Windows＋VC++でOOD原則とかデザパタを意識した事ある人って居る？
>>734
あったとしてもJavaがそれだけ使いやすいってことだろ。
マルチスレッドプログラミングも高度なレベルJavaで習得できる。
Pythonも教育用言語だが、Linuxでは実用としても使われている。
覚えやすいってのはそれだけで得なんだよ。
あったとしてもJavaがそれだけ使いやすいってことだろ。
マルチスレッドプログラミングも高度なレベルJavaで習得できる。
Pythonも教育用言語だが、Linuxでは実用としても使われている。
覚えやすいってのはそれだけで得なんだよ。
Pascalは教育用には絶賛されてた時代があるけど
今ではあんまり使われてない。
今ではあんまり使われてない。
Cがあるからだろ
740 ：仕様書無しさん：2005/12/17(土) 20:46:44
>>735 ミスリードもいいとこだがな
>マルチスレッドプログラミングも高度なレベルJavaで習得できる。
Javaのマルチスレッドはまだとても使い物になるレベルとは言いがたいと思うがどうか？
Javaのマルチスレッドはまだとても使い物になるレベルとは言いがたいと思うがどうか？
742 ：仕様書無しさん：2005/12/17(土) 21:27:20
金出せば楽できるからそれでいいじゃない。
お前ら考え方がおかしいよ。貧乏人は時間をかける。
金ある時は金で時間を買う。それだけの違いだろ？
開発ってそういうものだ。いや、世の中ってそういうものだ。
プログラマってプログラミングに特化した考え方しかできないよね。
視野が狭いっていうか、馬鹿っていうか。
お前ら考え方がおかしいよ。貧乏人は時間をかける。
金ある時は金で時間を買う。それだけの違いだろ？
開発ってそういうものだ。いや、世の中ってそういうものだ。
プログラマってプログラミングに特化した考え方しかできないよね。
視野が狭いっていうか、馬鹿っていうか。
>>742
素人が迷い込んできたな、という印象。
素人が迷い込んできたな、という印象。
>>743
実際現状の使われ方っておまけ的だし(○○待ちとかそんなんばっかだし、あっても単純なバックグラウンド処理)
Cωが色々研究しているみたいだがどうなるのか興味深深な所ですかね。
低動作クロック多数コアがこれからのメインストリームになりそうなので結構重要度高い気がする。
実際現状の使われ方っておまけ的だし(○○待ちとかそんなんばっかだし、あっても単純なバックグラウンド処理)
Cωが色々研究しているみたいだがどうなるのか興味深深な所ですかね。
低動作クロック多数コアがこれからのメインストリームになりそうなので結構重要度高い気がする。
複数CPUの鯖リソースをガンガン使うために業務屋といえど普通にやってるよ＜マルチスレッド
>>746
現状では処理単位をでかくした、つまらないマルチスレッドだけだと思われ
現状では処理単位をでかくした、つまらないマルチスレッドだけだと思われ
GUIなどのイベントドリブン用スレッドじゃダメ
デーモンでもダメ、CPUイジメもダメ
何をどうしたら高度なスレッドなん？
デーモンでもダメ、CPUイジメもダメ
何をどうしたら高度なスレッドなん？
749 ：仕様書無しさん：2005/12/17(土) 22:43:58
何もしないスレッドが大量にあるのが高度で抽象的なのだと思われる
デュアルCPUでもプロセス/スレッドが複数動いてないと効果がないんだな
751 ：仕様書無しさん：2005/12/17(土) 23:25:51
>>750
OSの勉強をしてくれ。
OSの勉強をしてくれ。
今んところ、マルチプロセッサを使い切るマルチスレッド環境は
Win32ネィティブ位しかないよ。
もっとも、Win32の場合はそれがサーバとしては悪い方向にも作用しているけど。
Win32ネィティブ位しかないよ。
もっとも、Win32の場合はそれがサーバとしては悪い方向にも作用しているけど。
753 ：仕様書無しさん：2005/12/17(土) 23:31:17
つまり、マルチスレッドに関してはJavaはVB.NET以下である。
>>745
お前、サーバサイドで接続待ち受ける処理描くとき、どう描いてるんだよ、ぬけさく。
お前、サーバサイドで接続待ち受ける処理描くとき、どう描いてるんだよ、ぬけさく。
756 ：仕様書無しさん：2005/12/17(土) 23:49:28
Javaには言語仕様にマルチスレッドが含まれているんで、
誰でも理解できるという点ですばらしいとは思う。
ただ、いくら頑張ってマルチスレッドやっても、Javaそのものの実装が
これを効率的にやってくれないんじゃ意味がない。
正しく動くが効率的には動いていない。
C/C++では、マルチスレッドプログラムは、あくまでもプログラマーの
腕で生きも死にもする。中級レベルの C/C++屋さんと腕のあるJava屋で
最終成果物は同じパフォーマンスをたたき出す。
Javaには超えられない壁がある。ただ、Javaの庇護の下ハッピーになれる
奴がいるのも確かだが。
誰でも理解できるという点ですばらしいとは思う。
ただ、いくら頑張ってマルチスレッドやっても、Javaそのものの実装が
これを効率的にやってくれないんじゃ意味がない。
正しく動くが効率的には動いていない。
C/C++では、マルチスレッドプログラムは、あくまでもプログラマーの
腕で生きも死にもする。中級レベルの C/C++屋さんと腕のあるJava屋で
最終成果物は同じパフォーマンスをたたき出す。
Javaには超えられない壁がある。ただ、Javaの庇護の下ハッピーになれる
奴がいるのも確かだが。
>>736
ﾉｼ
ﾉｼ
とはいっても、普通にJavaのスレッドで沢山なんだけどな。
759 ：仕様書無しさん：2005/12/17(土) 23:52:24
自分たちがしこしこ書き溜めたものが全部パーになって負け惜しみたらたらか、すくえねー。
761 ：69式フリーPG ◆hND3Lufios ：2005/12/17(土) 23:52:56
Pascalはあくまで教育向けであって、本来は分割コンパイルすらサポートされてなく、
実用的ではないな。Niklaus Wirthもそういう用途にはModula-2を想定していたと思う。
PascalにUnit等の独自拡張を施して使える言語にしたのは、Bolandのデヴ
もとい、Philippe Kahn。
実用的ではないな。Niklaus Wirthもそういう用途にはModula-2を想定していたと思う。
PascalにUnit等の独自拡張を施して使える言語にしたのは、Bolandのデヴ
もとい、Philippe Kahn。
Tomcatがマルチスレッドだと知らない人がいると聞いて飛んできました！
Javaのようなマルチスレッドのスタイルだと今後のプロセッサの性能向上にあやかれないというのが今後の問題になるかもね。
あの構造だと動作クロックの向上以外で高速化しないし、熱問題はこれ以上の動作クロック向上は困難間違いなし、
そうなると今以上の処理要求があっても応えることが難しくなる。
あの構造だと動作クロックの向上以外で高速化しないし、熱問題はこれ以上の動作クロック向上は困難間違いなし、
そうなると今以上の処理要求があっても応えることが難しくなる。
765 ：仕様書無しさん：2005/12/18(日) 01:30:05
>>765
使ってみたら、2CPU/4ハードスレッドのマシンだと余程マルチスレッドを意識したアプリでもない限りCPUリソース利用効率は50%すら超えてくれないよ。
使ってみたら、2CPU/4ハードスレッドのマシンだと余程マルチスレッドを意識したアプリでもない限りCPUリソース利用効率は50%すら超えてくれないよ。
>>764
VMを高速化すりゃいいんじゃないかと。
VMを高速化すりゃいいんじゃないかと。
>>767
ぶっちゃけ構造上無理
ぶっちゃけ構造上無理
769 ：仕様書無しさん：2005/12/18(日) 01:37:44
>>769
リナックス・ウインドウ共にダメ、要するにほぼ全部ダメ
リナックス・ウインドウ共にダメ、要するにほぼ全部ダメ
Win32のI/O完了ポートみたいな機構が無いと無理だな。
結局I/O待ちのスレッドが増えるだけ。CPUはすかすかってことになる。
結局I/O待ちのスレッドが増えるだけ。CPUはすかすかってことになる。
んじゃI/Oが早くなりゃ自然とCPU使用率あがるんじゃ。
773 ：仕様書無しさん：2005/12/18(日) 01:44:10
>>770
OSのバージョンにもよるよ。
Windows は、XP？
リナックスのカーネルのバージョンは？
最近のＯＳでシングルスレッドアプリでＣＰＵ片方が０％のままなら
>>771 さんの言うとおりかな。
OSのバージョンにもよるよ。
Windows は、XP？
リナックスのカーネルのバージョンは？
最近のＯＳでシングルスレッドアプリでＣＰＵ片方が０％のままなら
>>771 さんの言うとおりかな。
I./Oの速度とCPUの処理速度に圧倒的な差が生じてしまった現代では、
少々速くなった程度では無意味。
少々速くなった程度では無意味。
>I/Oが早くなりゃ自然とCPU使用率あがるんじゃ
できるもんならやってるって感じですかねw
それ以前に色々つっこみたいけどw
できるもんならやってるって感じですかねw
それ以前に色々つっこみたいけどw
776 ：仕様書無しさん：2005/12/18(日) 01:49:45
初心者ですがちょっと教えていただけますか？
JavaアプリからWindowsアプリへウィンドウズメッセージは送れますか？
全く無理ですか？
JavaアプリからWindowsアプリへウィンドウズメッセージは送れますか？
全く無理ですか？
んまあハード屋ではないので、アレなんだが。
今後早くならないことを証明すんのは難しいんじゃないかと。
今後早くならないことを証明すんのは難しいんじゃないかと。
778 ：仕様書無しさん：2005/12/18(日) 01:51:08
CPU パワーを食う NIC を使えばいいんじゃね？
やろうと思えばでるきとは思うが・・・・
>>778
無駄使いしてどうするw
無駄使いしてどうするw
I/O待ちのスレッドが増えると今度はコンテキストスイッチの分が
増えてしまってCPUが働かなくなる。
だから、OSレベルで常にCPUが働くような状態にスレッド数を調整する機構が
必要になってくる。またI/Oを要求したスレッドと別のスレッドが結果を処理
できる必要も生じる。
増えてしまってCPUが働かなくなる。
だから、OSレベルで常にCPUが働くような状態にスレッド数を調整する機構が
必要になってくる。またI/Oを要求したスレッドと別のスレッドが結果を処理
できる必要も生じる。
>>778
PCIバスの帯域が先に飽和するぞｗ
PCIバスの帯域が先に飽和するぞｗ
>>777
高速化は難しくないらしいが、高速化による急激な消費電力の増大が招く各種問題が解決しにくいとの事。
それで低速にして大量に搭載して、スペックは維持もしくは向上すればちょっとは状況はよくなるのではという話。
この場合ソフトウエアにしわ寄せが来るが、それがマルチスレッドって所。
高速化は難しくないらしいが、高速化による急激な消費電力の増大が招く各種問題が解決しにくいとの事。
それで低速にして大量に搭載して、スペックは維持もしくは向上すればちょっとは状況はよくなるのではという話。
この場合ソフトウエアにしわ寄せが来るが、それがマルチスレッドって所。
784 ：仕様書無しさん：2005/12/18(日) 01:58:39
このスレに来る奴って、アプリケーションの動作しか興味がないっていうか
知らないんだろう。より下層の話しを理解してなければ、スレッドやプロセスの
話しはできない。
スレッドと言っても、Linuxではプロセスのcloneだし。
知らないんだろう。より下層の話しを理解してなければ、スレッドやプロセスの
話しはできない。
スレッドと言っても、Linuxではプロセスのcloneだし。
785 ：仕様書無しさん：2005/12/18(日) 02:00:14
はたまた、ユーザスレッド、カーネルスレッドでやってることは違ったりする。
つきつめていくと、ハードウェア制御しないと本当の意味で思い通りにスケジューリングすることは不可能。
つきつめていくと、ハードウェア制御しないと本当の意味で思い通りにスケジューリングすることは不可能。
786 ：69式フリーPG ◆hND3Lufios ：2005/12/18(日) 02:01:45
SMP機は最高速度が上がるというより、負荷に対して余裕がでるんだな。
電池を直列と並列に繋いだ小学校の実験みたいな。
電池を直列と並列に繋いだ小学校の実験みたいな。
学生さん?
788 ：仕様書無しさん：2005/12/18(日) 12:28:11
789 ：仕様書無しさん：2005/12/18(日) 13:10:17
>>784
年がばれるｗ。
Windows 以降抽象化が進んで、実際にチップ、OSがどんな風に
動作しているのかイメージがつかめていない人が多くなってきているのは
確かだね。そういう技術者が増えてるから、Java的な抽象化された言語が
なくなる事はないんだろうね。
年がばれるｗ。
Windows 以降抽象化が進んで、実際にチップ、OSがどんな風に
動作しているのかイメージがつかめていない人が多くなってきているのは
確かだね。そういう技術者が増えてるから、Java的な抽象化された言語が
なくなる事はないんだろうね。
790 ：仕様書無しさん：2005/12/18(日) 13:36:02
NIC、グラボもチップセットに内蔵されている時代、CPUもメモリも
コソリと消費されている。BIOSの設定とか使うOSのバージョンとか・・・
コソリと消費されている。BIOSの設定とか使うOSのバージョンとか・・・
>>124
遅レスでなんだが、
http://slashdot.jp/？oku/journal/327177
http://slashdot.jp/？oku/journal/327943
という意見もある。
遅レスでなんだが、
http://slashdot.jp/？oku/journal/327177
http://slashdot.jp/？oku/journal/327943
という意見もある。
793 ：仕様書無しさん：2005/12/19(月) 02:13:27
Boland C++って、C++コンパイラの中では最適化がお粗末な方なんだけどな。
Visual C++やIntel C++が相手ならどうなることやら。。。
Visual C++やIntel C++が相手ならどうなることやら。。。
795 ：仕様書無しさん：2005/12/19(月) 04:19:58
一昔前なら最適化で速度の差がかなり出た（大昔のCPUは分岐ジャンプ命令の手前で
キャッシュがストップしたりする）が、今の時代、あまり関係ない気がする。
アセンブラがりがり書いてた職人かなんかかおまえは。
キャッシュがストップしたりする）が、今の時代、あまり関係ない気がする。
アセンブラがりがり書いてた職人かなんかかおまえは。
796 ：仕様書無しさん：2005/12/19(月) 08:38:37
Pentium4 使ってるが、それでも適当に書いたプログラムを gcc -O0 と
gcc-O3 とでコンパイルするのではやっぱり速度は全然違うぞ。
ということはコンパイラが違っても今でも速度は変わるんｼﾞｬﾏｲｶ。
gcc-O3 とでコンパイルするのではやっぱり速度は全然違うぞ。
ということはコンパイラが違っても今でも速度は変わるんｼﾞｬﾏｲｶ。
797 ：仕様書無しさん：2005/12/19(月) 09:19:29
798 ：仕様書無しさん：2005/12/19(月) 22:25:30
コンパイラで速度は変わる。
以前仕事で調べた。
インテルコンパイラが最速だった。
以前仕事で調べた。
インテルコンパイラが最速だった。
ｵﾌﾟｿﾏﾝｾｰのJava厨はGCCが最強と思ってるだろうけどなー
Java厨って一昔前のマック信者と同じ臭いがする
801 ：仕様書無しさん：2005/12/19(月) 22:40:59
実行時の速度より起動時の速度が我慢ならん。
802 ：仕様書無しさん：2005/12/19(月) 22:45:02
だ・か・ら・Java に速度を求めるなって・・・。
803 ：仕様書無しさん：2005/12/19(月) 22:47:48
だってさー、Cより速いとか寝言言ってるアフォが居るじゃん？
804 ：仕様書無しさん：2005/12/19(月) 23:05:37
ほっとけって、ビギナー相手にしなくていいって。
Javaのエキスパートは、意地張って嘘こいたりしないから。
Javaのエキスパートは、意地張って嘘こいたりしないから。
エキスパートJava厨たる俺様はネイティブならD言語を使う。
・・・いやさ、DMC++も実績あるしさ、いいでしょ？ダメ？
・・・いやさ、DMC++も実績あるしさ、いいでしょ？ダメ？
C厨のおっさんども。
そんなに速いのが優れてると思うなら、アセンブラ使えアセンブラ。
アセンブラでCGIを書いてみろ
そんなに速いのが優れてると思うなら、アセンブラ使えアセンブラ。
アセンブラでCGIを書いてみろ
10年程度でエキスパートを自称する人間が
本当にエキスパートであった例を知らないが
本当にエキスパートであった例を知らないが
10年もやったら厨じゃいられなくなるだろ
空気嫁ばか
空気嫁ばか
809 ：仕様書無しさん：2005/12/19(月) 23:34:22
810 ：仕様書無しさん：2005/12/19(月) 23:35:44
10年でエキスパートに慣れない奴はこの仕事向いてない。
811 ：仕様書無しさん：2005/12/20(火) 00:04:10
>>806
昔のHPにあった超鈍足malloc()みたいなもんでも登場しない限り、アセンブラなんて使わんだろ。
昔のHPにあった超鈍足malloc()みたいなもんでも登場しない限り、アセンブラなんて使わんだろ。
>>776
WIN32APIを使いなさい。
WIN32APIを使いなさい。
今はコンパイラの出来とアセンブラの必要性には関係がないでしょ。
単にお前らに必要なかっただけだろうが。
単にお前らに必要なかっただけだろうが。
815 ：仕様書無しさん：2005/12/20(火) 01:56:18
昔ほど、速度を気にすることはなくなったなぁ。
かつてアセンブラしらない若いＣプログラマーが叩かれたように、
今は、Ｃを知らない若いＪＡＶＡプログラマーが叩かれております・・・
今は、Ｃを知らない若いＪＡＶＡプログラマーが叩かれております・・・
817 ：仕様書無しさん：2005/12/20(火) 03:28:18
ちょwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwおまwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
818 ：仕様書無しさん：2005/12/20(火) 07:16:02
>>811 コーディングマシーンとしての壁がそんなもんだな。
819 ：仕様書無しさん：2005/12/20(火) 07:23:25
言語を問わず、論理だけで（コメント抜きで）まともに動作するプログラムの生産量は1KL/Mと言われて久しい。
おまいらの生産性は如何？ｗ
書いたものを説明することはできないことはわかってるさ。
でもそれって何なんだろうなｗ
おまいらの生産性は如何？ｗ
書いたものを説明することはできないことはわかってるさ。
でもそれって何なんだろうなｗ
820 ：仕様書無しさん：2005/12/20(火) 10:01:02
なんとなく
ここのJava厨を見ていると3D等の高度化した技術に付いて行けなくなった元ゲーム屋で現在ケータイしかできる仕事がなくなった奴のような雰囲気がする
ここのJava厨を見ていると3D等の高度化した技術に付いて行けなくなった元ゲーム屋で現在ケータイしかできる仕事がなくなった奴のような雰囲気がする
「C++の重要性は高まっている」：同言語の生みの親が主張
ttp://japan.cnet.com/news/ent/story/0,2000047623,20083118,00.htm
お前らのレスよりかは説得力あるかもな、一応生みの親だしｗ
ttp://japan.cnet.com/news/ent/story/0,2000047623,20083118,00.htm
お前らのレスよりかは説得力あるかもな、一応生みの親だしｗ
822 ：仕様書無しさん：2005/12/20(火) 11:35:54
ネイティブは最強
JAVAは糞
JAVAは糞
>>803
前調べた事があるんだが、Java の実行時コンパイラには
他の言語には望むべくもない「複数のコンパイル単位に
跨った最適化」というものがある。
条件が重なれば、他のどのネイティブコンパイラよりも
速くなる事もない事もない。
前調べた事があるんだが、Java の実行時コンパイラには
他の言語には望むべくもない「複数のコンパイル単位に
跨った最適化」というものがある。
条件が重なれば、他のどのネイティブコンパイラよりも
速くなる事もない事もない。
824 ：仕様書無しさん：2005/12/20(火) 13:07:12
>>823
メモリにロードする時間も含めた実行時間でJAVAが勝てる可能性はゼロ
メモリにロードする時間も含めた実行時間でJAVAが勝てる可能性はゼロ
>>823
ふうん。まあ、あり得ない話じゃないけど。
その「条件」とやらを現在の平均的なJavaプログラマに
理解させて実施させるコストのことを考えると・・・。非現実的な解だなぁ。
理論上の話を実用上の問題に出されてもねぇ
ふうん。まあ、あり得ない話じゃないけど。
その「条件」とやらを現在の平均的なJavaプログラマに
理解させて実施させるコストのことを考えると・・・。非現実的な解だなぁ。
理論上の話を実用上の問題に出されてもねぇ
>>691
一応、ム板のEclipseスレに出没するC厨C++厨は
EclipseのCDTプラグインでMakeFileを手書きで書いている。
そういう連中が多い。
Java屋はEclipseに加えてAntとMaven, XDocletを使うわけだが。
一応、ム板のEclipseスレに出没するC厨C++厨は
EclipseのCDTプラグインでMakeFileを手書きで書いている。
そういう連中が多い。
Java屋はEclipseに加えてAntとMaven, XDocletを使うわけだが。
>>712
XDocletかアノテーションを使えばStrutsの煩雑さは最小限に
押さえられる。
Sturtsが嫌ならJakarta Tapestryを使え。
それからJakarta Velocity + Apache Strutsという組み合わせもありだ。
XDocletかアノテーションを使えばStrutsの煩雑さは最小限に
押さえられる。
Sturtsが嫌ならJakarta Tapestryを使え。
それからJakarta Velocity + Apache Strutsという組み合わせもありだ。
>>828
＞XDocletかアノテーションを使えばStrutsの煩雑さは最小限に
＞押さえられる。
でもいらない。
＞Sturtsが嫌ならJakarta Tapestryを使え。
＞それからJakarta Velocity + Apache Strutsという組み合わせもありだ。
代替案になってないよ。
画面の遷移を外だしするような仕組み自体、いらないっての。
＞XDocletかアノテーションを使えばStrutsの煩雑さは最小限に
＞押さえられる。
でもいらない。
＞Sturtsが嫌ならJakarta Tapestryを使え。
＞それからJakarta Velocity + Apache Strutsという組み合わせもありだ。
代替案になってないよ。
画面の遷移を外だしするような仕組み自体、いらないっての。
>>825
「条件」に合わせて書けって話じゃない。
C++ で、ループ内でメンバ変数を操作する小さい関数を呼ぶと、
当然ながらメモリ操作するコードをインライン展開する。
ループ内では書き換えだけで参照しかしていない場合でもそう。
なんでかっつーと、他スレッドで参照する場合があるから。
(メンバ変数を mutable にして、メンバ関数を const にすれば
レジスタだけで済むが、これは幾らなんでも酷い手法)
ところが最近の JVM だと、他所で参照してないと判断すると
ループ内は全部レジスタ操作だけで済ませて、抜けた後で
変数の書き換えをするコードを吐く、らしい。
まあこの例からは JVM の出来がいいのが解るだけで
Java の言語仕様そのものとは関係ない話 (多分) だな。
.NET でもいずれそれくらいは出来るようになったり、
その他の言語でも一旦中間言語に落とすカタチにすれば
いいんだし。でも、現時点では Java のみの芸当なわけよ。
尤も、その「平均的なJavaプログラマ」の出来がかなりアレで
アプリケーションの構造そのものが「実行効率なんか
JVM が配慮すべきもの」とでも思ってんじゃねーか的な作りに
なってたり、JVM がメモリ莫迦喰いする所為でスワップが大量発生
したりするから、どんだけ最適化が凄くても意味 Nothing なんだけどな。
「条件」に合わせて書けって話じゃない。
C++ で、ループ内でメンバ変数を操作する小さい関数を呼ぶと、
当然ながらメモリ操作するコードをインライン展開する。
ループ内では書き換えだけで参照しかしていない場合でもそう。
なんでかっつーと、他スレッドで参照する場合があるから。
(メンバ変数を mutable にして、メンバ関数を const にすれば
レジスタだけで済むが、これは幾らなんでも酷い手法)
ところが最近の JVM だと、他所で参照してないと判断すると
ループ内は全部レジスタ操作だけで済ませて、抜けた後で
変数の書き換えをするコードを吐く、らしい。
まあこの例からは JVM の出来がいいのが解るだけで
Java の言語仕様そのものとは関係ない話 (多分) だな。
.NET でもいずれそれくらいは出来るようになったり、
その他の言語でも一旦中間言語に落とすカタチにすれば
いいんだし。でも、現時点では Java のみの芸当なわけよ。
尤も、その「平均的なJavaプログラマ」の出来がかなりアレで
アプリケーションの構造そのものが「実行効率なんか
JVM が配慮すべきもの」とでも思ってんじゃねーか的な作りに
なってたり、JVM がメモリ莫迦喰いする所為でスワップが大量発生
したりするから、どんだけ最適化が凄くても意味 Nothing なんだけどな。
それをバイトコードでやってるんじゃ無駄としか言い様が無いな。
>>826
ごめん、それって厨房の所業だと思えんのだが。俺、わかってない？
ごめん、それって厨房の所業だと思えんのだが。俺、わかってない？
PHPではだめですか?(´･ω･｀)
漏れ、C++やJavaはやらずPHP仕事オンリーの会社なんだけど
オブジェクト指向やデザインパターンなどのプログラミングスキルや
設計技術が身につけばこの先やっていけるかな・・・orz
漏れ、C++やJavaはやらずPHP仕事オンリーの会社なんだけど
オブジェクト指向やデザインパターンなどのプログラミングスキルや
設計技術が身につけばこの先やっていけるかな・・・orz
昔の事務処理代行だね。
ソフトと名の付く仕事はどこでも、人身売買するほうに回らないとまず仕事無くなる。
そういうことがだいたいわかったｗ
ソフトと名の付く仕事はどこでも、人身売買するほうに回らないとまず仕事無くなる。
そういうことがだいたいわかったｗ
>>835
とりあえずはPHPを極めれ。
しかし、休日や帰宅して晩酌のつまみに、自宅のPCにGCCやJDKを
インストールして遊んでみるといい。趣味として。
んで、仕事のほうでは言語とかではなく、客がこうしてと言ったから
こうするのではなく、背景に客がどういう望みがあってそういうことを
言っているのか考えてみたりとか、何か思いついたらそれを逆に
客に提案してみたりとか、もちろん最初は笑われたり駄目だしされるだろうけど、
どうしたら本当の要望にたどり着けるか、どう言えば説得力をもたせられるか、
どういう文書を書けばいいかとか、要求定義や基本設計に関わることに
精をだせばいい。
そのうち、趣味でやってたJavaやC++が陽の目をみる。
とりあえずはPHPを極めれ。
しかし、休日や帰宅して晩酌のつまみに、自宅のPCにGCCやJDKを
インストールして遊んでみるといい。趣味として。
んで、仕事のほうでは言語とかではなく、客がこうしてと言ったから
こうするのではなく、背景に客がどういう望みがあってそういうことを
言っているのか考えてみたりとか、何か思いついたらそれを逆に
客に提案してみたりとか、もちろん最初は笑われたり駄目だしされるだろうけど、
どうしたら本当の要望にたどり着けるか、どう言えば説得力をもたせられるか、
どういう文書を書けばいいかとか、要求定義や基本設計に関わることに
精をだせばいい。
そのうち、趣味でやってたJavaやC++が陽の目をみる。
C#とかVBとかだったら、
専用ツールがなければ快適にプログラミング出来なかったが、
Javaならメモ帳でも普通に出来た。
Eclipse最高。
RAD開発しないなら、
VisualStudioより使いやすいぞ！
専用ツールがなければ快適にプログラミング出来なかったが、
Javaならメモ帳でも普通に出来た。
Eclipse最高。
RAD開発しないなら、
VisualStudioより使いやすいぞ！
839 ：仕様書無しさん：2005/12/22(木) 19:43:11
VBもC#もメモ帳で開発出来るよな。
やらないけど。
やらないけど。
趣味で始める人間がいたとして
例えばすぐ自分や他人の環境で楽しめるデスクトップアプリつくろうか、となった場合
JAVAはやらんだろ・・・・
ホームページ用？でもアプレット使ってるのここ数年ほとんど見ないし
例えばすぐ自分や他人の環境で楽しめるデスクトップアプリつくろうか、となった場合
JAVAはやらんだろ・・・・
ホームページ用？でもアプレット使ってるのここ数年ほとんど見ないし
趣味だったらVBが一番だと思うよ。
デスクトップアプリだったらJavaもCもC++もC#もVBにはかなわないよ。
だってVB楽だもんマジで。
デスクトップアプリだったらJavaもCもC++もC#もVBにはかなわないよ。
だってVB楽だもんマジで。
Windowsしか使えん
844 ：仕様書無しさん：2005/12/23(金) 00:20:10
趣味に合理性もとめてどうする。好きなもの使うに決まってる。
Java が好きならJavaがいい、C++が好きならC++がいい。
Java が好きならJavaがいい、C++が好きならC++がいい。
>>835
PHPは名前空間が使えないからね。
同じ型に甘い言語Perlより糞だったりする。
地っこいプログラム書いてちっちゃい金稼ぐにはええんじゃねえの？
ハイエンドサーバ向けアプリケーションを作るには
PHPやPerlやCGI + C/C++じゃあまりにも弱すぎるがな。
PHPは名前空間が使えないからね。
同じ型に甘い言語Perlより糞だったりする。
地っこいプログラム書いてちっちゃい金稼ぐにはええんじゃねえの？
ハイエンドサーバ向けアプリケーションを作るには
PHPやPerlやCGI + C/C++じゃあまりにも弱すぎるがな。
>>839
一年間だけただっていうのもねえ。
それにEclipseと比べプラグインが貧弱。
膨大なプラグイン数ではVS.NETはEclipseには
かなわない。それにオープンソースってのが大きい。
M$のような一社が開発しているのではなく
IBM, Intel, 日立、東芝、モトローラ、Oracleなど
数多くの企業がEclipseの開発にかかわっている。
それが大きい。
一年間だけただっていうのもねえ。
それにEclipseと比べプラグインが貧弱。
膨大なプラグイン数ではVS.NETはEclipseには
かなわない。それにオープンソースってのが大きい。
M$のような一社が開発しているのではなく
IBM, Intel, 日立、東芝、モトローラ、Oracleなど
数多くの企業がEclipseの開発にかかわっている。
それが大きい。
CDT向けのプラグインってそんなに多いの？
850 ：仕様書無しさん：2005/12/24(土) 15:56:29
>>841
今Applet作る香具師は少ないが
かわりにJavaWebStartをやる香具師が出てきている。
それにJava3Dは面白い。
Javaでゲームを作ってる香具師も増えてきている。
なにより、Java GUIが再生してきている動きが見える。
NetBeansの影響かね。
あのIDEはEclipseよりも速いしGUI開発には非常に適している。
今Applet作る香具師は少ないが
かわりにJavaWebStartをやる香具師が出てきている。
それにJava3Dは面白い。
Javaでゲームを作ってる香具師も増えてきている。
なにより、Java GUIが再生してきている動きが見える。
NetBeansの影響かね。
あのIDEはEclipseよりも速いしGUI開発には非常に適している。
851 ：仕様書無しさん：2005/12/24(土) 15:57:14
JavaがC++を追い抜く日
kazekiriによる 2005年12月06日 12時44分の掲載
ハヤリスタリ部門より．
Java
プログラミング
Index
デベロッパー
vladobossdog曰く、" ITmediaに記事が出ているが、 世界最大のオープンソ
ースソフトウェア開発サイトである SourceForge.netにおいて Javaがプロジ
ェクト数において初めてC++を追い抜いたとのこと。 実際にSoftware Mapを
見てみると、Javaが16,906 projects、 C++が16860 projectsと確かに追い抜
いているが、それどころか C++どころか16030 projectsのCも追い抜いている
ようだ。 ちなみに SourceForge.JPでもJavaがトップのようである。 Javaが世
に出てから10年ほど経ったが、SF.netという オープンソース(フリーソフトウェ
ア)の世界においてこれだけ広まるとは 思いもよらなかった。"
"
http://slashdot.jp/developers/05/12/06/0325201.shtml
kazekiriによる 2005年12月06日 12時44分の掲載
ハヤリスタリ部門より．
Java
プログラミング
Index
デベロッパー
vladobossdog曰く、" ITmediaに記事が出ているが、 世界最大のオープンソ
ースソフトウェア開発サイトである SourceForge.netにおいて Javaがプロジ
ェクト数において初めてC++を追い抜いたとのこと。 実際にSoftware Mapを
見てみると、Javaが16,906 projects、 C++が16860 projectsと確かに追い抜
いているが、それどころか C++どころか16030 projectsのCも追い抜いている
ようだ。 ちなみに SourceForge.JPでもJavaがトップのようである。 Javaが世
に出てから10年ほど経ったが、SF.netという オープンソース(フリーソフトウェ
ア)の世界においてこれだけ広まるとは 思いもよらなかった。"
"
http://slashdot.jp/developers/05/12/06/0325201.shtml
>>849
さあ。Eclipseのプラグインは
Java開発専用とは限らないものが多いから
C/C++開発に役立つプラグインは予想外にかなり多いかもね。
CDT専用プラグインというのは、さあ、という感じだが。
それから、Eclipseに対応しうるVS.NETのC#向けプラグインが多いかは疑問だが。
さあ。Eclipseのプラグインは
Java開発専用とは限らないものが多いから
C/C++開発に役立つプラグインは予想外にかなり多いかもね。
CDT専用プラグインというのは、さあ、という感じだが。
それから、Eclipseに対応しうるVS.NETのC#向けプラグインが多いかは疑問だが。
・Web・基幹系
Java
Cobol
・デスクトップアプリ、OS
C/C++
VB
明確に住み分けしたな。
Java
Cobol
・デスクトップアプリ、OS
C/C++
VB
明確に住み分けしたな。
ところが実際にはJava棲み分けの必要もなく
どこでもオールマイティ。デスクトップアプリでも
Javaの勢力が拡大しつつある。
NetBeansがそれに拍車をかける勢い
どこでもオールマイティ。デスクトップアプリでも
Javaの勢力が拡大しつつある。
NetBeansがそれに拍車をかける勢い
855 ：仕様書無しさん：2005/12/24(土) 17:08:22
そのとおり！これからはデスクトップアプリもJAVAの時代。
856 ：仕様書無しさん：2005/12/24(土) 17:09:50
JavaVMはどの言語で開発してるのかな？
Java
Cじゃない？Rubyの作者はOOPでOOPは開発しずらいて言ってたし。
859 ：仕様書無しさん：2005/12/24(土) 17:12:49
バカの一つ覚えですか？
もうそれしかいえませんか？ﾌﾟ
もうそれしかいえませんか？ﾌﾟ
いやね、JavaがどんなにすごくてもそれはSunのエンジニアがすごいからで。
ここでぐだぐだ管巻いてるJava厨はちっともえらかないんじゃないかと思われる。
所詮マクロ書きでそ？厳重に他言語で開発されて検証されたプラットフォーム上で動く。
いってみりゃ釈迦の手のひらで遊んでるだけの。
砂遊びをする子供も帰ってサンタを待っている、そんなクリスマスの夜。
ま、がんがれ。
ここでぐだぐだ管巻いてるJava厨はちっともえらかないんじゃないかと思われる。
所詮マクロ書きでそ？厳重に他言語で開発されて検証されたプラットフォーム上で動く。
いってみりゃ釈迦の手のひらで遊んでるだけの。
砂遊びをする子供も帰ってサンタを待っている、そんなクリスマスの夜。
ま、がんがれ。
Javaでtailを書けば全てのプラットフォームでtailが動く。
CUI環境をどかんと拡張するならJavaがいい。
CUI環境をどかんと拡張するならJavaがいい。
いやね、C++がどんなにすごくてもそれはひろゆきがすごいからで。
ここでぐだぐだ管巻いてるC++厨はちっともえらかないんじゃないかと思われる。
所詮ねらーでそ？厳重に2ch語で煽られて検証された2chﾌﾞﾗｳｻﾞ上で動く。
いってみりゃ釈迦の手のひらで遊んでるだけの。
砂遊びをする子供も帰ってサンタを待っている、そんなクリスマスの夜。
ま、がんがれ。
ここでぐだぐだ管巻いてるC++厨はちっともえらかないんじゃないかと思われる。
所詮ねらーでそ？厳重に2ch語で煽られて検証された2chﾌﾞﾗｳｻﾞ上で動く。
いってみりゃ釈迦の手のひらで遊んでるだけの。
砂遊びをする子供も帰ってサンタを待っている、そんなクリスマスの夜。
ま、がんがれ。
>ひろゆきがすごい
すごいのはぴろゆきであり、ひろゆきではない！
中の人なぞ以内！
すごいのはぴろゆきであり、ひろゆきではない！
中の人なぞ以内！
まろゆきは凄いんだけどね。
865 ：仕様書無しさん：2005/12/25(日) 21:58:09
Java ? C/C++ ? 未来が心配で仕事が手に付かないのけ？
心配するな、その未来にこのスレの連中はいない。
心配するな、その未来にこのスレの連中はいない。
866 ：仕様書無しさん：2005/12/25(日) 22:08:18
>>865に至ってはこの世のどこにも居ない。いやマジで。
867 ：仕様書無しさん：2005/12/25(日) 22:14:13
>>866
君、消えるの確定。
君、消えるの確定。
1-867 869-999
まで消える。
どれからげろゆきは凄くない。
まで消える。
どれからげろゆきは凄くない。
869 ：仕様書無しさん：2005/12/25(日) 22:30:27
確かに・・・。
C++、Javaに先があるとかより、５年先にPGやってるとは思えないし、
あんまり考えても仕方ない気がしてきた。
今ある仕事を一生懸命やることにするよ。そしてら、PGやらなくても
稼げる身分になってるかもしれないし。。。
C++、Javaに先があるとかより、５年先にPGやってるとは思えないし、
あんまり考えても仕方ない気がしてきた。
今ある仕事を一生懸命やることにするよ。そしてら、PGやらなくても
稼げる身分になってるかもしれないし。。。
870 ：69式フリーPG ◆hND3Lufios ：2005/12/25(日) 22:37:02
12歳の時にJR-100を触って以来、24年、プロになって14年プログラムを
組んでいますが。
組んでいますが。
871 ：仕様書無しさん：2005/12/25(日) 22:39:12
872 ：仕様書無しさん：2005/12/25(日) 22:43:01
5年後は、40才超えるじゃん。まだ、ＰＧやる予定なの？
873 ：仕様書無しさん：2005/12/25(日) 22:45:15
はあ？C++とJavaじゃ大違いだぞ。
それを意識せずに設計するような糞SEはさっさと辞めてくれ。マジで。
それを意識せずに設計するような糞SEはさっさと辞めてくれ。マジで。
875 ：仕様書無しさん：2005/12/25(日) 22:48:51
876 ：仕様書無しさん：2005/12/25(日) 22:52:51
そうして理想論を掲げてそこかしこで今日もデスマ
879 ：仕様書無しさん：2005/12/25(日) 23:14:02
>>878
このレベルが君の理想？
このレベルが君の理想？
880 ：仕様書無しさん：2005/12/25(日) 23:18:28
そう。言語に依存しない設計こそ理想的である。
いや、言語に依存する設計しか出来ない糞SEなんかしんで暮れマジで
882 ：仕様書無しさん：2005/12/25(日) 23:30:59
>>880
要するにお前はエスペラント信者だろ
要するにお前はエスペラント信者だろ
徹底的に言語の話排除するのは簡単なんだけど、あとで苦労する。
だからエスペラントですよ。
統一言語つくっちゃおうぜ。
JavaC
とかさ。
統一言語つくっちゃおうぜ。
JavaC
とかさ。
Ｄだろ？
PL/Iだな
Ａｄａがえーだ
そもそも言語の差異を排除する手のが間違ってるんだろ。
プログラムを記述する言語で差異を排除するということは、言語と言語の公約数的な記述しかできないことになる。
それは記述力の低下を意味する。JavaのGUIがしょぼしょぼなのと一緒。
プログラムを記述する言語で差異を排除するということは、言語と言語の公約数的な記述しかできないことになる。
それは記述力の低下を意味する。JavaのGUIがしょぼしょぼなのと一緒。
何いっちゃってるの？
頭がいっちゃってる
何度見てもスレタイが先がぬるぽはに見える。
893 ：仕様書無しさん：2005/12/27(火) 00:48:41
言語からボトムアップで設計する気か？
アプリ開発では、要求から設計を導くんよ。このとき言語は出てこない。
コンポーネント開発は、責務から使用を導くんよ。このとき、言語のうち
インターフェース（シグネチャ）が出てくるんよ。この段階では、
実装（メソッド）は出てこないんよね。
アプリ開発では、要求から設計を導くんよ。このとき言語は出てこない。
コンポーネント開発は、責務から使用を導くんよ。このとき、言語のうち
インターフェース（シグネチャ）が出てくるんよ。この段階では、
実装（メソッド）は出てこないんよね。
>>860
おいおい、偉くなるためにJavaをやってるワケじゃないんだし。
便利だから使ってるんだけど。
偉くなるためにプログラミング言語を勉強する人なんているかな。
偉くなるためにやってるなんて本当に変わってる人だと思うよ
さすがにマクロとはつがいでしょうな。
おいおい、偉くなるためにJavaをやってるワケじゃないんだし。
便利だから使ってるんだけど。
偉くなるためにプログラミング言語を勉強する人なんているかな。
偉くなるためにやってるなんて本当に変わってる人だと思うよ
さすがにマクロとはつがいでしょうな。
>>869
> 確かに・・・。
> C++、Javaに先があるとかより、５年先にPGやってるとは思えないし、
C++プログラマには悪いが、
C++プログラマとJavaプログラマ
どっちが人間らしいプログラマになれるか、といったらJavaプログラマの
ほうだとおもう。
もちろん適材適所に遭わせてC++も使う。だけどC++しかやらないって
ことは無いようにしないといけない。
日本のプログラマはまともな地位も無く苛酷だが
WinnyやSoftEtherのような強力なソフトウェアを作れば一挙に
大物になれるぞ。これぞ理想のプログラマだ。
顧客の命令に従うだけのプログラマよりもWinnyやSoftEtherを
作った二人のプログラマのほうが断然立派だ。こういうことを
成し遂げた者が数多く現れたとき、プログラマは偉大な職業として
認められるのさ。
WinnyやSoftEtherのようなソフトを作っているプログラマはSEやアーキテクト、ソフトウェア科学者
という職業も兼ねているんだよ。これが理想の立派なプログラマさ。
> 確かに・・・。
> C++、Javaに先があるとかより、５年先にPGやってるとは思えないし、
C++プログラマには悪いが、
C++プログラマとJavaプログラマ
どっちが人間らしいプログラマになれるか、といったらJavaプログラマの
ほうだとおもう。
もちろん適材適所に遭わせてC++も使う。だけどC++しかやらないって
ことは無いようにしないといけない。
日本のプログラマはまともな地位も無く苛酷だが
WinnyやSoftEtherのような強力なソフトウェアを作れば一挙に
大物になれるぞ。これぞ理想のプログラマだ。
顧客の命令に従うだけのプログラマよりもWinnyやSoftEtherを
作った二人のプログラマのほうが断然立派だ。こういうことを
成し遂げた者が数多く現れたとき、プログラマは偉大な職業として
認められるのさ。
WinnyやSoftEtherのようなソフトを作っているプログラマはSEやアーキテクト、ソフトウェア科学者
という職業も兼ねているんだよ。これが理想の立派なプログラマさ。
897 ：仕様書無しさん：2005/12/27(火) 01:22:47
>>872
五年経って始めて30代になる漏れからすれば
まだまだ余裕だね。
Javaのような言語ならプログラマの寿命も比較的
長生きできそうだね。ソースコードの読みやすさ、
設計のしやすさがC++にはないJavaの強みかね。
>>875
> >>873
> 上に行くと環境から使用言語や基盤なども全て決める必要がある。
> だから両方とも理解して、何を作るときにどっちを使ったらいいかわかる必要がある。
そうでもないな。実際にいろんな言語作ってみて実際に動かしてみると
どの言語が適しているかだいたい解ってくる。
大抵、言語はすぐに決まってしまう。なぜなら
殆どのプロジェクトがすでに既存のソフトウェアを再利用する形のものが多いから。
殆どの場合、既存のソフトウェアに使われている言語でプロジェクトに使われる
言語が決まってしまう。それからチームにいるプログラマのスキル、得意言語、
実績によっても決まる。「こいつはC++が得意そうだからC++でやらせよう」みたいな。
時間と予算の余裕をよく見積もってプログラマと徹底的によく交渉したマネージャが
プロジェクトを成功に導く。
基盤に関してはサーバ系なら有力候補としてPerlを使うかPHPを使うかJavaを使うかの
選択肢しかない。クライアントサイドでは最近ではC++, VB、Delphiのほかに、C#.NET, Java Swing。
.NETとJavaが出てきたのはJavaWebStartとClickOnceが現れてきたから。
それからFlash + Flex。これらはリッチクライアントの一種だ。
これら三つの技術が今後GUIの世界を台頭してゆく。
> >>873
> 上に行くと環境から使用言語や基盤なども全て決める必要がある。
> だから両方とも理解して、何を作るときにどっちを使ったらいいかわかる必要がある。
そうでもないな。実際にいろんな言語作ってみて実際に動かしてみると
どの言語が適しているかだいたい解ってくる。
大抵、言語はすぐに決まってしまう。なぜなら
殆どのプロジェクトがすでに既存のソフトウェアを再利用する形のものが多いから。
殆どの場合、既存のソフトウェアに使われている言語でプロジェクトに使われる
言語が決まってしまう。それからチームにいるプログラマのスキル、得意言語、
実績によっても決まる。「こいつはC++が得意そうだからC++でやらせよう」みたいな。
時間と予算の余裕をよく見積もってプログラマと徹底的によく交渉したマネージャが
プロジェクトを成功に導く。
基盤に関してはサーバ系なら有力候補としてPerlを使うかPHPを使うかJavaを使うかの
選択肢しかない。クライアントサイドでは最近ではC++, VB、Delphiのほかに、C#.NET, Java Swing。
.NETとJavaが出てきたのはJavaWebStartとClickOnceが現れてきたから。
それからFlash + Flex。これらはリッチクライアントの一種だ。
これら三つの技術が今後GUIの世界を台頭してゆく。
・・・・とまあ、聞きかじった単語を無理に使うと
意味不明な文章ができるっていう見本でした。
意味不明な文章ができるっていう見本でした。
>>876
> >>874
> 勉強不足だねー。精進せーよ。
> 実装を意識しないといけない設計はＮＧ。これ、基本中の基本。
> これマジだからちょっちググッてみな。
どのキーワードでググったらそんなページが出てきたのかな。
優秀なアーキテクトと呼ばれる人はモデルよりもやはり実装を重視する
人が多いぞ。UMLツールであるJudeを作った男は口先だけでなく
やはり実装を重視している。実際に動くものを作ってこそ意味があることの
重要性を熟知しているからだ。
いくらモデルを作っても実装がなければ意味がない。
実装だけでモデルが伴わないものは作った後で面倒なことになるケースが大半ではあるが
かといってモデルばかりに力を入れすぎて実装がうまくいかないでは
本末転倒というものだよ。
> >>874
> 勉強不足だねー。精進せーよ。
> 実装を意識しないといけない設計はＮＧ。これ、基本中の基本。
> これマジだからちょっちググッてみな。
どのキーワードでググったらそんなページが出てきたのかな。
優秀なアーキテクトと呼ばれる人はモデルよりもやはり実装を重視する
人が多いぞ。UMLツールであるJudeを作った男は口先だけでなく
やはり実装を重視している。実際に動くものを作ってこそ意味があることの
重要性を熟知しているからだ。
いくらモデルを作っても実装がなければ意味がない。
実装だけでモデルが伴わないものは作った後で面倒なことになるケースが大半ではあるが
かといってモデルばかりに力を入れすぎて実装がうまくいかないでは
本末転倒というものだよ。
901 ：仕様書無しさん：2005/12/27(火) 01:25:15
>>899
で、どこが意味不明なの？
それすら説明できないってことは
君自身が心当たりある聞きかじったような単語ばかり
だなあ、と思っているってことじゃないかな。
つまりうろ覚えしている状態の用語を
大量に出されて戸惑っていると。
はては、図星かなw
で、どこが意味不明なの？
それすら説明できないってことは
君自身が心当たりある聞きかじったような単語ばかり
だなあ、と思っているってことじゃないかな。
つまりうろ覚えしている状態の用語を
大量に出されて戸惑っていると。
はては、図星かなw
902 ：仕様書無しさん：2005/12/27(火) 01:27:13
903 ：仕様書無しさん：2005/12/27(火) 01:27:23
>>888
> そもそも言語の差異を排除する手のが間違ってるんだろ。
> プログラムを記述する言語で差異を排除するということは、言語と言語の公約数的な記述しかできないことになる。
> それは記述力の低下を意味する。JavaのGUIがしょぼしょぼなのと一緒。
JavaのGUIと言語の記述力の低下とは全然関係ないと思うが
一体どういう喩えかね？
> そもそも言語の差異を排除する手のが間違ってるんだろ。
> プログラムを記述する言語で差異を排除するということは、言語と言語の公約数的な記述しかできないことになる。
> それは記述力の低下を意味する。JavaのGUIがしょぼしょぼなのと一緒。
JavaのGUIと言語の記述力の低下とは全然関係ないと思うが
一体どういう喩えかね？
>>893
> 言語からボトムアップで設計する気か？
> アプリ開発では、要求から設計を導くんよ。このとき言語は出てこない。
>
> コンポーネント開発は、責務から使用を導くんよ。このとき、言語のうち
> インターフェース（シグネチャ）が出てくるんよ。この段階では、
> 実装（メソッド）は出てこないんよね。
皮肉なことに、制御系の人間はいきなりメソッド(関数)
が出てくる。入力と出力をはっきりさせることが大事だと主張して。
どこでも実装はもちろんでる。
「実装」の意味にもよるがな。
> 言語からボトムアップで設計する気か？
> アプリ開発では、要求から設計を導くんよ。このとき言語は出てこない。
>
> コンポーネント開発は、責務から使用を導くんよ。このとき、言語のうち
> インターフェース（シグネチャ）が出てくるんよ。この段階では、
> 実装（メソッド）は出てこないんよね。
皮肉なことに、制御系の人間はいきなりメソッド(関数)
が出てくる。入力と出力をはっきりさせることが大事だと主張して。
どこでも実装はもちろんでる。
「実装」の意味にもよるがな。
>>896
おいおい。よりにもよって
「WinnyやSoftEtherのような強力なソフトウェア」ときたか
どちらも技術的には大した事無いだろ。
「犯罪行為が規制しづらくなる」ってことで、
実装してもおおっぴろげにされていなかったソフトを
何の工夫も無く焼きなおしておおっぴろげにしただけ。
変な風に宣伝されたから有名になっただけで、
あんなの目指しても意味ねーだろ。
おいおい。よりにもよって
「WinnyやSoftEtherのような強力なソフトウェア」ときたか
どちらも技術的には大した事無いだろ。
「犯罪行為が規制しづらくなる」ってことで、
実装してもおおっぴろげにされていなかったソフトを
何の工夫も無く焼きなおしておおっぴろげにしただけ。
変な風に宣伝されたから有名になっただけで、
あんなの目指しても意味ねーだろ。
この板年齢制限してほしい。
R22ぐらいで。
R22ぐらいで。
907 ：仕様書無しさん：2005/12/27(火) 01:56:33
>>904
リアルタイムシステムは、コンポーネント開発に近いな。
インターフェース（関数）とその呼び出し順（シーケンス）が、最も
重要な仕様だ。要求から落とし込むには時間がかかりすぎるからな
止むを得まい。
幸いな事に、リアルタイムシステムは、対象のハードの仕様さえ明確
になりさえすればそこから突き崩せるんだが・・・。
（この辺は、ハード屋とソフト屋の喧嘩の種なんだが・・・。）
実装ありきじゃないんよ。実装は、設計を分かりやすくするためにのみ
露出してもＯＫなだけで、実装を思い浮かべながら設計するのは、
基本的には、間違いだな。
別の言い方すると、全ての利害関係者が実装でコミュニケーション
するのは不可能だろ。設計者と実装者のコミュニケーションにおいてのみ
補完的に実装が出てくるのが自然だと思うが。
プログラムは、敬意を払ってプログラマーに任せるのが良いのではないか？
リアルタイムシステムは、コンポーネント開発に近いな。
インターフェース（関数）とその呼び出し順（シーケンス）が、最も
重要な仕様だ。要求から落とし込むには時間がかかりすぎるからな
止むを得まい。
幸いな事に、リアルタイムシステムは、対象のハードの仕様さえ明確
になりさえすればそこから突き崩せるんだが・・・。
（この辺は、ハード屋とソフト屋の喧嘩の種なんだが・・・。）
実装ありきじゃないんよ。実装は、設計を分かりやすくするためにのみ
露出してもＯＫなだけで、実装を思い浮かべながら設計するのは、
基本的には、間違いだな。
別の言い方すると、全ての利害関係者が実装でコミュニケーション
するのは不可能だろ。設計者と実装者のコミュニケーションにおいてのみ
補完的に実装が出てくるのが自然だと思うが。
プログラムは、敬意を払ってプログラマーに任せるのが良いのではないか？
908 ：仕様書無しさん：2005/12/27(火) 01:59:11
>>900
これ以上何も言わない。
一度、自分が間違っているという前提を置いて、調査・分析して結論
を導いてみろ。
ソフト開発を、凝り固まった一つの脳みそでやるのはしんどいぜ。
たまには帽子をかぶりなおしてみてはどうだ？
これ以上何も言わない。
一度、自分が間違っているという前提を置いて、調査・分析して結論
を導いてみろ。
ソフト開発を、凝り固まった一つの脳みそでやるのはしんどいぜ。
たまには帽子をかぶりなおしてみてはどうだ？
909 ：ウンコ：2005/12/27(火) 06:24:25
>>900と>>908は、どちらも一部正しいと思うし、
どちらも間違っていると思う。
結論としては、仕事の内容によって異なる、というものだ。
全ての仕事が、>>900の実装できなきゃ、という設計のものでもないし、
小規模のシステムなんて言語を意識しない設計するのは無駄だしな。
まあ、>>900も>>908も、神と呼ばれたこのおれ様からみたら、
まだまだひよっこだな。
がはは！
どちらも間違っていると思う。
結論としては、仕事の内容によって異なる、というものだ。
全ての仕事が、>>900の実装できなきゃ、という設計のものでもないし、
小規模のシステムなんて言語を意識しない設計するのは無駄だしな。
まあ、>>900も>>908も、神と呼ばれたこのおれ様からみたら、
まだまだひよっこだな。
がはは！
Swingって画面に色塗ってるだけだから、
いくらでもコンポーネント作れると思うが
いくらでもコンポーネント作れると思うが
>>910
低性能にはなるかもしれんが、低機能はないと思うぜ。
低性能にはなるかもしれんが、低機能はないと思うぜ。
もしかしてOS固有のAPI叩いてると思ってるのかな。
あ、SWTの話？
あ、SWTの話？
JAVAのGUIは低性能だな。。それも我慢できないそして利用価値がないぐらいのな
あんなもので生産管理の巨大なテーブルを処理する設計する馬鹿の気がしれんな。
あんなもので生産管理の巨大なテーブルを処理する設計する馬鹿の気がしれんな。
915 ：仕様書無しさん：2005/12/27(火) 12:15:30
javaはプログラムが大規模になればなるほど、
ハードウェアがソフトウェアの性能を支えきれなくなって
アボーンしてしまう。
その証拠に大規模なｼｽﾃﾑでjavaを使うってのは聞いた事が無い。
コンシューマー向けゲーム、ネットワークゲームなんかが良い例でしょう。
プログラム規模が小さいうちは高性能なハードウェアが吸収してくれるから
粗が見えないだけで・・・
ハードウェアがソフトウェアの性能を支えきれなくなって
アボーンしてしまう。
その証拠に大規模なｼｽﾃﾑでjavaを使うってのは聞いた事が無い。
コンシューマー向けゲーム、ネットワークゲームなんかが良い例でしょう。
プログラム規模が小さいうちは高性能なハードウェアが吸収してくれるから
粗が見えないだけで・・・
>>916
で、キミはそんなに大規模開発の事例集めて何がしたいの？
で、キミはそんなに大規模開発の事例集めて何がしたいの？
>ハードウェアがソフトウェアの性能を支えきれなくなって
11トントレーラを軽自動車のエンジンで動かすのがJava
11トントレーラを軽自動車のエンジンで動かすのがJava
919 ：仕様書無しさん：2005/12/27(火) 16:38:12
つりかマジかよくわからんレスが多いなｗ
920 ：仕様書無しさん：2005/12/27(火) 22:35:29
>>910
JavaのGUIが複数のプラットフォームの共通項としてしか実装できないからといって、
言語の違いでも同じ事が言えるとは限らないぞ。
極端な話、手続き型の C と関数型の Lisp とですら、言語としての能力は等価。
少なくとも情報系の学部を出た香具師にとっては常識のはずなんだけどなあ・・・。
JavaのGUIが複数のプラットフォームの共通項としてしか実装できないからといって、
言語の違いでも同じ事が言えるとは限らないぞ。
極端な話、手続き型の C と関数型の Lisp とですら、言語としての能力は等価。
少なくとも情報系の学部を出た香具師にとっては常識のはずなんだけどなあ・・・。
Swingアプリって携帯電話でも動くんだ。すごいね！
922 ：仕様書無しさん：2005/12/27(火) 22:47:20
>>909
神様か・・・、どおりで日本語が変だと思った。
神様か・・・、どおりで日本語が変だと思った。
923 ：仕様書無しさん：2005/12/27(火) 22:48:55
JAVAはあれだな。
ちんぽに自転車のチューブを被せてｵﾅﾆｰするようなもんだ。
ちんぽに自転車のチューブを被せてｵﾅﾆｰするようなもんだ。
925 ：仕様書無しさん：2005/12/27(火) 23:06:09
ノイマンはこの際関係ないと思う。
オブジェクト指向FORTH = JAVA
927 ：仕様書無しさん：2005/12/27(火) 23:15:29
>>924
むしろチョムスキーとかそっち方面。
むしろチョムスキーとかそっち方面。
928 ：仕様書無しさん：2005/12/27(火) 23:28:56
チョムスキーがどう関係するんだ？
929 ：仕様書無しさん：2005/12/27(火) 23:39:48
ミドルウェアはJavaでは無理
930 ：仕様書無しさん：2005/12/28(水) 00:56:00
今後一切てめーらと仕事したくない。
何が設計だよ。実装イメージできずに設計も糞もないだろヴォケが。
海底神殿をどうやって建設するんだよ。作業員を潜らせる？
水中でカナヅチ使うの？
何が設計だよ。実装イメージできずに設計も糞もないだろヴォケが。
海底神殿をどうやって建設するんだよ。作業員を潜らせる？
水中でカナヅチ使うの？
Javaのミドルなんていくらでもある
>>904 ぼけたこと言ってるんじゃねーと。
インタフェースとシーケンスだけだって？はぁ？
手続き指向でもの考えてるんじゃねーよ。今時のハードは全部ステートマシンで設計されてるんだぜ？
入力と出力が決まれば決定論的に処理が決まるという旧来の構造化技法だけでは駄目なんだよ。
って、構造化もできにゃい厨房とみたがね。
それぞれのブロックの役割と振る舞いを定義する仕事と、中身を実装する仕事は分かれてもいいと思う。
境界が曖昧になってきてる現状は特にな。
ＪａｖａとC++のどっちがましかと言えば、結局ＪＮＩに行き着くJavaはなんかうさんくさい気もするがな。
インタフェースとシーケンスだけだって？はぁ？
手続き指向でもの考えてるんじゃねーよ。今時のハードは全部ステートマシンで設計されてるんだぜ？
入力と出力が決まれば決定論的に処理が決まるという旧来の構造化技法だけでは駄目なんだよ。
って、構造化もできにゃい厨房とみたがね。
それぞれのブロックの役割と振る舞いを定義する仕事と、中身を実装する仕事は分かれてもいいと思う。
境界が曖昧になってきてる現状は特にな。
ＪａｖａとC++のどっちがましかと言えば、結局ＪＮＩに行き着くJavaはなんかうさんくさい気もするがな。
934 ：仕様書無しさん：2005/12/28(水) 08:26:33
あんかーみすしたきがするがまいいか
Javaのミドルの実例をあげよ
ただし初期化時のロード時間が1分以上かかるのはミドル失格
ただし初期化時のロード時間が1分以上かかるのはミドル失格
>>935
おいおい、Tomcatあげようと思ったけどあげれねぇジャン。不利だぜ。どうすんだよ。
おいおい、Tomcatあげようと思ったけどあげれねぇジャン。不利だぜ。どうすんだよ。
937 ：仕様書無しさん：2005/12/29(木) 01:07:42
>>933
「シーケンス」と「フローチャート」をごっちゃにしてないか？
あと、決定論という用語の使い方間違ってるし。
そもそも、ハードの設計手法をソフトの設計手法とごっちゃにしている
ところから改める必要がある。物事は整理して考えた方がいいと思うぞ。
「シーケンス」と「フローチャート」をごっちゃにしてないか？
あと、決定論という用語の使い方間違ってるし。
そもそも、ハードの設計手法をソフトの設計手法とごっちゃにしている
ところから改める必要がある。物事は整理して考えた方がいいと思うぞ。
938 ：仕様書無しさん：2005/12/29(木) 01:17:10
ハードの仕様はソフトの実装だからな。
最近数年のトレンド：
ハードとの境界破壊（SystemCでもSpecCでもま、いいわ。結果としての実装は
性能とコストのトレードオフで行われる、すなわち同じ動作をするものを
ソフト的に実装し、実施段階で分割する）
ソフトモジュールの境界破壊（データベース系の高速化とか、Java厨お得意のJITとか
本来造られた頃の枠組みを壊し、インタフェース部分を取っ払って高速化したと言い張る）
最近はごっちゃにしないとわからないことも多いんだよ。
シーケンスはOOならイベント交換だろ。本来は他の記法と組み合わせないとシステムわからん。
手続き思考の厨が陥る罠として、流れ図同様にシーケンス図を取る奴が居るから書いたまで。
古来のシーケンスとはラダーシーケンスでまた別物なんだがな。
整理したくても要素技術多すぎで難しいんだよ。
最近数年のトレンド：
ハードとの境界破壊（SystemCでもSpecCでもま、いいわ。結果としての実装は
性能とコストのトレードオフで行われる、すなわち同じ動作をするものを
ソフト的に実装し、実施段階で分割する）
ソフトモジュールの境界破壊（データベース系の高速化とか、Java厨お得意のJITとか
本来造られた頃の枠組みを壊し、インタフェース部分を取っ払って高速化したと言い張る）
最近はごっちゃにしないとわからないことも多いんだよ。
シーケンスはOOならイベント交換だろ。本来は他の記法と組み合わせないとシステムわからん。
手続き思考の厨が陥る罠として、流れ図同様にシーケンス図を取る奴が居るから書いたまで。
古来のシーケンスとはラダーシーケンスでまた別物なんだがな。
整理したくても要素技術多すぎで難しいんだよ。
939 ：仕様書無しさん：2005/12/29(木) 01:39:48
UMLはもともとリアルタイムシステムは対象外だった。だから、
足りない図は追加したりアレンジして使ってる。
シーケンス図に、状態を明記したりは普通にするね。矢印の種類も
増えてるし・・・。
境界破壊か・・・。最近はＰＣの性能ＵＰが激しいので、よほどの事
がない限りソフトを基盤にしたりはしないな。基盤の開発が終わる頃に、
次世代アーキテクチャのＰＣが出荷されるからな。うちの会社じゃ、
ハードで出来る事をソフトに持ってくる事は多いがその逆は最近ない。
だから、ソフト開発にかかる負担は増えてく一方さ。
ファームが最後の砦って感じかな？結果的に俺のところは、ファームと
ＰＣソフトがインターフェースするだけだから、ソフト屋は、直接ハードは
触ってない事になるな。ファーム屋が提供するドライバの仕様書は単なる
APIの説明とシーケンスが主になってる。
想定している階層にずれがあるのかもしれん。
境界にいるファーム屋は、ごっちゃになってるんだろうな。
実際、ソフトチームとハードチームは良く喧嘩してるけど、これは
開発スタイルの違いからくるものじゃなくて、境界線を明確にしないのが
原因だと思う。検討段階ではごっちゃになってても結果的に整理されないと
ソフトもハードも作れない。実際は、ハードが先にできてその後に、
それに合わせてソフトを作ることが多いので結果的にごっちゃにならない
とも言えるかな？
足りない図は追加したりアレンジして使ってる。
シーケンス図に、状態を明記したりは普通にするね。矢印の種類も
増えてるし・・・。
境界破壊か・・・。最近はＰＣの性能ＵＰが激しいので、よほどの事
がない限りソフトを基盤にしたりはしないな。基盤の開発が終わる頃に、
次世代アーキテクチャのＰＣが出荷されるからな。うちの会社じゃ、
ハードで出来る事をソフトに持ってくる事は多いがその逆は最近ない。
だから、ソフト開発にかかる負担は増えてく一方さ。
ファームが最後の砦って感じかな？結果的に俺のところは、ファームと
ＰＣソフトがインターフェースするだけだから、ソフト屋は、直接ハードは
触ってない事になるな。ファーム屋が提供するドライバの仕様書は単なる
APIの説明とシーケンスが主になってる。
想定している階層にずれがあるのかもしれん。
境界にいるファーム屋は、ごっちゃになってるんだろうな。
実際、ソフトチームとハードチームは良く喧嘩してるけど、これは
開発スタイルの違いからくるものじゃなくて、境界線を明確にしないのが
原因だと思う。検討段階ではごっちゃになってても結果的に整理されないと
ソフトもハードも作れない。実際は、ハードが先にできてその後に、
それに合わせてソフトを作ることが多いので結果的にごっちゃにならない
とも言えるかな？
940 ：仕様書無しさん：2005/12/29(木) 09:01:01
国内でメジャーなPCパーツ開発はもう誰もやってないから、ドライバ開発とかも
すでに一般的なことじゃなくなってる。PC系はもう全部ハードなんか気にしてない。
FileI/Oの下かソケットの下のなんか、つう意識しかないからもうなんかね。
ぎりぎりのコストを量産効果で追求する代物には本来ハードソフトの境界を綱引きできる
真のシステム設計のスキルが必要だけど・・・
PC厨上がりの連中にはそれがない。とくにオプソ厨とか犬厨な。
JavaでもC/C++でも使いどころはあるはずなんだが、連中が入ってくると
一様に使えなくなるのはなぜなんだろうな。
MS系のツール使いの連中は、齟齬が起こることが少ない。
仕様とか資料のありがたみが身にしみてるからなのかも知れないけどな。
すでに一般的なことじゃなくなってる。PC系はもう全部ハードなんか気にしてない。
FileI/Oの下かソケットの下のなんか、つう意識しかないからもうなんかね。
ぎりぎりのコストを量産効果で追求する代物には本来ハードソフトの境界を綱引きできる
真のシステム設計のスキルが必要だけど・・・
PC厨上がりの連中にはそれがない。とくにオプソ厨とか犬厨な。
JavaでもC/C++でも使いどころはあるはずなんだが、連中が入ってくると
一様に使えなくなるのはなぜなんだろうな。
MS系のツール使いの連中は、齟齬が起こることが少ない。
仕様とか資料のありがたみが身にしみてるからなのかも知れないけどな。
941 ：仕様書無しさん：2005/12/29(木) 09:05:00
とくにオプソ厨とか犬厨な。
とくにオプソ厨とか犬厨な。
とくにオプソ厨とか犬厨な。
とくにオプソ厨とか犬厨な。
わははは、おろうなミンチーの事だなw
とくにオプソ厨とか犬厨な。
とくにオプソ厨とか犬厨な。
とくにオプソ厨とか犬厨な。
わははは、おろうなミンチーの事だなw
942 ：仕様書無しさん：2005/12/29(木) 09:41:45
ＰＣ厨上がりのソフト屋は、コンピュータサイエンスの極々一部で勝負
している。ソースコードが実施にコンピュータのチップの中で電子的に
どんな風に動いているかなんて想像もできないだろう。
ソフト開発者不足を補うために、そんなに理解しなくてもソフトが開発
できるように抽象化が急速に進められてきたんだが、その弊害だろうな。
豊富なライブラリを単に使う、ちっともクリエイティブじゃない、単純
作業プログラマーが増えたのは確かだ。
オプソは単なる流行だろ。
Java は、華々しくデビューしたときは学生だったんでとりあえず
飛びついたんよ。当時は、Windows が使い物にならなかった時代で
UNIXで動かしてた。当時、UNIX での開発は面倒だった。なんせ、UNIX
は、いろんな種類が出ていて共通で動くソフトを開発するのは面倒
だったんよね。だから、Java は存在意義が大きかった。
その後、Windows が世界征服しちゃって、Linux の登場でUNIX が隅に
やられた。Mac はご覧の通りさ。結果、Windowsで動作するアプリだけを
作れば商売が出来る世の中になったんよ。そのご、Java はマイクロソフトに
振り回されて現在に至るつー感じかな。
ここ10年の変化ってだれも予想できなかったように、これからの10年も
誰も予想できないんだろな・・・。コンピュータの進化が止まれば、
Javaで、今後もどんどん進化が止まなければ C++/C かな。
コンピュータの性能向上はJavaにとっては向かい風だと俺は思う。
している。ソースコードが実施にコンピュータのチップの中で電子的に
どんな風に動いているかなんて想像もできないだろう。
ソフト開発者不足を補うために、そんなに理解しなくてもソフトが開発
できるように抽象化が急速に進められてきたんだが、その弊害だろうな。
豊富なライブラリを単に使う、ちっともクリエイティブじゃない、単純
作業プログラマーが増えたのは確かだ。
オプソは単なる流行だろ。
Java は、華々しくデビューしたときは学生だったんでとりあえず
飛びついたんよ。当時は、Windows が使い物にならなかった時代で
UNIXで動かしてた。当時、UNIX での開発は面倒だった。なんせ、UNIX
は、いろんな種類が出ていて共通で動くソフトを開発するのは面倒
だったんよね。だから、Java は存在意義が大きかった。
その後、Windows が世界征服しちゃって、Linux の登場でUNIX が隅に
やられた。Mac はご覧の通りさ。結果、Windowsで動作するアプリだけを
作れば商売が出来る世の中になったんよ。そのご、Java はマイクロソフトに
振り回されて現在に至るつー感じかな。
ここ10年の変化ってだれも予想できなかったように、これからの10年も
誰も予想できないんだろな・・・。コンピュータの進化が止まれば、
Javaで、今後もどんどん進化が止まなければ C++/C かな。
コンピュータの性能向上はJavaにとっては向かい風だと俺は思う。
943 ：仕様書無しさん：2005/12/29(木) 09:53:44
>豊富なライブラリを単に使う、ちっともクリエイティブじゃない、単純
>作業プログラマーが増えたのは確かだ。
人が作ったただのフレームワークの使い方を知る事だけに注力する
非クリエィティブなミンチー軍団だなw
>作業プログラマーが増えたのは確かだ。
人が作ったただのフレームワークの使い方を知る事だけに注力する
非クリエィティブなミンチー軍団だなw
Javaが嫌いというわけではないが、確かにJavaをやっていると独自アルゴリズムを作る必要性が出たときに凍り付いてしまう事が多々あるね、
アセンブラやC/C++をやってたときには無かった事なんだが、あれだよな、コンピュータ使っていると漢字を忘れてしまうって奴になんか似た感触がある。
アセンブラやC/C++をやってたときには無かった事なんだが、あれだよな、コンピュータ使っていると漢字を忘れてしまうって奴になんか似た感触がある。
Activex/OCXを貼り合わせるVBとたいして変わらないんだよ。Javaは。
接着剤言語。コンポーネントやフレームワークの中にバカは触るなって奴
接着剤言語。コンポーネントやフレームワークの中にバカは触るなって奴
接着剤といえばC#がいいな、あれは良い接着剤だ
C#でgenericsでなくtemplateが使えたらよかったのに･･･
無理。
あれの活用ははっきり言って裏技。
そんな訳解らないのは排除するのが当たり前。
あれの活用ははっきり言って裏技。
そんな訳解らないのは排除するのが当たり前。
んーとりあえずほしいのはGenericsの記述の中でクラス制約をしないでいい機能だけなんだが。
コンパイル時でも実行時でもいいからそこでメソッドなければエラーにしてほしい。
Genericsのクラス(メソッド)記述時点で文句言われるとかなり制約が出る。
コンパイル時でも実行時でもいいからそこでメソッドなければエラーにしてほしい。
Genericsのクラス(メソッド)記述時点で文句言われるとかなり制約が出る。
>>951
いや実行時のコンパイル時にだけ型情報見て、合わなければエラーはく。
たぶん浅薄な理解しかしてないと思うけど、Genericsでの対象の型が特定の派生系列に限定されるのがかなり不便です。同じシグネチャ持ってるもの呼び出せれば設計かなり楽になるのに。
あーかいてて思ったが、動的呼び出しすればいいのか。
いや実行時のコンパイル時にだけ型情報見て、合わなければエラーはく。
たぶん浅薄な理解しかしてないと思うけど、Genericsでの対象の型が特定の派生系列に限定されるのがかなり不便です。同じシグネチャ持ってるもの呼び出せれば設計かなり楽になるのに。
あーかいてて思ったが、動的呼び出しすればいいのか。
>>951
やりようはいくらでもあると思うけどね、たとえばせっかくアトリビュートがあるのだからそれを利用して、
特定マークされたメソッドに関連するコードをまとめてJITするとか
クラスベースオブジェクト指向の限界が見えている部分だから改良の余地はかなりあるよ、このあたりは。
やりようはいくらでもあると思うけどね、たとえばせっかくアトリビュートがあるのだからそれを利用して、
特定マークされたメソッドに関連するコードをまとめてJITするとか
クラスベースオブジェクト指向の限界が見えている部分だから改良の余地はかなりあるよ、このあたりは。
>>954
いや、面倒というよりもシグネチャが共通なものを呼び出せるようにしたいだけで、同じ派生系列であるという制限をなくしてほしいということ。
たとえば定義したDelegateに対してInvokeだっけかな？呼び出すようなGenericコード書いたんだけど、そのメソッドが定義されたときに自動的に作成されるクラスで定義されているためコンパイルが通らない。
Reflection使って、動的呼び出しすれば通るけれど美しくない。
まぁここで書いてもしょうがないんだけどね･･･
いや、面倒というよりもシグネチャが共通なものを呼び出せるようにしたいだけで、同じ派生系列であるという制限をなくしてほしいということ。
たとえば定義したDelegateに対してInvokeだっけかな？呼び出すようなGenericコード書いたんだけど、そのメソッドが定義されたときに自動的に作成されるクラスで定義されているためコンパイルが通らない。
Reflection使って、動的呼び出しすれば通るけれど美しくない。
まぁここで書いてもしょうがないんだけどね･･･
C#のGenericsって随分とって付けた系のGenericsなんだな・・・むむむ
>>955
俺、Javaモードで考えてるから、「そのメソッドが定義されたときに自動的に
作成されるクラスで定義されている」が上手く理解できない。
この辺の仕掛けについてもう少し詳しい話が聞きたいんだけど、語ってみる
気ない？
俺、Javaモードで考えてるから、「そのメソッドが定義されたときに自動的に
作成されるクラスで定義されている」が上手く理解できない。
この辺の仕掛けについてもう少し詳しい話が聞きたいんだけど、語ってみる
気ない？
○○が○○であるときに○○が生成されるというのは非常にC++のtemplate的だね。
てゆうか、これが無いtemplateなんてtemplateした気になれない・・・
てゆうか、これが無いtemplateなんてtemplateした気になれない・・・
>>957
C#のデリゲートだと定義したときにコンパイラーが内部的にクラスを生成する。
delegate void GraphDelegate(double,long);
↓
class GraphDelegate:MultiCastDelegate{
GraphDelegate(double param1,long param2)
void Invoke();
}
今回の話とは直接関係ないけれど、この自動生成で作成されるInvokeメソッドが派生クラスで定義されていないため,定義されるすべてのデリゲートで同じメソッドを持ってるにもかかわらずGenericsコード内で呼び出すことができない。
これは自分が直接困ってた問題だけど、ほかにも別クラスで同じメソッドネームとパラメータタイプを持つようなものを Genericコードで書けると便利なことがある。
まぁ一種のシンタックスシュガーといえなくもないんだけどGenericコード生成時にチェックしてくれれば動的コードバインディングよりも効率は上がる。
のでそれができるtemplateがあればいいのにとないものねだりで愚痴はいただけだす。
C#のデリゲートだと定義したときにコンパイラーが内部的にクラスを生成する。
delegate void GraphDelegate(double,long);
↓
class GraphDelegate:MultiCastDelegate{
GraphDelegate(double param1,long param2)
void Invoke();
}
今回の話とは直接関係ないけれど、この自動生成で作成されるInvokeメソッドが派生クラスで定義されていないため,定義されるすべてのデリゲートで同じメソッドを持ってるにもかかわらずGenericsコード内で呼び出すことができない。
これは自分が直接困ってた問題だけど、ほかにも別クラスで同じメソッドネームとパラメータタイプを持つようなものを Genericコードで書けると便利なことがある。
まぁ一種のシンタックスシュガーといえなくもないんだけどGenericコード生成時にチェックしてくれれば動的コードバインディングよりも効率は上がる。
のでそれができるtemplateがあればいいのにとないものねだりで愚痴はいただけだす。
CppとJavaとは全く関係ないけどさ、PL/SQLしか出来ないPGってどう思う？
PL/SQLっつうかDeveloperなんだが。
ポインタの名前すら知らないPGって悲惨だよな。
PL/SQLっつうかDeveloperなんだが。
ポインタの名前すら知らないPGって悲惨だよな。
PL/SQLだけのPGなんていないだろｰ。
DB屋でPL/SQLが一番得意です。って奴はいると思うが、そういう奴は
PGというよりDB設計とチューニングで食ってる。
DB屋でPL/SQLが一番得意です。って奴はいると思うが、そういう奴は
PGというよりDB設計とチューニングで食ってる。
Javaって高速化の為にオブジェクトの使いまわしをするとか
よく見るんだが、せっかくのＧＣ機能が意味が無くなり、
Ｃ＋＋とは逆の意味合いでのメモリー管理(削除ではなく維持)が
必要になると認識しちゃんだけど間違い？
よく見るんだが、せっかくのＧＣ機能が意味が無くなり、
Ｃ＋＋とは逆の意味合いでのメモリー管理(削除ではなく維持)が
必要になると認識しちゃんだけど間違い？
963 ：仕様書無しさん：2006/01/03(火) 08:41:06
>>962
ちょっち違う。
オブジェクトの使い回しは意識的にやっているのでGC機能の対象外
になるのは、仕方が無い。
その前に、GCのアルゴリズムが統一されていて、しかもその仕様が
分かっているなら、GCに関連するチューニングも意味があるが、
その他の場合は、徒労に終わる。
チューニングする前に、仕様を見直すとか、プロファイリングするとか
いろいろやる事はある。小手先のテクでJavaが速くなるといってる奴
は無視して問題ない。
あらゆる言語で普通メモリー管理はしない方がいい。
OSのメモリ管理の邪魔をするだけだ。
昔のOSは、freeでメモリを開放してないやつとかあったからな・・・。
独自GCは昔の話さ。自力でGCなんて爺くらいしかそんな事言わないよ。
ちょっち違う。
オブジェクトの使い回しは意識的にやっているのでGC機能の対象外
になるのは、仕方が無い。
その前に、GCのアルゴリズムが統一されていて、しかもその仕様が
分かっているなら、GCに関連するチューニングも意味があるが、
その他の場合は、徒労に終わる。
チューニングする前に、仕様を見直すとか、プロファイリングするとか
いろいろやる事はある。小手先のテクでJavaが速くなるといってる奴
は無視して問題ない。
あらゆる言語で普通メモリー管理はしない方がいい。
OSのメモリ管理の邪魔をするだけだ。
昔のOSは、freeでメモリを開放してないやつとかあったからな・・・。
独自GCは昔の話さ。自力でGCなんて爺くらいしかそんな事言わないよ。
part2 行く前に
次で誰かまとめてAA希望
次で誰かまとめてAA希望
965 ：仕様書無しさん：2006/01/03(火) 20:08:59
おいらＣ/Ｃ＋＋使いだけど、最近Ｃ＃も使うようになった。
Ｊａｖａ嫌いの連中も会社の方針で、Ｃ＃使うようになった。
おいらはこれいいと思う。明らかに生産性が上がったもんね。
Ｃ＃でできないことがあればＣ/Ｃ＋＋使えばいいんだし、どんな問題もない。
新人にはとりあえずＣ＃使わしてる。
十分使えるようになったらＣ/Ｃ＋＋の仕事でも使ってやるつもり。
ただ、Ｊａｖａはよくないね。
何がよくないって、Ｊａｖａ使いってのはどうもＪａｖａのことしかわかっていない。
プログラミングとはＯＳとはコンピューターとはという根本的な問いはまったといっていいほど答えられない。
Ｊａｖａ嫌いの連中も会社の方針で、Ｃ＃使うようになった。
おいらはこれいいと思う。明らかに生産性が上がったもんね。
Ｃ＃でできないことがあればＣ/Ｃ＋＋使えばいいんだし、どんな問題もない。
新人にはとりあえずＣ＃使わしてる。
十分使えるようになったらＣ/Ｃ＋＋の仕事でも使ってやるつもり。
ただ、Ｊａｖａはよくないね。
何がよくないって、Ｊａｖａ使いってのはどうもＪａｖａのことしかわかっていない。
プログラミングとはＯＳとはコンピューターとはという根本的な問いはまったといっていいほど答えられない。
いや、C#も流行になればそういう状態になるよ。
967 ：仕様書無しさん：2006/01/03(火) 20:18:24
Ｊａｖａ使い==馬鹿の集合
>>965-966
というか多分C#しか知らない新人はJava使いと同じ状態になると思う。
というか多分C#しか知らない新人はJava使いと同じ状態になると思う。
ということはC++が最強？
ちと聞くが、C++ってのはWindows C++ or UNIX C++のどっち？
ど ち ら も だ ！
>>970
wao
wao
>>969
言語仕様を理解する能力やコンピュータ全般の知識に関してはトップクラスだろう。
ただな、実務って極度に特化した世界だから、現実の複雑な問題を非常に簡素なモデル
へと転換する能力はあっても、それをコード化する能力がない奴とか、目的に応じてクラ
ス間の依存関係を見事に組み換える能力はあっても、ロジック書けない奴とか、あらゆる
道具を極短期間の学習で直ぐに使いこなす能力はあっても、プログラミング能力は限り
なくゼロに近い奴とか、そもそもコンピュータが苦手で触りたがらないが、人の扱いが上
手くて調停能力の高い奴とか、まぁ色んなのが居るわけだ。
色んなのが居て、全体として一つの成果物を産み出せるなら、それはそれでいいんだよ。
難解な言語仕様を理解し、高度なアルゴリズムを発案し、コンピュータのあらゆる側面を
理解する。非常に有用で高度な技術だけど、そういう人間ばかり集めても実務はこなせん。
実務ってね、実際幅広いの。だから、その中から自分の得意なものをやって役に立つ人
間であり続けさえすればいい。独りで全部できなくったって全然構わないのよ？
その為に、沢山の人間が集まってるんだからさ。
言語仕様を理解する能力やコンピュータ全般の知識に関してはトップクラスだろう。
ただな、実務って極度に特化した世界だから、現実の複雑な問題を非常に簡素なモデル
へと転換する能力はあっても、それをコード化する能力がない奴とか、目的に応じてクラ
ス間の依存関係を見事に組み換える能力はあっても、ロジック書けない奴とか、あらゆる
道具を極短期間の学習で直ぐに使いこなす能力はあっても、プログラミング能力は限り
なくゼロに近い奴とか、そもそもコンピュータが苦手で触りたがらないが、人の扱いが上
手くて調停能力の高い奴とか、まぁ色んなのが居るわけだ。
色んなのが居て、全体として一つの成果物を産み出せるなら、それはそれでいいんだよ。
難解な言語仕様を理解し、高度なアルゴリズムを発案し、コンピュータのあらゆる側面を
理解する。非常に有用で高度な技術だけど、そういう人間ばかり集めても実務はこなせん。
実務ってね、実際幅広いの。だから、その中から自分の得意なものをやって役に立つ人
間であり続けさえすればいい。独りで全部できなくったって全然構わないのよ？
その為に、沢山の人間が集まってるんだからさ。
>>973
> Javaプログラマがパフォーマンスチューニングに疎いのは確かだが
> コードレビューによる指摘は意味がない。
> Javaでは先ずプロファイリングする事が第一で、その後のチューニ
> ングはコードに留まらず、ハードウェアの構成からミドルウェアの設
> 定、バックエンドの選択から最適化までを含めたトータルチューニン
> グになる。
> そして、これを担当するエンジニアは非常に特殊なポジションをとる。
> どれくらい特殊かって言うと、これ一本で食ってるコンサルや外注さ
> んが居るくらい特殊ｗ
>
> 何故JavaではXPが持て囃されるのか？って話とも絡むんだけど
> まぁ、どうでもいいかｗ
まで呼んだ
> Javaプログラマがパフォーマンスチューニングに疎いのは確かだが
> コードレビューによる指摘は意味がない。
> Javaでは先ずプロファイリングする事が第一で、その後のチューニ
> ングはコードに留まらず、ハードウェアの構成からミドルウェアの設
> 定、バックエンドの選択から最適化までを含めたトータルチューニン
> グになる。
> そして、これを担当するエンジニアは非常に特殊なポジションをとる。
> どれくらい特殊かって言うと、これ一本で食ってるコンサルや外注さ
> んが居るくらい特殊ｗ
>
> 何故JavaではXPが持て囃されるのか？って話とも絡むんだけど
> まぁ、どうでもいいかｗ
まで呼んだ
>>973
確かに。全てを網羅する必要はないか。
確かに。全てを網羅する必要はないか。
976 ：仕様書無しさん：2006/01/04(水) 09:37:03
>>973
話をぼかしているだけだな。
そういう尤もらしい話並べて、プログラマー、アーキテクト、SE、
マネージャー・・・と職能で分類しようとして失敗してるんだろ。
実際にプロジェクトを成功に導くのに必要な人材、職能が定まらず、
適材適所も形だけ、結果、揉め事が耐えないデスマプロジェクトが
出来上がるというのが現状だろ。
独りで全部出来る奴がプロジェクトに、１人は必要なんだよな、現実
的には。異論もあるだろうが、100%間違いと言い切れる奴はおるまい。
>>975
全てのスキルを網羅した上で、当該プロジェクトにおける自分の役割に
応じた仕事をする。いざと言う時に、他人のヘルプに入れる人材になるの
つーのが最終形だと思うぞ。
ソフト開発のスキルを明確に分類する事なんて不可能だからな。
ソフト技術者も付加価値つけないと生き延びられないぜ。
なんだかんだ言っても、ソフト開発で普遍的なスキルといえば、
PGしかないんよ。PG以外のスキルは各社各様さ。
話をぼかしているだけだな。
そういう尤もらしい話並べて、プログラマー、アーキテクト、SE、
マネージャー・・・と職能で分類しようとして失敗してるんだろ。
実際にプロジェクトを成功に導くのに必要な人材、職能が定まらず、
適材適所も形だけ、結果、揉め事が耐えないデスマプロジェクトが
出来上がるというのが現状だろ。
独りで全部出来る奴がプロジェクトに、１人は必要なんだよな、現実
的には。異論もあるだろうが、100%間違いと言い切れる奴はおるまい。
>>975
全てのスキルを網羅した上で、当該プロジェクトにおける自分の役割に
応じた仕事をする。いざと言う時に、他人のヘルプに入れる人材になるの
つーのが最終形だと思うぞ。
ソフト開発のスキルを明確に分類する事なんて不可能だからな。
ソフト技術者も付加価値つけないと生き延びられないぜ。
なんだかんだ言っても、ソフト開発で普遍的なスキルといえば、
PGしかないんよ。PG以外のスキルは各社各様さ。
>>976
でもそういうことを考えるとプログラムの知識ばかりを要求するC/C++erって邪魔にならないか?
でもそういうことを考えるとプログラムの知識ばかりを要求するC/C++erって邪魔にならないか?
うちの会社はCもC++もC#もJavaもperlもVBも（中略）も使うから
結局全部勉強しなきゃいけねーんだよこん畜生！
結局全部勉強しなきゃいけねーんだよこん畜生！
第一にC++程度すら理解できないようじゃそれ以上に複雑な現実をモデル化することができるわけないジャン
980 ：仕様書無しさん：2006/01/04(水) 12:36:43
C++=>C#にうつったんだが、世間のC++は難しいといってるやつはどこのことを言ってるんだ?
メモリ管理?テンプレート?多重継承?オーバーロード?
メモリ管理?テンプレート?多重継承?オーバーロード?
982 ：仕様書無しさん：2006/01/04(水) 12:56:39
C++に慣れたからそう感じているだけのことだよ。
ブスも長年つれそうとかわいく見えてくるのと同じ原理
ブスも長年つれそうとかわいく見えてくるのと同じ原理
>>981
人によってどの機能をたくさん使うかわかれるのでソースコードに個性が出すぎてしまう点
人によってどの機能をたくさん使うかわかれるのでソースコードに個性が出すぎてしまう点
CやC++の自由度の高さはある意味凶器
つまり、それはよいことだ。管理・統制された共産主義は20性器末についに崩壊した。
>>985
いや、北斗の拳の世界並みに無秩序になるのも困るだろう。
いや、北斗の拳の世界並みに無秩序になるのも困るだろう。
CはともかくC++のスパゲッティーコードは
太陽めざして飛んで行きたくなるほど凄まじい
太陽めざして飛んで行きたくなるほど凄まじい
Javaなんかもっと飛散だ
>>982,983,984
あー言われてみればそうだな。Genericsの自由度の低さにないてるし。
でもそれをおぎなうC#+.NETの生産性の高さのせいでたぶんよっぽどでない限りC++は使わないと思う。
あー言われてみればそうだな。Genericsの自由度の低さにないてるし。
でもそれをおぎなうC#+.NETの生産性の高さのせいでたぶんよっぽどでない限りC++は使わないと思う。
990 ：仕様書無しさん：2006/01/04(水) 13:42:42
Java滅びろ
991 ：仕様書無しさん：2006/01/04(水) 13:43:02
発売当初、「生産性の高さ」 を謳っていた旧VBは今どうなった？
992 ：仕様書無しさん：2006/01/04(水) 13:45:27
993 ：仕様書無しさん：2006/01/04(水) 13:49:26
>>906
R22にしてもなにもかわりないと思うが。
今U30にしたら
愚痴ばっか吐いているキモイアニヲタやガンヲタが
多いバブル世代をコテンパに追い出してしまい
かなり寂しくなりそうだなw
バブル世代使用禁止令を発動してもいいぞw
R22にしてもなにもかわりないと思うが。
今U30にしたら
愚痴ばっか吐いているキモイアニヲタやガンヲタが
多いバブル世代をコテンパに追い出してしまい
かなり寂しくなりそうだなw
バブル世代使用禁止令を発動してもいいぞw
>>870
どんなのつくっとるんです?参考人させてくれ。
どんなのつくっとるんです?参考人させてくれ。
995 ：仕様書無しさん：2006/01/04(水) 13:53:33
>>910
> >>903
> JavaのGUIも複数のプラットフォームの共通項としてしか実装できない->低機能のGUIにならざるを得ない。
> これぐらい一瞬で浮かばんか?
高機能のGUIになるように自分でパーツを作れ。
MustangからはGUI周りがかなり進化するようだが。
BREWですら機能が足りないために仕方が無くスクロールバーなどを自作しているほどだぞ
> >>903
> JavaのGUIも複数のプラットフォームの共通項としてしか実装できない->低機能のGUIにならざるを得ない。
> これぐらい一瞬で浮かばんか?
高機能のGUIになるように自分でパーツを作れ。
MustangからはGUI周りがかなり進化するようだが。
BREWですら機能が足りないために仕方が無くスクロールバーなどを自作しているほどだぞ
996 ：仕様書無しさん：2006/01/04(水) 13:55:11
なんだ GUI屋か
997 ：仕様書無しさん：2006/01/04(水) 13:57:49
やっぱ必要なのはコミュニケーション能力だね。
998 ：仕様書無しさん：2006/01/04(水) 13:59:17
Java技術者が3人集まると話が進まない
999 ：仕様書無しさん：2006/01/04(水) 14:02:34
船頭多くして船山に登る
1000なら全員1年以内にリストラ
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。