Python vs. Lisp -- please explain

[63q2o4i02]

Hi, I've been thinking about Python vs. Lisp. I've been learning
Python the past few months and like it very much. A few years ago I
had an AI class where we had to use Lisp, and I absolutely hated it,
having learned C++ a few years prior. They didn't teach Lisp at all
and instead expected us to learn on our own. I wasn't aware I had to
uproot my thought process to "get" it and wound up feeling like a
moron.

In learning Python I've read more about Lisp than when I was actually
trying to learn it, and it seems that the two languages have lots of
similarities:

http://www.norvig.com/python-lisp.html

I'm wondering if someone can explain to me please what it is about
Python that is so different from Lisp that it can't be compiled into
something as fast as compiled Lisp? From this above website and
others, I've learned that compiled Lisp can be nearly as fast as C/C++,
so I don't understand why Python can't also eventually be as efficient?
Is there some *specific* basic reason it's tough? Or is it that this
type of problem in general is tough, and Lisp has 40+ years vs Python's
~15 years?
Thanks
Michael

[Isaac Gouy]

Steven D'Aprano wrote:

On Tue, 21 Feb 2006 09:46:27 -0800, Donn Cave wrote:

In article <43**************@REMOVEMEcyber.com.au>,
Steven D'Aprano <st***@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

[Rocco Moretti]

Alexander Schmolck wrote:

I wanted to point
out that one could with just as much justification claim CL to be more dynamic
than python (it is in some regards, but not in others -- how to weight them to
achieve some overall "score" is not obvious.
I think it's worth pointing out that not all dynamicism is equal, when
it comes to difficulty in compiling to machine code.
For example in CL you could just write

def foo(x, l=[], N=len(l)): [...]

Although computing default arguments at call-time vs. define-time is
arguably more dynamic, it really doesn't (appreciably) increase the
difficulty in creating machine code.

I think (see Caveat) that the one major difference between Lisp and
Python that has a major bearing on compilability is mutability.

Lisp, like the good functional language that it is, has (primarily)
immutable values, and minimal side effects. That is, you can make a
function that takes in one value, and outputs a different value, but
once you have a handle on a value, that value doesn't ever change. That
makes it comparatively easy to track value paths, and assign proper
machine code to each operation.

Python, on the other hand, is mutable to an absurd degree, with
reassignments and side effects galore. Even a relatively simple function
like:

def f():
act(module.value)
random_function()
act(module.value)

can't be (automatically) replaced with the "obvious" equivalent:

def f():
mv = module.value
act(mv)
random_function()
act(mv)

because of the off chance that random_function() will reassign
module.value. Even if you look at random_function(), and rule out a
change to module.value, there is always a chance that a some other
thread will alter module.value in the mean time. Trivial example, true,
but when you figure that you can do the same to any operation or builtin
function, the compiler is never quite sure what a particular function
will do, what side effects it may have, or what type it will return. In
order to be ready for any contingency, a compiled Python program will
effectively have to incorporate the entire interpreter.

C/C++ gets around the mutability issue by straight-jacketing types &
functions. A variable will only contain a particular type (or a
subclass), and a function always has a particular signature.

Granted, there are ways of doing heavy duty code analysis, and pinning
down functions, types, and side effects in Python, and
Psyco/PyPy/ShedSkin are making good strides in that regards. But due to
the heavy dependency on mutable objects and side effects in Python, such
analysis will never be as easy as with Lisp, and considering Python has
had less time, and less investment in those areas, it's no wonder that
it's only just now seeing progress on the compiler front.
* Caveat: I've never seriously programmed in Lisp, and the last time I
looked at it was some time ago, with not-up-to-date reference materials.
I might be mistaken about the extent of mutability in current versions
of Lisp. Hopefully others with more knowledge can give more accurate
details of mutability/side effects in Lisp vis-a-vis ease of compilation.

[sjdevnull]

Carl Friedrich Bolz wrote:

Chris Mellon wrote:

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 :-)

I was going to say "Don't forget EiC either", but it appears to have
vanished from the world.

[Alexander Schmolck]

Rocco Moretti <ro**********@hotpop.com> writes:

