merits of Lisp vs Python

[jayessay]

Re: merits of Lisp vs Python

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

jayessay <nospam@foo.com writes:

If you say foo.frob() in Python, that's supposed to look up 'frob' in
a dictionary hanging off of foo. You can modify the contents of this
dictionary any time you want.

Unless I'm missing something this looks absolutely dead easy to
implement in Lisp and with a very little macrology you would have the
syntax as well. I'm not sure how this makes one or the other "more
dynamic".

>
I'm talking about the way Lisp is actually used, not what contortions
one can do with macros.

But this _is_ the way it's actually used. I think this is a key point
that many people here don't understand. _If_ the construct you
mention, really had any underlying use/goodness, for someone who
wanted it, they would simply add it with the nice syntax and all.
Also note that most of this would not involve macros - that would only
be a final step to add the "nice" syntax.

This isn't any sort of "contortion ", it's simply how things are
actually done. And indeed, in this case, the macrology would be
pretty straight forward and simple as opposed to "contorted" (which
I'm sure there are cases of).

The way one does OOP in Lisp is with CLOS.

I'm not sure your construct has anything necessarily to do with "OOP"
(which is a pretty nebulus concept). But even if it did, what you can
really say is that CLOS is the preferred/standard way to do it in CL.
If you have other requirements that don't quite fit, you don't try
pounding them into the round hole. There have been a few people here
in the last few months who have wanted to do just that. Of course you
can get quite a distance in this respect via the MOP and may not need
or want to do more.


/Jon

--
'j' - a n t h o n y at romeo/charley/november com

[Robert Uhl]

Re: merits of Lisp vs Python

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

>
Speaking as somebody who programmed in FORTH for a while, that doesn't
impress me much. Prefix/postfix notation is, generally speaking, more
of a pain in the rear end than it is worth, even if it saves you a
tiny bit of thought when pasting code.

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

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

In the example, 'for,' 'range,' 'len' and 'dosomething' all use
prefix notation. In Lisp the example might look like this, assuming the
proper functions and macros to make it work:

(for ((x (range 0 (length y))))
(dosomething x))

Slightly more idiomatic would be:

(loop for x in (range 0 (length y))
do (dosomething x))

Even more idiomatic would be:

(loop for x below (length y)
do (dosomething x))

Which doesn't seem particularly more or less prefixy or infixy than the
Python version.

Infix is really only used in arithmetic--and there are Lisp macros which
give one infix notation if wanted, so one could write:

(infix 1 + x / 4)

--
Robert Uhl <http://public.xdi.org/=ruhl>
Give a man a fish and you feed him for a day; give him a freshly-charged
Electric Eel and chances are he won't bother you for anything ever again.
--Tanuki the Raccoon-dog

[jayessay]

Re: merits of Lisp vs Python

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

even more dynamic than Lisp. I mean "dynamic" in a less good way--
there is a huge amount of state scattered all through a running Python
program, that the application can modify at random and whose contents
the working of really fundamental operations like method invocation.
It's just a big mess and I'd get rid of it if I could. It reminds me
of like old time Lisp programs that pervasively used property lists on
symbols to attach random attributes to the symbol, instead of using
something like defstruct to make multi-field data values.

Indeed. Or even worse - default dynamic binding for everything.


/Jon

--
'j' - a n t h o n y at romeo/charley/november com

[Pascal Costanza]

Re: merits of Lisp vs Python

Pillsy wrote:

Ken Tilton wrote:
[...]

>That was my stance for about seven years of intense Lisp. Then the
>author of Practical Common Lisp did a nice job of breaking the whole
>mess up into sensible chunks and I picked it up. If one programs Lisp,
>one should learn Loop -- it is definitely worth the bother. I def regret
>not learning it sooner.

>
When I first read PCL (which was my introduction to Lisp) I thought
LOOP was really neato. Once I actually started using it for things that
weren't so simple, I began to really hate it. I think that having a
specialized mini-language for iteration is a superb idea, but I don't
think LOOP is it.
>
That being said, there's a portable alternatives out there that I like
way better, and I still use LOOP for dashing stuff off one-liners at
the REPL.

If you hate LOOP then you don't have to use it.

There's an important lesson to learn here: Not all language constructs
are supposed to be loved by everyone. ;)


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

[jayessay]

Re: merits of Lisp vs Python

Andrew Reilly <andrew-newspost@areill y.bpc-users.orgwrites :

On Tue, 12 Dec 2006 16:35:48 +1300, greg wrote:
>

When a Lisp compiler sees

(setq c (+ a b))

it can reasonably infer that the + is the built-in numeric
addition operator. But a Python compiler seeing

c = a + b

can't tell *anything* about what the + means without
knowing the types of a and b. They might be numbers, or
strings, or lists, or some user-defined class with its
own definition of addition.

