Creating programs is just part of being a programmer - the other big part is the act of debugging and yet we rarely consider it as an important skill - and yet it is.

The Trick Of The Mind - Programming & ComputationalThought

Buy Now From Amazon

Chapter List

1. The Trick Of The Mind

2. Little Languages
      Extract: Little Languages Arithmetic

3. Big Languages Are Turing Complete

4. The Strange Incident of The Goto Considered Harmful
      Extract: The Goto Considered Harmful

5. On Being Variable  

6. Representation

7. The Loop Zoo
      Extract The Loop Zoo
      Extract Advanced Loops ***NEW!!

8. Modules, Subroutines, Procedures and Functions
      Extract Modular Programming

9. Top-Down Programming 

10. Algorithms
       Extract: Binary Search 

11. The Scientific Method As Debugging 

12. The Object Of It All
       Extract Why Objects 

 <ASIN:1871962722>

<ASIN:B09MDL5J1S>

So far we have succumbed to the programmer’s conceit that every program is constructed correctly, even it if takes a few attempts at refinement. This is, of course, far from the truth. Programs are always faulty and there are always bugs. Even after you think you have finished constructing a program, it isn’t finished. There is the task of correcting the inevitable bugs.

The term bug when used to refer to a problem in a program hasn’t got a certain origin, but the first recorded use to mean something not working is credited to Thomas Edison. In a letter in 1878 he wrote:

“You were partly correct, I did find a ‘bug’ in my apparatus, but it was not in the telephone proper. It was of the genus ‘callbellum.’ The insect appears to find conditions for its existence in all call apparatus of telephones.”

The use of the term in computing goes back to the early days and was probably borrowed from general engineering, but one incident that is well reported is the day Grace Hopper (the inventor of Cobol) found a moth inside the Harvard Mark II, an early (1947) electro-mechanical computer. She found a moth-like insect that was stopping a relay from working and stuck it in the machine’s log book with the annotation:

“First actual case of a bug being found”

It is clear that Hopper was already familiar with the idea of bugs in programs and was amused to discover a real one. To this day bugs are an ever-present problem, even if they aren’t creepy-crawlies.

How do you debug a program? What approaches and qualities of mind are needed to get the job done? In many ways debugging a program is quite different from the act of programming and we need to be clear about it so that we can both do it better and teach it better. The skill of debugging is also generally applicable to the non-programming world. It is a form of analytical thinking that is typified by the scientific method. So learn to think like a scientist via algorithmic thought.

Debugging by Programming

As is the case with programming in general, some programmers aren't very clear about what skills are important in debugging a program. It is a common misconception that debugging is just programming, but getting it right rather than wrong.

In fact debugging is quite a different skill. If you are a programmer, you will know that this is true because you will be familiar with the way your mind changes the way that it works when you switch from programming to debugging. It is like a transition in a stick-shift gearbox.

When you are programming you are taking an algorithm, a process, and converting it into the static text of a program. You are performing the dynamic-to-static transcription. When you read a program to find out what it is doing you are doing the reverse – taking a static text and giving it a dynamic life of its own. You are performing the static-to-dynamic transformation.

When you are confronted by a program that isn't doing what it is supposed to, even if you have just written it, your understanding of the program has to change. It isn't the program you thought it was. The text expresses a process that isn't the one you were trying to render. If it was then it wouldn’t be misbehaving and there would be no bug to find. You could just start over and attempt to render the process into static text a second, or third or ... time.

Notice that you don't have to actually start over from scratch. In most cases what happens is that you mentally try to re-create the program while reading what is already there. By comparing your re-worked version of the process with the existing text you can often spot simple errors. This is the first level of debugging and it tends to find the easiest bugs. These can be thought of as the first level of bugs found using the most basic and brute force debugging approach.

The big problem is that you are often so close to the program you are trying reprogram that you simply keep repeating the same mistakes based on the same misconceptions. It is a good idea to try to put some distance between you and the program before trying to rewrite it. Either that or try to get someone else to program it.