merits of Lisp vs Python

[rurpy]

This is only because they openly disagree with your beliefs. Note that
you appear the same way to your Lisp-using flamewarrior counterparts.

We might look in the mirror:
<http://www.escapefromcubiclenation.com/get_a_life_blog/2006/04/how_the_technog.html>

Maybe Lisp users are singled out as particularly arrogant because they
claim that the last 20 or so years of the software profession have been
something of a fraud.

Well, having read a lot of this thread, I can see one of the
reasons why the software profession might want to avoid
lispies. With advocacy like this, who needs detractors?

 

[tayssir.john]

To bring that maligned natural
language analogy back into repute, I'd argue that Python and its
apparent restrictions act a lot like the specialised vocabularies and
familiar structures employed when presenting material in various
scientific disciplines: one could argue, upon reading a paper, that it
would have been a lot easier for the author to have structured the
paper differently and to have defined a one-off vocabulary, but issues
of convenient communication are highly likely to override such
considerations, especially in disciplines where conventions in
communication are already very strictly defined.

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.

So for example, Lisp may not offer infix syntax by default, but there
exist infix libraries you can download. (Haven't used it myself
though.)
http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/infix/0.html

In this sense, you can see that Lisp's syntax is rather general and can
be molded. Within the constraints of typical text sourcecode.


Tayssir

 

[Bill Atkins]

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

Um...

 

[Paul Boddie]

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]

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

PR> There would be terrible performance penalties dealing with the
PR> environment 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..

PR> That's the point. The compiler would treat those as references to
PR> slots in the call frame, would do type inference so it could use
PR> unboxed 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?

PR> I don't see how to implement coroutines with CL macros. Maybe I'm
PR> missing 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.

PR> Fully general call/cc has to be able to switch from one execution
PR> stack 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")

 

[Paddy]

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]

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:

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 nondeterministic computing features.
<http://ll2.ai.mit.edu/>
<http://www.cliki.net/Screamer>


YMMV, as usual.


Tayssir

 

[dixkey]

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]

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]

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]

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

In Python you'd say

@memoize
def function(): ...

 

[dixkey]

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=staticmethod(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 pythonistassholes.

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]

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

 

[jayessay]

http://caml.inria.fr
http://www.haskell.org

Aren't these "old-fashioned" and boring as well?



/Jon

 

[Wolfram Fenske]

You could do something with decorators that's not too bad. You'd end
up writing:

@withConnection
def some_func():
do_whatever_stuff ()

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.

 

[dixkey]

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.

 

[jayessay]

If you're talking about practicality, then of course you're correct, not
all languages are equally expressive.

In the context of programming languages, that's the key thing. And
the higher the better (more capable, more likely to get the job done).

Some languages are too expressive.

I don't believe such a claim can be shown to have any important sense
to it.

Look, all snarkiness aside, it just isn't true that "stuff like this is
impossible in other languages". If Wolfram Fenske had said "stuff like
this isn't easy in many other languages" he would have been right.

The key word here is "in". The point being made is that you can't do
this sort of thing _in_ the language, but of course (TC rearing it's
head here) you can do it _with_ the language (typically as some sort
of external preprocessor or something). There's nothing surprising
here at all. Think about it for a second and you will see that if it
were otherwise, you wouldn't need _any_ syntax (including the one
supposedly defining the language's constructs). You wouldn't "need"
IF, WHILE, DEF, assignment, or any of that stuff - it would all just
be function calls.[1]

practice.) But at least the basic syntax and keywords of the
language are known to be constant.

With Lisp macros, even that isn't guaranteed.

Of course it is. Actually it is in some sense even more guaranteed as
there is a specification for the language independent of
implemementation. Macros (whether simple or DLS level) don't change
this in the least. And having to understand the ones used in an
application/project/system is no different in kind from having to
learn the class, method, and function aspects (if any). There's no
difference in this respect. The actual difference is that once you go
to the effort of doing this phase, it is _easier_ to understand and
change such an application than a computationally equivalent one w/o
the high level abstraction you gain. That's it. Shrug.

Now, if Lispers would say "Oh yes, macros give you great power, and
with great power comes great responsibility. Be careful."

Actually, they say it all the time. IMO, they even tend to say it too
much. That you haven't stumbled across it is quite surprising.

seriously. But we don't hear that -- we hear Lispers going on and on about
how great it is that they can easily redefine every corner of the
language. Do you blame people for *believing them* and imagining that
reading Lisp code is like following some ghostly will-o-the-wisp across a
swamp, where nothing is what it seems and the landscape is forever
shifting?

I don't know if they should be blamed or not. Any real understanding
of the situation (even a somewhat cursory one) would immediately lead
one away from that sort of conclusion. So, I suppose the "real"
question is: why is there such an enormous level of misunderstanding
about this? I suppose the stock answer is "lispers are smug weenies"
or whatever. It's always the other guy's fault in todays society...


/Jon

1. Yes, I realize there are higher order techniques where people have
indeed worked on just this notion, but I don't think that's
relevant in this context.

 

[Kaz Kylheku]

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.

 

[Paul Rubin]

PR> I don't see how to implement coroutines with CL macros. Maybe I'm
PR> missing something.

read the book.

Which book?

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

I once understood the basic notion but confess to have never been
clear on the fine points. However, I don't see how you can do it with
CL closures since CL semantics do not guarantee tail recursion
optimization. If you code a loop with closures and CPS, you will blow
the stack.

 

[Kaz Kylheku]

Well, having read a lot of this thread, I can see one of the
reasons why the software profession might want to avoid
lispies. With advocacy like this, who needs detractors?

And thus your plan for breaking into the software profession is ... to
develop Usenet advocacy skills.

``That guy we just interviewed, I don't know. Perfect score on the C++
test, lots of good architectural knowledge, but he seems to care more
about being correct than convincing people. He'd be fine for now, but
what does that say about his ability when the crunch comes, and he's
called upon to ... advocate?''