2000 年 (私たち IIRC に .NET が導入されたとき) には、革新的な最先端の言語でした (私が最後に使用したのは 2003 年でした)。
私が読んだ限りでは、Sun は非常にゆっくりとしか言語を進化させていません。Generics の追加など、言語が進化したところでは、開発者が実装の貧弱さに不満を持っていることさえ読んだことがあります。
これらの正確な認識はありますか? もしそうなら、特に C# との一見明らかな競合について、その理由について何か考えはありますか?
2243 次
7 に答える
21
企業の観点からすると、言語を進化させることは良いことではなく、実際にはかなり悪いことです。
そのため、cobol、fortran、さらには C などの古い言語の後に年号が付けられているのを耳にします。多くの企業はその年に固執しています。
その上、大規模なチームは、チーム内の誰かが他の人が理解できないことを行う可能性が高くなることを意味します。そのため、言語をシンプルかつクリーンに保つことには、重要ではあるが過小評価されている価値があります。これは、物事を行うための代替方法を追加しすぎないことを意味します。
私は Ruby を使って仕事をしていて、その言語に夢中になりましたが、企業の観点から見ると、それはまったく恐ろしい言語でした。下手なプログラマーが大規模なチームを混乱させ、数分で作成された混乱を解くのに何日も費やすことを余儀なくされる方法は数え切れません。
ジェネリックの複雑さを理由に、Java 5.0 への移行を拒否する企業があります。(まだ 1.3x に取り組んでいますが、それは別の理由によるものです)。
そして正直なところ、ほとんどの「改善」はほとんど役に立ちません。いくつかの構文の変更、いくつかのレベルの中括弧を削除する機能。
Java がビジネス ロジックを繰り返すことを余儀なくされたケースを 1 つも思いつきません (これは、コードを "DRY" にしようとしているときに心配することです)。あなたは良いプログラマーです。
たとえば、ビジネス ロジックを繰り返さずにサブクラスで実行できるクロージャーで実行できることはすべて、ブレースや余分なクラス定義の層のために見栄えが悪くなりますが、多くの場合、より再利用可能です (クラスを拡張できます)。コールバックを実装するために使用しますが、クロージャ メソッドを拡張することはできず、書き直す必要があります。)
キャリアの最初の数十年間は、コードについてこのように感じることはありませんでした (私は言語のトリックが大好きで、ファンキーなほど良いです) が、今では長い間そうしてきました。 、またはそれは経験かもしれませんが、今では単純で明示的で安定したコード (いたずらをさせない言語によって提供される) に大きな利点があることがわかり、多くの代替方法に単一の利点を見つけることができません。 1 ～ 2 行の入力を節約できます。
ただし、Java のアップグレードをお探しの場合は、Scala をご覧ください。それは非常に驚くべきものであり、今でも JVM 上で実行され、Java とやり取りします。
于 2008-11-20T18:10:25.563 に答える
20
ほとんどの言語には、その起源と進化に関与する強力な手が 1 つあります。考えてみてください: Larry Wall/Perl、Guido/Python、Matz/Ruby、Odersky/Scala、Hickey/Clojure など。私は左腕を彼らの半分ほど賢くしたいと思います。
Java は実際には、1 人だけでなく、一連の素晴らしい言語担当者が指揮を執っているという特徴があります。Gosling から始まりますが、Guy Steele、Bill Joy、Gilad Bracha、Neal Gafter など、すべての素晴らしい人たちも思い浮かびます。それは実際には良いことでした（私は思う）。それは言語をより良くしましたが、停滞を防ぎました.
しかし、ここ数年、言語のリーダーシップには本当に空白がありました。現時点では、誰も店を気にしていません。何が Java の型に適合し、追加するのが理にかなっているのか (または、さらに重要なことに、追加しないほうがよいのか) について難しい決定を下している人は誰もいません。それが何を意味するのかわかりません。Java の絶大な人気とリーチ、そして JVM の強力な基盤が、この真空が魅力的すぎて、ある時点で埋めて方向性を与えることができないことを意味することを願っています。しかし、それが誰になるか分からないので、私は慎重に希望を持っているだけです.
John Rose は JVM 側の男です。いずれかでしか革新を得ることができない場合でも、とにかく今すぐ JVM を使用します。:)
于 2008-11-20T18:14:26.460 に答える
11
特に C# や VB と比較すると、Java は非常にゆっくりと進化しています。個人的には、実行時の安全性と効率性を犠牲にして下位互換性を維持するという点で、彼らはジェネリクスで間違った決定をしたと感じています。.NET アプローチは、ほぼすべての点で優れています。IMO です。
Java 7 には、潜在的な機能(言語とプラットフォームの両方) の長いリストがありますが、作成には非常に長い時間がかかっており、多くの機能にはまだ大きな疑問符があります。
しかし、なぜこれが起こったのかについて「責任」を負いたくありません。
于 2008-11-20T17:58:22.343 に答える
6
Java 言語の進化はゆっくりですが、意図的にそうしています。
ジェネリックが良い例です。以前のバージョンの Java との互換性が必要でした。プロジェクトの目標を考えると、ジェネリックの実装は設計どおりの非常に便利な機能を実行します。ただし、具体化されたジェネリックの動作を期待していた多くの開発者の期待には応えられません。
一方、JVM のイノベーションは非常に急速で、多くの場合、他の VM を先導し、パフォーマンス分野での競争を促進しています。
私の意見では、Java 言語は可能な限り安定しているべきです。私はクロージャの考え方は好きですが、Java がクロージャのための言語であるとは思いません。(何かを入れなければならない場合は、保守的な FCM の方がいいと思います。) 私は、トレーニングが必要な開発者のチームと協力して、複雑な実稼働アプリケーションを構築および保守しています。Java 言語は、そのままの力と構造を見事に融合させてくれます。
Scala や Groovy などの他の言語や、Ruby や Python などの JVM へのポートは、Java 言語自体が COBOL に取って代わった後も、Java プラットフォームに命を吹き込み続けるでしょう。
于 2008-11-20T18:05:44.793 に答える
3
現時点では、Java は .Net とは異なる問題を抱えているため、異なる選択肢が生じます。
.Net は比較的新しく、Java の間違いの一部を回避できる可能性があるため、別の方法を実行できる可能性があります。これにより、次の 2 つの主な利点が得られます。
- MS は、ランタイム プラットフォームをより明確に区別することができました。C# 3.0 は明らかに 1.1 フレームワークでは実行されず、C# 1.1 は 3.0 フレームワークでは実行されません。もちろん、多少のあいまいさはありますが、一般的には、自分がどこに立っているかをよりよく理解できます。一方、Windows ではクライアント JVM はデフォルトで自動更新されます。そのため、古いシステムを機能させ続けるのは非常に難しい場合があります。
- .Net フレームワークは、より新しいものであり、蓄積された粗悪さと内部の複雑さがはるかに少なくなっています。これらのことは、新しい機能を追加する速度を低下させます。現在、.Net でもこれが見られるようになりました。たとえば、代わりに IEnumerable を使用する配列を渡すか返す必要がある BCL 関数がいくつかあります。これらの関数の歴史により、それらを変更することはほぼ不可能です。
これら 2 つのことが協力して、(現時点では) .Net 言語がより迅速に進歩することを可能にしています。しかし、すでに述べたように、これらの効果が .Net にも追いつき始めています。
于 2008-11-20T18:48:24.083 に答える
1
長い間、Javaは（良くも悪くも）言語自体ではなく、フレームワークを介して新しい機能を導入することを好みました。
たとえば、Spring / Hibernate / Strutsアプリケーションを作成している人は、フレームワークによって実行されるすべてのリフレクション/インジェクション/インストルメンテーションの魔法がないとコードがほとんど動作しないため、実際にはJavaの特殊な方言で作成していると主張できます。
個人的には、言語をもう少し進化させ、フレームワークの作成者がバイトコード操作を介して言語セマンティクスでモンキーをやめることを望んでいます。
ちなみに、ジェネリックスの実装に型消去を使用するというSunの決定にも強く反対します。おそらく、彼らは下位互換性を確保したかったのですが、アノテーション（Java 5でまったく同時に追加された）が独自の非互換性のセットを作成したため、私にはまったく不思議に思えます。いずれにせよ、Java 5用にコンパイルされたコードは、以前のJVMで実行することはできないため、下位互換性の主張は私には非常に疑わしいようです。
于 2008-11-20T21:58:46.087 に答える
1
Sun は現在、保守的であり、いくつかの不適切な決定を行った後、正しい決定を行うようになっていると思います。
さらに、Java 1.5 が登場する前に、多くの政治的議論や混乱がありました。多くの企業は Generic Java のようなサードパーティのハックを使用していました。これらのコア言語機能は利用できませんでしたが、強く望まれていたからです。
1.5 以降、1.7 が間近に迫っており、これらのそれぞれが非常に便利な新機能を提供しているように見えます。言語のオープンソースも優れています。
一部の人々が何と言おうと、下位互換性を維持することは Java 言語の非常に重要な機能です。
私は、.NET が Sun のロバに拍車をかけたと思います。両方が存在するのは良いことです。
于 2008-11-20T18:07:44.790 に答える