[Discuss] Interpreters vs Compilers

[John Blomfield]

Adam Parkin wrote:
> Alan W. Irwin wrote:
>> I enjoyed your talk, John.  There was something for everybody there, but
>> unfortunately those who as yet have not programmed at all were (AFAICT)
>> underrepresented in the audience.  I recommend you make the presentation
>> available on our website so those who missed the talk can benefit.
>
> I unfortunately had to miss the presentation so I'd second the motion 
> that any notes/slides/etc be posted as I'd be very interested in 
> seeing them.
>
> As for the difference between interpreters and compilers, just to be a 
> bit of a devils advocate: the fact that we can't find an interpreter 
> that interprets as fast as a compiled language doesn't necessarily 
> imply that one does not (or can not) exist. :p
>
> This is why I'm not so much of a fan of "speed" benchmarks which are 
> usually fairly artificial.  It could just be that Larry Wall (Perl) 
> and Guido van Rossum (Python) are poor coders.
>
> Now if that last statement doesn't start a flame war, nothing will. :p
This is a very intriguing topic I only wish I new more about it.  I can 
speculate however using the knowledge I have. A little knowledge can be 
a dangerous thing! I can use C and C++ fairly effectively after a few 
years of practice and I am studying Python to see if can be of use to my 
projects.  One significant difference which may have a bearing on this 
topic is that C++ and Python handle polymorphism in different ways.  C 
and C++ are strongly typed languages whereas Python automatically 
changes the type definition of variables according the objects they 
point to.  In Python a variable cannot exist until it has been assigned 
an object i.e. memory space according to type and variables can change 
type dynamically during runtime requiring garbage collection (dynamic 
polymorphism ).  C++ variables representing objects are defined when the 
code is written before they are assigned any data i.e. they can be empty 
(null) and they exist on the "heap" when created at runtime or on the 
"stack" according to scope.  C++ polymorphism is defined by the 
programmer's code apart from some guessing that C++ does when it casts 
basic data types. But mostly if types don't match you get a syntax 
error. My guess therefore is that C++ during compilation optimization 
can scan the code and convert into machine instructions every possible 
memory allocation that can occur, even though it may not know until 
runtime exactly how much will be needed. With Python which converts its 
code into bytecode, that must be executed line by line and each line 
converted into machine code, it cannot know in advance what type of 
object a variable will be assigned until it gets to that line of code.  
It must then do the house keeping to allocate the appropriate type of 
memory and in a loop must repeat this time and again because a 
variable's type could be changing each time through the loop. So I 
conclude that the performance differences are inherent in the structure 
of the language but this does not detract from the usefulness of Python 
for the appropriate task.

I can see that Python can provide me with some useful "glue" but as yet 
I am uncomfortable with having variables change there type without me 
necessarily being warned that they have.  Most of the features that in 
Python are built types are available as library classes and templates in 
C++ and in general seem much more varied and powerful but I can see that 
for someone who has only used C, Python is very appealing since C 
libraries are not as easy to use.  I must pluck up courage and have 
another go at learning Perl.  I have in the past read several chapters 
of a Perl book but found the language very arcane and one that delights 
in obfuscation.  I can usually make some sort of sense out of most code 
even in languages that I don't know but Perl programmers seem to delight 
in seeing how many different obscure ways they can write a simple 
statement and get a hundred operations all on one line.  Not for someone 
that believes in the KISS principle.

I think we need to ask a computer science researcher or language writer 
for more understanding.

John Blomfield