One Compile A Day

Computer Science Teacher
Computer Science Teacher - Thoughts and Information from Alfred Thompson

One Compile A Day

Rate This
  • Comments 13

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"]

  • The fast and easy compile. I remember at my second job as a computer operator, the operators could wait up to 24 hours to submit a compile. (that is when operators made a lot of money, taking bribes). But those programmers desk checked the crap out of it, you can bet. That is a lost art today. Along with testing, as far as I am concerned. I test to try to BREAK my code, not to just make sure it runs. I think there is a big differnce there. I often take the programming cycle from begining to end myself, so I guess in other shops, some or all of testing may be delegated to others. But if we went back to the old days, most of us (myself included) would be in a serious hurting. We have become very spoiled by the quick and often compiles. And to an extent, the quality has suffered some.

  • I remember when we only used to get one go a day at compiling our Cobol programs and if you upset the operators they would shuffle your punch cards holding your source code -  which would blow that day's compilation. I'm sure it did make you a better programmer as you had to test logic in your head and you made sure there were no stupid syntax errors.

  • http://xkcd.com/303/

    just pictured this the entire article.

  • Yes, we all spent more time checking things...Maybe that same paradigm should be applied to the age of spelling correction, since in this posting, there are numerous cases of the wrong word being put in by the spelling correction...

    Even simple things like really Proof-reading your work seem to be a lost art....It is a good thing that we are a lot better at parsing the meaning, rather than a strict interpretation of the words being used...

    But none the less, thought provoking.

  • Could you compile a bigger font?

  • Scott, thanks for pointing out that there were typos. I especially appreciate that you didn't point out where they were so I could have fixed them more quickly. And that you did it in public to maximize my embarrassment. I hope to return the favor some day.

    Pair of glasses, I increased the font. You may want to also think about upgrading to IE which makes it very easy to increase the size of web pages you are reading. I find that very useful.

  • I was in this situation in the early sixties. We got about three compile and test runs in a long day. We used to spend hours "debugging" - each test ended with a memory dump (in octal) and we used to go over it with a fine tooth comb to check that each memory location contained the expected value.

    The current environment with instant response is much more productive.

  • Wow, you're absolutely right, never event thought of it that way. I'm very dependent now on compiling to get the compilers input on errors!

  • I use Resharper in Visual Studio and ItelliJ IDEA for Java so I don't have to compile to see problems in my code.

  • In some cases, times haven't changed. We have two build machines, four products, and multiple branches of each product. Some product attributes can only be correctly tested through a full build. Build times range from 45 minutes to two hours, and we typically get in four or five builds a day. Depending on priorities, that means it may take a day to turn around a build for a given branch.

  • This definitely brings back memories. A simple FORTRAN program with maybe 20 lines had turnaround of typically a day. Nothing worse than getting your one page listing back with a compile error. This was circa 1970 at a small private university with Xerox Sigma 7 mainframe. I used to pity the COBOL programmers carrying a shoe box full of cards.

  • Several years ago I was confronted with the same situation. I was acustomed to rapid ECLG cycles. In this C++ project a link run took almost one hour. The largest problem was that I had to do changes in unknown insufficient documented obect oriented code. So a lot of activity was try and error. What I did was debugging the code and find out what it did and later I found a way to incrementally link, what brought it down to a few minutes.

  • This takes me back to my student days in the seventies when programs had to be submitted on punchcards and students were found hanging around the punch room hoping their job would come back. It was never good practice to submit a large punchcard job close to the end of the operators' day as they would drop the pack of cards and return them un-compiled if they thought it would cause them a problem or overrun their finish time!

    We then moved onto crt terminals linked to a centre by a landline which was a huge advance in compilation and run times - until we had a spate of downtimes caused by bulldozers cutting through the landline and other such issues!

Page 1 of 1 (13 items)