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

[Mathias Panzenboeck]

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, 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-...ed_programming
http://en.wikipedia.org/wiki/Dynamic...mming_language
http://en.wikipedia.org/wiki/Lisp_programming_language
http://en.wikipedia.org/wiki/Python_...ng_language%29

[Paul Rubin]

"Mark Tarver" <dr********@ukonline.co.ukwrites:

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]

Paul Rubin wrote:

"Mark Tarver" <dr********@ukonline.co.ukwrites:

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>

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]

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]

"Mark Tarver" <dr********@ukonline.co.ukwrote in message
news:11**********************@79g2000cws.googlegro ups.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]

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]

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]

"Mark Tarver" <dr********@ukonline.co.ukwrites:

Paul Rubin wrote:

"Mark Tarver" <dr********@ukonline.co.ukwrites:

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>

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

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]

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

RBPerformance claims are always controversial. So, Python is much slower
RBdoing array multiplication, when you hand roll it, instead of using the
RBstandard 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]

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

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

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

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

[Ken Tilton]

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...d2=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]

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]

"Alex Mizrahi" <ud******@users.sourceforge.netwrote in message
news:45***********************@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]

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]

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-...dling-of-Types

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

[Carl Banks]

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]

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]

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]

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]

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]

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.

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

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]

Bjoern Schliessmann <us**************************@spamgourmet.comwrite s:

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]

Bjoern Schliessmann <us**************************@spamgourmet.comwrite s:

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]

"Mark Tarver" <dr********@ukonline.co.ukwrites:

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

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]

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/pyt...il/000286.html.
George

[Alex Mizrahi]

(message (Hello 'Kay)
(you :wrote :on '(8 Dec 2006 08:03:18 -0800))
(

KShttp://www.sbcl.org/manual/Handling-...dling-of-Types

KSIf you'd read the docs of the tools you admire you might find the
KSanswers 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.

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

[JShrager]

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]

(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

BSCan you give an example? I cannot imagine how homogenity always
BSresults 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
BSCan 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)

BSI think you acknowledged that the syntax is different and not
BSborrowed?

certainly

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

[Fredrik Lundh]

JS******@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]

Bill Atkins wrote:

"Mark Tarver" <dr********@ukonline.co.ukwrites:

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

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

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]

Alex Mizrahi wrote:

(message (Hello 'Kay)
(you :wrote :on '(8 Dec 2006 08:03:18 -0800))
(

KShttp://www.sbcl.org/manual/Handling-...dling-of-Types

KSIf you'd read the docs of the tools you admire you might find the
KSanswers 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]

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]

Alex Mizrahi wrote:

RBPerformance claims are always controversial. So, Python is much slower
RBdoing array multiplication, when you hand roll it, instead of using the
RBstandard 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]

Kaz Kylheku wrote:

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.

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]

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]

Petter Gustad wrote:

Bjoern Schliessmann <us**************************@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]

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]

Alex Mizrahi wrote:

(message (Hello 'Bjoern)

> BSCan you give an example? I cannot imagine how homogenity
always BSresults 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]

["Followup-To:" header set to comp.lang.python.]
On 2006-12-08, Mark Tarver <dr********@ukonline.co.ukwrote:

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]

In article <11**********************@16g2000cwy.googlegroups. com>,
Mark Tarver <dr********@ukonline.co.ukwrote:

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

Bjoern Schliessmann wrote:

Alex Mizrahi wrote:

>>(message (Hello 'Bjoern)

>>BSCan you give an example? I cannot imagine how homogenity
always BSresults 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]

Aahz wrote:

In article <11**********************@16g2000cwy.googlegroups. com>,
Mark Tarver <dr********@ukonline.co.ukwrote:

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

:)

ken

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

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

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

[Alex Mizrahi]

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

BSSorry, I don't get it ;) Where does Python have things like
BSnonexplicit 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?

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

[Stephen Eilert]

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]

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]

On 8 Dec 2006 12:23:54 -0800, Stephen Eilert <sp******@gmail.comwrote:

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

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]

Pillsy <pi*******@gmail.comwrote:
+---------------
| 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 [phone]

[JShrager]

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.