Charles Simonyi– 1986

Charles Simonyi

---

Born on September 10, 1948 in Budapest, Hungary, Charles Simonyi was introduced to computers and programming while attending high school, when his father arranged for him to assist an engineer who was working on one of the few computers in Hungary at the time.By 1966 Charles had not only completed high school but also his first compiler. With the experience gained from writing the compiler, he was able to obtain employment at A/S Regnecentralen in Copenhagen, Denmark. In 1968 Charles left Denmark to study in the United States at the University of California at Berkeley, where he received his bachelor of science degree in 1972, and his doctorate degree from Stanford University in 1977. Simonyi has worked at the UC Berkeley Computer Center, the Berkeley Computer Corporation, the ILLIAC 4 Project, Xerox PARC, and, since 1981, Microsoft Corporation. While at Xerox, Charles created the Bravo and Bravo X programs for the Alto personal computer. At Microsoft, Charles organized the Application Software Group, which has produced Multiplan, Microsoft Word, Microsoft Excel, and other popular application products.Almost everywhere here in the microcomputer world, Charles Simonyi has made his mark, either by something he has accomplished or by influencing someone with whom he has worked. He’s a modest but spirited fellow, quick to smile and able to comment on just about any topic, computer related or not. During the two times we met with Charles, once over lunch and the other time in his office, the conversations ranged from the attributes of Microsoft Excel, to flying helicopters, to certain facets of modern poetry. His speech is distinguished by a Hungarian accent which has become Charles’ trademark both in speaking and programming. Clad almost daily in a uniform of weathered jeans jacket, shirt, and worn jeans, he retains the appearance of a Berkeley student during the sixties, but his breadth of knowledge, manner and accomplishments exhibit a wealth of wisdom and experience.INTERVIEWER: Your first computer program was done before you graduated from high school in Hungary, correct?

SIMONYI: Yes. There is my first program and then my first professional program. The first program I ever wrote filled in a magic square, where all the columns and rows added up to the same sum. I programmed it into an ancient tube computer. I spent the whole afternoon pushing buttons just to enter it into the machine. That evening, I arrived home with an incredible headache and giant rolls of paper with printouts of 80-by-80 magic squares. That was in 1964.

INTERVIEWER: What was the first computer you worked on?

SIMONYI: It was a Russian-made computer, a Ural II. It had only 4K of memory, a 40-bit floating point, and 20-bit operations. The computer was programmed totally in octal absolute [no assembler]. I wrote thousands of lines of code in octal absolute.

All the action in this computer was directed through the console; it was truly a hands-on, one-on-one experience. Programmers didn’t have to stand around waiting for a computer operator to run a batch of cards. The Ural II was exactly like a personal computer because it was just you and the machine and no one else. With 4K of memory and the slow speed, it was very similar to the Altair, which was introduced in 1974. The excitement I experienced with the Ural II in 1964 was the same kind of excitement that Bill Gates experienced with the Altair in 1974.

Obviously, the Ural II differed from a personal computer in some respects. The Ural II was the size of a very, very large room and the method for input and output was incredibly primitive–primarily through console switches. The console looked like an old-fashioned cash register. There were six full columns of switches and an enter key on the right. Each column had keys numbered from zero to seven. You entered numbers just like you would on a cash register. So to enter 2275, you pushed the keys for two, two, seven, and five. If you made a mistake, you could correct it before pushing the enter key on the right. All this was exhilarating because there was a lot of noise associated with it. Every time I hit the switch, it clicked very firmly. Whenever I cleared it–it was all done mechanically–all the keys released at once with a great “thunk.”

INTERVIEWER: What was your first professional program?

SIMONYI: The first professional program that I wrote was a compiler for a very simple, FORTRAN-like, high-level language. I sold it to a state organization as an innovation and made a fair amount of money, none of which I ever spent, since I left Hungary soon after.

