One Compile A Day

A recent blog post by Ian Bogost (The Virtues of Long Compiles) has me thinking once again about the trouble with fast compiles. How would you program differently if you could only compile your project once an hour or perhaps once a day? Actually its more complicated than that. What would you do between compiles? Would you work on other programs or perhaps new modules for the compiling program? There are risks associated with working on modules that have to work with code that hasn’t actually been tested yet. Would you read the manual or textbook looking for new ideas? (That is one thing that comes up in Ian’s post BTW.) This is a hypothetical or theoretical question for most students today. For some of us old people it means trying to remember how did we do thing back in the day of card readers and line printers.

The first thing I remember is that I put a lot more thought into the code before I hit the compile button. Well actually before I gave the operator my card deck. Smile I didn’t compile after each syntax error was corrected for example. Or even some few number of them. I tried pretty darn hard to identify and correct each syntax error that the last compile had reported. The trick here is that one really had to understand what the error was. There was no time to try random changes and see if they worked. One did some analysis and you were always looking for the one fix that would correct several (or many) errors. Forgetting to declare variables was a killer. Today good IDEs (well Visual Studio which is what I use for most everything) help with the syntax errors are you type. Once doesn’t always have to run a full compile to catch the missing variable declaration for example. That doesn’t mean that errors that are a combination of syntax and logic such as bad assignments with mismatches of type always get caught of course. But one doesn’t have to wait for a long compile to catch most syntax errors.

With long wait times between compiles there was also an incentive of sorts to write as much code as possible before submitting to compile. This is not so much a good thing. It is much easier to debug a small piece of code than a large complex piece of code. On the other hand you really wanted to make sure your logic was sound, your interfaces clearly defined, and expectations well mapped out. This may be a win for the fast compile crowd in the long run but I’m open to opinions.

Once one handed in their card deck to the operator there was time before you got the results. Depending on that facility or school that could range from under an hour (the small liberal arts university I attended) to the next day sometime (the larger NYC university my wife attended). So what to do? Sometimes that was time used to prepare test data for when you did get a clean compile. Sometimes it was spent going over the assignment and seeing if anything was missing. Sometimes designing yet another module. Often it was in discussion with others waiting for their run to return. Still other times it was on to some other project for some other subject entirely. In some ways that mental break was a good thing. All in all one did learn some patience. Patience is a noble and necessary virtue for software developers – and other people as well.

The instant edit, compile and run cycle of modern high speed compilers has changed the way we develop code. In many ways for the better but in the process I sometimes fear we have lost something as well. Patience, careful consideration, attention to detail, and maybe solid planning. Back in the card punch days we saw more women in software development than we do today with the fast edit/compile/run system. Coincidence? I wonder. Does today’s way lend itself less to the way women work than the “old way?” I have no idea. I know of no study. But it is something I just happen to wonder about.

[EDIT: See also Eugene Walligford's blog post at "I Love The Stuff You Never See"]