Gary Kildall

As the founder and chairman of the board of Digital

Research, Gary A. Kildall developed the first operating system for a

microcomputer during 1972 and 1973. He called it the CP/M (Control

Program/Monitor) operating system and it became his company’s first

product. In addition, he designed the DR Logo programming language for

the IBM PC and he developed PL/1, one of the first high-level

languages for microcomputers.A native of Seattle, Kildall was born on May 19, 1942. He

received his Ph.D. in computer science from the University of

Washington in 1972. He then joined the Navy and taught computer

science at the Naval Postgraduate School in Monterey, California,

where he continued to teach after his discharge from the Navy.In 1984 Kildall formed a new company called Activenture

Corporation (recently renamed KnowledgeSet Corporation) to explore the

potential of optical-disc publishing. In 1985, Activenture announced

they would publish Grolier’s Encyclopedia in a CD ROM

format. Kildall retains the position of chairman of the board at

Digital Research along with his position as president of KnowledgeSet

Corporation.

We went to Digital Research on a Monday morning via Highway 1

along the California coastline. The scenery is some of the most

spectacular in the country and the coastline is dotted with more

resorts than computer-related businesses. Digital Research and

KnowledgeSet, both started by Gary Kildall, are two of the few

high-tech companies in the area. I couldn’t help but wonder how one

could coop oneself up in the characteristic dingy, dimly lit office to

write source code, knowing that such stunning beauty was right outside

the door. But Gary Kildall seems to have no difficulty devoting

attention to his work, and appreciating the surroundings during his

leisure time. Kildall likes to work and play equally hard. His “toys”

include a new Lamborghini Countach, a Pitts aerobatic biplane, and a

Rolls Royce.

Gary came to meet with us in a conference room around noon. He

is tall, with red hair and a trim beard, and he was wearing crisp new

western-style blue jeans, a white cowboy snap shirt, and boots. Having

just come from a weekend in Tahoe where, he confessed, he ate too

much, he ordered a Diet Pepsi while the rest of us called for

sandwiches. And with that, Gary, in his reserved and calculated

manner, discussed programming with great seriousness and passion. In

fact, we had pulled him away from writing source code for his latest

CD ROM encyclopedia project in order to do the interview. One reason

he had started KnowledgeSet was so that he could get back to the nuts

and bolts of programming, away from the management demands of his

first company, Digital Research, which has grown so large. Gary often

turned to the white board to draw diagrams or illustrate important

points as he explained the meticulous, creative process he goes

through to write code that makes computers perform.

INTERVIEWER: You taught at the Naval Postgraduate

School. If you were to go back and teach again, would you teach any

differently?

KILDALL: Probably not, because I don’t program any

differently now than when I was teaching. I would teach the course I

enjoyed most, the data-structures course. It goes back to the

fundamentals of programming: simplifying the problem. Part of the

programming process is general problem solving. How do you solve a

problem that’s complex, whether it’s designing a computer program or

constructing a building? You start at the point where you think it’s

too hard to solve, and then you break it down into smaller

pieces. That’s what I try to teach.

INTERVIEWER: It’s difficult to teach problem-solving

principles. How did you go about it?

KILDALL: On the first day in a particular data-structures

class, I said, “We’re going to have a little test. Put your books on

the floor and get a piece of paper. I want you to write a program that

will symbolically solve differential equations. Given a polynomial,

the program should differentiate the polynomial and produce the

symbolic, not numeric, result.” So the students started writing away,

thinking, and scratching their heads. This went on for about ten

minutes, then I told everyone to stop. I asked them to think about how

they approached solving that problem. What tools were they using? Were

they starting to write a program? Were they thinking about

mathematics? Were they starting to write little examples down? That

whole quarter we worked with the techniques and tools of problem

solving. Then, in the final exam, I gave them the same problem I had

given them to solve on the very first day.

INTERVIEWER: What were the most important principles your

students had learned when they completed your classes?

KILDALL: I taught two things that are important for students

to learn: problem solving and how to study. Knowing how to study takes

care of getting through tests and leads to other school-survival

skills. And if you learn how to solve problems, you can go through

life and do pretty well.