>
That may be true, but lisp's numeric addition operator knows how to add
fixnums, bignums, rationals and whatever the lisp name for floating points
is (imprecise?)

float. Of which there are several flavors.

http://www.lispworks.com/documentation/HyperSpec/Body/t_float.htm

sets can manage. So that's still type-dependent dispatch, which
isn't going to get us to the speeds that we actually see reported
unless there's extra stuff going on. Type inference? Declarations?

Yes - both are typically involved.


/Jon

--
'j' - a n t h o n y at romeo/charley/november com

[Robert Uhl]

Re: merits of Lisp vs Python

"HowiPepper " <hpepper@gmail. comwrites:

I have checked out Lisp several times in the past, but I always get
turned off completely by the parenthesis you have to use for
everything. What's up with that anyway?

It's no different from having to use newlines and spaces and square
brackets and parentheses in Python. E.g. the Lisp (f x y) is exactly
equivalent to the Python f(x, y); the Lisp (if x y z) is exactly
equivalent to the Python:

if x:
y
else:
z

There is, though, an advantage: (f x y) and (if x y z) aren't just parts
of programs--they're also lists. That means that one can use all the
list-manipulation primitives on a program, and thus that it's very easy
to write programs which manipulate programs. This in turn leads to
being able to extend the syntax of the language. Imagine if one could
write this in Python:

defsyntax unless(conditio n, commands):
if not condition:
commands

And use it like this:

unless day == 'Sunday':
work()

That'd be pretty cool, right? After all, 'unless day is Sunday' conveys
the sense of what you're doing a little better than 'if days is not
Sunday.' But in Python it's not possible--even my defsyntax example is
absurd: how would the compiler know the difference between pre-colon
argument and the command block? What if I wanted multiple blocks
(e.g. as with an else:)?

Whereas with Lisp one might simply write:

(defmacro unless (condition &body commands)
`(if (not ,condition)
,@commands))

When used as:

(unless (equal day "Sunday")
(work))

The compiler transforms it into:

(if (not (equal day "Sunday"))
(work))

This is a _really_ simple example (unless is nice, but it's hardly
vital); but what one can do is end up making a much more declarative
program by creating new syntax to describe stuff.

With Python's ease of learning and use, availability of a large number
of libraries, extremely active development community and large
user-base, I'd say the question to ask is what specific advantages
over Python does Lisp offer, to make people switch to it?

Well, these come to mind; they're in no order and are just my own
particular thoughts. No doubt more reflective commentators can come up
with a better list.

o Macros

As mentioned above, macros can make one's life significantly nicer. I
use Python a lot (it's currently a better choice than Lisp for many of
the problems I face), and I find myself missing macros all the time.
The ability to take some frequently-used idiom and wrap it up in a macro
is wonderful. E.g. a common idiom in Python is:

file = open(path, 'r')
for line in file.readlines( ):
foo(line)
bar(line)
baz(line)

Even this isn't much nicer:

for line in open(path, 'r').readlines( ):
foo(line)
bar(line)
baz(line)

Wouldn't it be nice to have a macro with-open-file?

filefor line in path:
foo(line)
bar(line)
baz(line)

o Speed

Lisp interpreters are several orders of magnitude faster than Python,
and Lisp compilers are faster yet. Speed's not the most important
thing, but it is _an_ important thing; all other things being equal, the
faster solution is better.

o Symbols

In Lisp, a symbol is essentially a hashed string; two symbols are alike
if their names are alike, but comparison of symbols is a constant-time
operation. Thus where in Python I have lots of string comparisons for
constants, and in C I have #defined integers, in Lisp I have symbols.
It's not just a performance hack--symbols are part of why macros and
packages work--but when I miss them, I miss them for the performance
side of things

o CLOS

The Common Lisp Object System is a really remarkable piece of work.
Among other things, it has generic functions instead of methods.
E.g. in Python or most other OO languages object.method(a rg1, arg2) is
really just a fancy piece of syntactic sugar for method(object, arg1,
arg2); method does different things depending on the type of object, its
first argument.

Wouldn't it be nice to be able to specialise a method on _any_ subset of
its arguments, not just its first one? Well, CLOS offers that. (method
object1 object2) could be specialised on the first argument, the second
or both. This can be very powerful.

Wouldn't it be nice to specify that some action be taken before or after
a superclass's method, rather than over-riding that method entirely?
Sure, one can over-ride the method and then call it within one's own
code, but that obscures the meaning of what one's doing.

o CLSQL

An OR mapper which actually works. 'Nuff said.


OTOH, here's what Python offers which Lisp doesn't:

o A capable standard library

Lisp's standard library was considered large once upon a time--why, it
included lists and hashes! But that's not a big deal nowadays. Right
now there are a plethora of choices, but it's not clear which choices
are blessed or particularly good. Sure, once could use a different MIME
library than Python offers as standard, but it's good to know that there
_is_ a standard.

o A large, friendly community

Lisp's community is small and exceedingly bright; it doesn't suffer
fools gladly. Python's is larger and friendlier, realising that we were
all fools once and that with education many of us get better.

o Top-notch Web frameworks

Pylons and Django are nice to use and take care of a lot of the
boilerplate one would otherwise have to write. While Webactions is a
very cool framework, it lives at a lower level and there's a lot more
one has to add to it for a complete app.

--
Robert Uhl <http://public.xdi.org/=ruhl>
People who are willing to rely on the government to keep them safe are
pretty much standing on Darwin's mat, pounding on the door, screaming,
`Take me, take me!' --Carl Jacobs

[Pillsy]

Re: merits of Lisp vs Python


Pascal Costanza wrote:

Pillsy wrote:

[...]

When I first read PCL (which was my introduction to Lisp) I thought
LOOP was really neato. Once I actually started using it for things that
weren't so simple, I began to really hate it. I think that having a
specialized mini-language for iteration is a superb idea, but I don't
think LOOP is it.

That being said, there's a portable alternatives out there that I like
way better, and I still use LOOP for dashing stuff off one-liners at
the REPL.

If you hate LOOP then you don't have to use it.

Indeed, I *don't* use it except for the simplest things.

There's an important lesson to learn here: Not all language constructs
are supposed to be loved by everyone. ;)

