Clojure は Java 仮想マシン (JVM) で実行するように設計されているため、次のステートメントが理解できません。
Clojure は主にサーバー側の言語として誕生しましたが、ClojureScript の出現は、コア開発者がそれを唯一の目的とは見なしていないことを示しています。
私は Lisp 言語と Clojure に興味がありますが、Java にはあまり詳しくありません。私が取り組んできたほとんどの Web サーバーは、Ruby、PHP、Perl などの標準的なサーバー側言語を備えた従来の Apache バリアントですが、私のホスティング環境で Java がデフォルトでインストールされたサーバー言語になっているのを見たことがありません。声明？
次に、JVM は通常、Mac や Windows などのクライアント オペレーティング システムで実行されますね。Sun は、世界中に何十億もの JVM があると言っていますが、これは明らかにサーバーのことではありません。
要点の 1 つは、Clojure には、JVM、JavaScript/ECMAScript などの特定のランタイム環境に適用すると、強力な言語を生み出すいくつかの重要な哲学と実践があるということです。これらの哲学には以下が含まれます。
シンプルさ:明確なパーツを分離する能力。すべての clojure バリアントは、コードとデータの分離を提供します。これには、データを生成したコードとは無関係にデータを処理する機能が含まれます。直接的には、これは複合および単純な (非複合) データ構造を読み書きする機能が言語に組み込まれていることです。
不変のデータ構造: すべての Clojure バリアントには、非常に大きなデータ構造の新しいバージョンを効率的に作成できるデータ構造があり、古いデータはそのまま残ります。大きなデータ構造を複数のスレッドに渡す場合、それらはデータの異なる「フォーク」で動作するため、ロックする必要はありません。これはすべてコピーせずに (構造共有を使用して) 行われ、効率的です。
Identity、State、および Timeの明示的な処理: すべての Clojure バリアントは、言語に組み込まれた一連のイベントの明示的な処理を提供します。これは、プラットフォームに応じてバリアント間で異なります。たとえば、出力として JavaScript を生成する ClojureScript には、調整された同期更新の場所がありません。これは、JavaScript にはスレッドが 1 つしかなく、残りのすべての型があるためです。
他にもたくさんあり、Clojure Philosophy Pageで見つけることができます。また、大部分ではないにしても、世界の Web アプリケーションの非常に大きな部分がほぼ完全に Java で書かれていることにも言及する価値があります。多くの人は、Java が好みの言語でなくても、Clojure がこの世界と対話する方法を提供していることに気付きます。
Java は、Ruby や Perl (実際には PHP ではありません) とまったく同じくらいサーバー側の言語です。Java は、Web アプリケーションや SOA サービスなどのサーバー アプリケーションを作成するために頻繁に使用される汎用言語です。Java が「デフォルトでインストール」されているかどうかにかかわらず、Java サーバーの通常のホストである Unix マシンにインストールするのは通常簡単です。
JVM は、理論的にはどのプラットフォームでも実行できます。裸の x86 ハードウェアで実行される JVM があり、Blu-Ray プレーヤーには JVM が組み込まれています。Sun は当初、Java がリッチ クライアント アプリケーションの未来であると考えていましたが、代わりに、クライアントがさまざまな API を介してアクセスする Web サイトやその他のサービスを強化するために、Java がはるかに広く使用されていることがわかりました。
言語によってserver-side、作成者は Web サーバーだけを意味するわけではありません。単純なファイルのアップロードからビッグデータ処理まで、サーバー上で実行されているサービスのスタック全体が含まれる場合があり、Web 経由でクライアントに提供されます。
Second, JVMs are typically run on client operating systems like Mac or Windows, are they not?
JVM は、開発プラットフォームであると同時にデプロイメント プラットフォームでもあります。JVM を介してデプロイされた多数の Web スケール アプリケーションがあります。スタックに Java ベースのサービスが含まれている場合、サーバーに JVM をインストールすることは非常に一般的です。
この声明の著者は、Clojure はサーバー側の言語として想定されていたが、クライアントでも Clojure を使用できるという要求がある場合には十分な力を持っていることを意味しています。
ただし、重要な違いは、Clojure が実際にブラウザーで実行されているわけではないということです。ClojureScript は、クライアント側 (つまり、ブラウザー) の Clojure コードを JavaScript にコンパイルするツールです。これは、Ruby スタイルのコードを JavaScript にコンパイルする CoffeeScript に似ています。
したがって、ClojureScript は、サーバー側の Clojure のパワーと簡潔さを愛する人々がクライアント側の Clojure をブラウザーで記述できるようにする構文糖衣にすぎません。しかし、最終的には、そのクライアント・サイドの Clojure は実際には Clojure ではなく、JavaScript です。
したがって、ClojureScript に関して言えば、JVM は関係ありません。
私は Clojure の歴史についてはあまり知りませんが、Hickey らが最初に何を推し進めたとしても、Clojure がしばらくの間汎用言語として意図されていたことは明らかです。それを開発したい。Clojure は既存の Java ライブラリへの簡単なアクセスをサポートし、標準の Java スタイルの jar ファイルを作成できるため、サーバーだけでなく他の場所でも非常に重要な利点があります。したがって、「ClojureScript の出現は、コア開発者が [サーバー側アプリケーション] を唯一の目的と見なしていないことを示している」理由に対する私の答えは、そのようなデモンストレーションは必要なかったということです。