merits of Lisp vs Python

[Steven D'Aprano]

Re: merits of Lisp vs Python

On Fri, 08 Dec 2006 14:52:33 -0500, Ken Tilton wrote:

>
>
Aahz wrote:

>In article <1165598576.650 860.126740@16g2 000cwy.googlegr oups.com>,
>Mark Tarver <dr.mtarver@uko nline.co.ukwrot e:
>>

>>>I'm looking at Python and I see that the syntax would appeal to a
>>>newbie. Its clearer than ML which is a mess syntactically. But I
>>>don't see where the action is in Python. Not yet anyway. Lisp syntax
>>>is easy to learn. And giving up an order of magnitude is a high price
>>>to pay for using it over Lisp.

>>
>>
>Speaking as someone who had been programming for more than twenty years
>before learning Python (including a brief gander at Lisp), and also
>referring to many years of observations of newcomers to Python: Python's
>syntax also appeals to experienced programmers.
>>
>I would say that your statement about Lisp syntax is wrong. Not that it
>is technically inaccurate, but that it completely misses the point, so
>much so that it is wrong to say it. One of the key goals of Python is
>readability, and while it is indeed easy to learn the rules for Lisp
>syntax, observational experience indicates that many people (perhaps even
>the vast majority of people) find it difficult to learn to read Lisp
>programs.

>
No programming language is easy to read,

Well, you've just blown your credibility out the water with that nonsense.

and no Lisp programmer stopped
using Lisp because they had been using it for a month and just could not
get used to reading it.

Or, to put it another way:

"No programmer who learned Lisp ever gave up before he learned Lisp."

I wonder, how many people gave up trying to learn Lisp because the
language was too hard for them to read? Anyone like to bet that the number
was more than zero?


--
Steven.

[Ken Tilton]

Re: merits of Lisp vs Python



Steven D'Aprano wrote:

On Fri, 08 Dec 2006 08:50:41 -0800, George Sakkis wrote:
>
>

>>André Thieme wrote:
>>
>>

>>>On the other hand can I see difficulties in adding macros to Python,
>>>or inventing a new object system, or adding new keywords without
>>>changing the sources of Python itself.

>>
>>Actually, an even bigger difficulty is the rejection of programmable
>>syntax by Guido, both for the near and distant future:

>
>
Why is that a difficulty? Like Guido, I think that's an ADVANTAGE.
>
>

>>"Programmab le syntax is not in Python's future -- or at least it's not
>>for Python 3000. The problem IMO is that everybody will abuse it to
>>define their own language. And the problem with that is that it will
>>fracture the Python community because nobody can read each other's code
>>any more."
>>
>>http://mail.python.org/pipermail/pyt...il/000286.html.

>
>
I couldn't have said it better myself.

No, but you could have quoted it more completely <g>:

But please save your breath. Programmable syntax is not in Python's
future -- or at least it's not for Python 3000. The problem IMO is
that everybody will abuse it to define their own language. And the
problem with that is that it will fracture the Python community
because nobody can read each other's code any more.

The last time c.l.l and c.l.p went to friendly war over macros we kept
wondering why macros were any less comprehensible than functions or
classes. Here it is!:

>
It's one thing to read code that calls an external function whose
meaning you have to guess from its name. It's quite another thing to
realize that you can't even know for sure where the function calls
are. Let's not go there.

GvR seems to be thinking of something like the loop macro, which in its
most commonly used syntax (it has two!) constitutes a distinct and
unlispy language. If that is how macros were normally used (LOOP is
quite abnormal) then, yikes, every macro could introduce a new language
to be mastered.

Uhhhh, that is not how macros are used normally. And it is a helluva lot
of work to erect a new syntax as LOOP does, so it is not exactly
tempting. So... is GvR being scared off by a straw man?

The other possibility is that he is just trying to justify not doing it
because it would be so hard without the regular syntax of Lisp,
including parens, and with the JIT module resolution problem discussed
earlier in his remarks. Understandable.

A final good reason is, hey, we already /have/ Lisp, Python needs to be
different in order not to get absorbed into the mother of all languages.

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

[hankhero]

Re: merits of Lisp vs Python

I was the one mentioning triple-quotes because it was one of the few
Python features i could think of that was better than Lisps.

For me python is 'strong OOP' scripting language in first place.
Inheritance, generalization and every kind of abstractions togeteher
with clean and simple syntax make python perfect language for medium
size "scripting" projects (ie just explore the code and add your
features, no messing with compilers).

The Common-Lisp object systems has all and more OO-features, some which
you never probably have thought of before. Here's one:
Inheritance lets you specialise a method so a rectangle and a circle
can have a different Draw method. If you wouldn't have OO you would
need a function with if statements to dispatch on thing, if
thing=rectange then drawRectangle if thing=circle then drawCircle.
What if you want a draw method that takes a thing and a backend, then
you need if statements again, draw(self,backe nd): if backend ==
postscript do one thing else do another.
Maybe you can solve this with multiple inheritance, creating
RectangePostscr ipt and CirclePostscrip t objects. Lisp supports multiple
inheritance too, but also multimethods which allow a looser coupling
between objects and dispatching on all parameters, not only the first
parameter (self in python speak). Just define one method
draw(rectange,p ostscript) and another draw(rectangle, pdf)

Exceptions, finally/except blocks,

Lisp has a unique exception system. Say ReadHtmlTag throws an exception
deep down in your system, UnexpectedChar. In Lisp you can define
recovery strategies all over your system. the IgnoreAttribute recovery
strategy can be in the same method as ReadHtmlTag. You can have another
ways to recover, IgnoreFile, or ReparseFile higher up in your program.
When you catch the error at the highest point in you main function, you
can choose which recovery you want to use. Either IgnoreAttribute and
continue in the ReadHtmlTag method or ReparseFile in the ParseFile
method. The stack and variables will be there right as when the error
occurred. If I write a library I don't have to guess if the users of my
library wan't me to show a nice GUI error message, ignore the error or
whatever. I provide all options and let they choose.

automatic reference counts and destructors make it easy to
write "robust" code.

No, Lisp doesn't have anything like that. There is a thing called the
garbage collector however, I think it exists in other languages.

[tmh]

Re: merits of Lisp vs Python

This is from the perspective of an aerospace engineer who passed
through python several years ago on the way to lisp. Futhermore, this
is a 2 glass of wine response.

Nota Bene: All references to lisp in this response imply common lisp.

Mark Tarver wrote:

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

Way back, my initial motivation for learning python was the desire for
something to post-process data files with a cleaner syntax than perl.
It did that in spades. Despite having taken a C++ course in college, it
wasn't until I started using python that I grokked concepts of object
orientation. The aforementioned course spent too much time on basic
concepts. I also envisioned being able to rapidly prototype things in
python, then migrate them to C for performance. Long term, that was
going to be the value of python, rapid prototype->C for performance.

After writing a C interface for python to an engineering analysis code,
I realized that there was nothing rapid about prototyping in python
then migrating to C. This was also a period of time where there was
some schizophrenia concerning numpy versus numeric python. I know this
has been hashed out now, but at the time it was a distraction from the
development of the library and I lost patience.

So, I began searching for alternatives. Spent a couple years with a
language that requires everything to be an object. Can someone hand me
a hammer, I have a round peg here and a square hole there. Didn't have
good numeric support, but based on other perceived advantages, I had
hashed out an object system that would have provided numeric support.
As I'm implementing the numeric stuff, I'm getting very annoyed with
changes in the language that are requiring redesign of my objects.
Plus, performance, while not bad, is not the best. The work required
starts to outway the benefits, so here I go again, searching for the
one language to rule them all. That's when I seriously consider lisp.
At this point, if lisp doesn't work out, I'm giving up and going back
to fortran, never to look at another language again. Ever.

So, six months ago, I start digging into lisp. Hmm, lisp promotes
functional programming, but you can do imperative if you really want
to, or objective, or aspect, or your own.

What about types? Well, to quote Yogi Berra, "In lisp, types are not
required until they are required." This is great, I can quickly thrash
out some code, profile, correct the algorithm, profile, add types, bam!
Good performance. Looking over CMUCL/SBCL, really good numeric
performance.

Playing with code that is 30 years old, still runs, nice.

Forced to learn emacs, why was I using vi again? In the correct
settings, slime can be fun. Emacs+SBCL is one setting, I'll let you
think of the other.

What the hell are closures? Oh, yeah, now I get it, functions with
state, I can use that in simulations with state vectors, very
intuitive.

And macros? Well, I don't need a domain specific language, yet, but
using macros to build closures with multiple functions and shoving as
much computation into the compilation stage as possible makes for very
fast iteration over ODE's. Now I'm simultaneously iterating over 3
variations of an ODE in less time than iterating over 1 ODE in the
previous one size fits all language.

Code is data is code. I know, a tired old cliche. But for an engineer
who wastes too much time data processing and not enough time
analyzing/understanding said data, this is very powerful and provides a
warm fuzzy feeling. Yet again, that could be the wine.

Note I'm not a Python person and I have no axes to grind here. This is
just a question for my general education.

I've been writing code for engineering solutions for 15 years in
various languages. I've gained more insight into coding in the last 6
months then in the previous 15 years. Since lisp allows you to employ
any and every programming technique, it actually requires you to
understand the techniques well enough to apply them when appropriate. I
still respect python if for no other reason than I learned concepts of
object orientation with it, but I don't consider for my coding.

You should study lisp for at least a year, use it for some decent size
projects. At the end of the day, even if you decide not to continue
using it, you will be a much better coder. My bet, though, is that if
you use it for a year, you won't want to use anything else. Don't be
deterred by the parens or the prefix notation. You will have to rewire
your brain to read lisp code, but the effort is worth it. The parens
disappear and there is an elegance and simplicity to prefix notation
that can't be matched by infix.

Time for some more wine.

Cheers,

Tom

[Ken Tilton]

Re: merits of Lisp vs Python



Steven D'Aprano wrote:

On Fri, 08 Dec 2006 14:52:33 -0500, Ken Tilton wrote:
>
>

>>
>>Aahz wrote:
>>

>>>In article <1165598576.650 860.126740@16g2 000cwy.googlegr oups.com>,
>>>Mark Tarver <dr.mtarver@uko nline.co.ukwrot e:
>>>
>>>
>>>>I'm looking at Python and I see that the syntax would appeal to a
>>>>newbie. Its clearer than ML which is a mess syntactically. But I
>>>>don't see where the action is in Python. Not yet anyway. Lisp syntax
>>>>is easy to learn. And giving up an order of magnitude is a high price
>>>>to pay for using it over Lisp.
>>>
>>>
>>>Speaking as someone who had been programming for more than twenty years
>>>before learning Python (including a brief gander at Lisp), and also
>>>referring to many years of observations of newcomers to Python: Python's
>>>syntax also appeals to experienced programmers.
>>>
>>>I would say that your statement about Lisp syntax is wrong. Not that it
>>>is technically inaccurate, but that it completely misses the point, so
>>>much so that it is wrong to say it. One of the key goals of Python is
>>>readabilit y, and while it is indeed easy to learn the rules for Lisp
>>>syntax, observational experience indicates that many people (perhaps even
>>>the vast majority of people) find it difficult to learn to read Lisp
>>>programs.

>>
>>No programming language is easy to read,

>
>
Well, you've just blown your credibility out the water with that nonsense.

I am delighted to learn I had any to begin with.

Perhaps you are thinking of individual lines of code being easy to read.
Sure. I am talking about algorithms. Code cannot be read as if it were
the Sunday comics. At any interesting level of complexity, one has to
slow down and effectively hand-execute code in one's mind, not just read
it as one reads natural language (and some of that makes one slow down
to, no matter how well known are the individual words and grammar).

>
>
>

>>and no Lisp programmer stopped
>>using Lisp because they had been using it for a month and just could not
>>get used to reading it.

>
>
Or, to put it another way:
>
"No programmer who learned Lisp ever gave up before he learned Lisp."

That would be the obvious retort, but my observation was empirical, so I
am afraid you need numbers, not word games.

You seem awfully hostile, by the way. Won't that make it harder to
conduct an intelligent exchange of value to lurkers?

I wonder, how many people gave up trying to learn Lisp because the
language was too hard for them to read? Anyone like to bet that the number
was more than zero?

Sorry, no one ever discovered Lisp, decided it would be great for
programming, started learning it and then gave up because they could not
handle the syntax. The syntax is actually easier to master because of
its regularity, and lisp-aware editors handle the parentheses such that
they disappear in a month.

Your position is untenable. It relies on this idea that all these Lisp
programmers not only handle Lisp syntax effortlessly but also praise it
as a significant advantage, they have all mastered several non-Lispy
languages, but...what? They are mutants? Who just happen to have no
problem with C and Java and Prolog and COBOL and Basic? Probably not.

If you are saying someone will glance at a Lisp book and say they cannot
understand it, well, that is not very interesting is it?

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

[Steven D'Aprano]

Re: merits of Lisp vs Python

On Fri, 08 Dec 2006 16:14:44 -0800, JShrager@gmail. com wrote:

>There is (IMO) some truth to that, but the flavor of Python
>programming is not that much like Lisp any more. Especially with
>recent Python releases (postdating that Norvig article) using iterator
>and generator objects (basically delayed evaluation streams) more
>heavily, Python is getting harder to describe in Lisp terms. It's
>moving more in the direction of Haskell.

>
Sorry, I missed something here. Why do you need a release to have these
sorts of things? Can't you just expand the language via macros to
create whatever facility of this sort you need... Oh, sorry. You CAN'T
expand the language.... Too bad.

No no, the phrase you want is "too good".

I guess waiting for Guido to figure
out what Fits Your Mind is part of The Python Way.

For the benefit of anyone who thinks that the troll has a point, consider
this.

In the real world, programmers aren't lone wolves stalking the programming
landscape doing their own thing. Whether we're talking open
source projects maintained by volunteers, or commercial software teams,
standardized languages are a good thing. 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.

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


--
Steven.

[Ken Tilton]

Re: merits of Lisp vs Python



tmh wrote:
<snip>

Time for some more wine.

....and then just cut and paste the snipped bit into:

http://wiki.alu.org/The_Road_to_Lisp_Survey

....if you are not there already. The survey questions are optional and
what you wrote is perfect as is. Tough call on what goes in:

http://wiki.alu.org/RtL_Highlight_Film

Candidates:

"If you use it for a year, you won't want to use anything else."
"I've gained more insight into coding in the last 6 months then in the
previous 15 years."

I'd go with:

"Yet again, that could be the wine."

:)

kt

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

[Paul Rubin]

Re: merits of Lisp vs Python

Ken Tilton <kentilton@gmai l.comwrites:

Not sure I understand why, unless you mean folks were raving about
Lisp in the 60s. Today's raving is about a much different language,
though the core elegance remains, and is as much about the contrast
with other languages as it is about the pleasure of Lisp itself. Those
raving about Lisp are quite accomplished at all those other languages,
and know about what they are talking. I doubt the Pythonistas weighing
in on this thread ever got far at all with Lisp, so... should they
really be offering comparative analysis?

I've used and implemented Lisp but am not a real expert. Some other
Python newsgroup regulars are very knowledgeable (more than me) about
it. Peter Norvig (author of that comparison page) wrote a Lisp book,
if I remember correctly.

Personally, I never like Lisp syntax; Clearly some people, some
fanatic judging by this thread :) think easily in prefix. I am not
one of them.

