Python vs. Lisp -- please explain
Paul Boddie
paul at boddie.org.uk
Sun Feb 19 16:02:16 EST 2006
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.
> 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...
> 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.
What typically prevents this is the potential difficulty of realising
complicated software designs in reasonably priced hardware, thus
introducing the nature of the machine: how complicated the instructions
are, what additional support would be required for implementing those
instructions, and so on. Low-level or systems programming languages are
compilable to instructions which are convenient to implement in
hardware and require little additional support: concepts such as stacks
(for various purposes) are supported by machine instructions and
registers, for example, whereas more advanced memory management is left
to software running on top of the virtual machine (although I imagine
that various Lisp machines did some interesting things in this domain).
> I've had such a discussion about TeX already, and my personal
> conclusion was that you can defend almost any opinion in that area.
> However, one should ensure that the definitions make a pragmatic and
> useful distinction.
Agreed. The CPython virtual machine consists of "complicated"
instructions: that is, some of those instructions may involve
non-trivial amounts of work and may be integrated with other subsystems
that can realistically only be implemented in software. Even virtual
machines like that of the Java platform have moderately high-level
instructions, resulting in various "Java optimised" hardware
implementations not attempting to provide a complete coverage of all
the available instructions (as far as I am aware).
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.
Paul
More information about the Python-list
mailing list