INTERVIEWER: How would you characterize your own

particular style of writing programs?

KILDALL: I follow very definite procedures which work for

me, though they may not work for other people. I start with drawing

the data structures, and I spend a lot of time thinking about them. I

also think about what the program has to go through before I start

writing code.

Programs are like mechanical devices; the way one piece of code

works with another is very similar to the way one gear meshes with

another gear. Building code is a little like building a

transmission. The PL/1 compiler I wrote a few years back is a good

example. People said it was impossible to write a compiler on a

microcomputer, but after a couple years of work, it was considered one

of the best optimizing compilers around.

Once the data structures are developed, I start writing small

chunks of code that I improve and monitor along the way. Checking them

as I go assures me that the changes I make are localized; and if I

have problems, I discover them immediately. This whole process of

iterative improvement requires speed, so for me at least, it’s very

important to have fast edit, execute, and debug cycles. This method

doesn’t work as well on a mainframe or a card-batch system because you

can’t make small changes and check them out.

INTERVIEWER: Do you prefer to work in an interpretive

environment?

KILDALL: No, I don’t like existing interpreters very

much. I’d like to have one for a systems language like C that would

parallel an existing compiler, but it’s still questionable how well

that would work, because most systems programs are

performance-oriented or timing-dependent. If I had a very effective

interpreter–something like I used when I developed PL/M, or now maybe

C–an interpreter might be worthwhile using.

INTERVIEWER: How did you get interested in

programming?

KILDALL: I originally planned to be a high school math

teacher, and started taking math courses at the University of

Washington. But a friend of mine had this FORTRAN statement card,

showed it to me, and told me it was going to be a really big thing. I

became so intrigued I had to get into it. So I took an

assembly-language programming course and FORTRAN right after that, and

I was hooked. I found I liked programming for the same reasons I liked

to build models, cars, and things of that sort. I found constructing a

program to be a similar experience.

INTERVIEWER: Do you remember the first program you

wrote?

KILDALL: Yes. It calculated the number of seconds between

any two times of the day and any two calendar dates. That program is

still around; every time I clean my desk I find it, like old clothes I

find in my closet.

INTERVIEWER: What about the first professional program

you wrote?

KILDALL: I wrote it at the navigation school my father

owned. We used to prepare tide tables by hand for one of the local

publishing companies in Seattle. I wrote a FORTRAN program that

calculated the tides. It was the first program I made money on–$500

or so.

INTERVIEWER: So how did you happen to begin working on

the CP/M operating system?

KILDALL: The operating system was actually just a little

fragment of a very large project. I was working with XPL, a language

for mainframe computers, written by Bill McKeeman at Stanford. I

developed a similar language called PL/M, a programming language for

microcomputers. I was trying to get PL/M to run resident on the 8080

microprocessor, and I had to write an interface to communicate with a

disk drive. It turned out that the operating system, which was called

CP/M for Control Program for Micros, was useful too, fortunately.

INTERVIEWER: So when you were developing CP/M you had no

idea it would be so successful?

KILDALL: No, I didn’t know CP/M would be such a hit, but it

was very clear to me that floppy disks would be. I had been working

with paper tapes for a year and a half. A floppy-disk drive was $500

and a paper-tape reader with a fancy punch was over $2,000. Just by

looking at the cost comparision of the two drives, I realized the

floppy disk would be a commercial success.

INTERVIEWER: Some programmers throw out code and start

over when they run into extremely serious problems with their code. Do

you ever do that?

KILDALL: No, because my problems never get serious enough to

start over. I never would have been coding if I didn’t think I had the

right data structure. Whenever I tear code apart, it is usually

because the underlying data structures weren’t any good, not because

of the algorithms I applied.

INTERVIEWER: Do you use comments when you write

code?

KILDALL: Rarely, except at the beginning of procedures, and

then I only comment on the data structure. I don’t comment on the code

itself because I feel that properly written code is very much

self-documented. Once I get the algorithms down, I start writing code

directly on the machine. I don’t even write it on a piece of paper

before it goes into the computer; it just doesn’t seem necessary. The

actual coding process has always been a little scary for me because I

don’t know if I’m writing the right code, nor do I know what I’ll