The syntax is a pretty superficial thing. The reaction from outsiders
to Lisp's parentheses and Python's indentation-based structure is
about the same. You get used to it either way.

The typical Pythonista values clean code but trembles in the face of
macros, which exist to hide boilerplate. That means the only thing
showing in any given block of code is exactly the interesting variable
and function names. Talk about readability.

There is just not that much boilerplate in Python code, so there's
not so much need to hide it.

Much of Lisp's power would be lost on a non-programmer, but Lisp might
make a programmer out of a non-programmer if they had it in them. You
might have the right language for you because what Python does have is
lotsa libraries, and if you are just hacking scripts to glue together
libraries the expressiveness of Lisp is more than offset by the better
library support in Python.

Python is more expressive than Lisp in the sense that its built-in
datatypes and simple syntax for using them has to be done through
kludgy macros and libraries with Lisp. I would say Lisp's facilities
for developing very large programs are better, and (for now) Lisp has
much more serious compilers. See the PyPy project for what's
happening in that direction with Python.

[Paul Rubin]

Re: merits of Lisp vs Python

"Wolfram Fenske" <int2k@gmx.netw rites:

with a couple of macros. I. e. if Common Lisp didn't have CLOS, its
object system, I could write my own as a library and it would be just
as powerful and just as easy to use as the system Common Lisp already
provides. Stuff like this is impossible in other languages.

