blocks|key|1477903|text|ABCL和SISC是已存在很长时间的现有语言的重新实现。如果出于某种原因，您想在JVM上使用标准的Scheme或标准的Common+Lisp，那么它们是非常好的选择。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1477904|Clojure是一种新语言。它不能填补空白。它增加了全新的可能性。它支持纯函数式方法--+Scheme和CL都是多范式的。Clojure大量借鉴了各种FP语言(ML、Haskell)的设计。|1477905|是的，您可以向其他Lisp添加并发支持，但这完全不是重点。Clojure从一开始就被设计为并发语言。如此之多，以至于在Clojure中编写并发程序是微不足道的-而不是像在非函数式语言中那样的火箭科学(Scheme，CL不排除)。你可以这样看：|1477906|人们说，默认情况下，C可以让你编写快速的程序。|1477907|默认情况下，Clojure允许您编写并发程序。|1477908|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Kawa, ABCL, and SISC are reimplementations of existing languages that are quite long in the tooth. They are excellent if for some reason you want to use standard Scheme or standard Common Lisp on the JVM.

Clojure is a new language. It doesn't fill a gap. It adds entirely new possibilities. It favors a purely functional approach- Scheme and CL are both multi-paradigm. Clojure borrows heavily from the design of various FP languages (ML, Haskell).

And yes you could add concurrency support to other Lisps, but that's entirely missing the point. Clojure was designed from the very beginning as concurrent language. So much so that writing concurrent programs is trivial in Clojure - not rocket science as it is in non-functional languages (Scheme, CL not excluded). Look at this way:

People say that C lets you write fast programs by default.

Well, Clojure lets you write concurrent programs by default.

blocks|key|1603984|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1603985|"Clojure是一个不受向后兼容性约束的Lisp“(来自Clojure网站)。这是一个全新的开始。这是进步。使用使Lisp/Scheme变得强大的想法，但围绕Java重新思考它们，platform.|ordered-list-item|1603986|Clojure将始终是最新的Clojure。对于移植到JVM的任何其他语言，JVM版本可能总是在迎头赶上。如果您不需要Java平台，为什么要使用SISC而不是其他方案呢？如果你这样做了，为什么不使用专门为它设计的Lisp+(Clojure)呢？|1603987|在设计时考虑了并发性。|1603988|1603989|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|K|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|L|7|@]|8|@]|9|$]]|$1|D|3|E|4|C|6|M|7|@]|8|@]|9|$]]|$1|F|3|G|4|C|6|N|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|O|7|@]|8|@]|9|$]]|$1|I|3|-4|4|5|6|P|7|@]|8|@]|9|$]]]|J|$]]

