Java 1.4SE正式リリース 145
ストーリー by Oliver
Java-the-Bytecode 部門より
Java-the-Bytecode 部門より
ryuuriを筆頭に大勢がJava 1.4SEの正式リリースをタレコんでくれた。今回のリリースはPerl風正規表現、IPv6、XMLやJDBC 3.0、assert()、リフレクションの強化といった、「やっと」なものから痒い所に手が届くものまで、新機能が山盛り。もう混雑も山を過ぎたみたいだし、Java使いはもうダウンロードするしか。 "
Java 2 Platform/SDK,Standard Edition,Version 1.4 (スコア:2, 参考になる)
たくさんコメントがついているようなので見に来たのですが、ツリーが一つしかなく、その中では1.4の話題がまったく出ていないので、とりあえず簡単にリリースから新機能と変更点を抜粋して挙げておきます。
こんな感じでしょうか?
Javaの必要性 (スコア:1)
僕はいまいちJavaの良さが分かりません。
誰かJavaのすばらしさを語ってもらえないでしょうか。
Re:Javaの必要性 (スコア:2, 興味深い)
- C 言語ライク。少ない費用でCプログラマを開発に投入できる。
- 参照(not ポインタ)とGC。これでメモリ管理のバグの数をかなり減らせる。
- 移植性。サーバOSのの変更も自由にできる。PC で開発、WS で稼動なんてのもらくちん。
- ライブラリ。標準で有用なライブラリがいくつも付いてくる。
Java を利用する企業の利点としては、
- ライセンス。タダで使っても構わない。
- 保証。企業がサポートしていないものを使う気にはならない。-
趣味のプログラマは好まないかもしれないけど、
職業的プログラマなら 利点はたくさんあると思う。
いや、俺も Java そんなに好きじゃないけどね。
#最近はスクリプト言語の方が好きだし。
# mishimaは本田透先生を熱烈に応援しています
Webアプリケーションではどう? (スコア:2, 参考になる)
Webアプリケーションの開発では Java は使えると思います。
実際の開発はちょっとめんどい部分ありますけど、
Servlet + JSP で MVC のフレームワークを使うと
あとあとラクです。(規模が大きくなればなるほどそう思います。)
DBとの連携もいろいろできるし。
あと、XMLの扱いがラク。まぁこれはライブラリィつうか
いろんなクラスが揃ってるからですけど。
もちろんPerl や php なんかの方がいい場面もありますが。
不満点がひとつ。SDKがだんだんでかくなる!
javax.* はオプションでいいんじゃないかと思います。
コアSDKに含めるものが多すぎ。
Remember, the good things in life are :
small, simple, easy, and elegant. - a.v.h.
Re:Webアプリケーションではどう? (スコア:1)
>javax.* はオプションでいいんじゃないかと思います。
>コアSDKに含めるものが多すぎ。
設計ミスってる部分とかもあるように感じます。
なんでプリミティブ型なんて存在して、ラッパーで対応させてるのかとか(全部オブジェクトでいいじゃん)、java.ioってやたらとごちゃついてるとか。
Re:Webアプリケーションではどう? (スコア:1)
文字コード周りではトラブりますけど。
#英語圏だと何の苦労もないんだろうなあ、ここらへん
DBアクセスの必要なWEBアプリは、今までOracleのPL/SQLでごりごり
書いていたんですけど、過去のコードをメンテしようとするともう気分が
悪くなりますね。
実行速度については、どうせ通信とOracleのオーバーヘッドの方が
大きいので気になりません。(適切なbeanを作っておけばですけど)
Re:Javaの必要性 (スコア:1)
ほら、少しでも楽しまないと。
Re:Javaの必要性 (スコア:1)
そうそう。仕事で使う言語としては、不快度が比較的低いんじゃないでしょうか。
# でもXMLまわりが含まれたことで、今までXercesとか使ってた人はいろいろ悩むかも(俺だけ?)
Re:Javaのすばらしさ (スコア:1, 余計なもの)
// 本題から外れててスマソ.
Re:Javaのすばらしさ (スコア:1)
JavaHouse の ML 読んでると、Java のタコいところがいっぱい見えてくる。
例えば、プロパティの初期化とコンストラクタの呼ばれる順番が
すげぇ直感的ではないとか…(ポインタを探そうと思ったけど見つからんわ)
Java について語ろうYO!
# mishimaは本田透先生を熱烈に応援しています
Re:Javaの必要性 (スコア:1)
Java Applet のことだったり、 JavaScript のことだったりする
ことがあるので、いっかい問い詰めてみたほうがいいです。
Re:Javaの必要性 (スコア:3, 参考になる)
"私は 何々の 言語が素晴しいと思っているんだけど、
それに比べて Java はあまり素晴しいと思えません。
利点教えて!"
っていうのでないと、あまり効果的な意見が述べられないかと
思います。
私は、あらゆる点で Ruby がいちばん好きな言語ですが、
その次くらいに Java が来ます。
私に関しては、ですが...
[よいところ]
* GUI がクラスライブラリとして標準化されているので、
GUI を作るとき、いろいろ悩むことがない。
(C++ だと、VCL か、MFC か、GTK か Qt か... って
悩むし、採用したライブラリが嫌いな人はソースを
見てくれないだろう...)
* やっぱしクロスプラットフォームの利点は大きい。
Windows を強要されなくて済む。
Linux のみを使っていても誰からも怒られない。
環境による差をあまり意識せずに開発できる。
* オブジェクト指向プログラミングしたい場合は、
C や C++ , Perl (, VB) でやった場合と比べると、
上手に書ける。
( STL を除けば、Java と比べて C++ の利点があまり無い )
[嫌いなところ]
* メモリ食うし、やっぱ起動が遅い。ある程度のマシンスペックは必要
* GUI を作成したとき、デフォルトではフォントの見栄えが悪い。
(しょぼい理由だが、実はこれが一番ヤなところでもある。
私は結構見栄えにこだわる)
挙げればキリがないのでこの辺で。
私としては、Java で仕事ができる環境にあったことがないので、
Java の利点が云々という以前に、むしろ Java で
飯が食えるというのは羨ましい話です。
開発環境を強要されて仕事をしなければならないという現状
においては、Java は比較的うれしい環境だと思います。
実際のところ私は 趣味的に使ったことしかありません。
サーバーサイドの利用 -> Perl 等の方がサクサク作れる
GUI アプリ -> Delphi などの方が...
っていう風に感じていますが、仕事で使われている方、
どのような用途で使用されてますか?
私は
* Java がどのような仕事で利用されており
* 他の言語で作成した場合と比べて利点があったか
というのが知りたいです。
Re:Javaの必要性 (スコア:2, 参考になる)
やっぱサーバーサイドです。Servletとして使います。あと、ソケット開いて
メッセージを処理なんてのも一つ作りました。
>* 他の言語で作成した場合と比べて利点があったか
phpやASPも使ったことがあったけど、HTML埋め込みってのはちとつらいです。
ややこしい画面表示になるとわけわかんなくなる(^^;;;;;
java(というかJ2EE)ならTAGライブラリを使ってかなりHTMLとjavaのコードを
分けられるのでその点楽でしたよ。
HTML埋め込みって (スコア:1)
PHPでもわけわかるように書こうとすると、MVCのようにロジックとビューが分離しちゃいますね。
HTML埋め込みは、本当に「埋め込み」程度の分量しかないときには有効だけど、がつがつと動的生成しなきゃいけないときにはむしろ邪魔、でしょう。
Re:HTML埋め込みって (スコア:1)
すらど宴会SNS開放中 [e-meet.jp]
Re:Javaの必要性 (スコア:1)
ぼくは、職業的なプログラミングにおいて、プログラムを書くときに「どの言語を使うといいか」という点を考えて言語を選択するということがどの程度行われているかのほうが知りたいです。
正直、利点があるかなんて考えてから Java を選択している人はどのくらいいるのかが疑問です。いっぱいいるのかなあ。
// この前も、小さなプログラムですが、何も考えずに C++ で書き始めてから後悔したばかり。
鵜呑みにしてみる?
Re:Javaの必要性 (スコア:2, 興味深い)
"どの言語を使ったらよいか" と考えるまえに、
"周囲の人間がどの言語を使う能力があるか" という
制約の方が極めて大きかったので、殆ど選択肢は皆無でした。
たぶん /.J を読んでおられる方は、複数の言語を使い回される
方が少くないと思いますが、実際の仕事の現場だと、
"この人は、これこれの言語を知っているから、この仕事
を与えよう" みたいな配分が行われていることが
結構あるのではないでしょうか?
私は、"本当に必要な理由から言語を制限" される分には仕方が
ないと思ったりもしましたが、"他の人が分からないから" という
理由で言語を強要されるのは非常に嫌でした。
知り合いの人から聞いた話ですが、C++ で STL を使ったプログラムを
書いたら、"他の人が分からないから" という理由で、書き直しを
迫られたことがあるそうです。
私に関しても, "オブジェクト指向でプログラムを作成" したときに、
"VB 使っている人が混乱して分からないから" という理由で、
ソースが全部破棄されたことがありました。
"いまさら構造化プログラミングですか..." とがっくりでしたが。
(まぁ、あのときは、まだ初心者で、私の書いた部分に
悪い点もいっぱいあったから仕方ない点もあるんですけど)
私は、最低限
* オブジェクト指向が分かっていない人には C++ は絶対使ってほしくない。
* ポインタが理解できていない人は、C 言語は使ってほしくない。
って思っています。
(保守されられて、泣きたくなったことがあります。)
そういう現状では、Java は強要されても一番うれしい環境ではないかと。
クラスとして分割して切り分ければ、悪いパーツだけ入れ変えることが
できるし。
悲しい現状でした。
Re:Javaの必要性 (スコア:1)
しかし、そーゆー事をする時は、事前に周囲にネゴをとっておかないと難しいでしょう。私が STLを導入した時は、事前に関係者に説明し、世間の実績や、STLによる生産性向上具合を説いて、了承を得てからやりましたよ。
オブジェクト指向の導入もしかり。
# 説得時に、若干、ばら色の脚色をした事は否定はしませんが (藁
もっとも、いつも了承される状況には無いし、職業上の立場もありますから、時には我慢をし機を見て行動しないと、チャンスを失います。
それって要するにCOBOL? (スコア:1)
そーゆーことなら、「仕事で使う」という条件付きならJavaも好きになれるかな? 私がCOBOL好きなのも、「仕事で使う」という条件付きだし。
Re:Javaの必要性 (スコア:1)
どの言語/プラットフォームを使うかなんて、プロジェクトの命運を左右しかねない、非常に重要な判断事項です。ただし、純粋に言語設計がすぐれているから、その言語を使う。という判断は無いです。
製品の特性、顧客の要望、プラットフォーム、手持ちの
リソース(人材,機材)、納期、保守、製品の使われる期間、
移植、再利用性、情報量、趣味
等の条件を考慮した総合評価です。
そうそう、"流行"も重要な要素です。不幸にして顧客がそれを望んでしまう時は... まぁ、自分が流行熱にかかって、どさくさで新言語って時も、絶対無いとは言い切れないが、何かあった時の責任は自分なので決めるときはドキドキするyo。(それがまたいい(爆
今まで、製品としては C, C++, Perl, JavaScript, Javaを使って来ましたが、Javaに対する印象は、
「とっつきにくくヘビーだが、信頼出来る頼もしい奴。開発が一旦軌道に乗れば生産性も上がり易い」
ですね。他人に依頼する時は CよりもJavaの方が安心出来るかな。
(でも本音は VB→Javaと移って来たプログラマは勘弁願いたい)
# ちなみに趣味のプログラムや、軽いツールは最近はRuby。
Re:Javaの必要性 (スコア:2, 参考になる)
JITの技術がありますが本質的な解決策では無いと思います。
しかもテキスト処理なんかはJITを使ってもAwkよりもPerlよりも遅い。
次に移植性です。
Write Once Run Anywareとか言っていますがはっきり言って実現されて無いと思います。
移植性 + 速度
で考えるとCの方が上だと思っています。
GCを利点として挙げる人がいますが、それも僕はどうかと思っています。
GCがあるためにむちゃくちゃなプログラムでもある程度動いてしまいます。
1時間ぐらいだったら動くけど長時間動かしているとVMが落ちることがありますし、その時のバグを見つけるのが非常に大変です。
最後にIDEです。
デバッグが難しいのにろくなIDEが無いために開発が非常に面倒です。
後は思想的な話ですが、そもそもJavaが出てきた時のライセンスが僕は嫌いでした。
「全ての環境で同じプログラムが動く。だからうちにお金を払ってね。」
って思いっきり某社の戦略ですよね。
今はライセンスが変わりましたが、それは単にJavaが最初のライセンスではやらなかったから変えただけであって、根本的な思想は某社と大して変わらない気がします。
dan kamiyubiさんの意見をお聞かせ下さい。
長文失礼しました。
Re:Javaの必要性 (スコア:3, 参考になる)
方の話をすると、
まず実行速度ですが、私の作ってるようなものだと他の要素、通信やデータベー
スが遅いので、今Javaな部分をCで書いたところで数%も速くならない、むしろ
開発速度が重要で、そういう意味では perl,python,ruby などの方が向いてる
と思います。
遅けりゃ負荷分散したらいいやん、ということで最近ではPCクラスタで分散オ
ブジェクトとかすることが多いので、言語標準のライブラリで分散オブジェク
トがしやすいのもありがたいです。
移植性は、Cでは移植性のないコードも書き易いのでその点さすがにC以外の方
がいいのでは。私の知るヘボCプログラマはすぐにリトルエンディアンを前提
にコードを書くのでSPARCにもってくとき苦労しました。
GCだめだからJavaだめってのは何とも…。他のオブジェクトを明示的に解放し
ない言語もだめなんでしょうか。
IDEは確かにあったほうが参入障壁は低いですね。初心者に勧め易いというか。
私のほうでは必要ないので、無いことがデメリットにはなりません。Junitを
使い出してからはいわゆるIDEでデバッグはしたことないです。バグがあった
らまず再現性を出すテストを書きます。Javaは例外時スタックトレースが出る
のでそれで分かることも多いです。あと再現性のだしづらいバグではIDE のあ
り無しはデバグの容易さとは関係ありません。GUIだと例えばマウスを押して
から離すまでの間動くコードのデバグなどはIDEがあっても楽にはなりません。
思想的な話は良く分からないのでパス。まあ、まっとうなソフトウェア技術者
ならC/C++、perl、python、java、lisp くらいは書けて当然なので「要は適材
的所だ」で済むのではないでしょうか。
Re:Javaの必要性 (スコア:1)
「Javaが適材適所の言語である」というのは納得してます。
でも、僕が良く分からないのは適材適所で無いような気がする分野にまでJavaが持ち込まれているような気がします。
例えばReal Time Javaなんていうのは本当に必要なのでしょうか。
dan kamiyubiさんはおそらくJava信者では無いと思いますが、Java信者の人はよく「Java万能」と考えていることがあります。
dan kamiyubiさんの目からみてJavaの可能性はどの程度あると思いますか?
Re:Javaの必要性 (スコア:2, 興味深い)
別に擁護するほどの義理も思い入れもないんだけど。
必要な時にプロセスとして起動するような用途には当然向かないですよ? PerlはともかくAWKを並べてるところを見ると、「テキスト処理」ってUNIXのフィルタプログラム的な使い方を想定してるんじゃないでしょうか?
Javaのソフトウェアをまともに使おうと思ったら、JavaVMは基本的に立ち上げっぱなし、その中でサービスを回して行くような方法しか今のところはないでしょう。それが、いわゆるJ2EEの考え方(のごく一面)ですね。
だからこそ、JavaOSなんて考え方があったんでしょう。要は適材適所ってこと。
Re:Javaの必要性 (スコア:2, 参考になる)
それは実感しますね。
jvmの起動はやっぱり遅い。一方でいったん上がれば遅さが気になることは案外(?)多くない。
複数の関連ある処理(の単位:OOPとそれ以外を比較するときにはこの辺が曖昧な言い方になっちゃいますが)を
繋ぎあわせて使うという状況においては、unixのプロセスモデルより、java(に限らないけど)の
Object単位のモデルのほうが、メリットが多いことが多いです。プロセスだと処理単位間の「壁」が高すぎ。
それがまさに、CGIに対するservlet、makeに対するant、のメリットになっているという触れ込み(^^;。
オフトピだけどant。make時に必要な複数の処理を同一プロセス(^^;でやってくれるのは
たしかに魅力的なんだけど、もう一歩欲しいです。
もしコンパイルが「終わって」も尚プロセスが残っていてくれたら、そして
次のコンパイルにそれを使い回せたら、きっと更に速くなるだろうに、と。
Re:Javaの必要性 (スコア:1)
AWK、Perlを例に挙げたのはUNIXのフィルタプログラム的な使い方を想定してるわけではなく、とにかく遅いって言いたかっただけです。
僕自身AwkやPerlよりも遅いと知ったときに非常に驚いたもので。
「ある特定の用途にはJavaが非常に有用だ」
というのは分かります。
ただ、言語として総合的な観点から見た場合に魅力的な言語だと僕は思えません。
しかし、Java信者ってすごく熱烈的ですよね?
いったいどこに魅力を感じるのかというのが僕にとって興味あることなのです。
Re:Javaの必要性 (スコア:1)
"あーんなに遅いのに、みんな平気で使っているんだろうか?"
って Java を使うときはいつも思っていたのですが、
やっぱしそのように思っている同士がいたということで。
Java の情報って、"けっこう速いですよ、いいですよ"
って思わせる情報ばっかりが見つかって,
"Java ダメじゃん.." って情報はあまり書いている人が
多くないんですよね。
欠点を述べるのって、結構重要だと思うのですよ。
だって、どのような時に Java を使えばいいかという
判断材料としては非常に有効ですから。
いろいろ勉強になりました。
Re:Javaの必要性 (スコア:1)
もちろん実行系の制約ってのは、Javaの思想に起因してるのだろうけど、それは言語としての評価とはちょっと違うように思います。
確かに、環境(言語と実行系を両方含めた話)としてのJavaは、あれこれ不満が多いですけど、ね。
Re:Javaの必要性 (スコア:2, 興味深い)
不要なオブジェクトへの活きた参照をいつまでもかかえてしまうようなコーディングをしてしまうと,長時間運用後にVMが落ちることがあります.確かに見つけにくいバグではありますが,GCがない場合のメモリリークはそれ以上に見つけにくいバグですし,何よりも開放してしまったメモリ領域を触る危険性がない方が安心して使えるのではないでしょうか.
Re:Javaの必要性 (スコア:1)
それともぼくが用語の定義を間違えているのかな。このあたりの概念、感覚的にしか把握していません。
Perl より遅くなる理由はない、というのは理解できますが。
// ただ、 Perl と実行速度を比較されているのは Java がなんか気の毒。
鵜呑みにしてみる?
ポインタ(Re:Javaの必要性) (スコア:1)
// なお、ぼくは C/C++ を学んだ後でしか Java や Visual Basic を理解できませんでした。
同様に、Cのポインタをアドレスとはまったく別に理解している人がいたら、そっちのほうがすごいと思いますが、いないだろうなあ……。
// ぼくはアセンブリ言語を学んだ後でしか C を理解できませんでした。これはある面恥ずかしいかも。
なお、ぼくはプログラマではありません。
鵜呑みにしてみる?
Re:ポインタ(Re:Javaの必要性) (スコア:1)
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:Javaの必要性 (スコア:2, 参考になる)
> GCがあるためにむちゃくちゃなプログラムでもある程度動いてしまいます。
> 1時間ぐらいだったら動くけど長時間動かしているとVMが落ちることがありますし、その時のバグを見つけるのが非常に大変です。
C だって「解放忘れ」なら同じ現象が起こるでしょー。
Java は free を呼ぶ替わりに使わなくなったポインタに逐一 null を入れろ、ってだけ。
むしろ、C では使われていないポインタに NULL 以外の値が
入っていることがあって、そっちの方が危ないと思うのだがどうか。
#ま、C だって boehm GC みたいなのがあるけどね。
# mishimaは本田透先生を熱烈に応援しています
Re:Javaの必要性 (スコア:2, 参考になる)
Cで動的に確保されたメモリブロックは、明示的に解放しない限り、(少なくとも)そのプロセスの生存中は回収されないのに対して、Javaの場合は、他から参照されなくなったオブジェクトは、ガベージコレクタによって自動的に回収されます。(そもそも、解放するという操作自体がない)
また、 これも、ガベージコレクタがオブジェクトを回収する際の「ヒント」を与えるために使われるテクニックであって、必ずしなければならない、というものではありません。(スコープを外れ、どこからも参照されていなければ、回収される)
# 「ポインタ」という用語も不適切かと。
(未確認ですが、ガベージコレクタの性能の向上で、そういったテクニックをする必要もなくなってきた、というような話もあるらしいです)
Re:Javaの必要性 (スコア:1)
という事でしょうか。
サーバー側のJavaが花開いたのは、バックエンドがころころ
変わるのに対応出来る、という事なのでは。
-----------------
#そんなワタシはOS/2ユーザー:-)
どの機能についていっています? (スコア:1)
これってどの機能のことを指していますか?
VC6.0を日常業務に使っていますけど、VC がメモリの解放し忘れ
を指摘してくれたことなど皆無なのですけど、、、
あとデバッガがメモリリークを指摘する機能は 設計がよくでき
ていてちゃんとコーディングされたプログラムに対して行う場合は
有効だけど、いい加減な設計のプログラムに対しては無力だと
思います。
#「ほとんどメモリは使い捨て」の前提で書かれた20万行ぐらいの
#プログラムを NuMega の BoundsChecker に掛けたら数千箇所も
#問題を指摘されてことがある、、、
コンタミは発見の母
BoundsCheckerは、Visual C++とは別製品だよ (スコア:2, 参考になる)
BoundsCheckerは、元々米国のNumega社が開発し、米国Compuware社に買収されて、現在は「Compuware社のNumega製品」ということで販売されています。
私の知る限りでは、M$社にぴったりくっついていて、VC++などとの相性というか、一部のように機能する、ということを売りにしていますが、完全な別会社の別製品です!。
ご参考までに日本コンピュウェアの該当サイトをお知らせしておきます。
ここ [numegajapan.com]です。
この会社の営業やってる知り合いに教えてやろうかと思っちまったい!
Re:Javaの必要性 (スコア:1)
前者だったら、ワタシはむしろプログラムする人がタコい気がしますし、後者だったらこれはチューリング賞クラスの偉大な機能な気がしますが、どっちなのでしょうか?
-----------------
#そんなワタシはOS/2ユーザー:-)
GCの必要性 (スコア:2, 参考になる)
C++ でマルチスレッドプログラムを書く時のメモリ管理の難しさといったら。まあ,気にしなくても動きますけど(皮肉なことに)。
Re:GCの必要性 (スコア:1)
>テーションを防ぐためのものと考えれば,その恩恵は計り知れないと思います。
え?
http://www.is.s.u-tokyo.ac.jp/~vu/jugyo/processor/process/soft/compilerresume/gc/gc.html
>Copying GCの興味深い性質は、コピーするときにオブジェクトの空きをつめるため、fragmentationが発生しないということである。
によると、フラグメンテーションを無くす機能(つーか嬉しい副作用?)を期待できるかどうかは
GCのアルゴリズム次第であって、GC一般の性質ではない、と読めますけど?
それとも、その副作用のあるGCしか使う予定が無い、言い換えれば
使おうとしている処理系のGCがお望みのアルゴリズムであることが既に判っている、
という状況なのでしょうか?
そりゃそうと、メモリリークが無くなるってのについては、有り難いと思いますよ。
1:unixプロセスモデル配下の短寿命プロセスならば、最悪でも「間もなく」OSがメモリを回収してくれる
ので有り難味は少ないかもだが、そうでないならそれ以外の管理が必要になる。
2:開放タイミングを決定するのが結構面倒なプログラミング形態も、ある。
ので、あーゆーものは、(プログラマの技量次第というよりも(笑))状況次第で、凄く欲しくなると思うんですが。
Re:Javaの必要性 (スコア:1)
>Write Once Run Anywareとか言っていますがはっきり言って実現されて無いと思います。
それはおっしゃる通りです。おれもなんだかんだ言って結局は、
Windowsクライアントでソース書く->Unixのサーバー上にftpしてコンパイル
なんてしたましたし(笑)今はサーバーもクライアントもlinuxだからその点楽。
>移植性 + 速度
>で考えるとCの方が上だと思っています。
write once....は「コンパイル済みのバイナリコードがそのまま移植できる」ということだと思うのだけど。Cの移植性(ソースもってってコンパイルすればOK)とは別の話になると思いますが。
ソースの移植性についても、#ifdef WIN32みたいなマネをする箇所がjavaならかなり減るのでは?、特にGUIについては。
というか、javaにマクロは無いが<-おれにとってはこれがjavaの嫌なとこです(笑)
それに、たとえば顧客にUNIX上で動くPGを納品するときに、ソースに#ifdef WIN32とか書いてあったらマズイ(笑)
速度に関しては、たしかに遅いですね。GUIのアプリをまともに作る気分にはなれない。
>最後にIDEです。
>デバッグが難しいのにろくなIDEが無いために開発が非常に面倒です。
xemacs + javac + jdbで開発してます(笑)
#そいえばCもdbxでやってたな
それを言うなら (スコア:1)
ブライド、というだけで終わってしまうかもしれないけど。(笑)
ふりまわされるほうは、たまらん・・・・・。
Re:それを言うなら (スコア:1, すばらしい洞察)
対抗したわけではなくて、純粋に「欲しかった」んだと思う。 振られたからつくらざるを得なかったってところかな。 もちろん振られた原因の多数は MS にあるわけだけど。 あの Java に機能追加した部分とかって、嬉々としながら やったんだろうなぁってのが、目にうかびますよ(苦笑)
つまるところ、Java の必要性 = C# の必要性 なのです。
ふりまわされるほうはたまらんってのは同意(苦笑)
Re:それを言うなら (スコア:1)
OSを含めた実装に問題があるだけで、古臭い部分もあるかもしれないけど、VBってそれほど悪くはないと思ふ。
まあ、その古臭い部分を改装したものが、VB.NET なんだろうけど。
そのおかげで、全く別物になってしまったという話もあるが。(苦笑)
Re:それを言うなら (スコア:1)
(VBの)SPのバージョンが異なるVB製ソフトの同居は出来ないっすよ。
まぁ、たしかにGUIのwinアプリを作る分にはjavaよりVBのほうが上だと思うけど。
Re:それを言うなら (スコア:1)
とーってもじゃないけど『どのWindowsでも…』とは言えないですよ。
でも仕事のしがらみでVBから完全に逃れきることも出来ないワタクシ…。
本当に”どのWindowsでも動くVB”が心底欲しいです(涙)。
VB色々 (スコア:1)
MSが、もっとしっかり管理さえしていれば、大した問題は発生してないはずなんだけどね。
横槍を入れる会社もないことですし。(笑)
Re:それを言うなら (スコア:1)
Re:Javaの必要性 (スコア:4, 参考になる)
比較が不毛なはずはないですね。
それぞれの言語に「違い」が有るのは(違う言語であるからには同語反復なみに)自明なので、
それを比較しないってのは全く意味をなさない行動です。
さもないと、どんな言語でも「同じであり、状況などによる使い分けは全く不要である」などという
明らかに現実に即さない結論が出てしまう(^^;
問題は、区別することではなく、差別することですね。
言語差別(^^;とでも呼ぶべき状態が、ご懸念の「不毛」な状態の正体かと思います。
友人によれば、差別とは、区別「しない」ことなんだそうです。
というか、正しい区別ポイントを見失って(故意か偶然か技量不足かはさておき)いる状態。
「嘘の相違点」に注目している状態。
だから的外れなことばかり言って禍根を作る。
的外れでなければ問題はないわけです。
言語の比較論 (スコア:2, 参考になる)
○○という言語はAという長所があり、Bという短所がある。
よって、Cという用途には向くが、Dという用途には向かない(と思う)。
私はEという特徴が好きでFという特徴は嫌いである。
よって私は○○は{好き|嫌い}である。
とかいった要素を全部漏らさず書かないと、宗教論(俺が好きなものは俺には いいものだ)になってしまうんですよね。宗教論になってしまうともう不毛。
しかし、実際に、書くべき要素を誤解無く読者に伝えられるように書くのはとて も大変なので、宗教論になってしまう確率は結構高いので、言語の比較論が不 毛なものになりがち、というのには賛成。