merits of Lisp vs Python

[Bill Atkins]

Re: merits of Lisp vs Python

André Thieme <address.good.u ntil.2006.dec.2 2@justmail.dewr ites:

But anyway, in Lisp you can save some code. Not much in this situation.
Instead of function = memoize(functio n)
one could just say: memoize(functio n).

Um...

[Paul Boddie]

Re: merits of Lisp vs Python

tayssir.john@go oglemail.com wrote:

>
Keeping with the analogy, Lisp offers power to adapt your notation to
the domain you're describing. One thing people expect from a language
is a certain malleability in order for it to somehow resemble the
domain they're describing.

I think the more interesting issue of relevance to both communities
(and I wonder whether the original inquirer is still reading) is
whether a language like Python is an acceptable specialised notation
for so many domains as to make a more malleable language like Lisp less
interesting for most specialists. In other words, that there are so
many areas where Python's arguably mundane semantics are sufficient
that the specialists have their convenient, common means of
communication which happens to span large areas of computational
endeavour. And on the occasions where Python doesn't provide adequate,
convenient metaprogramming features, might it not be the case that less
elegant program transformation mechanisms or even other approaches to
architectural design aren't good enough solutions? After all, the
various object-oriented design movements, for example, even though they
may be regarded as having produced clumsy and verbose mechanisms for
expressing certain kinds of systems, have in some way or other provided
a recognisable vocabulary that many people understand.

Paul

[Alex Mizrahi]

Re: merits of Lisp vs Python

