- - PR -
特集「私がJavaからC#に乗り換えた10の理由」について
投稿者 | 投稿内容 | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2003-07-08 17:46
>でも、思ったのですが、Java(言語)はそんなに他を寄せ付けないほど完成された
>言語なのでしょうか? いいえ.既に欠点も知られてます. ・スレッドやクローンメソッド周りの設計. ・インターフェースとクラス(もう少し統一的な扱いはできないか) ・レガシーコレクションクラス ・EmbeddedJava,PerosonalJava, 賛否両論の機能も含めればもっとあると思います. また完成されているわけではなく,常に改良が続けられています. この他にも小規模なプログラムならば,Rubyなどのスクリプト言語の方が 有利でしょうし.完全無欠で究極の言語など,当面は生まれることは ないと思います. 今回の記事の問題の一つは,こういう問題点は指摘せず,問題でない点 ばかりが問題とされていること. | ||||||||||||||||||||||||
|
投稿日時: 2003-07-08 17:52
Dandanさん、コメントありがとうございました。
申し上げたかった事に対して表現が足りず、すみませんでした。 私は、理想主義者ではなく、現実主義者なので、個人的にはC#のOOP的でないアプローチも採用する設計思想を好んでいます。すなわち、記事事態には共感を覚えている者です。 しかしながら、.NET Frameworkが他の言語を受け入れるようにJavaの言語や、設計思想(理想)を否定したくはありませんし、Javaをすばらしいとも思っています(もっとも.NET Framework自身は、言語しか受け入れてくれませんが)。 私が申し上げたかったことは、「Javaの批判と"C#を使おう"というプロパガンダ」の記事に対して、貶す言い回しのコメントでは、Javaのよさをアピールできないのではないかと感じたのです。私個人は、Javaも発展してほしいと思っていますし、C#ももっと普及してほしいと思っています(また、普及したその他の言語も否定はしたくありません)。 #ビジネス上でも、その企業にとってJ2EEを採用した方がよい場合と、.NETを採用した方がよい場合があることは言うまでもないことと思っております。 [ メッセージ編集済み 編集者: Kuolema 編集日時 2003-07-08 19:23 ] | ||||||||||||||||||||||||
|
投稿日時: 2003-07-08 18:02
他の話題に割り込むようになってしまって、ちょっと気がひけますが(^^;
マルチプラットフォーム対応、はちょっと置いといてっと。 C#をコマンドライン上からコンパイルする分にはフリーですよ。 .NET Framework SDKさえも必要ではなく、再頒布モジュール(Windows Updateで 入ってくる部分)だけで開発が可能です。 #まぁ、ドキュメント無しで開発できる人はそうはいないでしょうが(^^; フリーの開発環境としてはSharpDevelopが有名ですね。 高機能になるにつれて重くなっちゃったみたいだけど。。。 | ||||||||||||||||||||||||
|
投稿日時: 2003-07-08 18:17
小野@EAC様>
やや、これは失礼しました。またご教示ありがとうございます。 早速DLしてまず四則演算ベンチマークをやってみます。 | ||||||||||||||||||||||||
|
投稿日時: 2003-07-08 18:48
はじめまして。猪股といいます。
尾島の隣で働いています。
参考までに、オープンソースソフトウェア/自由なソフトウェア側からのアプローチを挙げておきます。 dotGNU Project Mono Project (追加:Mono Projectの日本語訳) マイクロソフト自身も、複数のプラットフォーム(Windows 2000/XP, FreeBSD 4.7, Mac OS X 10.2)で動作するC#処理系を公開しています。 シェアードソースCLI実装 (追加:MSDN online Japanの記事) このスレッドでライセンス論争をするつもりはありません、というお断りを入れた上で… 詳細はシェアードソースCLIのライセンス条項を読んでいただきたいのですが、 簡単に言うと、「教育、学術研究および個人的な実験のためであれば使ってもよい」とのことです。 とはいえ、上記のものが
ここを解決してくれるわけではないんですけれど… (ライセンス、互換性、ツールの対応など…) [ メッセージ編集済み 編集者: いのまた 編集日時 2003-07-08 19:32 ] | ||||||||||||||||||||||||
|
投稿日時: 2003-07-08 19:28
スレッドの趣旨と直接関係ない部分で恐縮なのですが、 私も気になったのでほぼ同様のテストを行ってみました。 動的な最適化を考慮に入れたいので、10億回の呼び出しをランダムな順序で、 10回連続で行ったところ、 JDK 1.3.1_05 では 初回 final: 4140 finalなし: 8547 2〜10回目平均(ほぼ同じ) final: 2890 finalなし: 8540 JDK 1.4.2 beta では 初回 final: 4156 finalなし: 4157 2〜10回目平均(ほぼ同じ) final: 3119 finalなし: 3130 となりました。(いずれも単位はミリ秒です。) ベンチマークの有効性については自分はよくわからないのですが、 少なくとも私の環境では、1.3から1.4への移行で、finalなしの 呼び出しも遜色なくなったといえるでしょう。 しかし、1.3ではfinalありの方がやはり速いらしいので、 1.3を使用する環境では ・パフォーマンスを改善しなければならない ・数千万回以上呼び出され、そのメソッドがボトルネックの原因である ・実際にfinalにするとパフォーマンス目標をクリアすることができる。 という事がわかっていたらfinalにすることも検討するとよいでしょうね。 ただ、デフォルトでfinalをつけて、無意識レベルでポリモーフィズムを 回避している人なら、やはりC#の方が合うのでしょうね。 #追記: 上記は、あくまでも私の取るに足らないベンチマークでの事例の話です。 また、ベンチマークでわかることは可能性のみであり、パフォーマンスチューニング の指標になりえるものではありません。 #下方の英-Ran様、お犬様にのレスでより適切に私の言葉足らずが補われています。 m(_ _)m #いずれにしても、パフォーマンスは問題が発生してから対応してください。 [ メッセージ編集済み 編集者: Wata 編集日時 2003-07-09 09:37 ] | ||||||||||||||||||||||||
|
投稿日時: 2003-07-08 20:03
尾島様、猪股様>
この会議室ではいつもお世話になっております。 > マイクロソフト自身も、複数のプラットフォーム(Windows 2000/XP, FreeBSD 4.7, > Mac OS X 10.2)で動作するC#処理系を公開しています。 これが私の勉強不足でしたら申し訳ありません。しかし、MSプラットフォーム以外にも 対応するムーブメントがある、という話は一般的なのでしょうか? もし、そうでなかったとしたら、これをアピールする絶好のチャンスだったのではないで しょうか? これまで、時代が変わるにつれ、様々な言語が生まれては消えています。 その時はその言語が最高と言われていたハズですが。広く普及するためには言語仕様の 良し悪しもありますが、まずこのあたりが重要ではないかと考えます。 [ メッセージ編集済み 編集者: Ken-Lab 編集日時 2003-07-08 21:11 ] | ||||||||||||||||||||||||
|
投稿日時: 2003-07-08 21:48
私には「悪夢を統べるもの」さんの具体的な意見が批判され、シンタックスシュガーすら理解しておらず、感覚に頼った意見で議論をすすめるおじまさんの文章が持ち上げられる理由がよくわからないので、後方支援させていただきます。
さて、一つのプログラムに占めるメソッド呼び出しの割合はどれくらいでしょう。プログラム中でメソッドが10億回呼ばれたとしても4秒しか実行時間が変わらないのじゃなくて? 私も、finalよりvirtualの方が優れていると思うけれど、それはパフォーマンスが理由ではなく実装すべき箇所がソースコードに明示されるからです。 今の時代、局所的な最適化が重要でないというのは常識になりつつあると思っていましたが、そうでもないのかな? だいたい、開発効率ではなく速度的なパフォーマンスを理由にJavaよりC#を選ぶ開発者なんているんですか?
「delegate」がコンポーネント指向を目指す上でどのような必然があるのかをきちんと論理的に説明してください。私が挙げた「ABOUT MICROSOFT'S "DELEGATES"」を読んでいただければ「delegateも無名Inner Classも機能は同じ」、「delegateは記述が短いがクラスの構造を壊す」、「無名Inner Classは冗長ではあるがクラスの構造を壊さないし、新しい概念を加える必要がない」ということが説明されているはずです。Microsoftがコンポーネント指向というからにはグラフィカルな開発を念頭においているのでしょうが、グラフィカルに開発するのであればdelegateだろうが無名Inner Classだろうが記述量は変わらないのではないですか。 structも同様で、パフォーマンスが問題にならないならば、機能的にクラスの下位互換でしかないstructに出番はありません。最近のJava VMは、過去の教訓を生かしてオブジェクト生成のコストは大幅に下がっている……と言う話が各所でぽつぽつと出始めています。現状はどうあれ、一年後には「オブジェクト生成のコストは高い」という話が昔話になっていたとしてもsturctが必要なのか考えてみることが必要でしょう。 私は長いことSwing(JavaのGUIコンポーネント)を使っていたことがあって、その遅さには非常に不満でした。ですが最近出たJ2SE1.4.2のSwingを久々に使ってみると、これが本当にJavaなのかというくらい実用的な速度で動いていたりして非常に驚きました(←昔、Swing使ってた人は必見です) 昔読んだアルゴリズムの本に「ハードウェアは年に2倍しか速くならないが、プログラムは実装によって一万倍速くなる」書いてあったのを思い出した次第ですが、同じように速度は言語仕様によって決まるわけではないのです。遅いといわれたLispでも今ではC言語によって書かれたものと同等の速度で動くものもあるようですし、ハードウェアが複雑になったせいで人間がアセンブラで書くよりコンパイラを使った方が高速なプログラムができるという話も聞いたことがあります。
そう言っているあなたが、Microsoftの主張は鵜呑みにするのですね。ビルゲイツの言う「Trustworthy Computing」は夢ではなく実装仕様なんですか。Javaのバグによって泣かされた開発者はいても、Microsoftのバグに泣かされた開発者はいないとでも言うのですか? 例えば、こんなのもありましたね。
別にこれをもってJavaが速いと主張したりはしませんが、ここでは「Javaが遅い」という主張がしばしばなされます。それなのに「C#(or .Net)がJavaよりも遥かに速い」ことは誰も示さないのはなぜなんでしょう。現実的主張と言うのならきちんと示してほしいところです。
たとえば、このことですね。 develeperWorks「もしも自分が王様だったら: Javaプログラム言語のスレッド化不具合への解決策提案」 http://www-6.ibm.com/jp/developerworks/java/010302/j_j-king.html とはいえ、ここで書かれていることがC#でどこまで実現されてるかを考えてみると……
この記事で一番の問題はここでしょうね。「ビルゲイツが嫌いだからWindowsが嫌い」と公言しているもんでしょう。こんな発言のどこに現実的主張があるんでしょうか。 ……と、こんな文句ばっかり言ってるからJavaコミュニティは云々と言われるのかもしれませんが [ メッセージ編集済み 編集者: 英-Ran 編集日時 2003-07-08 21:50 ] |