write next. It just seems to come out. Sometimes I realize the code’s

not exactly right, but I also realize intuitively that it will relate

to something else–it will factor out and become right even if I don’t

know exactly how at the time I’m writing it.

The magical part is that, at some point, all at once the whole

thing comes together. It’s like taking a logical Boolean expression

that simplifies and simplifies until, bam, you’ve got it. When I reach

the point where the code coalesces, I’m certain the program will work,

and I also have no doubt I did it about the best way it could be

done. I don’t completely understand the process, but it sure seems to

work for me, even when I make fairly massive changes to data

structures and algorithms.

INTERVIEWER: Is writing code always an unknown and

difficult process?

KILDALL: No. When I code without pressure to meet a

deadline, it’s very relaxing. Sometimes when I’m scheduled for a long

plane ride, I’ll take a little portable along and code just for

fun. In fact, even when there’s a deadline, it’s fun to sit at a

terminal and let the code flow. It sounds strange, but it just comes

out of my brain; once I’m started, I don’t have to think about it.

INTERVIEWER: Have you ever been unable to get the code to

work just the way you envision?

KILDALL: There are very few cases where someone has gone

into my code and said, “We could have done it a lot better,” but there

are times when it just doesn’t come together. The editor in the DR

Logo interpreter is a good example. I had some pieces of code I knew

were not quite right–it worked fine but hadn’t factored out correctly

and just wasn’t right. The engineers who took over the code zeroed in

on that piece of programming, but we didn’t have time to make changes

because we had to get the product out. That’s the kind of thing you

hope never happens, but it does sometimes, so you go back and fix it,

and learn something about your style.

INTERVIEWER: Do you think programming is something you

can practice as you would practice the piano?

KILDALL: Well, you can practice in a sense. Seymour Papert

has this notion that kids learn to be inventive by tinkering with

gears and other mechanical gadgets. The skills you learn and practice

with this kind of play carry over into other areas. Papert is

certainly talking about my childhood experience. My father was a great

craftsman. I used to stay and watch him by the hour, and then I would

go outside and try to imitate him with my own hammer and nails.

Data structures, which are the foundations of programs, are

mechanical by nature, like the things I played with as a kid. So, in

that sense, I practiced programming. The big difference is that

building something out of wood or steel takes hours of labor; if you

don’t do it right, you have to go back and rebuild. Programs can be

altered instantly.

INTERVIEWER: How else can you build your repertoire as a

programmer?

KILDALL: You need to study other people’s work. Their

approaches to problem solving and the tools they use give you a fresh

way to look at your own work. You need to learn only a small set of

procedures before you can write a program. For example, when you’re

writing compilers, the first thing you write is a scanner, which is a

little tool you use a lot. Once you learn those tools, it becomes a

matter of putting pieces together. You grab pieces from here and there

and stick them all together. Looking at programs others have written

gives you new ideas for constructing coherent code. That’s why, as a

teacher, I spent a lot of time with students showing them clean

algorithms I had picked up.

INTERVIEWER: You’ve talked about how you taught

others. Has anyone or anything influenced your style of

programming?

KILDALL: I’m very pragmatic. I like to build programs that

are fast and small, and use clear, concise algorithms. I learned that

style from the early Burroughs 5500, a very advanced machine for the

day, which was based upon the ALGOL philosophy of block-structured

languages. The ALGOL compiler was probably one of the nicest pieces of

code to come out at that time. I spent hours trying to fix and change

the compiler. Working with it so closely affected the way I think

about programming and had a profound influence on my

style. Fortunately, the ALGOL philosophy became the basis for design

of popular languages like Pascal and C, so the style works for me.

INTERVIEWER: One hears stories about the crazy hours

programmers keep. How about you? Do you have a certain

routine?

KILDALL: My pace varies during the development of the

program. At some points, the code gets explosive and I have everything

inside my brain at one time: all the variable names and how they

relate to one another, where the pointers start and where they end,

disk access, et cetera. All sorts of things go on in my brain that I

can’t put on paper simply because I’m always changing them. I’d spend

more time writing than I would coding, and I’d never get the project

done in a reasonable amount of time.

