【发布时间】：2017-07-21 16:40:18
【问题描述】：
据说Python/Ruby是conceptually close to Common Lisp。
我特别想知道 - 据说可以为现代 CL 实现提供高性能，Python Compiler for CMU Common Lisp 是否可以用作高性能 Python/Ruby 编译器实现的潜在基础？
注意：我意识到语言 不必 很快。我想念为什么如果有改进的地方他们必须变慢。
原始措辞，用于前 5 个 cmets 的上下文：
标题：
为什么 Python / Ruby 比 Common Lisp 慢这么多？
主体：
这不是要发动任何语言战争，只是好奇——
据互联网报道，Python/Ruby 和 Common Lisp 之间的性能差异是巨大的，尽管 CL 更具动态性、同音性等。
我读到 Common Lisp 的实现速度很快，因为实现了 Python Compiler for CMU Common Lisp 的版本。
我的问题是 - 如果这些年来速度“技术”一直存在，为什么现代动态语言不使用它？
【问题讨论】：
-
性能在每种语言中的优先级不同...
-
Rails 不是因为性能问题而放弃了吗？
-
Python 和 Ruby（以及它们之前的 Perl）出现在 Common Lisp 引发的场景中，即“程序员时间”（有时）比“计算机时间”更有价值。即，写一些 fast 执行速度 enough 的东西比花很多时间在稍微快一点的东西上要好。另一个主要原因是 Python 和 Ruby（和 R）是 glue 语言。他们将 C 库称为真正的东西。他们“自己”做的唯一事情是（磁盘和网络）i/o。
-
Common Lisp 是在编译器作者的影响下设计的。它可能有很多动态特性，但它们旨在允许将代码快速编译成某种东西，并且规范允许实现在与编译交互时放弃一些动态（例如定义和编译
foo，然后是bar调用（和内联）foo然后重新定义foo但bar不会更改为这个新定义）。词法作用域允许堆栈分配，宏和tagbody允许简洁的代码具有良好的性能。哈希表在 CL 中有点痛苦。大多数 python 对象都是哈希表。 -
Common Lisp 是在 1980 年代中期设计的，目的是统一当时竞争的 Lisp 实现。其中一些具有良好的编译器，并且他们当前的用户期望 Lisp 能够被编译成具有合理性能的东西。如果用户要从他们当前的实现切换到 CL，他们不会想要性能回归。 1980 年代的计算机速度很慢，因此“合理的性能”按今天的标准转化为良好的性能。
标签： python ruby performance common-lisp