Robert Carr

“Forefront is a small operation with a core group of programmers working together in a cooperative style. Bob Carr is young, full of energy, modest, and astute. He serves as the technical leader of this devoted group. Carr was dressed neatly, wearing round tortoise-shell glasses, corduroy pants, and an oxford cloth shirt. As we talked, Carr gesticulated and drew diagrams on the whiteboard. He spoke with great intensity and thoughtful deliberation in well-constructed sentences. He reflected upon his past and on his approach to program design, as exemplified in his most ambitious project, the creation of Framework. ”

“INTERVIEWER: When was the idea of Framework born?

CARR: One day I considered what would happen if you had a spreadsheet cell that you could open up and inside find another spreadsheet, and inside of that find yet another. I made a simple drawing of a square inside of a square inside of a square, to express this notion of information inside of information. Then one day I mentioned it to a friend. Then he asked the very simple question that set me on fire, and became the catalyst for Framework: “Well,” he asked me, “how would you do it?” I then knew I needed to test myself.

I worked on Framework in the mornings and evenings, just scribbling notes. I was still programming at my job during the day. After four months of brain-storming on paper, I had a direction to pursue. I spoke to the Context management about it. They were excited but already had plans for the evolution of their company and product line. The chances of my visions being implemented there were minimal, so I broke ties with them and moved to San Francisco, where I wouldn’t be tempted to go back to work for them. They were great people. I lived off my savings and continued designing, thinking that if it turned out to be a viable program, I could turn it into a business opportunity. I was obsessed. My emotions rode with the progress of the idea, and I worked on it harder than I had ever worked on anything.

One piece of advice I had been given was to hold off programming for as long as possible. Once you get a corpus of code building up, it’s hard to change direction. It sets like concrete. […]

One of my other goals was to simplify the core design and architecture as much as possible, by implementing a single universal data object. The reason for this is that when you implement layer upon layer of detailed features which absorb memory, you need an utterly simple scheme on the internals, or you’re doomed to have a big complex pig of a program…

In January 1983 I started programming the idea. It was based on this single data object, which I called a frame, and on which the whole system would be implemented. It was quite a gamble. If it worked, I’d be able to get a system up and running in a short time. If it failed, I’d go nowhere. It turned out to be tremendously successful. Within a few months I had a lot of the user interface working, and within six months I had a very efficient working prototype.”

“INTERVIEWER: Where did you learn the techniques you use?

CARR: From experience and also introspection. I tend to reduce things to a fairly simple framework, if you’ll excuse the term, and then expand it back out to apply to the real world. And I’m forgiving; I don’t expect the framework to fit perfectly what I’m applying it to, but I expect it to provide insight and guidance to whatever topic I bring it to.I’m horrible at math, but I might have been happy as a physicist, because I believe that they do what I do: They reduce all of physical reality to a relatively small number of theorems and rules they can use to predict and interpret physical reality. I’m doing the same thing with software—trying to come up with some theorems.

Second, granularity runs into another one of my rules, homogeneity. Architecture should be homogeneous; it should not have a lot of exceptions or special cases. If you design a system to deal efficiently with memory objects that are megabytes in size, as well as objects that are bytes, you’ll end up with tremendous complexity. It’s better to deal with either one or the other; that’s what I call homogeneity. Another global rule deals with recursion—it is one of the top three or so brilliant, powerful levers that computer science has brought into software. The most powerful software usually applies recursion internally and often provides recursive capabilities to users. Memory management is the most important aspect of the internal architecture of a program. One rule in this area is never copy the same data twice… if the same data appears twice again and again, different modules of code would copy data and place it in a buffer where it could be worked on, then the data would end up sprinkled throughout memory. This is an evil for several reasons…

INTERVIEWER: How did you translate simplicity and clarity into the user interface of Framework, yet retain a richness of functionality and performance?

CARR: We developed a menu scheme with restraint and discipline. We all know that sensual pleasures taken to excess are a curse rather than a blessing; it’s the same with menus. They require great discipline. Menus are the best way to present a choice of commands to the user. But there are menu systems that branch so much that they become monstrosities. ”