问如果Ruby的所有实现都编译成字节码，那么Ruby真的是一种解释型语言吗？

EN

是的，Ruby仍然是一种解释型语言，或者更准确地说，Matz的Ruby解释器(MRI)，这是人们在谈论Ruby时通常谈论的东西，它仍然是一种解释器。编译步骤只是为了减少代码的执行速度，而不是一次又一次地解释和重新解释相同的代码。

现在几乎每种语言都是“编译”的，如果你把字节码算作正在编译的话。甚至Emacs Lisp也是编译的。Ruby是一个特例，因为直到最近，它还没有编译成字节码。

我认为您对将语言描述为“编译”与“解释”的效用的质疑是正确的。不过，一个有用的区别是，该语言是否直接从用户代码创建机器代码(例如x86汇编程序)。C、C++、许多Lisp和支持JIT的Java都可以，但Ruby和Perl不支持。

不懂的人会把任何有单独手工编译步骤的语言称为“编译的”，而不是“解释的”。

这确实是一个微妙的问题。过去，“解释的”语言被解析并转换成执行速度更快的中间形式，但执行它们的“机器”是一个非常特定于语言的程序。“编译”的语言被翻译成由运行它的计算机支持的机器代码指令。早期的区别是非常基本的--静态作用域和动态作用域。在静态类型语言中，变量引用几乎可以在几条机器指令中解析为内存地址--您确切地知道变量在调用框架中引用的位置。在动态类型的语言中，您必须搜索(在A列表或调用框架上)来查找参考资料。随着面向对象编程的出现，引用的非直接性质扩展到更多的概念--类(类型)、方法(函数)，甚至语法解释(嵌入式DSL，如regex)。

事实上，这种区别可以追溯到70年代末，不是编译语言和解释语言之间的区别，而是它们是在编译环境中运行还是在解释环境中运行。例如，Pascal (我学习的第一种高级语言)首先在加州大学伯克利分校的Bill Joy的pxp解释器上运行，后来他在编译器上编写了pcc。相同的语言，在编译和解释环境中都可用。

有些语言比其他语言更具动态性，某些东西的含义--类型、方法、变量--依赖于运行时环境。这意味着无论编译与否，都存在与执行程序相关的大量运行时机制。第四，Smalltalk，新闻，Lisp，都是这样的例子。最初，这些语言需要如此多的机制来执行(而不是C或Fortran)，因此它们是自然的解释。

甚至在Java出现之前，就有人试图通过技巧、技术来加速复杂的、动态的语言的执行，这些技巧变成了线程编译、即时编译等等。

然而，我认为是Java，它是第一种广泛传播的语言，真正混淆了编译器/解释器之间的鸿沟，具有讽刺意味的是，这并不是为了让它运行得更快(尽管，这也是如此)，而是为了让它可以在任何地方运行。通过定义自己的机器语言和“机器”java字节码和VM，Java试图成为一种编译成接近任何基本机器的语言，但实际上不是任何真正的机器。

现代语言将所有这些创新结合在一起。有些语言具有传统解释语言(ruby、lisp、smalltalk、python、perl(!))的动态的、开放式的、直到运行时才知道你得到了什么的特性，有些语言试图具有规范的严格性，允许传统编译语言(java、scala)基于深度类型的静态错误检测。所有这些都编译成实际的机器无关表示(JVM)，以获得编写一次就能在任何地方运行的语义。

那么，编译还是解释？我想说，两者都是最好的。所有的代码都在源代码中(有文档)，改变任何东西都会立即产生效果，简单的操作几乎和硬件一样快，支持复杂的操作并且足够快，硬件和内存模型在不同的平台上是一致的。

当今语言中更大的争论可能是它们是静态类型还是动态类型，也就是说，它们的运行速度并不是有多快，而是错误会被编译器预先发现(代价是程序员必须指定相当复杂的类型信息)，还是会在测试和生产过程中出现错误。