Compiler vs Interpreter

[KayS]

For this quesiton I chose A, the only other option which makes sense is D.

 

D has some truth in it because it says interpreters will find errors in source code befo they are run but the second one im unsure because when i compile a program with syntax error it throws and error, but it says execute source code which is misleading. Im really stuck on choosing between the both A seems so right I can see what is wrong with B and C but cant see what is wrong with answer D.

 

can anyone help me and tell me if im correct or completely wrong.

 

[LaurieAG]

D has some truth in it because it says interpreters will find errors in source code befo they are run but the second one im unsure because when i compile a program with syntax error it throws and error, but it says execute source code which is misleading.

 

So you already know that compilers, not interpreters, find errors in source code before they are run and should therefore know D's correctness status.

 

What are your reasons for classifying the others correctness?

Edited July 18, 2014 by LaurieAG

[ryan001]

Unless I am mistaken Option D is definitely False

 

Compilers: 1 Debug

2 Translate

3 Execute

Compilers take longer to execute the code, but once executed the code runs much faster than that of an interpreter.

 

Interpreters: 1 Execute

2 Debug

3 Translate

Interpreters execute the code much faster than compilers, but the executed program runs much slower than that of a compiler.

 

Compiled programs usually produce a product that run faster,

 

I would lean towards Option A

Option B is False computers cannot understand intermediate languages they only understand pure machine language.

Option C Is only true for the interpreter. You do not need a compiler to run compiled programs you only need the correct operating system and

compatible hardware.

 

I Hope this Helps

Edited July 18, 2014 by ryan001

[Sensei]

Unless I am mistaken Option D is definitely False

 

void main( void )

{

*( (unsigned int *) 0 ) = 0;

}

 

Compile and run above code...

That depends on what kind of errors we're talking: about typos or real errors made by programmer..

[ryan001]

Is that C++ or C#

[LaurieAG]

Option B is False computers cannot understand intermediate languages they only understand pure machine language.

 

That only works if machine code is not a low level language.

 

Also, the two types of errors are syntax errors and logic errors.

[Dekan]

Aren't interpreters best for experimental programming. They allow a programmer to freely change any individual line, then run the program again - immediately - to see what effect the change has on the outcome.

 

Whereas compilers won't permit the slightest change, without re-compiling the entire program. This seems very inefficient and wasteful for the computer, in terms of all the unnecessary processing it has to do.

 

As an analogy, suppose you were writing a book. And you wanted to try the effect of changing, say, a single word on line 7 of page 548. But you couldn't do it, without going right back to page 1, and writing again all the text until you got to p. 548, and made the simple change to line 7. That would seem stupid and exasperating to a human.

 

Yet Isn't that what compilers force computers to do?

[Sensei]

Whereas compilers won't permit the slightest change, without re-compiling the entire program. This seems very inefficient and wasteful for the computer, in terms of all the unnecessary processing it has to do.

 

Typical program is made of many, perhaps even hundreds, or thousands separate source files.

Each source file is compiled to separate temporary object file. Then object files are linked together.

If you will make change to one source file, out of thousands, compilation will finish in second. As only one OBJ file must be recompiled.

 

Analogy might be building house from bricks - if one bricks has to be replaced because it's broken, you don't need to destroy whole house and start from scratch..

 

In reality it depends on particular case. If OBJ has f.e. class, and we're adding new methods or members to that class (so actually doing changes to .h header file), and it's widely used by whole application, then whole application must be recompiled.

But if we would be fixing already existing method of class (so changing .cpp file), that has not been inlined, recompilation of whole project wouldn't be needed.

 

[EdEarl]

There are various implementations of interpreters, including ones that compile source code into p-code that later interpret p-code, and ones that interpret source code directly. And, one could say that a computer interprets machine code. Consequently, some statements in this thread are correct for some kinds of interpreters and not correct for others. Moreover, some statements about compilers also apply to interpreters that compile to p-code. In my opinion, neither A, B, C, or D are totally correct and accurate. I don't know what the instructor taught and, therefore, cannot answer this question.

[Dekan]

 

Typical program is made of many, perhaps even hundreds, or thousands separate source files.

Each source file is compiled to separate temporary object file. Then object files are linked together.

If you will make change to one source file, out of thousands, compilation will finish in second. As only one OBJ file must be recompiled.

 

Analogy might be building house from bricks - if one bricks has to be replaced because it's broken, you don't need to destroy whole house and start from scratch..

 

In reality it depends on particular case. If OBJ has f.e. class, and we're adding new methods or members to that class (so actually doing changes to .h header file), and it's widely used by whole application, then whole application must be recompiled.

But if we would be fixing already existing method of class (so changing .cpp file), that has not been inlined, recompilation of whole project wouldn't be needed.

 

 

Thanks Sensei - I think I take the point. If the program isn't a single continuous listing of code, but is divided into separate self-contained "blocks" - or "bricks" as you well illustrate - then one such "brick" can be recompiled without necessarily affecting the rest of the structure.

 

Rather like having "local variables" in the old BASIC subroutines or Procedures.

 

I think programming has moved on since my day in the 1980's. Back then, we didn't have to consider "thousands of separate source files" linked together! Our old-fashioned programs had to be written using original analysis and logic.

 

Whereas modern programming seems to consist of tacking together ready-made blocks of code. Without any need to understand what's actually going on at deep level, within each block.

I suppose this is good in a way, as it saves mental effort.

[Sensei]

 

Whereas modern programming seems to consist of tacking together ready-made blocks of code. Without any need to understand what's actually going on at deep level, within each block.

I suppose this is good in a way, as it saves mental effort.

 

 

I think you oversimplified this.

In 1980 we had free access to hardware registers. And any program could do whatever machine allowed. Now that's job of operating system to talk to hardware. And regular programs have forbidden direct access to hardware.. You have to use OS functions to draw pixel on screen. You can't just set bit in bitplane.. This approach is required because different computers have completely different hardware, that program have no idea about..

 

Some people use linkable libraries for everything, usually beginners.

Some people have to use linkable libraries, or dynamic libraries, because their internals are licensed, and if you would include it in your code, you could be accused of stealing..

 

Our old-fashioned programs had to be written using original analysis and logic.

 

So the same is nowadays..