Debugging code is an activity that shows a lot of the developer’s personality. It is a process that looks a lot like an investigation, leading to the detection of a failure in an application.

During the investigation, a programmer has to employ some techniques, like information gathering, testing of hypothesis, performing quick instrumentation, etc.

When it comes to learning how a program works, though, there are two main “schools” of debugging: the ones that use print statements, and the ones that use a debugger.

Print Statements

From these two techniques, certainly printing is the most “primitive”, in the sense that it is available in almost any programming environment. As long as there is an output device (which doesn’t need to be the screen/stdio), this technique might work.

The advantage of printing statements is that they are easy to use and program. They also don’t require the program to slow down in order to be used. For example, when working with multithreaded code, printing may be more useful than debugging, because it doesn’t require one or more of the threads to slow down.

Interactive Debuggers

Using a debugger, on the other hand, is not a privilege for everyone. There are many platforms these days with very decent debuggers; however there are still lots of environment that don’t have one.

For example, I remember reading somewhere that Linus doesn’t create a debugger for the Linux kernel because he thinks it is not important.

Despite the rant, it is  nice to have a good debugger available. Depending on the quality of the debugger, it can do some things that would be possible only on dynamic languages. Things like changing the value of variables during a debug session, or going up in the call stack and repeating some code path, can be very useful when determining where a bug is hidden.

I personally like debuggers, but agree that they should not be an excuse for sloppy thinking. Some programmers believe that is normal to use debuggers to poke at a program, instead of stopping and thinking about what the application is doing.

I like to keep in mind that debugging is a research exercise, and it works much better when we use our head more than the debugger.

Modern IDEs have very sofisticated interfaces to allow code navigation and editing. Although these facilities are very useful (specially when working with external libraries), there are somethings that are just easier to do in more traditional editors, such as UNIX ed.

One of these things is keeping the context of several parts of your code. I learned this kind of trick a few days ago when working with a large source code file.

Simulating Literate Tools
A similar tactic is used by people who use Literate Programming.

Literate programming is the methodology of software development where documentation and coding are done at the same time. Moreover,
in literate programming documentation drives the development. The main idea is that programming should be similar to writing, in the sense that code should be entered only when we describe how it works.

To make literate programming work, we need a system that can move code from the place where it is written to the place where it needs to be used.
For example, if we define how a variable is used, we might need to define in one place, and write the code in another place, depending on how the language treats the initialization of variables.

One way to do this is using the “tangle” program in the standard TeX distribution. The problem with this solution, though, is that you need to write your code in a completely different format, which is hard to use with other development tools.

An option to this style development method is presented by the use of the ed editor. The great advantage of ed over other editors is that it works with regular expressions, and only the current line is of interest.

Thus, you can mix different lines when working in the same document.

For example, suppose you are writing a function. One way of simplifying the task of writing the program is keeping a marker for the end of variable definitions as well as a marker for the current code position. With ed, you can move between these positions using the quote command (‘).

Thus, if you have markers a and b, you can just do: ‘a to move to the code definition part, and ‘b to move to the coding part. If you are defining some code that will use a variable, you can just move between these markers. It is a very simple operation that makes it much more convenient to write code. This can be used with language such as C++, where member functions have to be listed in a class declaration as well as an in the body of the source file.

C++ is a multi-paradigm programming language. This means that there is no single style that is always the right one to use on C++ programs. It all depends on the task at hand. For example, it is completely fine to use C++ only as a structured language, since it has all elements of C and a few more that make structured programming even easier in C++.

The main style of use of the C++ programming language is the classic object oriented style, since it is a style that is easier to reconcile with business practices that have been developed in the previous years.

However, not every project can be done with class object oriented methods. Sometimes it is more productive to use ideas developed in other programming traditions, such as symbolic, functional, and dynamic programming. C++ can also do this, but it needs a little additional thought from the part of the program designer.

The book Advanced C++ Programming Styles and Idioms discusses several idioms that can be successfully used with the C++ programming language.

Many of these idioms are not mainstream, and some of them may not be even acceptable in your organization. Despite this, these idioms could just as well  be the tool of choice for specific problem domains.

Dynamic Features in C++
Among these idioms, are techniques that have been used for a long time in dynamic languages such as Smalltalk and Lisp, such as dynamic dispatching, symbolic computing, and related techniques.

The author, James Coplien, describes how to implement object orientation based on exemplar objects, instead of class based objects. In examplar-based programming, one uses objects as the foundation for creating objects, instead of using classes — as is the normal practice in C++. One of the keys for doing this is to use factory methods to create new objects, instead of using the new keyword, which by definition requires knowledge about the specific class of the created object.

Another strategy is to use Envelope objects, which provide some of the functionality of symbols in a language such as Lisp. Using Envelope objects, one can have automatic memory management through reference counting, and a clean separation between a value and the label that contains it.

