merits of Lisp vs Python

[Mark Tarver]

How do you compare Python to Lisp? What specific advantages do you
think that one has over the other?

Note I'm not a Python person and I have no axes to grind here. This is
just a question for my general education.

Mark

[JShrager]

Thankfully folks (including me) seem to be starting to cool off, so
perhaps we can disucss this in somewhat calmer register. I think that
Kenny unintentionally sold macros short by implying that they are
merely window-dressing for boilerplate, and you seem to have a
misunderstandin g of macros, which I won't go into too deeply but to
point out that the purpose of macros is not the same as functions.
Functions create new ...uuuhh... functionality, whereas macros create
new programming constructs. These work in very different conceptual
parts of the programming landscape: The former addresses the way that
the functions offered by the programming language fit the parts of the
problem whereas the latter addresses the way that the programming
language itself fits the problem.

So, whereas I will grant that:

"Oh yes, macros give you great power, and with great power comes great
responsibility. Be careful."

I don't think that any experience Lisp programming would grant that:

despite all the talk, Lisp coders don't
actually create new syntax or mini-languages all that often, that they
just use macros as functions

So, to your point:

then the question becomes: why do you need
macros then if you are just using them as functions? Why not use functions?

No, they are not functions. We need them because although it is usually
possible to make a given programming language's functionally fit any
given problem, it is often much more convenient, and much cleaner, both
practiaclly and conceptually, to make the programming langauge fit the
problem too.

[mystilleef]

Mark Tarver wrote:

How do you compare Python to Lisp? What specific advantages do you
think that one has over the other?

Note I'm not a Python person and I have no axes to grind here. This is
just a question for my general education.

Mark

Advantages of Python:

1). More and better mature standard libraries (Languages don't matter,
libraries do).
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)
3). Better OO implementation. (I used to hate OO until I started using
Python)
4). Ultimate glue language (Plays well with C, C++, Java, .NET. nuff
said. Bindings for almost any lib worth using, at least on *nix)
5). Clearer syntax.
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)
7). Easier packaging and distribution system.
8). Ubiquity! Python is everywhere. Lisp, bleh.
9). Relatively good docs (PHP has better).
10). Fewer perceived community assholes. Large community.
11). Less fragmentation.

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),
when there's mind bending Haskell. I'd go as far as saying I believe
Haskell has a better fate than Lisp.

On Lisp Macros:

I think they are overrated, and in general cause more harm than good.
It's the reason I find Lisp-like 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.

Conclusion:

The semantics or features of a language is almost irrelevant today.
Developers want to put the lego pieces together, they don't want to
make lego. Rewriting the sun and moon, or needlessly reinvent the wheel
was popular in the 70s, but it's boring and expensive today. Today,
when a developer needs to solve a problem, the question they ask is,
"Is there a library for that?". If the answer is no, they a more likely
to switch to a language that provides a library that solves their
problem. The challenge for developers today is software architecture,
robustness and scalability, not language purity or semantics. The Lisp,
and to an extent Haskell, community will never ever ever grok this.
They'll continue to wonder why an "inferior" language like Python keeps
getting popular. It will always escape them that it might be because
Python is actually easier to use for most people to write "real world"
applications. It has good usability.

[Timofei Shatrov]

On Sun, 10 Dec 2006 04:24:43 +1100, Steven D'Aprano
<st***@REMOVE.T HIS.cybersource .com.autried to confuse everyone with this
message:

>On Sat, 09 Dec 2006 14:00:10 +0000, Timofei Shatrov wrote:

>On Sat, 09 Dec 2006 20:36:02 +1100, Steven D'Aprano
<st***@REMOVE. THIS.cybersourc e.com.autried to confuse everyone with this
message:

>>>On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:

if Common Lisp didn't have CLOS, its object system, I could write my own
as a library and it would be just as powerful and just as easy to use as
the system Common Lisp already provides. Stuff like this is impossible
in other languages.

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

Here, you've basically shot yourself in the ass. Appealing to Turing
completeness when talking about programming language features is about the
dumbest thing you can make. In Turing sense, a program is simply a function that
takes an argument and returns a value. It doesn't say anything about how this
function was implemented. It could be Turing machine, lambda calculus, Markov
chains or whatever else. All these methods produce the same set of programs, but
that doesn't mean you could implement lambda in Turing machine for example.

What exactly are you trying to say here? Is this a comment about the
relative practicality of writing code in a Turing machine versus
high-level languages, or are you implying that lambda calculus is "bigger"
than any Turing-complete language?