It was during this time that I met some Danish computer people at a trade fair in Budapest. I approached them and got a lot of information about their new machine. At the next trade fair, I came prepared with a small demonstration program I had written. It provided feedback on exactly which part of a lengthy expression the machine was analyzing at any point in time. I asked one of the guys to take the program back to Denmark and show it to somebody in charge. They must have liked it because they gave me a job. That’s how I got out of Hungary.

I worked for a year and a half at the programming job in Denmark and saved enough money to go to the University of California at Berkeley. I became a programmer at the computer center there. I made just enough money to pay for the tuition.

While I was at Berkeley I wrote a very nice SNOBOL compiler. One of the computer science professors, Butler Lampson, liked the compiler very much and had his computer science students use it in class. When he and a bunch of other professors started Berkeley Computer Corporation, I was offered a job there. When BCC went under, the core group was picked up by Xerox PARC.

INTERVIEWER: Who influenced your style of prograrnming?

SIMONYI: I had two influences–an engineer in Hungary and the computer I worked on in Denmark. My mentor in Hungary was an engineer who worked on the Ural II computer. I was kind of a groupie, just being underfoot and offering free services in exchange for being tolerated in a place where I wasn’t supposed to be. This was not a place for kids. It was one of maybe five computers in all of Hungary and was considered a great asset.

INTERVIEWER: How did you manage to get underfoot?

SIMONYI: My father was a professor of electrical engineering and this engineer was a student of my father’s. I think my father asked him to let me in once as a favor. I made myself useful. First I brought him lunch, then I held the probes, and finally I offered to be a night watchman.

They always turned the computer off at night and turned it back on in the morning. When you turn tubes off and on, the filaments tend to break when they are cooled and heated. In a machine with two thousand tubes, one will break every time you turn the machine on. So they had to spend the first hour of every workday finding the one that broke. When I was there at night, they could leave the computer on and save all that work. So while I was watching it at night, I also managed to use it.

Anyway, the engineer and I became good friends. He was a mathematical genius. He taught me many ot me early tricks about how to think arithmetically, about symbolic problems.

The Danish computer also had an incredible influence on me. At that time, it had probably the world’s best Algol compiler, called Gier Algol. Before I went to Denmark, I had complete listings of the compiler, which I had studied inside and out. It was all written in machine language, so it was both a lesson in machine-language programming and an aesthetically beautiful way of thinking about a compilation process. It was designed by Peter Naur. He is the letter N in BNF, the Backus-Naur Form of syntax equations. I knew that program inside and out and I still know it.

The SNOBOL compiler I wrote at Berkeley, for example, was just a variation on the same theme. I think the Gier Algol program is still in my mind and influences my programming today. I always ask myself, "If this were part of the Algol compiler, how would they do it?" It’s a very, very clever program.

One notion that sticks in my mind is how they scanned the source text backwards. It turns out that in some cases, if you do things backwards, problems that previously appeared complex suddenly become very simple. For instance, resolving forward references can be difficult. If you scan backwards, they become backward references, which are easy to resolve. Just by looking at a program in a new way, what formerly might have been rather difficult to solve becomes easy to solve. The Algol compiler was absolutely full of wonderful tricks.

INTERVIEWER: How did you arrive at Microsoft?

SIMONYI: Once I made a decision to leave Xerox, I put out some feelers. I had lunch with Bob Metcalfe, the Ethernet guy and chairman and founder of 3Com, who left Xerox a couple of years before me. He made up a list of people I should see. Number one on the list was Bill Gates. I don’t remember who number two was because I never got that far.

INTERVIEWER: Is programming a technique or a skill?

SIMONYI: What is programming? People argue about it all the time. Some people call it a science, some people call it an art, some people call it a skill or trade. I think it has aspects of all three. We like to pretend that it has a lot of art in it, but we know it has a lot of science.

