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

[Bill Atkins]

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

>A compiler shifts a lot of decisions that an
interpreter would have to make at runtime to compile-time. There is
no reason a dynamic language can't enjoy this efficiency.

I'm not saying that it's impossible to compile
Python, only that's there's a lot more to it than
just macro expansion. The OP was saying something
like "If you added macros, you might get a compiler
for free", which is clearly far from true.

Yeah, my mistake - I simply glided right past the "just by macro
expansion." Oops. :)

>Despite its dynamism, Lisp is quite compilable.

Please correct me if I'm wrong, but as I understand,
getting efficient code out of a Lisp compiler requires
putting type declarations into the source.

If you put the same declarations into a piece of
Python code, then of course it would be fairly
straightforward to compile it efficiently. But it
wouldn't really be dynamic Python any more.

Type declarations can squeeze out extra efficiency, but vanilla Lisp
without type declarations will still beat Python, both because the
language is designed to compile well and because compilers for Lisp
are generally very mature. So it is not the case that type
declarations are the only thing that make Lisp efficient.

[Bill Atkins]

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

>>>Having edited both Lisp and Python code fairly
extensivel y,

How extensively?

Enough to know what I'm talking about. Tens
of thousands of lines of Lisp and Scheme, and
hundreds of thousands of lines of Python, I
would estimate.

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

To be honest, very little Python code. But I have manually indented
and rearranged enough code in other line-based languages to appreciate
the convenience of s-expression-based commands.

[Bill Atkins]

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

Pascal Costanza <[e-mail]:

>May you have tried the wrong Lisp dialects so far:

(loop for i from 2 to 10 by 2
do (print i))

The loop language is so complicated and confusing that I never
bothered trying to learn it. I always used simpler primitives to
write loops and it was always enough.

I think you're missing out. If you don't find LOOP appealing, look
for the ITERATE package. ITERATE is a more Lispy, more extensible
replacement for LOOP.

>This is Common Lisp. (Many Lisp and Scheme tutorials teach you that
you should implement this using recursion, but you really don't have
to. ;)

You can't really use that much recursion in Lisp because of the lack
of guaranteed TCO. I think that makes it reasonable to say that
Scheme is a functional language but Lisp is not. ("Functional " = it's
reasonable to code in a style where the only way to connect variables
to values is lambda binding (maybe through syntax sugar), so all loops
are implemented with recursion).

You should be pragmatic about this - I have never used a CL
implementation that didn't do TCO optimization (indeed, are there
any?). Although the standard doesn't require it, I treat it as a de
facto requirement and don't worry too much about it.

[Bill Atkins]

I V <wr******@gmail .comwrites:

On Sun, 10 Dec 2006 03:18:07 -0500, Bill Atkins wrote:

>We're not counting lines here, you goon. We're talking about how
expressive constructs are and how closely they match your concept of
what you want to do. The conditional example is lower-level; you're
talking to the interpreter instead of saying what you want to achieve.
You're having to repeat things because that's what the language asks
of you, instead of describing in a higher-level way what you're
actually doing.

To be a little provocative, I wonder if the idea that you're "talking to
the interpreter" doesn't apply more to lisp than to python; you can have
any syntax you like, as long as it looks like an AST.

Uhhh?

One of the things I've always found off-putting about lisp as that all the
syntax looks the same. In Algol-derived languages, each syntactic
construct has a fairly distinctive appearance, so when, for instance, I
encounter a for loop, I can quickly recognize that that's what it is, and
bracket out the "scaffoldin g" and pick out the details that interest me.
With lisp, I can't do that, I have to read through the sexp, decide on
what syntax it is, and then remind myself where to look for the relevant
specific details.

"Decide on what syntax it is"? Examples?

Now, this might well be just due to my comparative lack of familiarity
with lisp; I'd be interested to hear if you lisp people find different
lisp constructs as visually distinctive as constructs in python (or other
similar languages). But I think what people are getting at when they
complain about "all the brackets" in lisp may actually be this issue of
a visual distinction between different constructs (this is also a reason
why having a limited number of syntactic constructs can be helpful - there
are a probably a limited number of stereotypical layouts a programmer can
keep in their mind at once).

We rely on indentation for readability just as you guys do. Lisp
programs are not chaotic arrangements of parentheses and symbols; code
structure is made apparent through indentation.

(Why are people from c.l.p calling parentheses "brackets"? )

[Robert Brown]

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

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

I think CLPython is in the "children of a lesser Python" category, on the
grounds that it doesn't implement the complete language and there's no
obvious way to reuse the C packages that make CPython so useful. However,
the other distinguishing feature of the "children" category is bending
semantics to gain speed. CLPython doesn't appear to be doing much of this.
The author says it runs at about the same speed as CPython.

Python strings are implemented in CLPython as instances of a CLOS class, not
as raw Common Lisp strings, so they appear to be immutable.

[JShrager]

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

>

A compiler shifts a lot of decisions that an
interpreter would have to make at runtime to compile-time. There is
no reason a dynamic language can't enjoy this efficiency.

I'm not saying that it's impossible to compile
Python, only that's there's a lot more to it than
just macro expansion. The OP was saying something
like "If you added macros, you might get a compiler
for free", which is clearly far from true.

Speaking as the OP, let's see what the OP really said:

>... compilers are GREATLY facilitated by having a
macro facility because (at first blush) all you need to do is to
macro-expand down to something you know how to turn into code.
This isn't the only, nor perhaps the best way to get a compiler, but it's
a step in that direction. Later on you can learn the other great
features offered by homogeneous syntax, like being able to write code
walkers, which help improve over the "first blush" compiler....

So, "If you added macros, you might get a compiler for free" is not a
fair paraphrase of this.

(Another way, BTW, that macros improve efficiency is by replacing
function calls with in-line code. Another cheap improvement facilitated
by macros.)

[mystilleef]

Paddy wrote:

Robert Uhl wrote:

Steven D'Aprano <st***@REMOVE.T HIS.cybersource .com.auwrites:

>
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.

Of course, you use prefix notation all the time in Python:

for x in range(0,len(y)) :
dosomething(x)

In Python, most containers are directly iterable so we are much more
likely to arrange our program to use:
for a in y:
dosomethingwith (a)

-Paddy.

Or the more succinct Python (FP) construct:

map(dosomething , y)

[Kaz Kylheku]

Bill Atkins wrote:

(Why are people from c.l.p calling parentheses "brackets"? )

Because that's what they are often called outside of the various
literate fields.

[Raffael Cavallaro]

On 2006-12-12 19:18:10 -0500, "George Sakkis" <ge***********@ gmail.comsaid:

If you mistakenly select an extra parenthesis or omit one, it's
the same thing.

Because you can't mistakenly select an extra paren or omit one in a
lisp-aware editor. Whether its a commercial lisp IDE or emacs, you
don't manually select s-expressions. You put your cursor/point at one
paren and you tell the editor - with a keystroke or a mouse click - to
find the matching paren and select everything contained between the two.

[Lars Brinkhoff]

Bill Atkins <at****@rpi.edu writes:

the macro is just a friendlier syntax for expressing an idea.

I like that phrase!