Especially in Common Lisp, where it's possible to have replacements
that integrate with the rest of the language as seamlessly as the
original feature they're replacing.

I don't love CL because its devoid of features I hate. I love it
because it provides so many great ways of getting around the features I
hate. If it didn't have features I hate, I might actually like it less,
because I wouldn't have anything to bitch about on USENET. :)

Cheers,
Pillsy

[Paul Rubin]

Re: merits of Lisp vs Python

jayessay <nospam@foo.com writes:

It's simply that newer language designs by definition have more of an
experience base to build on than older ones, if the designers care to
make use of it.

>
Agreed. Indeed, that was the underlying guiding principle in putting
together CL. *ML being older than CL didn't have any more opportunity
in this respect.

You're forgetting that CL tried to be more or less backwards
compatible with its predecessors, at least compatible enough that
large systems in Maclisp, Interlisp, Zetalisp, etc. could be ported
without too much pain. Therefore, CL could not erase too many
mistakes from the past. Scheme went somewhat further than CL at
cleaning things up, and Scheme's aficionados think CL is a clumsy old
kludge as a result. But it's still a Lisp dialect. The ML's, for
their part, were able to start from scratch.

[Robert Uhl]

Re: merits of Lisp vs Python

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

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

>
Huh? Are you saying Lisp systems never release new versions?

The Common Lisp standard hasn't been updated in over a decade.
Moreover, one doesn't need to wait for a standard to add syntax--one
just adds it and gets on with solving the problem at hand.

And you can't implement Python generators as Lisp macros in any
reasonable way.

I'm pretty certain it could be done with conditions.

--
Robert Uhl <http://public.xdi.org/=ruhl>
We're going to Moe's. If we're not back, avenge our deaths.
--Homer Simpson

[Robert Uhl]

Re: merits of Lisp vs Python

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

>
It is a good thing that when Fred decides to stop contributing to an
open source project (or leave the company), other people can read his code
without having to learn his Uber-Special Custom Macro Extended
Language.

And yet they have to learn his Uber-Special Custom Function Extended
Language. If adding syntax is bad, surely adding functions is bad too.
And yet, I don't see very many people arguing for a return to
unstructured code.

In fact, the ability to add syntax is as important as the ability to add
functions; it's a second order of structure.

--
Robert Uhl <http://public.xdi.org/=ruhl>
Face it--Bill Gates is a white Persian cat and a monocle away from
being a Bond villain. --Dennis Miller

[Robert Uhl]

Re: merits of Lisp vs Python

"Ravi Teja" <webraviteja@gm ail.comwrites:

Mark Tarver wrote:

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

>
By that standard, every other mainstream dynamically typed language
for you is a cut-down version of Lisp with worse performance.

Pretty much;-)

Fewer features, worse performance. Why use 'em? In my case, because
the standard library is larger, and because I can get my teammates to
use 'em.

--
Robert Uhl <http://public.xdi.org/=ruhl>
When you disarm your subjects you offend them by showing that either
from cowardliness or lack of faith, you distrust them; and either
conclusion will induce them to hate you.
--Niccolo Machiavelli, The Prince

[Robert Uhl]

