首先，该语言不仅有两种主要方言（Common Lisp 和Scheme），而且每种方言都有许多单独的实现。例如，ChickenScheme、Bigloo等……各有细微差别。
从现代的角度来看，这很奇怪，因为当今的语言往往有明确的实现/规范。想想 Java、C#、Python、Ruby 等，其中每种语言都有一个明确的站点，您可以访问该站点来获取 API 文档、下载等。当然，Lisp 早于所有这些语言。但话又说回来，即使是 C/C++ 也是标准化的（或多或少）。
这个社区的分裂是因为 Lisp 的时代吗？或者也许不同的实现/方言旨在解决不同的问题？我知道 Lisp 永远不会像围绕单一明确实现发展起来的语言那样统一，这是有充分理由的，但在这一点上，Lisp 社区有什么充分理由不应该朝这个方向发展吗？
To begin, not only are there two main dialects of the language (Common Lisp and Scheme), but each of the dialects has many individual implementations. For example, Chicken Scheme, Bigloo, etc... each with slight differences.
From a modern point of view this is strange, as languages these days tend to have definitive implementations/specs. Think Java, C#, Python, Ruby, etc, where each has a single definitive site you can go to for API docs, downloads, and such. Of course Lisp predates all of these languages. But then again, even C/C++ are standardized (more or less).
Is the fragmentation of this community due to the age of Lisp? Or perhaps different implementations/dialects are intended to solve different problems? I understand there are good reasons why Lisp will never be as united as languages that have grown up around a single definitive implementation, but at this point is there any good reason why the Lisp community should not move in this direction?
发布评论
评论（9）
Lisp 社区是支离破碎的，但其他一切也是支离破碎的。
为什么有这么多 Linux 发行版？
为什么有这么多 BSD 变体？ OpenBSD、NetBSD、FreeBSD，...甚至 Mac OS X。
为什么有这么多脚本语言？ Ruby、Python、Rebol、TCL、PHP 以及无数其他语言。
为什么有这么多 Unix shell？ sh, csh, bash, ksh, ...？
为什么有这么多的Logo实现（>100），Basic（>100），C（无数），...
为什么 Ruby 有这么多变体？ Ruby MRI、JRuby、YARV、MacRuby、HotRuby？
Python 可能有一个主站点，但有几个略有不同的实现：CPython、IronPython、Jython、Python for S60、PyPy、Unladen Swallow、CL-Python，...
为什么有 C（Clang、GCC、MSVC、Turbo C、Watcom C） , ...), C++, C#, Cilk, Objective-C, D, BCPL, ... ?
只要让其中一些达到五十，然后看看它有多少种方言和实现。
我认为 Lisp 是多样化的，因为每种语言都是多样化的或者变得多样化。有些从单一实现（麦卡锡的 Lisp）开始，五十年后你就得到了一个动物园。 Common Lisp 甚至从多种实现开始（针对不同的机器类型、操作系统、不同的编译器技术……）。
如今，Lisp 是一个语言家族，而不是单一语言。甚至对于哪些语言属于该语系也没有达成共识。可能需要检查一些标准（s-表达式、函数、列表……），但并非每种 Lisp 方言都支持所有这些标准。语言设计者尝试了不同的功能，我们得到了许多或多或少类似 Lisp 的语言。
如果你看看 Common Lisp，就会发现大约有三到四个不同的活跃商业供应商。尝试让他们支持一项产品！行不通。然后你就会有一堆活跃的开源实现，它们具有不同的目标：一个编译为 C，另一个用 C 编写，一个试图拥有一个快速优化的编译器，一个试图通过本机编译获得一些中间基础，一个目标是JVM...等等。尝试告诉维护者放弃他们的实现！
该方案有大约 100 个实施方案。许多人已经死了，或者大部分已经死了。至少十到二十个是活跃的。有些是业余爱好项目。有些是大学项目，有些是公司项目。 用户有不同的需求。一个需要用于游戏的实时 GC，另一个需要嵌入到 C 中，一个只需要用于教育目的的准系统构造，等等。如何告诉开发人员不要破坏他们的实施。
还有一些人不喜欢 Common Lisp（太大、太旧、功能不够、不够面向对象、太快、不够快……）。有些人不喜欢Scheme（太学术、太小、无法扩展、太实用、功能不够、没有模块、错误的模块、不正确的宏……）。
然后有人需要将 Lisp 与 Objective-C 结合起来，然后你就得到了 Nu。有人为 .net 破解了一些 Lisp。然后你会得到一些具有并发性和新鲜想法的 Lisp，然后你就会得到 Clojure。
这是语言进化在起作用。这就像寒武纪大爆发（当许多新动物出现时）。有些人会死去，有些人会继续存在，有些人会出现。在某个时间点，出现了一些方言，它们达到了最先进的水平（Scheme 适用于 70 年代/80 年代的 Lisp 函数式编程，Common Lisp 适用于 80 年代的 MacLisp 式编程）——这导致一些方言大部分消失（即 Standard Lisp、InterLisp 等）。
Common Lisp 是 Lisp 方言的鳄鱼。这是一个非常古老的设计（数亿年），几乎没有什么变化，看起来有点可怕，而且时不时地它会吃掉一些年轻的......
如果你想了解更多，Lisp 的演变（以及 相应的幻灯片）是一个非常好的开始！
The Lisp community is fragmented, but everything else is too.
Why are there so many Linux distributions?
Why are there so many BSD variants? OpenBSD, NetBSD, FreeBSD, ... even Mac OS X.
Why are there so many scripting languages? Ruby, Python, Rebol, TCL, PHP, and countless others.
Why are there so many Unix shells? sh, csh, bash, ksh, ...?
Why are there so many implementations of Logo (>100), Basic (>100), C (countless), ...
Why are there so many variants of Ruby? Ruby MRI, JRuby, YARV, MacRuby, HotRuby?
Python may have a main site, but there are several slightly different implementations: CPython, IronPython, Jython, Python for S60, PyPy, Unladen Swallow, CL-Python, ...
Why is there C (Clang, GCC, MSVC, Turbo C, Watcom C, ...), C++, C#, Cilk, Objective-C, D, BCPL, ... ?
Just let some of them get fifty and see how many dialects and implementations it has then.
I guess Lisp is diverse, because every language is diverse or gets diverse. Some start with a single implementation (McCarthy's Lisp) and after fifty years you got a zoo. Common Lisp even started with multiple implementations (for different machine types, operating systems, with different compiler technology, ...).
Nowadays Lisp is a family of languages, not a single language. There is not even consensus what languages belong to that family or not. There might be some criteria to check (s-expressions, functions, lists, ...), but not every Lisp dialect supports all these criteria. The language designers have experimented with different features and we got many, more or less, Lisp-like languages.
If you look at Common Lisp, there are about three or four different active commercial vendors. Try to get them behind one offering! Won't work. Then you have a bunch of active open source implementations with different goals: one compiles to C, another one is written in C, one tries to have a fast optimizing compiler, one tries to have some middlle ground with native compilation, one is targeting the JVM ... and so on. Try to tell the maintainers to drop their implementations!
Scheme has around 100 implementations. Many are dead, or mostly dead. At least ten to twenty are active. Some are hobby projects. Some are university projects, some are projects by companies. The users have diverse needs. One needs a real-time GC for a game, another one needs embedding in C, one needs only barebones constructs for educational purposes, and so on. How to tell the developers to keep from hacking their implementation.
Then there are some who don't like Commmon Lisp (too big, too old, not functional enough, not object oriented enough, too fast, not fast enough, ...). Some don't like Scheme (too academic, too small, does not scale, too functional, not functional enough, no modules, the wrong modules, not the right macros, ...).
Then somebody needs a Lisp combined with Objective-C, then you get Nu. Somebody hacks some Lisp for .net. Then you get some Lisp with concurrency and fresh ideas, then you have Clojure.
It's language evolution at work. It is like the cambrian explosion (when lots of new animals appeared). Some will die, others will live on, some new will appear. At some point in time some dialects appear that pick up the state of art (Scheme for everything with functional programming in Lisp in the 70s/80s and Common Lisp for everything MacLisp-like in the 80s) - that causes some dialects to disappear mostly (namely Standard Lisp, InterLisp, and others).
Common Lisp is the alligator of Lisp dialects. It is a very old design (hundred million years) with little changes, looks a little bit frightening, and from time to time it eats some young...
If you want to know more, The Evolution of Lisp (and the corresponding slides) is a very good start!
我认为这是因为“Lisp”是对一种语言的广泛描述。据我所知，所有 Lisp 之间唯一的共同点是大多数内容都在括号中，并使用前缀函数表示法。例如
，然而，几乎所有其他内容都可能因实现而异。 Scheme 和 CL 是完全不同的语言，应该这样考虑。
我认为称 lisp 社区为支离破碎就像称“C 类”社区为支离破碎一样。它有c，c++，d，java，c#，go，javascript，python和许多其他我想不到的语言。
总结：Lisp 更像是一种语言属性（如垃圾收集、静态类型），而不是实际的语言实现，因此有许多语言具有类似 Lisp 的属性是完全正常的，就像许多语言具有垃圾收集一样。
I think it is because "Lisp" is such a broad description of a language. The only common thing between all the lisps that I know is most things are in brackets, and uses prefix function notation. Eg
However nearly everything else can vary between implementations. Scheme and CL are completely different languages, and should be considered like that.
I think calling the lisp community fragmented is like calling the "C like" community fragmented. It has c,c++,d,java,c#, go, javascript, python and many other languages which I can't think of.
In summary: Lisp is more of a language property (like garbage collection, static typing) than an actual language implementation, so it is completely normal that there are many languages that have the Lisp like property, just like many languages have garbage collection.
我认为这是因为 Lisp 诞生于并保持了黑客文化的精神。黑客文化是根据你对“更好”的信念，采取一些东西并使其“更好”。
因此，当你有一群固执己见的黑客和一种修改文化时，分裂就会发生。您将获得方案、Common Lisp, ELISP, < a href="http://en.wikipedia.org/wiki/Arc_(programming_language)" rel="noreferrer">Arc。这些都是完全不同的语言，但它们同时都是“Lisp”。
现在为什么社区变得支离破碎？好吧，我会把这归咎于时间和成熟度。该语言已有50年历史了！ :-)
I think it's because Lisp was born out of, and maintains the spirit of the hacker culture. The hacker culture is to to take something and make it "better" according to your belief in "better".
So when you have a bunch of opinionated hackers and a culture of modification, fragmentation happens. You get Scheme, Common Lisp, ELISP, Arc. These are all pretty different languages, but they're all "Lisp" at the same time.
Now why is the community fragmented? Well, I'll blame time and maturity on that. The language is 50 years old! :-)
Scheme 和 Common Lisp 是标准化的。 SBCL 看起来像是事实上的开源 Lisp，并且有很多关于如何使用它的示例。它快速且免费。 ClozureCL 看起来也相当不错。
PLT 方案似乎是事实上的开源方案，并且有很多如何使用它的示例。它快速且免费。
对我来说，CL HyperSpec 看起来和 JavaDoc 一样好。
就社区碎片化而言，我认为这与标准或资源无关。我认为这与直到最近为止还是一个相对较小的社区有关。
我认为 Clojure 有很好的机会成为新一代程序员的 Lisp。
也许我的观点是，只要有一个非常流行的实现，就可以产生一个有凝聚力的社区的幻觉。
Scheme and Common Lisp are standardized. SBCL seems like the defacto open source lisp and there are plenty of examples out there on how to use it. It's fast and free. ClozureCL also looks pretty darn good.
PLT Scheme seems like the defacto open source scheme and there are plenty of examples out there how to use it. It's fast and free.
The CL HyperSpec seems as good as the JavaDoc to me.
As far as community fragmentation I think this has little to standards or resources. I think this has far more to do with what has been a relatively small community until recently.
Clojure I think has a good chance to become The Lisp for the new generation of coders.
Perhaps my point is a very popular implementation is all that is required to give the illusion of a cohesive community.
LISP 并不像 BASIC 那样分散。
BASIC 的方言和版本太多了，我已经记不清了。
即使是最常用的实现（MS VB）在版本之间也有所不同。
LISP is not nearly as fragmented as BASIC.
There are so many dialects and versions of BASIC out there I have lost count.
Even the most commonly used implementation (MS VB) is different between versions.
Common LISP 有多种实现这一事实应该被认为是一件好事。事实上，考虑到这些语言的相对流行程度，Common LISP 的免费实现数量与 C++ 的免费实现数量大致相同，这是值得注意的。
免费的 Common LISP 实现包括 CMU CL、SBCL、OpenMCL / Clozure CL、CLISP、GCL 和 ECL。
免费 C++ 实现包括 G++（带有 Cygwin 和 MinGW32 变体）、Digital Mars、Open Watcom、Borland C++（传统？）和 CINT（解释器）。 C++ 也有各种 STL 实现。
关于Scheme和Common LISP，虽然无可否认，这是一个不准确的类比，但有时我会认为Scheme对于Common LISP就像C对于C++一样，即虽然Scheme和C很小而优雅，但Common LISP和C++很大并且（可以说）更适合更大的应用程序。
The fact that there are many implementations of Common LISP should be considered a good thing. In fact, given that there are roughly the same number of free implementations of Common LISP as there are free implementations of C++ is remarkable, considering the relative popularity of the languages.
Free Common LISP implementations include CMU CL, SBCL, OpenMCL / Clozure CL, CLISP, GCL and ECL.
Free C++ implementations include G++ (with Cygwin and MinGW32 variants), Digital Mars, Open Watcom, Borland C++ (legacy?) and CINT (interpreter). There are also various STL implementations for C++.
With regards to Scheme and Common LISP, although admittedly, an inaccurate analogy, there are times when I would consider Scheme is to Common LISP what C is to C++, i.e. while Scheme and C are small and elegant, Common LISP and C++ are large and (arguably) more suited for larger applications.
拥有许多实现是有益的，因为每个实现在独特的地方都是最佳的。而且现代主流语言无论如何都没有一种实现。想想 Python：它的主要实现是 CPython，但由于 JPython，您也可以在 JVM 上运行 Python；借助 Stackless Python，您可以通过微线程实现大规模并发；此类实现在某些方面是兼容的：JPython 与 Java 无缝集成，而 CPython 则不然。鲁比也一样。
您不希望有许多与骨骼不兼容的实现。方案就是这种情况，如果不重写大量代码，就无法在实现之间共享库，因为方案者无法就如何导入/导出库达成一致。 Common Lisp 库 OTOH 由于核心领域的标准化，更有可能是可移植的，并且存在有条件地编写处理每个实现的特性的代码的工具。实际上，现在你可能会说 Common Lisp 是由它的实现来定义的（想想 ASDF 包安装库），就像主流语言一样。
Having many implementations is beneficial, because each implementation is optimal in unique places. And modern mainstream languages don't have one implementation anyway. Think about Python: its main implementation is CPython, but thanks to JPython you can run Python on the JVM too; thanks to Stackless Python you can have massive concurrency thanks to microthreads; etc. Such implementations will be encompatible in some ways: JPython integrates seamlessly with Java, whilst CPython doesn't. Same for Ruby.
What you don't want is having many implementations which are incompatible to the bone. That's the case with Scheme, where you can't share libraries among implementations without rewriting a lot of code, because Schemers can't agree on how to import/export libraries. Common Lisp libraries, OTOH, because of standardization in core areas, are more likely to be portable, and facilities exist to conditionally write code handling each implementation's peculiarities. Actually, nowadays you may say that Common Lisp is defined by its implementations (think about the ASDF package installation library), just like mainstream languages.
两个可能的影响因素：
与 C/C++/Ruby 等其他语言相比，Lisp 语言并不是非常流行 - 仅这一点就可能给人一种社区支离破碎的错觉。其他语言社区中可能也存在同样的碎片化，但是更大的社区将会有更大的碎片。Lisp
语言比大多数语言更容易实现。我见过很多很多“玩具”Lisp 实现，人们为了好玩而制作，很多“正确”Lisp 实现来解决特定任务。 Lisp 实现的数量远多于 Python 解释器（我知道大约有 5 个，其中大多数通常是可以互换的）。
有一些有前景的项目，例如 Clojure，它是一种新语言，具有明确的目标（并发），没有太多“历史包袱”，易于安装/设置，可以搭载 Java 的库“生态系统”，拥有一个包含文档/库的良好网站，并且有一个官方邮件列表。这几乎解决了我不久前尝试学习 Common Lisp 时遇到的每个问题，并鼓励建立一个更加集中的社区。
Two possible contributing factors:
Lisp languages aren't hugely popular in comparison to other languages like C/C++/Ruby and so on - that alone may give the illusion of a fragmented community. There may be equal fragmentation in the other language-communities, but a larger community will have larger fragments..
Lisp languages are easier than most to implement. I've seen many, many "toy" Lisp implementations people have made for fun, many "proper" Lisp implementations to solve specific tasks. There are far more Lisp implementations than there are, say, Python interpreters (I'm aware of about.. 5, most of which are generally interchangeable)
There are promising projects like Clojure, which is a new language, with a clear goal (concurrency), without much "historical baggage", easy to install/setup, can piggyback on Java's library "ecosystem", has a good site with documentation/libraries, and has an official mailing list. This pretty much checks off every issue I encountered while trying to learn Common Lisp a while ago, and encourages a more centralised community.
我的观点是 Lisp 是一种小型语言，因此很容易实现（与 Java、C#、C 相比，...）。
注意：正如许多人评论说它确实没那么小，但它忽略了我的观点。让我尝试更准确地说：这个价格下跌到了入场点价格。与构建处理 LISP 的 VM 相比，构建一个编译一些众所周知的主流语言的 VM 是非常困难的。这样就可以轻松地围绕小项目建立小型社区。现在，库和规范可能会也可能不会完全实现，但价值主张仍然存在。关闭它是一个典型的例子，其中R5RS肯定不在范围内。
My point of view is that Lisp is a small language so it is easy to implement (compare to Java, C#, C, ...).
Note: As many comment that it is indeed not that small it miss my point. Let me try to be more precise: This boll down to the entry point price. Building a VM that compile some well know mainstream language is quit hard compare to building a VM that deal with LISP. This would then make it easy to build small community around a small project. Now the library and spec may or may not be fully implemented but the value proposition is still there. Closure it a typical example where the R5RS is certainly not in the scope.