Kids learn mathematics in school, and when they finish high school they think of mathematics as addition and multiplication, and maybe even algebra and calculus. But there is an incredible supporting science behind arithmetic, even for a simple operation like addition.

There is also a tremendous amount of supporting science behind computer programming. For example, the mathematical proof for Gödel’s Theorem is very long and complex, but if you use some of Turing’s theorems from computer science, the proof is trivial. Information theory and the other aspects of computer science have a great effect on mathematics, and vice versa.

There is a lot of science in programming, and at the same time it is somewhat of a trade. In fact, for many people, programming is a complex skill, very much like toolmaking, that requires a lot of care. I think if you take a healthy dose of all three [science, art, and skill], you can get some very exciting results.

INTERVIEWER: What is the part of programming that you consider to be art? Is it designing the user interface?

SIMONYI: I think that there is certainly an aesthetic aspect to programs,not only in the design, but even in the appearance, of the user interface. The artistic limitations of programmers come to light when you look at some ugly screens. Otherwise, computer programming is an art just as high-energy physics is an art.

INTERVIEWER: Is the aesthetic aspect related only to how the user perceives the program, or would it also be apparent to another programmer who looks at the program and sees how it is written?

SIMONYI: Absolutely, absolutely. I think the aesthetics of the listings and of the computers themselves have always fascinated me.

The Russian machine, for example, looked like a science-fiction computer because each flip-flop [the on-off device that stores one bit of information] in the machine had a little orange, old-fashioned gas discharge light. Hundreds of orange lights flickered behind glass doors and cabinets. The whole life of the machine pulsed right in front of your eyes.

The Danish computer was a beautiful piece of furniture. It was about the size of an antique wardrobe closet. The front of the computer had three teak doors. I once saw an American executive look at it in disbelief because it was paneled in teak. It even had a Danish-modern console. The whole machine had the intriguing smell of teak.

The Berkeley computer was quite large, about 20 feet long, 6 feet high, and 2 feet deep. It was hidden in a concrete vault that was painted completely black. The computer was a little like the monolith in the film 2001 because of the way it was placed inside the vault with spotlights shining on it.

INTERVIEWER: What do you perceive as aestheticaly beautiful or pleasing in either the listing or the structure of the algorithms when you look at a particular program?

SIMONYI: I think the listing gives the same sort of pleasure that you get from a clean home. You can just tell with a glance if things are messy–if garbage and unwashed dishes are lying about–or if things are really clean. It may not mean much. Just because a house is clean, it might still be a den of iniquity! But it is an important first impression and it does say something about the program. I’ll bet you that from ten feet away I can tell if a program is bad. I might not guarantee that it is good, but if it looks bad from ten feet, I can guarantee you that it wasn’t written with care. And if it wasn’t written with care, it’s probably not beautiful in the logical sense.

But suppose it looks good. You then pick deeper. To understand the structure of a program is much, much harder. Some people have different opinions about what makes the structure beautiful. There are purists who think only structured programming with certain very simple constructions, used in a very strict mathematical fashion, is beautiful. That was a very reasonable reaction to the situation before the sixties when programmers were unaware of the notion of structuring.

But to me, programs can be beautiful even if they do not follow those concepts, if they have other redeeming features. It’s like comparing modern poetry with classical poetry. I think classical poetry is great and you can appreciate it. But you can’t limit your appreciation to just classical poetry. It also doesn’t mean that if you put random words on paper and call it poetry, there will be beauty. But if a code has some redeeming qualities, I don’t think it needs to be structured in a mathematical sense to be beautiful.

INTERVIEWER: Is it possible that someone could read some of your source code and say, "Charles Simonyi wrote this code"?

SIMONYI: Oh yes, no doubt. Whether I wrote it myself or not might be fairly difficult to tell, but one thing is for sure: You could look at it and know if it was written in my organization or under my influence. This is because all the code that I have written since about 1972 has been written with certain naming conventions that are popularly called "Hungarian." You can immediately recognize all the code that has been written under my influence, including Microsoft Word and Multiplan, Bravo, and many others written with those conventions.

