blog
The Virtues of Long Compiles
Thoughts on the material conditions of programming practice
December 22, 2011
short url:
tags:

I was corresponding yesterday with Jock Murphy, a Portland-based photographer, software engineer, and mobile game developer. Jock had read Racing the Beam, and we were talking about the relative differences between the 6502 and the Z80 microprocessors.

This subject led us to different programming practices, a topic Nick and I discuss in RtB in relation to the Atari, but for which many different and weird techniques have existed on different systems at different times. Jock made this observation about his experience of programming over the last 25 years:

I firmly feel the post C++ languages (Java, C#, Python, et al) hurt the academics of the average programmer. Back when compiles and links took an interminable time to run; most of the people I know would read the API guides of our OS looking for new things to exploit, or read books on software. I probably read Threaded Interpreted Languages, and The Mouse Programming Language four or five times in 1987 alone (not to mention Programming Pearls and the other greats).

In other words, the weird, accidental material conditions of the practice of software development have an impact on the sort of practice it facilitates. For example, the separations created by long compiles created invitations to pursue other practices... but since software engineers are still tied to their desks, more or less, and since they once didn't have all the Internet to peruse or gossip upon, a relationship with reading was a natural thing to develop. I'm sure not everyone chose to pursue the craft practice of programming like Jock did, but I bet a great many were already thinking about algorithm design and performance optimization and the like, and the everyday routine of software development facilitated that sort of knowledge development.

The point isn't nostalgia, that things were better in simpler times, but that the conditions we create (deliberately or accidentally) for and around the practices we pursue have a tremendous influence on the ways we carry out those practices. In the case of computer programming in particular, the apparent benefits of speed, efficiency, accessibility, and other seemingly "obvious" positive virtues of technical innovation also hide lost virtues, which of course we then fail to see.

Comments (5)
Want to comment on my site? Use the comment form below.

The same could be true of rendering for games. As time speeds up, that in-between time which can be used to sketch / refine / iterate shapes and concepts gets squeezed out.

Christian McCrea on December 22, 2011 10:19 PM

I like the simplicity of compile times. In my work with game devs, I've thought more about the notion of interactive code, and the seductiveness of compile+recompile, where one loses track of the logic of a procedural argument and falls prey to hoping that another tweak + recompile will fix the problem. For. Many developers, interactive development is a goal, but that doesn't make it healthy.

I don't think it's about nostalgia, but rather about opportunity cost. If you remove the penalty for random changes in hope of a solution, you wind up with random solutions, not ones that where constructed (logic-ed) out.

Casey O'Donnell on December 22, 2011 10:29 PM

Sometimes creativity eclipses processing speed too, though, and ideas are lost.

Lawson on December 22, 2011 11:30 PM

Ref: Weinberg's "The Psychology of Computer Programming".

Besides things like the coffeepot corner conversations about programming problems that end when the coffeepot goes away, we've all seen the unthinking "maybe this will fix it; edit, compile, try it out" programming that can be so seductive. I've seen a steady progress of what I call "throw the spaghetti on the wall and see if it sticks" style of programming going back to the very lengthy punch cards-assemble-link-reboot-test cycle which really rewarded careful thought about the problem, desk checking, and analysis of results.

Garrett on December 23, 2011 7:52 AM

This reminds me of the complaint/concern my film editing teacher, Jill Godmillow, expressed about the shift from flatbed physical razor-and-cutting-block editing (which she taught us with) to digital computer-based editing.

She said almost the same thing: that back in the day, an editor would have to wait on an assistant editor to rummage through the bins to find the precise clip of film she needed, and while waiting, she would often ruminate on her decision and consider other possibilities. For her, this often led to even better ideas. She was critical of digital editing for collapsing that searching step, which to her heavily discouraged reflection about each decision.

Brett Boessen on December 23, 2011 10:49 AM
Post a Comment

If you haven't left a comment before, your comment will be held for approval. Thanks for waiting.

Name:
Email:
URL:
  Remember me for next time?
Comments:
To prove you are a human, type the word (loading...) below.