The love affair is over
It's been a while since I've written about coding. Scott Miller told me recently that I could increase my blog readership if only I'd focus, but I just can't seem to stick with one discipline. With game development in the state it's in today, this is okay, as I discuss in the latest Manager In A Strange Land.
So I'm going to write about coding!
I think it was item 50 in The Pragmatic Programmer that said, "Learn a text processing language." I chose to learn some perl, and after I had learnt a sort of pidgin perl I was thrilled - I took on some rudimentary text processing tasks for people in the office (turn this screenplay into a .csv file, rename all the files in this directory) and was impressed with how easy it was to do these tasks. Then I took on a nontrivial task (compare this file with these three files and n sets of directory listings to make sure they match) at which point I required arrays of arrays and the language turned on me. Like the time I dated a hot girl who turned out to be a recovering junkie, what started out great turned into a nightmare. Most popular perl idioms are completely alien to my brain, which has been thoroughly indoctrinated in the structured programming ways of C. Operators that also set the values of global variables...regular expressions which compress a ton of functionality into a single unreadable line of garbled punctuation...defining functions as you need them in the middle of a line of code...arrays of references of arrays...
500 lines of code (a real perl programmer could probably have done it in 50) and a few days later, I did complete the task...and if I had to do it again, I'd still use perl. But the magic is gone, and I wouldn't use perl for anything except text processing. Our automated build scripts are in perl, and I don't like it.
disappointment #2: test-driven development.
I've been trying harder to write more unit tests, eagerly awaiting the time when one of these unit tests is going to catch a bug. I've maybe written a couple dozen of these things. Although they've been useful in helping me write the code correctly in the first place, they have yet to flag bit rot. Just as an example, there's a train that follows a rail in Spidey 2. I wrote unit tests to exercise the follow-the-rail code, and left them in the code to make sure nobody broke it. Recently, we changed the train model, and had trouble exporting it from Max to spec. So I gave up and changed the code to work with the new train. This broke all my unit tests. But now it was the tests that were wrong - not the code. I'm thinking it's likely that most of the time a unit test fires, it's because the assumptions it's asserting are no longer true. I'm not giving up on unit tests yet -- mostly because I get coder-pleasure from writing them -- but they have yet to truly prove their value to me.