Subject: Re: image vs source
From: Erik Naggum <>
Date: 08 Dec 2002 21:57:47 +0000
Newsgroups: comp.lang.lisp
Message-ID: <>

* Peter Seibel
| But the old fooo is still in the image

  Why do you believe this?

| This is obviously a trivial example of a more general problem: how
| do you know that the contents of your image bear a predictable
| relation to the contents of your source file.

  This more general problem is known as "the problem of sanity" in
  the real world.  The solution is not to be found in the particular
  discipline, but rather in repairing your sense of loss of control
  (and predictability) of your environment.  Such sense of loss of
  control is a major component of fear, and it can remain and fuel
  more fear a long time after the initial feeling of loss of control.
  Some people make up their mind that they not trust an environment
  because they get burnt by a mistake that they strongly feel should
  not have caused them any harm.  This belief is at the core of their
  future susceptibility for loss of control, since they have ceased
  to believe that they have full control to begin with.

  To fix this problem, which is actually very common and occurs in
  everything from ablutophobia to zoophobia, one has to examine what
  caused the initial feeling of loss of control, demonstrate or have
  demonstrated that one may yet regain control of the situation.  The
  problem with these irrational fears is that they are unassayable if
  their core premise is not addressed.  In the case of programmers
  who have an abnormal fear of losing control if they make a mistake
  in their computing environment, nothing whatsoever can be done to
  address this particular fear if the person who wants to help them
  does not understand that the problem is loss of control; it serves
  only to aggravate the fear if the person who intends to help shows
  great dexterity and foreknowledge of the machine's reactions, as
  this is unattainable magic to the person who feels out of control.

  More often than not, the feeling of being out of control when using
  a computer is caused by lack of concentration, attention to detail,
  but some people get this misguided idea that the computer "ought"
  to do what they want, and that is a serious handicap as they become
  angry at the computer instead of making an effort to understand
  what it actually does.

  So what do other people do when they have made mistakes?  They do
  one thing that those who repeat their mistakes because they think
  are /not/ mistakes do not: They /listen/ carefully to the computer
  and pay attention to how it responds under different stimuli.  The
  only way to learn what the computer (that is, the programmers of
  the application you are using) think is right, is to accept that a
  computer, to be commanded, must be obeyed.  (Thus, no difference
  from anything else.)  The right way to command a computer is to
  obey it every single step of the way to changing its behavior.  For
  some reason, many people believe that they can somehow command a
  computer like a human being, that it kindly fills in the blanks in
  your commands.  This could be because most programmers have yet to
  spawn children of their own, do not have time for a dog, and do not
  even have cats.  Most adults are exceedingly willing to entertain
  their own assumptions when you give them insufficient information,
  but children and dogs and cats and computers need to be given the
  full set of information in their current context and you need to
  keep track of the context.  The reason many users seem to prefer a
  graphical user interface to a textual is that they may believe that
  more information about the context is available to them, but they
  limit the useful context to that which is visually apparent -- what
  you see is all you get.  It may be hard to keep track of everything
  the system "knows" at any given time, but the alternative to having
  to synchronize the computer with your mental image of it is to be
  given a completely /overwhelming/ visual status report unless you
  are satisfied to be constrained to believe only a subset "exists".

  Most Common Lisp environments provide some means of easily undoing
  definitions, if not a fully general "undo" mechanism.  The language
  sports functions like `makunbound´, `fmakunbound´, `remove-method´,
  `slot-makunbound´ and even `setf´ of `find-class´ to nuke the name
  to class association, as well as `delete-package´.  Other functions
  also undo various other operations, such as `unintern´.  You should
  investigate and familiarize yourself with these functions so you
  know how to clean up after your mistakes.  One of the reasons to
  develop your code in their own packages is that you can delete them
  and re-load them from the compiled sources.

  What most Common Lisp environments do not provide, however, is the
  previous value of something they are more than happy to overwrite.
  I miss a transaction facility where I can make a number of changes
  to the system that are only visible to my thread of a multi-threaded
  execution environment and then discard them or commit them all at
  once.  E.g., loading a file could be such a transcation.  Signaling
  an error during loading could cause the whole slew of operations
  that preceded it to be discarded instead of leaving the system in a
  partially modified state.  This is not impossible to build on top of
  the existing system, but it takes significant effort, so it is the
  kind of thing that Common Lisp systems programmers should do.

Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.