なぜ他のJVM Lisp：Kawa、Armed Bear、またはSISCに対してClojureを使用するのですか？
Clojureがシーンに到着する前に、JVMにはすでに3つのLispがありました： Kawa 、 Armed Bear および [〜＃〜] sisc [〜＃〜] 。
それらのLispによって残された Clojure 埋めるギャップは何ですか？
Kawa、ABCL、およびSISCは、非常に長い既存の言語の再実装です。何らかの理由でJVMで標準のSchemeまたは標準のCommon LISPを使用したい場合は、これらは優れています。
Clojureはnew言語です。 gapには入りません。それは全く新しい可能性を追加します。それは純粋に機能的なアプローチを支持します。SchemeとCLはどちらもマルチパラダイムです。 Clojureは、さまざまなFP言語（ML、Haskell）の設計から多くを借用しています。
そして、はい、他のLispに同時実行サポートを追加することができますが、それは完全にポイントを逃しています。 Clojureは最初から並行言語として設計されました。 Clojureで並行プログラムを書くのは簡単です-非関数型言語のようにロケットサイエンスではないためです（Scheme、CLは除外されません）。このように見てください：
Cを使用すると、デフォルトで高速プログラムを作成できると言われています。
まあ、Clojureでは、デフォルトで並行プログラムを作成できます。
「Clojureは、下位互換性によって制約されないLISPです」（ClojureのWebサイトにあります）。新たなスタートです。それは進歩です。 LISP/Schemeを強力にするが、Java platform。
Clojureは常に最新のClojureです。他の言語がJVMに移植されている場合、JVMバージョンは常に追いついてきます。 Javaプラットフォームが必要ない場合は、なぜ別の方式よりもSISCを使用するのですか？必要な場合は、専用に設計された1つのLISP（Clojure）を使用しないのはなぜですか？
並行性を考慮して設計されています。
私が思いつくことができる最も簡単な答えは、ClojureはCommon-LISPではないということです。 Clojureは他のLispの履歴に制約されていません。これは、JVMのnew言語builtです。
私はそれらに気づかなかっただけでした。これはClojureにとって重大な利点です（私が見つけた十分なノイズを人々が作り出したこと）。 Clojureがあなたがリストしたもので私が見なかった最大のものは Software Transactional Memory です。
Clojureは、他の言語のレイヤーではなく、JVM用にも設計されているため、相互運用を行う必要があるときに他の人が想像するのは、もう少し「Java-y」です。
Clojure.orgの理論的根拠ページには、
なぜさらに別のプログラミング言語を書いたのですか？基本的に私が欲しかったので：
- LISP
- 関数型プログラミング
- 確立されたプラットフォームとの共生
- 並行性のために設計
そして、それを見つけることができませんでした。
あなたが言及した3つの言語（Kawa、ABCL、SISC）はこれらの要件を満たしていますか？彼らです：
- Lisp（CLまたはScheme方言）✓
- 関数型プログラミング用✓
- 確立されたプラットフォーム（JVM）との共生✓
設計されていません（STM）同時実行用です。ただし、公平で完全なものにするために、CLについて、まだ言及されていないSTMライブラリが少なくとも2つあります。
- [〜＃〜] stmx [〜＃〜]
- ABCLでの作業をテストしました。現在開発中です。
- CL-STM
- デッド？最後の変更は2007年でした。
うーん...では、なぜ新しいLispを作成するのですか？これらは主にライブラリであるためです。 clojure.orgの論拠ページは続く（強調が追加されている）：
標準的なLisp（Common LISP and Scheme）についてはどうですか？
- 標準化後の革新が遅い/ない
- コアデータ構造は変更可能であり、拡張可能ではありません
- 仕様に同時実行性はありません
- JVMにはすでに優れた実装が存在します（ABCL、Kawa、SISCなど）
- 標準Lispは独自のプラットフォームです
他の人が述べたように、これは言語同時実行設計の問題です。
さらに、なぜJVMに立ち寄るのですか？ Clojure CLRサポートは現在開発中です。
これらは、私の観点から、それが埋める2つのギャップです。必要に応じてClojureを使用してください。 Clojureがマップから落ちても、スキルを失う心配はありません。あなたのLISPスキル、より重要なのはあなたの考え方は、他のLISP方言にも引き継がれます。
私が皮肉であるならば、それはClojureが より良いウェブサイト とセクシーな名前を持っているからだと思います。
また、Clojureは1人で実装する比較的新しい言語であり、優れたマーケティングスキルと多くのエネルギーを備えています。彼は多くの時間と誇大広告をclojureに投資しています...時々、誇大広告はそれが最新の最大のものであることを十分な人々に納得させることができれば、実際にそれを作るために十分なサポートと勢いを得ることができるという点で自己実現的な予言です作業。
Kawaなどの実装者はそれほど問題になっていないので、彼らの製品を宣伝していません。その上、誇大広告には何がありますか？ 「素晴らしい言語を持っている..それはLISPと呼ばれている」それはより難しいマーケティング売りです。
Javaはこの典型的な例です。非常に深刻な欠陥がありましたが、市場に出されて宣伝されていたため、ハードウェア/ソフトウェアベンダーからのサポートを意味する勢いがかなりありました。ツールのプロデューサー、業界別の投資など。いずれにしても、プログラミングは嫌いですが、ある程度の成功を収めています。
Clojureの利点は、そこにあるすべてのJavaライブラリ/コード）へのアクセスと、JVMに基づいているためマルチスレッドのサポートを提供することです。また、並行性を考慮して設計されています、一般的にはLISPに組み込まれていないものですが、マッピングプリミティブがあるため、同時実行性を適切にサポートするLISPを設計することはおそらく難しくありません。
そうは言っても、私はClojureを試してみたところ、Javaに接続されたものに付随する構文とお尻の要素の痛みを嫌っていました。
Clojureは「LISP」であり、すでに知っているLISPではありません。過去数日間、資料を読んだりビデオを見たりしてきました。とても感動しました。その前提は、（不変データに基づく）関数型プログラムが同時実行性を管理する最良の方法であることです。 Clojureは、JVMに基づいたLISPのようなシステムを実装して提供します。
もう1つ答える必要はありません（そして、この答えに投票することは期待していません）が、他のいくつかの答えに対するいくつかの小さな拡張機能があります。
新しいほど良いとは限りません。新しくて不十分な設計は良くない、新しくて保守されていないは良くない、そしてより大きな（または少なくとも成長している）ユーザーコミュニティなしで新しくなることは良くありません。 （新しい言語は定期的に出てきますが、それらのほとんどは廃用のために道端に落ちます。）
Common LISPが大好きです。その美しさの一部は、いくつかの互換性のない方言への後方互換性を目標として委員会によって設計されたという事実に由来する、その奇妙さです。
私はスキームが大好きです。美しくエレガントな言語です。それにもかかわらず、その発展は委員会に依存しており、おそらくそれは時々それを遅くしている。いずれにしても、その目標はClojureの目標とは異なります。
一般的なLISPとSchemeには、末尾再帰など、JVMの効率にあまり適していない強調事項があります。 Clojureは最初からJVMに適切にマッピングし、Javaと（かなり）相互運用できるように設計されています。 （ClojurescriptとCLR方言がどういう意味かはわかりません。）
Clojureが最初は1人のRich Hickeyによって開発され、小さなチームとともに彼によって制御されていたという事実は、委員会によって制御された言語よりも優れているとは限りません。その一人が悪い決定をしたならば、Clojureは良い言語ではないでしょう。
ただし、これが重要なポイントです：Hickeyはよく考えられたエレガントな言語を設計し、最初から体系的に関連する一連の関数を組み込んで、少し。これは、基本的なJVM相互運用機能だけでなく、その他の言語にも当てはまります。 Clojureを制御する人々は、これまでのところ、言語の目標に固執することに厳格です。
これは、私がClojureで気に入っている点の大部分です。全体としても、細部においても、よく設計されています。つまり、慣れてきたら、プログラミングするのは楽しいことです。
ClojureがSchemeの優雅さを備えたCommon LISPの力を持っていると言うのは、ほんの少しの過大評価（または過小評価？）でしょう。 Common LISPには、言語に組み込む必要のあるものがたくさんありますが、それは混乱します（私は愛を込めてそれを言います）。そして、言語にあるもの以上のものを必要とする場合、異なるトレードオフの互換性のないライブラリがいくつかある場合があります。利用可能なライブラリがありますが、設計によるスキームは小さいです。 Clojureには、多かれ少なかれ言語の一部である標準ライブラリ（CLとは異なります）の増大する本体があります。これの良い例は、core.matrixプロジェクトです。このプロジェクトは、いくつかの異なるマトリックス実装への共通インターフェースを提供します。これは重要です。たとえば、小さな行列を時々使用する場合や、巨大な行列を広範囲に使用する場合に最適なさまざまな行列の実装があるためです。
これは、ClojureがCommon LISPまたはSchemeよりも優れていることを意味するものではありません。そうではありません。 3つの言語にはそれぞれ異なる長所があります。
それは新しい！つまり、従来のLISPコミュニティはよく、伝統的であるため、多くの古いlispersがそれを使用することはありませんが、以前のLISP経験のない人々も意味します新しいものとしてピックアップします。
Imho、Clojureは古いLispにとってRubyはSmalltalkにとってはそうでした。必ずしも優れているわけではありませんが、十分です。そして、決定的に、それは勢いがあり、 Rubyかつてそうだったように、上昇。