<ol>
<li>"Clojure is a Lisp not constrained by backwards compatibility" (that's from the Clojure website).
It's a fresh start. It's progress. Use the ideas that make Lisp/Scheme powerful but rethink them around the Java platform.</li>
<li>Clojure will always be the most recent Clojure. With any other language ported to the JVM, the JVM version might always be playing catch-up. If you don't need the Java Platform why use SISC over another Scheme? If you do, why not use the one Lisp (Clojure) that was designed specifically for it?</li>
<li>Designed with concurrency in mind.</li>
</ol>

blocks|key|1604124|text|我能想到的最简单的答案是，Clojure不是Common-Lisp。Clojure不受其他Lisp历史的限制。它是为JVM构建的一种新语言。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1604125|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The most simple answer I can come up with is, Clojure is not Common-Lisp. Clojure is not constrained by the history of other Lisps. It is a new language built for the JVM.

blocks|key|73275|text|我只是没有意识到这些，这对Clojure来说是一个很大的好处(我发现人们制造了足够多的噪音)。我在你列出的列表中没有看到的Clojure最大的特性是Software+Transactional+Memory。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|73276|Clojure也是为JVM设计的，而不是作为另一种语言的层，所以当您必须进行互操作时，它更像是"Java-y“。|73277|entityMap|0|LINK|mutability|MUTABLE|url|http://java.ociweb.com/mark/stm/article.html^0|22|T|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

I simply wasn't aware of those, which is a serious benefit for Clojure (that people made enough noise I found out). The biggest thing Clojure has that I didn't see in those you listed is <a href="http://java.ociweb.com/mark/stm/article.html" rel="noreferrer">Software Transactional Memory</a>.

Clojure was also designed for the JVM, as opposed to being a layer for another language, so it's a little more "Java-y" that I imagine the others would be when you have to do interoperation.

blocks|key|1477866|text|如果我是一个愤世嫉俗的人，我会说这是因为Clojure有一个nicer+website和一个更性感的名字。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1477867|entityMap|0|LINK|mutability|MUTABLE|url|http://clojure.org/^0|U|D|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

If I were being cynical, I'd say it's because Clojure's got a <a href="http://clojure.org/" rel="noreferrer">nicer website</a> and a sexier name.

blocks|key|1602245|text|关于clojure.org的基本原理页面上写道：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1602246|1602247|为什么我还要写另一种编程语言？基本上是因为我想：|blockquote|1602248|1602249|1602250|用于Functional+Programming|1602251|symbiotic的|unordered-list-item|1602252|A+Lisp|1602253|，具有已建立的Concurrency|1602254|的Platform|1602255|
|1602256|designed|1602257|1602258|却找不到一个。|1602259|您提到的3种语言(Kawa、ABCL和SISC)是否满足这些要求？它们是：|1602260|1602261|Lisp(+CL或Scheme方言)|1602262|✓Functional+Programming✓|1602263|与已建立的平台(+JVM)✓共生|1602264|但是它们不是为(+STM+)并发而设计的；然而，为了公平和完整，我发现至少有两个用于CL的STM库还没有被提及：|1602265|1602266|STMX+|ordered-list-item|offset|length|1602267|测试了在ABCL上的工作。在active+development.|1602268|1602269|下|1602270|​|1602271|1602272|CL-STM+|1602273|已死？最后一次更改是在2007.|1602274|1602275|中|1602276|1602277|嗯..。那么为什么要创建一个新的Lisp呢？主要是因为这些都是库。关于clojure.org的基本原理页面继续(重点补充)：|1602278|1602279|标准Lisp+(通用Lisp和方案)怎么样？|1602280|1602281|1602282|在standardization|1602283|Core数据结构可变，而不是extensible|1602284|1602285|No并发的specs|style|BOLD|1602286|1602287|Good实现中，|1602288|缓慢/无创新已经存在于JVM中(ABCL，Kawa，SISC等)|1602289|标准Lisp是他们自己的平台|1602290|1602291|1602292|正如其他人所提到的，这是一个语言并发设计问题。|1602293|Clojure+CLR支持正在积极开发中。|1602294|从我的角度来看，这是它填补的两个空白。如果Clojure能满足您的需求，您应该使用它。不要担心如果Clojure从地图上消失，就会失去你的技能。您的Lisp技能，但更重要的是您的思维方式，将延续到其他Lisp方言。|1602295|entityMap|0|LINK|mutability|MUTABLE|url|http://stmx.org/features/|1|http://common-lisp.net/project/cl-stm/^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|4|0|1|1|0|0|0|0|0|6|1|1|1|0|0|0|0|0|0|0|0|0|0|0|0|A|0|0|0|0|0|0|0|E|6|0|0|J|0|0^^$0|@$1|2|3|4|5|6|7|31|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|32|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|33|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|34|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|35|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|36|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|37|8|@]|9|@]|A|$]]|$1|M|3|N|5|L|7|38|8|@]|9|@]|A|$]]|$1|O|3|P|5|L|7|39|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|3A|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|3B|8|@]|9|@]|A|$]]|$1|U|3|V|5|L|7|3C|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|3D|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|3E|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|3F|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|3G|8|@]|9|@]|A|$]]|$1|12|3|13|5|L|7|3H|8|@]|9|@]|A|$]]|$1|14|3|15|5|L|7|3I|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|3J|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|3K|8|@]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|3L|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|1D|7|3M|8|@]|9|@$1E|3N|1F|3O|1|3P]]|A|$]]|$1|1G|3|1H|5|L|7|3Q|8|@]|9|@]|A|$]]|$1|1I|3|-4|5|6|7|3R|8|@]|9|@]|A|$]]|$1|1J|3|1K|5|6|7|3S|8|@]|9|@]|A|$]]|$1|1L|3|1M|5|6|7|3T|8|@]|9|@]|A|$]]|$1|1N|3|-4|5|6|7|3U|8|@]|9|@]|A|$]]|$1|1O|3|1P|5|1D|7|3V|8|@]|9|@$1E|3W|1F|3X|1|3Y]]|A|$]]|$1|1Q|3|1R|5|L|7|3Z|8|@]|9|@]|A|$]]|$1|1S|3|-4|5|6|7|40|8|@]|9|@]|A|$]]|$1|1T|3|1U|5|6|7|41|8|@]|9|@]|A|$]]|$1|1V|3|1M|5|6|7|42|8|@]|9|@]|A|$]]|$1|1W|3|1X|5|6|7|43|8|@]|9|@]|A|$]]|$1|1Y|3|-4|5|6|7|44|8|@]|9|@]|A|$]]|$1|1Z|3|20|5|E|7|45|8|@]|9|@]|A|$]]|$1|21|3|-4|5|6|7|46|8|@]|9|@]|A|$]]|$1|22|3|-4|5|6|7|47|8|@]|9|@]|A|$]]|$1|23|3|24|5|6|7|48|8|@]|9|@]|A|$]]|$1|25|3|26|5|L|7|49|8|@]|9|@]|A|$]]|$1|27|3|T|5|6|7|4A|8|@]|9|@]|A|$]]|$1|28|3|29|5|L|7|4B|8|@$1E|4C|1F|4D|2A|2B]]|9|@]|A|$]]|$1|2C|3|T|5|6|7|4E|8|@]|9|@]|A|$]]|$1|2D|3|2E|5|L|7|4F|8|@]|9|@]|A|$]]|$1|2F|3|2G|5|L|7|4G|8|@]|9|@]|A|$]]|$1|2H|3|2I|5|L|7|4H|8|@]|9|@]|A|$]]|$1|2J|3|-4|5|6|7|4I|8|@]|9|@]|A|$]]|$1|2K|3|-4|5|6|7|4J|8|@]|9|@]|A|$]]|$1|2L|3|2M|5|6|7|4K|8|@$1E|4L|1F|4M|2A|2B]]|9|@]|A|$]]|$1|2N|3|2O|5|6|7|4N|8|@$1E|4O|1F|4P|2A|2B]]|9|@]|A|$]]|$1|2P|3|2Q|5|6|7|4Q|8|@]|9|@]|A|$]]|$1|2R|3|-4|5|6|7|4R|8|@]|9|@]|A|$]]]|2S|$2T|$5|2U|2V|2W|A|$2X|2Y]]|2Z|$5|2U|2V|2W|A|$2X|30]]]]

The rationale page on clojure.org states:

<blockquote>
 Why did I write yet another programming language? Basically because I wanted:
 
 <ul>
 <li>A Lisp</li>
 <li>for Functional Programming</li>
 <li>symbiotic with an established Platform</li>
 <li>designed for Concurrency</li>
 </ul>
 
 and couldn't find one.
</blockquote>

Do the 3 languages you mentioned (Kawa, ABCL and SISC) meet these requirements? They are:

<ul>
<li>Lisps (either the CL or Scheme dialects) ✓</li>
<li>for Functional Programming ✓</li>
<li>symbiotic with an established Platform (the JVM) ✓</li>
</ul>

but they are not designed for (STM) Concurrency; however, to be fair and complete, there are at least 2 STM libraries I found for CL that have not yet been mentioned:

<ol>
<li><a href="http://stmx.org/features/">STMX</a>
<ul>
<li>Tested working on ABCL. Under active development.</li>
</ul></li>
<li><a href="http://common-lisp.net/project/cl-stm/">CL-STM</a>
<ul>
<li>Dead? Last change was in 2007.</li>
</ul></li>
</ol>

Hmm... So why create a new Lisp? Mainly because these are libraries. The rationale page on clojure.org continues (emphasis added):

<blockquote>
 What about the standard Lisps (Common Lisp and Scheme)?
 
 <ul>
 <li>Slow/no innovation post standardization</li>
 <li>Core data structures mutable, not extensible</li>
 <li>No concurrency in specs</li>
 <li>Good implementations already exist for JVM (ABCL, Kawa, SISC et al)</li>
 <li>Standard Lisps are their own platforms</li>
 </ul>
</blockquote>

It is a language concurrency design issue, as others have mentioned.

Furthermore, why stop at the JVM? Clojure CLR support is under active development.

Those are the 2 gaps it fills, from my perspective. You should use Clojure if it meets your needs. Don't worry about losing your skills if Clojure drops off the map. Your Lisp skills, but more importantly your way of thinking, will carry over to other Lisp dialects.

blocks|key|1602178|text|我还应该补充说，Clojure是一种相对较新的语言，由一个人实现，具有良好的营销技能和大量的精力。他在clojure上投入了大量的时间和精力……有时，炒作是一种自我实现的预言，因为如果你能说服足够多的人相信它是最新的最伟大的东西，那么你就可以获得足够的支持和动力，让它真正发挥作用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1602179|我怀疑Kawa等的实现者没有那么多的风险，因此没有炒作他们的产品。再说了，有什么好炒作的？“我们有一门很棒的语言，叫做Lisp”，这是一个很难推销的语言。|1602180|我认为Java就是一个很好的例子。它有一些非常严重的缺陷，但由于它的市场和炒作如此之多，它获得了很大的发展势头，这意味着来自硬件/软件供应商、工具生产商、行业投资等的支持。无论哪种方式，它都取得了一定程度的成功，尽管我讨厌在其中编程。Clojure可能会取得类似的成功，而其他Lisp并非如此。|1602181|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I should also add that Clojure is a relatively new language, implemented by one person, with good marketing skills and a lot of energy. He's investing a lot of time and hype into clojure ... sometimes, the hype is a self-fulfilling prophecy in that if you can convince enough people that it's the latest greatest thing, then you can get enough support and momentum to make it actually work.

I suspect the implementers of Kawa etc. don't have as much at stake, hence are not hyping their product. Besides, what's there to hype? "We've got a great language .. it's called Lisp" It's a harder marketing sell. 

I think Java is a prime example of this. It had some very serious deficiencies, but because it was marketed and hyped so heavily it achieved a lot of momentum which meant support from hardware/software vendors, producers of tools, investment by industry, etc. Either way, it achieved a certain degree of success, although I hated programming in it. Clojure might achieve a similar success where other Lisps have not.

blocks|key|1477820|text|Clojure的优势在于，它允许您访问所有的java库/代码，并且支持多线程，因为它是基于JVM的。此外，它在设计时考虑了并发性，这通常不是用lisp设计的，尽管由于映射原语的原因，设计一个能够很好地支持并发性的lisp可能并不难。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1477821|话虽如此，我还是尝试了Clojure，但我讨厌它的语法以及似乎与Java相关的任何东西都会带来的麻烦。|1477822|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The advantage of Clojure is that it gives you access to all the java libraries/code out there, and multi-threading support because it's based on the JVM. In addition it was designed with concurrency in mind, something not generally designed into lisp, although because of the mapping primitives it probably wouldn't be hard to design a lisp that would support concurrency well.

That being said, I tried Clojure and hated the syntax and the pain in the butt factor that seems to go along with anything Java-connected.

blocks|key|1604118|text|Clojure是"a+lisp"，它不是你已经知道的任何lisp。在过去的几天里，我一直在阅读资料和观看视频，我对此印象深刻。它的前提是函数式程序(基于不可变数据)是管理并发性的最佳方法。Clojure基于JVM实现了一个类似lisp的系统来提供它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1604119|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Clojure is "a lisp", it's not any lisp you already know. I've spent the last
couple days reading the material and viewing the videos, and I'm impressed. Its
premise is that functional programs (based on immutable data) are the best way to
manage concurrency. Clojure implements a lisp-like system based on JVM to provide it.

blocks|key|302147|text|我们不需要再有一个答案(我也不期望这个答案会有选票)，但这里有一些对其他几个答案的小改进。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|302148|更新不一定是更好的。新的和糟糕的设计是不好的，新的和没有维护的是不好的，新的没有更大的(或至少是不断增长的)用户社区是不好的。(新语言会定期出现，但由于不使用，它们中的大多数都会半途而废。)|302149|我喜欢Common+Lisp。它的美的一部分是它的古怪，这来自于它是由委员会设计的，目标是向后兼容几种不兼容的方言。|302150|我喜欢Scheme。这是一门优美、优雅的语言。然而，它的发展依赖于委员会，也许这有时会拖慢它的发展。无论如何，它的目标与Clojure是不同的。|302151|常见的Lisp和Scheme具有尾递归等重点，这些重点不太适合JVM的效率。Clojure从一开始就被设计成很好地映射到JVM上，并(相当)与Java进行良好的互操作。(我不确定Clojurescript和CLR方言意味着什么。)|302152|Clojure最初是由一个人Rich+Hickey开发的，并由他和一个小团队一起控制，这一事实并不一定使它比委员会控制的语言更好。如果一个人做了错误的决定，Clojure就不是一种好的语言。|302153|然而，这是的重要一点：设计了一种经过深思熟虑的、优雅的语言，而且从一开始就包含了一套系统的相关函数，使得用少量的东西做很多事情变得很容易。这适用于基本的JVM互操作以及该语言的其余部分。到目前为止，控制Clojure的人仍然严格遵守该语言的目标。|offset|length|style|BOLD|302154|这是我喜欢Clojure的很大一部分原因:它的整体和细节都设计得很好。这意味着，一旦您习惯了它，在其中编程是一件很愉快的事情。|302155|这只会有点夸张(或轻描淡写？)可以说，Clojure既有Common+Lisp的力量，又有Scheme的优雅。Common+Lisp有很多您需要的内置到语言中的东西，但是它是一团糟(我说的是真的)，当您需要比语言中的东西更多的东西时，有时会有几个不兼容的库，它们有不同的权衡。尽管有可用的库，但设计的方案很小。Clojure拥有越来越多的标准库(与CL不同)，它们或多或少是语言的一部分。core.matrix项目就是一个很好的例子，它为几种不同的矩阵实现提供了一个公共接口。这一点很重要，因为有不同的矩阵实现，例如，最适合偶尔使用小矩阵，或者广泛使用大型矩阵。|302156|这并不是说Clojure比Common+Lisp或Scheme更好；它不是。这三种语言有不同的优点。|302157|entityMap^0|0|0|0|0|0|0|B|34|0|0|1R|0|0|7T|0|0|1E|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|13|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|14|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|15|8|@$N|16|O|17|P|Q]]|9|@]|A|$]]|$1|R|3|S|5|6|7|18|8|@$N|19|O|1A|P|Q]]|9|@]|A|$]]|$1|T|3|U|5|6|7|1B|8|@$N|1C|O|1D|P|Q]]|9|@]|A|$]]|$1|V|3|W|5|6|7|1E|8|@$N|1F|O|1G|P|Q]]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|Y|$]]