If Common Lisp didn't have lexically scoped variables (most Lisp
dialects before Scheme didn't have them) then it would be very
difficult to add that with macros.

Do you seriously think lexical scoping is the last word in language
features and that there's now nothing left in other languages that
can't straightforward ly be done in CL? Hint:
call-with-current-continuation (also known as call/cc).

I just don't see a non-messy way to simulate Python generators in CL.
They can be done in Scheme using call/cc though.

Take a look sometime at Hughes' paper on "Why Functional Programming
Matters":

http://www.math.chalmers.se/~rjmh/Papers/whyfp.html

The examples in it are pretty easy to do in Python or Scheme, but I
think not so easy in CL.

[tayssir.john@googlemail.com]

Re: merits of Lisp vs Python

Steven D'Aprano wrote:

On Fri, 08 Dec 2006 08:50:41 -0800, George Sakkis wrote:
Why is that a difficulty? Like Guido, I think that's an ADVANTAGE.
>

"Programmab le syntax is not in Python's future -- or at least it's not
for Python 3000. The problem IMO is that everybody will abuse it to
define their own language. And the problem with that is that it will
fracture the Python community because nobody can read each other's code
any more."

http://mail.python.org/pipermail/pyt...il/000286.html.

>
I couldn't have said it better myself.

This is sort of the top-down philosophy, where you have a "benevolent
dictator" rather than more of a democracy. (People actually call them
benevolent dictators.) Like any other top-down society, the benevolent
dictator tells you that he and his lieutenants are merely protecting
you against anarchism; terrible things will happen if you have too much
freedom.

