3. Darn bugs!

Nobody likes to talk about computer bugs. But, unfortunately, you must learn about them and, especially, how to get rid of them.

This lesson is a little longer than the previous ones, but I encourage you to read it completely at least once.

3.1. What is a bug?

The origin of the word bug in computer jargon is often attributed to an actual incident where a moth was found inside Harvard University’s Mark II computer; apparently this moth had caused the computer to stop working. It was found by the team headed by renowned computer scientist, mathematician, and young naval officer Grace Murray Hopper, who went on to invent the concept of compiler languages in computer programming. Dr. Grace Hopper eventually rose in the U.S. naval hierarchy to the rank of Rear Admiral.

The moth was preserved, taped into Hopper’s log book, as shown below. Interestingly, the log book included a note saying, “First actual case of bug being found.” as you can see.

Picture adapted from the public archive of the U.S. Naval Historical Center

Actually, the word bug in a technological context is attributed by the Oxford English Dictionary to Thomas Edison. According to the Oxford Dictionary, the following text can apparently be found in the March 11, 1889 edition of the Pall Mall Gazette:

Mr. Edison, I was informed, had been up the two previous nights discovering ‘a bug’ in his phonograph - an expression for solving a difficulty, and implying that some imaginary insect has secreted itself inside and is causing all the trouble.

It thus appears that the original ‘bug’, though it was indeed an insect, was in fact imaginary.

Unfortunately, computer bugs, while they are not insects, are also not imaginary.

3.2. Dealing with bugs

In computer jargon, a bug is an error that causes a program to behave in an unexpected way. If you are writing computer programs, you are going to have bugs in them sooner or later - everybody does. Good programmers seek to “remove” bugs or “fix” them as soon as they find that their program behaves unexpectedly.

Not so good programmers state that “bugs” are not really bugs but that they are “features” of their programs. You are going to be a good programmer, unlike the maker of Reeborg, whose program is littered with bugs.

Reeborg, full-scale (New Jersey, USA)

Courtesy picture of A. Judkis.

1. Reeborg has an oil leak. Oil leaks are damaging for the environment and inconvenient for Reeborg who must replenish its supplies when it’s not busy accomplishing tasks. The maker of Reeborg claims that it is a feature, as it enables you to follow Reeborg’s path, just like any programmer can learn to “trace” a program. You will learn how to fix Reeborg’s leak later. More advanced techniques to trace bugs, like using what is known as a debugger, are beyond the scope of these lessons.
2. Reeborg’s steering mechanism is not handled properly by Reeborg’s program: it can only turn left. The maker of Reeborg, once again, claims that this is a feature as it present you with an opportunity to learn about functions. Reeborg disagrees. You will soon learn how to program a workaround solution, enabling Reeborg to turn right, although in a wasteful fashion. Much later, you will learn how to truly fix Reeborg so that it can turn right just as easily as it can turn left.
3. Reeborg has a compass, enabling him to determine which direction he is facing. Unfortunately, yet again, the program that enables Reeborg to get the information from the compass has a bug: it only tells Reeborg if he is facing North ... or not. Once again, you will first learn how to implement a workaround solution and later how to fix permanently Reeborg and get rid of what its maker calls a “feature”.
4. Reeborg can see if a wall is in front of him, and can also turn its head to the right to see if there is a wall there. However, a software “glitch” (which is another weasel term that software manufacturers use to avoid having to say that their product has a bug) prevents Reeborg’s program from properly registering a wall when it turns its head left.

Sometimes to find the cause of bugs, it can help to break the normal flow of the program. To this end you may do one or more of the following:

1. You can pause a program as it is running by pressing the pause button. This is similar to what people refer to as setting a breakpoint in a computer program
2. Instead of actually pressing the pause button, you can type in the instruction pause() at any point inside a program and Reeborg will pause, awaiting your permission to continue.
3. You can step through a program, one instruction at a time, by pressing the execute one instruction and pause, or step button. By default, the line about to be executed is highlighted; you can turn off the highlighting by clicking on a button above the code editor.
4. You can change the speed of execution (the time between two instructions) at any point inside a program; I will explain how you can do this later.
5. You can have Reeborg write some information at any given point inside a program; again, I will explain how you can do this later.
6. Finally, you can stop a program at any point by pressing the stop button; this unfortunately may not work if you create what is known as an infinite loop, outside of Reeborg’s control. If worse comes to worst, you can always just reload the web page.