- PR -

特集「私がJavaからC#に乗り換えた10の理由」について

投稿者投稿内容
いまい
会議室デビュー日: 2002/07/02
投稿数: 13
投稿日時: 2003-07-04 19:26
私はずっとJavaを使ってますが、これをみてC#がうらやましくなりました。
J2SE1.5(Tiger)では、メタデータやオートボクシング、printfが使えるようになるので、ある程度はJavaでも可能になります。

それでも、オペレータオーバーロードやプロパティはうらやましいです。
コード:
foo.setB(foo.getA() + foo.getC());


みたいなコードはあんまり書きたくないですよね。
makura
ベテラン
会議室デビュー日: 2002/11/27
投稿数: 90
投稿日時: 2003-07-04 21:11
makuraです。

たしかにC#はJavaとは少し違った考え方が取り入れられていて、便利ですよね。

でも全面的にC#に乗り換えられるかというと、全面的に乗り換えたらMS製品以外扱えなくなってしまうので・・・
相互補完的に作用してくれればいいですね。

いまは両方使ってます。C#のよい点がJavaに取り込まれたとしても、やはり両方使い続けると思います。
記法が酷似した言語なので気をつけないといけないですが。

ただ、ユニシスの方が仰るとやはり


[ メッセージ編集済み 編集者: makura 編集日時 2003-07-05 00:56 ]
未記入
ぬし
会議室デビュー日: 2002/03/28
投稿数: 255
投稿日時: 2003-07-04 21:20
言語の好き嫌いは勝手ですがね,いくらなんでもjavaに関する
認識に間違いが多すぎると思います.まるでJavaのド素人が,
自分の思い込みだけで判断しているようにさえ思える.

>C#にはJavaにはない文法やJavaの常識では理解できない文法が多数
>存在するのだ。
それは整合性,一貫性がないということで,お世辞にも誉められた
ものではない.

>Javaプログラマは、生成と破棄のオーバーヘッドを避けるためにインスタン
>スを使い回したりインスタンスの粒度を大きくしたりすることになる。
いいえ.

メモリ割り当て,及びGC自体の負荷はさほど大きくなく,実際に
問題となることはまずありません.問題となるのはよほど頻繁に
大量のインスタンスを生成/消滅しつづけた場合くらいです.

>生成と破棄のオーバーヘッドを避ける抜本的な解決は、生成と破棄の
>オーバーヘッドをなくしてしまうことなのだ。
それは要するにC++と同様にメモリリークの問題を復活させる
ということに他ならない.

そうすると,
「ソース・コードの可読性が落ち、バグの発生率が上昇し、プロジェ
クトが失敗する。嘆かわしい話だ。」
ということになります.C++を使っていてメモリリークに泣いている
人がどれほどいることか.これは特に長期間ノンストップで動き
続ける高信頼性分野では極めて重要です.

>インスタンスの生成と破棄のオーバーヘッドを回避
>する根本的な手段は新たな値型を定義可能にすることだと分かる。
うーん.これについては推測も入りますが,

一部のインスタンスをスタックに入れることは可能でしょうが,
あまり大量のインスタンスを入れることは無理があります.
最初から巨大なスタックを用意するにせよ,動的に確保するに
せよ,オーバーヘッドがなくなるわけじゃない.

また生成/消滅のパターンがかなり限定されるため,利用できるのは
オブジェクト指向らしくないプログラムに限られるのでは.

ちなみに,インスタンスの生成のオーバーヘッドのいくらかは,
インスタンス初期化(コンストラクタ等)によるもので,これは
スタックを利用しても変わりません.

>Javaでのコンポジションの単位はインターフェイス(interface)だが、
別にコンポジションとインターフェースはほとんど関係がないと
思いますけどね.

>インターフェイスは詰まるところメソッド宣言の集合で、
インターフェースのことを理解していない.
このため,おそらく設計に利用できていないでしょう.

>例えば開発環境に応用するような場合にはメソッドだけでは不十分である。
これはどういう意味でしょう.
一般には不可能性の証明は不可能に近いものですが,それにしても
何の理由もなしに結論に飛びつくのはおかしいのでは.