However, I am paid to write Common Lisp, I've recently seen a terribly
unreadable codebase, and the problem wasn't macros -- merely overuse of
global vars. Nothing exotic.

Do we ban loops and recursion because we face infinite looping? Or, as
"power users," do we do the obvious, which is to learn how to use power
correctly?

How do Lisp users deal with a powerful weapon like macros? Well first,
many people don't define new ones. Instead, they use someone else's
time-tested macros, from some library. However, when they do use
macros, it's to make less readable code more readable.

Is all Python code readable? I somehow doubt it. Is the pressure from
experienced Python users stretching Python away from a clean design? I
suspect it is. (Though I could be wrong, as I don't pay close attention
to Python at the moment.)

I'm not trying to convince anyone that Lisp's radical flexibility here
is "better", just there's a different perspective to consider than what
Guido says. Many in the Lisp community have noticed the frequency of
sentences starting with "Guido said" from the Python world, and maybe
that sounds as disturbing to heavy Lisp users as macros sound to heavy
Python users.


Tayssir

--
"Patriotism is usually the refuge of the scoundrel. He is the man who
talks the loudest."
-- Mark Twain, 1908

[Paul Rubin]

Re: merits of Lisp vs Python

"tmh" <tmh.public@gma il.comwrites:

I've been writing code for engineering solutions for 15 years in
various languages. I've gained more insight into coding in the last 6
months then in the previous 15 years. Since lisp allows you to employ
any and every programming technique, it actually requires you to
understand the techniques well enough to apply them when appropriate.

