Python vs. Lisp -- please explain

[Chris Mellon]

You're correct as far as it goes, but can you provide a reasonable
definition for "interpreted" that matches the common usage? Most
people can't.

I thought Torsten's definition was good enough: if the instructions
typically produced when preparing your programs for execution can be
handled directly by the CPU then let's call it a "compiled language";
otherwise, let's call it an "interpreted language". I think we all know
about the subtleties of different levels of virtual machines, but if
you want an arbitrary definition that lots of people feel is intuitive
then that's the one to go for.

When asked to name some interpreted (or scripting) languages, they'll
name some off - perl, python, ruby, javascript, basic...

Right: compiled Perl and Python instructions typically aren't executed
directly by the hardware; Ruby visits the parse tree when executing
programs (see [1] for some casual usage of "interpreted" and "compiled"
terms in this context), although other virtual machines exist [2];
JavaScript varies substantially, but I'd imagine that a lot of the
implementations also do some kind of parse tree walking (or that the
developers don't feel like documenting their bytecodes), although you
can also compile JavaScript to Java class files [3]; BASIC varies too
much for any kind of useful summary here, but I'd imagine that early
implementations have tainted the language's "compiled" reputation
substantially.

They won't say Java. Ask them why Python is interpreted and Java isn't
and you'll have a hard time getting a decent technical answer, because
Python isn't all that different from Java in that regard, especially
pre-JIT versions of Java.

That's why I put Java and Python in the same category elsewhere in this
thread. Bear in mind, though, that Java's just-in-time compilation
features were hyped extensively, and I imagine that many or most
implementations have some kind of native code generation support,
either just-in-time or ahead-of-time.

Early Java versions did not, and many versions still don't, at least
in any meaningful way. There are ways of compiling "native" Java, but
they work more like py2exe than GCC. "Native code generation" is a
fairly imprecise term in and of itself - Psyco works almost exactly
the same way as Java JIT does,

Well, I think Torsten's definition was more objective and yet arrives
at the same result. Whether we're happy with that result, I have my
doubts. ;-)

I don't think it does, though. Firstly, as a definition it relies on
the environment the application will be running under and therefore
can't be considered to describe just a language. Secondly, by that
definition Java is an interpreted language which is at odds with the
common definition.

I've encountered a C scripting environment that works by using GCC to
compile each line as it is encountered, doing some magic to keep a
working compilation environment around.

Interpreted? Compiled?

I refer you again to Torsten's definition.

Torstens definition isn't useful for quantifying a difference between
interpeted and compiled - it's a rough sort of feel-test. It's like
how much of a naked body you can expose before before it changes from
art to pornography - it's not something that is easily quantified.

I wonder how "interpreted" people would think Python is if the
automagic compilation to .pyc was removed and you had to call
"pythonc" first.

Well, such things might have a psychological impact, but consider
removing Python's interactive mode in order to enhance Python's
non-interpreted reputation, and then consider Perl (an interpreted
language according to the now-overly-referenced definition) which
doesn't have an interactive mode (according to [4] - I don't keep up
with Perl matters, myself), but which allows expression evaluation at
run-time. No-one would put Perl together with C in a compiled vs.
interpreted categorisation. Removing the automatic compilation support
might strengthen the compiled feel of the both languages further, but
with knowledge of the technologies employed, both languages (at least
in their mainstream forms) are still on the other side of the fence
from C.

Paul

[1] http://www.rubygarden.org/faq/entry/show/126
[2] http://www.atdot.net/yarv/
[3] http://www.mozilla.org/rhino/doc.html
[4] http://dev.perl.org/perl6/rfc/184.html

 

[Donn Cave]

They won't say Java. Ask them why Python is interpreted and Java isn't
and you'll have a hard time getting a decent technical answer, because
Python isn't all that different from Java in that regard, especially
pre-JIT versions of Java.

For me that would be partly because I don't know that
much about Java, honestly. Just searching at random
for something about the subject, I cam across this -
http://www-128.ibm.com/developerworks/java/library/j-native.html?loc=j
- which seems like it might be of some interest here.

My impression from reading this is that Java actually
can be compiled to native code, though in 2002 this
was relatively new.

Donn Cave, (e-mail address removed)

 

[Dennis Lee Bieber]

That's why Sun doesn't describe Java as interpreted,
but as byte-code compiled. They did that before they
had JIT compilers to compile to machine code.
Consequently nobody thinks of Java source having to be
parsed, and parsed, and parsed, and parsed again.

Normal Java also requires one to perform that byte-code compilation
as a discrete step...

It would be the equivalent of having to explicitly create a .pyc
file using, say, "pythonc"; and "python" will only load a .pyc file, not
a source file.
--

 

