java - Java++ は必要ですか?

Question

いくつかの点で、Java は C がしばらく前にあった場所にあるように思えます。どちらも当時としてはかなり最小限の言語であり、比較的クリーンでシンプルなコアを構築することができます。(ここでは、ライブラリではなく、コア言語について言及しています。) どちらも非常に人気があります。どちらも共通語であり、レガシーコードが大量に含まれています。どちらも、他の言語のプログラマーが見逃しがちないくつかの最新の生産性機能を欠いています/欠いていました。どちらも非常に慣性に支配されており、変化する世界への適応が遅いようです。

C++ が C にあるように、Java のおおよそのスーパーセットである Java++ を作成することは合理的であるように私には思えます。絶対に必要な場合にのみマイナーな方法を使用し、プレーンな古い Java には欠けている多くの最新の機能を追加し、後で標準化について心配します。良いアイデアと思われる機能は次のとおりです。

ファーストクラスの関数、デリゲート。
閉鎖。
varC# やautoDと同様の静的型推論。
演算子のオーバーロード。
C# や D などのクラスとは異なる値型としての構造体。
プロパティ。
チェック例外を無視するオプション。
ファイルで複数の最上位パブリッククラスを宣言する機能。
追加などを可能にする、より強力な組み込み配列。
より良いジェネリック/実際のテンプレート。
C# 4.0 の dynamic キーワードのようなもので、一般的に静的な言語で必要に応じてダックタイピングを行うことができます。
Java は主に VM 言語であるため、特定の目的のためにオンザフライでコードを生成するなどのハードコアなメタプログラミング機能が含まれている可能性があります。

そのような言語の需要があると思いますか? そんなことが成功すると思いますか？

編集:ランタイム/バイトコードレベルでの互換性について話しているのではなく、ソースレベルでの Java との互換性について話しているのです。また、はい、Java 7 はこれらのいくつかを追加できますが、Java に機能を追加するための「公式」プロセスは非常に保守的であるようです。本当のポイントは、安定性/標準化よりも革新に重点が置かれている場合に、Java をブランチにフォークするというアイデアです。

score 29 · Accepted Answer

たとえば、Scalaのように、または Java の動的バージョンとして自らを主張する Groovy のように？

score 20 · Accepted Answer

これについてはJavaのファンに反対されますが、JavaとC＃の両方を作成する人として、C＃はJava++に近いと思います。

CからC++は、手続き型からオブジェクト指向へのパラダイムシフトでした。名前を保持する唯一の理由は、Cプログラマーに、C++を装った非常に悪いCコードの負荷につながる同じ言語であると思わせるためです。

Javaは絶えず拡大しており、Sunは急速に多くの機能を組み込んでいるため、Java7または8がJava++である可能性があります。

score 18 · Accepted Answer

「 Java++ が必要ですか? 」に対する答えは、「私たち」が誰であるかによって異なると思います (そして、「私たち」がすべて 1 つのクラスのインスタンスであるかどうかはわかりません ;-)。この問題は、 The Java Posseによって何度も議論されています。

Java の大企業ユーザーは、より保守的な傾向があります。彼らは大規模な開発スタッフと既存のコードの大規模な本体を持っています。結果として、言語またはライブラリの変更 (トレーニング、メンテナンス、既存コードの破損など) には、高いコストとリスクが認識されます。

その一方で、プログラミングの次の素晴らしいアイデアをいつでもつかむ準備ができている、小規模で軽快な開発チーム (オープンソースまたはそれ以外) がたくさんあります。1 つの回答ですべての人が十分に満足できるかどうかは、私にはわかりません。

JVM ベースの言語の成長するエコシステムが、この緊張に対処するのに役立つかもしれないと私は提案します。新しい言語 (Scala、Fan、JRuby、JavaFxScript など) が、既存の Java (より落ち着いたペースで動く可能性がある) との相互運用性を維持しながら、2 番目のグループが望む表記機能 (および目新しさ) を提供する場合、おそらく両方のグループが可能です。選んだケーキのフレーバーを持っています。

