Interpreted Language

The term "InterpretedLanguage" is archaic, and referred to a language that was evaluated as the programmer typed it instead of being compiled into a single monolithic "executable". Some early languages (Pascal and many early implementations of Basic, for example) could be either compiled or interpreted according to the desire of the programmer and system administrator. While the term is still used informally in some circles, most professionals agree that advances in both compiler and interpreter design and implementation have made the distinction moot in any rigorous sense.

Literally defined, a language which is not compiled directly into machine code. Most ScriptingLanguages are InterpretedLanguages, since they are executed directly from their textfile format, and no intermediate format is stored on disk. Some interpreted languages store an intermediate ByteCode (aka Pcode) file (such as a java .class file, or a python .pyc file), as well as a source code, to make the parsing/p-code creation stage faster when the same application code starts up the second time.

With the increase in machine speed in the last 20 years, interpreted languages are used more and more for tasks which were previously reserved for traditional compiled languages like C and C++.

The line is also very blurry now, between compilation and interpretation. Practically, working programmers refer to any language in which compile time is insignificant, or languages where it is common to distribute only the source or only the bytecode, or both the source and bytecode, but not common to distribute directly executable binaries, as InterpretedLanguages. Java/JIT blurs this line significantly, and it is generally considered an InterpretedLanguage, to distinguish it from traditional statically compiled languages like C and C++.

Isn't this more a characteristic of the implementation of a ProgrammingLanguage than of the language itself? E.g. there are interpreters for the CeeLanguage, and the JavaLanguage can be compiled to native code.

And to blur the line even further, there are interpreters that emulate particular machine architectures, so interpreting languages compiled for those architectures. And there are JIT interpreters that interpret machine code written for the architecture on which the JIT is running, and that perform dynamic optimisation of that code.

From ThereIsNothingPerlCannotDo:

what are the advantages and disadvantages of languages that interpret rather than compile? Does this have an incidence on the speed of the program itself?

InterpretedLanguages are usually more flexible than compiled ones, allowing programs to be written faster -- they optimize programmer time.

Programs written in interpreted languages usually run slower than in compiled languages, but most of the time it's not an issue.

(Note: in some cases, a non-optimized interpreted program will out-perform a non-optimized compiled one, because the library code in the interpreter comes pre-optimized -- e.g. I/O in perl is often faster than similar I/O in C because perl's I/O library has buffering built in, and C's doesn't [??what?? stdio? setvbuf? huh?]. You could build the buffering in your C program, but it's usually not done.)

Why are compiled languages considered to be faster than interpreted languages?

Because the compiled code executes the program the developer wrote. For interpreted languages, the code that's executing is a program that interprets the developer's program. In general, that other step adds time. Incremental compilers, modern processors with large caches, and interpreted programs that spend most of their time in calls to (compiled) library routines means this isn't always true, or when it is true, not always noticeable.

The term InterpretedLanguage is a common source of confusion. Just avoid it!

There is no InterpretedLanguage. In the general case you can interpret and/or compile any programming language. Implementations can be based on some interpretation.

More useful is it to say whether a particular implementation of a programming language is compiled or interpreted or both.

Also useful is it to say whether a particular implementation of a programming languages is interactive and incremental or not. An implementation allowing interactive use can be used from a listener, such that you can send methods to objects or call procedures. The implementation can also be incremental. This means that you can add, change or remove partial programs.

Typical Common Lisp systems for example are interpreted, compiled, interactive AND incremental.

I seem to remember that one of the reasons ChrisPressey had for creating BefungeLanguage was to prove that there are languages that are trivial to interpret, but impossible to compile. But yes, most languages can be compiled as well. In fact, many (most?) interpreters usually compile the program to ByteCode and then interpret the ByteCode.

Look, if it compiles to ByteCode, then it is a COMPILER. Simple as that. An interpreter does something completely different. An Interpreter executes statements of a representation of the source language.

So you consider Python to be a compiler? If I enter a statement in the interactive Python environment, Pythom compiles it to bytecode and executes it immediately. The bytecode is never stored on disk, but it's still there.

Python bytecode is stored on disk, as .pyc files. This is automatic for imported modules. Systems like Python and Perl that compile to bytecode and execute bytecodes are called 'bytecode interpreters'. This is very similar to the Java VM.

WhatIsAnInterpreter