[Steve Holden]

Chris Mellon wrote:
[...]

Torstens definition isn't useful for quantifying a difference between
interpeted and compiled - it's a rough sort of feel-test. It's like
how much of a naked body you can expose before before it changes from
art to pornography - it's not something that is easily quantified.

[...]

Possibly, but if your aim is exposing as much flesh as possible without
being labeled pornography I think I'd conclude you were in the
pornography business from the start, albeit masquerading as an "art dealer".

regards
Steve

 

[Pietro Campesato]

As they say, case is the difference between "I helped my

Uncle Jack off a horse" and "I helped my uncle jack off a horse."

Hahaha!... never heard of that though

 

[Steven D'Aprano]

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

 

[Carl Friedrich Bolz]

Chris Mellon wrote:
[snip]

I don't think it does, though. Firstly, as a definition it relies on
the environment the application will be running under and therefore
can't be considered to describe just a language. Secondly, by that
definition Java is an interpreted language which is at odds with the
common definition.

I've encountered a C scripting environment that works by using GCC to
compile each line as it is encountered, doing some magic to keep a
working compilation environment around.

Interpreted? Compiled?

There is also the wonderful C interpreter cint:

http://root.cern.ch/root/Cint.html

so obviously C must be an interpreted language

Cheers,

Carl Friedrich Bolz

 

[Donn Cave]

Quoth Steven D'Aprano <[email protected]>:
....
| 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?

I don't care whether the CPU has to interpret machine code. Are
you suggesting that we might in normal conversation wish to use
the term interpreter to mean CPU, like "what kind of interpreter
does your computer have?", that kind of thing?

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

Look, this is my last post on this matter, because you have evidently
reached a point where every statement has to be spelled out in excruciating
detail to avoid absurd interpretations. "will work independent of machine
architecture" does not declare that it is absolutely guaranteed to work -
after all, it may have some other flaw that will prevent it from working
anywhere. It just says that if it doesn't work, it isn't because it
tried to execute on the wrong machine architecture - the file is machine
architecture independent. You know that, you know I know that. What
is the fucking problem?

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

Anyone with an interest in computer programming is likely to know what
microcode means, that there are emulators, virtual machines, etc. You
might find the UCSD Pascal system interesting, to harken back to the
early days of my experience with computers, a fascinating twist on the
interpreted/compiled story. Interesting as perspective, but it wouldn't
change the way we apply these words to Python.

Donn Cave, (e-mail address removed)

 

[Torsten Bronger]

Hallöchen!

In a previous century, I used something called UCSD Pascal, which at
the time was a typical implementation of Pascal.

Not "a" typical implementation but "its".

[...]

And, as someone in this thread has pointed out, it is likely that
your important modern (x86) processor is not natively executing
your x86 code, and indeed meets your definition of having "in its
typical implementation an interpreting layer necessary for typical
hardware".

Only if you deliberately misunderstand me.

Another example: is Java the bytecode, which is compiled from Java
the language, interpreted or not? Even when the HotSpot JIT cuts
in?

It is partly interpreted and partly compiled. That's why it's
faster than Python.

[...]

Personally, in practice I don't care, so don't ask me. Ponder on
getting angels to dance on the head of a pin before you worry
about whether the dance can be interpreted or not.

I agree that the term "interpreted" is bad Python advocacy because
its implications are often misunderstood. However, I think that
it's fair to make a distiction between compiled and interpreted
languages because it may affect one's decision for one or the other.
Although I'm surely not ingenious, I can make this distinction.

The reason why Python is slower than C is because there is an
interpreting layer that C doesn't have. And the reason for this is
that Python's nature is incompatible with today's CPUs (which was a
deliberate and advantageous design decision). I'm sure that a
willing CS person could define this more clearly.

Anyway, if we drop "scripting" and drop "interpreted", what do you
want to tell people asking why Python is so slow? Because it is
dynamic? ;-)

Tschö,
Torsten.

 

