merits of Lisp vs Python

[Bill Atkins]

Steven D'Aprano <steve at REMOVE.THIS.cybersource.com.au> writes:

> 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 incomprehensible macros.  How does that help anyone?
Fortunately, it's not a problem in practice, because most macros map
quite straightforwardly 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
incomprehensible 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.