为什么解释语言和编译语言之间有如此清晰的界限？

Question

在学习像C或C++这样的编译语言时，你会了解编译器。为了运行你的代码，你必须首先编译它。编译代码会将其从文本表示形式转换为可以执行的内容。所得到的代码非常快，并且可以利用预处理器等。

在学习Python、Matlab或Ruby等动态语言时，您会了解解释器。为了运行你的代码，你只需要在解释器中输入它。因此，您可以在运行时处理代码，并动态更改程序的行为。这样做的缺点似乎是解释语言相当慢，而且缺乏明确的编译时间似乎使预处理器变得不可能。

然后是即时编译器，它的使用方式与解释语言类似，但与编译语言相比，性能缺陷较小。但它们通常不使用预处理器，也不输出可运行的二进制文件。

然后我学习了Lisp，它可以编译，解释等等，同时它既快又有一个强大的预处理系统(宏)。这似乎是Lisp世界中的常识，但在其他任何地方都不是。

为什么没有流行的C解释器或Python编译器？为什么解释语言和编译语言之间的鸿沟如此之大？(我知道有些项目可以编译Python或解释C语言，但一般来说，它们似乎不是很受欢迎)。

Answer 1

大多数流行的编译语言都是为编译而设计的:它们倾向于避免那些会导致难以生成高效编译代码的特性。这些语言特性包括方便的“动态”特性，如动态类型、非统一容器和即席对象名称空间。

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

相反，编译器必须复制解释语言的所有功能和行为，而不考虑成本。一般而言，这意味着用于解释语言的编译程序将承担解释器的大部分开销。例如，任何类型的eval()功能实际上都需要包含解释器。

最后，庞大的用户群、良好的支持和健壮的实现相辅相成的优势放大了这些影响。