Re: merits of Lisp vs Python

aahz@pythoncraf t.com (Aahz) writes:

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

The argument from popularity is invalid. French units have overtaken
standard units, yet they are technically worse. Windows has overtaken
Unix, yet it is technically worse.

The market does not select the technically best (although it may select
what is best when all factors are taken into account; e.g. Windows may
be better when dealing with an ignorant workforce, and French units may
be better when dealing with users thereof).

--
Robert Uhl <http://public.xdi.org/=ruhl>
Traditionally, there are only three classes of people who use 'we' in
describing themselves: Royalty (which you aren't), editors (no evidence
that this applies) and people with tapeworms. Please let us know when
you've been cured. --Hal Heydt, to Dennis O'Connor

[George Sakkis]

Re: merits of Lisp vs Python

Robert Uhl wrote:

o Macros
>
As mentioned above, macros can make one's life significantly nicer. I
use Python a lot (it's currently a better choice than Lisp for many of
the problems I face), and I find myself missing macros all the time.
The ability to take some frequently-used idiom and wrap it up in a macro
is wonderful. E.g. a common idiom in Python is:
>
file = open(path, 'r')
for line in file.readlines( ):
foo(line)
bar(line)
baz(line)
>
Even this isn't much nicer:
>
for line in open(path, 'r').readlines( ):
foo(line)
bar(line)
baz(line)
>
Wouldn't it be nice to have a macro with-open-file?
>
filefor line in path:
foo(line)
bar(line)
baz(line)
>

You probably need to refresh your Python skills if you want to be more
productive in it. Files have been iterable for the last couple of years
(since 2.1-2.2, don't remember).

for line in open(path):
foo(line)
bar(line)
baz(line)

You can also iterate through the lines of more than one files using the
fileinput module (http://docs.python.org/lib/module-fileinput.html):

import fileinput

# iterate over the lines of the files passed as command line
# arguments (sys.argv[1:]) or sys.stdin for no arguments
for line in fileinput.input ():
foo(line)


I'm sure there should be more convincing examples for macros, but
neither this nor the 'unless' syntax sugar cuts it.

George

[Robert Uhl]

Re: merits of Lisp vs Python

Neil Cerutti <horpner@yahoo. comwrites:

>

> http://www.gigamonkeys.com/book

>
I got stuck (last year) in that book:
>

http://www.gigamonkeys.com/book/practical-a-portable-pathname-library.html

>
The author didn't do Common Lisp (or me) any favors by drawing my
attention to the pathname library.

Yeah, I think his intent was for it to be a nice little practicum to
demonstrate how to use the language--unfortunately it dealt with one of
the uglier bits of CL. The fact that pathnames are really cool doesn't
fix the problem that they are at once overspecified and underspecified.

If the standard were revised, that'd be a good candidate right there.
This is where having a benevolent dictator for life comes in handy.

I suppose I missed whatever the point was supposed to be in the midst
of the mind-boggling. I meant to get back to it but haven't yet.

I pretty much skipped that chapter. The bit where it gets mind-boggling
is where he creates ID3-tag reading classes from binary-reading
primitives and ends up with a complete ID3 library in very few lines of
code.

--
Robert Uhl <http://public.xdi.org/=ruhl>
I won't insult your intelligence by suggesting that you really believe
what you just said. --William F. Buckley, Jr.

[jayessay]

Re: merits of Lisp vs Python

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

jayessay <nospam@foo.com writes:

It's simply that newer language designs by definition have more of an
experience base to build on than older ones, if the designers care to
make use of it.

Agreed. Indeed, that was the underlying guiding principle in putting
together CL. *ML being older than CL didn't have any more opportunity
in this respect.

>
You're forgetting that CL tried to be more or less backwards
compatible with its predecessors

You're mistaken, I'm not forgetting this. And despite this being
true, CL added several "new" things that (again through actual
experience) were deemed sufficiently understood to add (CLOS,
conditions, and such).

mistakes from the past. Scheme went somewhat further than CL at
cleaning things up,

But, Scheme was before CL (and indeed CL took some things from
Scheme). Of course Scheme too has continued to evolve.

and Scheme's aficionados think CL is a clumsy old kludge as a
result

Well, if you lower into "flamewar" talk, CL aficionados have similar
things to say about Scheme. But that is just irrelevant silly
flamage.

But it's still a Lisp dialect. The ML's, for their part,
were able to start from scratch.

There are Lisps like this as well (EuLisp sort of and now Arc). But
really, how is "starting from scratch" really an advantage?
Especially from a _practical_ point of view. Admittedly, I used to
think the same, but now think that is just wrong. Again, the example
of The Calculus and such come to mind...


/Jon

--
'j' - a n t h o n y at romeo/charley/november com