You might try Mozart, <http://mozart-oz.org>.

You should study lisp for at least a year, use it for some decent size
projects. At the end of the day, even if you decide not to continue
using it, you will be a much better coder. My bet, though, is that if
you use it for a year, you won't want to use anything else.

I've used Lisp for a long time and I've implemented it from scratch
(small dialects, not full CL) more than once. There's something
primordial about it that is very satisfying to the inner urges. But
there are higher forms of life out there these days too.

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

[Steven D'Aprano]

Re: merits of Lisp vs Python

On Sat, 09 Dec 2006 02:29:56 -0500, Ken Tilton wrote:

>
>
David Lees wrote:

Those raving about
Lisp are quite accomplished at all those other languages, and know about
what they are talking.

Such a sweeping generalization. Every person who raves about Lisp is also
accomplished with other languages. Yeah, right. I believe you, even if
millions wouldn't.

I doubt the Pythonistas weighing in on this
thread ever got far at all with Lisp, so... should they really be
offering comparative analysis?

I hit my hand with a hammer once. I didn't keep going until I was an
expert in hitting-own-hand-with-hammer before deciding that hitting my
hand with a hammer was not for me. Did I do the wrong thing? Should I have
kept going until I was an expect at it?

(Of course, writing Lisp isn't precisely like hitting one's hand with a
hammer. With the hammer, the endorphins kick in eventually, and it can
become quite pleasant...)

> Personally, I never like Lisp syntax;
>Clearly some people, some fanatic judging by this thread :) think easily
>in prefix. I am not one of them.

