blocks|key|3120711|text|您可以使用irb交互式Ruby+Shell以交互方式运行Ruby程序。虽然它可以生成中间字节码，但它肯定不是传统意义上的“编译器”。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3120712|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Interactive_Ruby_Shell^0|5|3|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You can run Ruby programs interactively using <a href="http://en.wikipedia.org/wiki/Interactive_Ruby_Shell" rel="nofollow noreferrer">irb</a>, the Interactive Ruby Shell. While it may generate intermediate bytecode, it's certainly not a "compiler" in the traditional sense.

blocks|key|3120752|text|是的，Ruby仍然是一种解释型语言，或者更准确地说，Matz的Ruby解释器(MRI)，这是人们在谈论Ruby时通常谈论的东西，它仍然是一种解释器。编译步骤只是为了减少代码的执行速度，而不是一次又一次地解释和重新解释相同的代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3120753|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Yes, Ruby's still an interpreted language, or more precisely, Matz's Ruby Interpreter (MRI), which is what people usually talk about when they talk about Ruby, is still an interpreter. The compilation step is simply there to reduce the code to something that's faster to execute than interpreting and reinterpreting the same code time after time.

blocks|key|3120835|text|编译后的语言通常编译成机器码，而不仅仅是字节码。不过，一些字节码生成器实际上可以进一步将字节码编译成机器码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3120836|字节码本身只是用户编写的文字代码和虚拟机之间的中间步骤，但它仍然需要由虚拟机解释(就像JVM中的Java和具有操作码缓存的PHP一样)。|3120837|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

A compiled language is generally compiled into machine code, as opposed to just byte code. Some byte code generators can actually further compile the byte code into machine code though.