一部の人々が One True Language を望んでいるように見えることに、私は少し困惑しています。当時、各言語 (表記法) には適用可能な「スイートスポット」があるという考えを耳にすることは非常に一般的でした。場合によっては、システムの各部分を適切な言語で記述し、それらをリンクすることが正しい解決策でした。

バック・トゥ・ザ・フューチャー、誰か？

score 6 · Accepted Answer

問題は、実際には「次の言語」で何を行うかをどのように決定するかです。機能を少しずつ追加/削除するだけで、大量のがらくたになります。これらの機能の追加または削除（多くの場合、組み合わせて機能する）によって、新しい原則に従ってプログラミングの方法がどのように変わるかを考える方がはるかに優れています。たとえば、Javaクロージャの提案が、豊富な型推論なしで静的型付けを処理しなければならないことで多くの点で苦しんでいることは興味深いと思いました。かなりのクロージャを持つ動的言語の例はたくさんあります-それらはうまく調和します。そして、Scalaや他の言語は、静的型付けと豊富な型推論もクロージャをきれいにすることができることを示しています。私のポイントは、言語Xを採用して言語X++を作成することはおそらくそれほど面白くないということです。それ'

確かに、今すぐJavaをフォークして、好きなものにすることを妨げるものは何もありません（Javaと呼ばないか、テストスイートに合格したい場合を除きます）。上で述べたように、まさにそれを実行し、Javaとの相互運用性を維持しているエキサイティングな高品質の言語のセットがすでにあります。私は主にGroovy、Scala、Clojure、Fanについて考えており、JRuby、Jython、RhinoなどのJVMへの以前の言語の移植は少なく、クリーンなJava統合の実装に苦労する傾向があります。

Java7のJVMに搭載されたJSR292機能は、すでに優れたJVMベースでの言語開発のためのさらに豊富な遊び場を提供する可能性が非常に高いです。また、CLR+DLRも多くの興味深い境界を押し広げています。

ますます、将来は仕事に適した言語を選ぶ傾向にあると思います。これは、伝統が混ざり合った言語（たとえば、ScalaはFP / OOの良い例です）または複数の言語間のクリーンな統合を促進する仮想マシン（JVM、CLR、BEAM、Parrotなど）のいずれかで発生します。または、おそらく、これらの両方。私たちは、Java（または他のもの）の派生物であるNextBigLanguageに向かっているわけではないと思います。

score 6 · Accepted Answer

現在 Java では、これらの多くに対して回避策が用意されていますが、これらのことを行うより自然な方法を導入することは難しくなっています。

ファーストクラスの関数、デリゲート。

ほとんどの場合、リフレクションを使用すると短くなります。(ただし、あまり自然ではありません)

.4. C# や D などのクラスとは異なる値型としての構造体。

これには同意します。

.5. プロパティ。

これはすぐに実行できますが、多少の努力が必要です。適切な組み込みサポートがあればより良いでしょう。

.6. チェック例外を無視するオプション。

あなたは今これを行うことができますが、それはハックです. 注: チェック例外はコンパイル時の機能です。

人々が例外を本当に理解していない限り、これが本当に良い考えであるかどうかについては、かなり懐疑的です。多くの場合、これを提案する人々は、エラー状態について考えさせられたり、それらを文書化したり処理したりすることを好みません。

。7。ファイルで複数のクラスを宣言する機能。

あなたは今これを行うことができます。トップレベルの public クラスは 1 つだけです。

.8. 追加などを可能にする、より強力な組み込み配列。

commons ArrayUtils を参照してください。健全な toString() を持つ配列が開始されます。

.9. より良いジェネリック/実際のテンプレート。

あなたが何を意味するかによって、私は同意します。改善する前に、まず現在の実装を機能させる必要があると思います。たとえば、Java API は未チェックの警告なしでコンパイルできます。

.10. C# 4.0 の dynamic キーワードのようなもので、一般的に静的な言語で必要に応じてダックタイピングを行うことができます。

繰り返しますが、リフレクションはこれを行いますが、比較的醜いです。

.11. Java は主に VM 言語であるため、特定の目的のためにオンザフライでコードを生成するなどのハードコアなメタプログラミング機能が含まれている可能性があります。