We don't have to have one more answer (and I don't expect votes for this one), but here are some small enhancements to several other answers.

Newer is not necessarily better. Newer and poorly designed is not good, newer and not maintained is not good, and newer without a larger (or at least growing) user community is not good. (New languages come out regularly, but most of them fall by the wayside because of disuse.)

I love Common Lisp. Part of its beauty is its quirkiness, which comes from the fact that it was designed by committees with a goal of backward compatibility to several incompatible dialects.

I love Scheme. It's a beautiful, elegant language. Nevertheless, its development depends on committees, and perhaps that has slowed it down at times. In any event, its goals are different from Clojure's.

Common Lisp and Scheme have emphases such as tail recursion that are not well-suited to efficiency on the JVM. Clojure was designed from the start to map well onto the JVM, and to interoperate (fairly) well with Java. (I'm not sure what that means about the Clojurescript and CLR dialects.)

The fact that Clojure was developed, initially, by one person, Rich Hickey, and is controlled by him along with a small team, does not necessarily make it better than a language controlled by committees. If that one person made bad decisions, Clojure would not be a good language.

However, and this is the important point: Hickey designed a language that is well thought out, elegant, and that from the start included a systematically related suite of functions that make it easy to do a lot with a little. That goes for the basic JVM interop as well as the rest of the language. The folks who control Clojure continue to be strict about sticking to the language's goals, so far. 

This is a big part of what I love about Clojure: It is well designed both as a whole and in its details. That means that once you get used to it, it's a pleasure to program in it.

It would only be a little bit of an overstatement (or understatment?) to say that Clojure has the power of Common Lisp with the elegance of Scheme. Common Lisp has lots and lots of what you need built into the language, but it's a mess (I say that with love), and when you need something more than what's in the language, there are sometimes several incompatible libraries with different tradeoffs. Scheme by design is small, although there are libraries available. Clojure has a growing body of standard libraries (unlike CL) that are more or less parts of the language. A nice illustration of this is the core.matrix project, which provides a common interface to several different matrix implementations. This is important, because there are different matrix implementations that are best for occasional use of small matrices, or for extensive use of huge matrices, for example.

None of this is intended to say that Clojure is better than Common Lisp or Scheme; it's not. The three languages have different virtues.

blocks|key|302174|text|这是新的！这意味着没有很多老的lisp用户会使用它，因为传统的lisp社区是很好的，传统的，但这也意味着以前没有lisp经验的人会把它当作新事物来使用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|302175|Imho，Clojure之于较老的Lisp就像Ruby之于Smalltalk。不一定更好，但已经足够好了。最重要的是，它更容易被你的雇主接受，因为它有发展势头，被视为一种正在崛起的语言，就像Ruby曾经的样子。|302176|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It's new! Which means not a lot of old lispers will use it since the traditional lisp community is well, traditional, but it also means that people with no previous lisp experience will pick it up as the new thing.

Imho, Clojure is to older Lisps what Ruby was to Smalltalk. Not necessarily better, but good enough. And crucially, it's more acceptable to your employer because it has momentum and is viewed as a language on the rise, much like Ruby once was.

The JVM already had three Lisps before Clojure arrived on the scene: <a href="http://www.gnu.org/software/kawa/" rel="noreferrer">Kawa</a>, <a href="http://common-lisp.net/project/armedbear/" rel="noreferrer">Armed Bear</a> and <a href="http://sisc-scheme.org/" rel="noreferrer">SISC</a>.

What gap does <a href="http://clojure.org/" rel="noreferrer">Clojure</a> fill that was left by those Lisps?

Why Clojure over other JVM Lisps: Kawa, Armed Bear or SISC?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

在Clojure出现之前，JVM已经有了三个Lisp：、和。填补了那些Lisps留下的空白？

问为什么Clojure胜过其他JVM Lisp: Kawa、JVM还是SISC？
EN

回答 11

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么Clojure胜过其他JVM Lisp: Kawa、JVM还是SISC？EN

回答 11

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么Clojure胜过其他JVM Lisp: Kawa、JVM还是SISC？
EN