- PR -

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

参照元記事 | 同じ記事を参照しているスレッド一覧
«前のページへ 1|2|3|4|5|6|7|8|9|10|11 次のページへ»
投稿者投稿内容
プリンス
ベテラン
会議室デビュー日: 2003/07/05
投稿数: 78
お住まい・勤務地: 神奈川
投稿日時: 2003-07-05 11:30
私がxxからxxにxxしたxxの理由という形式の記事は洋書にはよくあるように、挑発的になります。IT会議室での反応をみれば著者の記事は良くも悪くも成功したといえます。

4ページ目を読むとわかりますが、著者がいいたかったことは実は言語レベルの話ではなく、実行効率と実装効率が目的で、C#だのJavaだのというのは手段ということです。
それを立証するために3ページも費やしたため論点がぼけてしまいました。
本来なら、4ページ目を最初に述べるべきでしょうけど。

さて、100歩譲って、C#のほうがJavaより実行効率/実装効率がよいと仮定します。

著者の記事で???なところはシステム構築の目的が実行効率と実装効率であるということです。これは非常に近視眼的で顧客を無視した受託開発でいかに粗利をだすかという考えです。顧客の立場にたてば、究極のゴールはお金をもうけて株主に利益を還元すること、そして、その手段としてシステムがあるのです。

ではお金を生み出すシステムとはなんでしょうか？
それはビジネスの変化に迅速に対応できる柔軟なシステムです。
実行効率と実装効率を重視する一方で、柔軟性を犠牲にしていないでしょうか？
このあたりメインフレーマーに所属する著者の考えが聞ければうれしいです。




[ メッセージ編集済み 編集者: プリンス 編集日時 2003-07-05 11:34 ]
いまい
会議室デビュー日: 2002/07/02
投稿数: 13
投稿日時: 2003-07-05 13:47
わたしはJavaBeansの命名規則でハマったクチなので、プロパティを明示できる言語仕様は良いと思ってます（Rubyなんかもそうですよね）。
＃getFoo()は'foo'、getXXFoo()だと'XXFoo'って変換規則でハマったことありません？

１年くらい先の話になるけど、J2SE1.5で結構ビックリするくらい言語拡張されるので、こっちが良い、あっちが悪いって言ってもしょうがないんですけどね。
＃metadataなんか待望なんだけど、J2EEで使えるようになるのはいったいいつになるやら。

結局の所、いろんな言語の特性を知っているのが寛容かと。
今はJavaで仕事してるけど、いつC#(.NET)にスイッチするかわかりませんし。
そういった意味では、この記事は「C#ってJavaとどう違うの」ってのがわかって良かったです。
会社員
ベテラン
会議室デビュー日: 2003/01/21
投稿数: 50
投稿日時: 2003-07-05 20:50
（C#とjavaに関係ない発言だったので削除します。）

[ メッセージ編集済み 編集者: 会社員 編集日時 2003-07-06 23:06 ]
未記入
大ベテラン
会議室デビュー日: 2003/06/28
投稿数: 219
投稿日時: 2003-07-05 23:10
会社員様＞納得しました。
で、私がこの記事を読んでふと疑問に思ったのは、
プリンス様も申し上げています4ページ目の落ちがそれまでの勢いに比べ
あまりにも弱すぎるので（これもストーリーの「型」かもしれませんが）
この筆者様は実のところ乗り換えていないのでは？と感じてしまいました。
恐らく、まずタイトルありきで、そこから文章を組み立てたのか、と。
タイトルは「私がC#を選択肢に加えた10の理由」とすべきではないでしょうか？


[ メッセージ編集済み 編集者: Ken-Lab 編集日時 2003-07-05 23:24 ]
おじま
会議室デビュー日: 2003/07/06
投稿数: 14
投稿日時: 2003-07-06 00:29
書いた人です。

>>記事を読んでいただけた全ての方

読んでいただいて、本当にありがとうございます。

あと、舌足らずな文章で申し訳ありませんでした。ちょっと補足を。

私は、JavaとC#の最も大きな違いは「オブジェクト指向」を唯一絶対の指針とす
るか否かだと考えています。

で、JavaとC#の違いを考察する場合に重要なことは2つ。「オブジェクト指向は
万能の道具なのか」と「夾雑物があるとオブジェクト指向は不可能になるのか」
だと考えます。オブジェクト指向が万能の道具であるならC#での他技術の採用は
無駄となります。オブジェクト指向が（万能かどうかはともかくとして）有効で
あることは論を待たないので、夾雑物でオブジェクト指向できなくなるならC#で
の他技術の採用は害をなすだけとなります。

