merits of Lisp vs Python

846 views
Skip to first unread message

Mark Tarver

unread,
Dec 8, 2006, 6:07:09 AM12/8/06
to
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

Mathias Panzenboeck

unread,
Dec 8, 2006, 6:45:52 AM12/8/06
to

I do not know much about Lisp. What I know is:
Python is a imperative, object oriented dynamic language with duck typing, List is a declarative,
functional dynamic language -> those two languages have different scopes.

For more Information:
http://en.wikipedia.org/wiki/Functional_programming
http://en.wikipedia.org/wiki/Object-oriented_programming
http://en.wikipedia.org/wiki/Dynamic_programming_language
http://en.wikipedia.org/wiki/Lisp_programming_language
http://en.wikipedia.org/wiki/Python_%28programming_language%29

Paul Rubin

unread,
Dec 8, 2006, 7:08:24 AM12/8/06
to
"Mark Tarver" <dr.mt...@ukonline.co.uk> writes:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?

<http://google.com/search?q=python+lisp&btnI=I'm+feeling+lucky>

Mark Tarver

unread,
Dec 8, 2006, 7:57:35 AM12/8/06
to

Thanks; a quick read of your reference to Norvig's analysis

http://norvig.com/python-lisp.html

seems to show that Python is a cut down (no macros) version of Lisp
with a worse performance. The only substantial advantage I can see is
that GUI, and Web libraries are standard. This confirms my suspicion
that Lisp is losing out to newbies because of its
lack of standard support for the things many people want to do.

Mark

Fredrik Lundh

unread,
Dec 8, 2006, 8:47:35 AM12/8/06
to pytho...@python.org
Mark Tarver wrote:

> seems to show that Python is a cut down (no macros) version of Lisp
> with a worse performance.

"can be seen as, by a Lisp programmer", perhaps. it's not like anybody set out
to make a Lisp-with-other-syntax but "failed"...

</F>

Richard Brodie

unread,
Dec 8, 2006, 9:08:09 AM12/8/06
to

"Mark Tarver" <dr.mt...@ukonline.co.uk> wrote in message
news:1165582654.9...@79g2000cws.googlegroups.com...

> seems to show that Python is a cut down (no macros) version of Lisp
> with a worse performance.

Performance claims are always controversial. So, Python is much slower
doing array multiplication, when you hand roll it, instead of using the
standard numerical packages available.

I see that the effbot has already responded the first part.

Istvan Albert

unread,
Dec 8, 2006, 9:11:20 AM12/8/06
to
Mark Tarver wrote:

> seems to show that Python is a cut down (no macros) version of Lisp
> with a worse performance.

or maybe it shows that Lisp is an obfuscated version of Python with
lots of parentheses, backward logic, and complicated constructs that
run faster.

i.

Tim Chase

unread,
Dec 8, 2006, 9:19:21 AM12/8/06
to Mark Tarver, pytho...@python.org
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?

Easy...
Python reads like pseudocode
Lisp reads like line-noise (much like most Perl or Ruby code)


Python makes better use of my time as a programmer because it
maps fairly closely to how I think, as well as being easy to pick
up when you've been away from the code for several months.

-tkc


Harry George

unread,
Dec 8, 2006, 9:14:20 AM12/8/06
to
"Mark Tarver" <dr.mt...@ukonline.co.uk> writes:

It is not just a newbie thing. Even people who are reasonably fluent
in Lisp use Python for many tasks, and some make python the default
with Lisp as a special case. It would probably be fair to say that
the more you know about a variety of languages, the more you
appreciate Python.


--
Harry George
PLM Engineering Architecture

Alex Mizrahi