>新たなメタ・データが必要になるたびに文法を変更するわけには
>いかないので、
確かにそういう問題もあります.ただし,ここで言う「メタデータ」を
表すためにインターフェースを使うのは割と普通のことです.

なお,シリアライズ可能なクラスにするためには,メタデータの追加以上
に設計やセマンティクス的な変更の方が重要です.「シリアライズが不可能
なクラス」にメタデータだけを後付けしても,「シリアライズ可能なクラス」
に変化するわけではありません.本質的にはバグが発生します.

>スレッド関係のバグはデバッグが大変なのだ。
たしかにこれは事実です.

ですが,それはデバッガが当てにならないこと,再現性の低いタイミング
バグが発生すること,特定環境でしか発生しないバグがあることなどによるも
ので,コード量とはさほど関係ありません.
#さらにポインタのある言語だと,スレッドを跨ったポインタバグが
#発生し,死ぬほど苦労する羽目になる.

なお,Javaのスレッド周りの設計は必ずしも優れたものではなく,
既に問題が指摘されています.その点に触れなかったのは,無知
ゆえでしょう.
#他にも幾つか設計上,あまり良くない部分はいくつか指摘されている.

また,マルチスレッド周りは近い将来に大幅に強化される話が出ています.

>この結果どうなるかといえば、“実行時”に型の不整合で失敗する
>プログラムが出来上がってしまうのである。
それは設計やセマンティクスに無理がある以上,あたりまえのことでは?

>閑話休題。そもそもインターフェイスは型に基づく安全な
>プログラミングをするためのものである。
まず,違うでしょう.

少なくともインターフェースの「目的」はそれではない.

>「インターフェイス・メソッドの明示的な実装」
名前こそインターフェースだが,実装がある以上既にインター
フェースではない.それに抽象クラスとの違いは一体?

> 優秀なJavaプログラマが書いたソース・コードを見ると、やたらと
>「final」が目に付く。(中略)ポリモルフィズムが不要な部分では、
>finalを指定した方が実行効率を向上させられるのだ。
これは大嘘です.

たしかにJavaプログラマーも必要があればfinalを使いますが,それは
継承やオーバーライドを禁止するためです.実行速度についてはほとんど
影響ありません.これはそれこそJDK1.0とかの大昔の話か,或いは
その後のJava技術の進歩を知らない素人かですね.

>C#のデフォルトは「ポリモルフィズムなし」であり、
.....自慢にならない.
C++と同じでデフォルトがOOPでない「自称OOP言語」というだけのこと.

>ソース・コードの保守性が落ちてしまうのである。(中略)
>C#には私が願ってやまなかった条件コンパイルがある。
「#if」等の条件コンパイル(或いはプリプロセッサ)は
「ソース・コードの保守性が落ちてしまう」
という致命的な弱点があります.

上手く使えば便利なことは分かってましたが,乱用されると極めて
危険であるためにJavaでは外されたと考えられています.なお
Java言語用のプリプロセッサも既にあります.

>しかし、いくらJavaの統合開発環境が高機能であっても、やはりVisual
>Studio .NETの方が便利だと考える。
まあこれについては好みですのでお好きなように.
私はVisualStudioが使いやすいとは夢にも思いませんが,
それは私の個人的意見にすぎません.

> 正確には「一部のJavaコミュニティの存在が嫌になった」である。
そりゃあ,これだけメジャーになれば,いろいろな組織があるでしょう.
中には気に入らない組織があっても驚くに値しない.

C#がマイナーなうちはいいですが,万が一メジャーになればきっと
「一部のC#コミュニティの存在が嫌になった」
ということになるんでしょうね.

>C#でJavaと同程度にきれいにオブジェクト指向を採用したコードを作れる。
C++でも同じことが言われていましたね.でも,或いはだからこそ
C++は失敗した.理論上「作れる」ということは,全てのプログラマー
が本当に作れるということを意味しない.

>C#ではオブジェクト指向以外の方式も積極的に採用しているので、相対的
>にオブジェクト指向の地位が下がっているといいたいのである。
というより「JavaとC++を足して2で割った」と言った方が
わかり易いのでは.その結果,C++の悪いところを受け継いで
しまったわけです.
いまい
会議室デビュー日: 2002/07/02
投稿数: 13
投稿日時: 2003-07-04 23:37
引用:

