Subject: Re: Macro-writing in CL
From: Erik Naggum <>
Date: Mon, 11 Jun 2001 09:48:30 GMT
Newsgroups: comp.lang.lisp
Message-ID: <>

* "Wade Humeniuk" <>
> Why is this?  I think programmers may come to use CL because of how
> disenchanted they are with programming in general (that is how it was for
> me).  Any imperfection further magnifies their disenchantment and the
> blame of those that went before starts.

  This is insightful.  Starting to use Common Lisp for real felt like
  arriving in what some call heaven, nirvana, etc.  Then I found that there
  were a lot of stuff that I needed to do at a lower level.  I always liked
  the lower levels, but I always hated having to do stuff there that did
  not belong there, such as the repetitiveness of command line processing
  in Unix and C's "main", which no two programs do exactly the same way.

  The other day, I found _another_ "idiot bug" in the Common Lisp printer.
  (write #*101 :radix t :base 36) produces #*#36r1#36r0#36r1 in Allegro CL
  and CMUCL.  When I read Wade's comment now, I realized that my sense of
  _betrayal_ in discovering that bug and my subsequent exasperation with
  having to track it down and fix it, knowing (and fearing) that hundreds
  of similar printer-control-variable-unaware bugs floats around, was such
  a downer precisely because my expectations are so much higher to begin
  with, but also that somebody else's sense of quality had not produced
  code that was free of this particular "thinko".  It may be like finding a
  dirty fork in a fine restaurant -- somebody did not care as much as one
  had reason to expect.

  This may also explain why some people are so reluctant to use Common Lisp
  functionality that is not part of the language -- because so much of what
  we need is already part of the language.  So Common Lisp gets blamed for
  not being perfect.  The other side of this is that some people are afraid
  to use Common Lisp because they think their code needs to be beautiful
  all the time.  Some people get disappointed when they discover that what
  makes a Common Lisp system is a lot of "dirty" code, interfacing with
  "dirty" operating systems and their "dirty" tricks.  Manufacturing the
  most beautiful things is not at all a beautiful process.  Anyone who has
  ever visited the manufacturing plant for stuff that looks very elegant
  when they are new at the end-user site realizes that the process and the
  result may have radically different characteristics.  Perhaps the strong
  sense of disappointment betrays a lack of understanding of this
  difference and the irrational desire to see manufacturing as elegant as
  the results.  This also applies to code for functions that export some
  beautiful interface, but are quite messy inside because of all the gory
  details they hide from the user of that interface.

  Perhaps there is a psychology of beautiful things that make us fear they
  might break or prove insufficient at close inspection.  If so, it needs
  to get fixed.  How can we do that?

  Travel is a meat thing.