When the data structures are so new, they require intense

concentration to keep them organized in your head. So at this point in

the process, I’ll usually start at 3:00 a.m. and work until maybe 6:00

p.m. Then I’ll have dinner, go to bed early, get up again pretty early

in the morning, and keep banging on it until things are calmer.

During the calm times, when my pace is more relaxed, I come up with

solutions for the next phase. When I’m trying to solve a problem that

has a series of steps, I take them in order, one at a time–step A,

step B, then step C. I’ve tried, but I just can’t work on C until B

has been Completed.

I take short vacations during the lulls because I like to enjoy

life, too. That’s the time I go out and fly airplanes just to get

away. It’s good for my work, because I always come back with some

fresh ideas.

INTERVIEWER: Does your flying airplanes have any other

impact on your programming?

KILDALL: I certainly hope my program planning is better than

my flying. I’ve heard that quite a few programmers are also fliers. I

know Charles Simonyi flies a helicopter. And both Fred Gibbons and

Vern Rayburn were very interested in flying.

Programmers like flying a plane because it is a mechanical process

just like programming. Also, people who like computers like gadgets,

and airplanes are just loaded with gadgets. They’ve got all the dials

and wheels and knobs you could ever want to play with. You get to play

a little dangerously because it’s the real thing, not just a video

game. Computers are very abstract, but airplanes are real.

INTERVIEWER: Do you ever get tired of

programming?

KILDALL: I don’t think of my work as tedious, if that’s what

you mean. When I go on vacation I look forward to returning to

work. The only time I don’t want to come back is when the code

explodes. Then it becomes tough because I’m working under pressure to

get the code back together. When you’ve got the code all ripped apart,

it’s like a car that’s all disassembled. You’ve got all the parts

lying all over your garage and you have to replace the broken part or

the car will never run. It’s not fun until the code gets back to the

baseline again.

INTERVIEWER: Do you find anything aesthetically pleasing

in your work?

KILDALL: Oh, absolutely. When a program is clean and neat,

nicely structured, and consistent, it can be beautiful. I guess I

wouldn’t compare a program with the Mona Lisa, but it does have a

simplicity and elegance that’s quite handsome. Stylistic distinctions

of different programs are intriguing, very much like the differences

art critics might see between Leonardo’s Mona Lisa and a Van Gogh. I

like the LISP programming language so much because it’s so

pleasing. There’s a concise form of LISP called the M expressions.

When you write an algorithm using M expressions, it’s so beautiful you

almost feel it could be framed and hung on a wall.

When I was working on my Ph.D. thesis, I was trying to solve a

difficult global flow analysis problem. I knew there had to be a

solution, but I just couldn’t crack it. Finally, when I got a clean

mathematical model, I coded the algorithms in LISP. The program took

only two hours to write, and it was beautiful; it did exactly what I

wanted it to do. At that point, I had no direct proof the program

worked, but every example I ran through LISP was functioning the way I

expected. I wrote the same program in XPL, which is a systems language

for running compilers. Later, when I got proof that the program was

correct, I found it was based on the concepts of the very pretty LISP

program, not the concepts developed in the relatively ugly XPL

program.

INTERVIEWER: Do you consider programming to be an art or

a science?

KILDALL: There certainly is some art in it. But a lot

of programming is invention and engineering. It’s much

like a carpenter who has a mental picture of a cabinet he’s

trying to build. He has to wrestle with the design and

construction to get it into a physical form. That’s very much

what I do in programming.

Programming has some science as well, though not a

lot. Experimental science means you hypothesize, try things, and

compare results, and in that way programming is science. You may have

a concept of how a retrieval system should work, but it’s not until

you run it with sufficient data that you can see the mechanism

operating and get some statistics.

But remember, I’m in one special area of programming: compilers,

operating systems, retrieval, and other system software. A programmer

who specializes in graphics, for example, may have an entirely

different view of the programming world. Because graphics programmers

are dealing more with the physical world–talking about the way light

sources affect objects, for instance–there may be a lot more

mathematics and science involved in their work. You know, I also think

programming is very much a religious experience for a lot of

people.

INTERVIEWER: What do you mean when you say programming is

