Compiled vs. Interpreted Languages

A compiled language is one where the program, once compiled, is expressed in the instructions of the target machine. For example, an addition "+" operation in your source code could be translated directly to the "ADD" instruction in machine code.

An interpreted language is one where the instructions are not directly executed by the target machine, but instead read and executed by some other program (which normally is written in the language of the native machine). For example, the same "+" operation would be recognised by the interpreter at run time, which would then call its own "add(a,b)" function with the appropriate arguments, which would then execute the machine code "ADD" instruction.

You can do anything that you can do in an interpreted language in a compiled language and vice-versa - they are both Turing complete. Both however have advantages and disadvantages for implementation and use.

I'm going to completely generalise (purists forgive me!) but, roughly, here are the advantages of compiled languages:

• Faster performance by directly using the native code of the target machine
• Opportunity to apply quite powerful optimisations during the compile stage

And here are the advantages of interpreted languages:

• Easier to implement (writing good compilers is very hard!!)
• No need to run a compilation stage: can execute code directly "on the fly"
• Can be more convenient for dynamic languages

Note that modern techniques such as bytecode compilation add some extra complexity - what happens here is that the compiler targets a "virtual machine" which is not the same as the underlying hardware. These virtual machine instructions can then be compiled again at a later stage to get native code (e.g. as done by the Java JVM JIT compiler).

A language itself is neither compiled nor interpreted, only a specific implementation of a language is. Java is a perfect example. There is a bytecode-based platform (the JVM), a native compiler (gcj) and an interpeter for a superset of Java (bsh). So what is Java now? Bytecode-compiled, native-compiled or interpreted?

Other languages, which are compiled as well as interpreted, are Scala, Haskell or Ocaml. Each of these languages has an interactive interpreter, as well as a compiler to byte-code or native machine code.

So generally categorizing languages by "compiled" and "interpreted" doesn't make much sense.

Start thinking in terms of a: blast from the past

Once upon a time, long long ago, there lived in the land of computinginterpreters and compilers. All kinds of fuss ensued over the merits ofone over the other. The general opinion at that time was something along the lines of:

• Interpreter: Fast to develop (edit and run). Slow to execute because each statement had to be interpreted intomachine code every time it was executed (think of what this meant for a loop executed thousands of times).
• Compiler: Slow to develop (edit, compile, link and run. The compile/link steps could take serious time). Fastto execute. The whole program was already in native machine code.

A one or two order of magnitude difference in the runtimeperformance existed between an interpreted program and a compiled program. Other distinguishing points, run-time mutability of the code for example, were also of some interest but the majordistinction revolved around the run-time performance issues.

Today the landscape has evolved to such an extent that the compiled/interpreted distinction is pretty much irrelevant. Manycompiled languages call upon run-time services that are notcompletely machine code based. Also, most interpreted languages are "compiled" into byte-codebefore execution. Byte-code interpreters can be very efficient and rival some compiler generatedcode from an execution speed point of view.

The classic difference is that compilers generated native machine code, interpreters read source code andgenerated machine code on the fly using some sort of run-time system. Today there are very few classic interpreters left - almost all of themcompile into byte-code (or some other semi-compiled state) which then runs on a virtual "machine".