merits of Lisp vs Python

[Mark Tarver]

How do you compare Python to Lisp? What specific advantages do you
think that one has over the other?

Note I'm not a Python person and I have no axes to grind here. This is
just a question for my general education.

Mark

[Paul Rubin]

jayessay <no****@foo.com writes:

If you say foo.frob() in Python, that's supposed to look up 'frob' in
a dictionary hanging off of foo. You can modify the contents of this
dictionary any time you want.

Unless I'm missing something this looks absolutely dead easy to
implement in Lisp and with a very little macrology you would have the
syntax as well. I'm not sure how this makes one or the other "more
dynamic".

I'm talking about the way Lisp is actually used, not what contortions
one can do with macros. The way one does OOP in Lisp is with CLOS.

[Paul Rubin]

André Thieme <ad************ *************** *@justmail.dewr ites:

In Python it can't happen because + is not a function.
And what do you do if you want to pass + as a HOF?

Use a lambda. There's a library module (use "import operator") that
exports functions for most of these operators. It's used sometimes
but not all that often. You could think of Python as sort of a
Huffman code. It tries to make the most common operations very
convenient, sometimes at the expense of the less common ones.

[Paul Rubin]

"HowiPepper " <hp*****@gmail. comwrites:

With Python's ease of learning and use, availability of a large number
of libraries, extremely active development community and large
user-base, I'd say the question to ask is what specific advantages over
Python does Lisp offer, to make people switch to it?

Lisp has a more uniform design geared towards large system
development. It doesn't have as many weird quirks and exceptions as
Python. It has much more serious implementations with real compilers.
There is an inevitability about the way the language works, it's just
"cosmic". The only way I can suggest to appreciate that is study an
implementation of it sometime. The parentheses really aren't a big
deal. Lisp is simply hypnotic, to those receptive to that kind of
thing. In musical terms, Python is like a Beatles song, very popular
and easy to sway and dance to. Lisp is like a Bach fugue.

[Paul Rubin]

Espen Vestre <es***@vestre.n etwrites:

Can you redefine CLOS methods without calling CLOS functions that tell
the object system what to expect (so it can do things like update the
MRO cache)? I.e. can you redefine them by poking some random
dictionary? You can in Python. I don't claim that's a good thing.

Just as I said: Less managable, but not more dynamic.

I'm not getting through to you. Yes, you could create a Python-like
object system in Lisp that's separate from CLOS, but nobody would use
it. It wouldn't matter whether you could compile it efficiently or
not, since nobody would care. What matters is that you can compile
CLOS efficiently.

Python's object system is used in every Python program and it has
those properties and if you try to remove them, you don't have Python
any more. A Python compiler has to deal with that. So compiled
Python code is necessarily going to suffer compared with compiled Lisp
code.

[Greg Menke]

Paul Rubin <http://ph****@NOSPAM.i nvalidwrites:

André Thieme <ad************ *************** *@justmail.dewr ites:

import module
module.function = memoize(module. function)

Yes, I mentioned that a bit earlier in this thread (not about the
"during runtime" thing).
I also said that many macros only save some small bits of code.
Your python example contains 4 tokens / brain units.
The Lisp version only has 2.

You shouldn't count the import statement, since you'd need the
equivalent in Lisp as well.

Contrast the much more common

a[i] = b[n]

with

(setf (aref a i) (aref b n))

and the attractions of Python may make more sense.

Not really. The syntax of getting and setting array elements isn't
really the point. It ignores the cognitive efficiency of Lisp when
things get more complex, and likewise whatever similar characteristics
that Python offers. I don't mean to imply Python is inefficient, just
that array manipulation syntax isn't where the two languages' strengths
& weaknesses appear. To compare the languages when things get
complicated, in effect, to see how they help and how they hurt when
problems are difficult, then a more complex example is necessary. Since
the arguments so far seem dominated by syntactical trivia, they seem to
me more about perceived aesthetics and personal preference than anything
else.