INTERVIEWER: What do you mean by “Hungarian” naming conventions?

SIMONYI: It’s called “Hungarian” as a joke. You know they say, “That’s Greek to me,” meaning they don’t understand it, so it might as well be written in Greek. “Hungarian” is a twist on that phrase because these naming conventions are actually supposed to make the code more readable. The joke is that the program looks so unreadable, it might as well be written in Hungarian. But it’s a set of conventions that controls the naming of all quantities in the program.

If you were to break up a program, put it into a grinder, and then sort the pieces, you would find that the bulk of the program is in names. If you just write, "apples + oranges, "the name "apples" is six characters, the operation "+" is one character, the name "oranges" is seven characters, for a total of fourteen characters. Only one character, the plus sign, had to do with the operation. So to me it seemed logical that to make an impact or improve things, I would try to improve the greatest bulk–and that was the names. "Hungarian" is a way of almost automatically creating a name from the properties of the named quantity. Very similar to the idea of calling people Taylor if they were tailors and Smyth if they were blacksmiths.

So if you have a structure with certain properties, instead of giving it some arbitrary name and then having everybody learn the association between the name and the properties, you use the properties themselves as the name. This method has a lot of advantages. First, it’s very easy to create a name–as you think of the properties, you write them down and immediately have the name. Second, it is very understandable, because as you read something you learn a lot about the properties from the name. As these properties get more and more numerous, it becomes difficult to describe them concisely. So “Hungarian” introduces some abbreviated notation to encode the properties in a short space. Of course this is a complete jumble to the uninitiated, and that’s the joke.

Some people think if they can read each of the words in a code, then the program is readable. In fact, readability is in that sense unimportant. Nobody takes a listing, goes up to a podium, and reads a program out loud. It’s comprehension that counts. The fact that you can just read the words and pronounce them is useless. When people see a listing in “Hungarian,” they find these words difficult to pronounce, so they might think it isn’t readable. But in fact, it’s easier to comprehend and easier to communicate because of the association between the name and the properties. People who use Hungarian to program usually continue to use it even after they leave my organization. I have a lot of splinter organizations at Apple Computer, 3Com, and many other companies.

INTERVIEWER: Let’s talk about the process you go through in creating programs. Is there a process you can apply to all programs?

SIMONYI: Sure. If we’re talking strictly about programming, then let’s assume I already know what I want to do. If I don’t, then there is some aspect of the process that is common to all problem solving: What am I trying to do? What is the goal?

For example, I want a text editor to be menu driven, fast, have a spelling checker, and so on. I need to know the end product before true programming begins. Sometimes the choice of the goal depends on what I already have in my bag of tricks. In the case of Bravo, the program was guided by the algorithms. Butler Lampson described a couple of interesting algorithms, so we attempted to write the editor around those algorithms to exploit them. Also, J Moore–he is the Moore of the Boyer-Moore string search algorithm — had some very interesting algorithms for editing documents. Again, we said, "Hey, let’s do an editor that includes the Moore editing algorithm, the Lampson screen-update algorithms, and a couple of caches." Once I have a good feel about the goals, then the real programming begins. I shift gears and sit down, dose the door, and say, "Now I want to program."

INTERVIEWER: When you shift gears and actually start programming, what do you do first?

SIMONYI: The first step in programming is imagining. Just making it crystal clear in my mind what is going to happen. In this initial stage, I use paper and pencil. I just doodle, I don’t write code. I might draw a few boxes or a few arrows, but it’s just mostly doodles, because the real picture is in my mind. I like to imagine the structures that are being maintained, the structures that represent the reality I want to code.

Once I have the structure fairly firm and clear in my mind, then I write the code. I sit down at my terminal–or with a piece of paper in the old days–and write it. It’s fairly easy. I just write the different transformations and I know what the results should be. The code for the most part writes itself, but it’s the data structures I maintain that are the key. They come first and I keep them in my mind throughout the entire process.