Byte code itself is just an intermediate step between the literal code written by the user and the virtual machine, it still needs to be interpreted by the virtual machine though (as it's done with Java in a JVM and PHP with an opcode cache).

blocks|key|3120889|text|现在几乎每种语言都是“编译”的，如果你把字节码算作正在编译的话。甚至Emacs+Lisp也是编译的。Ruby是一个特例，因为直到最近，它还没有编译成字节码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3120890|我认为您对将语言描述为“编译”与“解释”的效用的质疑是正确的。不过，一个有用的区别是，该语言是否直接从用户代码创建机器代码(例如x86汇编程序)。C、C%2B%2B、许多Lisp和支持JIT的Java都可以，但Ruby和Perl不支持。|3120891|不懂的人会把任何有单独手工编译步骤的语言称为“编译的”，而不是“解释的”。|3120892|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Nearly every language is "compiled" nowadays, if you count bytecode as being compiled. Even Emacs Lisp is compiled. Ruby was a special case because until recently, it wasn't compiled into bytecode.

I think you're right to question the utility of characterizing languages as "compiled" vs. "interpreted." One useful distinction, though, is whether the language creates machine code (e.g. x86 assembler) directly from user code. C, C++, many Lisps, and Java with JIT enabled do, but Ruby, Python, and Perl do not.

People who don't know better will call any language that has a separate manual compilation step "compiled" and ones that don't "interpreted."

blocks|key|3333712|text|这可能有点离题但是..。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3333713|Iron+Ruby是一个基于.net的ruby实现，因此通常被编译成字节码，然后在运行时编译成机器语言(即不解释)。此外(至少对于其他.net语言，我假设对于ruby)+ngen可以用来提前生成编译的本机二进制文件，因此这实际上是ruby代码的机器代码编译版本。|offset|length|3333714|entityMap|0|LINK|mutability|MUTABLE|url|http://www.ironruby.net/|1|http://msdn.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx^0|0|0|9|0|2D|4|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]|$D|U|E|V|1|W]]|A|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]|N|$5|I|J|K|A|$L|O]]]]

This is possibly a little off topic but...

<a href="http://www.ironruby.net/" rel="nofollow noreferrer">Iron Ruby</a> is a .net based implementation of ruby and therefore is usually compiled to byte code and then JIT compiled to machine language at runtime (i.e. not interpreted). Also (at least with other .net languages, so I assume with ruby) <a href="http://msdn.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx" rel="nofollow noreferrer">ngen</a> can be used to generate a compiled native binary ahead of time, so that's effectively a machine code compiled version of ruby code.

blocks|key|349037|text|这确实是一个微妙的问题。过去，“解释的”语言被解析并转换成执行速度更快的中间形式，但执行它们的“机器”是一个非常特定于语言的程序。“编译”的语言被翻译成由运行它的计算机支持的机器代码指令。早期的区别是非常基本的--静态作用域和动态作用域。在静态类型语言中，变量引用几乎可以在几条机器指令中解析为内存地址--您确切地知道变量在调用框架中引用的位置。在动态类型的语言中，您必须搜索(在A列表或调用框架上)来查找参考资料。随着面向对象编程的出现，引用的非直接性质扩展到更多的概念--类(类型)、方法(函数)，甚至语法解释(嵌入式DSL，如regex)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|349038|事实上，这种区别可以追溯到70年代末，不是编译语言和解释语言之间的区别，而是它们是在编译环境中运行还是在解释环境中运行。例如，Pascal+(我学习的第一种高级语言)首先在加州大学伯克利分校的Bill+Joy的pxp解释器上运行，后来他在编译器上编写了pcc。相同的语言，在编译和解释环境中都可用。|offset|length|style|BOLD|349039|有些语言比其他语言更具动态性，某些东西的含义--类型、方法、变量--依赖于运行时环境。这意味着无论编译与否，都存在与执行程序相关的大量运行时机制。第四，Smalltalk，新闻，Lisp，都是这样的例子。最初，这些语言需要如此多的机制来执行(而不是C或Fortran)，因此它们是自然的解释。|349040|甚至在Java出现之前，就有人试图通过技巧、技术来加速复杂的、动态的语言的执行，这些技巧变成了线程编译、即时编译等等。|349041|然而，我认为是Java，它是第一种广泛传播的语言，真正混淆了编译器/解释器之间的鸿沟，具有讽刺意味的是，这并不是为了让它运行得更快(尽管，这也是如此)，而是为了让它可以在任何地方运行。通过定义自己的机器语言和“机器”java字节码和VM，Java试图成为一种编译成接近任何基本机器的语言，但实际上不是任何真正的机器。|349042|现代语言将所有这些创新结合在一起。有些语言具有传统解释语言(ruby、lisp、smalltalk、python、perl(!))的动态的、开放式的、直到运行时才知道你得到了什么的特性，有些语言试图具有规范的严格性，允许传统编译语言(java、scala)基于深度类型的静态错误检测。所有这些都编译成实际的机器无关表示(JVM)，以获得编写一次就能在任何地方运行的语义。|349043|那么，编译还是解释？我想说，两者都是最好的。所有的代码都在源代码中(有文档)，改变任何东西都会立即产生效果，简单的操作几乎和硬件一样快，支持复杂的操作并且足够快，硬件和内存模型在不同的平台上是一致的。|349044|当今语言中更大的争论可能是它们是静态类型还是动态类型，也就是说，它们的运行速度并不是有多快，而是错误会被编译器预先发现(代价是程序员必须指定相当复杂的类型信息)，还是会在测试和生产过程中出现错误。|349045|entityMap^0|0|2X|3|3I|3|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@$D|X|E|Y|F|G]|$D|Z|E|10|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|11|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|12|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|13|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|14|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|15|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|16|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|U|$]]

A subtle question indeed...
It used to be that "interpreted" languages were parsed and transformed into an intermediate form which was faster to execute, but the "machine" executing them was a pretty language specific program. "Compiled" languages were translated instead into the machine code instructions supported by the computer on which it was run. An early distinction was very basic--static vs. dynamic scope. In a statically typed language, a variable reference could pretty much be resolved to a memory address in a few machine instructions--you knew exactly where in the calling frame the variable referred. In dynamically typed languages you had to search (up an A-list or up a calling frame) for the reference. With the advent of object oriented programming, the non-immediate nature of a reference expanded to many more concepts--classes(types), methods(functions),even syntactical interpretation (embedded DSLs like regex). 

The distinction, in fact, going back to maybe the late 70's was not so much between compiled and interpreted languages, but whether they were run in a compiled or interpreted environment.
For example, Pascal (the first high-level language I studied) ran at UC Berkeley first on Bill Joy's pxp interpreter, and later on the compiler he wrote pcc. Same language, available in both compiled and interpreted environments.

