Python vs. Lisp -- please explain

[Isaac Gouy]

Steven D'Aprano wrote:
> On Tue, 21 Feb 2006 09:46:27 -0800, Donn Cave wrote:
>
> > In article <43FAD2C2.7080908 at REMOVEMEcyber.com.au>,
> >  Steven D'Aprano <steve at REMOVEMEcyber.com.au> wrote:
> > ...
> >> Hey Donn, here is a compiled program for the PowerPC,
> >> or an ARM processor, or one of IBM's Big Iron
> >> mainframes. Or even a Commodore 64. What do you think
> >> the chances are that you can execute it on your
> >> x86-compatible PC? It's compiled, it should just
> >> work!!! Right?
> >>
> >> No of course not. If your CPU can't interpret the
> >> machine code correctly, the fact that the code is
> >> compiled makes NO difference at all.
>
> [snip for brevity]
>
> > Sure, all this is true, except for the term "interpreter."
> > You would surely not use the word that way, unless you
> > just didn't want to communicate.
>
> Do you honestly believe that the CPU doesn't have to interpret the machine
> code, or are you just deliberately playing silly buggers with language?
>
> In modern CPUs, there is an intermediate layer of micro-code between the
> machine code your C compiler generates and the actual instructions
> executed in hardware. But even if we limit ourselves to obsolete hardware
> without micro-code, I ask you think about what an interpreter does, and
> what the CPU does, in the most general way possible.
>
> Both take a stream of instructions. Both have to take each instruction,
> and execute it. In both cases the link between the instruction and the
> effect is indirect: for example, the machine code 00000101 on the
> Zilog Z80 processor causes the CPU to decrement the B processor register.
> In assembly language this would be written as DEC B. There is absolutely
> nothing fundamental about the byte value 5 that inherently means
> "decrement B processor register".
>
> In other words, machine language is a language, just like it says, and
> like all languages, it must be interpreted.
>
> > Your paragraph above that starts with "No of course not",
> > even omits a point that everyone understands, you can in
> > fact expect a .py file will work independent of machine
> > architecture - like any interpreted language.
>
> Amazing. In your previous post you were telling everybody how the
> *disadvantage* of interpreted programs is that they won't run unless the
> interpreter is present, and in this post you are telling us that
> interpreted languages will just work. What happened to the requirement for
> an interpreter?
>
> Let's see you run that Python program on a Zilog Z80 without a Python
> interpreter. Can't be done. No interpreter, whether in hardware or
> software, and the program won't run, whether in source code or byte code
> or machine code.
>
> If I allow that the machines have an interpreter, perhaps you'll return
> the favour and install an interpreter for machine language (often called
> an emulator). Now your compiled C or Lisp code also will run independent
> of machine architecture.
>
> In order to force "interpreted language" and "compiled language" into two
> distinct categories, rather than just two overlapping extremes of a single
> unified category, you have to ignore reality. You ignore interpreted
> languages that are compiled, you ignore the reality of how machine code is
> used in the CPU, you ignore the existence of emulators, and you ignore
> virtual machines.
>
>
> > We all know
> > what native code compilation buys you and what it doesn't.
>
> Did you fail to learn *anything* from my parable of interpreted Lisp on a
> Macintosh II running faster than compiled Lisp running on a Mac II fitted
> with a Lisp processor?
>
>
> --
> Steven

A different perspective:

"Although we refer to Lua as an interpreted language, Lua always
precompiles source code to an intermediate form before running it.
(This is not a big deal: Most interpreted languages do the same.) The
presence of a compilation phase may sound out of place in an
interpreted language like Lua. However, the distinguishing feature of
interpreted languages is not that they are not compiled, but that any
eventual compiler is part of the language runtime and that, therefore,
it is possible (and easy) to execute code generated on the fly. We may
say that the presence of a function like dofile is what allows Lua to
be called an interpreted language."

p57 Programming in Lua