Gary Kildall 1986

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.

---