为什么 Lisp 社区如此分散？ [关闭]答案

【问题标题】：Why is the Lisp community so fragmented? [closed]为什么 Lisp 社区如此分散？ [关闭]
【发布时间】：2011-01-08 01:26:25
【问题描述】：

首先，该语言不仅有两种主要方言（Common Lisp 和 Scheme），而且每种方言都有许多单独的实现。例如，Chicken Scheme、Bigloo 等……各有细微差别。

从现代的角度来看，这很奇怪，因为如今的语言往往具有明确的实现/规范。想想 Java、C#、Python、Ruby 等，每个都有一个权威站点，您可以访问 API 文档、下载等。当然，Lisp 早于所有这些语言。但话又说回来，即使是 C/C++ 也是标准化的（或多或少）。

这个社区的分裂是因为 Lisp 的时代吗？或者也许不同的实现/方言旨在解决不同的问题？我理解 Lisp 永远不会像围绕单一明确实现而发展起来的语言那样团结的充分理由，但在这一点上，Lisp 社区不应该朝这个方向发展有什么充分理由吗？

【问题讨论】：

这是因为当他们说话时，他们无法理解彼此在说什么。 ;)
C 远非同样古老！ Lisp 已经 50 岁了，C 也快 40 岁了。最初的 10 年很艰难！
C 有一个标准和许多开发其扩展的变体。然后是 C++、C#、Objective C、C--、BitC、D、...
LISP 也有标准。有两个主要标准（Scheme 和 CL）。
这个问题应该标记为“社区维基”，因为它是关于编程文化的问题，而不是关于编程的问题。

标签： lisp scheme common-lisp

【解决方案1】：

我认为这是因为 Lisp 诞生于并保持了黑客文化的精神。黑客文化就是根据你对“更好”的信念去拿一些东西并把它做得“更好”。

因此，当您拥有一群固执己见的黑客和一种修改文化时，就会发生碎片化。你会得到Scheme、Common Lisp、ELISP、Arc。这些都是完全不同的语言，但它们同时都是“Lisp”。

现在社区为什么会支离破碎？好吧，我会把这归咎于时间和成熟度。语言已有50年历史！ :-)

【讨论】：

【解决方案2】：

我认为这是因为“Lisp”是一种语言的广泛描述。我所知道的所有 lisp 之间唯一的共同点是大多数东西都在括号中，并使用前缀函数表示法。例如

(fun (+ 3 4))

但是，几乎所有其他内容都可能因实现而异。 Scheme 和 CL 是完全不同的语言，应该这样考虑。

我认为将 lisp 社区称为碎片化就像将“C like”社区称为碎片化一样。它有 c、c++、d、java、c#、go、javascript、python 和许多其他我想不到的语言。

总而言之：Lisp 与其说是一种实际的语言实现，不如说是一种语言属性（如垃圾收集、静态类型），因此有许多语言具有类似 Lisp 的属性是完全正常的，就像许多语言都有垃圾一样收藏。

【讨论】：

一直都是这样吗？一开始肯定有一个 Lisp，然后分裂（分裂？崩溃？解体？）成这些其他方言？还是一直有方言？
是的，确实如此，但这与类似 C 的语言开始的方式相同。最初只有一个（显然是 c），然后是 c++、java 和所有其他的。这是很自然的，因为每种语言都以不同的方式做事。比如c++引入了对象，java引入了内存管理和虚拟机的概念。
一开始只有一个 Lisp，最初的实现。但它肯定是支离破碎的。我们今天拥有 Common Lisp，特别是因为这种碎片化，它旨在统一分裂的 Lisp。也就是说，虽然事情是从 Scheme 中提取出来的（特别是词法绑定），但 Scheme 从来都不是 Common Lisp 不可避免的组成部分的“一部分”。对于额外的功劳，我们可以讨论基于 Lisp 的对象系统。
对 lisp 的原始描述是一篇学术论文，没有实现，甚至没有打算做一个。第一个实现很快就出现了，这让作者感到惊讶。请参阅维基百科文章的历史部分。
python 是“C 类”？粗暴地不：S

【解决方案3】：

LISP 不像 BASIC 那样分散。

BASIC 的方言和版本太多了，我数不清了。

即使是最常用的实现（MS VB）也因版本而异。

【讨论】：