私は、オブジェクト指向は万能ではないと考えます。継承関係のないオブジェク
トに機能を追加できなかったり、構造化プログラミングで表現する方が実装効率
が高い場合があるためです。もちろん、オブジェクト指向が有効であることには
異論はありませんけど。

私は、夾雑物はオブジェクト指向の妨げとはならないとも考えます。私がオブジ
ェクト指向で最も嬉しいと感じたことはモジュール間の直交性を容易に実現でき
ることで、直交性を提供するオブジェクト指向が他の技術と直交できないという
のはおかしいと“感じる”ためです（感覚的な話で申し訳ありません）。

で、C#ではこんなに貪欲にいろんな技術を取り入れていながら、全体として使え
るものになっているんですよ、という話のつもりでした。

＃だったらこんな書き方をするなというのは非常にもっともなのですけれど、こ
＃ういう書き方をしないと誰も読んでくれないので勘弁してください。

_________________
おじま
会議室デビュー日: 2003/07/06
投稿数: 14
投稿日時: 2003-07-06 00:31
>> いまいさま

J2SE1.5、すごそうですね。私はJavaSoftがVMに手を入れるとは思っていませんでしたので、かなり驚いています。

Javaはオブジェクト指向の範囲で最善のものを提供し、C#はオブジェクト指向の範囲を逸脱することに躊躇しないという違いを感じていただければ幸いです。
おじま
会議室デビュー日: 2003/07/06
投稿数: 14
投稿日時: 2003-07-06 00:34
>> makuraさま

おっしゃる通りです。C#を.NET Frameworkへの乗り換え理由とするのは無理があ
りますね。別途J2EEと.NET Frameworkを比較しなければなりませんし、
Microsoftをどこまで信用するかどうかという問題がありますから。

でも、.NET FrameworkはC#と似た設計思想で面白いですよ〜。やっぱり「利益が
あるならあらゆる手段を採用してやる」という感じです。一般の人が使うOSにも
この思想を採用しているMicrosoftの態度にはちょっと疑問があると思いますけ
れど、プログラマ相手の.NET Frameworkならばアリだと考えます。

＃makuraさんは既にC#を使われているわけですから、釈迦に説法でしたね……。
おじま
会議室デビュー日: 2003/07/06
投稿数: 14
投稿日時: 2003-07-06 00:38
>> 悪夢を統べるものさま

>それは整合性，一貫性がないということで，お世辞にも誉められた
>ものではない．

たしかにC#には「一貫性」はありません。しかし、「整合性」はあると考えます。
様々な技法を取り入れているので全体としての技法は一貫していませんが、それ
ぞれの技法を（ちょっとムリヤリなところはありますけど）整合させていると考
えます。

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

はい。最近のGCは頭良いですもんね。ただし、ミドルウェアなどでは大量のイン
スタンスを作らなければならない場合があり、そこではやたらとインスタンスを
使いまわしていたりします。Javaのswingもそうで、初期には使いまわしに起因
するメモリリークに泣かされたりしました。

基盤製品を作る人にとってはGCは手なずけなければならない仮想敵の一つだと思
います。というわけで、structを使ってMicrosoftの人が作った.NET Framework
Class Libraryは快適ですよという話でした。

もちろん、私のような一般開発者であれば悪夢を統べるものさまがおっしゃるよ
うにGCはあまり気にしなくてよいでしょうけど、私が楽するためにいろいろして
くれる人たちも楽して欲しいなと思います。

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

はい。ですから、structは「メモリ・リークを発生させない範囲」でオーバーヘ
ッドをなくします。

> 一部のインスタンスをスタックに入れることは可能でしょうが，
> あまり大量のインスタンスを入れることは無理があります．

はい。ですから、structは「小さなもの」しか使うなとドキュメントに記載され
ています。すみません、これを本文の中に書き忘れてました。

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

はい。ポリモルフィズムがあまり必要でない場合にしか適用できません。これは
本文の中に書きました。

structは、classを補完するものです。小さかったり、ポリモルフィズムが不要
だったりする場合に使用します。C#では、intとかdoubleがstructなんです。基
本型と呼ばずに値型と呼ぶのは、このあたりが理由だと思います。

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

最小単位の「最小」が抜けていました。ごめんなさい。関係はclass間や
interface間、classとinterfaceの間にしか作れないという意味です。

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

この部分は理解できませんでした。私はinterface使いまくりだと自負してきた
人間なので、もう少し詳しく説明していただけると嬉しいです。

