SELECTIVE IGNORANCE

Finding the Signal in the Noise

One of the loudest criticisms I hear about C++ is that it doesn't have garbage collection. In other words, whenever a program allocates memory, some other part of that program has to figure out when to free it.

Of course, that figuring out can often be automated. As an obvious example, every standard-library container class keeps track of its own memory and frees it as needed. Nevertheless, it is hard to resist the belief that automatically freeing memory would make life a lot simpler for C++ programmers.

Continue reading "Automatic memory management -- no panacea"

Posted by Andrew Koenig at 11:17 AM  Permalink |

When you find that your code's behavior doesn't match the documentation, which one do you change?

Continue reading "When code and documentation disagree"

Posted by Andrew Koenig at 11:45 AM  Permalink |

There is a school of thought that says that when you set out to write a program, you should write the tests first. Your goal is then to write the simplest program that passes the tests. Once you have done so, you're done.

This approach is certainly appealing. In particular, having automated tests that capture as much as possible of a program's desired behavior is an excellent idea. But what if a program has to have a characteristic that you don't know how to test?

Continue reading "The trouble with testing"

Posted by Andrew Koenig at 10:06 AM  Permalink |

I was just reading an article on the website of a major newspaper that I'd rather not name. I finished the first page, clicked on the second, and got:

    Sorry for the interruption.

    Hello! You have been chosen to participate in
    an important survey from <name deleted>, a
    respected 3rd party research company.

    This is for RESEARCH PURPOSES ONLY.
    We are not selling anything. Your answers are grouped anonymously.

followed by "yes" and "no" buttons.

Continue reading "Another bug that should never happen"

Posted by Andrew Koenig at 12:21 PM  Permalink |

A strong influence on how I think about programming is a 1971 book by Edsger Dijkstra named A Discipline of Programming. Most of this book is a series of elegant solutions to simple problems, but parts of it are philosophical essays, some of which have stuck with me for the more than 35 years since I've read them.

Continue reading "Computers versus programs"

Posted by Andrew Koenig at 11:25 AM  Permalink |

A well known software design principle is "Divide and conquer"--the notion that by dividing a large problem into smaller problems will yield a solution where the overall problem might be too hard to solve. This strategy is often combined with recursion. For example, one widely used sorting algorithm is to divide the data to be sorted into two approximately equal pieces, sort each piece, and finally merge the two sorted pieces.

However, sometimes the division doesn't have quite the intended effect. Each individual piece of the problem might be solved correctly, but combining the solutions yields a surprise.

Continue reading "Divide and botch"

Posted by Andrew Koenig at 10:00 AM  Permalink |

We have seen that it's not easy to collect several players into teams that have well-defined strength. Such surprises come up even when we're not dealing with teams. Indeed, they happen even in seemingly straightforward situations such as elections.

Continue reading "Least surprise in elections"

Posted by Andrew Koenig at 02:48 PM  Permalink |

Now that we've seen how trying to combine plausible-sounding rules can surprise APL programmers, let's look at a more mundane example: a tournament to find out which of several teams is the strongest. We shall learn that it is hard to avoid surprising results, even in simple cases.

Continue reading "Least surprise in tournaments"

Posted by Andrew Koenig at 02:26 PM  Permalink |

It's hard to study software design for long without coming across the principle of least surprise, sometimes called the principle of least astonishment. Both terms refer to the idea that a system should cause as little surprise as possible for someone who doesn't already know how it behaves.

This idea is a good one most of the time. However, sometimes there is a good and simple reason for behavior that is surprising at first glance. In such cases, following the principle of least surprise may introduce extra complexity into the system and make its behavior more surprising in the long run.

Continue reading "The principle of least surprise can be surprising"

Posted by Andrew Koenig at 10:39 AM  Permalink |

Experienced programmers usually think that warning messages from compilers are a Good Thing. After all, such messages let us know when we have written programs that might not do what we expected, and sometimes save us from hours of debugging.

Continue reading "The hazards of warning messages"

Posted by Andrew Koenig at 11:36 AM  Permalink |