INTERVIEWER: Is that the biggest step?

SIMONYI: Absolutely, that is the biggest step: The knowledge of the best algorithms is the science, and the imagining of the structure is the art. The details of algorithms, writing efficient lines of code to implement transformations on those structures, is the trade aspect of programming. Technically, this is called maintaining the invariances in the structures. Writing the code to maintain invariances is a relatively simple progression of craftsmanship, but it requires a lot of care and discipline.

INTERVIEWER: Do you ever get tired of programming?

SIMONYI: Yes.

INTERVIEWER: When you write a program, is it a painful process or a pleasurable process?

SIMONYI: It’s a mixture. I think it’s foolish to pretend that every minute is a pleasure. Like the athletes say, “If it doesn’t hurt, you’re not working hard enough.” After twenty years, I don’t get the feeling of novelty that I did after I had been programming for one or two years. I still get it sometimes, but not as often, no way.

INTERVIEWER: Do you have a routine? Do you program every day or do you walk away from the problem for a while and then stay up for a week to work on it?

SIMONYI: I don’t have a chance to program every day. I don’t have to walk away from a problem, because people interrupt me. My routine is that I program at night and I am interrupted during the day.

INTERVIEWER: Do you come to the office to work at night or do you work at home?

SIMONYI: I work here at the office. I live very nearby, so it’s easy. It’s like going to a different room in your home. Instead of going to the den to program, I come to the office. It’s just two minutes away.

INTERVIEWER: How do you supervise the programmers who work for you? Do you find that you are doing more supervising now than programming?

SIMONYI: I do both, and right now I’m doing more programming. In the Bravo days, the supervision of the programmers was very, very direct. Once I actually wrote an incredibly detailed work order, which was called a metaprogram. It was almost like a program, except written in a very, very high-level language. We hired two bushy-tailed guys from Stanford as "experimental subjects." They wrote the program exactly the way I wanted it to be written and we accomplished two things. First, it was easier for me to work in this incredibly high-level language, essentially programming these people. Second, they really learned the program much better than if I had finished it and given them the listing and said, "Study this program." They learned it because they wrote it. See, everybody could claim that they wrote the program. I wrote the program and they wrote the program. That was really great.

I think the best way to supervise is by personal example and by frequent code reviews. We try to do code reviews all the time.

INTERVIEWER: If you have more than one programmer working on a program, does it develop more quickly?

SIMONYI: Not necessarily. The actual amount of code produced per person is smaller, the more people there are writing the program. Consequently, the total code produced is greater for a while, and then it may actually decrease. With two people, you might get 50 percent more code per unit of time.

By the way, the efficiency of the code also decreases with an increase in the number of people working on the program. The most efficient programs are written by a single person. The only problem is, it might take forever to write, and that is unacceptable. So you have two or three, five or ten, or hundreds of people working on a project.

INTERVIEWER: Can you predict how long it will take to write a program?

SIMONYI: We have great difficulty in predicting the time it will take to write a program. There are valid reasons why this is so. It doesn’t mean we shouldn’t try our best to predict, because there are reasons why a prediction might be useful, just like when a weather prediction has economic as well as other benefits.

Really good programs will live forever and take forever to write, at least as long as the hardware exists, and maybe even longer. Certainly, Bravo lived for as long as the Alto existed. The people who wrote it were just there for the summer. At the end of the summer, one of them left and the other stayed. So the first release took about three months. There were about fourteen releases over about a five-year period.

The same thing is going to be true for Multiplan. When you consider that Multiplan lives in Microsoft Excel, then Multiplan is going to be a continuing story. And Microsoft Excel on the Macintosh is not going to be the last application in the chain either. It’s going to continue on Windows.

