programming-languages - 为什么解释语言和编译语言之间有如此明显的界限?

标签 programming-languages interpreted-language compiled-language

学习 C 或 C++ 等编译型语言时,您会了解编译器。为了运行你的代码,你必须先编译它。编译您的代码会将其从文本表示形式转换为可以执行的内容。生成的代码非常快,可以使用预处理器等。

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

然后是即时编译器,它们像解释语言一样使用,但与编译语言相比性能不足。但它们通常不支持预处理器,也不输出准备运行的二进制文件。

然后我学习了 Lisp,它可以被编译、解释以及你拥有什么,同时它既快速又具有强大的预处理系统(宏)。这似乎是 Lisp 世界的常识,但在其他任何地方都不是。

为什么没有流行的 C 解释器或 Python 编译器?为什么解释型语言和编译型语言之间存在巨大差异? (我知道存在一些可以编译 Python 或解释 C 的项目,但总的来说它们似乎不是很受欢迎)。

最佳答案

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

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

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

最后,这些影响因庞大的用户群、良好的支持和稳健的实现等相互增强的优势而得到放大。

关于programming-languages - 为什么解释语言和编译语言之间有如此明显的界限?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/15765671/

相关文章:

c++ - 有一个 n 个数字的数组。一个数字重复 n/2 次,其他 n/2 个数字不同

V8 中的 JavaScript 编译

haskell - 如何在解释模式下运行 Haskell 文件

perl - Perl 是编译型编程语言还是解释型编程语言?

module - 从多个项目导入 D 模块

r - Lua 替代 optim()

c++ - 如何处理在方法中间在内存中移动的对象?

java - scala.runtime 中这些 Java 文件的用途是什么?

bytecode - 每次到达该行时是否重新解释解释语言的代码?

ruby - Ruby 是脚本语言还是解释型语言?