>
Yeah, you are, you just did not use it heads down for a month.

The sheer arrogance of this claim is astounding.

Actually, this is comp.lang.lisp. It isn't astounding at all.

I don't know, maybe lisp coders actually are more intelligent than
ordinary mortals, but it has been my experience that they have absolutely
no grasp whatsoever of the way most (many? some?) people think. And I'm
not talking about can't-walk-and-think-at-the-same-time people either, I'm
talking about bright, intelligent people who, nevertheless, don't agree
with lisp coders.

The way
to tell if you spent enough time on Lisp is to look at Lisp code. If you
see any parentheses, you have not spent enough time. They disappear in a
month.

If the parentheses are that meaningless, why do you need them?

The typical Pythonista values clean code but trembles in the face of
macros, which exist to hide boilerplate.

Funny, when I write code, I try to remove boilerplate, not hide it.

That means the only thing
showing in any given block of code is exactly the interesting variable
and function names. Talk about readability.

Yes. And your point is?

>Computer languages are tools and
>everyone should pick the ones that they are most comfortable and
>productive with.

>
No, languages are not interchangeable .

Perhaps you should consider what the term "Turing complete" implies.

Python is a fine language, but
Lisp is much more expressive/powerful.

Maybe so. A bulldozer is a lot more powerful than a tack-hammer, but if
somebody suggested using a bulldozer to lay carpet, I'd politely show them
to the door. Sometimes more power isn't better.


--
Steven.

[Paul Rubin]

Re: merits of Lisp vs Python

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

http://www.math.chalmers.se/~rjmh/Papers/whyfp.html

>
The examples in it are pretty easy to do in Python or Scheme, but I
think not so easy in CL.

Hmm, well I guess they can be done in CL too, about the same way as in
Scheme, but I'd say you have to be more careful.

[Alex Mizrahi]

Re: merits of Lisp vs Python