INTERVIEWER: When you wrote Bravo, did you think that the Xerox Alto was a machine that everyone was going to use?

SIMONYI: I did, because I was naive. But I was right insofar as the successors of Alto are becoming something everybody can use. In a way, the Macintosh computer and the Windows program are successors of … [Simonyi stops to answer the telephone and talks briefly, then continues]. That was Tom Malloy, one of the summer students I just mentioned–the one who stayed. I haven’t talked to him in a year. He went to Apple and did the editor program for the Lisa.

INTERVIEWER: Why do you write programs? Do you see it as a job, or a profession, or a way of making money? Is it something you are born with?

SIMONYI: I think it is all of those. I had some aptitude when I was young. Even when I didn’t know programming, I knew things that related a lot to programming. It was easy for me to remember complex things. As you get older, it gets harder. The images get less clear.

INTERVIEWER: Why do the images become less clear?

SIMONYI: It’s probably just that aging changes your mode of thinking. Right now, I have to really concentrate and I might even get a headache just trying to imagine something clearly and distinctly with twenty or thirty components. When I was young, I could imagine a castle with twenty rooms with each room having ten different objects in it. I would have no problem. I can’t do that anymore. Now I think more in terms of earlier experiences. I see a network of inchoate clouds, instead of the picture-postcard clearness. But I do write better programs.

INTERVIEWER: Are there any formulas to follow in order to be a good programmer?

SIMONYI: I doubt it.

INTERVIEWER: Is it inherited talent or education?

SIMONYI: There are a lot of formulas for making a good candidate into a good programmer. We hire talented people. I don’t know how they got their talent and I don’t care. But they are talented. From then on, there is a hell of a lot the environment can do.

Programmers get a couple of books on their first day here. One of them, called How to Solve It, is by George Polya, the mathematician. [Simonyi takes the book from a bookcase next to his desk and opens it to a certain page.] These two pages are important. The rest of the book just elaborates on these two pages. This is like a checklist for problem solving. This is the preflight, the takeoff, and the landing checklist. It doesn’t mean this will tell you how to fly, but it does mean if you don’t do this, then you can crash even if you already know how to fly.

We follow these four steps of problem solving: first, understanding the problem, then devising a plan, carrying out the plan, and, finally, looking back. We have about four books like this and I think we make the programmers better than when they arrive.

INTERVIEWER: How do you see the role of the programmer in the future?

SIMONYI: If you are asking if we are going to be as bigheaded as the physicists were, who knows? When any particular science has a string of great successes, there seems to be a tendency for those involved to say, "We knew we were really bright.” Then they want to solve problems in other areas.

What comes to mind is the physicists after 1945. They said, “We really did it! Now let’s look around.” And they looked at biology and cybernetics and they said, “These guys studying brains don’t know anything. They don’t even know how memory is stored. No wonder, because they are turkeys. Let us look at it. We’ll fix it. We’ll apply Heisenberg’s equations, or quantum mechanics, or whatever worked before, and we’ll apply it to brain research and something great will come out of it.”

Sometimes it works and sometimes it doesn’t work. Who knows? Maybe computer science will help decode DNA, and not just by supplying tools. Disassembling DNA could be a hacker’s ultimate dream.

INTERVIEWER: Do you see any great change in the way programs will be written in the future?

SIMONYI: I think computers will be quite a bit more effective than they are now, but I don’t think there will be any great differences. I don’t know that the sixth or the thirty-second generation will do something really drastically different or that great. I am wary of new methods promising wonderful new benefits. I can see incredible possibilities for improvement within the confines of our current methods. I have much more faith in the current methods, not because I am conservative, but because I know that I am not going to lose any of the current benefits either.

I have always worried that when these claimed incredible new benefits come, we will lose all the old ones. Then it becomes a kind of trade-off situation where you have to see if you are better off. I like clear wins. I would bet on improving what we have while maintaining all the benefits and eliminating the drawbacks, rather than introducing new games where there are new benefits and new drawbacks. But I might be wrong, and I’ll be the first to jump on the bandwagon. I have no doubt things will change drastically for the better, but it’s going to take some time.

