Subject: Re: image vs source From: Erik Naggum <erik@naggum.no> Date: 08 Dec 2002 21:57:47 +0000 Newsgroups: comp.lang.lisp Message-ID: <3248373467280622@naggum.no> * 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.