|   Sorry, its been 15 years since I programmed in LISP.

that may explain why you didn't do this:

    (if (< (+ a b) 5)
        (setq a 1)
      (setq b 1))

but even this is not the best use of LISP.  different languages, different
concepts, and different expressability.  if you try to write FORTRAN in
LISP, it will look less pretty than FORTRAN, and FORTRAN will "win", but
try to write LISP in FORTRAN, instead.

|   The principle of a programming language being mostly readable by a
|   reader not familiar with it.  Programming is a difficult enough job as
|   it is - why make it harder by using languages that are hard to read?

why do you want to optimize for irrelevant people?  "a reader not familiar
with" a programming language is either not someone you want to read your
code, or he will become familiar with it shortly if he isn't.  programmers
have to be able to express themselves in a language, and that is more than
just "familiarity".  readability is a factor of many things, but common to
all is familiarity.

|   Here's kind of a twisted example, but heck, maybe someone out there can
|   help me with it. I've written a MUD system at home (if you don't know
|   what a MUD is, just ignore this), and one day I thought it would be
|   K00L to put a variant of "Eliza" or "Doctor" into it. I think all the
|   needed facilities are there. So, I grabbed the only version I had
|   around - that for GNU-Emacs ELisp. I have yet to be able to figure out
|   just what it does. This is precisely what I mean - if I can ever
|   convert it to my MUD system (a language along the lines of the first
|   one above), I would hope that it would be much more readable. Anyone
|   got a version that I can understand?

it's a twisted example, all right.  with languages come concepts, and if
you don't know the concepts, no amount of readability will help.  the
belief that one can "read" simple code (e.g., C) because the operations are
simple is erroneous.  you need to understand _why_ something is done, not
just _what_ it does.  you reimplement the _why_, not the _what_, anyway.