I think it's worth pointing out that not all dynamicism is equal, when it
comes to difficulty in compiling to machine code.
No kidding (do you have any idea how this thread started out?).
Lisp, like the good functional language that it is, has (primarily) immutable
values, and minimal side effects.

[further nonsense snipped]

Please don't spread misinformation about things about which you are clueless[1].

'as
Footnotes:
[1] Just as a minor illustrative detail: in python 2 out of 4 builtin
collection types are immutable (tuples and strings; newer versions also
have immutable and mutable sets) in CL 5 out of 5 are mutable
(arrays/vectors/strings, hash-tables, cons cells).

[Kay Schluehr]

Paul Boddie wrote:

Kay Schluehr wrote:

Paul Rubin wrote:

"Kay Schluehr" <ka**********@gmx.net> writes:
> 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.

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

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

I would say yes, it is still "proper Python" in that each RPython
program is also a CPython program. That does not tell us much though,
because a simple calculator providing basic arithmetic operations in
infix notation fits the definition as well. The reason why RPython is
not formally defined may be that it is dedicated to be a maximal
sublanguage of Python that can be accepted by a reasonable
type-inferencer that translates code into a statically typed language.
I find this idea fascinating. Extending the type system by structural
types ( e.g. duck-typing a la C++ ) or algebraic types ( ML -like type
constructors including recursive types ) is a declarative way to extend
the languages power. Another one is extremely-late-binding enabling
arbitrary mutability. Now think for a moment about Guidos idea of
optional type annotations. How would this fit into the whole picture?

Kay

[Roy Smith]

Many people in this thread have said things like:

Interpreted? Compiled? Scripting language?

Let me quote from the preface to "Programming Ruby: The Pragmatic
Programmer's Guide" by David Thomas and Andrew Hunt (aka "the pickaxe
book").

----------
In the old days, the distinction between languages was simple: they were
either compiled, like C or Fortran, or interpreted, like BASIC. Compiled
languages gave you speed and low-level access; interpreted languages were
higher-level but slower.

Times change, and things aren't that simple anymore. Some language
designers have taken to calling their creations "scripting languages." By
this, we guess they mean that their languages are interpreted and can be
used to replace batch files and shell scripts, orchestrating the behavior
of other programs and the underlying operating system. Perl, TCL, and
Python have all been called scripting languages.

What exactly *is* a scripting language? Frankly we don't know if it's a
distinction worth making.
----------

I've made several attempts to sound intelligent in this thread, and each
time, I bailed out before hitting the Post button. I keep coming back to
the conclusion that Thomas and Hunt said it better than I possibly could.

BTW, if like Python and haven't looked at Ruby, it's worth a glance. If
Python can be called similar to Lisp, then Ruby is even more so. I'm not
fond of Ruby's perlesqe syntax, but I like many of the fundamental ideas.

[igouy]

Donn Cave wrote:

In article <ma***************************************@python. org>,
"Chris Mellon" <ar*****@gmail.com> wrote:
...

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/developerwork...ive.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, do**@u.washington.edu

Excelsior Jet ahead-of-time (AOT) compiler FAQ
"How does it work from the technical point of view?"
http://www.excelsior-usa.com/jetfaq.html#internals

[Paul Boddie]

Kay Schluehr wrote:

I would say yes, it is still "proper Python" in that each RPython
program is also a CPython program.

I suppose it depends on which direction you're coming from, in that
many Python programs just wouldn't be able to run in RPython. But then
I can understand the convenience of having a subset of Python that is
executable by CPython, but which can also be inspected and processed
for other purposes, and whose programs maintain their semantics in both
situations.

Paul

[Torsten Bronger]

Hallöchen!

"Paul Boddie" <pa**@boddie.org.uk> writes:

Kay Schluehr wrote:

I would say yes, it is still "proper Python" in that each RPython
program is also a CPython program.

I suppose it depends on which direction you're coming from, in
that many Python programs just wouldn't be able to run in
RPython. But then I can understand the convenience of having a
subset of Python that is executable by CPython, but which can also
be inspected and processed for other purposes, and whose programs
maintain their semantics in both situations.

I'm still afraid of the following scenario: Eventually, people might
regard "RPython plus type declarations" (or something similar) as
first-class Python because it's faster and runs on more
implementations, so they try to stick to it. So effectively you
would have changed Python.

