Pilgrim’s Progress

I don’t know why he’s always been such a figure of fascination to me. Maybe it’s because my grandfather forced me to watch Firing Line when I was about eight years old. I remember seeing some old guy on the screen talking to some other old guy using words that I could not grasp. He was a truly remarkable man, no matter what you thought of his politics. His collected papers weighed more than 7 tons!!! Goodbye Bill, I don’t know who will use words like perspicacious in casual conversation now that you’re gone.

Apple is finally ready to tell us about the iPhone SDK. Put it on your calendars, March 6th at 10:00 AM PST. If the thing didn’t cost $400+ I would have JailBroken it already. Let’s keep our fingers crossed, and hope that I won’t have to donate a lung or anything to get my SDK license.

Ok, so I’ve been patiently (at least as far as y’all know) waiting for the February iPhone SDK release that was promised last October. Well, here it is February 23rd and no SDK. According to the Businessweek blog it may be 1-3 weeks late. I’ve pretty much exhausted what can/should be done using DHTML and Javascript, and I’m itching to get my hands into the warm, steaming guts of my phone. So to speak.

In my quest for unclear/confusing/just plain bad code, I couldn’t in good conscience ignore my own code. Of course, code I’ve written recently is still too fresh in my mind to be looked at objectively. I would probably still see things now the way I did a few months or a year ago.

But what about code I wrote five years ago? Or more than ten years ago? To test my theory, I’ve started digging up some development projects from the archives so that I can see how my style has changed and also see if maybe some of my code can be of use to someone. I’ve created a new Programming section of my site and I’ve posted up a pretty simple example of my Java programming circa 1997.

The example I’ve chosen to start with is a set of classes for doing DNS queries. It was originally written for a SMTP/POP3 server I wrote in Java. Maybe if I get ambitious I’ll start posting some of that up as well.

There are many things that I’d do differently if I were writing this code today, but I’ll pull out one obvious example to talk about:

283   private void SortRRs(DNSResourceRecord [] arr, boolean fDescending) {
284     if (arr == null || arr.length < 2) {
285       return;
286     }
287 
288     boolean fSwapped;
289     DNSResourceRecord rrSwap;
290 
291     do {
292       fSwapped = false;
293       
294       for (int i = 0; i < arr.length - 1; i++) {
295         boolean fSwap = false;
296 
297         if (arr[i+1].m_iType < arr[i].m_iType) {  
298           fSwap = true;
299         } else if (arr[i+1].m_iType == arr[i].m_iType) {
300           switch (arr[i].m_iType) {
301           case TYPE_MX: {
302             fSwap = arr[i+1].m_lData < arr[i].m_lData;
303           } break;
304           }
305         }
306 
307         if (fSwap = fSwap ^ fDescending) {
308           rrSwap = arr[i];
309           arr[i] = arr[i+1];
310           arr[i+1] = rrSwap;
311           fSwapped = true;
312         }
313       }
314     } while (fSwapped);
315   }
316 

What this subroutine is doing should be obvious to most old-school programmers. Yes, it’s the infamous bubble sort. It’s widely regarded as one of the worst types of sorts available. So why did I use it? Probably because it was easy to remember and I couldn’t be bothered to create the extra class I would have needed to use the built-in Java sort() method.

But, the bubble sort itself isn’t the biggest problem with this code. This code is a victim of excess cleverness, on line 307:

307         if (fSwap = fSwap ^ fDescending) {

When I wrote this code, I was obviously in love with my knowledge of Boolean logic and operator precedence. I wrote this code and it actually took me a minute to decipher what it really meant. Here are some mistakes I made in this case:

1. Inaccurately naming my variables. The fSwap flag actually should be called the fBigger flag. It doesn’t necessarily mean that a swap should happen, it just means that the current array element is “bigger” than the next one.
2. Using obscure operators. Yeah, yeah, everyone should know their XOR truth table, but it would have been much easier to read if I had written (fBigger != fDescending). Not as “cool”, but much easier to decode after 11 years.
3. Unnecessary assignment. I assign the result of the XOR back into the fSwap variable, and promptly forget it. Removing the assignment would have made the logic clearer and saved the initial confusion that some programmers have when they see an assignment in a conditional expression (thinking that the programmer meant == when he really meant =).

All that from one little line of code. So had I written it today, it would have looked something like this:

if (fBigger != fDescending) { .. do swap }

In the long run, overly-clever code really doesn’t save us much. If you don’t believe me, consider what the father of the quicksort algorithm said:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
–C. A. R. Hoare

For our next installment, I’ll probably be tackling one of my other older Java projects, possibly the mail server, or even my Java-based COBOL compiler (it’s a long story).

Good (or bad) code is almost impossible to classify through rigid rules or guidelines. Like Justice Potter Stewart said (in reference to what constituted hard core pornography) “I know it when I see it.”

There are some web sites, such as thedailywtf.com, dedicated to collecting examples of inefficient, confusing, or completely inexplicable code. While they are entertaining to look at, they are so blatant that they are not really a problem in the every-day life of a programmer.

It’s the little things that get you over the long haul. It’s the too-complex method here, the overly elaborate expression there. I went out browsing open-source projects for an example of the kind of thing that makes code more difficult to maintain over the long run and found this in the very first file I saw. I’ve simplified it and removed the product-specific identifiers, to protect the innocent.

do {
    bool res = func();
    if (res) {
       // more processing
    } else
       break;
} while (1);

While being very simple, the choices the programmer made cause it to be difficult to understand at a glance. Here is the equivalent code, using the correct looping structure:

while (func()) {
  //more processing
}

As written, the code is difficult to understand. Why is there an endless loop? Where does the loop terminate? Why? When rewritten using the correct type of loop, its operation is obvious.

Now imagine having to read through thousands of lines of code written like that. It’s difficult enough to understand other people’s logic without the additional stress of deciphering overly-elaborate constructs. Keep it simple.

I’ve been writing code for basically as long as I can remember. I started programming on a TRS-80 Model I in 1982, and I haven’t stopped since. Sometimes people ask me how I did that, how I “made” myself learn to program. I didn’t, it was just natural to me. I’ve never really treated programming as anything special, any more important to me than say reading, writing, or cooking. But it is important. It’s what I do to earn a living, it’s what I’ve spent most of my adult life doing. And for the foreseeable future it’s what I’ll continue to do.

Not all programmers are the same. When I was at Microsoft, I worked with some of the greatest programmers in the world. And the thing about that is that you already have to be a pretty good programmer yourself to even appreciate the difference between a so-so programmer and a super-star. It’s so technical, so abstract that even a so-so programmer often can’t tell the difference between good code and great code. There are certain qualitites that make code great, and even though I tend to appreciate them without conscious thought, I’ll try to list them.

• succinct — All great code is brief. I’m not saying it’s short, but it’s absolutely no longer than it needs to be. If it needs to be 4 lines long, it is. If it needs to be four pages long, it is (but that happens rarely).
• simple — Great code doesn’t require a lot of effort to understand. The logic behind it is explicit. It doesn’t use tricks and shortcuts to make the programmer look clever. You can go back to great code after five years and understand it just as well as you did the day it was written.
• repetitive — Very well written code tends to consist of repeated patterns, with small variations. This isn’t to say that it has redundancies or blocks of cut-and-paste search-and-replace code. But similar tasks are done using similar means, which increases the likelihood that the code will work as designed. If it works once, it works every time.
• fail-safe — Great code degrades gracefully. When abnormal conditions exist, it fails cleanly. This doesn’t mean that it is cluttered with hundreds of assertions and error tests, but it does mean that variables are always initialized to something safe, conditional statements take possible null values into account, etc.

That’s all I have on great code for now. Maybe I’ll go track down some examples and post them with commentary later.

Ok, the best present I (I mean, my kids) got this Christmas was the Nintendo Wii. I’ve become somewhat obsessed with the golf game that comes with it, and right now my best score is 2 under par for 9 holes. I’m planning on making the Wii tour by spring. If you too are a Wii-lover, my Wii # is 3909 5891 5512 2921. Enjoy!

Score one for religious tolerance! The Sudanese president pardoned Gillian Gibbons, a British school teacher who was imprisoned for allowing her students to name a teddy bear “Mohammed”. I don’t know what the big deal was, she only drew 15 days, and she was pardoned after only serving 9. Apparently there were some protesters calling for her to be executed.

I’m not going to pick on Islam in particular. Most religions tend to breed extremism in one form or another. Whether it’s people killing doctors at abortion clinics or flying airplanes into buildings, it’s amazing what people will do when they’re convinced that they are Right. Not just right, but Right. Thankfully, I’m never sure that I’m Right, so my mistakes are somewhat more limited in scope (like choosing the wrong drapes, for example). So I guess I’d better get rid of my toy octopus named Jésus, huh?

Yesterday I went with my friend Joe to see the eponymous movie, which was directed by the Cohen brothers. Starring Tommy Lee Jones, Javier Bardem, and Josh Brolin, this movie was just soaked in atmosphere. Based on the novel by Cormac McCarthy, it’s full of his usual cast of lawmen, outlaws, border rats, and other back-country characters.

A lot of people die in this movie. Or, to put it differently, a lot of people are killed in this movie. I mean an awful lot. And so when I got home my mother asked me how the movie was, and I told her it was great, but she wouldn’t have lasted through the first two minutes. My tastes and her tastes have only the teeny, tiniest overlap, mainly in the area of obscure foreign dramas. She can’t understand the appeal of movies like this (or other great movies like Fargo), because to her the violence and death is only repulsive, never entertaining.

Is it wrong to enjoy a movie like this, which isn’t so much immoral as amoral? I think there are two ways to look at it. One way would be that somehow these movies are abberations, and by making, promoting, and watching them we are somehow encouraging this type of behaviour. Another way to look at it, which is the one I subscribe to, is that by watching these kinds of behaviours, it somehow innoculates us against them in reality. Not that I’m saying that people who don’t watch movies like this will all become sociopathic killers, but maybe by watching we somehow feed that aggressive, impulsive side of ourselves that is best kept locked up.

Either way, if you liked Fargo or The Three Burials of Melquiades Estrada, you’ll love No Country for Old Men.