INTERVIEWER: Why is it taking so much more time?

SlMONYI: Because a lot of dumb ideas have to die first. That’s why progress takes time. First, new ideas have to evolve, then the bad ideas that stop progress have to die. That’s always been the case. Even with relativity and quantum mechanics, the good ideas had to crystallize. And then people with vested interest in the old physics had to die out.

INTERVIEWER: Can you give an example?

SIMONYI: If I mentioned something that is universally abhorred like punched cards I would not be contributing much. So I will have to take a potshot at something that most people believe in. I think that the “cult of simplicity,” the idea that simplicity is a desirable end in itself, is highly suspect. For many years this has been a heuristic enabling us to focus on the problems with the quickest payoffs. But it is just a means. I think that computer science, together with all the other symbolic sciences (mathematics, physics, and modern molecular biology) will be revamped by the understanding of very complex phenomena. Mathematics is leading the way with the discovery of very complex fundamental objects. The traditional name for a class of these objects, “simple groups,” ironically reflects the old belief that “fundamental” is equal to “simple.” Well, maybe it isn’t. In computers we may not get anywhere with real artificial intelligence, user interfaces, languages, and so on by harping on simplicity.

INTERVIEWER: What do you do when you aren’t programming? Do you have any other interests?

SIMONYI: There are some other interesting things that I wouldn’t mind spending some time with. I have dabbled just a bit in Egyptian hieroglyphics. Learning other languages, traveling, and seeing the world are great activities, and I wouldn’t mind doing them. I also have a private rotorcraft (helicopter) pilot’s license.

I don’t think programming is that much more important than anything else. But if you look at the business side, then it becomes a different story. It’s really the business that keeps me occupied more than just programming. In the course of business, I program more than I want to.

INTERVIEWER: Do you think your time might be better spent on the business side of programming?

SIMONYI: No. I’m just saying I do programming because it’s a business. Not just because I love programming, but because I love the business. It’s not because with every line I write I say, “Hey, I get great pleasure from writing one more line, so let’s write because I’m getting more pleasure.” No way. I probably wrote this line ten times already. It can get pretty tiring just typing the bloody thing until my fingers hurt. So when I’m doing that, I’m doing it because it’s part of the business, and I want to do the business.

The key difference between programming in the abstract and programming as a business is that there is a solid purpose in business. Otherwise, it is just an abstract activity, like playing a game of chess. When you are at the end of the game, you jumble the pieces. The game is gone. When the program is done, some people use it, and I see they enjoy it, and I derive enjoyment from that. Some of them even pay for it, and some of that money finds its way into my pockets, which I then spend on visiting Egypt, or flying a helicopter for half an hour, which is, by the way, a lot like programming projects: The launch and landing are spectacular, the ride can get very tiring, and the whole thing can come apart at any time.

INTERVIEWER: How do you regard other programmers of your time?

SIMONYI: I have a great regard for the men who influenced me in the past. I regard them very highly. But I also have a great regard for the people I work with now.

INTERVIEWER: Do you associate with any other programmers who have developed major programs? Do you trade ideas with them?

SIMONYI: I have great regard for the competition. I’ve had the pleasure of meeting Bob Frankston and Dan Bricklin [the founders of Software Arts and writers of VisiCalc] at a couple of trade shows. I once met Jonathan Sachs [a founder of Lotus Development Corporation]. But unfortunately we don’t move around much and not many of these programmers have a reason to come to Seattle. Bruce Artwick [who wrote and designed Flight Simulator] sometimes visits, and the guys at Apple, like Bill Atkinson [one of the Lisa programmers who later developed the MacPaint program for the Apple Macintosh computer] — I think Atkinson is the greatest–and Bill Budge [who programmed Pinball Construction Set for Electronic Arts]. These guys are all great.