Maybe I misunderstood something because I could not follow all of
Kay's text but I think one should not change Python or create a
look-alike to allow for better implementations. The language should
fit my brain rather than an implementation.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646

[Paul Boddie]

Alexander Schmolck wrote:

Rocco Moretti <ro**********@hotpop.com> writes:

I think it's worth pointing out that not all dynamicism is equal, when it
comes to difficulty in compiling to machine code.
No kidding (do you have any idea how this thread started out?).

I had to remind myself.

Lisp, like the good functional language that it is, has (primarily) immutable
values, and minimal side effects.

[further nonsense snipped]

Please don't spread misinformation about things about which you are clueless[1].

I don't see why you have to be quite so blunt, here. Anyway, some of
the observations made about Python, especially when any comparisons
with Lisp (once corrected) show that Python is more similar to Lisp
than previously thought, are worth considering with respect to things
like type inference and the subsequent generation of low-level code.
Footnotes:
[1] Just as a minor illustrative detail: in python 2 out of 4 builtin
collection types are immutable (tuples and strings; newer versions also
have immutable and mutable sets) in CL 5 out of 5 are mutable
(arrays/vectors/strings, hash-tables, cons cells).

Well, apart from a brief encounter with Lisp back in the microcomputer
era, I've only just got back into looking at the language, and I
suppose I'll eventually find out how the optional type declarations
mentioned occasionally in connection with Lisp actually manage to
handle the harder problems around efficient code generation. I haven't
really studied type systems or compilers in any depth, however, but
having considered the issues for a while I'd like to think that my
rating has progressed from "clueless" to "mostly clueless" by this
point.

Paul

[Ed Jensen]

Roy Smith <ro*@panix.com> wrote:

BTW, if like Python and haven't looked at Ruby, it's worth a glance. If
Python can be called similar to Lisp, then Ruby is even more so. I'm not
fond of Ruby's perlesqe syntax, but I like many of the fundamental ideas.

I can't get over Ruby's ugly syntax. :(

Long live Python! :)

[dlp]

> Paul Rubin wrote:

I think both of you are missing the point of the question, which is
that Lisp is dynamically typed exactly the way Python is and maps to
Python almost directly; yet good Lisp implementations are much faster
than CPython.

But Lisp isn't dynamically typed "exactly the way Python is". Python
documents ways to manipulate the internals of objects at runtime. It
is
possible to add, change or delete methods and slots by directly
changing
the hashtable they're stored in. While CLOS does permit a certain
amount
of runtime redefinition, it is not as completely free wheeling and
unpredicatable.

[Peter Mayne]

Torsten Bronger wrote:

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

Do you mean that Python is byte-compiled for a VM, and not Java, or
vice-versa?
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.

So what kind of practical decisions are you trying to make? What kind of
implications are useful to you?

PJDM

[Paul Rubin]

dl*@itasoftware.com writes:

But Lisp isn't dynamically typed "exactly the way Python is".
Python documents ways to manipulate the internals of objects at
runtime. It is possible to add, change or delete methods and slots
by directly changing the hashtable they're stored in. While CLOS
does permit a certain amount of runtime redefinition, it is not as
completely free wheeling and unpredicatable.

Although CLOS is now part of the Lisp standard I haven't generally
thought of it as describing the language semantics. It's more like a
library routine. Python's standard library generally doesn't provide
documented ways of mucking around with the internal structure of
library classes. CLOS (or something close to it) similarly can and
has been implemented as a Lisp macro package independent from the rest
of the Lisp system.

[Torsten Bronger]

Hallöchen!

Peter Mayne <Pe*********@hp.com> writes:

Torsten Bronger wrote:

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

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.

Do you mean that Python is byte-compiled for a VM, and not Java,
or vice-versa?

I mean "Python is byte-compiled for a VM".

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.

So what kind of practical decisions are you trying to make?

Which language should I use for my project.
What kind of implications are useful to you?

Speed, ease of programming, necessity to learn/use a secondary
language, issues with distributing, portability.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646

[Paul Boddie]

Torsten Bronger wrote:

Peter Mayne <Pe*********@hp.com> writes:

What kind of implications are useful to you?

Speed, ease of programming, necessity to learn/use a secondary
language, issues with distributing, portability.

