Interpreter vs Compiler: What Are the Differences and Benefits?

[phinds]

Indeed. Especially when numbers go large, e.g. the number and kind of clients, frequency of changes, or the amount of data. If a system slows down, then you need to know which component does what in order to optimize it.

I also find it annoying when I find myself (as I did just last night) in the situation of debugging several sections of new code, realizing that I now understand what I need to change in one section and wanting to execute on to the next (independent) section but having to stop and recompile to get rid of the error before the debugger will LET me go on.

 

[pbuk]

Using a language, like R, in an interpreter like RStudio is quite a different interaction from the normal use of a compiler. Some of these languages have quite a large user community.

Yes that is true: a Read, Evaluate, Print Loop (REPL) only really makes sense in the context of an interpretive language.

 

[pbuk]

Indeed. Especially when numbers go large, e.g. the number and kind of clients, frequency of changes, or the amount of data. If a system slows down, then you need to know which component does what in order to optimize it.

I don't see any difference between compilers and interpreters in any of these situations, for example performance profiling exists for both Python and C++, or do I misunderstand what you mean?

 

[pbuk]

I also find it annoying when I find myself (as I did just last night) in the situation of debugging several sections of new code, realizing that I now understand what I need to change in one section and wanting to execute on to the next (independent) section but having to stop and recompile to get rid of the error before the debugger will LET me go on.

Hmmm, perhaps the lesson there is not to work on two independent changes at once! Of course I would do not practice what I have just preached...

 

[phinds]

Hmmm, perhaps the lesson there is not to work on two independent changes at once! Of course I would not practice what I have just preached...

I agree and I would not normally do that but this was new code that I knew needed several kinks worked out and I wasn't even totally clear on how a couple of issues should be handled. The issues were independant of each other. It would have been nice to have been working in an interpretive environment.

 

[fresh_42]

I don't see any difference between compilers and interpreters in any of these situations, for example performance profiling exists for both Python and C++, or do I misunderstand what you mean?

The number and kind of clients effects the availability of necessary software, especially for interpreter code.
The frequency of changes effects the necessity for compiled distributions.
The amount of data is directly related to response times and as such where the needed data are provided, which therefore depends on the system.

 

[harborsparrow]

The "machine language" to which many languages compile (or are translated/interpreted) is now a virtual machine. The virtual machine is a program. For both user applications written in a given programming language, and the virtual machine that "executes" the instructions, there may be what is called "just in time" compilation, which is arguably a hydrid between compilation and interpretation. This topic gets very involved; the more you look, the more complexities there are. And none of it means anything without also studying the loading and linking mechanisms for programs and their libraries.

So, define yourselves blue in the face about interpreters vs. compilers; it won't be adequate to reflect what is really happening with most programming languages. So as @pbuk said, it's no longer a contemporary subject of much debate in comp. sci. circles.

 

[pbuk]

The number and kind of clients effects the availability of necessary software, especially for interpreter code.

Oh you mean 'clients' in the sense of 'customers', I was thinking of devices connected to a server. Yes of course you need to distribute packages that your customers can install and use, and if you are targeting Windows or iPhones or Android this means executable code compiled for the platform - but the most widely installed customer platform today is web browsers running the interpreted languange JavaScript! In the mid 80s consumer market in the UK it meant Spectrum BASIC (also interpreted). So I don't think there is a difference of principle here, just transient market factors.

The frequency of changes effects the necessity for compiled distributions.

How is this different whether you are distributing a new C# runtime or a bundle of Python scripts - they still need to be loaded on to the target hardware?

The amount of data is directly related to response times and as such where the needed data are provided, which therefore depends on the system.

Sorry, I still don't understand this point.

 

[fresh_42]

Oh you mean 'clients' in the sense of 'customers'

I did not.

I was thinking of devices connected to a server.

So did I.

In grown network structures or on remote offline clients you can run an executable, but not necessarily code that must be interpreted, or vice versa.

How is this different whether you are distributing a new C# runtime or a bundle of Python scripts - they still need to be loaded on to the target hardware?

Have you ever updated a server software, and changed an index.html? If so. then you know the difference. And if databases are involved, it's even worse.

Sorry, I still don't understand this point.

A complied program gives you control over the data, an interpreted code not necessarily.

 

[PeterDonis]

Interpreters take the source code, translate it to machine code, and executes this statement immediately and one statement at a time.

This is not necessarily true. In Python, for example, the interpreter first "compiles" the source code to byte code, and then executes the byte code; the byte code can be thought of as "machine code" for a virtual machine implemented by the interpreter, but this type of "machine" is many levels removed from the actual hardware machine. Also, if the interpreter is executing a source code file, it does not execute the file one statement at a time; it compiles the entire file to byte code and then executes the byte code.

If you are using the Python interpreter interactively, in the REPL, then each statement or expression you enter into the REPL is compiled to byte code and executed immediately, yes. But even then the byte code is not the same as hardware machine code, as above.