merits of Lisp vs Python

[Ken Tilton]

Re: merits of Lisp vs Python



Steven D'Aprano wrote:

It is a good thing that not every
hare-brained idea that some random programmer comes up with can be
implemented as part of the core language.

Well, that's the FUD/strawman, but nothing more. Just a hobgoblin to
keep the Pythonistas from straying. But you have an excuse: Lispniks
always /talk/ about macros giving us the ability to create a DSL. But no
one does. :) Macros mostly hide implementation -- always a good thing --
where functions cannot.

This, btw, is why Norvig brushing off macros with the ability to use
regex to parse a DSL was so disappointing.

I guess your other excuse is that your BDFL says the same thing.

All in all, this is getting pretty funny. I am starting to picture you
all (including GvR) running around with your hands over your ears going
woo-woo so you cannot hear what we are saying.

:)

ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon

[Ken Tilton]

Re: merits of Lisp vs Python



Paul Rubin wrote:

>
Do you know the Paul Graham piece "Beating the Averages"? It's at:
>

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

>
The error in it is that Lisp is really just another Blub.
>

http://weblog.raganwald.com/2006/10/are-we-blub-programmers.html

>

There we find: "But when our hypothetical Blub programmer looks in the
other direction, up the power continuum, he doesn't realize he's looking
up. What he sees are merely weird languages... Blub is good enough for
him, because he thinks in Blub."

What is up the power continuum from Lisp?

ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon

[Alex Mizrahi]

Re: merits of Lisp vs Python

(message (Hello 'Paul)
(you :wrote :on '(08 Dec 2006 17:15:32 -0800))
(

PRHuh? Are you saying Lisp systems never release new versions? And you
PRcan't implement Python generators as Lisp macros in any reasonable
PRway. You could do them in Scheme using call-with-current-continuation
PRbut Lisp doesn't have that.

we can implement Scheme's call-with-current-continuation first :)
it's relatively easy -- just a code walker that coverts everyting into CPS.
i've used one for a web application development.

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

[Ramon Diaz-Uriarte]

Re: merits of Lisp vs Python

On 08 Dec 2006 19:56:42 -0800, Paul Rubin
<"http://phr.cx"@nospam. invalidwrote:

(...)

Lisp just seems hopelessly old-fashioned to me these days. A
modernized version would be cool, but I think the more serious
Lisp-like language designers have moved on to newer ideas.

Paul, I find most of your comments well thought. But I don't follow
these. Could you elaborate?

a) "old-fashioned"? Is that supposed to be an argument? I guess
addition and multiplication are old-fashioned, and so is calculus;so?
I think "old-fashioned" should only carry a negative connotation in
the fashion world, not in programming.


b) "the more serious Lisp-like language designers have moved on to
newer ideas." Can you elaborate? I am not an expert but by looking at,
say, lambda the ultimate, I'd say this statement is just not true. And
which are these "newer ideas"; what programming languages are
incorporating them? (Scala, Mozart/Oz, Alice-ML, ...).


R.

--

http://mail.python.org/mailman/listinfo/python-list

>

--
Ramon Diaz-Uriarte
Statistical Computing Team
Structural Biology and Biocomputing Programme
Spanish National Cancer Centre (CNIO)

http://ligarto.org/rdiaz

[Andrea Griffini]

Re: merits of Lisp vs Python

Alex Mizrahi wrote:

....

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.

I once had a crazy idea about the lookup speed problem;
can't the lookup result be cached in the bytecode ?
I am thinking to something like saving a naked pointer
to the value together with a timestamp of the dictionary.
With timestamp I mean an integer (may be 64 bit) that is
incremented and stamped in the dictionary every time
the dictionary is modified; this counter can be
shared among all dictionaries. The use of a naked pointer
would be IMO safe because to invalidate the object you
would also need to touch the dictionary.

Using this approach the lookup for a constant
string could be

if (bytecode_times tamp == dict->timestamp)
{
// just use the stored result
}
else
{
// do standard lookup and store
// result and dict->timestamp
}

I'd expect that this would be a big win for a lot of
lookup as the problem with python speed is the *potential*
dynamism... hopefully people don't keep changing what
math.sin is during the execution so the vast majority of
lookups at module level will find the timestamp being valid.
This invalidation is not "optimal" as changing math.sin
would also invalidate any lookup on math, but IMO a lot
of lookups happen in *fixed* dictionaries and the the
overhead of checking the cached result first should be
small. What it would break is code that actually
dynamically changes the string being looked up in the
dictionary in the bytecode, but I hope those places
are few if the exist at all.

Is this worth investigation or it has already
been suggested/tried ?

Andrea

[Steven D'Aprano]

Re: merits of Lisp vs Python

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]

Re: merits of Lisp vs Python

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]

Re: merits of Lisp vs Python

(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]

Re: merits of Lisp vs Python

(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]

Re: merits of Lisp vs Python

Ken Tilton <kentilton@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]

Re: merits of Lisp vs Python

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]

Re: merits of Lisp vs Python

"Alex Mizrahi" <udodenko@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]

Re: merits of Lisp vs Python

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]

Re: merits of Lisp vs Python

Paul Rubin wrote:

"Alex Mizrahi" <udodenko@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]

Re: merits of Lisp vs Python

(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")