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"