Difference between compiled and interpreted programming languages

When considering about implementation of different programming languages they have used different approaches to achieve their goals. Compiled and interpreted are two different implementations which are used by people who developed programming languages.

I wanted to know what are these interpreted and compiled programming languages, what are the differences, advantages and disadvantages of those approaches. In this post I'm presenting simple and clear answers, I found in my small research of interpreted and compiled programming languages.

[This content is from a answer to a stackoverflow question about programming languages.]

• In a compiled implementation, the original program is translated into native machine instructions, which are executed directly by the hardware.
  
• In an interpreted implementation, the original program is translated into something else. Another program, called "the interpreter", then examines "something else" and performs whatever actions are called for. Depending on the language and its implementation, there are a variety of forms of "something else". From more popular to less popular, "something else" might be
  • Binary instructions for a virtual machine, often called bytecode, as is done in Lua, Python, Ruby, Smalltalk, and many other systems (the approach was popularized in the 1970s by the UCSD P-system and UCSD Pascal)
  • A tree-like representation of the original program, such as an abstract-syntax tree, as is done for many prototype or educational interpreters
  • A tokenized representation of the source program, similar to Tcl
  • The characters of the source program, as was done in MINT and TRAC

One thing that complicates the issue is that it is possible to translate (compile) bytecode into native machine instructions. Thus, a successful intepreted implementation might eventually acquire a compiler. If the compiler runs dynamically, behind the scenes, it is often called a just-in-time compiler or JIT compiler. JITs have been developed for Java, JavaScript, Lua, and I daresay many other languages. At that point you can have a hybrid implementation in which some code is interpreted and some code is compiled.

And here is another answer for a  post, I found in same site that helps to further understanding of the concept. It discuss about the advantages and disadvantages as well.

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).