悪夢を統べるものさんの書き込み (2003-07-04 21:20) より:
>閑話休題。そもそもインターフェイスは型に基づく安全な
>プログラミングをするためのものである。
まず,違うでしょう.

少なくともインターフェースの「目的」はそれではない.


わたしもインターフェイスって「型に基づく安全なプログラミング」のためだと思ってた。

後学のために、悪夢を統べるものさんの考えるインターフェイスを教えて頂けませんか?
英-Ran
ベテラン
会議室デビュー日: 2002/06/12
投稿数: 55
投稿日時: 2003-07-04 23:47
記事のレベルの低さに関しては、他の方が指摘してくださると思うので、記事への反論になりそうなドキュメントをば。

IBM developerworks 「Javaの理論と実践: パフォーマンスの都市伝説」
http://www-6.ibm.com/jp/developerworks/java/030627/j_j-jtp04223.html

java.sun.com 「ABOUT MICROSOFT'S "DELEGATES"」
http://java.sun.com/docs/white/delegates.html日本語訳)←手前味噌ですが

USERS GROUPのC#メーリングリストと比較すると筆者はC#の良さに関しても正しく認識できていないような気がします(すみません。現在、USERS GROUPのページがメンテナンス中らしく、ポインタを示せません)

[QUOTE]Javaのマスコットである“Duke”がゴーゴー・ダンスを踊っちゃうくらいにJavaな日々を送っていた。[QUOTE]

結局、筆者はJavaに踊らされてただけで、何も習得できなかったようで。

[ メッセージ編集済み 編集者: 英-Ran 編集日時 2003-07-04 23:48 ]
Kissinger
ぬし
会議室デビュー日: 2002/04/30
投稿数: 428
お住まい・勤務地: 愛知県
投稿日時: 2003-07-05 00:54
尾島さんの記事はこれから .NET, C#の採用をしようとしている人には
参考になると思います。 自分がイイと感じたものに対して、これだ
け筋道を立てて体系的に説明できる人を羨ましく思います。

でも、私はこの記事を読んで C#を使ってみようとか、C#に乗り換えよ
うとは思いませんでした。

それは、記事のレベルだとか、体系だった理屈で説明できるものでは
ありませんが、Javaが出てきたときの、あのワクワクが大好きだから。
そしてまだそれは醒めることはありません。 しばらくはマクネリに
踊らされてみるつもりです。
佐々木
大ベテラン
会議室デビュー日: 2003/03/30
投稿数: 121
投稿日時: 2003-07-05 00:54
私はJava屋ですが、そんなに悪い記事ではないと思いました。
「ちょー素晴らしー。明日からC#!」とも思いませんが、
「プロパティ」と「メタデータ」は正直うらやましいです。

でも「struct」と「delegate」は全く不要だと思いますね。
何かの間違いでJavaに導入されて言語仕様を汚さないことを願うばかりです。
makura
ベテラン
会議室デビュー日: 2002/11/27
投稿数: 90
投稿日時: 2003-07-05 01:20
makuraです。私も サ さんと同感。

まあ、C#もJavaも熟知しているという人がどれだけいるかという点を考えれば、Javaの方から見て「なんたる無知」と思われるのも致し方ないかと。
記事に対してどのように対処するかは、個々人の情報リテラシーの問題かと。
ただ、ビギナーの情報収集の場でもあり信頼もある@ITのようなサイトでそれはきついかな。
今回の記事は技術者としての意見というよりは営業的側面が強いかなという気もします。
.netでなら断然C#だけど、Javaから乗り換える意味はない。

私はなぜか「選択の余地なし」の環境でばかり開発をしているので(顧客の要望とか)、JavaもC#も使いますが、きれいな設計のJavaと便利なC#の間で揺れています。プロパティはJavaにも欲しいですね。
新入社員に教えるなら断然Javaです。
(でも付け焼き刃のJava技術者は使い物にならんと営業サイドから苦情が・・・


[ メッセージ編集済み 編集者: makura 編集日時 2003-07-05 01:23 ]

スキルアップ/キャリアアップ(JOB@IT)