Interview to Gary Kildall

Hello all!

I have found this interview in the internet. I believe that it is very
interesting.

Best regards,

Source: http://www.sourcesystems.net/gary_interview.html

--- begins here ---

Developer Resources / Network

Gary Kildall

ProgrammersAtWork/GaryKildall
(From http://web.archive.org/web/20010222060611/www.rjh.org.uk/PAW/m1105.htm)

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.

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

---- ends here ---

.

Loading