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

[Steven D'Aprano]

On Fri, 08 Dec 2006 22:02:59 +0200, Alex Mizrahi wrote:

you have an expression 3 + 4 which yields 7.
you have an expression 4 * 1 which yields 4.
if you paste 3 + 4 in place of 1, you'll have 4 * 3 + 4 = 16. as we know, *
is commutative, but 3 + 4 * 4 = 19.
so result depends on implicit operator precendence rules.

in lisp, if you paste (+ 3 4) in (* 4 1), you'll have (* 4 (+ 3 4)), and it
does not depend on order of operands, (* (+ 3 4) 4) yields same results. you
do not have to remember precendence rules

Speaking as somebody who programmed in FORTH for a while, that doesn't
impress me much. Prefix/postfix notation is, generally speaking, more of a
pain in the rear end than it is worth, even if it saves you a tiny bit of
thought when pasting code.

Except, of course, it doesn't really save you any thought. You can't just
expect to paste an expression randomly into another expression and have it
do the right thing. Oh, it will compile all right. But it won't do the
right thing! Since you -- not the compiler -- have to understand the
semantics of what you are pasting where, and paste the right expression
into the right place, the effort saved by not using infix notation is less
than the effort needed to mentally translate between prefix and infix.

If you are one of those people who actually think in prefix notation, then
I raise my hat to you while backing away slowly.

(And actually, I'll give you one point: I've been hitting my head against
a brick wall over a particular problem, and I think your email just gave
me a clue how to solve it. Sometimes prefix/postfix notation is the right
tool for the job. See, I can learn from Lisp.)

--
Steven.

[Jon Harrop]

Steven D'Aprano wrote:

Anything any language can do is possible in any other language

Not true. Concurrency, for example.

Lisp developers so often gloss over that: "Oh,
feature X is *easy*, I could write it in a couple of macros. Two or three.
Maybe thirty. Or forty, max. And they would work the right way first time.
No, I haven't actually done it myself. But I'm sure I could do it, easy."

True.

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet

[Alex Mizrahi]

(message (Hello 'Steven)
(you :wrote :on '(Sat, 09 Dec 2006 20:02:06 +1100))
(

SDIt is a good thing that when Fred decides to stop contributing to an
SDopen source project (or leave the company), other people can read his
SDcode without having to learn his Uber-Special Custom Macro Extended
SDLanguage. Even if Fred's USCMEL ran 35% faster (and thus saved an
SDentire four seconds on an average run with typical data!) the five or
SDsix weeks of reduced programmer productivity when somebody else has to
SDmaintain his code outweighs that.

have you ever faced this problem?
it's not a problem at all.

and it's possible to write unmaintanable code in any langauge. for example,
Bram Cohen's BitTorrent (written in Python)
has a constructors with 21 positional parameters

class Rerequester:
def __init__(self, url, interval, sched, howmany, minpeers,
connect, externalsched, amount_left, up, down,
port, ip, myid, infohash, timeout, errorfunc, maxpeers,
doneflag,
upratefunc, downratefunc, ever_got_incomi ng):

and here's how it called:

rerequest = Rerequester(res ponse['announce'],
config['rerequest_inte rval'],
rawserver.add_t ask, connecter.how_m any_connections ,
config['min_peers'], encoder.start_c onnection,
rawserver.add_t ask, storagewrapper. get_amount_left ,
upmeasure.get_t otal, downmeasure.get _total, listen_port,
config['ip'], myid, infohash, config['http_timeout'], errorfunc,
config['max_initiate'], doneflag, upmeasure.get_r ate,
downmeasure.get _rate,
encoder.ever_go t_incoming)

i think it might be a bit hard to non-autist to remember order of parameters
in such constructor. (and it's not the only one such place in BitTorrent)
and that guy teaches us how to write maintanable code!
http://advogato.org/article/258.html

thus, you don't need macros to write unmaintanable code -- functions are
enough for this. and with macros you can make it more maintanable, actually
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")

[Alex Mizrahi]

(message (Hello 'Ken)
(you :wrote :on '(Sat, 09 Dec 2006 04:26:02 -0500))
(

KTkeep the Pythonistas from straying. But you have an excuse: Lispniks
KTalways /talk/ about macros giving us the ability to create a DSL. But
KTno one does. :)

certainly there's no reason to make a new DSL each day, but sometimes they
are good.
i've recently posted an example of DSL to do queries to RDF data base -- i
find it's very helpful.

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")

[Paul Rubin]

Ken Tilton <ke*******@gmai l.comwrites:

What is up the power continuum from Lisp?

These days I've been fooling with Haskell. Mozart/Oz is also
interesting.

[Jon Harrop]

Mark Tarver wrote:

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.

From my point of view as neither a Lisp nor Python user:

Lisp has some interesting features that separate it from many other
programming languages. In contrast, there is nothing interesting about the
Python language, AFAIK.

Lisp is fairly elegant in the way that it facilitates different programming
paradigms. Python is inelegant.

Lisp is likely to be faster.

Lisp is more mature but Python is (currently) more popular.

I think that people who know more languages and more about programming will
be much more inclined to use Lisp than Python. Look at the contents of the
newsgroups for example, c.l.l has a thread on memoization whereas c.l.p has
a thread about wrestling oiled pigs.

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet

[Paul Rubin]

"Alex Mizrahi" <ud******@users .sourceforge.ne twrites:

we can implement Scheme's call-with-current-continuation first :)
it's relatively easy -- just a code walker that coverts everyting into CPS.

It's not enough to convert to CPS, you have to be able to actually
save the continuation when you switch to another one, so you can go
back to the first one later. Maybe I'm missing something but I just
don't see how to do that in the Lisp execution model. I guess you
could write an interpreter in Lisp that simulates it all, but it might
as well be a Python interpreter ;-).

[Pascal Costanza]

Ken Tilton wrote:

What is up the power continuum from Lisp?

3-Lisp. ;)
Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

[Pascal Costanza]

Paul Rubin wrote:

"Alex Mizrahi" <ud******@users .sourceforge.ne twrites:

>we can implement Scheme's call-with-current-continuation first :)
it's relatively easy -- just a code walker that coverts everyting into CPS.

It's not enough to convert to CPS, you have to be able to actually
save the continuation when you switch to another one, so you can go
back to the first one later.

You get this for free once your program is in CPS. (This is true for any
language, btw. It's just that it's easier to abstract away from the
details of CPS in Lisp.)
Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

[Alex Mizrahi]

(message (Hello 'Andrea)
(you :wrote :on '(Sat, 09 Dec 2006 11:08:34 +0100))
(

??>so we can see PyDict access. moreover, it's inlined, since it's very
??>performance-critical function.
??>but even inlined PyDict access is not fast at all. ma_lookup is a long
??>and hairy function containing the loop.

AGI once had a crazy idea about the lookup speed problem;
AGcan't the lookup result be cached in the bytecode ?

actually i don't see any reason why lookup is needed at all.
i think you can use approach similar to Lisp Symbols in Python, so it's
implementation slow, not the language.
there are some subtle differences -- for example, if you del global binding,
function gets undefined, but in Lisp uninterning does not invalidate code
that uses that symbols. but you can easily override this invalidating the
symbol bindings.

i think symbols can be implemented just as cache you suggest, but without
need of timestamp, but with additional indirection.
you should associate a SYMBOL with each entry in the globals dict, however
those SYMBOL lifetime should be managed independently (lifetime management
is one of difficulties, but i think not non-solvable). once you need to
cache lookup, you cache a SYMBOL pointer.
then you just get symbol's value on firther lookups. if dict gets update, it
should update all symbols associated with it. if entry (or whole dict) is
deleted, it should invalidate all symbols, so accessing them will produce
error, but it should not delete symbols.
you can resolve symbols not on first access, but during the read operation
(when bytecode is produced), as it's done in Lisp.

however, it's only applicable to LOAD_GLOBAL and STORE_GLOBAL, i think it
won't be possible to optimize STORE_ATTR that way without changing
semantics.

by the way, maybe some optimizations are already implemented in Psyco?
it's Python JIT with profile-guided type optimization, but i don't know how
it deals with lookups..

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")