- - PR -
特集「私がJavaからC#に乗り換えた10の理由」について
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2003-07-08 12:18
>個人的にはC#をとっても気に入っています
>（Javaの開発経験はゼロです。だから適当なことを言っていると叱られるかもしれませんが、） まあ，Javaの猿真似言語と言われるくらいですから． Javaを知らないのならC#が素晴らしいと感じても無理もないかと思います． >C＃は言語的には全然違いますが、裏にあるphilosophyは >Rubyに一番近いんじゃないか？と思ってます。 うーん．．． たしかに，Perl+OOPと言う意味で「Perlの真似をしている」と言う意味 では似ているかもしれません．しかしOOPの有無というのは言語設計と してはかなり大きな違いだと思います．なにより矛盾なくOOPを取り込む のは簡単ではない． それに比べるとねえ． >（そういう意味で、C#の出現をもっとも脅威と感じたのは >まつもとゆきひろさんじゃないかと思うんです） まさか．およそありえないと思います． そもそも言語としての性質が違いすぎる．直接競合することは まず考えられない． | ||||||||
|
投稿日時: 2003-07-08 15:13
objectです。
コンポーネントに関する事は何も書いて無いので、「delegate」について書きます。 尾島さんを含め、Javaでも「delegate」を問題にしているようです。 Sunには、【「delegate」をサポートするかどうか】に関するレポートもあるようです。 でも、これは基本的に視点が違うと思います。 前のレスで、 Java：クラス指向 C# ：コンポーネント指向 と書きました。 【「delegate」をサポートするかどうか】という発想は、クラス指向だからだと思います。 コンポーネント指向のC#が、重要視しているのは、イベントです。 そのイベントを実装する手段として、「delegate」が導入されたという事を忘れてはいけないと思います。 C#は、イベントを必要不可欠なもと考え、そこではサポートするかどうかとういう選択肢は無い、と私は思います。 コンポーネントが最初に意識された状況は、設計時にそのオブジェクト自身に設計を支援させる、という状況だと思います。 この状況で実現目標とされたのは、「イベント」を「メソッド」にバインド出来る安全な実体です。 ※決して「イベントリスナ」等の実現手段ではありません。 C#は、実際にこの実体を「delegate」で実装し、それを「イベント」と呼称し、言語として取り込んだ、と考えるべきだと私は思います。 Java、C#それぞれのスタンスの違いを無視した、感情的で不毛な双方への非難は、意味が無いと思います。 ※これが直ちに、双方の優劣に繋がる程単純でも無いと私は思います。 ただ、忘れてならないのは、ソフト開発言語はソフト開発者の為にある、という事実だと思います。 少しでも、分かり易くソフトを記述出来る事、この事には両言語共に最大限の努力して頂きたいと私は思います。 | ||||||||
|
投稿日時: 2003-07-08 15:28
私は、(仙人ではない)一般の開発者です。仕事上、C#もJavaもそれ以外の言語も使用しています。 悪夢を統べるものさんは、JavaやOOPに精通されていて、この会議室に寄せられている多くのコメントも技術的にもいつも非常に参考にさせて頂いております。どうもありがとうございます。 でも、思ったのですが、Java(言語)はそんなに他を寄せ付けないほど完成された言語なのでしょうか？ (今朝のIT Proの広告メールでは「Javaシステムにおけるメモリーリーク、レスポンスタイムの悪化、システムダウン。こういった性能問題の解決や、Java システムを安定稼動させることの難しさにお困りではありませんか?」などと、Java システムの不安定さでメシを食っていける企業さんもいますが、今はシステムとしてのJavaはオープンシステムが故の他の要素が多いため、完全無視) Javaの教理は、他の言語を認めない一神教のようなものに感じてしまいますが、 Javaとは、神が人類のためにお与えになった唯一の救世主なのでしょうか？（あるいは、MSに属するものはすべてサタンに属するものなのでしょうか?）・・・違いますよね。 Javaも（完全ではない）人類が生み出したものですよね・・・。 できれば、C#（他の言語）のことを徹底的に貶す言い回しではなく、悪夢を統べるものさんの技術力をもってして、もっとJavaのすばらしさを伝えるような表現を使っていただけた方が、もっと多くの一般素人開発者がJavaに惹かれると感じました。Javaの福音がこれ以上広まることを望まないのでしたら、別に結構ですが。 （悪夢を統べるものさん、感情的なコメントで失礼で申し訳ありません。できることなら、お気を悪くされないでください・・・） [ メッセージ編集済み 編集者: Kuolema 編集日時 2003-07-08 19:25 ] | ||||||||
|
投稿日時: 2003-07-08 15:49
今後C#がメジャーになっていくために必要（ではないか）という観点から見た場合、
・マルチプラットフォームへの対応 ・（できれば）フリー化 の2点が大きな要素と考えます。この2点については現時点ではJavaに一日の長があるのは 事実だと思います。いや、.NETファミリーが普及するのはこれからだから、というものある かもしれませんが。 ちょっと上記と関連（？）しない内容かもしれませんが、自分は半身Macユーザーです。 MacOS X はFreeBSDベースであるのは広く知られていることですが、FreeBSDベースであるにも 関わらず、jdk1.4.1_01が装備されています。もちろんTomcat4.1.24も使えますし、PostgreSQLもMySQLも使えます。 Webデザイナーの間ではMacユーザーは少なくありません。これの意味していることは デザイナーがJSPをデザインする上で実際に動作検証（ユーザビリティなど）まで可能に している点。Webインターフェースを制作する上では案外大きなメリットかと思います。 今後のC#の発展を願って退席いたします。 | ||||||||
|
投稿日時: 2003-07-08 16:55
間違ってJavaの方に送信して(色々書いて)しまいましたが、こちらにも。
えー、私が「私がJavaからC#に乗り換えた10の理由」を最初に読んだときはまさにこのような感覚を感じたのですが。 1ページ目から3ページまで徹底的にJavaを貶めた記事は、特にC#の魅力よりも、Javaの批判と"C#を使おう"というプロパガンダとしか思えませんでした。 後に4ページ目に
と書いてますが、他の方が書いている通り、最終ページではなく最初に書いていたら変わっていたかも知れない。 ま、今にして思えば、コーディングレベルで言語の選択はプライベートはありえるとしてもビジネスとしては別ものだけど。 ＃「Spencer F. Katt」が書いたら違う風に思えたかもしれない…。 | ||||||||
|
投稿日時: 2003-07-08 17:11
こういう記事、いいと思います。
実態とかけ離れたプロパガンダや建前論が横行する昨今、こういう現実的主張は貴重だと思います。 私も会社でJavaを使っていて、ほとんど同じことを考えていました。 現実的にいえば、GCが最も頭の痛い問題ですね。実製品向けに書かれたコードでは、Javaのあまりの遅さをカバーするためにインスタンスプーリングが使われることが多く、何のために言語レベルのメモリ自動管理機能がついているのかさっぱり分からないという惨状です。 これは.netにも全く当てはまらないわけではないのでなんともいえませんが、個人的には、自動メモリ管理はVB式の参照カウントとGCの併用方式がベストではないかと思っています。 いろいろ思うところは多いのですが、とりあえず、ここの議論の過程でfinalの効果について改良されている(?)という主張がありました。これが本当なら、書法を改めないといけないので、手元のPCで簡単なテストを行なってみました。 下記の単純なメソッドをクラス外から10億回呼び出す時間を計測。 JDKのバージョンは1.3.1_02です。(ちと古いが、このあたりが現役で十分使われてます) public final void meth() { x++; } final有で8562ms、final無だと18026msかかりました。 よって、final効果は未だ有効のようです。 ただし、privateなものにfinalを付加してもタイムは一緒でした(当たり前？)。 メソッド呼び出しのコストの占める割合によって、全体に与える影響は変わってくるでしょうが、finalの効果があるか？と聞かれれば、この数字を見る限り答えはyesです。 処理系の改良云々については、製造元(=Sun)の主張を鵜呑みにするのではなく、実装されたものを動かしてから議論したほうが安全かと思います。 あの会社は時として、夢と実装仕様を混同して語るので…。それで起きたトラブルは数知れず…。 個人的にはC++派なのですが、JavaよりC#派です。というか、Java嫌い。C#にも#include欲しいです。 | ||||||||
|
投稿日時: 2003-07-08 17:37
>個人的には、自動メモリ管理はVB式の参照カウントとGCの併用方式がベスト
>ではないかと思っています。 参照カウントはGCのマーク付けアルゴリズムの一種ですよ． 「GCのマーク付けとGCの併用方式」なんてわけがわからない． おまけに参照カウントは循環参照が識別できない弱点があるので ベストとは言い難い方式です． ＃そもそもマーク付けアルゴリズムを言語やVMの仕様で規定する ＃こと自体がおかしい．Javaでもそれは規定していない． >final有で8562ms、final無だと18026msかかりました。 >よって、final効果は未だ有効のようです。 1，ベンチマークの危険性はご存知ですね． 2，finalの有無で差があるのは当然です．問題なのは「finalをつけない ことが無視できないほどのボトルネックになるのか」という点． インターフェースメソッドなども同様．インターフェースメソッドの方が そうでないメソッドより遅いのは事実．問題なのは，それが問題になるほど 遅いかという点． 3，動的な最適化も考慮していますか？ 計測時の条件を見る限り，考慮されているようには見えませんが．．． | ||||||||
|
投稿日時: 2003-07-08 17:44
そんなことより、先のインターフェイスについてご教授してほしいです。
＞悪夢を統べるものさん 結構、期待してる人、多いんじゃないかな？ ＃少なくとも、わたしはそう。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。