Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've recently started two introductory level courses - one using Python, the other Java.

I've read the answers to this Question but still have difficulty understanding how each ends up with machine code and what the main differences between the two models are:

  • Is an interpreter doing the same job as something like the JVM, just without the byte-code?
  • For python is the interpreter taking the high-level code and translating it into machine code?
  • The Java virtual machine needs to be installed on a machine for a java program to run on it - is it similar for python - if the interpreter is installed on the target machine then the python program will run?
  • Is the JVM (& .net framework) effectively byte-code interpreters?
share|improve this question
4  
You may want to verify what your terms mean; a software framework is orthogonal to an interpreter. –  Martijn Pieters Oct 12 '13 at 12:02
    
Will try to edit: had a feeling I was probably not far enough into the subject to try to post this question. In layman's terms I thought python uses an "interpreter" and java uses a "framework"? –  whytheq Oct 12 '13 at 12:06
4  
The line between compiler and interpreter is more blurry; CPython compiles, then interprets. Jython compiles then leaves it to the JVM to run, which can be interpreted or run directly on machine hardware (through a JIT, so further compilation, or a specialized Java processor). –  Martijn Pieters Oct 12 '13 at 12:08
    
Both Python and Java come with a lot of libraries pre-installed, that part is the framework. –  Martijn Pieters Oct 12 '13 at 12:09
    
@MartijnPieters I've attempted to edit the OP as "framework" was the wrong term to use. Do you now get the gist of my question? Does it need further edits? –  whytheq Oct 12 '13 at 12:10

3 Answers 3

Various comments have pointed out several ambiguities in the question and nuances to the answer, but the simple answer is no.

The JVM and .NET Framework are Just-In-Time Compilers. They are still compilers, and do all of the work of a compiler. They take an intermediate language (bytecode), optimize it, and convert it into machine code. The only difference between jitters and traditional compilers is when they do the compilation.

Interpreters, at least in their traditional definition, never compile code. Rather, they use code that is already compiled in order to execute the instructions they are given. This makes them faster to start up (since they don't need to compile anything) but generally slower to run, since there is overhead associated with each instruction.

If you wrote some code that did the following with a bunch of "switch" or "if" statements:

  • Read every line of a file
  • For every line that says "A", write "hello" to the screen
  • For every line that says "B", write "world" to the screen
  • For every other line, write "error" to the screen

Then this would be a (very crude) interpreter. It would not be a compiler of any kind, because all of the parts that actually run on the machine are in your program. It's doing parsing, but skipping the compile and link steps and going directly to execution based on a look-up table.

Another way to think of it - and I caution that this is purely an analogy for beginners and not a perfectly accurate technical description - is that interpreters essentially work on a line-by-line basis, whereas jitters will compile large chunks of the bytecode or possibly even the entire bytecode at the same time.

It's also often possible to precompile bytecode without a jitter (like Microsoft's NGen), since bytecode is typically very similar (but not identical) to the machine code. Interpreted code usually remains in a high-level language all the way to execution.

share|improve this answer
3  
I think it might be worth pointing out that no language in serious use today follows the traditional interpreter route. Almost all compile to bytecode and interpret from there. –  Winston Ewert Oct 14 '13 at 3:27
    
+1 this is excellent and a description I suspect I'll be re-visiting in the future. Before jitters did languages compile their programs direct to machine code, or was there originally just interpreters? ...ok- just reading @Kaydell's answer which is helping me with the evolution aspect. –  whytheq Oct 14 '13 at 7:52
    
@whytheq: yes, C, C++ and many other "traditional" languages are (usually) compiled directly to native code that is then executed by the machine directly. –  Joachim Sauer Oct 14 '13 at 9:14

There is a technical point of view:

  • a compiler is a processus which transforms a view of a program into another view, lowering the level of abstraction

  • a interpreter is a processus which execute a program, possibly first transforming the source in another view, but that one will not have a significantly lower level of abstraction.

