顧客と利害関係者は、JVMなどの業界標準プラットフォームのパフォーマンス、セキュリティ、安定性に対して多大な投資を行い、それらに満足しています。Java開発者は、動的言語の簡潔さ、柔軟性、生産性を羨むかもしれませんが、顧客承認済みのインフラストラクチャでの実行、既存のコードベースとライブラリへのアクセス、パフォーマンスについて懸念があります。さらに、ネイティブスレッドとロックを使用した並行処理に対処する上で、継続的な問題に直面しています。Clojureはこの文脈における実用的な動的言語設計の試みです。Javaが適している分野で一般目的の言語となることを目指しています。並行プログラミングの未来においては、遍在的で抑制されていない変異は単純に廃止されなければならないという現実を反映しています。
Clojureは、業界標準のオープンなプラットフォームであるJVMを採用し、由緒ある言語であるLispを現代化し、不変の永続データ構造による関数型プログラミングを促進し、ソフトウェアトランザクショナルメモリと非同期エージェントによる組み込みの並行処理サポートを提供することで、その目標を達成します。その結果、堅牢で実用的で高速なものが実現します。
Clojureは状態と同一性に対して独特のアプローチを取っています。
なぜまた新たなプログラミング言語を書いたのか？基本的に、私は欲しかったからです。
Lisp
関数型プログラミングのため
確立されたプラットフォームとの共生関係
並行処理のために設計された
そして、そのような言語が見つからなかったのです。Clojureの背後にあるいくつかの動機となるアイデアの概要を以下に示します。
しばしば模倣/略奪され、未だに複製されていない
ラムダ計算は極めて小さなコアを生み出す
構文はほとんどない
コード・イズ・データと構文的抽象化というコアな利点は依然として存在する
標準的なLisp（Common LispとScheme）はどうだろうか？
標準化後、遅々とした/革新がない
コアデータ構造は可変であり、拡張可能ではない
仕様に並行処理がない
JVM用の優れた実装は既に存在する（ABCL、Kawa、SISCなど）
標準的なLispはそれ自体がプラットフォームである
Clojureは、下位互換性によって制約されていないLispである
コード・イズ・データのパラダイムをマップとベクターに拡張する
不変性をデフォルトとする
コアデータ構造は拡張可能な抽象化である
プラットフォーム（JVM）を採用する
不変データ＋第一級関数
Lispでは常に規律/慣習によって行うことができた
しかし、データ構造が*変更可能*である場合、変更されないとは想定するのは危険である
従来のLispでは、リストデータ構造だけが構造的に再帰的である
純粋関数型言語は、強い静的型付けになりがちである
すべての人、またはすべてのタスクに適しているわけではない
Clojureは動的な重点を置いた関数型言語である
すべてのデータ構造が不変で永続的で、再帰をサポートする
異種コレクション、戻り値の型
動的多態性
OSではなくVMは、将来のプラットフォームであり、以下を提供する。
型システム
動的強制と安全性
ライブラリ
OSを抽象化する
巨大な機能セット
組み込みとサードパーティ
メモリとその他の資源管理
GCはプラットフォームであり、言語の機能ではない
バイトコード＋JITコンパイル
ハードウェアを抽象化する
言語としてのプラットフォーム対言語＋プラットフォーム
古い方法 - 各言語が独自のランタイムを定義する
GC、バイトコード、型システム、ライブラリなど
新しい方法（JVM、.Net）
言語に依存しない共通ランタイム
プラットフォーム用に構築された言語対プラットフォームに移植された言語
多くの新しい言語はまだ「言語としてのプラットフォーム」アプローチを取っている
移植されると、プラットフォーム上のプラットフォームの問題が発生する
メモリ管理、型システム、スレッドの問題
ライブラリの重複
元の言語がCに基づいている場合、Cで記述された一部の拡張ライブラリは移植されない
プラットフォームはクライアントによって決定される
「JVMで実行する必要がある」または.Net対「UnixまたはWindowsで実行する必要がある」
JVMは確立された実績と信頼レベルを持っている
現在ではオープンソースでもある
他のコードとの相互運用が必要
Cリンケージは現在では不十分である
Java/JVMは言語＋プラットフォームである
元々の話ではないが、JVM用の他の言語は常に存在し、現在はSunによって採用されている
Javaは冗長で、表現力が不十分な場合がある
第一級関数の欠如、型推論の欠如など
Javaを呼び出して/消費する機能は重要である
Clojureは言語であり、JVMはプラットフォームである
シミュレーションから生まれ、今ではすべてに使用されている。不適切な場合でも。
(慣習的な)他のものに対するサポートがないため、Java/C#ではあらゆる状況で推奨されている
可変状態を持つオブジェクトは、新しいスパゲッティコードである
理解、テスト、推論が難しい
並行処理の災害
継承は多態性を行う唯一の方法ではない
「10個の関数が10個のデータ構造を操作するよりも、100個の関数が1つのデータ構造を操作する方が良い。」 - アラン・J・パーリス
Clojureは、インターフェースで表される不変オブジェクトとしてデータ構造をモデル化し、それ以外の独自のクラスシステムは提供しない。
少数の主要なデータ構造（seq、map、vector、set）で定義された多くの関数。
JavaはJavaで記述し、ClojureからJavaを消費して拡張する。
switch文、構造的マッチングなどは、脆いシステムを生み出す
多態性は、拡張可能で柔軟なシステムを生み出す
Clojureのマルチメソッドは、多態性をOOと型から切り離す
複数の分類体系をサポートする
静的、動的、または外部のプロパティ、メタデータなどによってディスパッチする
不変性により、多くの問題が解決する
スレッド間で自由に共有する
しかし、シミュレーションや外部世界へのプログラム内プロキシでは、状態の変更は現実である
ロックは何度も正しく行うのが難しい
Clojureのソフトウェアトランザクショナルメモリとエージェントシステムは、難しい部分を処理する
要するに、Clojureは、強力な並行処理サポートを備えたJVM向けの関数型Lispとして独自のニッチを占めていると考えています。機能の一部を確認するか、Clojureを使い始めることができます。
