68

Clojureが現場に到着する前に、JVMにはすでに3つのLispがありました。Kawa、Armed Bear、SISCです。

それらのLispによって残されたClojureはどのようなギャップを埋めますか？

4

11 に答える 11

34

  1. 「Clojureは下位互換性に制約されないLispです」（ClojureのWebサイトからのものです）。新たなスタートです。それは進歩です。Lisp / Schemeを強力にするアイデアを使用しますが、Javaプラットフォームの周りでそれらを再考します。

  2. Clojureは常に最新のClojureになります。他の言語がJVMに移植されている場合、JVMバージョンは常に追いつく可能性があります。Javaプラットフォームが必要ない場合、なぜ別のスキームよりもSISCを使用するのですか？もしそうなら、それのために特別に設計された1つのLisp（Clojure）を使ってみませんか？

  3. 並行性を念頭に置いて設計されています。

于 2009-09-11T21:36:10.503 に答える
14

私が思いつく最も簡単な答えは、Clojure は Common-Lisp ではないということです。Clojure は、他の Lisp の歴史に縛られることはありません。これは、JVM 用に構築された新しい言語です。

于 2009-09-14T03:05:16.637 に答える
11

私は単にそれらに気づいていませんでした。これはClojureにとって重大な利点です（人々が私が見つけた十分な音を立てたこと）。あなたがリストしたもので私が見なかったClojureの最大のものは、ソフトウェアトランザクショナルメモリです。

Clojureは、別の言語のレイヤーではなく、JVM用にも設計されているため、相互運用が必要な場合に他の言語がそうであると想像するのは、もう少し「Java-y」です。

于 2009-09-11T21:36:47.703 に答える
11

私が皮肉を言うなら、それは Clojure のWeb サイトがより優れていて、よりセクシーな名前になっているからだと言えます。

于 2009-09-11T21:47:03.617 に答える
10

clojure.org の理論的根拠のページには、次のように記載されています。

なぜ私はさらに別のプログラミング言語を書いたのですか? 基本的に私が欲しかったので：

  • Lisp
  • 関数型プログラミング用
  • 確立されたプラットフォームとの共生
  • 同時実行のために設計された

見つけられませんでした。

あなたが言及した 3 つの言語 (Kawa、ABCL、SISC) はこれらの要件を満たしていますか? 彼らです：

  • Lisp (CL 方言または Scheme 方言) ✓</li>
  • 関数型プログラミング用 ✓</li>
  • 確立されたプラットフォーム (JVM) との共生 ✓</li>

ただし、(STM) 同時実行用には設計されていません。ただし、公平かつ完全にするために、まだ言及されていないCL用に見つけたSTMライブラリが少なくとも2つあります。

  1. STMX
    • ABCL で動作テスト済み。活発な開発中。
  2. CL-STM
    • 死？最後の変更は 2007 年でした。

うーん... では、なぜ新しい Lisp を作成するのでしょうか? 主な理由は、これらがライブラリであるためです。clojure.org の理論的根拠のページは続きます (強調を追加):

標準的な Lisp (Common Lisp と Scheme) はどうですか?

  • 標準化後のイノベーションが遅い/ない
  • コアデータ構造は変更可能、拡張不可
  • 仕様に並行性がない
  • JVM の適切な実装が既に存在します (ABCL、Kawa、SISC など)。
  • Standard Lisp は独自のプラットフォームです

他の人が言及したように、これは言語の同時実行設計の問題です。

さらに、なぜ JVM で止まるのですか? Clojure CLR のサポートは活発に開発中です。

私の観点からすると、これらはそれが埋める2つのギャップです。必要に応じて Clojure を使用する必要があります。Clojure がマップから消えても、スキルが失われる心配はありません。あなたの Lisp スキル、さらに重要なことはあなたの考え方は、他の Lisp 方言に引き継がれます。

于 2014-09-13T22:03:41.677 に答える
5