a religious experience for a lot of people?

KILDALL: Well, if you talk about programming to a group of

programmers who use the same language, they can become almost

evangelistic about the language. They form a tight-knit community,

hold to certain beliefs, and follow certain rules in their

programming. It’s like a church with a programming language for a

Bible.

FORTH is a good example; it’s a programming language that is

probably close to being a religious experience for many people. When

FORTH first came out, its disciples claimed any algorithm could be

done ten times faster. That was a typical claim. If you argued that

point or any other, you found yourself talking to a brick wall and you

definitely weren’t allowed in the church. Now I don’t mean to be

derogatory about the people who use that language. It’s a very

supportive group and a very effective language, but the discussions

were not based on reason. They were based on belief. By saying this,

I’ll probably get about a thousand letters about FORTH and the

religious experience people are having over it. But I’m not putting

myself in a special category either; I can preach about the wonders of

LISP all day.

INTERVIEWER: What do you think will be the future role of

computers?

KILDALL: Basically, our technology tends to simplify

mechanical processes. That’s why computers have been so successful: We

take things normally done with cogs, wheels, and relays, and do them

with vacuum tubes and then with semiconductors. Look at automobiles,

for example. More and more of the processes in the automobile, like in

the 1984 Corvette, are being turned over to the semiconductor or its

equivalent. When semiconductors take the place of speedometer cables

and tachometers, they turn the car into a less expensive and more

reliable product that is easier to produce. Computer systems are going

through identical changes right now; the hard disk drive is a

mechanical device. Because it is mechanical, we know it will

eventually go away. We don’t know how it will go away, but we know

it’s a prime target.

Some gadgets and processes will continue to function mechanically,

such as wheel bearings on cars, because it’s pretty hard to make those

from a semiconductor. But many other things in our daily lives will go

through the transition from mechanical to electronic. The print

industry is a good example; CD ROMs and optical storage are becoming

important there now. Computers help to get away from the mechanical

processes of printing: running printing presses, laying out and

pasting up by hand, setting up the cameras. The semiconductor will

take over the mechanical process. But computers won’t stop

there. Right now they control the production of print but not the

actual display of information.

Right now, a very big bottleneck–one of the reasons why the

personal computer industry is in the doldrums–is that we have a

difficult time thinking about what to do with computers once we get

past spreadsheets and word processing. We don’t know what the next

step is. We’re stuck.

It goes back to what I was saying about the dependence of

programming on beliefs rather than reason. Ultimately the problem is

that we, as a society, took the big computers that we understood and

applied their underlying architecture, languages, and concepts to the

development of microcomputers. As we move toward using computers as

controllers, we will find that communication between processors will

become more important than the processes they are carrying out. Then

we will be forced to change the way we code. That will be a very slow

evolutionary process.

INTERVIEWER: So the future really depends on our ability

to free ourselves from old patterns of thinking?

KILDALL: I felt strongly in the early days of

microprocessors that they should be used primarily as embedded

processors, talking to one another and coordinating the transition

from mechanical to electronic processes. That’s where I felt the

computer industry was going. I saw them as replacements for random

logic, with engineers being the primary users of these small

machines. In fact, someone from Lawrence Livermore Labs suggested I

develop a BASIC for the microcomputer–that was probably in 1974. I

told him that was the most stupid idea I had ever heard. Who would

want to do a BASIC for microprocessors when they were being put into

such tools as inventory-control systems, cathode-ray tube displays,

and word processors? Obviously, I was wrong about that. It turns out

that one of my thesis students, Gordon Eubanks, did very well with C

BASIC, as did Paul Allen and Bill Gates.

Somehow we have to break loose from the ways we think about

microcomputers if we want to stimulate advances in computers. People

at home don’t want to buy another computer system. They bought one and

there was no real use for it. They don’t want to be ripped off

again. And we’re talking about 95 percent, not 5 percent, of computer

users. There are 16 million television sets sold every year; there’s

no reason why we shouldn’t sell 16 million gizmos with embedded

microprocessors.

INTERVIEWER: You mentioned CD ROM a minute ago, and its

potential impact on the printing industry. Will it have any other role

in the evolution of computers?

