Python vs. Lisp -- please explain

[Steven D'Aprano]

On Sun, 19 Feb 2006 13:02:16 -0800, Paul Boddie wrote:

> Torsten Bronger wrote:
>> Hallöchen!
>>
>> Bruno Desthuilliers <bdesth.quelquechose at free.quelquepart.fr> writes:
>> >
>> > Ok, then what do you think happens to 'machine' code ?
>> >
>> > "interpreted" usually means "no compilation, all parsing etc
>> > redone at each execution", which is not the case with a
>> > bytecode/vm based implementation.
> 
> Such criteria sound more like those which would distinguish interactive
> languages from others.

How can that be? Python is interactive, and yet it has a bytecode/vm
implementation.

And I'm just waiting for somebody to mention Forth, which completely
breaks down the barriers between compilation and interpretation. In a
world of virtual machines, bytecode compilers, CPUs which emulate other
CPUs using embedded software, and Forth, I would have thought that it was
as obvious as the Sun in the sky that compiled versus interpreted is a
false dichotomy.



>> That sounds like an implementation feature rather than a language
>> feature.  Besides, it's not a very sensible distinction in my opinion.
>> Much better is to think about the structure of the interpreting
>> machine.
> 
> And it's even better to think about the nature of the machine...

Is it? Why? Do you particularly know what happens when your machine code
hits the CPU?


>> I'm not a CS person (only a physicist) but if you *need* a bytecode
>> interpreter on top of the CPU interpretation, it's an interpreted
>> language to me.
> 
> Yet one could potentially have that bytecode interpreter in hardware.

Not potentially, in actuality. I know of only one example, and it
wasn't commercially success, but in 1993 IBM developed a version of
the PowerPC RISC chip that had support for the Intel x86 instruction set.

What has been done once can be done again.

[snip]

> I'm not sure why people get all defensive about Python's
> interpreted/scripting designation or about the details of the CPython
> implementation, especially considering that the virtual machine
> technology in use has been around for a decade and a half, and that
> various projects have been experimenting with alternatives.

I can't speak for others, but for me it is because generally the people
who are the quickest to insist that Python is interpreted appear to mean
it as a put-down. I never hear "Python has the rapid development and
flexibility that only an interpreted language can give", it is always "Of
course Python is slow, it is interpreted, what do you expect?".

Even if they themselves are perfectly aware of the subtle shades of
modern language design, and that interpretation does not mean that every
line of code is parsed repeatedly as it is run, it seems to me that very
often they don't mind one bit if others, less informed than them, come
away with that impression.

Let's be frank: "interpreted language" has negative connotations which may
have been valid in the 1960s and perhaps even the 1970s, but are no longer
automatically valid. Nevertheless, those connotations stick around,
generally amongst the less knowledgeable. That hurts Python's commercial
success, and Python's commercial success is vital for anyone who wishes to
get paid to program in Python. 


-- 
Steven.