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

[Ken Tilton]

greg wrote:

Bill Atkins wrote:

>You're missing Ken's point, which is that in Lisp an s-expression
represents a single concept - I can cut out the second form of an IF
and know that I'm cutting the entire test-form.

For selecting a single form, that's true. For
more than one form (such as selecting some, but
not all, of the statements in a loop body) it's
not much different.

But my point was that I don't find "manually
reindenting the lines" to be a chore. He made it
sound like you have to laboriously go through
and adjust the lines one by one, but it's not
like that at all. You shift them all at once
in a block.

It is a gray area. Manually maintaining indentation does not have to be
a "laborious chore" to slow down development.

I believe it was in the mid 1980s when I turned to the developer sitting
next to me and said, "I wonder how much time I spend re-tabbing my
code?" That was probably Vax Basic or COBOL. I /think/ the editor had a
block-tab capability, and I think I used same in some C IDES, but to be
honest retabbling a few lines was not such a laborious chore <gthat I
would first do the select operation to be able to use it.

Also, Python does not support a functional style of programming so the
line is the only meaningful textual entity. In this sense the
primitiveness of Python makes editing easier.

Finally, Python is just a (fine) scripting language. Which means one
does not tackle hard problems with it, the kind one figures out as one
goes. That means less refactoring, and less refactoring means less
slicing and dicing of the code.

Seeing as you asked, how much Python code have
you or Ken edited?

See above. Not Python, but out the wazoo in other languages.

Remember, we are not Lisp-only aliens, we program all the languages you
program, plus one. :)

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

[Robert Brown]

greg <gr**@cosc.cant erbury.ac.nzwri tes:

From another angle, think about what a hypothetical Python-to-Lisp
translator would have to do. It couldn't just translate "a + b" into
"(+ a b)". It would have to be something like "(*python-add* a b)" where
*python-add* is some support function doing all the dynamic dispatching
that the Python interpreter would have done.

Luckily, Willem Broekema has written a Python to Lisp compiler called
clpython that can be consulted to answer questions like these.

http://trac.common-lisp.net/clpython/

It turns out that addition is fairly straightforward . Attribute lookup,
however, turns out to be complex, as is comparing objects. Here is Willem's
description of the attribute lookup algorithm from the file doc/pres.txt:
To look up person.name (the "name" attribute of object "person")

a. if the class of "person" (say, Person), or one of Person's
base classes (say, Animal) defines __getattribute_ _,
that will intercept all attribute lookups.
Call: Animal.__getatt ribute__(person , name)

b. look in instance dictionary: val = person.__dict__["name"]

- but if it has fixed slots:
look in person.__slots_ _
and give error if "name" is not one of the fixed slots

- unless "__dict__" is specified as one of the fixed slots:
in that case, don't give an error if it is not one of the
fixed slots, but search in the instance dictionary too

c. look in the classes Person, Animal for an attribute called "name"