もし、インターフェイスは概念であるという話でしたら、私の書き方が悪かった
ですね。ここは概念のインターフェイスではなくてinterfaceという文法のつも
りで書いてました。

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

「Java Beanを貼り付けるスタイルの開発環境では貼り付けたコンポーネントの
インスタンスを設定するためにプロパティが必要になる」ですね。不可能ではな
くて「他に必要なものがある」でした。

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

メソッドや引数、戻り値、モジュールにも使えるところがC#のカスタム属性の利
点です。クラスだけならinterfaceのmixinでかまいません。

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

変化しないのは同意します。記述が曖昧であった点は申し訳ありませんでした。
もっとも、これはSerializableでも同じですよね。バグ云々は実行環境の出来し
だいだと考えます。

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

スレッド・プールを作成するコードなどは、デバッグ地獄と直接結びつくと考え
ます。

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

無知ですか……。まぁ、Javaの問題のいくつかは解決されていると考えていただ
けるとありがたいです。

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

すばらしい！不勉強で知りませんでした。でも、将来を持ち出すのならばどんな
議論でも勝てちゃうので、これはここまでロジカルだった悪夢を統べるものさま
らしからぬ発言だと思いますよ（Javaにもカスタム属性が追加されるわけですし）
。

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

設計はちょっとわかりません。セマンティクスに関しては、無理があったのでC#
では改善されたというつもりで書いています。

>> 閑話休題。そもそもインターフェイスは型に基づく安全な
>> プログラミングをするためのものである。
> まず，違うでしょう．
> 少なくともインターフェースの「目的」はそれではない．

すみません。わかりませんでした。

私の文書で、概念としてのインターフェイスと文法のinterfaceがごっちゃにな
っていたことがこの混乱の原因でしょうか？その場合はお詫びします。

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

実装があるのは、implementsするclassの部分です。ですからインターフェイス
ではないのはあたりまえで、抽象クラスとは何も関係ありません。文章（C#の文
法も）がわかりづらいのはごめんなさい。すみませんが、この部分をもう一度読
んでみてください。

>> 優秀なJavaプログラマが書いたソース・コードを見ると、やたらと
>> 「final」が目に付く。(中略)ポリモルフィズムが不要な部分では、
>> finalを指定した方が実行効率を向上させられるのだ。
> これは大嘘です．
>
> たしかにJavaプログラマーも必要があればfinalを使いますが，それは
> 継承やオーバーライドを禁止するためです．実行速度についてはほとんど
> 影響ありません．これはそれこそJDK1.0とかの大昔の話か，或いは
> その後のJava技術の進歩を知らない素人かですね．

すみません。素人でした。都市伝説に振り回されてましたね。本当にごめんなさ
い。

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

はい。デフォルトはポリモルフィズムではありません。これを「オブジェクト指
向ではないから駄目」と考えるのではなくて、前の発言に書いたように「オブジ
ェクト指向以外の技法を取り入れるという設計方針の是非」という視点で論じて
いただきたいと考えています。

＃だったらこんなタイトルにするなってのはあるんですけど、こうしないと悪夢
＃を統べるものさまは読んでくれなかったでしょ？

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

ツールとして「だけ」考えるなら、私はVisual Studio .NETよりIDEAの方が使い
やすいと思います。本文にもそう書きましたが、ここで書きたかったことは環境
構築の容易性です。xercesバージョン地獄は辛かったなぁという話でした。

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

えっと、問題は比率です。やたらと多すぎると思います。まぁ、私の環境が悪か
っただけかもしれませんが、Javaでビジネスをやっていると真面目に勘弁して欲
しいようなことを言う人たちが多かったんですよ。

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

嫌なコミュニティの絶対数は増えると思いますけど、全体における比率は少ない
値に収まるのではないかと予想しています。Microsoftの文書は、かなり夢がな
いですから。

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

うぅ、実は私の一番好きな言語はC++なんです。「普通のスキルを持ったプログ
ラマ」なら、C++でオブジェクト指向できると考えてます。

＃あと、「全て」のプログラマは、Javaでも無理だと思います。

最後に。C#をオブジェクト指向の観点で評価すると夾雑物が多くて駄目だという
結論になることは、ちょっとでもC#をいじれば分かることだと思います。これを、
オブジェクト指向以外の技術にも評価すべきものがあるのではないかという視点
で論じていただけると嬉しいです。

＃もちろん、結論はオブジェクト指向以外は不要とかオブジェクト指向の技術以
＃外を入れると駄目とかでも構いません。
«前のページへ 1|2|3|4|5|6|7|8|9|10|11 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）