We don’t have much to talk about. We feel good vibes and exchange three or four words. I know that if one of these guys opens his mouth, he knows what he is talking about. So when he does open his mouth and he does know what he is talking about, it’s not a great shock. And since I tend to know what I am talking about, too, I would probably say the same thing, so why bother talking, really? It’s like the joke tellers’ convention where people sit around and they don’t even have to tell a joke. They just say the joke number and everybody laughs.

It would be great to be able to work with all these guys, but we are business competitors. I think we could do incredible stuff together. Maybe the Martians will invade and we will have to do a Manhattan project in computers. We would all be shipped to New Mexico. Who knows?

(All Rights Reserved. Copyright 2008, Susan Lammers)

---

5200 22 7200 4 5240 16 5006 4   1 00 0001 0 1 22 6570 4 2 13 5214 0 2 22 5376 0 3 22 5311 0 3 22 5306 0 4 22 5171 4 4 02 7542 0 5 22 5341 0 5 14 5515 0 6 22 6631 4 6 21 5123 0 7 11 0014 0 7 02 5121 0 5210 21 5345 4 5250 16 5012 0 1 25 2302 0 1 22 5373 0 2 22 5074 0 2 22 5171 4 3 11 0002 0 3 00 0000 0 4 21 5355 4 4 11 0016 0 5 22 7000 4 5 21 5415 4 6 56 0000 4 6 22 6570 4 7 02 5002 4 7 22 5036 0 5220 16 5006 4 5260 16 5005 0   1 02 0000 4 1 25 2267 0 2 22 5332 0 2 22 5074 0 3 11 0001 0 3 22 5015 4 4 21 5415 4 4 22 5015 4 5 25 2304 0 5 22 5134 4 6 22 5074 0 6 02 5011 0 7 22 7342 4 7 11 0001 0 5230 00 0002 0 5270 22 5157 4 1 14 5514 0 1 22 5522 0 2 21 5415 0 2 22 5435 4 3 25 2300 0 3 22 6512 0 4 22 5074 0 4 22 5435 4 5 02 6077 0 5 22 5022 0 6 16 5012 0 6 22 7342 4 7 02 5002 4 7 00 0002 0 Oct 8 11:59 1985 example 1 Page 1 vfii.dypAfter = 0; if (vfii.cpMac = = caPara.cpLim) { int dyp = vpapFetch.cyaAfter / dyaPoint; vfli.dypLine += dyp; vfli.dypBase += dyp; vfli.dypAfter = dyp; vfli.dypAfter = dyp; } /* First, need to scan thru grpchr, till we find a chr whose ich is >= ichMac (this can happen because we add a chr and then decide to do the line break before the character indexed by chr.ich) or until we reach &(**vhgrpchr)[vbchrMac] */ for (pchr = pchrBeg = &(**vhgrpchr)[0], (char *) pchrMac = (char *) pchr + vbchrMac; pchr < pchrMac; (char *) pchr =+ pchr->chrm) if (pchr->ich >= vfli.ichMac) break; /* Now, enter chrmEnd in grpchr. Note: no need to check for sufficient space*/ vbchrMac = (char *) pchr – (char *) pchrBeg; pchr->chrm = chrmEnd; pchr->ich = vfli.ichMac; Scribble(5, ‘ ‘); CkFli( ); return; } Top: code written in 1965 on the Russian-made Ural II computer. All changes had to be patched using goto’s (instructions beginning with &quot;22&quot;). Bottom: “Hungarian” code from Microsoft Word. The name vbchrMac, for example, shows that the variable is: global (v), current maximum pointing one beyond the last element (Mac) based pointer to a group (b) of chr structures. The name chr has further meaning: character run, which is specific to Word. See the Appendix (page 383) for a sample of Simonyi’s &quot;early Hungarian style.