5

[これは最新技術に関する経験的な質問です。私は、Java が JVM で動作する動的言語よりも優れているか劣っているのかを尋ねているわけではありません。]

パフォーマンスが主な決定要因である場合を除いて、企業/開発者は、Groovy、JRuby、または Jython よりも Java を進んで選択しますか?

編集:答えが「はい」の場合、なぜですか?

個人的なメモ:私が尋ねている理由は、私は専門的な仕事の一部を Ruby (今のところ JRuby ではありません) で行っていますが、個人的なプロジェクトでは Java を使用しているためです。私は重要なアプリを Groovy で作成してきましたが、Java の方が好きですが、それを乗り越えてすべてを Groovy で行うべきかどうか疑問に思っています。Java が好きなのは、静的型付けによって時間が節約され、リファクタリングが容易になるからです。(いいえ、私は Scala に詳しくありません。) しかし、この非常に経験に基づくトピックに関するプログラミングの質問は、私の決定に役立つかもしれないと感じています。

4

6 に答える 6

8

静的型付けは依然として重要です。

何度も何度も議論されており、動的アプローチの支持者は、動的型付けがもたらす問題は、十分な単体テストで軽減(または排除)できると述べています。

この議論が正しいかどうかについては議論したくないので、この答えは正しいと思います。

その場合でも問題が1つあります。それは、多くのショップが十分な数の高品質の単体テストを作成するための手順/ノウハウ/ルール/管理を持っていないことです。

また、単体テストなしの動的型付けコードと単体テストなしの静的型付けコードのどちらかを選択する必要がある場合は、毎日静的型付けコードを選択します。

ダブルディスパッチにも同様の問題があります。

Groovyでは、メソッド呼び出しは実行時の引数の実際の型に基づいてディスパッチされます(静的型は不明であるか、ほとんどObjectの場合、静的型が不明であるため、ほとんど必要です)。これは、拡張可能なクラス階層に直面したときに、コードの任意の時点でどのメソッドが呼び出されたかを知るための信頼できる方法がないことを意味します。

ほとんどの場合、シグネチャを使用してメソッドを呼び出すコードは、実行時foo(String)に突然呼び出されるfoo(Integer)foo(SomethingElseEntirely)、引数の実際のタイプのみに依存する可能性があります。呼び出されるメソッドの正確なシグネチャはコンパイル時に決定されるため、発生する可能性のないJava言語では。

他の「動的」言語機能と同様に、ダブルディスパッチは非常に便利なツールである場合があり、その欠如によりJavaで醜い構造が生成される可能性がありますが、コードの読み取り、理解、推論がさらに困難になるというコストがかかります。 。

于 2010-05-10T12:30:25.607 に答える
8

静的に型付けされていない言語は、メンテナンスの意味でうまく「スケーリング」しません。数万行までのコードを保守できます。それを過ぎると、保守、リファクタリング、または更新にさらに労力がかかります。これは、非静的型付き言語、Perl、Python、Groovy、Ruby などのいずれにも当てはまります。50 万行の Python コードと、C/C++/Java の同じ行数のコードを操作するためのツールはまったく違います。そこにいない。Python のコード行数は、同等の Java プログラムの約 1/3 から 1/5 です。したがって、これがリンゴとオレンジになることは決してありませんが、非静的言語のコードの行数がメンテナンスの収益を減少させるカットオフ ポイントがあります。また、ソフトウェア プロジェクトの真のコストは常にメンテナンスにかかっていることは誰もが知っています。

于 2010-05-10T15:15:17.683 に答える
5

はい、もちろんです。

なぜ企業はまだ「積極的に」Javaを使用しているのですか?

企業は本質的に保守的だからです。彼らはクールであるか、あるいはグルーヴィーでさえあるので、彼らはテクノロジーを変えません。慎重な理由がある場合、彼らはしぶしぶ変化します。アーリーアダプターは、アーリーアダプターであることに非常に重いペナルティを支払います。

編集:これは、「変化への抵抗以外に変化を避ける理由はない」のように、蔑称的な意味での「慣性」ではなく、慎重さの意味でです。確かに良いものができるまで、企業が機能しているものを放棄しないのは正しいことです。

そして、「クールだから開発者を幸せにする」という意味ではなく、組織の開発を推進するビジネス要件をより迅速かつ確実に満たすという意味で。

Javaは以下を提供します:

  1. 訓練を受けた経験豊富な開発者の大規模な基盤。それほど長く存在していない言語を選択せず​​に、ソフトウェア開発を上手に行うことができる人を見つけることは十分に困難です。そして、新しい言語で人々を訓練することは、時間とお金の両方で費用がかかります。

  2. ブランド名の認知と、成功裏に完了したプロジェクトの簡単に証明された実績。これは嘲笑するものではありません。私が上級管理職に、彼らが聞いたことのないグルーヴィーな新しい言語でプロジェクトを開始していると言った場合、私は彼らにそれについて教育する必要があり、彼らはそれをリスクとして評価します。「確立された」言語であれば、そのステップをスキップできます。

  3. 確立された成熟したサポートツール、およびサードパーティのサポート。

これらの利点は、Javaとリストだけでなく、老舗の言語と新しい言語を比較することで得られます。いつの日か、Groovyらが確立された言語になることを期待しています。そして、より新しく、より輝く言語について同じ質問をする人々がいるでしょう。これがサイクルです。それは私がビジネスに携わってきたよりも長い間そうだった方法です。

于 2010-05-10T14:42:17.690 に答える
4

パフォーマンスが主な決定要因である場合を除いて、企業/開発者は、Groovy、JRuby、または JPython よりも Java を進んで選択しますか?

はい、主な理由は、開発者または会社の慣性によるものだと思います。

  • 企業: Java への既存の投資 (スタッフのスキルとインフラストラクチャの観点から)、変更のリスクがメリットを上回ると認識されている
  • 開発者: Java の仕事はたくさんあるのに、わざわざ別の言語を学ぶ必要はありません。

利用可能なリソースの不足もおそらく別の理由ですが、これはニワトリが先か卵が先かの問題 (またはメキシコのスタンドオフ、自己実現的予言など) のようなものです。Groovy や Jython などに注目している企業はたくさんあると思いますが、思い切って採用する前に、それらがより広く採用されるのを待っています。明らかに、採用自体を延期することで、このリソース不足の問題を悪化させています。

個人的な余談

私は昨年、Groovy/Grails 開発者として働いていました。私は最近転職し、現在は Java 1.4 開発者として働いていますが、(Groovy プログラミングと比較して) 錆びたスプーンで目をえぐり出すのと同じくらい楽しい作業です。

静的型付けは、コンパイル時のチェックや FindBugs などのコード分析ツールを容易にするという点で優れていますが、Java を作成するときに最も単純なタスクを実行するために必要な大量の (ボイラープレート) コードを補う方法はありません (特に、 1.5 より前のバージョンを使用している場合)。

于 2010-05-10T12:14:48.603 に答える
2

私の会社で何が起こっているのかをお話しすることができます。現在のアプリケーションはJavaで実行されていますが、grails / groovyへの移行を開始しており、これが次世代の製品のプラットフォームになる可能性があります。

于 2010-05-10T13:38:39.323 に答える
1

あなたは経験的な質問をしているので、私は経験的な答えを探していると思います:

パフォーマンスが主な決定要因である場合を除いて、企業/開発者は依然としてGroovy、JRuby、またはJPythonよりもJavaを積極的に選択していますか?

はい。

他に言うことはないと思います。

于 2010-05-10T11:58:30.350 に答える