Coplien describes how to create more dynamic objects by avoid the classic hierarchy-based approach for classes. He proposes two main solutions for this problem: in the first solution, one creates a shallow hierarchy, where each class has all possible methods that could be implemented by subclasses. In this approach, each object is always crated using the interface of the parent class, and implements only the methods that are of their interest. Subclasses rely on polymorphism to receive the correct messages, and send an error whenever they don’t respond to a particular message.

This technique has the great advantage that clients don’t need to know exactly what class is being called. Also, since the differences between objects is now based only on what methods they respond to, the system is now based on generic methods, rather than on specific classes. Any class can override any method of the top class, which makes it easy to supply dynamic behavior.

The drawback of the previous approach however is that, unless we known all methods that are of interest, the system is subject to recompilation whenever a new method is added to the parent class. To avoid this problem, one can go one step further and create a dynamic dispatch system. In such a system, there is just one method to which an operation descriptor is passed, followed by a number of parameters. In this way, easy concrete subclass can add as many operations as necessary, without any change to the parent class. While such a system may not perform as quickly as a statically defined dispatch method, it is much more flexible, and allows the system to evolve without recompilation.

Finally, the books discuss how to load code dynamically, and therefore avoid linking. The approach works on most systems, however it is machine and compiler-dependent, so it should be used with care when portability is of importance for the system.

Further Reading

Check Advanced C++ Programming Styles and Idioms at Amazon.

Some time ago I wrote about the sam text editor, a UNIX text editor that incorporates many features that are cherished by UNIX users, such as regular expressions and programmability.

It turns out that many of these features were already present on the standard UNIX editor: ed. For many, it seems crazy that one might want to edit text in an editor that is not screen oriented, and is capable only of showing individual lines. However, sometimes this is not only OK, it is even desirable.

The most common case for me is when I am on a UNIX command line. Frequently there is a small change that needs to be performed to a file in order to continue. For example, this happens most of the time when I am compiling code with gcc or some other compiler that I might be using at the moment. After a compilation error happens, the compiler will say exactly what file is the culprit, and at what line the problem occurred.

The common UNIX user will then start their preferred screen-oriented editor to make the change. This can be one of vi, emacs, gedit, eclipse, or whatever editor you may be into. Then, after the editor starts (which, depending on the program, may take a few seconds — or minutes if it is eclipse), you need to locate the line reported by the compiler, and make the necessary change.

The point is that you don’t need to have access to the whole file to make this simple edit. You just need to see one line of the file. An editor such as emacs or vi will do the work, but it can only make it more confusing, by displaying all the other lines that you don’t need.

With ed, you can just type ed followed by the name of the file: ed will start immediately, since there is no UI to wait for. Finally you type the number of the line followed by enter, and the desired line is displayed. It is now just a matter of using a single command to change the line (either s or c, depending on the kind of changes you want to perform).

Another situation where ed is really useful is when you just want to add lines, either to the end or the beginning of a file. That’s another case when it doesn’t matter that you have access to a screen-oriented editor: you just need to enter text into a very specific point of the file. What you can very well do in this case is to forgo the screen editor and use ed to add as much text as you want to the beginning (using 1 followed by i) or end (using the “a” command).

So, you see that using ed has a lot to do with the way UNIX systems work. You always want to use the tool that is most efficient for the task at hand. If the task is simple, the best way to do it is using a simple tool such as ed.

When I am writing, one of my constant quests has been to find a good editor where I can not only write but also organize my ideas. As strange as it might think, my best solution up to now has been not a text editor, but a presentation software. Yes, that is true, I use power point to write text.

One of the things that many users don’t know is that power point can also be a decent text editor and, in some respects, even better than Microsoft Word — just change the font used to “Times Roman” 10pts and you’re ready. There are some reasons why I think it is easier to edit large documents using power point than Word.

First, it provides a clear distinction between pages. Each page is a “slide”. You can create as many pages as you want, and they are independent of each other. You can move then around, and the content will also move around.
It is just like having old and trusted pages of paper.

This solves a major organization problem. When I edit a long text document, sooner than later I have problems with keeping information around. Where to put summaries, plots, notes, research, and many other things I need?

Clearly, one can create separate files for each document, and use a complicated directory structure to keep things organized. Whatever you do, at the end it is always confusing to keep your many ideas in a logical shape.

For example, if you have a new idea you would later want to incorporate into a document, where are you going to write it down? Simple: create a new slide to store it. An individual slide then becomes something hybrid between a file and a page of text. But you don’t have to go through the hassle of creating a new file, everything is stored in the presentation. When you run out of space in one page, create another one. It is as simple as that.
In the end, you are going to have as many sections in your document as you want, and they can be organized easily. You can move then around in the sorting order, and delete the ones you don’t want.

For example, I use the structure of power point to do several things. If I am creating a blog, I use each slide of the presentation to store one post. The slide contains roughly the size of a blog post, so I know that I should keep just one page per post, and the number of pages is the number of posts.

When writing a book, I use a power point file for the whole project, and each slide is a page. Then I use the summary tools to determine what I’m going to write in each page. It is the easiest way I have find to organize my writing — no more papers or simple notes left around.