Monday, May 23, 2005

Comprehension

“In general whatever you’re trying to learn, if you can imagine trying to explain it to a computer, then you learn what you don’t know about the subject. It helps you ask the right questions. It’s the ultimate test of what you know.” -Donald Kunth


I didn’t get a lot of reading done this weekend, but I did run across that quote in Out of their Minds. In my first CS class, as I have mentioned before, we were programming in Scheme. Each exercise was completed according to a recipe. These recipes were outlines that would help beginning students get into the mindset of problem solving. Each function that we would program followed a form like this:

- Contract (what are the pre and post conditions)
- Purpose (what is the function supposed to do)
- Example (what would a sample call to the function look like, and return
- Definition (the actual code)
- Tests (tests the definition at least against the example to make sure it works)

The above recipe came from How to Design Programs. As the book continued and examples became more complex, additional steps would be added. For each function that we programmed, it was required that in comment form each step of the recipe be explained in the context of that function. This relates well to Kunth’s quote as it adds formalism to the idea that one must really understand that which he is trying to program before he commits it to code. My introductory CS professor called this the “domain knowledge”, and stated that it was important to understand what it is we were dealing with before we jumped off to try and make a program to do it for us. It is a sound idea.

Computers are only as smart as the people who program them. They do exactly what they are told. This is why programming languages are so precise. Though we try to escape the binary, and abstract away notions of assembly, they are still there at the heart of computing. In order that we produce useful programs that accomplish real world tasks it is critical that we understand what it is that we want the computer to do, and that we understand at some basic level how the computer does it. Granted, this advice may not apply to the end user. Certainly, every user of Microsoft Word doesn’t need to understand how the dynamic spell checker works. Yet, for the programmer who implemented it, he needed a solid grasp of the big picture.

In my Linear Algebra class last semester, we were charged with programming a simple MatLab function that would calculate a least square solution two different ways. I remember thinking that I understood how least square solutions worked, until I sat down to formalize it into a function. Though this is a simple anecdote, it is an example of Kunth’s quote come to life. I had to go back to the book to really understand the algorithm for calculating a least square solution before I could even hope to tell the computer how to do it.

The whole purpose of this short essay may seem trivial, but I can’t tell you how many times I have seen programmers hack away at a problem without taking the time to try and understand the basic underpinnings of the problem they are trying to solve. I am not an expert, but the quote above really made an impression on my mind. As I have been reading Out of their Minds, the common thread is that each of these early computer scientists saw something that they thought that they could improve, and by working to better understand that area, discovered something that forever had an impact upon the way we now understand computing. Had these men not endeavored to understand how to “explain it to the computer”, the world today would be a vastly different place.

No comments: