Why don't people like lisp?

Tayss tayss_temp at yahoo.com
Sun Oct 19 07:07:53 EDT 2003


Lulu of the Lotus-Eaters <mertz at gnosis.cx> wrote in message news:<mailman.198.1066494800.2192.python-list at python.org>...
> As soon as I try to learn more by reading discussions, I am bombarded
> with weirdly fanatical (and very long) posts that are overwrought with
> many misrepresentations (e.g.  Python has "Lisp DNA", when pointedly it
> does not by GvR's indication).  Not that different Lispers even bother
> with the same misrepresentations--just so long as they are clear that
> programmers of all other languages are ignorant and stupid.

It is very strange.  The Pythonista in me wonders if Common Lispers
(as a whole) realize what appeals to Python users.  But then, their
most coherent marketing story is an attempt to reach those attracted
to Python for its powerful nature, not necessarily the mainstream
Python user.

The big appealing argument in favor of macros is with-open-files.  You
set up a block, and the power of macros close the file automagically
when you're done.  None of this try/finally madness.  The try/finally
is hidden inside the macro.

So you basically have something like:
with_open_file f (filename, 'r'):
    # read from f, do what you want;
    # once you leave the block it will be autoclosed!
    # Even if the clever user reassigns f it will be closed!

(In fact, I keep on wanting to describe Emacs's save-excursion as a
fantasy that you wake up from at the end.  The system protects you
from the likely negative consequences of your actions.)


Alex Martelli argued that macros create hidden things that affect code
at-a-distance.  But there are CL tools to fix this!  I just used
macroexpand to see what with-open-file "really" becomes. 
macroexpand(with_open_file f (filename, 'r')) would become something
like:
try:
    unique_temp = open(filename, 'r')
    f = unique_temp
    # do work here with f
finally:
    if unique_temp:
        unique_temp.close()

Now, I don't know if macros can seriously be done within Python, it's
just a demonstration on how safe macros can make a language.


Another nicety of the lisps is you can have almost whatever names you
like, for functions and variables.  Something like "number->string"
could be a name of a function that converts a number into a string. 
Everyone gets those destructive Python functions like list.sort()
wrong at first, thinking that it returns a list.  Why not have it be
sort!() for something that returns None?  Of course, many of these
names would be up to kindly people like Guido & Co, so that coherent
guidelines could ripple through the Python continuum.

It's not absolutely clear if Common Lisp is readable in the small.  I
believe the normal CL argument is about readability in the large,
since the Lisps have good abstraction facilities.  (This way, you can
"name" nasty pieces of code with simple representations.)  Scheme is
very readable in the small; but it's unclear whether it will evolve a
highly used Lisp anytime soon.  But in terms of WRITING code, I prefer
Common Lisp even though Python's nicer to read.  So a lot of CL is
invisible.  In particular, the difficulty of reading CL may be partly
due to CLers removing patterns whenever they come up.

Anyway, just my opinion, as someone with the Pythonic and Lisp DNA.




More information about the Python-list mailing list