An interpreted language is a programming language that is run by an interpreter which directly performs the actions implied by the code, rather than emitting a machine code translation.1 This is contrasted to a compiler, which reads the program and then translates it (and possibly optimizes it) and saves the result as object code or an executable before the program can be run.

The interpreter may directly interpret the source code and run it as it reads it, or it may read all of the source at once and tokenize and parse it first and then interpret the results. Other interpreters may save the tokenized bytecode or require an external compiler to first translate the source to bytecode which is then interpreted. Other interpreted languages don't care, and can run the untokenized source code directly, or run compiled byte code with a slight memory and performance improvement.

An interpreter may also be combined with a Just In Time compiler to optimize performance of the language.

Many interpreted languages, especially in unix, have very simple, weak data types, and have little or no support for complex data types. These languages typically have heavy reliance on external programs to accomplish more complicated tasks, and are used as glue to connect different applications. These are typically called scripting languages.2 Some of these languages are so weak that they are not generally considered programming languages, as some of them lack Turing completeness.

The distinction between script languages, byte compiled languages, and outright compiled languages may be a bit fuzzy, especialy when tokenization, parsing, interpretation, and JIT compiling are all happening at the same time (or interleaved anyway).

Interpreters typically have the advantage over compilers that you can run the program immediately without the edit-compile-link-run process. Usually you can run individual statements in the interpreter independently from a larger program just by typing them in. Also, interpreted programs, even when saved as bytecode, tend to be machine independent, as they do not rely on cpu or architecture specific instructions.

Of course, there is very little to stop someone from writing an interpreter for a compiled language or a compiler for an interpreted language, although there may be some fundamental differences in the architecture of the language that might encourage either compiling or interpreting more.

In unix, any program that will take commands directly from an input file is considered an interpreter. You can create an executable script in unix merely by marking the script executable with chmod and making the first line

 #!/path/to/interpreter 
Obviously, the interpreter must also know to skip this line.

Some interpreted languages make it easy to construct strings and feed them back to the interpreter for execution. This is a very powerful feature, and such constructs can make a program difficult to compile.

Examples of scripting languages include: sh, awk, ed, sed, perl, expect, tcl, PostScript, JavaScript, MSDOS batch file, Windows Scripting Host

Examples of interpreted languages that can (or must) save their bytecode include: basic, perl, python, java, lisp, Forth, prolog, smalltalk

Debuggers like gdb try very hard to make C act a bit like an interpreted language, but don't quite make it, especially since that's not their main goal.

/msg me if you want me to add your favorite interpreted language.

1 The Dragon Book, page 3, "Interpreters"
2 thanks to FOLDOC: "scripting language"

Log in or registerto write something here or to contact authors.