In my compiler design courses, I have learned about and worked with a clear academic definition of an interpreter and a compiler, with an interpreter being
a program Pi from a language M capable of taking a program i from a language I and an input and executing i with the given input and the correct semantics for I on a machine capable of running programs from M
and a compiler being
a program Pc that, when given a valid program i from a language I as an input, produces a semantically equivalent program o in a language O
This definition would clearly put the usual execution of Java bytecode by a JVM in the domain of interpretation, no matter how much JIT compilation is done. (Of course, Java is also compiled before, from Java code to Java bytecode.) I have encountered opinions in discussions on this site that clearly and vehemently state the opposite, i.e. that Java Bytecode execution thingies are compilers. Since I am about to make the leap from academics to industry, I am a little bit confused here:
Is the above definition of interpreters false from the viewpoint of industry people in general? Or is it just false for Java people? Is the view of Java as a fully compiled language an alternate, but minority view? Or just a few loonies?
(PS: Please do not move this to cstheory. I have deliberately put this question here since I would really like to get the view of the professional industrial, not the academic community.)
Best Answer
Well, the two definitions aren't mutually exclusive. An interpreter can contain a compiler (in fact, most modern interpreters contain at least a bytecode compiler).
But I think the intuitive definition most people here use is something like:
By this distinction, an "interpreter" is usually an order of magnitude slower than a "compiled" program. So when we're talking about performance, this definition is more useful than the classic CS definition.