Indeed. Given the various convenient arguments about what "interpreted"
means (and how Python is simultaneously the same as and yet quite
different to Lisp), you'd think that the average C/C++/Lisp programmer
would have to be quite familiar with microcode to finish off a fair
number of their projects.

Paul

[Kay Schluehr]

Torsten Bronger wrote:

Hallöchen!

"Paul Boddie" <pa**@boddie.org.uk> writes:

Kay Schluehr wrote:

I would say yes, it is still "proper Python" in that each RPython
program is also a CPython program.
I suppose it depends on which direction you're coming from, in
that many Python programs just wouldn't be able to run in
RPython. But then I can understand the convenience of having a
subset of Python that is executable by CPython, but which can also
be inspected and processed for other purposes, and whose programs
maintain their semantics in both situations.

I'm still afraid of the following scenario: Eventually, people might
regard "RPython plus type declarations" (or something similar) as
first-class Python because it's faster and runs on more
implementations, so they try to stick to it. So effectively you
would have changed Python.

I wonder why you believe that it would run on more platforms? This
assertion is justifiable with regard of tiny target hardware - but
else? I do think that "RPython++" could be a viable replacement for C
as a systems programming language BECAUSE it is connected closely to
Python. It is a kind of upside-down evolution: a low level language
emerges from a more high level language. We currently know only the
other side of the story. RPython would just be the common denominator
or the language interface. Gilad Bracha suggested optional type systems
for dynamic languages[1] but as it seems to me RPython would be a fine
candidate for a declarative layer, not Python.
Maybe I misunderstood something because I could not follow all of
Kay's text but I think one should not change Python or create a
look-alike to allow for better implementations. The language should
fit my brain rather than an implementation.

It should first of all fit the diversity of a programmers needs. C was
never considered as a hostile brother of Python so why should it be
Pythons own son?

Kay

[Torsten Bronger]

Hallöchen!

"Kay Schluehr" <ka**********@gmx.net> writes:

Torsten Bronger wrote:

[...]

I'm still afraid of the following scenario: Eventually, people
might regard "RPython plus type declarations" (or something
similar) as first-class Python because it's faster and runs on
more implementations, so they try to stick to it. So effectively
you would have changed Python.
I wonder why you believe that it would run on more platforms?

I meant the following: RPython programs will run on all Python
implementations, *plus* the environments where only RPython is
possible.
This assertion is justifiable with regard of tiny target hardware
- but else? I do think that "RPython++" could be a viable
replacement for C as a systems programming language BECAUSE it is
connected closely to Python.
Ah, okay. This was a vision that I didn't understand from previous
postings.
[...]

Maybe I misunderstood something because I could not follow all of
Kay's text but I think one should not change Python or create a
look-alike to allow for better implementations. The language
should fit my brain rather than an implementation.

It should first of all fit the diversity of a programmers needs. C
was never considered as a hostile brother of Python so why should
it be Pythons own son?

Because I think it would be tempting to add all necessary declations
in order to make one's code working with the fastest Python
implementation available. After all, mostly we know the types,
although currently we don't declare them. It's a purely
psychological issue: People want to create "valueable" code,
pythonistas even more so, ignoring that eventually it may turn out
that this was not a good idea. Current Python *forces* us to keep
the code as flexible as possible.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646

[Christos Georgiou]

On Tue, 21 Feb 2006 15:05:40 -0500, rumours say that Steve Holden
<st***@holdenweb.com> might have written:

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

The difference between art and pornography, as I perceive it, is that you
don't have to think about it when you see pornography. You can even turn
off the audio in cinematographic/video pornography and still the message
comes through (in the vague lines of "jerk off along").

So, in pornography there's no interpretation step involved; therefore, by
pure logic, all "compiled to machine code" languages should be looked down
upon as pornographic, and Python is art. QED.
PS You (the READER) are licensed to substitute other "non compiled to
machine code" languages for Python (the PROGRAM) in the previous paragraph,
just do it outside comp.lang.python (the COMPANY). We don't care what you
do late at night with *your* object of desire, whatever that may be, since
it's not Python.
--
TZOTZIOY, I speak England very best.
"Dear Paul,
please stop spamming us."
The Corinthians