unread,
Dec 8, 2006, 9:43:23 AM12/8/06
to
(message (Hello 'Richard)
(you :wrote :on '(Fri, 8 Dec 2006 14:08:09 -0000))
(

??>> seems to show that Python is a cut down (no macros) version of Lisp
??>> with a worse performance.

RB> Performance claims are always controversial. So, Python is much slower
RB> doing array multiplication, when you hand roll it, instead of using the
RB> standard numerical packages available.

heh, do you have "standard numeric packages" for everything? maybe then
we'll make standard programs for everything -- that will obsolete "slow"
"custom scripts" and we'll just use shell to select what program we want to
run?
certainly, it's possible to write code in C and use FFI to access it, but
it's not suitable for rapid prototyping/fast development, when requirements
may change, or you're just experimenting with different methods.

it's interesting than as of bare "interpreter overhead", python is aprox
order of magnitude (10 times) slower than lisp interpreters. it's also
interesting, that python, perl, php and ruby show very similar peformance,
while lisp and scheme implementations show large improvements -- it makes me
think that there's something "pathalogically scripting" in their
specifications (maybe some obligatory use of strings for method dispatch?).

note that i've mentioned "lisp interpreters" above. as for lisp _compilers_,
they run lots faster than lisp interpreters.

please check http://shootout.alioth.debian.org/
to compare Python to Lisp SBCL. lisp is faster more then 10 times in many
benchmarks, and even more than 100 times faster in two benchmarks.
unfortunately there's no lisp interpreters (CLISP) in the benchmark.

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


Alex Mizrahi

unread,
Dec 8, 2006, 9:50:01 AM12/8/06
to
(message (Hello 'Istvan)
(you :wrote :on '(8 Dec 2006 06:11:20 -0800))
(

??>> seems to show that Python is a cut down (no macros) version of Lisp
??>> with a worse performance.

IA> or maybe it shows that Lisp is an obfuscated version of Python

hell no, lisp's syntax is much easier than python's since it's homogenous
(and certainly lisp was invented much 30 years before Python, so that's
Python uses Lisp features)

IA> with lots of parentheses,

that make logic more explicit

IA> backward logic,

??

IA> and complicated constructs that run faster.

no, there are no complicted constructs -- just it's designed with 30-year
history in mind, not like "let's make another simple scripting language".

Ken Tilton

unread,
Dec 8, 2006, 9:55:55 AM12/8/06
to

Mark Tarver wrote:
> How do you compare Python to Lisp?

Lisp programmers are smarter and better looking. And better programmers.
Not sure if that is what you were after, though.

> What specific advantages do you
> think that one has over the other?

http://www.googlefight.com/index.php?lang=en_GB&word1=parentheses&word2=white+space

Ouch.

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

Wade Humeniuk

unread,
Dec 8, 2006, 10:12:37 AM12/8/06
to
Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
>

Since the late 1950's Lisp has participated in the development of
modern (present day) programming practises. It has shaped and been
shaped by the minds of just not programmers, but people involved
in dealing with the larger impacts and possibilities.
Its been there, is here, and will continue to be there in the future.
Lisp is a human construct that is a force to be reckoned with. Its
construction reflects something very deep and fundamental about
computing. So, it depends on what you want.

What do you want?

W

Richard Brodie

unread,
Dec 8, 2006, 10:29:15 AM12/8/06
to

"Alex Mizrahi" <udod...@users.sourceforge.net> wrote in message
news:45797a0c$0$49204$1472...@news.sunsite.dk...

> heh, do you have "standard numeric packages" for everything? maybe then we'll make
> standard programs for everything -- that will obsolete "slow" "custom scripts" and we'll
> just use shell to select what program we want to run?

No, I was observing that, faced with a matrix multiplication problem, most
sensible Python developers would do "apt-get install python-numeric" or
equivalent. Trying to do it in pure Python would be the wrong tool for the
job. If you think that's a weakness of Python compared to Lisp, then so
be it.


Rob Thorpe

unread,
Dec 8, 2006, 10:54:43 AM12/8/06
to
Mathias Panzenboeck wrote:
> 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.
> >
> > Mark
> >
>
> I do not know much about Lisp. What I know is:
> Python is a imperative, object oriented dynamic language with duck typing,

Yes, but Python also supports the functional style to some extent.

> List is a declarative,
> functional dynamic language

Lisp is only a functional language in that it support both functional
and imperative programming styles. Duck typing is almost identical to
latent typing in Lisp.
And, Common Lisp at least is object orientated.

> -> those two languages have different scopes.

Their scope is actually very similar. Learn about lisp and you will
soon discover their similarity.

Kay Schluehr

unread,
Dec 8, 2006, 11:03:18 AM12/8/06
to
Alex Mizrahi schrieb:

> it's also
> interesting, that python, perl, php and ruby show very similar peformance,
> while lisp and scheme implementations show large improvements -- it makes me
> think that there's something "pathalogically scripting" in their
> specifications (maybe some obligatory use of strings for method dispatch?).

"The most unusual features of the SBCL compiler (which is very similar
to the original CMUCL compiler, also known as Python) is its unusually
sophisticated understanding of the Common Lisp type system and its
unusually conservative approach to the implementation of type
declarations.

These two features reward the use of type declarations throughout
development, even when high performance is not a concern. Also, as
discussed in the chapter on performance (see Efficiency), the use of
appropriate type declarations can be very important for performance as
well."

http://www.sbcl.org/manual/Handling-of-Types.html#Handling-of-Types

If you'd read the docs of the tools you admire you might find the
answers yourself.

Carl Banks

unread,
Dec 8, 2006, 11:16:33 AM12/8/06
to
Mark Tarver wrote:
> This confirms my suspicion
> that Lisp is losing out to newbies because of its
> lack of standard support for the things many people want to do.

Whoa there, that's a pretty big logical jump there, don't you think?

Consumer choice can never be boiled down to one thing; there are so
many factors. No one knows the whole answer. I certainly don't. (If
I did, I'd be courteously turning down the Nobel Prize for Economics on
account of being so rich I really didn't need the extra pocket change.)

I have no doubt that what you say is a contributing factor, but if I
had to guess the main reason why Lisp is losing out to newbies, I'd say
it's first impressions. When newbies see Python they say, "Ok, I can
kind of follow that, it doesn't look too hard to learn." When they see
Lisp they say, "WTF IS THAT???"

It's kind of sad, in a way, that a superficiality would be so crucial.
(Not that I think outward appearance is all superficial--I think humans
have evolved and/or learned to regard as beautiful that which minimizes
effort--but it's not the whole story and not basis for a whole
judgment.)


Carl Banks

hankhero

unread,
Dec 8, 2006, 11:17:01 AM12/8/06
to
One overlooked advantage for Lisp over Python is a better development
environment, for me that means Slime for Lisp. For Python I have
several years of experience with IDLE and the win32 Ide, and Slime is
the winner. Press a key and the function you are editing is recompiled
and loaded into memory. The crossreference and the object inspector is
very nice. How about fuzzy-complete, I only have to write de-me and
press tab, and I get define-method-combination.
Slime coupled with the paredit structured editing mode, which lets you
edit Lisp code as list structure rather than characters, is a dream.

Pythons advantages are:

Faster startup-time which makes it a good scripting language.

More platforms, there is no Common Lisp on Nokia phones.

Some clever details, like using minus to index vectors from the right.
(aref "hello" -1) gives an error on Lisp, but the character o on
Python.

Another detail I like is that you can choose how to quote strings, in
Python you can write three double-quotes to start a string that can
include anything, quotes, doublequotes and newlines.
You can use double-quote if you want to embed single-quotes "john's" or
single-quote if you want to embed double-quotes '<id="2">'.

Talking about Lisps advantages will take me too long.

/hankhero, a switcher.

Fredrik Lundh

unread,
Dec 8, 2006, 11:26:55 AM12/8/06
to pytho...@python.org
Carl Banks wrote:

> Consumer choice can never be boiled down to one thing; there are so
> many factors. No one knows the whole answer. I certainly don't.

it's all due to Python's humongous marketing budget, of course. just
imagine what would have happened if someone had spent that much VC money
on Lisp.

</F>

Bjoern Schliessmann

unread,
Dec 8, 2006, 11:31:08 AM12/8/06
to
Alex Mizrahi wrote:

> hell no, lisp's syntax is much easier than python's since it's
> homogenous

Can you give an example? I cannot imagine how homogenity always
results in easiness.

> (and certainly lisp was invented much 30 years before
> Python, so that's Python uses Lisp features)

I think you acknowledged that the syntax is different and not
borrowed?

[many parentheses]


> that make logic more explicit

Can you give an example?

Regards,


Björn

Xpost cll,clp

--
BOFH excuse #166:

/pub/lunch

Soni Bergraj

unread,
Dec 8, 2006, 10:55:25 AM12/8/06
to Mark Tarver, pytho...@python.org
Mark Tarver wrote:
> seems to show that Python is a cut down (no macros) version of Lisp
> with a worse performance.

If you wont to put it this way, go for it. But if you care to give it a
closer look, you may understand that Pythons main advantage is not
seizable by feature and performance charts.

Regards,
--
Soni Bergraj
http://www.YouJoy.org/

George Sakkis

unread,
Dec 8, 2006, 11:33:32 AM12/8/06
to
Alex Mizrahi wrote:

> (message (Hello 'Istvan)
> (you :wrote :on '(8 Dec 2006 06:11:20 -0800))
> (
>
> ??>> seems to show that Python is a cut down (no macros) version of Lisp
> ??>> with a worse performance.
>
> IA> or maybe it shows that Lisp is an obfuscated version of Python
>
> hell no, lisp's syntax is much easier than python's since it's homogenous

It sure is easier... if you're a compiler rather than a human. Also a
lightbulb is much easier understood as a bunch of homogeneous elemental
particles.

George

André Thieme

unread,
Dec 8, 2006, 11:36:14 AM12/8/06
to
hankhero schrieb:

> Some clever details, like using minus to index vectors from the right.
> (aref "hello" -1) gives an error on Lisp, but the character o on Python.

It would not be difficult to add this feature to Lisp.


> Another detail I like is that you can choose how to quote strings, in
> Python you can write three double-quotes to start a string that can
> include anything, quotes, doublequotes and newlines.
> You can use double-quote if you want to embed single-quotes "john's" or
> single-quote if you want to embed double-quotes '<id="2">'.

You could add a reader macro in Lisp that allows you to do the same.
At the moment I would say that one could pretty much add most Python
features to Lisp. Be it slicing, list comprehension, or, if one wants,
Pythons object system.

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.


André
--

Petter Gustad

unread,
Dec 8, 2006, 1:48:13 PM12/8/06
to
Bjoern Schliessmann <usenet-mail-03...@spamgourmet.com> writes:

> Can you give an example? I cannot imagine how homogenity always
> results in easiness.

CL-USER> (+ 1 2 3 4 5 6 7 8 9 10)
55

CL-USER> (< 1 2 3 4 5 6 7 8 9 10)
T
CL-USER> (< 1 2 3 4 5 6 7 8 9 10 9)
NIL


Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Bill Atkins

unread,
Dec 8, 2006, 11:44:23 AM12/8/06
to
Bjoern Schliessmann <usenet-mail-03...@spamgourmet.com> writes:

> I think you acknowledged that the syntax is different and not
> borrowed?

Um, so does that mean that Python couldn't have borrowed other
features?

Bill Atkins

unread,
Dec 8, 2006, 11:47:58 AM12/8/06
to
"Mark Tarver" <dr.mt...@ukonline.co.uk> writes:

What was the reasoning behind cross-posting this to c.l.p and c.l.l?
This type of question inevitably leads to controversy.

George Sakkis

unread,
Dec 8, 2006, 11:50:41 AM12/8/06
to
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:

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

http://mail.python.org/pipermail/python-3000/2006-April/000286.html.


George

Alex Mizrahi

unread,
Dec 8, 2006, 11:52:15 AM12/8/06
to
(message (Hello 'Kay)
(you :wrote :on '(8 Dec 2006 08:03:18 -0800))
(

KS> http://www.sbcl.org/manual/Handling-of-Types.html#Handling-of-Types

KS> If you'd read the docs of the tools you admire you might find the
KS> answers yourself.

SBCL is a COMPILER that explains everything. it's interesting why
INTERPRETER like CLISP is faster.
well, it can be type declarations as well, but maybe something other too..

for example, in languages like Python, PHP and JavaScript, as i understand,
by semantics of the language interpreter MUST use dict to call objects
method -- at any time it can be changed, for any object instance. i'm not
sure whether it has to dynamically resolve package's methods doing lookup in
packages dict.

however, in Common Lisp object methods are dispatched on object types, that
is a special language entity, so as long as new types are not introduced,
interpreter can optimize calls how it wants to. the difference is that while
it's still dynamic, dispatch over types are more controlled/optimizable than
dispatch using dict.
then, symbols in common-lisp package cannot be changed according to spec,
thus compiler/interpreter is safe to do optimizations it wants when sees
that symbols (if we want symbols with same names, we can make other package
with them).

then, Common Lisp standard defines what inlining is. i bet most
optimizations in dynamic languages are not possible if inlining is not
enabled -- since any symbol that is not inlined can change it's meaning in
any time.

JShr...@gmail.com

unread,
Dec 8, 2006, 12:03:53 PM12/8/06
to
Sounds like it's time for:

A Beginners' Meta FAQ for comp.lang.lisp:

http://nostoc.stanford.edu/jeff/llisp/cllfaq.html

The purpose of this page is to help those new to Lisp (aka. "newbies")
gain some background before they enter the fray of comp.lang.lisp
(c.l.l). This is not a complete Lisp FAQ! Once you have a sense of Lisp

and of how c.l.l operates you should have no trouble finding all the
additional information you need, either by your own search efforts or
by asking the community. If you have issues with any of the below
please do not send me email. Rather, post on c.l.l in the weekly thread

where this is announced (heading: "*** C.L.L README/FAQ ***").

Alex Mizrahi

unread,
Dec 8, 2006, 12:08:04 PM12/8/06
to
(message (Hello 'Bjoern)
(you :wrote :on '(Fri, 08 Dec 2006 17:31:08 +0100))
(

??>> hell no, lisp's syntax is much easier than python's since it's
??>> homogenous

BS> Can you give an example? I cannot imagine how homogenity always
BS> results in easiness.

homogenity means that i can cut any expression and paste in any other
expression, and as long as lexical variables are ok, i'll get correct
results -- i don't have to reindent it or whatever.
this is aproximately what programmer does -- he paste pieces of code from
his mind into the program.

BS> [many parentheses]
??>> that make logic more explicit
BS> Can you give an example?

also, there's no need for operator precendence to be taken in accound --
order is explicitly defined. expressions are homogenous, they do not depend
on other expressions near them (except lexical variables and side effects).

the other example of homogenous syntax is XML, that is very popular
nowadays, and it's very similar to lisp's s-expressions.

certainly, it's a matter of taste what syntax to prefer -- i prefer lisp
syntax, others might prefer Python, ML or Haskell syntax.
but homogenous syntax is very important for true macros.

??>> (and certainly lisp was invented much 30 years before
??>> Python, so that's Python uses Lisp features)

BS> I think you acknowledged that the syntax is different and not
BS> borrowed?

certainly

Fredrik Lundh

unread,
Dec 8, 2006, 12:16:17 PM12/8/06
to pytho...@python.org
JShr...@gmail.com wrote:

> Sounds like it's time for:
>
> A Beginners' Meta FAQ for comp.lang.lisp:
>
> http://nostoc.stanford.edu/jeff/llisp/cllfaq.html
>
> The purpose of this page is to help those new to Lisp (aka. "newbies")
> gain some background before they enter the fray of comp.lang.lisp

so why are you posting this to comp.lang.python ?

</F>

Mark Tarver

unread,
Dec 8, 2006, 12:22:56 PM12/8/06
to

I don't mind controversy - as long as there is intelligent argument.
And since it involves Python and Lisp, well it should be posted to both
groups. The Lispers will tend to say that Lisp is better for sure -
so it gives the Python people a chance to defend this creation.

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.

Mark

Rob Thorpe

unread,
Dec 8, 2006, 12:24:26 PM12/8/06
to
Alex Mizrahi wrote:
> (message (Hello 'Kay)
> (you :wrote :on '(8 Dec 2006 08:03:18 -0800))
> (
>
> KS> http://www.sbcl.org/manual/Handling-of-Types.html#Handling-of-Types
>
> KS> If you'd read the docs of the tools you admire you might find the
> KS> answers yourself.
>
> SBCL is a COMPILER that explains everything. it's interesting why
> INTERPRETER like CLISP is faster.
> well, it can be type declarations as well, but maybe something other too..

I agree with your other points. Python allows the programmer to
override absolutely anything, including things like addition. This
entails extra work.

It's also worth mentioning that Clisp is an hugely optimized
interpreter. A much work has been put in to making it's bytecode
interpreting inner loops as fast as possible.

Kaz Kylheku

unread,
Dec 8, 2006, 1:17:19 PM12/8/06
to
Mark Tarver wrote:
> I don't mind controversy - as long as there is intelligent argument.
> And since it involves Python and Lisp, well it should be posted to both
> groups. The Lispers will tend to say that Lisp is better for sure -
> so it gives the Python people a chance to defend this creation.

And that would be our confirmation that this is another trolling
asshole.

Jan Dries

unread,
Dec 8, 2006, 1:35:15 PM12/8/06
to pytho...@python.org
Alex Mizrahi wrote:
> RB> Performance claims are always controversial. So, Python is much slower
> RB> doing array multiplication, when you hand roll it, instead of using the
> RB> standard numerical packages available.
>
> heh, do you have "standard numeric packages" for everything? maybe then
> we'll make standard programs for everything -- that will obsolete "slow"
> "custom scripts" and we'll just use shell to select what program we want to
> run?

I think you're missing the point. You must know your language's
strengths and weaknesses, and use the approach/function/library that's
right for the job in the given language.

For instance, on my machine the following Python-code:

some_string = ""
while len(some_string) < 100000:
some_string += "*"

outperforms the following C-code:

strcpy(some_string,"");
while(strlen(some_string) < 100000)
strcat(some_string,"*");

by roughly *factor 15*!

The point of course is you shouldn't be using strlen/strcat this way,
nor use this piece of code as a reference for benchmarking C versus
Python performance.
And for the same reason: in the presence of excellent optimized Python
libraries for matrix multiplication, you probably shouldn't be doing
that in pure Python if performance matters, nor use that as a reference
case in benchmarking Python.

Regards,
Jan

Mark Tarver

unread,
Dec 8, 2006, 1:45:42 PM12/8/06
to

This would be a confirmation that you are ignorant in your manners and
don't know how to address a straight question.

Mark

Bjoern Schliessmann

unread,
Dec 8, 2006, 1:51:03 PM12/8/06
to
Bill Atkins wrote:

> Um, so does that mean that Python couldn't have borrowed other
> features?

No, but he used this point in direct conjunction with the syntax. At
least by my understanding.

Regards,


Björn

Xpost cll,clp

--
BOFH excuse #61:

not approved by the FCC

Bjoern Schliessmann

unread,
Dec 8, 2006, 1:52:13 PM12/8/06
to
Petter Gustad wrote:
> Bjoern Schliessmann <usenet-mail-03...@spamgourmet.com>

>> Can you give an example? I cannot imagine how homogenity always
>> results in easiness.

> CL-USER> (+ 1 2 3 4 5 6 7 8 9 10)
> 55
>
> CL-USER> (< 1 2 3 4 5 6 7 8 9 10)
> T
> CL-USER> (< 1 2 3 4 5 6 7 8 9 10 9)
> NIL

Please forgive me, it's too easy for me to understand.

Regards,


Björn ;)

Xpost cll,clp

--
BOFH excuse #262:

Our POP server was kidnapped by a weasel.

Pillsy

unread,
Dec 8, 2006, 1:56:11 PM12/8/06
to
hankhero wrote:
[...]
> Pythons advantages are:

> Faster startup-time which makes it a good scripting language.

I agree with the others (especially the cleverness of Python's string
quoting), but on my machine, SBCL starts up and runs a "Hello World"
program a bit faster than Python, and CLisp really blows its doors off.

Cheers, Pillsy

Bjoern Schliessmann

unread,
Dec 8, 2006, 1:57:28 PM12/8/06
to
Alex Mizrahi wrote:
> (message (Hello 'Bjoern)

>> BS> Can you give an example? I cannot imagine how homogenity
>> always BS> results in easiness.

> homogenity means that i can cut any expression and paste in any
> other expression, and as long as lexical variables are ok, i'll
> get correct results -- i don't have to reindent it or whatever.

Ah, so *that's* what you meant ... but I don't really understand the
ease of it.



> also, there's no need for operator precendence to be taken in
> accound -- order is explicitly defined. expressions are
> homogenous, they do not depend on other expressions near them
> (except lexical variables and side effects).

Sorry, I don't get it ;) Where does Python have things like
nonexplicit defined operator order?



> the other example of homogenous syntax is XML, that is very
> popular nowadays, and it's very similar to lisp's s-expressions.

Spoken freely, I don't like XML because it's hardly readable. Is
it "easy"? If yes, what's your definition of "easy"?

Regards,


Björn

Xpost cll,clp
--
BOFH excuse #437:

crop circles in the corn shell

Neil Cerutti

unread,
Dec 8, 2006, 2:30:39 PM12/8/06
to
["Followup-To:" header set to comp.lang.python.]

On 2006-12-08, Mark Tarver <dr.mt...@ukonline.co.uk> wrote:
> 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.

And if you stew it like applesauce, it tastes more like prunes
than rhubarb does.

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

I find it easier to learn syntax than special forms. But either
system comes naturally enough with practice.

--
Neil Cerutti

Aahz

unread,
Dec 8, 2006, 2:46:58 PM12/8/06
to
In article <1165598576.6...@16g2000cwy.googlegroups.com>,

Mark Tarver <dr.mt...@ukonline.co.uk> wrote:
>
>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.

As for your claims about speed, they are also nonsense; I doubt one
would find an order of magnitude increase of speed for production
programs created by a competent Lisp programmer compared to programs
created by a competent Python programmer.

Consider this: Lisp has had years of development, it has had millions of
dollars thrown at it by VC firms -- and yet Python is winning over Lisp
programmers. Think about it.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/

Member of the Groucho Marx Fan Club

Ken Tilton

unread,
Dec 8, 2006, 2:48:50 PM12/8/06
to

Bjoern Schliessmann wrote:
> Alex Mizrahi wrote:
>
>>(message (Hello 'Bjoern)
>
>
>>> BS> Can you give an example? I cannot imagine how homogenity
>>> always BS> results in easiness.
>
>
>
>>homogenity means that i can cut any expression and paste in any
>>other expression, and as long as lexical variables are ok, i'll
>>get correct results -- i don't have to reindent it or whatever.
>
>
> Ah, so *that's* what you meant ... but I don't really understand the
> ease of it.

Code in the abstract exists as a tree of trees. With parens, we now have
textual markers delimiting these trees. That means I can point to any
arbitrary subtree by pointing to its left or right parens, and tell the
editor to copy or delete "that chunk of logic". And now I am
manipulating chunks of program logic instead of text.

One simple but hopefully illustrative example: suppose I have an if
statement with two big branches. My code then looks like:
(if (condition) (big-branch-1)(big-branch-2))

Please remember that any of those fakes can be arbitrarily deep nested
expressions. Now during refactoring, I decide bb-2 processing goes
elsewhere, maybe somewhere "upstream" in the logic. So I double-click
and then drag-and-drop, or cut and paste.

Then I double-click on the entire if statement, and then do a
control-click on the "then" condition, control-click happening to mean
"paste what I am clicking". Suddenly the "then" is the whole form.

(And, yes, this means my vendor took away from me the normal
copy-and-drop associated with control click <g>, but I could modify
things to get it back if I really cared.)

Of course the next question has to be, how often does that come up? When
refactoring it sometimes feels like I do nothing else. :) It turns out
that this is an insanely natural way to work with code.

Note also that after any amount of dicing I simply hit a magic key combo
and the editor reindents everything. In a sense, Lisp is the language
that handles indentation best.

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

unread,
Dec 8, 2006, 2:52:33 PM12/8/06
to

Aahz wrote:
> In article <1165598576.6...@16g2000cwy.googlegroups.com>,
> Mark Tarver <dr.mt...@ukonline.co.uk> wrote:
>
>>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, 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. So I think you are just making things up. :)

> Consider this: Lisp has had years of development, it has had millions of
> dollars thrown at it by VC firms -- and yet Python is winning over Lisp
> programmers. Think about it.

Haha, what's the score? And how much time is left in the first quarter?

:)

Alex Mizrahi

unread,
Dec 8, 2006, 3:02:59 PM12/8/06
to
(message (Hello 'Bjoern)
(you :wrote :on '(Fri, 08 Dec 2006 19:57:28 +0100))
(

??>> also, there's no need for operator precendence to be taken in
??>> accound -- order is explicitly defined. expressions are
??>> homogenous, they do not depend on other expressions near them
??>> (except lexical variables and side effects).

BS> Sorry, I don't get it ;) Where does Python have things like
BS> nonexplicit defined operator order?

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 -- * and + are not anyhow special
from other functions. all you need to remember is how to call functions.

certainly it's a very simple example, but it shows that generally, homogeous
lisp syntax make expressions much less dependant on context, and there are
much less rules affecting it. thus, work require by brain to understand and
write code can be reduced -- that way it's easier.

Common Lisp specification define internal languages that are not in
homogenous s-expr syntax -- that is formatter and loop macro.
like

(loop for i from 1 to 20 collect i)

or

(loop for e in list
maximizing e into max
minimizing e into min
finally (return (values min max)))

remarkable thing about that is that it's the only place which i cannot
remember and need to lookup quite frequently in the reference.
although it looks almost like plain english and looks quite easy, it's much
harder than other parts of lisp that use uniform syntax.

but certainly this uniform syntax doesn't worth much without macro
facilities.

i'll show an example from my recent experiments.
in this example we want to perform a query into a RDF database
(triplestore), SPARQL-style query, and then we format results as HTML.
here's how it looks in the SPARQL (i'm not fluent in it, so it can be
buggy). basically, we want to query information (firstname, lastname,
salary) or all users in specified departament.

PREFIX myapp: <https://mydomain.net/myapp/1.1/>
SELECT ?fname, ?lname, ?salary
WHERE
{
?user myapp:name ?uname.
?uname myapp:first-name ?fname.
?uname myapp:last-name ?lname.
?user myapp:salary ?salary.
?user myapp:department ?dept.
}

we should feed this text to the query-builder.
then we should bind ?dept to our variable departament (i'm not sure how this
is done in SPARQL, but there should be a way).
then we should iterate over results and output HTML. a python-like
pseudocode:

query = BuildQuery(query_str)
query.bind("?dept", departament)
results = query.execute()
for each rs in results:
print "<tr><td>" + htmlesc(rs.get("?fname")) + "</td><td>" +
htmlesc(rs.get("?lname")) + "</td><td>" + rs.get("?salary") + "</td></tr>"

so how uniform syntax and macros can help here? we can make a macro
rdf:do-query that will both programmatically create query, bind input
variables and then bind results into local variables. also we can wrap HTML
output in a macro too.
so here's a code:

(rdf:do-query
((?user :name ?uname)
(?uname :first-name ?fname)
(?uname :last-name ?lname)
(?user :salary ?salary)
(?user :department department))
(html (:tr
(:td (:princ ?fname))
(:td (:princ ?lname))
(:td (:princ ?salary)))))

as you can find, it's two times less code, it's less clumsy, and there's
even less quotes and parentheses there -- who says that lisp has more
parentheses? also, this code is less error-prone, because some part of
correctless can be checked during compilation time by macros, because it
operates with symbols on semantic level, but not with simple strings.
for example, if i make a type and write ?fnme instead of ?fname in the HTML
output, compiler will report a warning about unbound variable, but if this
variable will be in string-form, compiler will not be able to.
there are other benefits: RDF query language is transparently integrated
into Lisp, there's no need to learn some other language (SPARQL) syntax
additionally. and it strains my brain less when i don't have to switch
between different languages.

is it possible to construct such helper functions (or whatever) to simplify
code in Python?

Stephen Eilert

unread,
Dec 8, 2006, 3:23:54 PM12/8/06
to

Alex Mizrahi escreveu:


>
> we should feed this text to the query-builder.
> then we should bind ?dept to our variable departament (i'm not sure how this
> is done in SPARQL, but there should be a way).
> then we should iterate over results and output HTML. a python-like
> pseudocode:
>
> query = BuildQuery(query_str)
> query.bind("?dept", departament)
> results = query.execute()
> for each rs in results:
> print "<tr><td>" + htmlesc(rs.get("?fname")) + "</td><td>" +
> htmlesc(rs.get("?lname")) + "</td><td>" + rs.get("?salary") + "</td></tr>"

I just want to add that this kind of HTML mixed with code is something
that should be avoided, no matter what language is used.


Stephen

Kay Schluehr

unread,
Dec 8, 2006, 3:25:09 PM12/8/06
to
O.K. I agree with what you said about the generic function vs per
object dictionary dispatch.
But do the performance differences vanish when only builtin types and
functions are used to express Python algorithms?

Chris Mellon

unread,
Dec 8, 2006, 4:08:00 PM12/8/06
to pytho...@python.org

results = doQuery(department="Accounting")
for row in results:
for field in ["fname","lname","salary"]:
print "<td>%s</td>" % htmlesc(row[field])

I hide away the binding etc in doQuery as the lisp version does. Note
that in any kind of real code most of the literals that take up the
space are likely to come from elsewhere.

Note how much more trivial it is to change the HTML output of this
version that the lisp - it's a matter of creating a format string,
which you can retrieve from just about anywhere, rather than requiring
a code refactoring. Just because you have macros doesn't mean it makes
sense to use them.


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

Rob Warnock

unread,
Dec 8, 2006, 4:17:07 PM12/8/06
to
Pillsy <pill...@gmail.com> wrote:
+---------------

| hankhero wrote:
| > Pythons advantages are:
| > Faster startup-time which makes it a good scripting language.
|
| ... but on my machine, SBCL starts up and runs a "Hello World"

| program a bit faster than Python, and CLisp really blows its doors off.
+---------------

On my various machines, CMUCL startup is *slightly*
faster than CLISP, but both are under 20 ms...

I use Common Lisp for scripting a *lot*!


-Rob

-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

JShr...@gmail.com

unread,
Dec 8, 2006, 4:28:00 PM12/8/06
to
Okay, since everyone ignored the FAQ, I guess I can too...

Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?

(Common) Lisp is the only industrial strength language with both pure
compositionality and a real compiler. What Python has is stupid slogans
("It fits your brain." "Only one way to do things.") and an infinite
community of flies that, for some inexplicable reason, believe these
stupid slogns. These flies are, however, quite useful because they
produce infinite numbers of random libraries, some of which end up
being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python
is rapidly replacing Perl, and Ruby is simultaneously and even more
rapidly replacing Python. Each is closer to Lisp than the last; the
world is returning to Lisp and is dragging the flies with it.
Eventually the flies will descend upon Lisp itself and will bring with
them their infinite number of random libraries, and then things will be
where they should have been 20 years ago, but got sidetracked by Tcl
and other line noise.

Fred Gilham

unread,
Dec 8, 2006, 4:57:01 PM12/8/06
to

A suggestion is to mention Dylan as a possibility to people who think
Lisp syntax is too funky but want to see something Lisp-like.

--
Fred Gilham gil...@csl.sri.com
Progressive (adj): Value-free; tolerant; non-judgemental.
E.g. traditional archery instruction methods spent tedious hours
teaching the archer to hit a bulls-eye. Progressive methods achieved
better results by telling the student archer to shoot in the manner he
or she found most comfortable, then calling whatever the arrow hit the
bulls-eye.

Paddy

unread,
Dec 8, 2006, 5:05:03 PM12/8/06
to

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

I've never programmed in Lisp but I have programmed in Cadence Skill a
Lisp inspired language with infix notation as an option. I found Skill
to be a very powerful language. At the time I new only AWK, C, Pascal,
Forth, Postcript, Assembler and Basic. Skill was superior and I came
to love it.
But that was a decade ago. Now, I'd rather a company integrate Python
into their product as I find Python to be less 'arcane' than Skill;
with more accessible power, and a great community.
.
Analogy time!
You need Pure Maths, but more mathematicians will be working applying
maths to real-world problems. You need research physicists, but more
physicists will be applying physics in the real world. It seems to me
that Lisp and its basis in maths makes people research and develop a
lot of new techniques in Lisp, but when it comes to applying those
techniques in the real world - switch to Python!

Lisp has a role to play, but maybe a language tuned to research and
with its user base would naturally find it hard to compete in the roles
in which dynamic languages such as Python are strongest.

- Paddy.

Klaas

unread,
Dec 8, 2006, 5:14:45 PM12/8/06
to

Aahz wrote:

> As for your claims about speed, they are also nonsense; I doubt one
> would find an order of magnitude increase of speed for production
> programs created by a competent Lisp programmer compared to programs
> created by a competent Python programmer.

Lisp can be compiled into an executable that has c-like speeds. It can
be much faster than python.

-MIke

tayssi...@googlemail.com

unread,
Dec 8, 2006, 5:18:31 PM12/8/06
to
Aahz wrote:
> 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.

I think this holds true for experienced programmers, who often report a
difficult unlearning process with Lisp. However, for people without
preconceptions, the difference is likely less -- after all, many have
painful memories of poorly-taught math and computer classes in school.
So Python's similarity to gradeschool math may not be such a plus.

Richard Stallman explained about a Lisp variant:

"Multics Emacs proved to be a great success -- programming new editing
commands was so convenient that even the secretaries in his office
started learning how to use it. They used a manual someone had written
which showed how to extend Emacs, but didn't say it was a programming.
So the secretaries, who believed they couldn't do programming, weren't
scared off. They read the manual, discovered they could do useful
things and they learned to program."
<http://www.gnu.org/gnu/rms-lisp.html>

But of course this is anecdotal evidence.


> Consider this: Lisp has had years of development, it has had millions of
> dollars thrown at it by VC firms -- and yet Python is winning over Lisp
> programmers. Think about it.

Even now, Lisp still contains radical concepts (as in latin's radix
meaning "root"), and overly radical ideas tend not to dominate in the
marketplace. So we see an incremental progression towards Lisp ideas.

Guy Steele, a central figure in Java, claimed:

"And you're right: we were not out to win over the Lisp programmers; we
were after the C++ programmers. We managed to drag a lot of them about
halfway to Lisp. Aren't you happy?"
<http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04045.html>

But speaking of the marketplace, there's at least one Lisp company
sustaining itself by asking for a cut of its customers' revenues... The
last Lisp implementation I used "merely" asked for thousands per head
per platform. ;)


(Personally, I used Python before being aware of Lisp. Now I use Common
Lisp all the time, though I will recommend Python when I consider it
more appropriate. A few months ago, I missed the Condition System most
when using Python, and also lexical scope. However, it is nice to work
with friends, who know Python and not Lisp.)


Tayssir

Paddy

unread,
Dec 8, 2006, 5:22:15 PM12/8/06
to

JShr...@gmail.com wrote:

What is it about Lisp that despite doing everything first, way before
any other language, people don't stop using anything else and
automatically turn to Lisp? Maybe there is more to this everything than
the Lisp community comprehends.
Maybe Lisp is to science, as Python is to engineering - with a slight
blurring round the edges?

- Paddy.

smal...@juno.com

unread,
Dec 8, 2006, 5:24:36 PM12/8/06
to

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

cmp `which clisp` `which python`
/usr/bin/clisp /usr/bin/python differ: byte 25, line 1

HTH

--S

George Sakkis

unread,
Dec 8, 2006, 5:44:45 PM12/8/06
to

I know we shouldn't feed the trolls, but this one was particularly
amusing to resist the urge. The joke about lisp's world domination in
some unspecified point in the future never fails to bring a good
chuckle. I heard it's scheduled right after strong AI and before time
travel, is this still the plan? A quick look at
http://www.tiobe.com/tpci.htm may be helpful as a reality check before
you go back to your ivory tower (interesting how close in ratings and
growth is the "Lisp/Scheme" entry with another dinosaur, Cobol).

Ken Tilton

unread,
Dec 8, 2006, 6:04:02 PM12/8/06
to

And it interesting that VB is almost three times "better" than Python,
and that a Honda could kick a Lamboghini's ass for it at Laguna Seca:

http://www.googlefight.com/index.php?lang=en_GB&word1=lamborghini&word2=ford

Come on, COBOL is a great language, even has macros (copy ... replacing)
and the worlds greatest case statement, evaluate. We are proud to be its
neightbor.

Duane Rettig

unread,
Dec 8, 2006, 6:12:14 PM12/8/06
to
"Paddy" <padd...@netscape.net> writes:

> 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.
>>
>> Mark
> I've never programmed in Lisp but I have programmed in Cadence Skill a
> Lisp inspired language with infix notation as an option. I found Skill
> to be a very powerful language. At the time I new only AWK, C, Pascal,
> Forth, Postcript, Assembler and Basic. Skill was superior and I came
> to love it.

Remember; Lisp is a program-language programming language. Sometimes,
one programs in Lisp without really knowing it:

http://www.franz.com/careers/jobs/outside/cadence03.21.06.lhtml

--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182

George Sakkis

unread,
Dec 8, 2006, 6:30:27 PM12/8/06
to

Didn't say better, not even in quotes (and btw, if you're only doing
GUI apps in MS, VB is the path of least resistance in many cases, as is
PHP for quick'n'dirty web apps). What was funny in the GP's post was
the pomposity about "flies eventually descending upon Lisp itself", as
if language popularity (or any popularity for that matter) is
determined solely by theoretical computer science metrics.

George

JShr...@gmail.com

unread,
Dec 8, 2006, 6:39:28 PM12/8/06
to
> I heard it's scheduled right after strong AI and before time
> travel...

I think that time travel predated strong AI, although I'm not sure
since it's a little hard to pin down the time coordinates of time
travel (probably The Time Machine will do

> A quick look at
> http://www.tiobe.com/tpci.htm may be helpful as a reality check before
> you go back to your ivory tower (interesting how close in ratings and
> growth is the "Lisp/Scheme" entry with another dinosaur, Cobol).

Oh, Right, George... Reality, of course... I completely neglected
random surveys! I suppose that we should all be using VB because this
survey tells us it's the next best things to C++! See that Ruby green
arrow rocketing up behind you, George; better watch your ass, clown. :-)

Paul Rubin

unread,
Dec 8, 2006, 6:43:48 PM12/8/06
to
"Mark Tarver" <dr.mt...@ukonline.co.uk> writes:
> Thanks; a quick read of your reference to Norvig's analysis
>
> http://norvig.com/python-lisp.html
>
> seems to show that Python is a cut down (no macros) version of Lisp
> with a worse performance. The only substantial advantage I can see is
> that GUI, and Web libraries are standard. This confirms my suspicion
> that Lisp is losing out to newbies because of its
> lack of standard support for the things many people want to do.

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.

Paul Boddie

unread,
Dec 8, 2006, 7:09:07 PM12/8/06
to
Mark Tarver wrote:
>
> Thanks; a quick read of your reference to Norvig's analysis
>
> http://norvig.com/python-lisp.html
>
> seems to show that Python is a cut down (no macros) version of Lisp
> with a worse performance.

I'm quite interested in Lisp, at least from the perspective of seeing
how it supports particular kinds of development activities where you'd
have to "do extra laps" with languages like Python, but while it's
possible to frame lots of languages as being Lisp with something
removed, such observations neglect the origins and objectives of those
languages (and the contributions of a number of other languages).

> The only substantial advantage I can see is that GUI, and Web libraries are standard.

This is actually something of a running joke in the Python community.
There's one sort of de-facto GUI library which many people swap out for
one of the many other GUI libraries available, many of which are
actually very good and relate to modern, actively and heavily developed
graphical user interface environments. Meanwhile, Web standardisation
in the Python scene needs more attention, although there's so much
activity and so many end-to-end solutions to choose from that Python is
quite a reasonable choice for Web development.

> This confirms my suspicion that Lisp is losing out to newbies because of its
> lack of standard support for the things many people want to do.

There was a thread on comp.lang.lisp recently [1] where Ian Jackson of
Debian fame attempted to raise awareness of a lack of apparent
community standards for Lisp, amongst other things, at least for those
people developing software for various Free Software platforms. I think
a re-reading of the many and varied responses will give you some ideas
about where the Lisp community stands in that and in other respects.

Paul

[1]
http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/ea994085b54de92d

JShr...@gmail.com

unread,
Dec 8, 2006, 7:14:44 PM12/8/06
to

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. I guess waiting for Guido to figure
out what Fits Your Mind is part of The Python Way.

Oleg Batrashev

unread,
Dec 8, 2006, 7:23:50 PM12/8/06
to

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.
>
> Mark
Im myself python programmer with C,C++,Java,Fortran background and also
quite limited knowledge of Haskel, Lisp,Tcl,... .

Im confused with most python answers like triple doublequotes.
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). Exceptions, finally/except
blocks, automatic reference counts and destructors make it easy to
write "robust" code. Packaging system and libraries are just fine.

So, python is just C++ combined with elegancy of Java and simplicity of
scripting.

Again, Im not Lisp programmer, so would like to here about mentioned
features, do those things work as nicely, especially OOP ones?
And IMHO paren misfeature is bad, although you claim it to has some
advantages. Mostly, when I copy code in python I just need to call
increase-left-margin emacs macro and there are no mentioned a+b*c
problem. So, I imagine my typical 1-2 page, max 4-5 nested python
function with great readabilty and almost no refactoring problems and I
need to add 20*2 parens to make it homogenous. :)

Oleg

bearoph...@lycos.com

unread,
Dec 8, 2006, 7:49:54 PM12/8/06
to
JShr...@gmail.com:

> 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. I guess waiting for Guido to figure
> out what Fits Your Mind is part of The Python Way.

There are few programmers that are very intelligent and know how very
well how to design languages, so they can invent such things. They are
able to manage and appreciate the more freedom Lisp gives them. But
*most* other programmers aren't intelligent enough for that, or they
don't know enough language design to produce something working or
something nice. So maybe Lisp is for the more intelligent people, or
for really difficult programs (or for dynamic and flexible programs
that have to run quite faster than Python+Psyco code), where having a
bit simpler language isn't an advantage. All the other people use
Python that contains things already well designed for them, such
language constructs are the same for everybody, they are standards of
the language, like generators, so reading each other code is simpler
and faster too.

Bye,
bearophile

Paul Rubin

unread,
Dec 8, 2006, 8:15:32 PM12/8/06