Lisp is influencing the way I write C++ in a few different ways.

To Generalize…

Imagine my horror: Lisp caused me to realize that I’ve been refactoring the wrong way! For a few years!

Well, that is not entirely accurate. My code did the same thing after I was done. I broke code down into small logical units. Unless I was careless, the code still worked. My functions were more readable, and one could usually see what they did at a glance.

I asked myself questions along the lines of, “What can I do to break this up logically?”, and therein lies the problem:

Weak questions have weak answers.

Powerful questions are much better suited to refactoring!

• “Can I use an existing solution to solve this?”
• “Could this solve a completely unrelated problem?”
• “Can I rearrange things elsewhere so that this code isn’t even needed?”

Sometimes, the answer is no. Some boilerplate code (like exception catching) is an overhead that can not be avoided, can not usually be generalized, and sticks out like a sore thumb in C++ style languages.

Why did Lisp fundamentally shape my refactoring practices? Paul Graham and Peter Norvig are both to blame for this, and for different reasons.

First up, Graham. I taught myself from “ANSI Common Lisp“. At first, I attacked the problems in the book from a C++ perspective, trying to wedge loops and functions into my solutions. Doing the Lisp examples forced me to think simpler. Within a month I started being able to think of functional solutions instead of C++ solutions (reaching for reduce and lambdas instead of loops and classes).

I worked problems out of this book every night for a month and a half, and it still sits next to me as a quick reference. After 8 years of C++ programming, it took a while for things like “reduce” to become the most obvious solution to a problem.

I haven’t reached that magical enlightening moment that Lisp causes. I don’t have the “ooh, shiny!” awe over macros that seasoned Lisp programmers seem to have, so I’m still hacking away.

Norvig has sent me towards enlightenment with Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp. In these pages, I found something that was missing from Graham: elegance

Some of the solutions that I see in this book give me a sense of awe and enlightenment that I haven’t had since I took Abstract Algebra. He presents them in a very straightforward and honest style that can only come with experience.

This book has given me a whole new level of quality to try to reach. I hope one day to be able to do this.

Tools

A year ago, I would have described my programming process like this:

1. Design
2. Code + document
3. Neaten + prune
4. Return to 1, as needed

Not bad. However, working with Lisp and seeing that there are different tools in the world has led me to fundamentally restructure how I program. I would now describe my process like this:

1. Design
2. Code + document
3. “Would a tool/function/class have made this task easier?”
4. Return to 1, as needed.

For instance, I’m writing some image processing libraries in CL right now, and I’ve written a few tools that I might never have thought of generalizing from a pure-C++ mindset! After all, iterating over an image is really easy in C++, so why bother making it simpler?

However, map-image is invaluable: apply a function at each pixel of an image, and return a new image. Combine this with the lambda construct, and you have a level of flexibility possible only with some of the goofier Boost libraries.

In Short…

While working through the Graham examples, I found that I was playing Code Golf against myself.

I’ve started to see this carry over to my coding at work as well. In the past, I might have done something like the following:

int num_times = SomeFunction();
 
return AnotherFunction(num_times);

This is a reasonable approach. The local variable name reflects the role of the function, and adds a little bit of clarity for the human reader. Using this style is fine if these are your priorities.

However, I’ve started giving functions better names (when I can), and cutting out the middleman:

return AnotherFunction(NumberOfTimes());

This is effectively the same code, and there’s a good chance that it would compile down to the same assembly language. It’s just as readable. The difference is the line count. It’s a difference small enough for a bikeshed issue holy war, but over the course of small projects (all I’ve done so far in Lisp), being able to fit more code on my screen is a big win for me (all else equal).

I am starting to prefer reading and writing compressed code as a result of trying to solve Graham’s examples in as few lines as possible.

Future Directions

I’m still looking for my “Lisp Enlightenment” with respect to macros, which leads me to believe that there’s something significant that I’m still not getting about Common Lisp. I’m not sure where all of these new techniques are going to lead me, but in the meantime, it is starting to fundamentally change how I approach programming problems.