JavaCompiler (Java 6)、Scripting support (Java 6)、JCI または BeanShell と同様です。

score 4 · Accepted Answer

4

Java++はすでにここにあります... :D

于 2010-01-12T04:51:51.200 に答える

score 4 · Accepted Answer

大きな変化を起こすとしたら、最初からやり直したいと思いませんか? Java での修正/削除でできることはたくさんあります。機能を個別に検討することはできません。機能は予期しない方法で相互作用します。大規模で複雑な言語は、おそらく悪い言語です (C++ を参照)。

score 3 · Accepted Answer

ほとんどの機能はすでに存在しています。

その言語は次のとおりです。

_{（出典：codehaus.org）}

=

はどうかと言うと：

1つのファイルで複数のクラスを宣言する機能。

それは最初からJavaに存在しています。

score 3 · Accepted Answer

これらはすべて、言語哲学を根本的に変更するのではなく、主に開発者の利便性によって動機付けられた「表面的な」言語変更のように見えます。

私の見解では、構文の小さな調整は、新しい言語への大規模な移行を正当化するものではありません。プラットフォーム、コードベース、および開発者のスキルセットへの多額の投資を捨てることを意味する場合は特にそうです。

十分な需要があれば、時間の経過とともに (Java 7、8、9... で) Java 言語に小さな変更を加えることができます。ただし、このような変更が行われるたびに言語が複雑になり、さまざまな開発者がさまざまな機能のサブセットを使用し始めるため、コードベースの学習と維持がより困難になるため、それらが正当化されるかどうかについての本当の疑問があります。

C++ を例にとると、理論的には素晴らしい言語であり、最適化されたコードで機械語レベルのパフォーマンスを維持しながら、可能な限りの抽象化レベルでプログラミングすることができます。実際には、このすべての言語機能の複雑さは、実際に何が起こっているのかを理解できる人間はほとんどいないことを意味し、大規模なコードベースはほとんど維持できなくなります。

私の見解では、大規模な「Java++」を正当化する唯一の変更は、ソフトウェアの開発方法をより良い方向に変える基本的なパラダイムシフトです。Java を成功に導いた (1995 年から 2000 年にかけての C++ などに対する) 根本的な変化は、私の見解では次のとおりでした。

再コンパイルを必要としない、移植可能な標準のクロスプラットフォームランタイム環境 (JVM/JRE) でのバイトコード実行
大規模で堅牢な標準クラスライブラリ (スレッド化、ネットワーキング、GUI などを含む) - つまり、プラットフォームは単なる言語以上のものであるという認識
ガベージコレクションが義務化されました

根本的な変化の次の段階の例は次のとおりです。

関数型プログラミングを支持してオブジェクト指向を捨てる
ソフトウェアトランザクショナルメモリを優先してロックを排除し、大規模なマルチコアアーキテクチャで高性能でスレッドセーフな同時実行を可能にします。
言語およびクラスライブラリ全体で可変変数を不変値に置き換えます (同時実行状態について推論できるようにするため)。
新しい構文を言語に追加したい、または DSL を作成したいという欲求に対する一般的な解決策として、コンパイル時マクロメタプログラミングを採用する

そうそう、これをすべて行う JVM 言語があります - Clojure

score 3 · Accepted Answer

それらのものはほとんど綿毛です。

並行コードの設計と推論を容易にするなど、いくつかのより大きな問題を解決する必要があります。

score 2 · Accepted Answer

これらの構造のサポートを JVM に追加し (必要に応じてクロージャなど)、記述言語とコンパイラで必要なシンタックスシュガーを作成します。もちろん、下位互換性を維持したい場合は、設計上の決定を行う必要があります。これが、Java Generics が本来の性能を発揮できなかった理由です。より完璧なJavaを手に入れるために、それから解放されたいと思うでしょうが、互換性が問題になっているため、需要はほとんどないでしょう。

そして7はすぐに行くことができます。ここでは、フロッピーディスクの FAT12 ファイル制限に達していません。

score 2 · Accepted Answer

