Abstracting programmer behavior

While I was waking up this morning, I had a sudden insight. Like most half-conscious insights, this one is only partly baked--but I thought it interesting enough to share it anyway.

Usually, we think about abstraction of program behavior. Sometimes, however, it can be useful to form abstractions of programmer behavior.

One example should be fairly well known: When offered a variety of options, most programmers will choose the default most of the time. We learn from this behavior to take care that defaults will be usable most of the time; if we can't think of a default that is usually the right thing to do, it is better to force the programmer to make an explicit choice.

A design example that follows from this phenomenon: If the default action after detecting an error is to ignore it, most errors will be ignored. It is this observation that led to the design of C++ exception handling--specifically, the idea of signaling an error in a way that can be handled, but for which the default is to behave in a way that is difficult to ignore.

I welcome comments about other examples of behavioral abstraction.

Posted by Andrew Koenig at 11:24 AM  Permalink