从 quicklisp 下载数据看， sbcl 占据绝对优势，个人觉得会比较适合上手，数据：
sly 的作者感觉挺厉害的，好多厉害的项目都是他在维护或者开发
你用的是 master branch 吗？切到 release branch 试试。
指环王的特效，任天堂的很多游戏的建模，都是在 Symbolics Lisp Machine 上完成的。
应用基本上都是 Classical AI, 数学，艺术，工业系统。
release还是同样的错误
用clisp 也会出错 但出错的文件不一样
acl2不编译的话 能用吗? 慢一点没关系。
我应该先看看sbcl 再尝试编译acl2
Common Lisp 有流行过吗？表示怀疑。
情况比Scheme好吧，一大堆人讨论Common Lisp，r7rs一直憋不出来，还老被Racket抢话题。
我个人一直想写Scheme，不过没机会。。。现在我r6rs基本忘光了，只记得点r5rs。。。
现代 Common Lisp 都是编译执行的，只不过因为是增量编译看起来像是解释执行的。
Roswell 我一次编译成功后也没更新过，没想到今天推荐一下反而没法编译了。不然还是直接用 quicklisp 吧。现在没电脑，不方便 debug
ACL2 先别着急下，把这个页面 http://www.cs.utexas.edu/users/moore/publications/how-to-prove-thms/index.html 的材料过一遍，了解一下这是什么，然后根据自己的需要，兴趣和精力考虑一下要不要学这个，建议对 Common Lisp 有一定了解以后（最低标准是看完 Common Lisp: A Gentle Introduction to Symbolic Computation 或同等水平）再开始看。这个不是传统意义上的编程语言，入门的门槛相对有点高，应用也比较偏门。
3 个赞
也许lisp就像以色列人，人数不多却被拣选。
很多语言吸收了lisp的特性，lisp本身已经不那么独特了。Is Lisp Still Unique
个人感觉，学习lisp需要更多的记忆量。Java之类的语言API都是按对象组织，便于记忆，有规律可循，没用过的API都能猜个大概，而lisp的API要记住很多才能流畅使用。
不太会用 Discourse 的回复功能，见谅。
保守估计，主流语言至少要学五种才能涵盖所有 CL 的特性，反过来，没有什么语言的特性 CL 是做不到的。
我觉得应该这样说。如果五门语言的特性都塞入一个语言，你觉得这个语言不够复杂吗？
编译时就是运行时，运行时也能使用编译器。
能做元编程的语言都能解决这个功能所解决的问题。当然不如 Lisp 那么简洁明了。
高度可扩展的 parser 和 printer。
没有意义 +1。每个人都自己做一个 DSL 生态还发展不发展？
别的语言的确没有的功能，multiple-return-value
没有意义 +2。默认只能用第一个返回值，但如果要用剩下的返回值就比较麻烦。相反，其他语言使用 tuple 强迫你去 destruct 在一般情况下反倒看起来更简单。（同样，我觉得大部分语言不抄这个是有理由的……
比绝大多数语言短
和我个人的经验不符。当然我没做过什么大项目就是了。
这一点是和第三方生态紧密结合的。用 Django 我可以在几小时内开发出一个勉强能用的基于 Markdown 的多用户博客系统（而且是带后台的）。我不觉得对于此类项目 CL 可以在开发者工作量上打败 Django，除非 CL 有一个媲美 Django 的库。这也是我为什么这么强调第三方生态的原因。
和最快的语言在同一梯队
来源请求。
从 Racket, Haskell, Python, Java, Ruby 抄个库信手拈來，对于 Java, C, C++ 都可以调用。
换句话说，哪个语言不是呢？对第三方库来说，有没有 idiomatic 的 binding 是比较重要的（如果每个项目都自己封装……倒也不是不行）
几年前我大概翻过 Quicklisp 列表……猜猜看有几个 toy 单元测试框架？至少可用于生产环境的生态是严重缺乏的。
大量项目的巴士指数小于等于 1。就这一点我觉得足够让严肃项目望而却步了。
此外还有很多库是缺乏的。这也阻碍了快速的原型开发。
看起来大型严肃项目和小型原型项目都不太适合呢。
有一个语言标准并不代表语言实现者不会加扩展。
所以每个语言实现的扩展互不兼容，并催生了若干个弥合这种不兼容的库，它们之间还不兼容。
LISP 的核心是符号处理语言，而不是什么 lambda calculus 的模型。
你说的对，这里我错了。
Rust 在 Haskell 群体看来，设计是相当孱弱的，也就能骗骗只会写 C++ 的土包子。
Rust 的设计目标和使用场景是相当明确的，设计是围绕这个目的展开的，我不觉得强行把 Haskell 之类的语言按在这些目标上会更好。
总结：CL 仍然有一些遗产，比如 CLOS 乃至 Metaobject Protocol。但我目前没有觉得这些贡献足够 CL 成为一门主流语言。作为一个语言，CL 有趣吗？是挺有趣的，我学习 CL 时得到了极大乐趣，远甚于 Ruby 之流。但由于 CL 的历史包袱（深入学习就感觉到处都是坑），和不成器的生态环境，于是 CL 注定是冷门的… 如果有一门设计得更干净的 CL，也不是不可能，但 CL 本身我觉得是不行了。
2 个赞
Scala，C++，Haskell 都是往特性复杂发展，在特定方面不亚于或超过 CL。
GHC 编译成二进制后接近 200 MB，多数都是语言扩展和优化用的 rewrite rules。这还不算汇编生成后端。
我在 CL 以后看了一大圈，交互性上，Julia，Worfram 之类天生有集成交互交互环境的才能比，而且这两个还不能算是通用语言。哪怕 JVM，Idris 之流，都没有 90 年的的 Lisp Machine 强。元编程能用来做在线 Debug 调试吗？
Parser 和 Printer 的意义就在于创造新语言，Racket，Haskell，Ocaml 都是新语言和编译器技术的温床，Idris, Rust, Curry, F* 新语言源源不断出来，CL 没有理由放弃自己的强项，而且相比这几个有更多实用编程语言的特新。要说原型开发，Mozilla FireFox, MS .NET，Haskell 原型开发都用了 Common Lisp，都是大型项目原型开发。
从实现角度，Multiple return value 比 tuple 快。tuple 需要分配额外内存（无非就是个 vector），multiple return 只要从栈上返回。
随便搜 Django + Common Lisp 的结果，虽然不见得成熟，但是能说明从别的社区抄个库是多么简单而正常的事。说生态不强是伪命题。
测试框架: https://www.cliki.net/test%20framework
设计得更干净是什么意思？我认为应该加更多的功能，但是能把大部分功能拆分成独立的标准模块，减少维护难度和提高代码复用，统一生态环境的同时保留用途各异的具体实现众多的优势。
1 个赞
而且相比这几个有更多实用编程语言的特新 ？？？？？？
这几个 OOP paradigm 方面都不如 MOP 强。也就是说，操作系统编程方面完败。
Common Lisp 实现在对 OOP 的优化上甚至到了 access class slot 比 access hash table 还快的程度。
tuple不需要从堆上分配内存啊
C++: A tuple is typically implemented as a compile time linked-list (std::tuple)
C#: Sequential Memory Allocation: like arrays, tuples are allocated in sequential memory
Python seems unstable, when allocating big memory. For example, the following C++ code creates a tuple of tuples: … When the n is small, say 100, the code works fine. when n is big, say 10,000, Python has trouble allocating memory, saying: “Exception exceptions.IndexError: ‘tuple index out of range’ in ‘garbage collection’ ignored Fatal Python error: unexpected exception during garbage collection Aborted”
够证明了吧，就算是 Haskell 的 Tuple 从特性上看可以推测出是用 vector 实現的。事实上 Yale Haskell 就是这樣实現 tuple 的。
别的不说，C++的tuple完全可以直接返回一个struct，至少我写的就是。(use_allocator没有主流的实现鸟它)
返回struct，完全可以是在栈上完成的。
至于其它语言，实现的时候，也完全可以在栈上返回，它们不这么干，可能是因为有GC。
而且，要有完全的闭包的话，值也不能是栈上的。
作为数据结构，从栈上分配没法直接赋值给其它变量，只有在显式使用指针的语言才能控制，在只有 reference 的语言只能靠给编译器提示来控制。