Is Ruby Really an Interpreted Language If All of Its Implementations Are Compiled into Bytecode

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

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.

Is Ruby a scripting language or an interpreted language?

Things aren't just black and white. At the very least, they're also big and small, loud and quiet, blue and orange, grey and gray, long and short, right and wrong, etc.

Interpreted/compiled is just one way to categorize languages, and it's completely independent from (among countless other things) whether you call the same language a "scripting language" or not. To top it off, it's also a broken classification:

• Interpreted/compiled depends on the language implementation, not on the language (this is not just theory, there are indeed quite a few languages for which both interpreters and compilers exist)
• There are language implementations (lots of them, including most Ruby implementations) that are compilers, but "only" compile to bytecode and interpret that bytecode.
• There are also implementations that switch between interpreting and compiling to native code (JIT compilers).

You see, reality is a complex beast ;) Ruby is, as mentioned above, frequently compiled. The output of that compilation is then interpreted, at least in some cases - there are also implementations that JIT-compile (Rubinius, and IIRC JRuby compiles to Java bytecode after a while). The reference implementation has been a compiler for a long time, and IIRC still is. So is Ruby interpreted or compiled? Neither term is meaningful unless you define it ;)

But back to the question: "Scripting language" isn't a property of the language either, it depends on how the language is used - namely, whether the language is used for scripting tasks. If you're looking for a definition, the Wikipedia page on "Scripting language" may help (just don't let them confuse you with the notes on implementation details such as that scripts are usually interpreted). There are indeed a few programs that use Ruby for scripting tasks, and there are doubtless numerous free-standing Ruby programs that would likely qualify as scripts (web scraping, system administration, etc).

So yes, I guess one can call Ruby a scripting language. Of course that doesn't mean a ruby on rails web app is just a script.

Compiler and Interpreter in RUBY

Some languages can be both compiled into platform specific runtime executables and be interpreted. For example Ruby can be interpreted by multiple interpreters, native ruby, ree, etc as well as "compiled" into native java code (which is not exactly a native executable) by JRuby.

Compiled interpreted language

Compilation vs. "interpretation" is essentially a matter of implementation, not the language itself. For example, MRI Ruby 1.8 is interpreted, while MacRuby is compiled to native machine code. Both include an interactive REPL. All the languages I know that have at least one machine-code compiler and at least one REPL:

• Ruby
• Python
• Almost all Lisps (Lisp was the language that pioneered this technique, AFAIK)
• OCaml
• Haskell
• Forth

If we're counting compilation to bytecode as well as machine code, it's true of the vast majority of popular bytecode-compiled languages:

• Java
• Scala
• Groovy
• Erlang
• C#
• F#
• Smalltalk

What does it mean for a language to be ‘interpreted’?

I'll just be mean now and say that just about EVERY programming language is interpreted, whether it's a software (Ruby, Python, Java) or a hardware (C, C++) interpreter :)

For a real answer, while I don't know about the internal Ruby implementation, I'm sure as hell they don't parse the statement over and over and over again. While not using bytecode in the original implementation (or did they migrate already?), they use some intermediate representation (you can see it nicely when you want to write C-extensions for it), thus just executing those over and over again.

Confused about advantage of interpreted language

For each different machine architecture, wouldn't you need a different
compiler to interpret the same .class file into the machine language?
So if you need a different compiler for each different machine
architecture to interpret the same .class file into machine code, how
does this save you any work?

The above statement is your core misunderstanding.

Application developers write Java code that is compiled to byte code that can run on any compliant Java Virtual Machine.

The Java Virtual Machine interprets (and possibly compiles) this bytecode and executes the application. These JVMs are developed for the major architectures and operating systems, such as Windows/Mac/Linux on Intel. The JVM developers are a relatively small group of engineers, such as those from Oracle and Sun.

From the application developers' point of view, he or she only has to compile once because the byte code (in the .class file) can be executed on compliant JVMs. Application developers do not need to worry about the underlying architecture or OS; they only need to target the architecture of the JVM. The JVM developers are the ones who deal with the underlying layer.

---

Related Topics