我想从Lisp家族学习一些语言。它可能是CL或Scheme，并尝试将其用于Web编程。纯娱乐。我有很多C ++经验（专业发展）。
但是我希望我的选择是没有遗产的现代语言（在语言本身和库中），因为我想从一开始就学习好的设计模式。
我无法判断什么是更好的：CL或Scheme。 CL拥有更大更优质的库和框架（Weblocks），但我听说它在语法和库方面有很多遗产。 Scheme是另一种：简单，简洁的语法但是库很差。如果它没有遗产，我更喜欢CL。
我不喜欢学习像C ++这样的另一个怪物。 CL是否像Lisp系列中的C ++一样？而Scheme就像是C＃或Java - “修改过的”C ++。
编辑： 我想用函数式写作，OOP可能是，但可选。
答案 0 :(得分：18)
计划是在70年代中期发明的。
CL从1982年开始开发。第一个定义发表于1984年：Common Lisp the Language。
该计划没有遗产或更现代是一个神话。 Scheme已经在Common Lisp之前定义了近十年。 Scheme仍然有s-expressions，cons单元格，符号，car，cdr，cons等遗留物。该计划有遗产使其成为Lisp语言家族的一员，其源于1958年的第一个Lisp语言。
Scheme的最初目标是成为一种比传统Lisp更接近lambda演算的小型语言。因此，词法绑定作为Lisp语言的默认值是第一个。
不幸的是，它在许多其他方面都是一种玩具语言。它只有一小部分功能，是编写程序所需的功能，比如一种有用的错误处理方式。
Common Lisp十年后的设计目标是不同的。它旨在编写商业软件，大型软件，高性能软件。另一个目标是它是Lisp方言主线（这里是Maclisp）的传统，因此已经拥有大型图书馆或程序的程序员不会从零开始。
Common Lisp从第一天开始就添加了许多被认为有用的功能：
等等。
在90年代中期，CL的修订版已经发布。它补充道：由于CL作为Scheme开始变大，因此一些设计决策使得CL比Scheme更好用。例如，Scheme只有原始参数列表，仅此一点就使得库更难使用。
Scheme对其标准进行了更多修订，但基本的设计决策仍然存在，社区正在努力解决错误处理，记录，对象系统等基础问题。 R6RS最终引起争议，我同意批评者的看法。我认为R6RS的方向和内容都非常令人失望。
还有另外两种观点：半标准和个别实施。
Scheme社区产生了许多半标准扩展。这应该被视为成功。
OTOH的实施在Scheme中广泛分歧。对他们几乎没有共识。有许多非常小的实现和许多大型实现。
CL实现OTOH已经包含一个大型语言，因此它们不会从小开始。关键字参数就在那里。对象系统也是如此。随着时间的推移，一些应用程序确保它们可以在许多实现上大致保持不变。此外，个别实现还添加了许多功能，如Unicode支持，线程，并发执行等等。
所以当前的Lisp实现可以有很多功能。
Common Lisp和Scheme共享Lisp的遗产：符号，s表达式，汽车，cdr，cons，cons基于单元格的列表，......等等。
Common Lisp有一些不太好的部分，但在标准中定义。一个例子是CL符号名称在内部是大写的。 “序列”的概念在标准中是不可扩展的。和更多。各个实现处理CL标准的许多限制。因此，例如在大多数实现中，I / O系统使用CLOS编写，条件基于CLOS，SBCL有可扩展序列等等。
CL可能是一种庞大的语言，但它不是C ++。许多部件设计出色，易于使用。由于Common Lisp是一种可编程编程语言，因此用户也可以修复许多问题。你不喜欢内置的LOOP吗？使用ITERATE，如果您更喜欢或甚至自己编写。
答案 1 :(得分：11)
Common Lisp有许多特性，其中一些可能源于遗留（不知道我的Lisp历史是否足够肯定）。有很多瑕疵，如功能命名和参数顺序的不一致。但实际语言本身虽然有点奇怪，但相当明智。不像C ++ ......
Scheme也有瑕疵，但我认为程度较轻。另一方面，与CL相比，Scheme的标准库很小，因此疣的空间也较小。 ： - ）
除了普通的CL和Scheme实现之外，你还有一些“下一代Lisps”，例如Clojure（可能是它们中最“现代”的 - 从头开始设计用于重度并发）和newLISP，以及“下一代计划”，Racket（以前称为PLT计划）。
我个人对Racket印象非常深刻，我希望有一天能用它做些什么。
答案 2 :(得分：4)
我是Scheme的粉丝，因为它从一开始就设计为一致且简单，但仍然具有大多数其他语言所没有的高级功能。出于这些原因，它在教育和学术界尤其受欢迎。
如果您想学习函数式编程，我建议使用本书The Little Schemer以及Racket或Petite Chez Scheme（两者都是免费的）。