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

There's (to my knowledge) no such thing as an interpretted "language" or a compiled "language".

Languages specify the syntax and meaning of the code's keywords, flow constructs and various other things, but I am aware of no language which specifies whether or not it must be compiled or interpreted in the language spec.

Now if you're question is when you use a language compiler vs a language interpreter, it really comes down to the pro's/con's of the compiler vs. the interpreter and the purpose of project.

For instance, you may use the JRuby compiler for easier integration with java libraries instead of the MRI ruby interpreter. There are likely also reasons to use the MRI ruby interpreter over JRuby, I'm unfamiliar with the language though and can't speak to this.

Touted benefits of interpreters:

• No compilation means the time from editing code to testing the app can be diminished
• No need to generate binaries for multiple architectures because the interpreter will manage the architecture abstraction (though you may need to still worry about the scripts handling integer sizes correctly, just not the binary distribution)

Touted benefits of compilers:

• Compiled native code does not have the overhead of an interpreter and is therefore usually more efficient on time and space
• Interoperability is usually better, the only way for in-proc interoperation with scripts is via an interpreter rather than a standard FFI
• Ability to support architectures the interpreter hasn't been compiled for (such as embedded systems)

However, I would bet in 90% of cases it goes something more like this: I want to write this software in blub because I know it well and it should do a good job. I'll use the blub interpreter (or compiler) because it is the generally accepted canonical method for writing software in blub.

So TL;DR is basically, on a case by case basis comparison of the interpreters vs the compilers for your particular use case.

Also, FFI: Foreign Function Interface, in other words interface for interoperating with other languages. More reading at wikipedia

It's important to remember that interpreting and compiling are not just alternatives to each other. In the end, any program that you write (including one compiled to machine code) gets interpreted. Interpreting code simply means taking a set of instructions and returning an answer.

Compiling, on the other hand, means converting a program in one language to another language. Usually it is assumed that when compilation takes place, the code is compiled to a "lower-level" language (eg. machine code, some kind of VM bytecode, etc.). This compiled code is still interpreted later on.

With regards to your question of whether there is a useful distinction between interpreted and compiled languages, my personal opinion is that everyone should have a basic understanding of what is happening to the code they write during interpretation. So, if their code is being JIT compiled, or bytecode-cached, etc., the programmer should at least have a basic understanding of what that means.

What’s the difference between compiled and interpreted language?

The difference is not in the language; it is in the implementation.

Having got that out of my system, here's an answer:

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