好点，尽管在 MS 方面，每个新版本都旨在替换旧版本。当然，这会产生使用旧版本 BASIC 的孤立项目的效果，因此您仍然会看到有关 VB6 的帖子。在 MS 实现之外，是否有任何 BASIC 方言/版本仍在积极使用？
这个答案没有解决问题。
@Justin Ether '是否有任何 BASIC 方言/版本仍在积极使用' - 它广泛用于在各种收购和合并中幸存下来的 DEC/VMS 站点，此外还有一些商业产品具有某种内置的基本解释器（例如 IBM/Ascential DataStage）
@ken lui，虽然我的评论没有直接回答它提供附加数据的问题。即 Lisp 不是唯一支离破碎的语言，这可能有助于回答发帖者的问题

【解决方案4】：

Scheme 和 Common Lisp 是标准化的。 SBCL 似乎是事实上的开源 lisp，并且有很多关于如何使用它的示例。它快速且免费。 ClozureCL 看起来也相当不错。

PLT 方案似乎是事实上的开源方案，并且有很多如何使用它的示例。它既快速又免费。

在我看来，CL HyperSpec 和 JavaDoc 一样好。

就社区分裂而言，我认为这与标准或资源无关。我认为这与直到最近还是一个相对较小的社区有关。

我认为 Clojure 很有可能成为新一代程序员的 Lisp。

也许我的意思是，一个非常流行的实现就是给一个有凝聚力的社区的错觉所需要的一切。

【讨论】：

【解决方案5】：

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、...？

让他们中的一些人得到 50，然后看看它有多少方言和实现。

我猜 Lisp 是多样化的，因为每种语言都是多样化的或变得多样化。有些从一个单一的实现开始（麦卡锡的 Lisp），五十年后你得到了一个动物园。 Common Lisp 甚至从多种实现开始（针对不同的机器类型、操作系统、使用不同的编译器技术……）。

如今Lisp 是一个语言家族，而不是单一语言。甚至没有共识哪些语言属于那个家族。可能有一些标准需要检查（s 表达式、函数、列表……），但并不是每个 Lisp 方言都支持所有这些标准。语言设计者尝试了不同的功能，我们得到了许多或多或少类似于 Lisp 的语言。

如果您查看 Common Lisp，大约有三四个不同的活跃商业供应商。尝试让他们支持一项产品！不会工作。然后你有一堆具有不同目标的活跃开源实现：一个编译为 C，另一个是用 C 编写，一个试图拥有一个快速优化的编译器，一个试图在本机编译中有一些中间基础，一个是针对JVM ...等等。尝试告诉维护者放弃他们的实现！

方案有大约 100 个实现。许多人已经死了，或者大部分都死了。至少有十到二十个是活跃的。有些是爱好项目。有些是大学项目，有些是公司的项目。 用户有不同的需求。一个需要用于游戏的实时 GC，另一个需要嵌入到 C 中，一个只需要用于教育目的的准系统构造，等等。如何告诉开发人员不要破解他们的实现。

还有一些人不喜欢Commmon Lisp（太大、太旧、功能不够、面向对象不够、太快、不够快……）。有些人不喜欢 Scheme（太学术、太小、无法扩展、太实用、功能不够、没有模块、错误的模块、没有正确的宏……）。

然后有人需要一个 Lisp 与 Objective-C 的结合，然后你得到 Nu。有人为 .net 破解了一些 Lisp。然后你会得到一些具有并发性和新鲜想法的 Lisp，然后你就有了 Clojure。

这是工作中的语言演变。这就像寒武纪大爆发（当时出现了许多新动物）。有些会死，有些会继续存在，有些新的会出现。在某个时间点，一些方言出现了最先进的技术（70 年代 / 80 年代在 Lisp 中使用函数式编程的所有方案和 80 年代所有类似 MacLisp 的 Common Lisp 的方案） - 这导致一些方言大部分消失（即 Standard Lisp、InterLisp 等）。

Common Lisp 是 Lisp 方言的鳄鱼。是很古老的设计（亿年），变化不大，看起来有点吓人，时不时会吃掉一些年轻...

如果您想了解更多，The Evolution of Lisp（和corresponding 幻灯片）是一个很好的开始！

【讨论】：