[Steven D'Aprano]

Only if you deliberately misunderstand me.

If the words you choose to use have implications which you failed to
realise before saying them, don't blame the reader for spotting those
implications.

It is partly interpreted and partly compiled. That's why it's faster
than Python.

But Python is partly interpreted and partly compiled too, so that can't be
the answer.

I think we all know what the answer is. The Python interpreter isn't as
fast as the Java interpreter, or most machine code interpreters built into
hardware.

On the other hand, I'm pretty sure that interpreted Python runs faster on
my current PC than compiled code runs on the 20 year old Macintosh in my
cupboard. So "compiled" isn't a magic wand that makes code run faster.

[...]

Personally, in practice I don't care, so don't ask me. Ponder on
getting angels to dance on the head of a pin before you worry about
whether the dance can be interpreted or not.

I agree that the term "interpreted" is bad Python advocacy because its
implications are often misunderstood. However, I think that it's fair
to make a distiction between compiled and interpreted languages because
it may affect one's decision for one or the other. Although I'm surely
not ingenious, I can make this distinction.

Would you rather use a blindingly fast interpreted language, or a
slow-as-continental drift compiled one?

This isn't a rhetorical question. In the mid-80s, Apple and Texas
Instruments collaborated on a Macintosh II computer with a Lisp
coprocessor. The problem was, according to benchmarks at the time, Lisp
compiled and run natively on the coprocessor was actually slower than Lisp
interpreted on a standard Macintosh II.

I'm sure that's hardly the only example of a speedy interpreted language
beating a glacial compiled one.

The reason why Python is slower than C is because there is an
interpreting layer that C doesn't have.

The primary reason Python is slower than C is because C compilers have
been optimized to create fast code, while Python has been created to
optimize programmer productivity instead. That means that a simple
instruction like x + y does a lot more work in Python than it does in C.

There are other languages that, like Python, are dynamic, interpreted,
interactive and the rest, and they execute faster than Python. (By the
same token, there are also some that execute slower than Python.) Let's be
honest here: it isn't that Python can't be as fast as C, it is that the
Python Dev team have had other priorities.

But over time, as PyPy, Psycho, and other technologies bear fruit, Python
will speed up, even though it will remain interpreted.

And the reason for this is that
Python's nature is incompatible with today's CPUs (which was a
deliberate and advantageous design decision). I'm sure that a willing
CS person could define this more clearly.

Anyway, if we drop "scripting" and drop "interpreted", what do you want
to tell people asking why Python is so slow? Because it is dynamic? ;-)

Who says Python is so slow? I've just got Python to count from 0 up to
100,000, and it only took 7 milliseconds. That's at least 12 milliseconds
faster than I can count on my fingers.

But seriously... why not tell them the truth? Python is slower than some
other languages because optimization for execution speed has not been the
primary focus of Python's development. If you tell them that Python is
slow because it is interpreted, they will believe that Python will always
be slow. If you tell them that Python is slow because speed has not been
the priority, they will believe that some day it will become the priority,
and then Python will get faster. And they will be right. That is the aim
of PyPy after all.

 

[Kay Schluehr]

But over time, as PyPy, Psycho, and other technologies bear fruit, Python
will speed up, even though it will remain interpreted.

I talked to Richard Emslie recently and he told me that the PyPy team
works on a mechanism to create CPython-extension modules written in
RPython i.e. a statically translateable subset of Python. So even
without dynamic code specialization there will be an optimization path
based on the PyPy toolchain that is amazing.

Kay

 

[Paul Rubin]

I talked to Richard Emslie recently and he told me that the PyPy team
works on a mechanism to create CPython-extension modules written in
RPython i.e. a statically translateable subset of Python. So even
without dynamic code specialization there will be an optimization path
based on the PyPy toolchain that is amazing.

Sounds great but is that a whole lot different from pyrex?

 

[Kay Schluehr]

Sounds great but is that a whole lot different from pyrex?

RPython is Python code not a different language. In a sense RPython
consists of a set of rules usual Python has to conform to make complete
type-inference feasible. Here is an overview of those rules.

http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#restricted-python

Kay

 

[Torsten Bronger]

Hallöchen!

If the words you choose to use have implications which you failed
to realise before saying them, don't blame the reader for spotting
those implications.

To me it sounds like "Some hardware is harder than other".

But Python is partly interpreted and partly compiled too

It's byte-compiled for a VM, that's not the same, and you know it.
Sorry but I think we've exchanged all arguments that are important.
Any further comment from me would be redundant, so I leave it.

[...]

[...] However, I think that it's fair to make a distiction
between compiled and interpreted languages because it may affect
one's decision for one or the other. [...]

Would you rather use a blindingly fast interpreted language, or a
slow-as-continental drift compiled one?

This isn't a rhetorical question. [example]

I'm sure that's hardly the only example of a speedy interpreted
language beating a glacial compiled one.

I agree that the distinction between interpreted and compiled
languages is not as clear as between positiv and negative numbers,
however, neither anybody has claimed that so far, nor it is
necessary. It must be *practical*, i.e. a useful rule of thumb for
decision making. If you really know all implications (pros and
cons) of interpreted languages, it's are very useful rule in my
opinion.

[...]

But seriously... why not tell them the truth? Python is slower
than some other languages because optimization for execution speed
has not been the primary focus of Python's development. If you
tell them that Python is slow because it is interpreted, they will
believe that Python will always be slow.