I spent a year or so using Python as a scripting language for relatively
simple applications where shell scripts were insufficient. It works
fine as such. But it began to suck performance-wise when I started
trying to manipulate more complex datasets and I began wanting
compilation to get throughput up. Common Lisp, being a highly mature
language (and thus sometimes ossified in appearance), offered a
standardized language with a variety of implementations , some of which
gave me the compiler tools I needed without forcing me to retool
concepts and source code from the freebie implementations I started
with. This is a very important point once there is considerable
conceptual investment in a suite of source.

When the New & Cool arguments are presented, this issue seems neglected.
There are many tradeoffs to be made between New & Cool and Highly
Matured, syntax being only one.

Gregm

[Paul Rubin]

Greg Menke <gr***********@ toadmail.comwri tes:
re: comparison of

a[i] = b[n]

with

(setf (aref a i) (aref b n))

Not really. The syntax of getting and setting array elements isn't
really the point. It ignores the cognitive efficiency of Lisp when
things get more complex, and likewise whatever similar characteristics
that Python offers.

Well, there's some similar way to look up elements in a Lisp
hashtable, but I've forgotten the keyword for it (oops, cognitive
inefficiency, having to remember separately.) Python uses the same
syntax for both.

Yeah it's probably true that very complex applications are easier to
develop in Lisp. For small and medium ones, I really do find Python
more pleasant, and I'm speaking as someone for whom the discovery of
Lisp was once an unbelievably powerful epiphany.

[tac-tics]

In musical terms, Python is like a Beatles song, very popular

and easy to sway and dance to. Lisp is like a Bach fugue.

Very nice analogy.

[Piotr]

Paul Rubin wrote:

a[i] = b[n]
(setf (aref a i) (aref b n))

Well, there's some similar way to look up elements in a Lisp
hashtable, but I've forgotten the keyword for it (oops, cognitive
inefficiency, having to remember separately.) Python uses the same
syntax for both.

That's true, Lisp would benefit from _standard_ homogenuous polymorphic
accessor functions to list-like objects and/or low-level (macro-like)
syntactic sugar. Yes, you can easily make (a i) act like (aref a i)
but it is not done by default. Legacy reasons? Graham has interesting
things to say about this issue:

http://www.paulgraham.com/ilc03.html

Most of my programs are also written in Python, however, I would say
that in many cases "a[i] = b[n]" is an artefact of programming habits
from C, which has no language support for list comprehension,
iterators, etc. I tend to avoid such constructs; usually there is a
more natural way to do the same and it's just too easy to get the
indices wrong.

Piotr

[Jan Dries]

Paul Rubin wrote:

In musical terms, Python is like a Beatles song, very popular
and easy to sway and dance to. Lisp is like a Bach fugue.

While I agree with your point in principle, I think that comparing
Python to a Beatles song doesn't give the language the credit it IMO
deserves. To avoid another thread like this one I will not state what
language I would compare to a Beatles song, but if Lisp is a Bach fugue
then Python I think is more like Mozart. Sure, Bach is the ultimate
Master, no doubt. But Mozart wrote some damn fine music, often heavily
borrowing ideas not only from Bach but also other masters (Handel for
instance), but turning the whole into "something popular and easy to
sway and dance to".

Come to think of it, there definitely is something pythonic to Mozart ...

Regards,
Jan

[Pillsy]

Piotr wrote:

Paul Rubin wrote:

[...]

Well, there's some similar way to look up elements in a Lisp
hashtable, but I've forgotten the keyword for it (oops, cognitive
inefficiency, having to remember separately.)

FWIW, the command is GETHASH. The situation in CL is actually even
worse than just having different names for these functions, since some
functions put the index as the first argument (GETHASH, NTH) and others
put it as the second argument (AREF, ELT). You can at least hide this
archaic nonsense away by defining methods for a generic function if it
bugs you.

Python uses the same syntax for both.

That's true, Lisp would benefit from _standard_ homogenuous polymorphic
accessor functions to list-like objects and/or low-level (macro-like)
syntactic sugar. Yes, you can easily make (a i) act like (aref a i)
but it is not done by default. Legacy reasons?

Well, it's not such a hot idea in a Lisp-2, since you'll often have a
variable named, say, LIST, and then the meaning of (LIST 1) becomes
ambiguous.

In CL, you could do the implicit indexing with different braces,
though, like [a i] for (aref i); this is something I periodically
consider doing.

Cheers,
Pillsy