为什么解释型语言和编译型语言之间存在如此明显的界限？

Question

当学习像C或C++这样的编译语言时，您需要了解编译器。为了运行代码，您必须首先将其编译。编译代码将其从文本表示转换为可执行的内容。生成的代码非常快，并且可以使用预处理器等工具。

当学习像Python、Matlab或Ruby这样的动态语言时，您需要了解解释器。为了运行代码，您只需将其键入解释器中。因此，您可以在运行时玩弄代码并更改程序的行为。这种方法的缺点似乎是解释性语言的速度相对较慢，而且没有明显的编译时间，这使得预处理器不可能实现。

然后有即时编译器，类似于解释性语言，但与编译语言相比，性能损失较小。但它们通常不支持预处理器，并且不输出可运行二进制文件。

然后我学习了Lisp，它可以被编译、解释和其他形式使用，同时又快又具有强大的预处理系统（宏）。这在Lisp世界中似乎很普遍，但在其他地方却不是这样。

为什么没有流行的C解释器或Python编译器？为什么解释性语言和编译语言之间存在如此强烈的分界线？（我知道一些项目可以编译Python或解释C，但总体上它们似乎不是很流行。）

- bastibe

---

有适用于C语言的解释器：http://root.cern.ch/drupal/content/cint。 - Max

我想挑战你的前提的某些部分。预处理器是完全独立的，可以在任何编译器或解释器之前运行很长时间（它们操作源代码，而不是二进制代码）。C和C兼容语言内置了特定的预处理器，但这有其他原因（希望获得廉价的编译时抽象）。并且，正如你在下一句中承认的那样，有Python编译器和C解释器。它们似乎不是主流，但有使用它们的社区。无论如何，“没有解释器/编译器”显然是错误的。 - user395760

@delnan，没错，“没有解释器/编译器”是错误的。我已经修正了。感谢您指出这一点。关于预处理器：许多编译语言似乎都内置了这些（特别是所有派生自C的语言），但很少有解释性语言有一个。除了Lisp，它既可以编译又可以解释，并且有一个预处理器。而且那非常有用，那么为什么其他语言没有呢？ - bastibe

@bastibe 请举例说明。我知道的唯一（稍微流行一点的）语言是C，Obj-C（它是C的一个真正的超集），以及C++（它几乎是C的超集）。然而，比这更多的“编译”语言，例如Pascal + 衍生物（特别是Delphi），Java，C#，ML + 衍生物，Haskell和Rust。您可以使用预处理器运行任何源代码，并且实际上有些人确实这样做。两个例子：我见过有人建议在Python代码上运行m4，一些Haskell项目在其代码上运行C预处理器。 - user395760

@delnan 说得对，我没有从那个角度去看。所以某种程度上来说，C预处理器在C衍生语言中有一些独特性。大多数其他语言没有内置（或广泛使用的）预处理器。有趣。谢谢你指出这一点。 - bastibe

许多人会说编译器是机器语言解释器。 - Dru

Answer 1

大多数流行的编译语言是从头开始设计为编译的：它们倾向于避免那些难以生成高效编译代码的功能。这些语言特性包括方便的“动态”特性，如动态类型、非均匀容器和特定对象命名空间。

因此，编译语言的解释器不能利用可用于解释语言的动态特性，但缺乏编译实现的性能优势。

相反，编译器必须复制解释语言的所有特征和行为，无论代价如何。一般来说，这意味着解释语言的编译程序将承载大量解释器的开销。例如，任何类型的 eval() 功能都需要包含解释器。

最后，这些影响因大型用户群、良好支持和强大实现而被放大。

- comingstorm