I'm trying to say that the ability to read is a very useful skill in a Usenet
discussion. Your posts, like the two quoted above, seem to indicate the lack of
it.

--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________ |

[tayssir.john]

Steven D'Aprano wrote:

With Lisp macros, even that isn't guaranteed. Now, if Lispers would say
"Oh yes, macros give you great power, and with great power comes great
responsibility. Be careful." then, no doubt, we'd take you guys more
seriously.

Who are "we"? I was a heavy Python and Java user before being aware of
Lisp. I knew even then that there was something wrong with the
programming world, because there were too many programming patterns I
could not automate away within the language. It's ironic to be a
programmer who can't automate her own work.

I told people that programming was just "glorified accounting." I
shrugged when reading about how complexity was exploding, because that
was the language designers' job to manage it.

Upon hearing of Lisp, I taught it to myself alone, because it was
important. Despite all the FUD, despite all the people who presumed
that a language designer was smarter than his users. I came to realize
that the programming world was full of users who repeated "convention al
wisdom" based on generalities they heard from a friend of a friend of
an evangelist of a corporation -- and worse yet, I was part of that
culture and picked up those poor habits.

Now, if you want to tell me that, despite all the talk, Lisp coders don't
actually create new syntax or mini-languages all that often, that they
just use macros as functions, then the question becomes: why do you need
macros then if you are just using them as functions? Why not use functions?

You may wish to read the following:
<http://www.defmacro.or g/ramblings/lisp.html>

Perhaps Lisp becomes clearer once you see its syntactic similarity with
a very mainstream language -- XML. (But sexps are far more lucid than
XML.) Then we can seriously talk about the real-world engineering
implications of macros, and other powerful features which aren't so
hyped as macros.
Tayssir

[Bill Atkins]

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

I've read all the arguments against significant indents/whitespace, or
in favour of braces, and while there are a few minor good points they
make, a few edge cases where Python's significant indentation is
sub-optimal, overall I believe that the famous reaction of programmers to
Python and whitespace is simply them being more like cats than usual:

"It's different, anything different is frightening, I don't like it, hiss
hiss spit!!!"

What about "It's wrong, it's wrong, hiss hiss spit!" ?

I want to be able to change my code and let the editor indent the
result; if I make extensive changes to a section of Python code, I
have to review it afterward and make sure I haven't introduced any
subtle indentation mistakes. Compare

