Python vs. Lisp -- please explain

[Paul Boddie]

Steven D'Aprano wrote:
> On Sun, 19 Feb 2006 13:02:16 -0800, Paul Boddie wrote:
>
> >> 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.

The criteria were "no compilation, all parsing etc redone at each
execution": things which would possibly describe features of a language
where much use is made of an interactive mode, and where there wouldn't
be many advantages in generating instructions in another form for later
execution. Not that this applies to Python, since it does compile
source code to bytecode instructions as we all know, and the only
re-parsing occurs in well-defined circumstances, but there have been
other "dare I say scripting?" languages whose execution models have
apparently involved ASTs instead of virtual machine instruction sets.

[...]

> > 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?

In general, yes: it's interpreted by a virtual machine implementation
in hardware. But this is where the nature of the machine is important,
as I originally wrote, since you don't want highly complicated
instructions implemented in hardware for a variety of well-understood
reasons.

[...]

> 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.

I think we're mostly in agreement here. My point was, as usual,
tangential: there is a certain class of instructions conveniently or
economically implementable in hardware; CPython's runtime also has
instructions more complicated than those. Consequently, when people
used to speculate about Python CPUs and other magical devices that
would make Python run much faster (see [1] for more recent material
which doesn't specifically do so, although I believe the speaker made
references to such devices; see [2] for an old mailing list thread),
one has to accept that there are certain constraints that have a severe
effect on whether such devices are viable or not. If some people want
to classify runtime environments on this basis then I don't have a
problem with that, provided that they are honest about it and put
things like the Java VM in the same category as CPython.

Paul

[1]
http://www.python-in-business.org/ep2005/talk.chtml?talk=2116&track=692
[2]
http://mail.python.org/pipermail/python-list/1999-June/thread.html#4543