- if it is a `descriptor', call its __get__ method
- else, if it is a method, make it a bound method
- else, return it unchanged

d. if nothing found so far: look for __getattr__ method in the
classes, and call it: C.__getattr__(p erson, "name")

[Kaz Kylheku]

Paul Rubin wrote:

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.

Actual Lisp session transcript:

[1](load "infix.cl")
;; Loading file infix.cl ...
;;;
*************** *************** *************** *************** *************
;;; Infix notation for Common Lisp.
;;; Version 1.3 28-JUN-96.
;;; Written by Mark Kantrowitz, CMU School of Computer Science.
;;; Copyright (c) 1993-95. All rights reserved.
;;; May be freely redistributed, provided this notice is left intact.
;;; This software is made available AS IS, without any warranty.
;;;
*************** *************** *************** *************** *************
;; Loaded file infix.cl
T
[2]#i( if x < y then a[i] = b[j] else a[i] = c[j,j] ^^ w )

*** - EVAL: variable X has no value
The following restarts are available:
USE-VALUE :R1 You may input a value to be used instead of X.
STORE-VALUE :R2 You may input a new value for X.
ABORT :R3 ABORT
Break 1 [3]:a
[4](quote #i( if x < y then a[i] = b[j] else a[i] = c[j,j] ^^ w ))
(IF (< X Y) (SETF (AREF A I) (AREF B J))
(SETF (AREF A I) (EXPT (AREF C J J) W)))
In spite of such possibilities, things like this just don't catch on in
Lisp programming. Once people know that they /can/ get it if they want,
they no longer want it.

What doesn't make sense is writing entire language implementations from
scratch in order to experiment with notations.

I think someone may have been working on a Python interface built on
Common Lisp.

Ah, here!

http://trac.common-lisp.net/clpython/wiki/WikiStart

[Andrew Reilly]

On Tue, 12 Dec 2006 16:35:48 +1300, greg wrote:

When a Lisp compiler sees

(setq c (+ a b))

it can reasonably infer that the + is the built-in numeric
addition operator. But a Python compiler seeing

c = a + b

can't tell *anything* about what the + means without
knowing the types of a and b. They might be numbers, or
strings, or lists, or some user-defined class with its
own definition of addition.

That may be true, but lisp's numeric addition operator knows how to add
fixnums, bignums, rationals and whatever the lisp name for floating points
is (imprecise?) -- something that not many (if any) processor instruction
sets can manage. So that's still type-dependent dispatch, which isn't
going to get us to the speeds that we actually see reported unless there's
extra stuff going on. Type inference? Declarations?

Cheers,

--
Andrew

[Kay Schluehr]

Kaz Kylheku wrote:

Kay Schluehr wrote:

Juan R. wrote:

A bit ambiguous my reading. What is not feasible in general? Achieving
compositionalit y?

Given two languages L1 = (G1,T1), L2 = (G2, T2 ) where G1, G2 are
grammars and T1, T2 transformers that transform source written in L1 or
L2 into some base language
L0 = (G0, Id ). Can G1 and G2 be combined to create a new grammar G3
s.t. the transformers T1 and T2 can be used also to transform L3 = (G3
= G1(x)G2, T3 = T1(+)T2) ? In the general case G3 will be ambigous and
the answer is NO. But it could also be YES in many relevant cases. So
the question is whether it is necessary and sufficient to check whether
the "crossing" between G1 and G2 is feasible i.e. doesn't produce
ambiguities.

See, we don't have this problem in Lisp, unless some of the transfomers
in T1 have names that clash with those in T2. That problem can be
avoided by placing the macros in separate packages, or by renaming. In
In the absence of naming conflicts, the two macro languages L1 and L2
combine seamlessly into L3, because the transformers T are defined on
structure, not on lexical grammar.

Renaming is of course feasible too but it has to be done manually and
likely involves the change of some keyword. If both L1 and L2 define a
repeat_stmt with slightly different semantics they can't be combined -
renaming of rules is not always a big problem since a new package is
created for L3 anyway and scripts that work with L1 and L2 are at least
binary compatible with L3. The clash happens when one tries to edit an
L2 script in an L3 context. One has to refactor it regarding the
renamed rule ( this can very likely be done automatically ).

Since the rule definitions originate in different packages ( each
language is created in an own package ) there is basically no conflict
and one can switch between L1 and L2 and also import L1 in L2 or vice
versa but this is not the kind of composition I intend since one can't
really nest the statements/expressions made in L1 with those made in
L2.

The read grammar doesn't change (and
is in fact irrelevant, since the whole drama is played out with
objects, not text). In L1, the grammar is nested lists. In L2, the
grammar is, again, nested lists. And in L3: nested lists. So that in
fact, at one level, you don't even recognize them as being different
languages, but on a different level you can.

I don't see how this differs. A grammar G is just a "script" written in
another language ( say EBNF ) which can be represented within the sytem
as just another grammar. The internal representation of G is that of a
list of lists. While the programmer manipulates the surface structure
of the Grammar script which could be represented in whatever she likes
( currently as plain text but maybe also as a graph using dot and
graphviz or in any other slick way an UI designer imagines ) all
internal operations are defined on nested lists i.e. objects.

[Paul Rubin]

Robert Brown <bb****@speakea sy.netwrites:

Does this make Lisp "less dynamic" than Python? Espen would say it's not
less dynamic, but rather that a similar level of dynamism is achieved in
Common Lisp via well defined interfaces. The compiler knows the interfaces,
so it can do a better job optimizing the code.

I'd say Python is more dynamic in the sense that the Python runtime
system has to actually concern itself about the dynamism all the time
in practice, i.e. on every object method invocation. The Lisp runtime
only has to think about it when the application calls specific
functions in those interfaces. The rest of the time, it can use
various optimizations like compile-time analysis and caching. I do
not consider this contrast to be in Python's favor.

[Paul Rubin]

Robert Brown <bb****@speakea sy.netwrites:

Luckily, Willem Broekema has written a Python to Lisp compiler called
clpython that can be consulted to answer questions like these.

http://trac.common-lisp.net/clpython/

Does this count as a "children of a lesser Python"? How does clpython
implement Python's immutable strings, for example?

http://dirtsimple.org/2005/10/childr...er-python.html

[Kay Schluehr]

Paul Rubin wrote:

Robert Brown <bb****@speakea sy.netwrites:

Does this make Lisp "less dynamic" than Python? Espen would say it's not
less dynamic, but rather that a similar level of dynamism is achieved in
Common Lisp via well defined interfaces. The compiler knows the interfaces,
so it can do a better job optimizing the code.

I'd say Python is more dynamic in the sense that the Python runtime
system has to actually concern itself about the dynamism all the time
in practice, i.e. on every object method invocation. The Lisp runtime
only has to think about it when the application calls specific
functions in those interfaces. The rest of the time, it can use
various optimizations like compile-time analysis and caching. I do
not consider this contrast to be in Python's favor.

The main complaint I have myself is that the CPython runtime can't even
deal with static information presumed that it is available. Psyco
indeed can do it but it is a plugin and it is not supported and
understood by the whole core development team but only by Armin Rigo
himself. Instead of making up the CPython runtime for better support of
Psyco and related approaches Armin had to start PyPy ( this happened
more than 3 years ago! ) Now we are in the situation that parts of
Python are also RPython which means that their can be analyzed
statically but we need PyPy to compile them into CPython extensions.
This is really weird.

[Espen Vestre]

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

Robert Brown <bb****@speakea sy.netwrites:

Does this make Lisp "less dynamic" than Python? Espen would say it's not
less dynamic, but rather that a similar level of dynamism is achieved in
Common Lisp via well defined interfaces. The compiler knows the interfaces,
so it can do a better job optimizing the code.

[thank you for clarifying my post, Robert]

I'd say Python is more dynamic in the sense that the Python runtime
system has to actually concern itself about the dynamism all the time
in practice, i.e. on every object method invocation.

Ok, but when you state that language A is more dynamic than language
B, most programmers would interpret that as (or so I guess) "A offers
more dynamism to the programmer than B" - not that it burdens the run
time system implementor with more dynamism...

--
(espen)

[Juan R.]

Rob Thorpe ha escrito:

Juan R. wrote:

Ken Tilton ha escrito:

You missed it? Google fight:
>
http://www.googlefight.com/index.php...hon&word2=Ruby
>
Python wins, 74 to 69.3. And there is no Monty Ruby to help.
>
ken

Nice animation!

http://www.googlefight.com/index.php...rd2=Monty+Ruby

It's not fair to pick on him just because you're better at
Googlefighting. ..

I simply noticed (eval "there is no Monty Ruby to help") --NIL

http://www.googlefight.com/index.php...uan+Gonz%E1lez

This thing is strange, I don't understand it at all...

There is many "Juan González" but i am not one of them. Try next

http://www.googlefight.com/index.php...1lez+%C1lvarez

http://www.googlefight.com/index.php...=Robert+Thorpe
I find the results dubious. A conspiracy masterminded by Monty Ruby no
doubt.

With some help from mediocre programmers :)