I don't think that "Python's developers don't focus primarily on
speed" sounds better than "Python is interpreted". Both suggests
that you must circumvent problems with Python's execution speed (we
all know that this works and how) because you can't count on
language improvements. Even worse, evading "interpreted" may sound
like an euphemism and as if you want to hide unloved implementation
features, depending on your audience.

Tschö,
Torsten.

 

[Torsten Bronger]

Hallöchen!

If the words you choose to use have implications which you failed
to realise before saying them, don't blame the reader for spotting
those implications.

To me it sounds like "Some hardware is harder than other".

But Python is partly interpreted and partly compiled too

It's byte-compiled for a VM, that's not the same, and you know it.
Sorry but I think we've exchanged all arguments that are important.
Any further comment from me would be redundant, so I leave it.

[...]

[...] However, I think that it's fair to make a distiction
between compiled and interpreted languages because it may affect
one's decision for one or the other. [...]

Would you rather use a blindingly fast interpreted language, or a
slow-as-continental drift compiled one?

This isn't a rhetorical question. [example]

I'm sure that's hardly the only example of a speedy interpreted
language beating a glacial compiled one.

I agree that the distinction between interpreted and compiled
languages is not as clear as between positiv and negative numbers,
however, neither anybody has claimed that so far, nor it is
necessary. It must be *practical*, i.e. a useful rule of thumb for
decision making. If you really know all implications (pros and
cons) of interpreted languages, it's are very useful rule in my
opinion.

[...]

But seriously... why not tell them the truth? Python is slower
than some other languages because optimization for execution speed
has not been the primary focus of Python's development. If you
tell them that Python is slow because it is interpreted, they will
believe that Python will always be slow.

I don't think that "Python's developers don't focus primarily on
speed" sounds better than "Python is interpreted". Both suggests
that you must circumvent problems with Python's execution speed (we
all know that this works and how) because you can't count on
language improvements. Even worse, evading "interpreted" may sound
like an euphemism and as if you want to hide unloved implementation
features, depending on your audience.

Tschö,
Torsten.

 

[Paul Boddie]

I've wondered that as well.

RPython is Python code not a different language. In a sense RPython
consists of a set of rules usual Python has to conform to make complete
type-inference feasible. Here is an overview of those rules.

http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#restricted-python

But does that make it "proper Python"? Having, for example, only one
type associated with a name (they use the term "variable", though) at
any given time makes it more like various statically typed or
functional languages, although I can fully understand why you'd want
this restriction.

Paul

 

[Carl Friedrich Bolz]

Well. "... the PyPy team works on ..." is definitively much too strong.
It is more like "... the PyPy team is thinking about ...". It is very
unclear whether it will work on a technical level and whether the EU
will allow us to allocate resources accordingly.

Sounds great but is that a whole lot different from pyrex?

Indeed, there are similarities to pyrex. Of course in pyrex you have to
give the types yourself, but since the type inference engine of PyPy can
sometimes be hard to understand this is maybe not the worst trade-off. A
nice advantage of the PyPy approach would be that you can test your
RPython code by running it on top of CPython until it works and only
then translating it into C. Plus it would be possible to use the same
extension module for PyPy, CPython and potentially even Stackless or
Jython (if somebody writes a Java backend).

But as I said, this is all pretty unclear at the moment (and getting
really quite off-topic for this thread).

Cheers,

Carl Friedrich

 

[bearophileHUGS]

Carl Friedrich Bolz:

Indeed, there are similarities to pyrex. Of course in pyrex you have to
give the types yourself, but since the type inference engine of PyPy can
sometimes be hard to understand this is maybe not the worst trade-off.
A nice advantage of the PyPy approach would be that you can test your
RPython code by running it on top of CPython until it works and only
then translating it into C. [...]
But as I said, this is all pretty unclear at the moment

Maybe PyPy can be used to allow a better linking between interpreted
Python code and code compiled by ShedSkin.
SS contains a good type inferencer that maybe can be useful to compile
RPython too, aren't PyPy people interested in SS and its capabilities?

Bye,
bearophile

 

[Michele Simionato]

I replied to this message yesterday, but it did not appear, so let's
try again.

I agree with your points, but I would not say that Lisp is
intrinsically more dynamic than Python
as a language; it is just more interactive and has more features (and
more complexities too).
BTW, regarding your first point on interactive sessions, are you aware
of Michael Hudson's recipe
"automatically upgrade class instances on reload()"
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/160164 ?

Michele Simionato

 

[Daniel Harding]

Who says Python is so slow? I've just got Python to count from 0 up to
100,000, and it only took 7 milliseconds. That's at least 12 milliseconds
faster than I can count on my fingers.

+1 QOTW