Um, sorry, but this isn't correct.

Although there might be a slight bit of gray area, the simple difference between compiled and interpreted languages is that compiled languages produce a binary consisting of bytes that mean something specific to the CPU of the computer the program is running on. The program is executed pretty much by just sending those bytes to the CPU.

In an interpreted language, the "binary" (whether it be a straight text file or a bytecode file that has been produced from a text file) is, at runtime, processed by another program which _does_ consist of the bytes the CPU understands directly. Interpreted languages put an extra layer of software between the executable and the program.

In practical terms, there are three differences:

1) Interpreted language programs are typically much easier to transfer between machines (not necessarily between operating systems).
2) Compiled languages typically have the potential (depending how much work goes into the compiler, amongst other things) to be _far_ faster than interpreted languages.
3) Compiled languages require an often very painful, ugly compilation step to produce a binary. In interpreted languages (that produce bytecode), this phase is usually quite a bit easier, if not invisible.

Yes, a language can have both an interpreter and a compiler, but almost always one of those plays a trivial role in the use of the language, because it is usually very difficult to get the semantics of the two to match and at the same time produce enough of a benefit to make the effort worthwhile. 

Ken


On 14-Oct-05, at 9:29 AM, Alex Stapleton wrote:

You can see that the entire, interpreted vs compiled debate is  

utterly meaningless and that only implementation specific details  

actually matter. e.g. Java is native if you compile it with GCJ. x86  

is interpreted if you run it under a VM like VirtualPC.



-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to