merits of Lisp vs Python

[Fredrik Lundh]

Re: *** C.L.L README/FAQ *** (Was: merits of Lisp vs Python)

JShrager@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.pytho n ?

</F>

[Mark Tarver]

Re: merits of Lisp vs Python

Bill Atkins wrote:

"Mark Tarver" <dr.mtarver@uko nline.co.ukwrit es:
>

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]

Re: merits of Lisp vs Python

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]

Re: merits of Lisp vs Python

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]

Re: merits of Lisp vs Python

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_str ing,"");
while(strlen(so me_string) < 100000)
strcat(some_str ing,"*");

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]

Re: merits of Lisp vs Python

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]

Re: merits of Lisp vs Python

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]

Re: merits of Lisp vs Python

Petter Gustad wrote:

Bjoern Schliessmann <usenet-mail-0306.20.chr0n0s s@spamgourmet.c om>

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

Re: merits of Lisp vs Python

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]

Re: merits of Lisp vs Python

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]

Re: merits of Lisp vs Python

["Followup-To:" header set to comp.lang.pytho n.]
On 2006-12-08, Mark Tarver <dr.mtarver@uko nline.co.ukwrot e:

I'm looking at Python and I see that the syntax would appeal to
a newbie. Its clearer than ML which is a mess syntactically.

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]

Re: merits of Lisp vs Python

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

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

Speaking as someone who had been programming for more than twenty years
before learning Python (including a brief gander at Lisp), and also
referring to many years of observations of newcomers to Python: Python's
syntax also appeals to experienced programmers.

I would say that your statement about Lisp syntax is wrong. Not that it
is technically inaccurate, but that it completely misses the point, so
much so that it is wrong to say it. One of the key goals of Python is
readability, and while it is indeed easy to learn the rules for Lisp
syntax, observational experience indicates that many people (perhaps even
the vast majority of people) find it difficult to learn to read Lisp
programs.

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 (aahz@pythoncra ft.com) <* http://www.pythoncraft.com/

Member of the Groucho Marx Fan Club

[Ken Tilton]

Re: merits of Lisp vs Python



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]

Re: merits of Lisp vs Python



Aahz wrote:

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

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

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

No programming language is easy to read, 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]

Re: merits of Lisp vs Python

(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:departmen t ?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(quer y_str)
query.bind("?de pt", 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 programmaticall y 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")