Scheme 和 Common Lisp 之间的实际区别是什么？ （或任何其他两种 Lisp 方言）
注意：我并不是在问学习哪个、哪个更好，或者诸如此类的问题。
我选择了 SICP 的免费版本，因为我觉得阅读它会很好（我听说过一些好东西）关于它，我对编程的这一方面很感兴趣）。
我知道Scheme 是Lisp 的一种方言，我想知道：Scheme 和Common Lisp 之间的实际区别是什么？
似乎有很多关于“CL 有一个更大的 stdlib...方案不适合现实世界的编程...”，但没有实际的东西说“这是因为 CL 是这个/有这个”。
Note: I am not asking which to learn, which is better, or anything like that.
I picked up the free version of SICP because I felt it would be nice to read (I've heard good stuff about it, and I'm interested in that sort of side of programming).
I know Scheme is a dialect of Lisp and I wondered: what is the actual difference is between Scheme and, say, Common Lisp?
There seems to be a lot about 'CL has a larger stdlib...Scheme is not good for real-world programming..' but no actual thing saying 'this is because CL is this/has this'.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这是一个有点棘手的问题，因为差异既是技术上的，也是（更重要的是，在我看来）文化上的。答案只能提供不精确、主观的观点。这就是我要在这里提供的内容。有关一些原始技术详细信息，请参阅 Scheme Wiki。
Scheme 是一种建立在提供优雅、一致、经过深思熟虑的基础语言基础原则之上的语言，实用和学术应用语言都可以在此基础上构建。
您很少会发现有人用纯粹的 R5RS（或 R6RS）Scheme 编写应用程序，并且由于简约标准，大多数代码都无法跨Scheme 实现移植。这意味着，如果您想编写某种最终用户应用程序，您将必须仔细选择您的方案实现，因为该选择将在很大程度上决定您可以使用哪些库。另一方面，设计实际应用程序语言的相对自由意味着Scheme 实现通常提供在其他地方闻所未闻的功能；例如，PLT Racket 使您能够使用静态类型并提供非常具有语言感知能力的 IDE。
超越基本语言的互操作性是通过社区驱动的 SRFI 流程提供的，但任何给定 SRFI 的可用性因实现而异。
大多数Scheme方言和库都专注于函数式编程习惯，例如递归而不是迭代。当您想要进行 OOP 时，您可以将各种对象系统加载为库，但与现有代码的集成在很大程度上取决于 Scheme 方言及其周围的文化（例如，Chicken Scheme 似乎比 Racket 更面向对象）。
交互编程是Scheme子社区的另一个不同点。MIT的Scheme以强大的交互性支持而闻名，而PLT Racket则感觉更加静态。无论如何，交互式编程似乎并不是大多数Scheme子社区的核心关注点，而且我还没有看到一个与大多数Common Lisps类似的交互式编程环境。
Common Lisp 是一种久经考验的语言，专为实际编程而设计。它充满了丑陋的缺陷和兼容性问题——与Scheme 优雅的极简主义截然相反。但它本身也更具特色。
Common Lisp 已经孕育了一个相对较大的可移植库生态系统。通常，即使在应用程序部署之后，您也可以随时切换实现，而不会遇到太多麻烦。总体而言，Common Lisp 比 Scheme 更加统一，而且更激进的语言实验（如果有的话）通常会作为可移植库嵌入，而不是定义全新的语言方言。因此，语言扩展往往更加保守，但也更加可组合（并且通常是可选的）。
普遍有用的语言扩展（例如外部函数接口）不是通过正式手段开发的，而是依赖于所有主要 Common Lisp 实现上可用的准标准库。
语言习惯是函数式、命令式和面向对象方法的疯狂混合，一般来说，Common Lisp 感觉更像是一种命令式语言，而不是函数式语言。它也非常动态，可以说比任何流行的动态脚本语言都更加动态（例如，类重新定义适用于现有实例，并且条件处理系统内置了交互性），并且交互式探索性编程是“Common Lisp 方式。”这也反映在 Common Lisp 可用的编程环境中，几乎所有这些环境都提供与正在运行的 Lisp 编译器的某种直接交互。
Common Lisp 具有内置对象系统 (CLOS)、比单纯的异常处理强大得多的条件处理系统、运行时可修补性以及各种内置数据结构和实用程序（包括臭名昭著的 LOOP 宏，一种迭代子语言，对于Scheme来说太丑陋了，但非常有用，更不用说，以及类似 printf 的格式化机制，在格式字符串中支持 GOTO）。
由于基于图像的交互式开发，并且由于语言较大，Lisp 实现通常比 Schema 实现更难跨操作系统移植。例如，让 Common Lisp 在嵌入式设备上运行并不适合胆小的人。与 Java 虚拟机类似，您也往往会在虚拟内存受到限制的机器（例如基于 OpenVZ 的虚拟服务器）上遇到问题。另一方面，方案实现往往更加紧凑和便携。 ECL 实施质量的提高在一定程度上缓解了这一点，但其本质仍然是正确的。
如果您关心商业支持，有几家公司提供自己的 Common Lisp 实现，包括图形 GUI 构建器、专用数据库系统等。
总结，Scheme是一种设计更加优雅的语言。它主要是一种具有一些动态特性的函数式语言。它的实现代表了具有鲜明特征的各种不兼容的方言。 Common Lisp 是一种成熟、高度动态、多范式的语言，具有各种丑陋但实用的功能，其实现在很大程度上相互兼容。与 Common Lisp 相比，Scheme 方言往往更加静态且交互性较差； Common Lisp 实现往往更重且安装起来更棘手。
无论您选择哪种语言，我都祝您玩得开心！ :)
This is a bit of a tricky question, since the differences are both technical and (more importantly, in my opinion) cultural. An answer can only ever provide an imprecise, subjective view. This is what I'm going to provide here. For some raw technical details, see the Scheme Wiki.
Scheme is a language built on the principle of providing an elegant, consistent, well thought-through base language substrate which both practical and academic application languages can be built upon.
Rarely will you find someone writing an application in pure R5RS (or R6RS) Scheme, and because of the minimalistic standard, most code is not portable across Scheme implementations. This means that you will have to choose your Scheme implementation carefully, should you want to write some kind of end-user application, because the choice will largely determine what libraries are available to you. On the other hand, the relative freedom in designing the actual application language means that Scheme implementations often provide features unheard of elsewhere; PLT Racket, for example, enables you to make use of static typing and provides a very language-aware IDE.
Interoperability beyond the base language is provided through the community-driven SRFI process, but availability of any given SRFI varies by implementation.
Most Scheme dialects and libraries focus on functional programming idioms like recursion instead of iteration. There are various object systems you can load as libraries when you want to do OOP, but integration with existing code heavily depends on the Scheme dialect and its surrounding culture (Chicken Scheme seems to be more object-oriented than Racket, for instance).
Interactive programming is another point that Scheme subcommunities differ in. MIT Scheme is known for strong interactivitiy support, while PLT Racket feels much more static. In any case, interactive programming does not seem to be a central concern to most Scheme subcommunities, and I have yet to see a programming environment similarly interactive as most Common Lisps'.
Common Lisp is a battle-worn language designed for practical programming. It is full of ugly warts and compatibility hacks -- quite the opposite of Scheme's elegant minimalism. But it is also much more featureful when taken for itself.
Common Lisp has bred a relatively large ecosystem of portable libraries. You can usually switch implementations at any time, even after application deployment, without too much trouble. Overall, Common Lisp is much more uniform than Scheme, and more radical language experiments, if done at all, are usually embedded as a portable library rather than defining a whole new language dialect. Because of this, language extensions tend to be more conservative, but also more combinable (and often optional).
Universally useful language extensions like foreign-function interfaces are not developed through formal means but rely on quasi-standard libraries available on all major Common Lisp implementations.
The language idioms are a wild mixture of functional, imperative, and object-oriented approaches, and in general, Common Lisp feels more like an imperative language than a functional one. It is also extremely dynamic, arguably more so than any of the popular dynamic scripting languages (class redefinition applies to existing instances, for example, and the condition handling system has interactivity built right in), and interactive, exploratory programming is an important part of "the Common Lisp way." This is also reflected in the programming environments available for Common Lisp, practically all of which offer some sort of direct interaction with the running Lisp compiler.
Common Lisp features a built-in object system (CLOS), a condition handling system significantly more powerful than mere exception handling, run-time patchability, and various kinds of built-in data structures and utilites (including the notorious LOOP macro, an iteration sublanguage much too ugly for Scheme but much too useful not to mention, as well as a printf-like formatting mechanism with GOTO support in format strings).
Both because of the image-based, interactive development, and because of the larger language, Lisp implementations are usually less portable across operating systems than Scheme implementations are. Getting a Common Lisp to run on an embedded device is not for the faint of heart, for example. Similarly to the Java Virtual Machine, you also tend to encounter problems on machines where virtual memory is restricted (like OpenVZ-based virtual servers). Scheme implementations, on the other hand, tend to be more compact and portable. The increasing quality of the ECL implementation has mitigated this point somewhat, though its essence is still true.
If you care for commercial support, there are a couple of companies that provide their own Common Lisp implementations including graphical GUI builders, specialized database systems, et cetera.
Summing up, Scheme is a more elegantly designed language. It is primarily a functional language with some dynamic features. Its implementations represent various incompatible dialects with distinctive features. Common Lisp is a fully-fledged, highly dynamic, multi-paradigm language with various ugly but pragmatic features, whose implementations are largely compatible with one another. Scheme dialects tend to be more static and less interactive than Common Lisp; Common Lisp implementations tend to be heavier and trickier to install.
Whichever language you choose, I wish you a lot of fun! :)
一些基本的实际差异：
(function ...)将函数显式转换为值，并使用(funcall ...)< 显式调用存储在值中的函数/code>nil（空列表）被认为是 false（例如在if中），并且是唯一的 false 值。在Scheme中，空列表被认为是true，并且（不同的）#f是唯一的false值Some basic practical differences:
(function ...), and explicitly call a function stored in a value using(funcall ...)nil(the empty list) is considered false (e.g. inif), and is the only false value. In Scheme, the empty list is considered true, and (the distinct)#fis the only false value这是一个很难公正地回答的问题，特别是因为许多 LISP 人员将 Scheme 归类为 LISP。
乔什·布洛赫（Josh Bloch）（这个类比可能不是他的发明）将选择一种语言描述为类似于选择一家当地酒吧。从这个角度来看，
“Scheme”酒吧里有很多编程语言研究人员。这些人花了大量的注意力在语言的含义上，保持它的定义明确和简单，并讨论创新的新功能。每个人都有自己的语言版本，旨在让他们探索自己特定的编程语言角落。方案人员非常喜欢他们从 LISP 中获取的带括号的语法；它灵活、轻量且统一，消除了语言扩展的许多障碍。
“LISP”酒吧？嗯...我不应该发表评论；我在那里呆的时间还不够:)。
That's a hard question to answer impartially, especially because many of the LISP folks would classify Scheme as a LISP.
Josh Bloch (and this analogy may not be his invention) describes choosing a language as being akin to choosing a local pub. In that light, then:
The "Scheme" pub has a lot of programming-languages researchers in it. These people spend a lot of attention on the meaning of the language, on keeping it well-defined and simple, and on discussing innovative new features. Everyone's got their own version of the language, designed to allow them to explore their own particular corner of programming languages. The Scheme people really like the parenthesized syntax that they took from LISP; it's flexible and lightweight and uniform and removes many barriers to language extension.
The "LISP" pub? Well... I shouldn't comment; I haven't spent enough time there :).
schema：
common lisp：
这是一些要点，当然还有更多，我现在不记得了。
scheme:
common lisp:
that are some points, sure there are many more, which i don't remember right now.