Tom's Guide | Tom's Hardware | Tom's Games
![]() |
![]() |
![]() |
hi
i would like to know the tradeoffs when one uses a compiler instead of interpreter or vice versa
i know just about the basics of compiler and interpreter
please explain with an application as to why tht application will work better if the initial code is compiled instead of interpreted or vice versa
thanks in advance
amogh

Forgive me, but if you knew about the trade off between a compiler and an interpreter, you wouldnt need to ask the question.
A compiler compiles the source coude in a form that can be used directly by the computer. At run time the code is to run the programme is already there.
An interpreter reads each line of the source code and converts it to machine code on the fly. This happens every time the programme is run. Consequently it is very slow as it is converting source code to machine code while the programme is running.
A compiler does it once and thats it.
So the trade off is speed.
DOS BASIC was interpreted. QBASIC could be either. VB, C++ and all modern high level languages are compliled. Nobody uses an interpreter for anything serious although an interpreted programme can be a good teaching aid.
Stuart

'Java is an interpreted language'
umm.. not purely. Java has to be compiled into byte-code before it can be interpreted.. same with python. Even perl isnt truely interpreted. It gets compiled into a parse tree before interpretation. I believe this all classifies as kind of a two step interpretation. Most of the shell languages are purely interpreted though.

"Nobody uses an interpreter for anything serious although an interpreted programme can be a good teaching aid."
Java is interpreted. Java is used world-wide for important and mission-critical applications. The interpreter I wrote for a tiny programming language I wrote for college, is not "serious" but was important to my grade.
To answer the question. Speed is in fact the trade off. Think in terms of this analogy:
1) Read a book a page at a time
2) Read a book, line by lineObviously, reading a whole page at one time (compiler) is faster than reading a book one line after the next (Interpreter).
IR

The two cant really be compaired... If I write a 3 line program to strip some useless files out of a directory, and will most likely never use the script again, I'm certainly not going to use c or java... which by the way, is an exception to the rule.. any code you need to compile first is certainly not interpreted. The byte-code(which gets compiled) is what is interpreted... that in itself certainly stretches the definition.

I believe I will jump in on this one...gpp is correct (by my definitions of "interpreted" and "compiled"). Java is neither compiled nor interpreted (or some would say it is both compiled and interpreted.) I don't know about Python, but Perl can be interpreted or compiled, or somewhere in between, depending on the tools you are using (there is a native-code compiler for perl.) It is typically interpreted, however.
I have heard of native-code compilers for Java as well, but I suspect they actually just wrap the necessary parts of the JVM in the EXE, like VB used to do.
Anyhow, back to the topic at hand: Tradeoffs. Everybody has mentioned that speed is a major tradeoff, but nobody has mentioned what you get in return for speed...Interpreted languages are much more portable. One file can be run on many machines without having to re-compile.
Also, when a language is interpreted, it gets freedom to do many things that are very cumbersome for a compiled language...Dynamic types of variables, for example. Interpreted languages also have less overhead when setting up functions (no need to do an activation record for the same function over and over), so most functional languages are interpreted (at least to some degree.) Lisp is used for many "serious" applications, as IR will surely attest to, and it is usually considered interpreted (although many kinds of lisp have a 'byte code' kind of feature like java.)
"VB, C++ and all modern high level languages are compliled. Nobody uses an interpreter for anything serious although an interpreted programme can be a good teaching aid. "
This is quite wrong. Only a portion of all modern high level languages are compiled. Java, lisp, prolog, perl, php, asp, python, and many others are modern, interpreted (to some degree), high-level languages. People use interpreters for serious stuff all the time. This forum, for example, has javascript and perl, both languages that are usually thought of as interpreted.
Nowadays the line between interpreted and compiled languages is more hazy than ever...We had an interesting discussion on this topic in this thread. I liked perl.com's line "A computer scientist will correctly explain that all programs are interpreted, and that the only question is at what level."
Good luck, and you better get an A if this is homework!
-SN

Lisp... the nightmares of Lisp... AHHHHHH!
Anyway, one concept for those of you who don't know what this language is associated with... Artificial Intelligence. However, the importance of AI has been a debate where people seem to be willing to fight to the death. I agree with SN's comment in regards to Lisp.If this is, in fact, homework (which I remember it as a question on a compiler design test many moons ago)... you should pay SN for your grade. :)
IR