(message (Hello 'Kay)
(you :wrote :on '(8 Dec 2006 12:25:09 -0800))
(

KSO.K. I agree with what you said about the generic function vs per
KSobject dictionary dispatch.
KSBut do the performance differences vanish when only builtin types and
KSfunctions are used to express Python algorithms?

no.
language semantics require python to do dict lookup on each access to some
global function (or builtin) or variable.
i don't have enough time for in-depth analysis, but here's what's it.
suppose we have

def Fib(n):
if n < 2:
return 1
else:
return Fib(n -2) + Fib(n-1)

import dis
dis.dis(Fib)

you will see this:
....
21 LOAD_GLOBAL 1 (Fib)
24 LOAD_FAST 0 (n)
27 LOAD_CONST 2 (1)
30 BINARY_SUBTRACT
31 CALL_FUNCTION 1
34 LOAD_GLOBAL 1 (Fib)
37 LOAD_FAST 0 (n)
40 LOAD_CONST 1 (2)
43 BINARY_SUBTRACT
44 CALL_FUNCTION 1
47 BINARY_ADD
48 RETURN_VALUE

now let's check what is LOAD_GLOBAL in ceval.c (i have Python 2.4.1
sources):

case LOAD_GLOBAL:
w = GETITEM(names, oparg);
if (PyString_Check Exact(w)) {
/* Inline the PyDict_GetItem( ) calls.
WARNING: this is an extreme speed hack.
Do not try this at home. */
long hash = ((PyStringObjec t *)w)->ob_shash;
if (hash != -1) {
PyDictObject *d;
d = (PyDictObject *)(f->f_globals);
x = d->ma_lookup(d, w, hash)->me_value;
if (x != NULL) {
Py_INCREF(x);
PUSH(x);
continue;
}
d = (PyDictObject *)(f->f_builtins);
x = d->ma_lookup(d, w, hash)->me_value;
if (x != NULL) {
Py_INCREF(x);
PUSH(x);
continue;
}
goto load_global_err or;
}
}
/* This is the un-inlined version of the code above */
x = PyDict_GetItem( f->f_globals, w);
if (x == NULL) {
x = PyDict_GetItem( f->f_builtins, w);
if (x == NULL) {
load_global_err or:
format_exc_chec k_arg(
PyExc_NameError ,
GLOBAL_NAME_ERR OR_MSG, w);
break;
}
}
Py_INCREF(x);
PUSH(x);
continue;

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.
moreover, we can see that there are two dict lookups -- into globals and
builins.
lookup into a global hash should about order of magnitude slower than simple
table fetch, so here's the root of python's slowness.

how lisp can be faster here? lisp has SYMBOLs and well-defined semantics of
source code parsing.
first source code is processed by reader, that outputs trees of code. each
variable or function name becomes a SYMBOL object. symbols are typically
interned into packages, but they don't need to be looked-up in the packages
in runtime -- in fact, it's not possible at all.
i can read a piece of code and then unintern some symbol from package --
that will not make that code invalid. packages are used mostly by reader.
(also, i can have many symbols with same name, if they are not interned --
and they will be all different objects)
in runtime, lisp has to lookup symbol's function -- but symbol can be
implemented as a structure, and symbol-function can be just it's field
access.

one more thing -- you can see lookup into builins, so they are in dict too!
and you can see that builtins dict is checked only if name is not found in
globals, so builtins are even slower than globals. that's a reason for
performance slowdowns too.
one can say that it's the only way to change builtins in runtime. yes, but
dict lookup is a big price for it (well, if python use symbols, it would be
faster).
in fact, Common Lisp also allows to redefine "built-in" function -- you can
define a symbol with a same name as builtin in some package and use it, it
will "shadow" symbol in the common-lisp package (common-lisp:+). you can
change symbol-function of this symbol in runtime and do whatever you want.
but symbols in common-lisp package are immutable. that makes it possible to
optimize code.

and there's inlining. for example, in fib definition:

(defun fib (n)
(if (< n 2)
1
(+ (fib (- n 2))
(fib (- n 1)))))

CLISP does not even use symbol FIB in function bytecodes -- it notes that
it's a recursive function calls, so instead of normal function call it does
a local jump.

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

[Steven D'Aprano]

Re: merits of Lisp vs Python

On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:

if Common Lisp didn't have CLOS, its object system, I could write my own
as a library and it would be just as powerful and just as easy to use as
the system Common Lisp already provides. Stuff like this is impossible
in other languages.

Dude. Turing Complete. Don't you Lisp developers know anything about
computer science?

Anything any language can do is possible in any other language, if you are
willing to write your own libraries. And debug them. Let's not forget the
debugging and testing, unless you'd like us to believe that Lisp code
never contains bugs. 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."



--
Steven.