- 1 名前：仕様書無しさん [2007/02/14(水) 15:14:25 ]
- 言語機能的にも実装的にもどっちが上なんですか？
- 852 名前：仕様書無しさん mailto:sage [2009/01/01(木) 21:38:07 ]
- クラスプラットフォームなんてのは幻想だ。
まともに動きやしねえ。
- 853 名前：仕様書無しさん [2009/01/01(木) 22:51:43 ]
- >>852
具体的には？
うちでは普通に使っているけど、
なんら問題なく運用回ってるよ。
Windows上でうまく行ってLinuxで不可能なことって何だ？
- 854 名前：仕様書無しさん mailto:sage [2009/01/01(木) 23:03:32 ]
- そのうちまともに動くようになるんじゃないの。
- 855 名前：仕様書無しさん mailto:sage [2009/01/02(金) 11:07:07 ]
- Java製ソフト作るとき、逆コンパイル対策とかやってますか？
- 856 名前：仕様書無しさん mailto:sage [2009/01/02(金) 11:45:52 ]
- 逆コンパイルしても読む気が失せるくらい汚いコード書くようにしてる
- 857 名前：仕様書無しさん [2009/01/02(金) 14:28:56 ]
- ms-officeすら綺麗にパクれないjavaは糞
- 858 名前：仕様書無しさん mailto:sage [2009/01/02(金) 15:00:36 ]
- ms-officeってN88BASICで作ってるんだよね
- 859 名前：仕様書無しさん mailto:sage [2009/01/02(金) 17:39:25 ]
- >>856
さすがにそれじゃ自分の首しめるぞｗ
Javaは難読化ツールがあったはず。試したこと無いけど。
- 860 名前：仕様書無しさん mailto:sage [2009/01/02(金) 18:11:46 ]
- >>851
ぎゃくにJavaの必要性あるか？
リソースをふんだんに使えるならRubyやらPythonとかのOOPLで十分だし、
早さが必要なら依然C++。JITをメリットに掲げたところでLLVMや.Netの出現で
最早Javaの特権ではなくなったわけだし。
そういや、遂にC++で回路を動作合成できるようになったな。
マルチプラットフォームを謳うJavaがこの地に足をつける日はいつになるのやら。
- 861 名前：仕様書無しさん mailto:sage [2009/01/02(金) 18:33:17 ]
- こういう信者ホイホイみたいなスレは
ダラダラと伸びるね
- 862 名前：仕様書無しさん [2009/01/02(金) 18:41:34 ]
- >>860
HibernateやiBatisなどのO/Rマッピングフレームワーク、
strutsやSpring、seaser2などのフレームワークなど新米PGが開発しても
そこそこまともなアプリになる。
Java関連の入門書、専門書は他言語に比べて圧倒的に多く独学でも勉強しやすい。
C++みたいに難解な言語ではない。
これだけでも十分必要な開発言語でしょｗ
そりゃ極めりゃC++のほうが実行速度が速いしいいのかもしれんが
頭のいいやつにしかできん言語なんぞ廃れるのは火を見るより明らかなのは当然です。
- 863 名前：仕様書無しさん mailto:sage [2009/01/02(金) 22:12:34 ]
- >>851
仕事は、環境もセットで納品するからJavaでも良いんだよな
趣味ソフトは、Javaは配布すると環境の問題で動きませんとかうざいので
どうしても展開すれば即起動可能に出来るC/C++になるかな
.netも人によってはフレームワーク入ってないとかあるし
スクリプトも結局インタプリタ入れさせないといかんし
- 864 名前：仕様書無しさん [2009/01/02(金) 23:36:13 ]
- >>851
unixしらねーｱﾎは黙ってれば？
unixでc++ならソースレベルでクロスプラットフォームだっつーの
- 865 名前：仕様書無しさん [2009/01/03(土) 00:12:27 ]
- >>864
unixとwindowsじゃ開発スピードが全然違うよ。
>>860
Javaもそんなに遅くは無いぞ。
速さが必要だったとしても、C++の開発の非効率性から考えると、
割が合わないことが多い。
- 866 名前：仕様書無しさん [2009/01/03(土) 00:16:33 ]
- >>863
趣味ソフトのほうがむしろJavaでは？
仕事の場合どうしてもパフォーマンス云々でC++を余儀なくされることはあるが、
趣味であれば容易に保守がしやすいJavaを選ぶのが賢明。
それに、環境の問題ごとき、適切なread me 入れれば特に問題は無いだろ。
>>855
してない。
というか、むしろ俺の場合オープンソースで配布してるからな。ｗ
難読化とか、そんな小細工しなくても、
著作権法という法律面で守られているから、特に神経質になる必要はないと思うけど。
- 867 名前：仕様書無しさん mailto:sage [2009/01/03(土) 00:23:10 ]
- >>862
そういうことだね。
Javaはオープンで用意されているライブラリや、
設計やリバースエンジニアリングのツールとかが豊富なんだよな。
あとPGが学習するための資料や環境も十分にある。
こういった取っ付きやすさもJavaの強みだ。
- 868 名前：仕様書無しさん mailto:sage [2009/01/03(土) 00:25:56 ]
- しかし趣味でもJavaやC++なんか書きたくないわー
- 869 名前：仕様書無しさん mailto:sage [2009/01/03(土) 23:34:07 ]
- 一番とっつきやすいのはVB.NET
- 870 名前：仕様書無しさん mailto:sage [2009/01/04(日) 02:28:53 ]
- >866
著名なアプリを見る限りでは、個人製作のは圧倒的にC/C++が多いんだが。
Java製のはEclipseみたいに企業がバックについてるの以外ほぼ見かけない。
日本のWindows界隈に限った話だけど。
- 871 名前：仕様書無しさん mailto:sage [2009/01/04(日) 15:35:42 ]
- >>862
だから速度いらねーならスクリプトでいいじゃん。
携帯電話とかは別としてスクリプトならマルチプラットフォームだし。
>>865
効率とはライブラリのことかな？まともに書いたコードのこしておけば大差さないだろ。
int main(void)
{
Model model;
Form view(model);
view.Visible(true);
}
- 872 名前：８７１ mailto:sage [2009/01/04(日) 15:41:58 ]
- 間違えて書いてる最中に送信押してしまったOTL
>>865
効率とはライブラリのことかな？まともに書いたコードのこしておけば大差さないだろ。
int main(void)
{
Model model;
Form<Controler> view(model);
view.Visible(true);
return 0;
}
一回ライブラリ化してしまえばC++でGUI表示させるのもこんなもんだし。
特に分数とか超倍整数なんてJavaのほうがよっぽど効率悪いと思うが？
typedef Fraction<int> f;
f a=f(5,2)+f(10,3);
- 873 名前：仕様書無しさん mailto:sage [2009/01/04(日) 17:43:09 ]
- >>871
JavaぐらいAPIが用意されてて統合開発環境が充実しているスクリプト言語教えてくれ。
速度いらない＝スクリプト の考え方はレベルが低いですよ。
- 874 名前：仕様書無しさん mailto:sage [2009/01/04(日) 18:42:35 ]
- >>873
CPANとか触れたことあるか？
Shell Scriptは？#まぁ、こっちは状況で制限を喰らうことはあるが
あと、スクリプト系でIDEのありがたみを感じたことはない。
必要なところは言語機能が補完してくれるからね。
OO系ならRubyとか型いらずでめっさ楽。それでいて本当のポリモーフィズムが行える。
- 875 名前：仕様書無しさん mailto:sage [2009/01/04(日) 19:00:28 ]
- 本当のポリモーフィズム？
じゃあ、本当じゃないポリモーフィズムとは一体？
JavaぐらいAPIが用意されてて統合開発環境が充実しているスクリプトマダー？
- 876 名前：仕様書無しさん mailto:sage [2009/01/04(日) 19:15:06 ]
- >>870
俺んとこの/usr/binをほじくったら、開発ツール以外でjavaはoperaだけだった。
ただし、シェルスクリプトとかとミックスしてるけどね。
あと、名前を聞いただけだがLimeWireってのもJava製らしいねぇ。
やっぱり個人レベルの有名どころは無いな。
- 877 名前：仕様書無しさん mailto:sage [2009/01/04(日) 19:26:59 ]
- >>875
だからCPANとかあるだろうが。
そうでなくとも、PhytonとかRuby、Perlといった
メジャー言語はリポジトリを覗けばGUIからネットワークまで
操作できるライブラリが準備されてるってのに。
プラットフォームがUNIX系ならすべてのコマンドが関数と同じだし。
(関係ないがJavaのAPIって表現おかしくね？)
本当ポリモーフィズムじゃないってのはインターフェース等で
束縛されたポリモーフィズム。C++から続く型安全は保証されるかわりに
柔軟性が無い。もし似たような事をするなら1メソッドのインターフェース
を大量に作りそれを実装させるしかない。それでも記憶効率なんかは
言語機能として搭載されているものに比べ下がるけど
- 878 名前：仕様書無しさん mailto:sage [2009/01/04(日) 20:03:40 ]
- > 本当ポリモーフィズムじゃないってのはインターフェース等で
> 束縛されたポリモーフィズム。
では、インターフェース等で束縛（？）されないポリモーフィズムが、
本当のポリモーフィズムだと？
ひょっとして、ダックタイピングと強い型付けの話をしてない？
それはポリモーフィズムじゃなく、単に型についての議論では？
本当のとそうでないのとのポリモーフィズムについての議論、
なんかどっかにソースある？ Smalltalk界隈とか？
ポリモーフィズムはどこまで行っても単にポリモーフィズムでは？
- 879 名前：仕様書無しさん mailto:sage [2009/01/04(日) 21:11:39 ]
- 議論に参加しようと思ったけど
ポリモーフィズムをまともに論じようと思えば圏論の知識が要るらしいから
勉強してからにします
- 880 名前：仕様書無しさん mailto:sage [2009/01/04(日) 21:35:27 ]
- >>878
いい反応だねぇ。もっと具体的に言えばメッセージング。まぁ、
これを言うとRubyなんかも若干中途半端な言語ということになるけど。
感覚として完全なポリモーフィズムと言うと
Smalltalk>Objective-C、Javascript>Ruby、Python他OO系LL>>>>Java>C++
こんなかんじかな。C++もダックタイプはできるけど配列なんかじゃ生かせない。
Javaはライブラリを使えば近いことはできるけど言語機能であるのとは訳が違う
(それが有りならC++も有りだ
Objective-Cはメッセージングとしてかなりいい線を行っているがメッセージその物を
オブジェクトとしては扱えない。
- 881 名前：865 mailto:sage [2009/01/05(月) 20:13:34 ]
- >>871 >>872
それは趣味でプログラム書きたいときの話？
それだったら別に好きなほうで書けばいいじゃない。
俺が言ったのは、会社などの組織で使う場合の話ね。
>まともに書いたコードのこしておけば大差さないだろ。
>一回ライブラリ化してしまえばC++でGUI表示させるのもこんなもんだし。
オブジェクト指向なんだから一度モジュール化してしまえば使えるのは当然。
しかし、大規模なシステムになってくると、
そういうモジュールも属人的な部分が目立ち始めて保守性も悪くなる。
その点Javaであれば標準として備わっているものが多い。
例えば新しい人を雇った場合には、
前の同じようなフレームワークやライブラリを使った経験があれば、
すぐにその技術を活かしてもらうことができる。
- 882 名前：仕様書無しさん mailto:sage [2009/01/06(火) 02:27:09 ]
- >873
クロスプラットホームの縛りが無いようなので、C#でも挙げとこうかw
ちなみ.NETはM$製であるせいかウケが悪いが、（漏れも眼中に無かった）
Javaの利点に加えてgccのように多言語対応、パフォーマンスもVB並(?)なんで
個人的には期待してる。
好みの言語で作ったライブラリを、対応言語・対応プラットホーム全てで共有できるというのは、
M$発祥であることを考慮しても、もっと評価されて良いと思うんだが。
- 883 名前：仕様書無しさん mailto:sage [2009/01/06(火) 10:48:15 ]
- >>881
デファクトスタンダードなライブラリならC++の方が多いんだよチミ。
そもそも、標準ライブラリは最小限にして他で補うのがC++の指針だからね。
もし標準ライブラリ以外使用禁止で有名ライブラリが使えないという職場環境
ならご愁傷様としか言いようは無いけどねぇ。
あと、新規にライブラリ構築するならJavaだろうがC++だろうが他の言語だろうが
状況は変わらないだろ。優秀なアーキティクトやライブラリアン居るかいないかって
だけの事。
#とは言っても日本にゃ居なそうだけどナァ
- 884 名前：仕様書無しさん mailto:sage [2009/01/06(火) 19:44:51 ]
- >>883
>もし標準ライブラリ以外使用禁止で有名ライブラリが使えないという職場環境
>ならご愁傷様としか言いようは無いけどねぇ。
まぁそういうこと。
システムには当然信頼性が求められるわけだが、
それにはサポートがきっちりされているかどうかも大切な一要素とされる。
もっとも俺はC++にJavaを超えるほどの良質なライブラリがあって、
Javaよりも手早くシステムの作成が可能だなんて思えないが。
仮に百歩譲ってそうだったとしても、
どうしても利益を求める組織は、
標準で用意されている機能が豊富なJavaを使いたがるだろうな。
- 885 名前：仕様書無しさん mailto:sage [2009/01/06(火) 19:56:04 ]
- 標準で、っていうところがポイントで、
Javadocで作られたあのびっしりとしたAPI 仕様、
あれが標準で用意されているのもでかいと思う。
- 886 名前：仕様書無しさん mailto:sage [2009/01/06(火) 21:16:52 ]
- >>884
よくある経営者の流行り乗り。
金がある奴は何かうまくと聞くと
知りもしないのによく飛びつくw
ウチの取引先の管理職なんて
オブジェクト指向はGUIの様な
もんだと思ってる。
そりゃ、社員も青ざめるわな。
- 887 名前：仕様書無しさん mailto:sage [2009/01/06(火) 21:37:59 ]
- >>886
？？？
全然違う話をしているな？？
俺はリスクの観点で話してるんだが。
要はシステムに不具合が発生したとき、
標準のを使っていると原因を特定しやすいし、責任とかもしっかりしてるだろ。
- 888 名前：仕様書無しさん [2009/01/06(火) 22:00:01 ]
- あと、有名ライブラリよりも、
標準で用意されていたほうが、
スキルをどこでも活かせるというメリットがある。
標準で用意されていないと、
現場によって使っているライブラリ違ったら、
また学習しなおしだから、それだけ人件費がかかるということ。
- 889 名前：仕様書無しさん [2009/01/07(水) 08:22:31 ]
- 馬鹿が多い現場ではJAVAがいい
- 890 名前：仕様書無しさん mailto:sage [2009/01/07(水) 17:48:48 ]
- >>889
Javaが良いって言うか…
まぁC++をバカに触らせるよりは、確かに問題は減るかもなｗ
- 891 名前：仕様書無しさん mailto:sage [2009/01/07(水) 19:22:36 ]
- 結論：どっちも優れている。状況に応じて使い分ければいい
- 892 名前：仕様書無しさん mailto:sage [2009/01/07(水) 20:18:36 ]
- >>889
そういうこと。
バカが多い現場でJavaを使えば問題が減る。
優秀なやつが多い現場でJavaを使えばより開発がスムーズに行く。
どちらにせよJavaを使えば間違いなし。終了。
- 893 名前：仕様書無しさん mailto:sage [2009/01/07(水) 20:22:57 ]
- でも、止めちゃイケナイものが入れ替え後に問題起こして止まってしまうのは
いつもJavaを採用したもの。
- 894 名前：仕様書無しさん mailto:sage [2009/01/07(水) 20:52:33 ]
- >>893
意味が分からんｗ
たまたまだろ。
- 895 名前：仕様書無しさん mailto:sage [2009/01/08(木) 07:02:53 ]
- 去年トラブった某J○Bの基幹系システムってたしかJavaだったよね。
- 896 名前：仕様書無しさん mailto:sage [2009/01/08(木) 11:33:50 ]
- >>893
その理論は無理があるｗ
C++で作ったって、止まるときゃ止まるｗ
- 897 名前：仕様書無しさん mailto:sage [2009/01/08(木) 12:25:29 ]
- むしろC++のほうが（ｒｙ
- 898 名前：仕様書無しさん [2009/01/08(木) 12:32:12 ]
- 889に戻る
- 899 名前：仕様書無しさん mailto:sage [2009/01/08(木) 17:04:39 ]
- Javaなら低コストかつ安全です＾＾v
ってJava厨がしつこいから入れ替えてみたらトラブル多発とか。
- 900 名前：仕様書無しさん [2009/01/08(木) 17:15:05 ]
- IBMとスルガ銀行のやつがJAVAだっけ？
- 901 名前：仕様書無しさん mailto:sage [2009/01/08(木) 23:34:36 ]
- Javaは軟派なイメージ
C++は硬派なイメージ
- 902 名前：仕様書無しさん mailto:sage [2009/01/09(金) 01:58:28 ]
- >>899
>Javaなら低コストかつ安全です＾＾v
そりゃうそだ。Javaの開発は決して安くはない。
- 903 名前：仕様書無しさん [2009/01/09(金) 03:34:38 ]
- Ｃ＋＋が先にできて．．だから、その改良型だよＪＡＶＡは。
Ｃ＋＋がＦ１カーとすれば、ＪＡＶＡは日産ＧＴ−Ｒのようなもの。
プロの君は、どっちを使う？ もう分かったよね？
- 904 名前：仕様書無しさん mailto:sage [2009/01/09(金) 07:26:07 ]
- なら例えばC#はさらに改良されたと言えるのではないかい？
あるいはDだってあるぞ。
- 905 名前：仕様書無しさん mailto:sage [2009/01/09(金) 21:50:38 ]
- C/C++はドライバや中小規模のアプリを作成するのには向いているが、
大規模なアプリやサービス構築するのには不向き。
Javaは逆に大〜中規模のアプリやサービスには向いてるが、
小規模なアプリやドライバとかには向かない。
例えるなら戦術に長けるC/C++、戦略に長けるJavaと言った所。
- 906 名前：仕様書無しさん mailto:sage [2009/01/09(金) 22:18:22 ]
- >>905
君の知る大規模とは何だい？
まさか、銀行システム程度の規模じゃないよね。
各種ミドルウェアは何で構成されているか知ってるかい？
DB、VM、各種COMアパートメント、エミュレーター、インタプリタ。
どれもCかC++。
アプリケーションレベルでもExcel、Word、統合開発環境。
本当に大規模なプログラムは大抵CかC++になるんだよ。
2000年からリリースされて早9年。なんで、JavaでEclipseや
Opera、OOoぐらいしか著名アプリが作成されていないか解るかい？
Javaの謳い文句が現場のメリットとして形を成してないんだよ。
- 907 名前：仕様書無しさん [2009/01/09(金) 22:21:06 ]
- このスレ意味なくね？
- 908 名前：仕様書無しさん mailto:sage [2009/01/09(金) 22:44:55 ]
- 本当に優秀なのはどっちも使えるプログラマってことだよな
- 909 名前：仕様書無しさん mailto:sage [2009/01/09(金) 22:52:50 ]
- >>906
ムキになってるところすまんが、規模って案件の規模のことじゃね？
銀行の基幹系みたいに何百人が開発に関わるような規模だと
使える技術者を集めやすいかとか、低コスト短期間でそれなりの
クオリティのものを出せるかで使える言語も変わってくるだろ。
そりゃコストに制限がなければ優秀なC++プログラマでも集めて
好きなだけオーバーエンジニアリングしてりゃいいけどさ。
- 910 名前：仕様書無しさん mailto:sage [2009/01/09(金) 23:10:29 ]
- >>906
>>905じゃないけどよ、
>2000年からリリースされて早9年。
>著名アプリが作成されていないか解るかい？
そりゃ古い有名アプリはC/C++が主流の頃作られたんだから、
Java使われてなくて当たり前だろｗ
分かってないのお前だけじゃないのか？ｗ
Javaはほとんどの場合の現場において、C/C++よりも効率的な事は事実。
もっとも俺は、小規模でもJavaが向かない理由は無いと思うがね。
main関数一つで出来たような、本当に小さい規模なら別かもだがｗ
- 911 名前：仕様書無しさん mailto:sage [2009/01/09(金) 23:12:14 ]
- てか、
>DB、VM、各種COMアパートメント、エミュレーター、インタプリタ。
低次元の事をやりたいんならC/C++が向いてるに決まっているだろｗ
だが、そんな低次元のコーディングが求められる事は、
ほとんどのシステム開発においてないよ。
- 912 名前：仕様書無しさん [2009/01/09(金) 23:43:13 ]
- コマンドプロンプトで、コンパイルするとclはバッチ ファイルとして認識されていませんとなるのですが、どうしてか教えてください＞＜
プログラミング初心者です。
- 913 名前：仕様書無しさん mailto:sage [2009/01/10(土) 00:00:25 ]
- 使えないなら無理して使わなくていいと思う
- 914 名前：仕様書無しさん mailto:sage [2009/01/10(土) 00:55:02 ]
- >>910
一応著名なアプリOOoは破綻気味ですが
なんでだろうね？
>>911
JRuby、Jythonなどある訳ですが？
別にJavaで、できない程低水準な訳じゃない。
ライブラリに依存しすぎて言語機能として貧弱なんだよJavaは。
- 915 名前：仕様書無しさん mailto:sage [2009/01/10(土) 04:37:47 ]
- なんでそんなに低水準を基準にして考えるのでしょうか？
業務用アプリでJava使うのはメンテナビリティを考えてるからでしょ。
言語として優れてるかどうかなんてプログラムが好きな人間が考えること。
企業は将来的に保守に金かからない言語とるのは当然だし、だからJavaが
今でも新規開発で使われてると思ふ。
一昔前のJavaならCチックなコーディングもかなりあるけど新規で開発してる
Javaに関してはかなりきちんとしたオブジェクト指向のソースですよ。
なので業務という点でいえばJavaのほうが優れている。
言語としてはしらん。
- 916 名前：仕様書無しさん mailto:sage [2009/01/10(土) 07:20:16 ]
- >906,911
ドライバ開発とか組み込みを忘れて内科医。
Javaでドライバなんて聞いた事ないし、組み込みもケータイアプリ等に用途が限られてる。
>915
>業務用アプリでJava使うのはメンテナビリティを考えてるからでしょ。
COBOLやVBと同じで、「質より量」的運用ができるからだと思うけど。
実際、業務で競合する言語はC/C++じゃなくてそっちでしょ。
- 917 名前：仕様書無しさん mailto:sage [2009/01/10(土) 11:32:34 ]
- >>915
その水準ならグルー系言語で十分だよ。
暫くしたらJavaも取って代わられるよ。
早さはミドルウェアに任せれば良いし、
POSIXコマンドや、CPANの様にJava
ライブラリとは比較に成らない規模の
ライブラリがある。
- 918 名前：仕様書無しさん mailto:sage [2009/01/10(土) 13:39:20 ]
- 結局2ｃｈ並みに大量に処理する必要があるなら
必然的にメモリ単位で処理を設計できる
Ｃ＋＋が圧勝だろ
- 919 名前：仕様書無しさん mailto:sage [2009/01/10(土) 17:01:35 ]
- 結局は適材適所ということか
- 920 名前：仕様書無しさん mailto:sage [2009/01/10(土) 18:04:11 ]
- 適材適所なんて、少なくとも >>20 で答えが出てる訳で
- 921 名前：仕様書無しさん mailto:sage [2009/01/10(土) 18:13:47 ]
- >>914
正直言っている意味がわからねぇｗ
>別にJavaで、できない程低水準な訳じゃない。
>ライブラリに依存しすぎて言語機能として貧弱なんだよJavaは。
この二つの行で既に言っている事が矛盾しているわけだがｗ
>>918
大量の処理をするのにメモリ単位で処理を設計？
何年前の話だｗ
今はそんなのを意識しなくても済むようなハードウェア性能があるんだよ。
むしろ、そんなプログラム作られた日にゃ保守が困るからやめて欲しいだろう。
>>917
Javaと比較にならないほどの高性能統合開発環境や、マニュアルが存在するのか？
>>916
組み込みの話なんて誰がしたの？
大規模なシステムっていったら基幹システムとか、
日々の業務処理を行っている重要な部分のことだろ。
- 922 名前：仕様書無しさん mailto:sage [2009/01/10(土) 18:37:45 ]
- で、ナルトとルフィはどっちが強いんだ？
- 923 名前：仕様書無しさん mailto:sage [2009/01/10(土) 18:54:01 ]
- >>922
ナルト=C++ ルフィ=Java という認識でよろしいか意識あわせしましょう。
- 924 名前：仕様書無しさん mailto:sage [2009/01/10(土) 21:00:58 ]
- >921
「組み込み」とは誰も書いてないけどけど、>905に
c/c++ … ドライバや中〜小規模アプリ向き
Java … 大〜中規模アプリ向き
って書いてあるのを良く見てね。（’ドライバ’に注目）
あと基幹システムとかにはJava’の方’が向いてるのは否定してないから。
ただしJava’だけ’が向いてるとは思わないけどね。
- 925 名前：仕様書無しさん mailto:sage [2009/01/10(土) 21:32:51 ]
- >>921
>>別にJavaで、できない程低水準な訳じゃない。
>>ライブラリに依存しすぎて言語機能として貧弱なんだよJavaは。
>この二つの行で既に言っている事が矛盾しているわけだがｗ
矛盾か？一行目は「組み込みレベルでは実質Javaを使うのは無理だが
ミドルウェアレベルならAPI直叩きする必要は無いから実装は可能。」
ということだと思うが？で二行目は、ライブラリに無いアルゴリズムや
テクの比率が多い場合言語機能で凌ぐしかないって事だろ。
>Javaと比較にならないほどの高性能統合開発環境や、マニュアルが存在するのか
Java向け統合開発環境以上の統合開発環境が無いとまともに開発できないの？
着色とソースコードを飛び回るぐらいならemacsやvi、幾らでもある。
使いやすい言語ならテンプレート生成やインテリセンスとか凝ったリファクタリングツールは要らんぞ。
- 926 名前：仕様書無しさん mailto:sage [2009/01/10(土) 21:38:34 ]
- ところで、特に意味もなくC/C++と表記するのは何故？
機能規模が全然違うんだからC++だったらC++と書けば？
C++で開発経験が無いのに書き込んでる様に見える。
- 927 名前：仕様書無しさん mailto:sage [2009/01/10(土) 23:46:00 ]
- >>926
C++がCと同じ使われ方しかしてないからそう表記するんじゃね？
Java/Javascriptとはかかんでそ？
- 928 名前：仕様書無しさん mailto:sage [2009/01/11(日) 00:14:01 ]
- >>927
世間一般の表記の事を言ってる？
そういうことじゃなくて、このスレの中の話でCとC++を
ごっちゃにしてるのはどうよと言う話。
CとC++じゃ機能や移植性が異なるから開発する
世界かなりが違う。単に早さやCの仕様内の話ならC/C++
で構わんだろうがテンプレートなどを含めた話ならC++と
書かないとあんまり仕様を知らないように見える。
昔かし、C/C++が使えますと言って入ってきた新人が
全然C++を知らなかった事があって個人的どうしてもそう見える。
(学校でVC++を触ったことがあってそう言ったらしい)
- 929 名前：仕様書無しさん mailto:sage [2009/01/11(日) 00:32:52 ]
- 課題だして確かめなかったのが悪いのさ。
- 930 名前：仕様書無しさん mailto:sage [2009/01/11(日) 00:56:37 ]
- ではVBよりVC++使うことがあるということは
C++には何らかの利点があるということか
- 931 名前：仕様書無しさん mailto:sage [2009/01/11(日) 01:32:10 ]
- >>924
>「組み込み」とは誰も書いてないけど
はぁ？
>>916
>ドライバ開発とか組み込みを忘れて内科医。
>Javaでドライバなんて聞いた事ないし、組み込みもケータイアプリ等に用途が限られてる。
書いてんじゃん。
だめだ。お前はもう話にならない。
>>925
>Java向け統合開発環境以上の統合開発環境が無いとまともに開発できないの？
保守的な人はこれだから…（笑）
非効率な事を一生懸命やって、評価される時代は終わったのｗ
これからの時代は、利用できるものは利用して、
仕事を効率的に進めた人の勝ちなの。ｗ
お前が言っているのは「自分はviを使いこなせる」とか、
「リファクタリングツールが無くてもまともな開発ができる」と自慢をしているだけで、
Javaより優れた言語であるか？という問いに関してはまるで答えになっていない。
まぁ、お前は必死に 統合開発環境vi(笑)つかってプログラミングしててくださいよ。
- 932 名前：仕様書無しさん mailto:sage [2009/01/11(日) 01:39:31 ]
- >926
組み込み分野だと、ハードに近い部分ほとC的、遠くなるにつれてC++的になる傾向があり
C++をベターC的に使うことが多いんで、CでもC++でもなくC/C++。
>930
ライブラリやフレームワークの類が、ヘッダとlib/dllしか無いってのは割とあるから、
MFCが扱える程度のC++の知識/技術があれば、VC++使った方が手っ取り早い。
ただCOMとかはVBの方が扱いやすい。（VBじゃなくても良いけど）
- 933 名前：仕様書無しさん mailto:sage [2009/01/11(日) 01:54:10 ]
- >931
えーと。
>921が>916に対して「誰が組み込みと言った」とツッコミ入れたのに対し、
>924は>916は>905を受けて書いてるから…と返している。
要するに>924は>916へのフォロー。
それに対して「>916が書いてるだろ」って…
「バカと言う奴がバカ」に対し、「今言った」と返すようなもんだぞ?
- 934 名前：仕様書無しさん mailto:sage [2009/01/11(日) 02:06:26 ]
- >931
Java使いが他を「保守的」と言うのは違和感があるな…
emacs、viは安全性より利便性を追求する傾向にあるから、
保守的とは言わんと思うんだが。（C++も同様）
古臭いとか、時代遅れというならまだ分かるんだが…
933の件もそうだけど、よく国語力が無いとか言われない?
- 935 名前：仕様書無しさん mailto:sage [2009/01/11(日) 02:44:54 ]
- >>933 >>934
そういう揚げ足はもういいよ。
面倒くさい。
本題と関係ないし。
話をすりかえるな。
- 936 名前：仕様書無しさん mailto:sage [2009/01/11(日) 02:54:02 ]
- 933はむしろ意味不明な揚げ足取りへの反論。
- 937 名前：仕様書無しさん mailto:sage [2009/01/11(日) 03:20:11 ]
- Java = 凡人
C++ = 職人気取り
C = 原住民
VB = 新成人
VC++ = 五月病
こんな感じだな
- 938 名前：仕様書無しさん mailto:sage [2009/01/11(日) 12:44:59 ]
- >>914
> ライブラリに依存しすぎて言語機能として貧弱なんだよJavaは。
ライブラリに依存しすぎて、の意味が分からない。
誰か分かるやついる？
- 939 名前：仕様書無しさん mailto:sage [2009/01/11(日) 12:50:41 ]
- >>914
ついでにこれも意味が分からない。
>一応著名なアプリOOoは破綻気味ですが
なにがどう破綻してるのか。
>>934
>emacs、viは安全性より利便性を追求する傾向にあるから、
viが利便性追求？？
あのー。何年前の話してるんでしょうかｗ
>よく国語力が無いとか言われない?
国語ではなく、Java言語、C++言語の話をしています。
>>936
反論？？
どう見ても苦し紛れのいいわけだろｗ
なんだよ、あの日本語はｗ論理にもなってねぇ
- 940 名前：925 mailto:sage [2009/01/11(日) 13:00:24 ]
- >>931
>使いやすい言語ならテンプレート生成やインテリセンスとか凝ったリファクタリングツールは要らんぞ。
俺が強調したいのはこっちなんだが。
レスするならこっちにレスしてくれ。
- 941 名前：仕様書無しさん mailto:sage [2009/01/11(日) 13:04:59 ]
- 【オープンソース】開発者24人のOpenOffice.は「極めて病んでいる」「停滞している」(2008/12/30)
pc11.2ch.net/test/read.cgi/pcnews/1230658127/
- 942 名前：仕様書無しさん mailto:sage [2009/01/11(日) 13:15:53 ]
- >>938はもしかしたらライブラリと自前のコードが1:9になるような
開発をした事が無いんじゃなかろうか？
- 943 名前：仕様書無しさん mailto:sage [2009/01/11(日) 13:25:43 ]
- >>942
1:9って言われても、ねえｗ
>>914の言ってること、分かる人？
- 944 名前：仕様書無しさん mailto:sage [2009/01/11(日) 13:30:10 ]
- >>942
> >>938はもしかしたらライブラリと自前のコードが1:9になるような
ライブラリと自前のコードが1:9になる、の意味が分からない。
誰か分かるやついる？
- 945 名前：仕様書無しさん mailto:sage [2009/01/11(日) 14:32:31 ]
- >>940
そんなに強調したいんならもうちょい説明お願いしようか。
>使いやすい言語ならテンプレート生成やインテリセンスとか凝ったリファクタリングツールは要らんぞ。
こう思う理由はなんだ？
お前の言っている理論は、根拠が抜けてるんだよ。
リファクタリングツールは高性能であればそのほうがいいだろう。
保守対象となったシステムの前任者が、
分かりにくいソースコードを書いていたらなおさらの話。
てか、常識的な事をいちいち俺にレスさせるな。
お前もしかして仕事で開発やったこと無いの？
学生？？
- 946 名前：仕様書無しさん mailto:sage [2009/01/11(日) 15:21:29 ]
- >>938
CもC++も、ライブラリの山だと思うんだが
STLもboostも、その他Cが便利な理由は全部ライブラリだろ
stdioさえもライブラリなんだから、Javaとさほど変わらない程度には依存していると言えそうだが
- 947 名前：仕様書無しさん mailto:sage [2009/01/11(日) 15:32:41 ]
- >>943-944
代表例組み込み
組み込みは極端過ぎるが科学計算関係も良い例。
入出力関係と一部の数学系関数以外は計算が大半を締める。
- 948 名前：仕様書無しさん mailto:sage [2009/01/11(日) 16:02:00 ]
- >>945
リファクタリングツールは有るに越したことは無い。
しかし、型依存しない言語などだとどうだい？
色々リリースされているリファクタリング機能の内
何割が必要になる？大体必要になるとすれば
名前変更と、重複管理ぐらいになるだろうよ。
君がJavaしか使えなら知らないが。他の言語の
知識があるならオープンソースの世界でどう
保守されているか覗いてみるといい。
- 949 名前：仕様書無しさん mailto:sage [2009/01/11(日) 17:46:28 ]
- >>948
>型依存しない言語などだとどうだい？
すまんがさっきから何が言いたいのか全然伝わらんぞ？
型依存しない言語だと、型の変更をするためのリファクタリングが必要ないから、
リファクタリングツールのほとんどの機能がいらない。とでも言うのか？
本気でそんな事言っているとしたら話にならないよ。
確かに狭義の意味での「リファクタリング」であれば、百歩譲って一理あると言ってもいいが、
統合開発環境があれば、継承関係や委譲関係が一目瞭然だし、
UMLへのリバースエンジニアリングも一瞬だ。
いくら言語が優れていようとも、これらの機能が不要とはならないと思うんだが。
- 950 名前：仕様書無しさん mailto:sage [2009/01/11(日) 19:42:04 ]
- >>947
く、組み込み？？
か、科学計算関係？？
な、なんかアホらしくなってくるな。
- 951 名前：仕様書無しさん mailto:sage [2009/01/11(日) 21:14:46 ]
- >950
今時そんな仕事ねーよという意味でアホらしいとか言ってるなら、
あるわボケ、と返しておく。
あと組み込みだと1:9どころか0:10に限りなく近い現場もごく稀にある。
一昔前だとコンパイラも作ってたり。
科学計算に関しては1:9はちょっとうそ臭い。piとかsinとかも自作してるんだろうか?
パッケージ使わないの?
- 952 名前：仕様書無しさん mailto:sage [2009/01/12(月) 08:08:10 ]
- 科学計算で無理矢理JavaやC++を使う理由はない。
FORTRANでいい。
|
 |
