在 Clojure 出现之前，JVM 已经有了三个 Lisps：Kawa、Armed Bear 和 SISC。
Clojure 填补了那些 Lisps 留下的空白？
【问题讨论】：
Kawa、ABCL 和 SISC 是对已经存在很长时间的现有语言的重新实现。如果出于某种原因您想在 JVM 上使用标准 Scheme 或标准 Common Lisp，它们非常好。
Clojure 是一种新语言。它没有填补空白。它增加了全新的可能性。它支持纯函数式方法——Scheme 和 CL 都是多范式。 Clojure 大量借鉴了各种 FP 语言（ML、Haskell）的设计。
是的，您可以向其他 Lisps 添加并发支持，但这完全没有抓住重点。 Clojure 从一开始就被设计为并发语言。如此之多，以至于在 Clojure 中编写并发程序是微不足道的——而不是像在非函数式语言中那样的火箭科学（不排除方案，CL）。这样看：
人们说 C 默认让你编写快速程序。
嗯，Clojure 默认允许您编写并发程序。
【讨论】：
“Clojure 是一种不受向后兼容性限制的 Lisp”（来自 Clojure 网站）。 这是一个新的开始。是进步。使用使 Lisp/Scheme 强大的想法，但围绕 Java 平台重新思考它们。
Clojure 将始终是最新的 Clojure。对于移植到 JVM 的任何其他语言，JVM 版本可能总是在追赶。如果您不需要 Java 平台，为什么要使用 SISC 而不是另一个方案？如果您这样做，为什么不使用专门为其设计的 Lisp (Clojure)？
在设计时考虑了并发性。
【讨论】：
我能想到的最简单的答案是，Clojure 不是 Common-Lisp。 Clojure 不受其他 Lisp 历史的限制。它是一种新语言为JVM构建。
【讨论】：
我根本不知道这些，这对 Clojure 来说是一个很大的好处（我发现人们制造了足够多的噪音）。 Clojure 的最大功能是Software Transactional Memory。
Clojure 也是为 JVM 设计的，而不是作为另一种语言的层，所以当你必须进行互操作时，我想其他语言会更“Java-y”。
【讨论】：
(.method someopject param1 param2)。 Clojure 中最棘手的 Java 部分是围绕设置环境（具有 JVM、类路径、.jar 文件等）
如果我是愤世嫉俗的话，我会说这是因为 Clojure 有一个 nicer website 和一个更性感的名字。
【讨论】：
clojure.org 上的基本原理页面指出：
我为什么要编写另一种编程语言？基本上是因为我想要：
- 口齿不清
- 用于函数式编程
- 与已建立的平台共生
- 为并发设计
找不到。
您提到的 3 种语言（Kawa、ABCL 和 SISC）是否满足这些要求？它们是：
但它们设计用于 (STM) 并发；然而，为了公平和完整，我为 CL 找到了至少 2 个尚未提及的 STM 库：
嗯...那么为什么要创建一个新的 Lisp 呢？主要是因为这些是库。 clojure.org 上的基本原理页面继续（强调添加）：
标准的 Lisp（Common Lisp 和 Scheme）呢？
- 标准化后缓慢/没有创新
- 核心数据结构可变，不可扩展
- 规范中没有并发
- JVM 已经存在良好的实现（ABCL、Kawa、SISC 等）
- 标准 Lisp 是他们自己的平台
正如其他人所提到的，这是一个语言并发设计问题。
此外，为什么要停在 JVM 上？ Clojure CLR 支持正在积极开发中。
在我看来，这就是它填补的两个空白。如果 Clojure 满足您的需求，您应该使用它。如果 Clojure 从地图上消失，请不要担心失去您的技能。你的 Lisp 技能，但更重要的是你的思维方式，将延续到其他 Lisp 方言。
【讨论】：
我还应该补充一点，Clojure 是一种相对较新的语言，由一个人实施，具有良好的营销技巧和大量精力。他在 clojure 上投入了大量时间和炒作……有时，炒作是一种自我实现的预言，如果你能说服足够多的人相信它是最新的最伟大的东西，那么你就可以获得足够的支持和动力来实现它工作。
我怀疑 Kawa 等的实施者没有那么多风险，因此没有大肆宣传他们的产品。此外，有什么好炒作的？ “我们有一门很棒的语言……它叫做 Lisp” 这是一种更难推销的营销语言。
我认为 Java 是一个很好的例子。它有一些非常严重的缺陷，但由于它被大力推广和炒作，它获得了很大的动力，这意味着硬件/软件供应商、工具生产商、行业投资等的支持。无论哪种方式，它都取得了一定程度的成功。成功，虽然我讨厌在里面编程。 Clojure 可能会取得其他 Lisp 没有的类似成功。
【讨论】：
Clojure 的优势在于它可以让您访问所有的 Java 库/代码，并且支持多线程，因为它基于 JVM。此外，它在设计时考虑了并发性，这通常不会被设计到 lisp 中，尽管由于映射原语，设计一个能够很好地支持并发性的 lisp 可能并不难。
话虽如此，我尝试了 Clojure，但讨厌与 Java 相关的任何语法和对接因素的痛苦。
【讨论】：
Clojure 是“口齿不清”，它不是您已经知道的任何口齿不清。我已经度过了最后 几天阅读材料和观看视频，我印象深刻。它的 前提是函数式程序（基于不可变数据）是实现 管理并发。 Clojure 实现了一个基于 JVM 的类 lisp 系统来提供它。
【讨论】：
我们不必再提供一个答案（我不希望对这个答案投票），但这里对其他几个答案进行了一些小的改进。
更新不一定更好。较新且设计不佳的不好，较新且未维护也不好，较新而没有更大（或至少不断增长的）用户社区也不好。 （新的语言经常出现，但大多数都因为废弃而被淘汰。）
我喜欢 Common Lisp。它的美丽部分在于它的古怪之处，这来自于它是由委员会设计的，其目标是向后兼容几种不兼容的方言。
我喜欢方案。这是一门优美、优雅的语言。然而，它的发展取决于委员会，也许这有时会减慢它的速度。无论如何，它的目标与 Clojure 的不同。
Common Lisp 和 Scheme 的重点是尾递归，它们不太适合 JVM 上的效率。 Clojure 从一开始就被设计为很好地映射到 JVM，并与 Java（相当）良好地互操作。 （我不确定这对 Clojurescript 和 CLR 方言意味着什么。）
Clojure 最初是由一个人 Rich Hickey 开发的，并且由他和一个小团队控制，这一事实并不一定比委员会控制的语言更好。如果那个人做出了错误的决定，Clojure 就不是一门好语言。
然而，这是重点：Hickey 设计了一种经过深思熟虑、优雅的语言，并且从一开始就包含一套系统相关的函数，可以很容易地完成很多有一点。这适用于基本的 JVM 互操作以及语言的其余部分。到目前为止，控制 Clojure 的人仍然严格遵守该语言的目标。
这是我喜欢 Clojure 的一个重要部分：它的整体设计和细节都设计得很好。这意味着一旦你习惯了它，就会很高兴在其中编程。
如果说 Clojure 具有 Common Lisp 的强大功能和 Scheme 的优雅，这只是一点点夸大（或轻描淡写？）。 Common Lisp 在语言中内置了很多你需要的东西，但它是一团糟（我很喜欢这样说），而且当你需要的东西比语言中的更多时，有时会有几个不兼容的库具有不同的权衡。设计方案很小，尽管有可用的库。 Clojure 拥有越来越多的标准 库（与 CL 不同），它们或多或少是该语言的一部分。 core.matrix 项目就是一个很好的例子，它为几种不同的矩阵实现提供了一个通用接口。这一点很重要，因为有不同的矩阵实现最适合偶尔使用小矩阵或广泛使用大矩阵。
这并不是说 Clojure 比 Common Lisp 或 Scheme 更好；它不是。这三种语言有不同的优点。
【讨论】：
这是新的！这意味着不会有很多老 lisp 人会使用它，因为传统的 lisp 社区很好，很传统，但这也意味着 没有以前 lisp 经验的人 会将它作为新事物来接受。 p>
恕我直言，Clojure 之于老 Lisps 就像 Ruby 之于 Smalltalk。不一定更好，但足够好。至关重要的是，它更容易为您的雇主所接受，因为它具有发展势头并且被视为一种正在崛起的语言，就像曾经的 Ruby 一样。
【讨论】：