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.