嵌入式语言：Lua vs Common Lisp (ECL)

我以前没有嵌入过 Common Lisp，但我已经用 Lua 和两种特定的 Scheme 实现（Gambit-C 和 GNU Guile）嵌入过它们。

我认为 Scheme 是一个很好的嵌入式语言，因为它很灵活而且不是太臃肿。Gambit-C 特别适合这个用途，因为它允许你运行解释脚本，也可以将你的代码编译成 C 代码。在我的测试中，Gambit-C 生成的 C 代码只比手写的 C 代码慢一点点（例如，一个在 C 中运行了 0.030 秒的特定测试在 Gambit 中运行了 0.040 秒！）。Gambit 还有一个非常好的 FFI（外部函数接口），基本上就是具有特殊语法的 Scheme，用于编写绑定到 C 库（ObjC 和 C++ 也直接支持）的库。Gambit 还具有一个非常好的 repl，带有一些调试功能。

Guile 也相当不错，实际上比 Lua 运行得更快（我目前所知道的最快的解释语言——Guile 近年来取得了巨大的进展）。但是由于 Gambit-C 可以编译成非常快的代码，所以除非我打算在最终版本中使用解释代码，否则我通常不会使用 Guile。

Lua 有闭包，但你不会得到 Scheme 中的续延，也不会得到宏。不过仍然可以做相当数量的函数式编程。它没有完整的对象系统（如 CL 中的 CLOS），但它确实有表格，它们可以用来相当容易地实现基于类的继承和基于原型的继承。此外，Lua 有一个非常好的 C API，非常令人愉快。它是基于堆栈的，并以一种您完全不必担心 Lua 内存管理的方式设计。API 非常清晰和有组织，有很多伟大的文档和示例代码。Lua 无法编译，但它确实使用字节码（始终如此——当您向 Lua VM 发送代码时，它总是首先将该代码编译为字节码，然后再运行它）。

至于 Common Lisp，我认为它可能不是很适合作为嵌入式语言。原因是 CL 太庞大了。通常，嵌入轻量级语言是可取的，因为它将使用您提供给它的平台/库而不是太多外部内容。

因此，我认为你不能错选 Gambit-C、Guile 或 Lua，它们都非常好用。CL 很强大，但我认为它太大了，不适合作为嵌入式语言。

我只能同意 Lua 很糟糕。它在使用纯命令式的函数式编程风格时效果很好，但不适用于具有大型层次结构的面向对象编程，例如永远不要尝试将典型的 GUI 工具包（如 GTK）包装成 Lua 层次结构，性能会非常糟糕。

我仍然使用 Lua，因为它非常轻，可以同时运行数十个解释器，并且最终用户可以理解如何编写代码片段，而 Lisp/Scheme 的语法只适合专家使用（缺少语法）。

现在，我会补充说， mruby 3.0 已经发布，是一个很好的嵌入语言。不幸的是，在此期间，所有人都转向了 JavaScript。