Clojure の利点は、JVM に基づいているため、そこにあるすべての Java ライブラリ/コードにアクセスでき、マルチスレッドをサポートできることです。さらに、それは並行性を念頭に置いて設計されており、一般的には Lisp には設計されていませんが、マッピング プリミティブのために、並行性を適切にサポートする Lisp を設計することはおそらく難しくありません。

そうは言っても、私はClojureを試してみましたが、構文と、Javaに接続されたものすべてに付随するように見えるバットファクターの痛みが嫌いでした.

于 2009-09-11T21:40:31.287 に答える
2

Clojure は「a Lisp」であり、あなたがすでに知っている Lisp ではありません。ここ数日、資料を読んだり、ビデオを見たりして、感銘を受けました。その前提は、機能的なプログラム (不変データに基づく) が並行性を管理する最良の方法であるということです。Clojure は、JVM に基づく Lisp に似たシステムを実装して、それを提供します。

于 2009-09-13T19:53:47.863 に答える
1

もう 1 つの回答を用意する必要はありません (そして、これに対する投票は期待していません)。

新しいものほど良いとは限りません。新しくて設計が不十分なものはよくありません。新しくて保守されていないものは良くありません。また、ユーザ コミュニティが大きくない (または少なくとも成長している) ものは良くありません。(新しい言語は定期的に出てきますが、ほとんどの言語は使われなくなってしまいます。)

Common Lisp が大好きです。その美しさの一部は、いくつかの互換性のない方言への下位互換性を目的として委員会によって設計されたという事実に由来する、その奇抜さです。

スキームが大好きです。美しくエレガントな言語です。それにもかかわらず、その開発は委員会に依存しており、おそらくそれが時々それを遅らせてきました. いずれにせよ、その目標は Clojure のものとは異なります。

Common Lisp と Scheme には、JVM での効率にはあまり適していない末尾再帰などの重点があります。Clojure は、最初から JVM に適切にマッピングされ、Java と (かなり) 相互運用できるように設計されています。(Clojurescript と CLR の方言については、それが何を意味するのかわかりません。)

Clojure が当初 Rich Hickey という 1 人の人物によって開発され、彼によって小さなチームと共に管理されているという事実は、委員会によって管理される言語よりも優れているとは限りません。その 1 人が間違った決定を下した場合、Clojure は良い言語とは言えません。

ただし、これは重要なポイントです。Hickey は、よく考え抜かれたエレガントな言語を設計し、最初から体系的に関連する一連の関数を含んでいたため、少量で多くのことを簡単に行うことができました。これは、言語の残りの部分だけでなく、基本的な JVM 相互運用にも当てはまります。Clojure を管理している人々は、これまでのところ、言語の目標に固執することに厳格であり続けています。

これは、私が Clojure について気に入っている大きな部分です。全体としても細部においても、よく設計されています。つまり、慣れればプログラムを作成するのは楽しいということです。

Clojure が、Scheme のエレガンスを備えた Common Lisp の力を備えていると言うのは、少し誇張 (または控えめな表現?) にすぎません。Common Lisp には必要なものがたくさん言語に組み込まれていますが、それはごちゃごちゃしています (愛情を込めて言います)。言語にあるもの以上のものが必要な場合、異なるトレードオフを伴ういくつかの互換性のないライブラリが存在することがあります。利用可能なライブラリはありますが、設計によるスキームは小さいです。Clojure には標準の本体が増えています多かれ少なかれ言語の一部であるライブラリ (CL とは異なります)。これの良い例は、いくつかの異なるマトリックス実装に共通のインターフェースを提供する core.matrix プロジェクトです。これは重要です。たとえば、小さな行列をときどき使用したり、巨大な行列を広範囲に使用したりするのに最適なさまざまな行列の実装があるためです。

これは、Clojure が Common Lisp や Scheme よりも優れていると言っているわけではありません。そうではありません。3つの言語にはそれぞれ異なる美徳があります。

于 2015-06-05T04:49:11.573 に答える