值得指出的是，lisp 是当今仍在使用的最古老的语言之一。这意味着它比大多数语言有更多的时间来分片。
@KenLiu 实际上，Lisp 源代码的括号数量似乎与某些主流语言（例如：Java）相同，但总体而言标点符号较少。
@Elena - 有趣...你有参考吗？
@JustinEthier - 不。有一天我在用 Java 编码时注意到它，并注意到每个函数调用都有一对括号，就像 Lisp 一样，但是 Java 有冒号和点，而 Lisp 中会缺少这些。
@JustinEthier - 示例：i = 0; => (setq i 0) // 有趣的 (a, b, c); => (fun abc) // object.fun (a, b, c) => (fun obj abc) // ` Lisp 的括号更明显，因为它们是堆积的，但是一旦你习惯了它们，可能会突出显示用更微妙的颜色，然后你会意识到整体上没有那么混乱。

【解决方案6】：

Common LISP 有很多实现这一事实应该被认为是一件好事。事实上，考虑到这些语言的相对流行度，Common LISP 的免费实现数量与 C++ 的免费实现数量大致相同，这是非常了不起的。

免费的通用 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++很大并且（可以说）更适合更大的应用程序。

【讨论】：

【解决方案7】：

两个可能的影响因素：

与其他语言（如 C/C++/Ruby 等）相比，Lisp 语言并不是很流行——仅此一项就可能给人一种分散社区的错觉。其他语言社区可能存在相同的碎片化，但更大的社区将有更大的碎片..

Lisp 语言比大多数语言更容易实现。我见过很多很多人们为了好玩而制作的“玩具”Lisp 实现，以及许多用于解决特定任务的“适当”Lisp 实现。 Lisp 实现比 Python 解释器多得多（我知道大约 5 个，其中大多数通常是可互换的）

有像 Clojure 这样有前途的项目，它是一门新语言，目标明确（并发），没有太多“历史包袱”，易于安装/设置，可以搭载 Java 库“生态系统”，拥有良好的网站带有文档/库，并有一个官方邮件列表。这几乎可以解决我在不久前尝试学习 Common Lisp 时遇到的所有问题，并鼓励建立更加集中的社区。p>

【讨论】：

【解决方案8】：

我的观点是 Lisp 是一种小型语言，因此很容易实现（与 Java、C#、C 相比...）。

注意：许多评论说它确实没有那么小，它没有抓住我的意思。让我试着更准确地说：这可以归结为入场点价格。与构建处理 LISP 的 VM 相比，构建一个编译一些众所周知的主流语言的 VM 很难。这将使围绕一个小项目建立小型社区变得容易。现在库和规范可能会或可能不会完全实现，但价值主张仍然存在。关闭它是 R5RS 肯定不在范围内的典型示例。

【讨论】：

好点，尤其是关于Scheme。
...虽然我会说为 Lisp 实现一切——甚至是 Scheme R5RS——可能并不像你想象的那么小或容易。
当然不是，你可能会陷入很多陷阱，但与 C++ Java 之类的东西相比......
@JustinEthier 确实，除此之外，您还有 SRFI。
Common Lisp 的标准在原始页数上仍然大于 C，尽管 C 正在迎头赶上。

【解决方案9】：

拥有许多实现是有益的，因为每个实现在独特的地方都是最佳的。无论如何，现代主流语言都没有一种实现。想想 Python：它的主要实现是 CPython，但是多亏了 JPython，你也可以在 JVM 上运行 Python；多亏了 Stackless Python，您可以通过微线程获得大量并发；这样的实现将在某些方面兼容：JPython 与 Java 无缝集成，而 CPython 则没有。 Ruby 也是如此。

您不希望有许多与骨骼不兼容的实现。 Scheme就是这种情况，如果不重写大量代码，您就无法在实现之间共享库，因为Schemers无法就如何导入/导出库达成一致。由于核心领域的标准化，通用 Lisp 库 OTOH 更可能是可移植的，并且存在有条件地编写代码来处理每个实现的特性的设施。实际上，现在你可能会说 Common Lisp 是由它的实现定义的（想想 ASDF 包安装库），就像主流语言一样。

【讨论】：

我编写了一个 Lisp 应用程序，它使用 Clozure Common Lisp（CCL，以前的 MCL）编译为 Windows 可执行文件。该应用程序有一个在 Debian 服务器上运行的许可后端，该服务器在 CLISP 下运行。他们有共同的 Lisp 代码，并使用公共库。相同的加密库等等。