11

今後3年間は、非常に特殊なサードパーティAPIを使用してJVM（プロジェクト要件）を操作する必要があります。彼らはJavaを望んでいますが、私にはJavaから離れる余裕があります。.NET Frameworkに戻って、OCamlを完全に気に入って、F＃でコードを開発できるようになることを望んでいました。.NETの開発は、お客様によって打撃を受けました。ノーゴーです。

私は、ScalaとClojureのどちらの言語が私にさらにアピールするかを理解しようとして、プログラミングブログ/フォーラムを見て、読んで、突っついています。それらは最大のコミュニティ/ファンベースを持っているようです。ML言語の経験があると、ScalaをMLと比較する人がたくさんいます。ただし、この比較を行う場合、実際の否定論者がいます。ScalaがMLに非常に近い場合、私の生産性と学習曲線はこの切り替えを行うのに役立ちます。

インターネットは誤った情報でいっぱいで、私がそのようなことに苦しんでいるのではないかと思います。私はLispの構文が好きではありません（私を傷つけないでください！）が、Scalaに私が読んでいる疣贅がある場合（不十分なIDEサポート、フラックスユニットテストフレームワーク、パフォーマンスの問題）、Clojureの方が優れているかどうか疑問に思いますオプション。関数をファーストクラスのオブジェクトとして使用し、並行性の問題を最小限に抑えながら、生産性を高めたいと考えています。

とにかく、私がインターネットに多くの時間を費やして仕事をしない前に...私はJVMで立ち往生していて、Javaにうんざりしていて、どこに行けばいいのだろうか？

4

11 に答える 11

25

私の意見では、Clojure と Scala はどちらも優れた IDE サポートを提供していません (それが本当に重要な場合)。とはいえ、これが私の読書と経験から収集できるものです。

Scalaの長所

  • より静的な型付けにより、Clojure よりも高速
  • ML に近い(構文、型指向プログラミング)
  • より大きな標準 API (Clojure の API は、公開する前に最適なイディオムを確実に見つけたいため、非常にゆっくりと成長します。ただし、Clojure には準公式の補助 API がまだあります)
  • 典型的な Java ツールセットとのより良い統合プラクティス(Clojure はまだいくつかの選択を行っているため、この点に関してはまだ確立されていません)
  • Clojure よりも古い(ただし、Clojure は非常に古く実績のあるコア: Lisp の上に構築されている)
  • 人々はそれが主流になる可能性があると言っていますが、Clojure についてはそうではありません。

Clojureの長所

  • MVCC ベースの STMおよびその他の同時実行メカニズムによる、信じられないほど簡単で高速かつ適切な同時実行
  • デフォルトでの不変性は、最初に正しいことを行うのに役立ちます
  • より安定した標準 API
    • 状況が変わっても、通常は既存のコードを書き直す必要はありません
    • (Scala のコレクションは 2.8 用に再作成されています)
    • (Scala の Actors の実装には再考と書き直しが必要だというのはよく知られていることもどこかで読んだことがあります。)
  • 習得しやすい(小さな言語、(非常にクリーンな) Lisp である)
  • さまざまなことを学ぶことで成長する機会
  • Clojure のパフォーマンスは時間の経過とともに向上します。コンパイラにはまだ最適化の余地があります
  • Scala の Java への結合は、Clojure の結合 (Scala と Java の静的型システム間の相互作用) よりも制限を感じます。Clojure についても同じことが言えます (オブジェクト指向のサポートは 1:1 ではありませんが、これに対するサポートはすぐに改善されます)。
  • Rich Hickey は、Clojure を、数十年後に他の言語に採用される技術的な優れた機能を持つ立場に置くという選択をする才能を持っています。そして、彼はそれらを説明する才能も持っています。したがって、今日 Clojure でそれらを使用するか、数年後に別の言語で使用するのを待ってください。:)

分散同時実行について

並行処理のニーズが分散されている場合、Terracotta などの上で実行しない限り、Clojure にはまだ何もありません。その場合、Clojure のすべての並行処理機能を使用できます。そうすれば、Scala のアクター (IMO) よりも優れた分散同時実行エクスペリエンスが得られます。

結論

IMO Scala はすべてを実行しようとし、そのほとんどを実行することに成功しています。Clojure は同じことを試みていませんが、Clojure を本当に知っているほとんどの人が他の何かに戻りたくないほど、それが焦点を当てていることは十分であり、成功しています。開示：私の個人的な好みは、もちろんClojureです。私が書いたもので客観的になることができたことを願っています。

于 2009-09-24T19:23:25.600 に答える
10

Groovyを検討しましたか？Scala/Clojure ほど機能的ではないと思いますが、Java** よりもはるかに機能的であることは確かです。一般に、Groovy では、Java で必要なコードの約 50% で同じ作業を行うことができます。

これは、Groovy が構文的に Java に似ており、JDK ライブラリへのシームレスなアクセスを提供するためですが、多くの言語機能 (クロージャー、メタプログラミング、プロパティ) と動的型付けの追加により、Java プログラミングに関連するボイラープレートがほぼすべて排除されます。

** 「正しく動作する」というよりは、「関数型プログラミング」という意味で関数型を意味します

于 2009-09-24T18:12:15.850 に答える
10