In our time, a compiler is a static interpreter. An interpreter is a dynamic compiler.
Traditionally, a compiler translated source to an object, but did not execute the object. Traditionally, an interpreter only executed objects or pseudocode.
In practice, an interpreter performs the same functions as the first stage of compilation. Often, it performs optimizations as well. Therefore, it is in the programmer's interest to have the interpreter compile and execute code. It simplifies developement. This is a dynamic model - the programmer spends more time dealing with algorithms, abstract data structures, OO features, and spends less time specifying details for the compilation. The code is also more easily reverse engineered in many cases. The benefit is focus on design, principle, and code. A common OO set of libraries and features is a natural result.
In practice, a compiler performs complex optimizations, operates on large source files, and provides extensive customization for any compilation. This is a static model - the programmer generally creates extensive configuration (make files, directives, arguments, etc.) intended for pre-runtime optimization. The code is often not so easily reverse engineered and native code is usually the object. Procedural control is more accessible.
The static model is still widely used, but it will continue to be used only when needed. Instead, virtual machines will probably take over the majority of developement efforts. Interpreters as we know them, will probably hook into virtual machines or establish their own VM's. Wait till OS's start integrating more fully with VM's.
All high level languages must be compiled and interpreted to be executed.
"I have heard of native-code compilers for Java as well, but I suspect they actually just wrap the necessary parts of the JVM in the EXE, like VB used to do."
Well, its still native code. The object must be linked with a library which provides similar services the JVM normally would. The compilers usually do not use parts of the JVM.
"'VB, C++ and all modern high level languages are compliled. Nobody uses an interpreter for anything serious although an interpreted programme can be a good teaching aid.'
This is quite wrong. Only a portion of all modern high level languages are compiled."
All high level languages are compiled. The interpreter contains a de facto compiler. The programmer generally doesn't interact with it. It is (ideally) a behaved, encapsulated compiler which can be controlled by the interpreter.
Not all languages are native-code compiled (portable Java). Their compilation, if any, is for a VM or interpreter. In case no one ever said it, a VM is an evolved interpreter.

"All high level languages must be compiled and interpreted to be executed."
That statement is false. All high level languages must be compiled - period.

I was looking forward to anonproxy's comments...I knew he'd come through with the good stuff.
As with each time we have this conversation, it's easy to get lost in the semantics. I agree wholeheartedly that all languages are compiled..."The interpreter contains a de facto compiler." - Obviously some way or another any code, high or low level, has to be turned into 1s and 0s at some point. If "compilation" is that process, then certainly all languages are compiled.
That's fine if you want to define compilation that way, but I suspect most people associate compilation with the production of some (non-temporary) version of the program that is closer to the machine language at some point previous to run-time. Most interpreters don't produce any such files, so we tend to draw a (perhaps arbitrary) line between "compilers" and "interpreters."
One could make pretty convincing arguments of any of the following statements:
1. All programs are compiled
2. All programs are interpreted
3. No programs are compiled
4. No programs are interpreteddepending on the definition of each. I think this is what anonproxy was illuding to when he said:
"In our time, a compiler is a static interpreter. An interpreter is a dynamic compiler.Traditionally, a compiler translated source to an object, but did not execute the object. Traditionally, an interpreter only executed objects or pseudocode."
Anyhow, I would guess the better questions are when the programs are compiled and at what level they are interpreted at run time. Then you could talk about a more continuous spectrum of tradeoffs between "compilation" and "interpretation".
I hadn't previously considered that VMs were the wave of the future...I suppose that as computers get fast enough to handle them it makes sense from a business perspective...One version fits all, no more windows or macintosh logos on the software boxes. Nice point. Maybe I'll be glad my school taught Java instead of C++ 20 years down the road...Right now I feel cheated.
-SN

thx for ur responses
i wud like to put a particular eg doubt
if some1 is writing a game code
then is it tht compiler wud b bettr option coz once compiled to DLL or say exe it can b used to call the DLL functions instead of using some interpreter
which compiler can used for these purposes?
If not compiler then wont it become esoteric?or here still its user dependent?
thx
amogh

C++ is definitely the preferred language for gaming. Some non-processor intensive games are written in Java (like the ones at Yahoo! games)
"If not compiler then won't it become esoteric?"
Quite the opposite, if esoteric means what I think it means. Interpreted languages typically are more portable, and their runtime environments available for free, so the game would be available to everybody.
I would like to make a correction to my last post...I would change the list of 4 items from saying "programs" to "high level languages". I'm not sure I could make the argument "No programs are compiled."
-SN

![]() |
![]() |
![]() |

This post is quite old and has been locked from receiving new replies. Please create a new posting instead.
| Ads by Google |