merits of Lisp vs Python

[Ravi Teja]

Re: merits of Lisp vs Python


Mark Tarver wrote:

Paul Rubin wrote:

"Mark Tarver" <dr.mtarver@uko nline.co.ukwrit es:

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

<http://google.com/search?q=python +lisp&btnI=I'm+ feeling+lucky>

>
Thanks; a quick read of your reference to Norvig's analysis
>

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

>
seems to show that Python is a cut down (no macros) version of Lisp
with a worse performance.

By that standard, every other mainstream dynamically typed language for
you is a cut-down version of Lisp with worse performance.

The only substantial advantage I can see is
that GUI, and Web libraries are standard.

Somehow you conveniently miss the fact that he stated that it is ...
1. An excellent language for his intended use.
2. Easy to use and learn.
3. Easier to read than Lisp.
4. Looks more like pseudo code than does Lisp.

Here is a quote from the same Peter Norvig

"Python has been an important part of Google since the beginning, and
remains so as the system grows and evolves. Today dozens of Google
engineers use Python, and we're looking for more people with skills in
this language."

http://www.python.org/Quotes.html

This confirms my suspicion
that Lisp is losing out to newbies because of its
lack of standard support for the things many people want to do.

You confirm things too easily :-).

[Paul Rubin]

Re: merits of Lisp vs Python

André Thieme <address.good.u ntil.2006.dec.2 2@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.

[Paul Rubin]

Re: merits of Lisp vs Python

Michael Livshin <usenet@cmm.kak pryg.netwrites:

Nobody seems to concerned that Haskell lacks macros. What's up with
that?

>
Haskell is lazy, so it doesn't need macros (well, it would be more
accurate to say that by not evaluating function arguments until they
are needed it makes many of the usual macro usecases moot).
>
lazyness has a nontrivial cost, however, both runtime and cognitive.
>
hoping he's not answering a rhetorical question,

It's a reasonable answer. Does SML have a macro system?

[Paul Rubin]

Re: merits of Lisp vs Python

Marc 'BlackJack' Rintsch <bj_666@gmx.net writes:

We are following them in the direction of much more powerful, and at the
same time more secure (type-safe) solutions like Haskell Template
Meta-programming.
>
So there seems to be something macro-like for Haskell.

I think that's some kind of proposed or experimental Haskell feature,
not in the current standard, but I'm not sure. I'm barely even a
newbie with Haskell.

[Paul Rubin]

Re: merits of Lisp vs Python

jayessay <nospam@foo.com writes:

Also, there is the issue of whether there even is a "continual
progression", as in "moving up some ladder" towards something
"better", in the context of programming languages. All of that is
pretty fuzzy stuff, and plenty of CogSci work has shown these value
judgements in this context to be less than obvious in any meaning.

It's simply that newer language designs by definition have more of an
experience base to build on than older ones, if the designers care to
make use of it. ML's designers were quite aware of what it was like
to write Lisp code. Lisp (like anything else) has good and bad
points, and ML's designers were able to examine these in retrospect
and try to improve on them.

Are there any Lisp devotees who have done serious development in ML?

[Paul Rubin]

Re: merits of Lisp vs Python

jayessay <nospam@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]

Re: merits of Lisp vs Python

André Thieme <address.good.u ntil.2006.dec.2 2@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]

Re: merits of Lisp vs Python

"HowiPepper " <hpepper@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]

Re: merits of Lisp vs Python

Espen Vestre <espen@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]

Re: merits of Lisp vs Python

Paul Rubin <http://phr.cx@NOSPAM.i nvalidwrites:

André Thieme <address.good.u ntil.2006.dec.2 2@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]

Re: merits of Lisp vs Python

Greg Menke <gregm-xyzpdq3@toadmai l.comwrites:
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]

Re: merits of Lisp vs Python

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]

Re: merits of Lisp vs Python

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]

Re: merits of Lisp vs Python

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]

Re: merits of Lisp vs Python

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