(let ((x 'blah))
(if (eql x 'foo)
(print "blah")
(print "bloo"))))

This could quite conceivably be the result of a lot of refactoring
of (admittedly silly) code. But now I just press C-M-q and, pow:

(let ((x 'blah))
(if (eql x 'foo)
(print "blah")
(print "bloo")))

All happily-indented. And mistakes in nesting show up as mistakes in
indenting. Who could ask for anything more? Python requires me to
review the structure of the code to make sure I haven't inadvertantly
broken it. Why?

Why do I need Python to enforce my indentation (potentially leading to
bugs) when my editor can indent my code perfectly because the syntax
of Lisp is so free of special cases?

But Lisp's syntax is so unlike most written natural languages that that it
is a whole different story. Yes, the human brain is amazingly flexible,
and people can learn extremely complex syntax and grammars (especially if
they start young enough) so I'm not surprised that there are thousands,
maybe tens or even hundreds of thousands of Lisp developers who find the
language perfectly readable.

Most programming languages are nothing like natural languages
(thankfully - ever heard of something called COBOL?). Lisp's syntax
is trivial to lean, and its semantics are very precise.

But that isn't to say that the syntax of Lisp is for everybody. Far from
it -- I'd be willing to bet that Lisp developers are a self-selected group
of far above average intelligence. That would explain why so many of them
seem to be so much more comfortable with higher-order functions than most
other people -- even intelligent people.

(Looking back, I'm embarrassed about my first reaction to factory
functions all those years ago. Hiss hiss spit. But even with added
familiarity, there comes a time where one has to question the benefit of
sufficiently high-order functions. If you are writing a factory function
that returns factory functions that return factory functions that return
the functions that you needed in the first place, chances are you really
need to rethink your tactics.)

If I'm right, then maybe Lisp is "better" in some absolute sense, *for
those who can use it*. For those who can't, it isn't just a matter of
(say) the syntax being hard to read because it is unfamiliar, but it
being objectively harder to use.

An interesting study would be to track people's eyeballs as they read
code, or look at how much oxygen their brain uses. Do Lisp coders do more
work to read Lisp than Python coders do to read Python? I suspect they do,
but successful Lisp coders don't notice. Everybody else does, and
gravitate to languages which might not be "better" but are "good enough".

(If my post leads to any Lisp developer's already swollen head exploding
from pride, my job here is done *wink*)

I'm afraid you're on the wrong track. Any programmer can pick up Lisp
and be productive in it these days. Please don't try to make Lisp
seem more mysterious or elitist than it really is. It's just a
programming language, and anyone can learn it:

http://www.gigamonkeys.com/book

[Bill Atkins]

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

On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:

>if Common Lisp didn't have CLOS, its object system, I could write my own
as a library and it would be just as powerful and just as easy to use as
the system Common Lisp already provides. Stuff like this is impossible
in other languages.

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

Of course, but you have to realize that Turing-completeness is a
useless concept when comparing languages. C and Python are both
Turing-complete. So: write me some code in each that reads in a line
of text, splits it on spaces and stores the result in an array. Which
would you rather write? Which will be shorter and more easily changed
and straightforward ly grasped in the future?

QED. Turing-completeness is irrelevant when comparing languages.
Take it as a given.

[Bill Atkins]

"mystilleef " <my********@gma il.comwrites:

Mark Tarver wrote:

>How do you compare Python to Lisp? What specific advantages do you
think that one has over the other?

Note I'm not a Python person and I have no axes to grind here. This is
just a question for my general education.

Mark

Advantages of Python:

1). More and better mature standard libraries (Languages don't matter,
libraries do).
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)
3). Better OO implementation. (I used to hate OO until I started using
Python)
4). Ultimate glue language (Plays well with C, C++, Java, .NET. nuff
said. Bindings for almost any lib worth using, at least on *nix)
5). Clearer syntax.
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)
7). Easier packaging and distribution system.
8). Ubiquity! Python is everywhere. Lisp, bleh.
9). Relatively good docs (PHP has better).
10). Fewer perceived community assholes. Large community.
11). Less fragmentation.

Are any of these not subjective?

Advantages of Lisp:

Learning a functional language can improve your programming range and

Lisp is much more than a functional language.

depth. And today, I wouldn't even recommend Lisp (it's rather archaic),
when there's mind bending Haskell. I'd go as far as saying I believe
Haskell has a better fate than Lisp.

Yeah, that's pretty far.

On Lisp Macros:

I think they are overrated, and in general cause more harm than good.
It's the reason I find Lisp-like 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.