Sun によるこのような取り組みは、単に Java 7 (または 1.7 または 2.0) と呼ばれるのではないでしょうか? 他の人/グループによるそのような取り組みは、Java以外のものと呼ばれることはありませんか?

score 1 · Accepted Answer

BeyondJavaをご覧になることをお勧めします。

JoelonSoftwareに関する良いレビューがあります。

score 1 · Accepted Answer

Javaは改善できるし、改善すべきですが、すべてのニーズを満たすために1つの言語が必要だとは思いません。これは、デススターのように、一般的に悪い考えです。

多くのプログラマーはただ怠惰で、新しいことを学びたくありません。彼らはむしろ、過去10年間使用してきた1つの言語に固執しています。

ハードウェアの速度と制御が必要な場合は、Cのようなものを使用します。システム管理タスクが必要な場合は、シェルスクリプト、またはperl、python、rubyなどのスクリプト言語を使用することになります。数学特有のことをたくさん行う場合は、Matlabが適しています。等pp。

言語に関係なく、タスクに最適なツールを使用してください。優れたプログラマーは、どの言語でも作業できるはずです（私に関しては、私はまだそれに取り組んでいます）。

score 1 · Accepted Answer

Java はオープンソースになりつつあるため、ソース (すべてが利用可能な場合) を取得して、独自のバージョンの Java を作成できます。これが広く採用されれば素晴らしいことですが、そうでない場合は、必要な機能のセットではない可能性があります。

score 0 · Accepted Answer

私は実際にあなたの意見に本当に同意し、あなたの提案によって軽減できる Java の問題に遭遇しました。

原則として、これに対応し、既存の Hotspot JRE を使用する独自の javac を作成できます。しかし、Sun の助けがなければ、それを実現することはできません。

問題は実際には 2 つあります。1) Sun のアプローチは「Java プラットフォーム」をサポートすることであり、スーパーセットであっても新しい標準に耐性があること、および 2) Java に変更を加えるには、JSR を発行する必要があることです。通常、企業スポンサーが必要です。企業は他の優先事項を持つ傾向があります。

もう一度、私はあなたにそれを推し進めることをお勧めします。結局のところ、2007 年までは多くの賢い人々が Java をゼロから作り直すところだった = GNU クラスパス。したがって、「第 2 級の JVM 言語」に必要な才能があります。

score 0 · Accepted Answer

私は Java が時代遅れになったと感じていますが、実際には、言語として Java が今でも十分に機能することは誰もが知っていると思います。確かに、他の言語で見つけることができる新しいものの多くはそこにはありませんが、それでも機能します! それでもすべてを行うことができますが、時間がかかり、より多くの作業が必要になる場合があります。私はそれが取って代わられる日を楽しみにしていますが、Java で書かれた既存のコードとアプリケーションのすべてを考えると、現時点では方法がなく、(ほとんど) Java++ に移行する人はいないと思います。C++ から C への移行のように、私たちは真のパラダイムシフトを待っていると思います。おそらく、関数型プログラミングが次の大きなものになる可能性があり、Scala が次の Java になるでしょう。

score 0 · Accepted Answer

Java 7 で利用可能な情報を確認してください。Java 7 には、誰もが求めているいくつかの機能が追加される予定であることがわかると思います。

score -1 · Accepted Answer

C++ はオブジェクト指向の C です。Java はすでにオブジェクト指向です。では、別のパラダイムシフトをどのようにして Java++ にするのでしょうか?

ある意味逆だと思います。Java は C++ よりはるかに進んでいます。Java には高レベルのライブラリとフレームワークがありますが、C++ は依然として低レベルであり、ANSI C と混在していることが非常に多いのに対して (可能であるため)。

Java には優れた単体テストの可能性があり、すべてが同じ方向を向いている大規模なコミュニティがあります。

より多くの「機能」を持つことは、言語をより良くするものではありません。悪化させる可能性はあると思います。

結局、一方の言語をもう一方の「前」に置くことは役に立ちません。ジョブに最適なツールを選択します。言語としての Java はそのままで十分だと思います。ただし、C++ では、Spring のポートなど、より優れたライブラリを使用できます。

java - Java++ は必要ですか?

19 に答える 19

Related

Reference