(message (Hello 'Paul)
(you :wrote :on '(10 Dec 2006 10:07:12 -0800))
(

PRThere would be terrible performance penalties dealing with the
PRenvironment lookup on every lexical variable reference.

LOL! you're saying it in Python newsgroup!
do you know that python makes a dict lookup on each access to global
variable/function/builtin?
and it does dict lookup for each object's method/field access.

and actually we can use vectors rather than dicts for lexical environments,
so it will be much faster.
and if you call that "terrible penalties", how will you call python's
performace? i don't know which adjective can express it then..

PRThat's the point. The compiler would treat those as references to
PRslots in the call frame, would do type inference so it could use
PRunboxed atoms where it could, etc. You'd lose all that.

i think there can be some optimizations (we need lex env object only where
we need a closure, i think), but right -- to have best performance, you'll
need to implement it in the language level. but you can get functionality
working right, and with acceptable performance.
if python's performance is acceptable for you, why other interpreter's won't
be?

??>why do you think so?
??>you know some case that does not work with call/cc?

PRI don't see how to implement coroutines with CL macros. Maybe I'm
PRmissing something.

read the book.

i can give you a basic idea:

* (macroexpand '(with-call/cc (print 1) (call/cc (lambda (k1) k1)) (print
2)))

(DRIVE-CPS
(PROGN
(PRINT 1)
(LAMBDA ()
(FUNCALL #'TOPLEVEL-K
(FUNCALL #'(LAMBDA (K1) K1)
(MAKE-CALL/CC-K
(LAMBDA (#:V-1712)
(DECLARE (IGNORE #:V-1712))
(LAMBDA ()
(FUNCALL #'TOPLEVEL-K (PROGN (PRINT 2)))))))))))

you see that it makes a cut in call/cc point -- continuous blocks are not
affected with the transform.

??>and then use call/cc as i've shown in
??>example. that's real generators. there's no need for any cond -- you
??>can save state as current-continuation.

PRFully general call/cc has to be able to switch from one execution
PRstack to another and back.

that's from imperative point of view.

but once you convert it to CPS, you just operate with closures. stack is
just a lexical variables caught into closure.
do you know what does CPS mean at all??

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

[jayessay]

Re: merits of Lisp vs Python

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

On Mon, 11 Dec 2006 02:51:50 +1100, Steven D'Aprano wrote:
>

On Sun, 10 Dec 2006 14:21:17 +0000, Kirk Sluder wrote:

In article
<pan.2006.12.10 .14.24.05.64806 8@REMOVE.THIS.c ybersource.com. au>,
Steven D'Aprano <steve@REMOVE.T HIS.cybersource .com.auwrote:
>
>Yes. But you can't redefine 1+2 in Python, at least not without hacking
>the interpreter. Can you redefine (+ 1 2) in Lisp?
>
Not without barreling through error messages about name conflicts.

Ah, nice to get a straight answer to a question for a change, and without
an insult or a misrepresentati on in sight. Thank you.

>
Such a pity that answer is, apparently, wrong.
>
Thank you to those who wrote back with the more accurate answer, which
apparently is "yes, it is easy and there are no error messages".

Actually, that's not correct either. The correct answer is that the
consequences of redefining (or altering in any way) cl:+ are
undefined. Generally, in this context, that means the same as
"implementa tion defined". So, while it would be possible in some
conforming implementation to "just sit back and let all hell break
loose" in this situation, in practice, they issue a "barrel" of error
messages.

The message from Frank Buss (and possibly others) that it is actually
easy and results in no errors in any implementation is in error (i.e.,
its just plain wrong). What he is showing is that it is possible to
_shadow_ cl:+ - this in no way shape or form _alters_ (including
redefinition) cl:+.

So, while both comments you mention here are strictly speaking wrong,
Kirk Sluder is quite close to being correct, since, while a conforming
implementation could do nothing, all extent ones that I know of do
issue errors.


/Jon

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

[Paddy]

Re: merits of Lisp vs Python


JShrager@gmail. com wrote:

Paddy wrote:

Python is fun to use.
Easy to read.
Simple and powerful.
Easy to test.
Easy to maintain.
Fast. Very fast!

>
Okay, I'm going to commit another rhetorical fallacy here called
"Argument from Authority": I challenge anyone making psychological
claims about language X (for any X) being easier to either
read/learn/use than language Y (for any Y) to come up with any valid
evidence whatever. Having a PhD in Cognitive Psychology (as well as two
degrees in computer science) where my subject was how people learn to
program (among other things), and having extensive experience in this
field, I am almost certain that no such evidence exists (at least not
for any real programming language). Now, like any good scientist, I
could be wrong, but you'd have to convince me, and I very much doubt
that you could.

Whilst you wait for 'evidence' proving that, for any languages X and Y,
for
example, befunge is easier to grasp than Logo; people who have tried
Python and found it easier to learn than other languages can switch to
Python, (welcome, by the way); and just get things done.
,

>
While I'm engaging in this particular fallacy, here's another instance:
Since I'm probably (although I'm not certain) the only person in this
thread who has made a significant amount of money on either of these
languages (i.e., via the sale of a startup whose product was tens of
thousands of lines of Lisp code, and some Tk GUI stuff), and knowing
both Lisp and Python (although I'm certainly not a Python wizard), I am
nearly certain that what we did in Lisp COULD NOT HAVE BEEN DONE IN
PYTHON -- PERIOD. The reason has little to do with macros (although
they were very helpful, of course, esp. in making Tcl look like a
reasonable language so that we could use Tk); it has to do with speed,
which has to do with compilers, which, as it turns out, has to do with
macros. (See below.)

Maybe for your application, but others think that speed is more to do
with algorithm. Python has to rely more on using the right algorithm
but
it makes algorithm exploration easier than some languages, embedding
good algorithms for things like sort, and allowing the wrapping of
libraries optimised in other languages.

>
Now, speaking as a scientist, permit me to make a small practical
suggestion:

Speaking as an engineer please allow me to make the large practical
suggestions ;-)

Python -- make parens (or whatever) optionally replace whitespace and
line breaks as syntax -- and then add a simple macro facility -- macros
are actually a very simple extension if you have homogenous syntax,
homogenizing your syntax to the point where macros are possible is the
hard part -- and just see what happens. One of two general things are
likely to happen: Either people will not use them, and they will
languish and die, and then at least you can say; "Been there, done
that" to the Lisp community. Or, more likely, the some subset of the
Python community will get it, and will figure out how useful they are,
although it might take some time. And then you might find yourself with
a wonderful new tool. You might even get a compiler out of the deal, at
a pretty low cost, too! If you get macros, and get a compiler, I'm
pretty sure that you will have no problem winning over the Lisp
community, who would LOVE to have your extensive libraries, and that
you will probably be able to maintain and improve your flagging
position wrt Ruby (which, according to Matz, is more-or-less just Lisp
w/o macros.)
>
I'm not saying that this is going to be an easy or quick experiment,
but it's one that I, and I think most Lispers, would both like to see
happen, and would benefit from! Moreover, I dare say that some of us in
the Lisp community would love to HELP -- at least I would, and I'm
guessing that others would as well.

Talk to these guys:
http://en.wikipedia.org/wiki/PyPy they have an interesting take on
Pythons
interpreter, and their work is being used as part of a Python->C++
flow..

>
(Unless you guys get a compiler too, you'll always just be a
scripting language,

Guess what. Scripting Language is not a pejorative term. If you mean
that
python can only be used for 'glue code' then, you'r right, you don't
know
enough about Python.

but compilers are GREATLY facilitated by having a
macro facility because (at first blush) all you need to do is to
macro-expand down to something you know how to turn into code. This
isn't the only, nor perhaps the best way to get a compiler, but it's
a step in that direction. Later on you can learn the other great
features offered by homogeneous syntax, like being able to write code
walkers, which help improve over the "first blush" compiler. Soon
enough, I predict, you'll be so far past us and Ruby that...well,
even Kenny with jump on board! :-)

Code walkers? Do you mean reflection?
Python has this unsung module called doctest that neatly shows some of
the strengths of python:

http://en.wikipedia.org/wiki/Doctest

- Paddy.

[tayssir.john@googlemail.com]

Re: merits of Lisp vs Python

Paul Boddie wrote:

tayssir.john@go oglemail.com wrote:

Keeping with the analogy, Lisp offers power to adapt your notation to
the domain you're describing. One thing people expect from a language
is a certain malleability in order for it to somehow resemble the
domain they're describing.

>
I think the more interesting issue of relevance to both communities
(and I wonder whether the original inquirer is still reading) is
whether a language like Python is an acceptable specialised notation
for so many domains as to make a more malleable language like Lisp less
interesting for most specialists. In other words, that there are so
many areas where Python's arguably mundane semantics are sufficient
that the specialists have their convenient, common means of
communication which happens to span large areas of computational
endeavour.

Well, I think it's twofold:

* How well do languages keep up with changing requirements and
paradigms?

* Don't you want a domain expert (perhaps you) designing your problem
domain's notation, someone who cares deeply about the problems you
face?

When Python is fine for your domain, great. But as you stray from the
intention of Python's central designers, your code loses correspondence
with your problem domain.


For example, this book offers a case study in an mp3 parser syntax
which corresponds visually to the spec:
<http://www.gigamonkeys .com/book/>

Or here are some simple examples, with HTML:
<http://weitz.de/cl-who/#example>

And on the occasions where Python doesn't provide adequate,
convenient metaprogramming features, might it not be the case that less
elegant program transformation mechanisms or even other approaches to
architectural design aren't good enough solutions? After all, the
various object-oriented design movements, for example, even though they
may be regarded as having produced clumsy and verbose mechanisms for
expressing certain kinds of systems, have in some way or other provided
a recognisable vocabulary that many people understand.

OOP is actually a good example. Alan Kay stated: "I invented the term
Object-Oriented, and I can tell you I did not have C++ in mind." (From
a link I gave earlier.)

The central designers behind C++ were certainly thoughtful. But they
weren't all OOP experts. There should be some room for interested
people to easily experiment with a new paradigm's concepts. After going
through enough testing and common use, it can even be folded into the
language itself.


There's another anecdote. At LL2, a convention of language designers, I
recall the guy from Microsoft Research wanted nondeterminism in a
programming language. But you can actually download a Lisp library
which provides nondeterministi c computing features.
<http://ll2.ai.mit.edu/>
<http://www.cliki.net/Screamer>


YMMV, as usual.


Tayssir

[dixkey@gmail.com]

Re: merits of Lisp vs Python


Steven D'Aprano wrote:

from foolib import *
bar.bar("somefi le")

What does this program do? I have no idea. Its functionality is
hidden behind multiple layers of abstraction (function, object,
library.)

>
Sure.
>
But at least you know that foolib is a module or package. You know what
from and import do, and that can't change. And you know that bar is an
object with a method also called bar, it is being called, and the
argument is a string "somefile". Those things can't change. Imagine a
hypothetical language where those two lines could mean *anything*.

Oh, you mean imagining a hypothetical language like Python? Where bar
might not have a method bar at all? Where it might be a property set to
an intance of a class with __call__ method? Oh where a metaclass for
bar can intercept a request for "bar" property, do *anything* and call
sys.exit() without even getting to the ("somefile") part?
Thanks, it was fun to hear about Python being hypothetical.

[Ravi Teja]

Re: merits of Lisp vs Python

Why? The benefit of expressiveness and power isn't monotonically

increasing. Look at us: we're all communicating in a common language,
English, and we all agree on syntax and grammar.

I think we all agree that with flexibility comes abuse "potential" . But
if that potential will actually be likely realized or that we are just
being scared of a phantom can only be determined by empirical evidence.
While, reliable empirical evidence is hard to get in programming
languages, we can only ask the people who use the languages which
support features like macros and tell us what they feel about them
rather than make arguments based on hypothetical possibilities.

So far I am hearing a near unanimous statement from users of these
languages that while there is abuse potential, they do not use it in
that manner and that they are glad that the feature is available than
not. Of course, people tend to defend the languages (or just about any
skill) that they have invested in. Especially when they are not aware
of the alternatives. But this does not seem to be the case with these
people. Macros continue to be incorporated in the latest languages
(OCaml, Boo, Nemerle) with no reports of abuse.

But then again, Python may not be the right language for macros. We try
to have a language that is easy for beginners while having sufficient
richness for advanced users. The abuse potential could potentially be
higher with excess expressiveness as we have seen with Perl. That might
be a good argument to not make Macros a part of language but not so
much as to not have external support.

I doubt that Logix did not catch on because people thought it was too
dangerous to use. 3 likely reasons are.
1. They did not hear about it.
2. They did not understand it.
3. The current implementation is slow.

Now, I could be a lot
more expressive, and language could be a lot more powerful, if I could
define my own language where "You are a poopy-head" was in fact a detailed
and devastatingly accurate and complete explanation for why Python was a
better language than Lisp.

This is exactly what I meant by a phantom. Could you show me some any
Lisp macros in the wild that show this kind of abuse?

You could just as egregiously abuse Python's dynamic typing and
metaclasses. And it is likely that some do that. But I have not seen
any Python library worth mentioning with such abuse. All the Python
programmers I have seen, seem a lot more sensible than you seem to give
credit. And that is the whole point of "We are all adults here"
argument that you seem to side step.

[Paul Rubin]

Re: merits of Lisp vs Python

jayessay <nospam@foo.com writes:

Maybe not bleeding edge, but more modern than CL in my opinion.

Odd, caml is even older than CL.

You'd have to compare (say) OCaml to CL if it's dialect against
dialect. If you're going to bring in the earlier ML family you also
have to bring in Lisp 1.5, which goes much further back than CL.

[Paul Rubin]

Re: merits of Lisp vs Python

André Thieme <address.good.u ntil.2006.dec.2 2@justmail.dewr ites:

Instead of function = memoize(functio n)
one could just say: memoize(functio n).

In Python you'd say

@memoize
def function(): ...

[dixkey@gmail.com]

Re: merits of Lisp vs Python


mystilleef wrote:

Advantages of Python:
>
1). More and better mature standard libraries (Languages don't matter,
libraries do).

Right.

2). Multiple programming paradigms (including functional style
programming see itertools, functools, operator modules (lambda, map,
filter, reduce, sum etc builtins), higher order functions, list
comprehension, blah, blah)

Either you meant this to go under "advantges of Lisp" or you know
nothing
about Lisp.

3). Better OO implementation. (I used to hate OO until I started using
Python)

Better than what? Lisp's OO? Same comment as number 2.

4). Ultimate glue language (Plays well with C, C++, Java, .NET. nuff
said. Bindings for almost any lib worth using, at least on *nix)

Plays well with C - correct. But who does not? C++, really, you sure
about that?
Java and .NET? Sure. Separtely. How about some of the above at the same
time?
Oh, sorry, no advatage here...
Also, when you say "plays well" you mean the necessity to hand-craft a
C wrapper, compile and debug it *in C*? Or do you mean the easy and
"pythonish" way, the ctypes thing, that even IIRC was even included in
python 2.5 (I switched to Lisp before 2.5) which allows to create the
bindings without leaving the comfort of your host language? Yeah, the
praise for ctypes was well-earned, it was a very nice development,
great for python world. Now, that said, wanna make a wild guess how
exactly the foreign-function interfaces in Lisp have been working? ;)

5). Clearer syntax.

Sometimes. Sometimes not.
class aaa:
def mmm()
...
mmm=staticmetho d(mmm)

6). Better namespace management. (nobody ever talks about this, but
Python seems to be one of the few languages that gets symbol management
right from a users perspective)

Maybe, yes. Subject for discussion.

7). Easier packaging and distribution system.

Oh which one do you mean? the <=2.4 style, which is a tar.gz with a
setup.py inside, and that setup.py knows how to compile the library?
Kina like ASDF in Lisp, only not handling dependencies, recompilation
etc? Or the new 2.5+ style, that can also download stuff from the
net... Kinda like ASDF-INSTALL? (I'm using version numbers here as time
designators, mybe the new system works with 2.4, I don't know)

8). Ubiquity! Python is everywhere. Lisp, bleh.

You're probably right. Still, are you able to name without doing a
research three-five platforms that support python, but don't support
Lisp? And how many of them are you using?

9). Relatively good docs (PHP has better).

"Relatively " is a keyword here.

10). Fewer perceived community assholes.

I thought so before (although it didn't bother me). But this thread
somewhat readjusted my perception of the amount of pythonistasshol es.

Large community.

Right.

11). Less fragmentation.

Not sure what you mean here. Are you referring to multiple Lisp
implementations ? Do you think they differ much more that python vs.
jython?

Advantages of Lisp:
>
Learning a functional language can improve your programming range and
depth. And today, I wouldn't even recommend Lisp (it's rather archaic),

Right, you know nothing about Lisp.

I think they are overrated, and in general cause more harm than good.
It's the reason I find [...] programs difficult to grok, maintain
and extend. Cos every smart ass wants to needlessly write his own mini
language to the point of absolute obfuscation. Naturally, I'm supposed
to be awed by his mischievous cleverness.

Substitute, for example, python metaclasses for [...]


You've got a point about the libraries though.

[JShrager@gmail.com]

Re: merits of Lisp vs Python

Python has to rely more on using the right algorithm...

This sound familiar: "Macros are dangerous!" "Compilers make you lazy."
"Worse is better!" (I have a Russian friend -- a mathematician -- who
jokes that the reason the Soviets were great mathematicians because
their computers sucked, so they had to use extensive formal
manipulation to get things to run fast enough to get anything done. He
was joking (I think); you don't appear to be.)

Talk to these guys:
http://en.wikipedia.org/wiki/PyPy they have an interesting take on

No, actually maybe you should talk to them since you seem to think that
making Python run fast is dangerous, or at least unnecessary.

Python has this unsung module called doctest that neatly shows some of
the strengths of python: http://en.wikipedia.org/wiki/Doctest

Now I'm *certain* that you're just pulling my leg: You guys document
all your random ten-line hacks in Wikipedia?!?! What a brilliant idea!
Hey, you even have dead vaporware projects like uuu documented in
Wikipedia! Cool! (Actually, I don't know that doctest is ten lines in
Python, but it'd be about ten lines of Lisp, if that, so I'm just
guessing here.)

[Wolfram Fenske]

Re: merits of Lisp vs Python

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

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

>Yes, I wrote about it in another post. It was introduced in Python
>2.5. And if it hadn't been I'd still have to write code like this.

>
You could do something with decorators that's not too bad. You'd end
up writing:
>
@withConnection
def some_func():
do_whatever_stu ff ()

Yes, now I can. But I had to wait until Python 2.4 to be able to
that. What I like so much about Lisp macros is that they allow me to
make these changes myself.

--
Wolfram Fenske

A: Yes.

>Q: Are you sure?

>>A: Because it reverses the logical flow of conversation.

>>>Q: Why is top posting frowned upon?

[dixkey@gmail.com]

Re: merits of Lisp vs Python

JShrager@gmail. com wrote:

Talk to these guys:
http://en.wikipedia.org/wiki/PyPy they have an interesting take on

>
No, actually maybe you should talk to them since you seem to think that
making Python run fast is dangerous, or at least unnecessary.
>

I find it amusing that most of the arguments that python-people are
making in this thread are actually the arguments that C++ and Java make
against Python. "Who needs dynamic typing?", "Who needs closures?",
"The idea of using whitespace for syntax is beyond stupid"... Now the
python guys obviouly see that that those arguments are bogus, but they
keep the same reasoning against lisp.

I switched to learning Lisp after Python and knowing Python helped me
greatly. And not only the fact that many features were already familiar
from Python (I've already known Smalltalk, Prolog and Mozart-Oz for
example, as the more weird ones, besides of course the whole array of
standard ones like FORTRAN, Pascal, C, Modula-2,C++, etc), but mostly
it was the fact that even if something looks weird and
unreadable/useless/dangerous/whatever at first sight, it might turn out
different when you get used to it. For example I started to learn
Python three times. The first two - I've read about whitespace syntax,
exclaimed "how stupid some people are" and threw the book away. The
third time I've managed to pass that barrier and found the experience
rewarding. And that was the *real* knowledge - when faced with Lisp's
parentheses I would've probably have the same reaction, but I've
remembered my experience with Python and decided to give it a try. So,
thanks to Python for making me more open to unconventional concepts and
guiding me to learning Lisp!
I still find Python a nice language and have warm feelings towards it,
although I don't think that given a choce I'd ever pick it over Lisp.

[Kaz Kylheku]

Re: merits of Lisp vs Python

Steven D'Aprano wrote:

I'd love to say it has been fun, but it has been more frustrating than
enjoyable. I don't mind an honest disagreement between people who

Honest disagreement requires parties who are reasonably informed, and
who are willing not to form opinions about things that they have no
experience with.

So now I have an even better understanding for why Lispers have a reputation for being difficult and
arrogant.

Whereas, for instance, lecturing a Lisp newsgroup (of all places) in
the following manner isn't arrogant, right?

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

If that had been intended to be funny, you should have made that more
clear by choosing, say, lambda calculus as the subject.

But I also gained a little more insight into why Lispers love their
language. I've learnt that well-written Lisp code isn't as hard to read as
I remembered, so I'd just like to withdraw a comment I made early in the
piece.

You /think/ you learned that, but in reality you only read some
/opinions/ that Lisp isn't as hard to read as was maintained by your
previously held opinions. Second-hand opinions are only little better
than spontaneous opinions. It's, at best, a slightly favorable trade.

I no longer believe that Lisp is especially strange compared to natural languages.

Natural languages are far less completely understood than any
programming language. Only your own, and perhaps some others in nearby
branches of the language tree do not appear strange to you.