Logo IMG
HOME > PAST ISSUE > Article Detail


Bit Rot

Brian Hayes

Writing Source Code

The problems I'm whining about here—the problems of keeping a grip on digital text and other kinds of data as computer technology evolves—must seem quaint to professional programmers and software engineers. Moving a data file from one machine to another is easy compared with "porting" software. You don't just take a Windows .EXE file and try running it on a Macintosh. And programs are notoriously brittle. A data file may lose something in translation—such as footnotes—and yet still be usable. When a program fails, it fails totally.

Living on such thin ice, programmers learn to tread carefully. It's part of their education and culture. Writing code for keeps is a major theme of software engineering. Tricks and shortcuts that solve the problem of the moment are not much admired if they fail on another platform on in the next version of the operating system. The emphasis is on portability—on program constructs that work in any computer environment.

Programmers observe a distinction between "source code," which is what the programmer writes and revises, and "object code," which is the final product. The Central Dogma of software development holds that information flows only from source code to object code, never the other way around. Programmers also put a high value on abstraction—on expressing concepts in the most generic way possible. And they are wary of the dangers of duplication and repetition: They know that if information is written down twice, the two copies will eventually become inconsistent.

The same principles and attitudes may apply just as well to other kinds of computer work. Indeed, it's not much of a stretch to see writing with a word processor or drawing with illustration software as a kind of programming. The manuscript I am typing at this moment is not a magazine article but the source code of a program that can be compiled to produce a magazine article. If I compile and run the program through a laser printer, the output is a paper printout. Later the same source code will be compiled again and run through a larger machine that produces photographic film for printing plates. Compiling with still another set of options yields Postscript files for distribution via the Web. It all goes smoothly (most of the time) because the same source code is the input to all the transformations. If I make a change to the source, it automatically shows up in all three object-code versions.

Several years ago a book title proclaimed: The Mac Is Not a Typewriter. Neither is the PC. It's not a typewriter; it's also not a sketchpad; it's not a ledger book. It's a computer. When you sit at the keyboard, you may think you're writing or drawing or balancing the budget, but what you're doing is creating computer programs, which have to be compiled and run before they yield their output of text or art or spreadsheet. You may think you're just a content provider, but you're really a programmer.

© Brian Hayes

» Post Comment



Of Possible Interest

Letters to the Editors: Getting Personal

Perspective: The Nature of Scientific Proof in the Age of Simulations

Computing Science: Delving into Deep Learning

Subscribe to American Scientist