在哪些情况下使用 Clojure 更好？
我使用 Lisp 和Scheme 进行开发，但我正在阅读有关 Clojure 的内容，然后我想知道，在哪些情况下使用它比使用 Lisp 或Scheme 更好？谢谢
I develop in Lisp and in Scheme, but I was reading about Clojure and then I want to know, in which cases is better to use it than using Lisp or Scheme? Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
这个问题是无法回答的。我想说的是，你应该在几乎 100% 的时间里使用 Clojure，而不是 CL 和 Scheme。但这并不意味着你应该听我的。其他人可以提出很好的论据，证明事实恰恰相反。
对我来说，Clojure 中的语法和函数名称很美观。某些 Java 库对于我进行数据处理、Web 编程和 GUI 工作来说非常宝贵。函数式编程既具有挑战性又充满乐趣。在我看来，Clojure 的缺陷并不重要，而且其优点远远超过了它。其他 Lisp 中的某些无法容忍的缺陷在 Clojure 中得到了“修复”，因为它是新的并且可以忽略向后兼容性。它有一种新颖且可以说是强大的并发方法。 Clojure 社区充满活力、热情且非常棒。所有这些都说明了我和我的价值观，就像它说明了 Clojure 或其他 Lisp 语言一样。
有些用于 CL 和 Scheme 的库在 Clojure 或 Java 中是不存在的。有些人不喜欢 Clojure 使用太多语法，如
[]和{}，并希望在任何地方都使用括号。如果您想要 CLOS 风格的 OOP 或大量可变数据结构，另一个 Lisp 可能会更好。 JVM 是重量级的，对于某些人来说可能太重量级、太多包袱。许多 Java 内容（按设计）泄漏到了 Clojure 中，这冒犯了一些人的感情。 STM 和不可变数据结构的开销会使某些事情（例如数字运算）变慢或不太优雅。 Clojure 是新的，在某些领域仍然很粗糙，在其他领域仍在快速变化和发展。 Clojure 尚未通过时间的考验，而其他 Lisp 已经通过了。 Clojure 不是一个“标准”，有些人发现由实现定义的语言没有吸引力。等等。这些事情对我来说都不重要，但对你来说可能很重要。这几乎完全是主观的。您应该使用哪种语言取决于您已经知道的内容、您愿意学习的内容、您想要使用的库、您熟悉的编辑器和工具、您愿意忍受和解决的语言缺陷以及哪些缺陷是你不能容忍的，哪些可以帮助你更快、更便宜、更愉快地完成工作，或者实现你的任何目标。
基本上，任何让你感到温暖和模糊的东西。了解所有这些，然后根据您自己的喜好做出明智的选择，并使用您最喜欢的一个。他们都很好。
This question is impossible to answer. You should use Clojure nearly 100% of the time over CL and Scheme, is what I would say. But that doesn't mean you should listen to me. Others can make a good argument that the opposite is the case.
For me, the syntax and function names in Clojure aesthetically pleasing. Certain Java libraries are invaluable for what I do for data munging and web programming and GUI stuff. Functional programming is challenging and enjoyable. Clojure's flaws are unimportant and outweighed by its benefits in my eyes. Certain intolerable flaws in other Lisps are "fixed" in Clojure, because it's new and it can ignore backwards compatibility. It has a novel and arguably powerful approach to concurrency. The Clojure community is vibrant and welcoming and awesome. All of this says as much about me and what I value as it does about Clojure or other Lisps.
There are libraries for CL and Scheme that don't exist in Clojure or Java. There are people who dislike how Clojure uses too much syntax like
[]and{}and want to use parens everywhere. If you want CLOS-style OOP or lots of mutable data structures, another Lisp is arguably better. The JVM is heavyweight, maybe too heavyweight and too much baggage for some people. A lot of Java leaks into Clojure (by design) and this offends some people's sensibilities. The STM and immutable data structures have overheads that make certain things (e.g. number crunching) slower or less elegant. Clojure is new and still rough in certain areas, still rapidly changing and evolving in others. Clojure has yet to pass the test of time, whereas other Lisps already have. Clojure is not a "standard" and some people find a language defined by an implementation to be unappealing. And so on. None of these things matter to me, but they may to you.This is almost entirely subjective. Which language you should use depends on what you already know, what you are willing to learn, what libraries you want to use, what editors and tools you're comfortable with, what language flaws you're willing to live with and work around and what flaws you can't tolerate, and what helps you get your work done faster, more cheaply, more enjoyably, or achieve whatever your goals are.
Basically, whatever makes you feel warm and fuzzy. Learn them all and then make an informed choice based on your own tastes, and use whichever one you like the best. They're all good.
“Clojure 在 JVM 上运行”意味着您可以获得所有可用的 Java 库。您可以在 Swing 中制作漂亮的 GUI，使用 Apache 的 Web 客户端或服务器代码，连接现成的数独解算器......无论您喜欢什么。
Clojure 的另一大优点是其非常完善的并发支持，大约有 3 种不同的风格。如果您有计算密集型、可并行的任务，Clojure 可以让它变得简单。嗯，更容易。
更新：另一个论点。 Clojure 的功能非常强大，因此如果您想强迫自己进行功能性思考和编写，那么它是一个优势。
"Clojure runs on the JVM" means you get the whole cornucopia of Java libraries available. You can make pretty GUIs in Swing, use Apache's Web client or server code, connect a ready-built Sudoku solver... whatever you like.
Another big plus of Clojure is its very polished concurrency support, with about 3 different flavors. If you have a compute-intensive, parallelizable task, Clojure can make it easy. Well, easier.
Update: Another argument. Clojure is pretty strongly functional, so it's a plus if you want to force yourself to think and write functionally.
时，应该使用 Clojure
会更好
[1] 是的，这是一个糟糕的糟糕的原因，这就是我们生活的世界......
Clojure should be used when
Scheme would be better when:
[1] yes this is a bad bad bad reason. such is the world we live in...
什么时候？尽量。
为什么？不可变数据结构——它们真的那么好。还有很多其他原因。
When? As much as possible.
Why? Immutable Data Structures - they really are that good. There are plenty of other reasons too.
ABCL (Armed Bear Common Lisp) 和一些计划实现（KAWA、SISC、.. .) 也在 JVM 上运行。
一般来说，Common Lisp 有不同的“风格”—— ABCL 就是其中之一。其他编译为 C、本机代码，具有广泛的开发环境或专门的扩展，如逻辑语言或数据库。
Clojure OTOH 是一种新的 Lisp 方言，强调惰性函数式编程和并发编程。它的作者（Rich Hickey）是一位非常有经验的软件开发人员（他还为 Common Lisp 编写过 Java 和 .net 接口），并且在 Clojure 方面做得非常出色。尽管该语言有一些炒作，但它还是值得一试——它绝对是近年来开发的更好的 Lisp 方言之一（与 Newlisp 或 Arc 相比）。
ABCL (Armed Bear Common Lisp) and a several of Scheme implementations (KAWA, SISC, ...) are also running on the JVM.
Generally Common Lisp is available in different 'flavors' - ABCL is one of them. Other compile to C, to native code, have extensive development environments or specialized extensions like logic languages or databases.
Clojure OTOH is a new Lisp dialect with emphasis on lazy functional programming and concurrent programming. Its author (Rich Hickey) is a very experienced software developer (he has also written Java and .net interfaces for Common Lisp) and did an excellent job with Clojure. Even though there is some hype around the language, it is worth checking out - it is definitely one of the better Lisp dialects developed in recent years (compared to say Newlisp or Arc).
原因有很多，上面已经提到了一些。我的看法是：
目前可用的硬件
（多核）及其发展
今天使用的范式。推理并发性要容易得多。功能方面也更好。显然，你可以在 Lisp 中进行函数式编程，但是很容易在不知不觉中、不经意间和无意中打破范式。
Linux、Windows 和
苹果。有很多原生 Lisp
跨平台运行，但是
支持所有功能
平台有点参差不齐，你
必须时刻保持警惕
对于一个人身上缺少的东西
平台或其他。同样，
您需要的库并不总是
一致支持
平台。 ABCL 和一些
JVM 方案实现有这个
也一直支持，但我
仍然更喜欢 Clojure 因为
第 2 点.
社区。让我们面对现实吧，很多
Common Lisp 社区的时代
只是很难处理。那是
Clojure 根本不是这种情况。
无需任何帮助即可轻松获得有用的帮助
的屈尊和卑鄙
通常会得到来自
Common Lisp 社区。正如我所拥有的
自己学过几次，
没有一个问题如此愚蠢
你不会得到有礼貌和乐于助人的
Clojure 社区的回复。
如果我必须找一件事来抱怨的话，那就是 IDE 支持。也许这是一个学习新习惯的问题，但对我来说，处理 Java 开发的机制仍然比 Clojure 更容易。我尝试并使用了 Clojure Box、NetBeas 上的 enclojure、Intellij IDEA 上的 La Clojure 以及 Eclipse 上的 Counter Clock。如果您主要通过 REPL 工作，它们都可以正常工作，但是对于类文件的编译和执行，它们仍然感觉有点笨拙。
There are lot's of reasons, some mentioned above. My take is:
hardware currently available
(multi-core) and the development
paradigms in use today. It is so much easier to reason about concurrency. The functional aspects are nicer too. You can do functional programming in Lisp, obviously, but it is very easy to break the paradigm unknowingly, unwittingly, and unintentionally.
programs on Linux, Windows, and the
Mac. There are lot's of native Lisps
that run across platforms, but
support for all features on all
platforms is a bit spotty and you
constantly have to be on the alert
for things that are missing on one
platform or the other. Likewise,the
libraries you need are not always
consistently supported across
platforms. ABCL and some of the
JVM Scheme implementations have this
consistent support as well, but I
still prefer Clojure because of
point 2.
community. Let's face it, a lot of
the time the Common Lisp community
is just nasty to deal with. That is
not the case with Clojure at all.
It's easy to get useful help without
the condescension and meanness that
often comes with an answer from the
Common Lisp community. As I have
learned for myself several times,
there is no question so stupid that
you won't get a polite and helpful
reply from the Clojure community.
If I had to find one thing to complain about, it would be IDE support. Maybe it's a question of learning new habits, but it is still easier for me to handle the mechanics of Java development than Clojure. I have tried, and use, Clojure Box, enclojure on NetBeas, La Clojure on Intellij IDEA, and Counterclockwise on Eclipse. They all work fine if you are working primarily from the REPL, but for compilation and execution of class files, they all still feel a bit clumsy.
Clojure 的子集也可以编译为 javascript
A subset of Clojure can also compile to javascript
Clojure 在 JVM（和 CLR）上运行，所以就是这样。
Clojure runs on the JVM (and on the CLR), so there is that.
Clojure 的设计关注的是安全地容纳多种并发编程风格，故意使人们很难错误地用其他语言编写危险的、不稳定的、经常被破坏的并发容忍代码。如果您的问题领域涉及并发编程，Clojure 的一系列用于管理并发的集成工具可能比其他 Lisp 和 Scheme 中可用的特定于实现或最低公分母的库更适合。
Clojure's design is concerned with accommodating several styles of concurrent programming safely, deliberately making it difficult to mistakenly write the dangerous, rickety, and often broken concurrency-tolerant code in other languages. If your problem domain involves concurrent programming, Clojure's array of integrated tools for managing concurrency may be a better fit than the implementation-specific or lowest-common-denominator libraries available in other Lisps and Schemes.
Clojure 最伟大的事情之一就是您可以使用大量的库。你拥有 Java 的强大功能和 Lisp 的表达能力，这是一个绝妙的组合。 Clojure 更适合现实世界的开发，因为它是为现实世界的开发而设计的。有了 Clojure，您就拥有了很棒的库、很棒的现代功能以及由乐于助人、志同道合的人们组成的令人惊叹的社区。
我不得不说 Clojure 是一种更好的语言，无论从哪方面来说。这是一个极具争议性的陈述，所以我要在这里指出，这只是我的诚实观点。
Clojure 岩石。
One of the greatest things about Clojure is the plethora of libraries you can use with it. You have the power of Java with the expressiveness of Lisp, and that is a badass combination. Clojure is more suited for real world development, because it was made for real world development. With Clojure, you have awesome libraries, awesome modern features, and an amazing community of helpful, like-minded people.
I would have to say that Clojure is a better language, all the way around. That is a highly argumentative statement to make, so I will point out here that this is just my honest opinion.
Clojure rocks.
我一直在尝试学习新语言，所以我对学习 Clojure 很感兴趣。但是，SBCL 和其他一些 Common Lisp 实现不是比 Clojure 快得多吗？您是否不需要 4 个以上的处理器（以及合理的可并行任务）来弥补 Clojure 应用程序甚至同一应用程序的单线程 SBCL 版本之间的性能差异？
I'm always trying to learn new languages, so I'm interested in learning Clojure. But, aren't SBCL and some other Common Lisp implementations much, much faster than Clojure? Wouldn't you need considerably more than 4 processors (and a reasonably parallelizable task) to make up for the performance difference between a Clojure app and even a single-threaded SBCL version of the same app?
根据一般经验，在满足以下任一语言的情况下，我倾向于选择 Clojure 而不是其他语言：
(1).领域模型往往看起来非常递归和/或类似图形。
（2）。有机会利用多核 JVM 环境（例如 Elastic Beanstalk）
（3）。数据和代码之间存在模糊的障碍（想想 RPN 计算器，其中节点可以是运算符或数字）
这些可能听起来有点做作，但我的很多工作涉及处理图形和信息树，无论是查看社交网络，还是一些一种基于约束的优化，或语义关系构建。我发现我最喜欢的另一种语言 Ruby 无法为我提供与 Clojure 相比的表达能力和原始计算能力，特别是在定量、递归、并发类型的问题解决方面。
As a general rule of thumb, I tend to favor Clojure over other languages in cases where either of these fit the bill:
(1). The domain model tends to look very recursive and/or graph-like.
(2). There's an opportunity to leverage a multi-core JVM environment (e.g., Elastic Beanstalk)
(3). There's a fuzzy barrier between data and code (think RPN calculator where nodes can be operators or numbers)
These might sound a bit contrived, but a lot of my work involves dealing with graphs and trees of information, whether it's looking at social networks, some kind of constrained-based optimization, or semantic relationship building. I find that my other favorite language, Ruby, cannot give me the mix of expressiveness and raw computing power compared to Clojure, particularly when it comes to quantitative, recursive, concurrent-type problem solving.