Uh huh. Can you cite examples of this? Sounds like you're just
making stuff up here. Contrary to popular belief, writing a Lisp
macro that warps your mind and introduces a totally un-CL-like
semantics is extremely difficult. Most of the people who are good
enough at CL to do it (I'm certainly not one of them) are also
experienced enough to know when it's the right choice.

And Lisp environments all support getting the macroexpansion,
documentation, and source of any unfamiliar macro you might happen
upon, so really this is not as much of a problem as you might
fantasize it to be.

Conclusion:

The semantics or features of a language is almost irrelevant today.
Developers want to put the lego pieces together, they don't want to
make lego. Rewriting the sun and moon, or needlessly reinvent the wheel
was popular in the 70s, but it's boring and expensive today. Today,
when a developer needs to solve a problem, the question they ask is,
"Is there a library for that?". If the answer is no, they a more likely
to switch to a language that provides a library that solves their
problem. The challenge for developers today is software architecture,
robustness and scalability, not language purity or semantics. The Lisp,
and to an extent Haskell, community will never ever ever grok this.
They'll continue to wonder why an "inferior" language like Python keeps
getting popular. It will always escape them that it might be because
Python is actually easier to use for most people to write "real world"
applications. It has good usability.

I don't agree with a lot of what you say in this paragraph, but I
you're right that libraries are crucial. That's why I wish there were
more people writing Lisp libraries instead of being scared away by
sheer fabrications like the stuff that's appearing in this thread.

[Bill Atkins]

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

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

"Can you imagine if carpenters were like computer scientists? Some of
them would argue that it's not necessary to own a hammer because the
butt of a screwdriver is naildriver-complete."
-- Barry Margolin in comp.lang.lisp

[Alex Mizrahi]

(message (Hello 'Paul)
(you :wrote :on '(09 Dec 2006 01:01:14 -0800))
(

PRIf Common Lisp didn't have lexically scoped variables (most Lisp
PRdialects before Scheme didn't have them) then it would be very
PRdifficult to add that with macros.

i think there's some way to hack that. for example, make defun a macro that
will collect all lexically scoped variable and mangle them. for example:

(defun foo () (let ((i 1)) (print i)))

will be transformed to

(defun foo () (let ((i_foo 1)) (print i_foo)))

(or just some random suffix). this way variables in different functions will
never collide. maybe there's a catch somewhere, but that should look very
close to lexical variables.

PRDo you seriously think lexical scoping is the last word in language
PRfeatures and that there's now nothing left in other languages that
PRcan't straightforward ly be done in CL? Hint:
PRcall-with-current-continuation (also known as call/cc).

there's nothing impossible :)
we even have a lib for nondeterministi c calculations -- Screamer, that's
much much more cool than that call/cc..

(defun pythagorean-triples (n)
(all-values
(let ((a (an-integer-between 1 n))
(b (an-integer-between 1 n))
(c (an-integer-between 1 n)))
(unless (= (+ (* a a) (* b b)) (* c c)) (fail))
(list a b c))))

you define ranges for variables, define constraints (in a form very close to
normal lisp code) and then just say -- all-values, or solutions (first thing
that satisfies constaints).

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

[Bill Atkins]

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

With Lisp macros, even that isn't guaranteed. Now, if Lispers would say
"Oh yes, macros give you great power, and with great power comes great
responsibility. Be careful." then, no doubt, we'd take you guys more
seriously. But we don't hear that -- we hear Lispers going on and on about

And, of course, we do say that. Nobody wants people running around
writing incomprehensibl e macros. How does that help anyone?
Fortunately, it's not a problem in practice, because most macros map
quite straightforward ly to Lisp constructs and almost no one has the
time or the intelligence to write the mini-languages that seem to be
terrifying you so much.

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?

"every corner of the language"? Please. Why are you so post-happy
when it's quite obvious that you don't know enough about Lisp to
attack it?

Most programmers do not write macros that are incredibly difficult to
understand. Beginners might, but beginners might also write
incomprehensibl e code in Java or Python. As you learn Lisp, you learn
to keep your macros tied to the underlying Lisp. You learn to make
the expansions into function or method defintions, instead of
reinventing the wheel. You leverage what Lisp offers, instead of
redefining it.

The only times you are really going to find completely alien semantics
are in textbooks (like Prolog in Lisp), in very ambitious and large
projects where the new semantics are the only reason you'd use the
code in the first place (like Franz's AllegroProlog or Marco
Baringer's CPS transformer), or in code written by beginners. Please
stop spreading FUD about this. In real life, macros make coding more
pleasant and make your code more maintainable. They are something to
embrace, not something to fear.

To provide a more solid example, Peter Seibel's book _Practical Common
Lisp_ (full text at http://www.gigamonkeys.com/book) provides a set of
classes for parsing binary files. Some user code provided in the
book:

(define-binary-class id3v2.3-tag (id3-tag)
((extended-header-size (optional :type 'u4 :if (extended-p flags)))
(extra-flags (optional :type 'u2 :if (extended-p flags)))
(padding-size (optional :type 'u4 :if (extended-p flags)))
(crc (optional :type 'u4 :if (crc-p flags extra-flags)))
(frames (id3-frames :tag-size size :frame-type 'id3v2.3-frame))))

This code very closely mirrors the standard DEFCLASS in Common Lisp,
so a maintainer knows right away what to expect. The macro expands
into DEFCLASS and DEFMETHOD forms. There's nothing mysterious going
on here; the macro is just a friendlier syntax for expressing an idea.
What I get from this are methods that read binary data into objects of
the class that I've just defined (*). That's all - methods and a
class. There is no mind-bending going on at all here. It's true of
course that I have to understand how the macro works. But without it,
I'd have to write and/or read through a lot of similar-looking code
for handling binary data. Which would you prefer?

Without a macro like this, the code required would be the definition
of boilerplate. Instead of specifying declaratively the order and
type of fields in the binary file, I would write code to read each
field from the file and then store the result in an object. I'd also
have to take into account fields that are optional. This is ugly and
boring code. Did I mention that DEFINE-BINARY-CLASS also defines
methods to save these objects back to binary files? Because it does.

So why not write this code once and then take advantage of it in the
future to get more expressive, less boring programs?

* If you don't believe me, here is the expansion of the code I cited above:

http://paste.lisp.org/display/31799

Just methods and a class.