Some languages are more dynamic than others, the meaning of something--a type, a method, a variable--is dependent on the run-time environment. This means that compiled or not there is substantial run-time mechanism associated with executing a program. Forth, Smalltalk, NeWs, Lisp, all were examples of this. Initially, these languages required so much mechanism to execute (versus a C or a Fortran) that they were a natural for interpretation. 

Even before Java, there were attempts to speed up execution of complex, dynamic languages with tricks, techniques which became threaded compilation, just-in-time compilation, and so on.

I think it was Java, though, which was the first wide-spread language that really muddied the compiler/interpreter gap, ironically not so that it would run faster (though, that too) but so that it would run everywhere. By defining their own machine language and "machine" the java bytecode and VM, Java attempted to become a language compiled into something close to any basic machine, but not actually any real machine.

Modern languages marry all these innovations. Some have the dynamic, open-ended, you-don't-know-what-you-get-until-runtime nature of traditional "interpreted languages (ruby, lisp, smalltalk, python, perl(!)), some try to have the rigor of specification allowing deep type-based static error detection of traditional compiled languages (java, scala). All compile to actual machine-independent representations (JVM) to get write once-run anywhere semantics. 

So, compiled vs. interpreted? Best of both, I'd say. All the code's around in source (with documentation), change anything and the effect is immediate, simple operations run almost as fast as the hardware can do them, complex ones are supported and fast enough, hardware and memory models are consistent across platforms. 

The bigger polemic in languages today is probably whether they are statically or dynamically typed, which is to say not how fast will they run, but will the errors be found by the compiler beforehand (at the cost of the programmer having to specify pretty complex typing information) or will the errors come up in testing and production.

blocks|key|3121141|text|至于我从上海RubyConf+2011上得到的信息，Matz正在开发一个“MRuby”(代表Matz's+Ruby)，目标是在嵌入式设备上运行。Matz说，MRuby将提供将ruby代码编译成机器码的能力，以提高速度并减少嵌入式设备上(有限的)资源的使用。所以，有各种各样的Ruby实现，并且肯定不是所有的都在运行时被解释。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3121142|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

As for the information I got from RubyConf 2011 in Shanghai, Matz is developing a 'MRuby'(stands for Matz's Ruby) to targeting running on embedded devices. And Matz said the the MRuby, will provide the ability to compile the ruby code into machine code to boost the speed and decrease the usage of the (limited) resources on the embedded devices. So, there're various kind of Ruby implementation and definitely not all of them are just interpreted during the runtime.

In the chosen answer for <a href="https://stackoverflow.com/questions/716543/what-is-the-significance-for-ruby-programmers-of-saps-new-implementation-of-ruby">this question about Blue Ruby</a>, Chuck says:

<blockquote>
 All of the current Ruby
 implementations are compiled to
 bytecode. Contrary to SAP's claims, as
 of Ruby 1.9, MRI itself includes a
 bytecode compiler, though the ability
 to save the compiled bytecode to disk
 disappeared somewhere in the process
 of merging the YARV virtual machine.
 JRuby is compiled into Java .class
 files. I don't have a lot of details
 on MagLev, but it seems safe to say it
 will take that road as well.
</blockquote>

I'm confused about this compilation/interpretation issue with respect to Ruby.

I learned that Ruby is an interpreted language and that's why when I save changes to my Ruby files I don't need to re-build the project.

But if all of the Ruby implementations now are compiled, is it still fair to say that Ruby is an interpreted language? Or am I misunderstanding something?

Is Ruby really an interpreted language if all of its implementations are compiled into bytecode?

虚拟机

编译器

解释器

Java

Perl

在为选择的答案中，查克说：所有当前的Ruby实现都被编译成字节码。与SAP的声明相反，从Ruby1.9开始，MRI本身就包含了一个字节码编译器，尽管在合并YARV虚拟机的过程中，将编译后的字节码保存到磁盘的能力消失了。将JRuby编译成Java .class文件。我没有太多关于MagLev的细节，但似乎可以肯定地说，它...

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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