KILDALL: Optical storage will clearly pull the computer

industry in a new direction. When we worked with floppy disks, we were

just making little machines out of big machines. And we haven’t yet

gone a whole lot farther than that today.

Optical storage is completely different. We’re not talking about

computing anymore; we’re talking about putting information into

people’s hands. People now might buy personal computers because

somebody else told them they should, but with optical storage, people

will buy computers because they want the information. Computers will

be competing more with publishing.

INTERVIEWER: So information could take the form of an

electronic encyclopedia, like the one you’re putting on CD ROM? How do

you envision the design–both the retrieval system and the

enhancements?

KILDALL: I take the concept for the initial product, get an

overall idea of what I want to do, and start coding right from the

nucleus, letting it expand in the direction it flows. As long as I

don’t limit the fundamental data structures, features can be added. We

did a videodisc called the Knowledge Disc, which carried over nicely

into CD ROM retrieval systems. All text was done with

bit-mapped fonts at the pixel level. A very nice side effect of

working with pixels is that pictures go into the whole thing very

cleanly and nicely. So we don’t have to go back and do total redesigns

of anything to add images to text that already exists on the CD

ROM.

It’s a problem if the design doesn’t let you add features at a

later date. If you have to redo a program, the hours you spend can

cause you to lose your competitive edge. A flexible program

demonstrates the difference between a good designer and someone who is

just getting a piece of code out.

Right now, we’re going full speed ahead just to blast as many

people out of the water as we possibly can. We’re hoping to be ready

by the first part of 1986. Economically, we have no choice but to go

fast and to use this technology. It’s the best. Then we make sure that

we license the rights to it.

INTERVIEWER: Are knowledge systems part of where you see

the home market going?

KILDALL: Yes. People don’t usually go home to work. Some

tasks people do at home are related to work, like keeping track of

taxes or running a little home business. But mostly they go home to

relax. I think games and entertainment are valuable. We have a lot of

trouble figuring out how to entertain people at home. And TV does a

good job right now; competing with “Dynasty” is extremely

difficult.

One possible computer application is something to help kids

study. My fourteen-year-old daughter is taking some hard courses and

she needs help studying. Computer applications like that would give me

a direct benefit: My child does better and that helps her in the

future. That’s clearly an important area for development.

Another area for development is providing general information about

selected subjects, such as medicine. People go to doctors for many

reasons. Some are psychological. But sometimes they only want medical

information. It costs a lot to go to the doctor, and if people had

less expensive ways to access that data, they would. Here’s another

example: When I want a car, I try and shop L.A., San Francisco, and

San Jose to get the best prices. But it’s virtually impossible to get

the facts about car dealers because people who don’t want you to be

able to shop like that are protecting the information. I’d be a

candidate for that information because it could save me thousands of

dollars, not to mention a lot of time. I’d pay a reasonable amount to

get it.

We want to develop applications that will give people a definite

economic advantage if they buy them. That’s why we went for an

encyclopedia as the first CD ROM application. Everyone knows

encyclopedias usually cost about $1,000. Someone can rationalize

buying a computer that has the encyclopedia, if it’s in the same price

range as the printed encyclopedia.

INTERVIEWER: How friendly will this machine be?

KILDALL: Well, I don’t think it’s a matter of friendliness,

because ultimately if the program is going to accomplish anything of

value, it will probably be relatively complex.

Some people suggest that machines would be friendlier if input

could be in a natural language. But natural language is probably the

worst kind of input because it can be quite ambiguous. The process of

retrieving information from the computer would be so time-consuming

that you would be better off spending that time getting the

information directly from an expert.

Expert systems will be the ultimate in user friendliness. But we’re

a long way from having the expert in the box. The doctor-in-a-box,

although a phenomenal product, is incredibly complex. It would have to

be perfect. Someday, we’ll have programs like that. I just don’t know

how far off they are, and there are lots of problems to solve along

the way, but that’s the fun part.

All Material Copyright 1986, 2008, Susan Lammers. All Rights Reserved.

Gary Kildall made this sketch during development of the Knowledge Retrieval System to provide a graphic picture of the menu tree design. The Appendix shows more details of this menu.