Scalaについてあなたが指摘した点に対処します。

  • IDE サポート:

    Scala には、Java と同じレベルまたは IDE サポートがありません。さらに言えば、F# が VS10 で持つべきものと同じレベルまたは IDE サポートもありません。

    とは言っても、Java 以外の JVM での IDE サポートは最高の (おそらく最高?) の 1 つです。現時点では、NetBeans で十分であり、人々は常に IDEA の方が優れていると言っています (伝聞)。ただし、Eclipse プラグインは不安定です。

    しかし、あなたは 3 年の範囲に言及しました。Scala 2.8 がリリースされると、IDE のコンパイラ サポートが提供されるため、Scala の IDE サポートは大幅に強化されるはずです。リリース日は決まっていませんが、今後 6 か月以内、おそらく 3 か月以内になるようです。また、それに合わせて Eclipse プラグインも更新されます。

  • フラックスユニットテストフレームワークでは：

    はい、停滞したり放棄されたりするのではなく、活気に満ち、進化し、十分にサポートされていることを意味しているのであれば. ScalaTest、Specs、および ScalaCheck は最高品質のフレームワークであり、相互に互換性があり、JUnit や JMock などの他の Java フレームワークやライブラリと互換性があります。

    実際、テスト フレームワークは、Scala で何ができるかを示す子ポスターのようなものです。

    編集: Scala は、標準ライブラリ (scala.testing.SUnit) で基本的な単体テストをサポートしています。ただし、多くの優れた、積極的にサポートされている無料の代替手段が登場したことを考えると、これは非推奨となり、Scala 2.8 に同梱されるライブラリには含まれない可能性があります。

  • パフォーマンスの問題:

    他の言語と同じように、お粗末なコードを書くことができるという事実を除けば、私は何も知りません。関数型プログラミングに慣れていない人は、末尾再帰を使用しない、またはリストを連結するなど、効率の悪いことを行うことがよくありますが、Scala が可能にするパラダイム シフトはそれを明らかにします。

    いずれにせよ、Scala コードは Java コードと同じくらいの速さで記述できます (いくつかの今後の機能ではさらに高速になります)。また、関数機能を備えた Scala コードを Java コードとほぼ同じ速度で作成できます。

于 2009-09-24T19:45:14.553 に答える
9

率直に言って、別の仕事に就いてください。

今後3年間、自分のしていることに不快感を覚える場合は、より魅力的な選択肢を探すことを検討する必要があります.

好きな言語を手に入れることができたとしても、あなたがチームの一員である場合 (私はそうだと思います)、チームの他のメンバーはその言語を好まないかもしれません。それらの残りの部分が Java でコーディングされていて、「空白を埋める」プログラミング言語を使用している場合、問題が発生する可能性があります。

結局のところ、それほど悪くはありません。

上司と話して、あなたの気持ちを彼に知らせてください。代替案を探し始め、素敵でプロフェッショナルな「休暇」を取りましょう。

現在の上司と良好な関係を維持できない理由はありません。最終的に彼らが .net 用の新しいプロジェクトを持っている場合は、戻ってくるかもしれません。それについても彼らと話してください。ドアを開けたままにします。

于 2009-09-24T18:31:25.017 に答える
6

それは実際にはゼロサムゲームではありません。すべてを学びましょう。ps: 私はClojure
に 投票します。Clojure が一番楽しいと思います!

于 2009-09-24T19:01:34.940 に答える
5

JVM は、Java よりも代替プログラミング言語としてますます人気が高まっているため、JVM を使用できることは幸運であると考える必要があります。

Java のほかに、 Groovy、Scala、Clojure (JVM 上の Lisp 方言)、JRuby (JVM 上の Ruby)、Jython (JVM 上の Python)、Jaskell (JVM 上の Haskell)、Fan (JVM および.NET CLR) など、他にも多数あり、JVM で実行されるOCaml-Java 、OCaml もあります。

そのため、JVM のプログラミング言語には、純粋に機能的なものから単純なスクリプト言語、高度な OO 言語まで、さまざまな選択肢があります。

于 2009-09-24T19:35:46.150 に答える
3

Scala と Clojure のツール サポートは未熟かもしれませんが、着実に改善されています。

あなたは F# が好きなので、おそらく Scala が最善の策でしょう。私はそれを試してみて、あなた自身の意見を形成すると言います.

于 2009-09-24T18:18:54.777 に答える
2

jRuby を忘れないでください。Java 以外の場合、IDE はオプションであることに注意してください。

あなたは素晴らしい状況にあると思います。実装言語を選択する許可を得ているのは何人ですか? 環境を選択する JVM で使用できるすべてのものを使用すると、それほど制限はありません。

  • あまり冗長でない言語では、優れた IDE サポートは必要ありません。
  • 型宣言のない Ruby のような強力な言語では、IDE はまったく必要ありません。
  • Scala は、verbose-java-blues の問題を解決するために特別に開発されました。
  • 3年間の仕事が並んでいることを幸運だと考えてください:-)
  • Clojure は楽しいかもしれませんし、機能的な同時実行セーフな設計パターンを提供します
于 2009-09-25T03:31:51.173 に答える
0

いや？http://code.google.com/p/noop/ (実験的ですが)

于 2009-09-24T18:11:01.987 に答える
0

ML が好きなら、多かれ少なかれ JVM 用の Haskell 98 であるCALが好きかもしれません。

これは高品質で非常に安定しており、Eclipse で優れた IDE サポートを備えていますが、残念ながら現在は活発な開発が行われていません。

于 2009-09-26T21:01:46.810 に答える
0

IDE のサポートやその他の疑問点に関して言えば、Clojure は Scala に勝るものはありません。また、ML/F# のバックグラウンドを持つ人 (または一般的に厳密に静的に型付けされた FP 言語のバックグラウンドを持つ人) にとっては、Scala が慣れ親しんでいるものにはるかに近いことに間違いなく気付くでしょう。

于 2009-09-24T21:00:39.163 に答える