There is a user point of view:

  • a compiler just transfor the program, it won't be executed there until another step

  • an interpreter will execute the program.

There is some confusion lying in the difference between the two.

A interpreter as a user see it sometimes use compilation techniques. Upfront, compiling the source program in a intermediate representation which is of a significantly lower level of abstraction than the source before interpreting it, maybe even going down to machine level (load and go compiler). Sometimes detecting heavily used code and compiling just that part or applying special optimization (just in time compilation).

Compilers don't have to go to machine language. C is a popular target for experimental languages. Another popular choice is a more or less machine like intermediate code which has to be interpreted after by a virtual machine, sometimes exposing the byte code as such, sometimes bundling the virtual machine with the byte code in one executable (it was the way one of the most popular and widespread Pascal implementation worked).

The virtual machine is itself an interpreter, but may apply compilation techniques as written above.

Compilers sometimes generate a more or less machine like description and delegates the true machine code generations to the linker. That generation may also be done at installation time (AS/400, and successors whose name I can't remember in the ?Series soup, is the longest during system I know which is using that method).


Now your questions:

  • Is an interpreter doing the same job as something like the JVM, just without the byte-code?

Sometimes yes, sometimes it is the bundling of the java compiler and the JVM.

  • For python is the interpreter taking the high-level code and translating it into machine code?

There are several Python interpreters and systems. I don't think the most popular one goes down to machine code.

  • The Java virtual machine needs to be installed on a machine for a java program to run on it - is it similar for python - if the interpreter is installed on the target machine then the python program will run?

The most popular Python implementation is an interpreter which need to be installed.

  • Is the JVM (& .net framework) effectively byte-code interpreters?

Yes, what I called "user level interpreters", they may apply true compilation techniques to offer better performance.

share|improve this answer
    
+1 ok - thanks: lots more information. Intrigued by this snippet Compilers don't have to go to machine language. C is a popular target for experimental languages .... so C is sort of built in to most computers? Then some languages have been designed to simply get interpreted into C? –  whytheq Oct 14 '13 at 20:41
    
No, C compilers are widely available and generating C is easier than generating assembly language or machine code. Those compilers just call a C compiler to process what they have generated. In the same spirit, some compilers generate assembly language and then call an assembler. (The question if an assembler is a compiler could be asked, I tend to think that there is no difference enough in the degree of abstraction to be the case, but I can understand the opposite POV). –  AProgrammer Oct 14 '13 at 20:53

The distinction between interpreted code and compiled code used to be more clear when I was first learning.

The first programming language that I learned was an early version of Microsoft BASIC which was text and it was interpreted by an interpreter.

Then, when I went to college, I learned to program in Pascal and C which are both compiled languages that compile down to machine code and don't need anything like a virtual machine to run.

Also, in college, I learned Unix shell-scripting which is text and is interpreted.

The distintion used to be more clear.

I think of Java and Python as both being compiled and interpreted. I see Python as being the right tool for the job when you want to be able to change something without having to recompile.

Java is good because you when you compile it, more of the bugs are found at compile-time.

I believe that both Python and Java are both compiled and interpreted. I see Java as being "more compiled" because more bugs are found at compile-time.

share|improve this answer
    
+1 thanks for this information - the history of the evolution of these modes helps to understand the current situation. –  whytheq Oct 14 '13 at 7:56
    
I don't think the "more compiled" distinction is directly tied to the execution method. You can have a very dynamic language that's still compiled to native code, or you can have a strictly-checked statically typed language that's interepreted. While there is a tendency for statically-typed languages to be "more compiled", it's not necessarily true! –  Joachim Sauer Oct 14 '13 at 9:16
    
@Joachim, my remark about my thinking of Java as being "more compiled" isn't about static versus dynamic typing. It's about the compiler finding errors at compile time. Java has runtime errors too, like Python does, but it seems to me that more errors are found in Java at compile-time than errors found in Python before running it. –  Kaydell Oct 14 '13 at 15:23

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.