John Warnock

“One can’t help but notice the sign for Adobe Systems as you enter the company’s office building, located in Palo Alto off of the Embarcadero, a road dotted with high-tech companies. The sign is rather large and it shines like gold. It is indicative of the success Warnock’s company has recently experienced. Like so many others, Warnock took his ideas out of Xerox PARC into the real world, where he turned them into a language, PostScript, and a company, Adobe Systems.

John Warnock has a professorial look, with a full beard and tousled brown hair and has an unassuming air and a casual manner. He wore a tweed jacket, a white shirt with an open collar, and wool slacks. His corner office is impressive, with clean lines and a contemporary look. I got the impression my visit was one of many Warnock has received since his company has met with such success. We swapped gripes about being on the road for so long. These days, the time Warnock spends programming is restricted to doing routines with PostScript, but he remains one of the programming wonders of our time.”

“INTERVIEWER: A lot of Dave Evans’s students went on to become systems designers. What do you think makes a good systems designer?

WARNOCK: There are very few really talented systems designers. Some people are very good at one particular thing or another, but systems design takes real balance, taking a list of options here and a list of options there, and combining them so they really work well together. A lot of people design an algorithm and then design the system around that algorithm.

Good systems design is much more of an engineering activity; it’s a set of trade-offs and balances among various systems’ components. I think the most difficult part of systems design is knowing how to make those trade-offs and balances among the various components.

INTERVIEWER: When did you come up with the original idea for the PostScript language?

WARNOCK: PostScript started in the Evans and Sutherland days when we were doing a harbor simulator for the Maritime Academy. We had to build a digital model of New York harbor, with 1,500 buildings and tank farms, and all the bridges and buoys and everything—all the landscape. The simulator was going to project the view of the harbor as seen from the bridge of the ship. We needed to write a huge, three-dimensional database and a lot of real-time software to make the simulator work the way they wanted it to.

We had a year to complete this massive undertaking. It was a full-color model with all three dimensions. We decided the most stupid thing we could do was to design this database in a form that would be used directly by the simulator. In other words, to bind it up too tightly. We decided to create a text file and write a compiler to compile the text file into the form that the simulator would need (whenever we decided what that would be). We still didn’t know what the simulator was going to look like. So we started building this huge database in text form. In digitizing the database and in building this big three-dimensional model, it became very obvious that rather than having a static data structure in the text file, it was much more reasonable to have a language. It needed to be a very simple, easily parsed, and extensible language. So that’s where the basic ideas of PostScript got started, in developing a language for this three-dimensional graphic database.

INTERVIEWER: Do you approach writing code differently today? Do you have a different method? Do you plan everything out beforehand?

WARNOCK: I think a lot before I do anything, and once I do something, I’m not afraid to throw it away. It’s very important that a programmer be able to look at a piece of code like a bad chapter of a book and scrap it without looking back. Never get too enamored with one idea, never hang onto anything tenaciously without being able to throw it away when necessary; that should be the programmer’s attitude. Also, never make an assumption that you know something somebody else doesn’t know. There will always be some smart guy who will come along and figure out a better algorithm or figure out an easier way of performing some task. One of the tricks of the trade is to recognize this early, adopt it quickly, and exploit it without having a “not-invented-here” hangup about doing it your way.”