An Interview with Henry Moll

HM = Henry Moll
GAM = George Michael

GAM: Today is the 30th of April, 2008 and I am interviewing Henry Moll. Why don't you start, Henry, by telling us where you went to school, what your degree was, and when you came to the Laboratory?

HM: OK, I went to school at Berkeley, where I had a double major of Mathematics and Physics, then to the University of Oregon for a year in Mathematics. I met John Killeen there; he was recruiting for the Laboratory. I signed on, dropped out of school, and started at the Laboratory in 1959. When I showed up, my clearance preceded me so I didn't spend any time in the cooler; I came directly through the gate and to work on day one.

GAM: That's very nice. Is it safe to assume that John was your first supervisor?

HM: No, no, Tad Kishi took me in. I sat around for a couple days, waiting for them to figure out what to do with me. Larry Larson, another new hire, and I shared an office. We whiled away the time reading Camus's "Myth of Sisyphus", mentally adjusting to the right mind set needed to work with computers. Soon I was assigned to put SIMON on the LARC. The LARC hadn't arrived yet, but it was imminent. Nobody felt that SIMON would fit on the LARC and give any kind of meaningful output, because the capacity of the machine wasn't large enough. I guess that was why it was assigned to me. No one else wanted to spend time on a project that had little prospect of success. I soon came to realize that the proposed implementation was not going to result in a meaningful simulation. There was talk that re-ordering the difference equations may offer a solution because less data would need to be accessible in central memory, all at the same time, to perform a critical computation during each time-cycle. The LARC's memory was 26,000 words with 250,000 words on four or so spinning drums. The question was, would reordering the equations lead to a correct result? Without telling anyone I decided to find out and reordered the difference equations. Instead of moving all the data from time Delta T to Delta T+1, some advanced that way, the rest advanced from Delta T-1/2 to Delta T+1/2.

GAM: And then interpolated, yes...

HM: No. Interpolation was inherent in the reordering. There were some previous computations to compare the results to. A very small version of SIMON had run on an older IBM machine. When I got SIMON running on the LARC, the answers agreed with the smaller version to four or five places.

GAM: Hum, that's neat.

HM: Yes, And so it worked out that I sort of, overnight, became well known in A division. Strangers would introduce themselves to me and compliment me for a good job.

GAM: And this carried you for what, a year or two?

HM: It took about nine or ten months to put it on the LARC.

GAM: So, we're now into 1961.

HM: Yes, and I met you, for the first time, at the Hungry Truck, at three o'clock one morning. I went there with Chuck Leith and Roy Nutt from CSC (Computer Sciences Corporation). CSC was writing a Fortran compiler for the LARC. That's when I was introduced to you. I was just a new guy, I didn't know anybody or anything about computers. Working day and night in that environment, with the pros, was really great. I learned so much, so fast and made many friends. That was my best time at the lab.

GAM: All of us did. Chuck is a marvelous, marvelous, person. By the time you met him, he had his Ph.D. in Mathematics from Berkeley.

HM: I think he was just finishing it, because he wasn't there when I first got there. He came when I was about half or three quarters of the way through SIMON. He was working on his atmospheric model; he was putting it on the LARC. He needed a fast plot routine because he wanted to make a movie of the "weather"--he needed 3 plots every cycle. So, I wrote a fast plot routine that I also used for SIMON. He used that to make his ninety-second movie. Others started to use the plot routine and it became the LARC plot routine.

GAM: Yes, I worked with him on the atmospheric model. He was using a semi-global projection that would show the maps of the Northern Hemisphere. They displayed, aside from the continental outlines, the isobars of the various dynamic fields. Pressure, water vapor, wind velocity, stuff like that.

HM: That's right. It was in color. He took each "weather" picture three times. Then he would develop one in red, one in blue, one in yellow, and superimpose them.

GAM: Right, we merged those through the appropriate filters. The first movie he made, I actually took the black and white film down to a photo-finishing studio in Hollywood. Linwood Dunn was the guy who invented what was called the ACME printer. We got that name because it was a lath bed made by ACME. He just put cameras and projectors on the lath ways and insert filters in between them and he could get the colors he wanted. He put color film in the camera and gets the projector to skip frames so it would project the picture, then skip forward three, take another picture, skip forward three and so forth. So it was red, green and blue or something like that. Forgot the colors now but that was a fun time.

HM: The LARC had two built in movie cameras which were user programmable via software. One could either plot points or vectors. Given two points it would draw a connecting vector. A vector might have one point in the frame and one point out of the frame. The LARC required both be in the frame. In this case, one would have to compute the intersection of the frame with the vector to determine the "in-frame" point. That took too many cycles. A faster method was to compute the midpoint of the vector. The midpoint would either be inside or outside the frame. Two or three iterations would result in a "midpoint" inside the frame and close enough to it to suffice. This was an application of "thinking" binary convergence that I learned from Chuck. He also showed me how to do fast merges and sorts which he picked up from Roy Nutt.

GAM: That's delightful. So, you ended up, in a sense, working with Chuck Leith a lot?

HM: When he was doing his atmospheric model I provided the plot routine. I didn't work with him after that, but we became good friends and went backpacking several times. We had to write memory dump routines, printer routines, root routines, everything. The LARC came with just simple tape and drum drivers. I wrote a routine that would label the first page of printer output with the person's name using regular sized characters to draw a big character. The first time I tried that, there was somebody using the computer and I was just standing there, so I figured I'd wait until he printed something out and see if it worked. And so the printer started printing out and it printed Z-I-Z-Z-O, and I figured, oh man, I really screwed it up--how could I mess up something as simple as that? And then the guy who was running the computer came over to get his printout. I looked at his badge, and his name was Sam Zizzo. So, it wasn't a bug after all. But, it was a coincidence to have someone with three Zs in his name be the first user. He and I became good friends after that. He is a very pleasant person.

GAM: Did you go to any other machines at that point?

HM: No, I got SIMON working on the LARC. The CDC 6600s were coming some time in the future so, after I got SIMON running, I started converting it to run on the 6600s. I remember that I used another CDC machine (3600?) to debug most of the code for the 6600. LARC SIMON was used a lot and many little additions were added on--I was busy. I wrote a controller to run and control other codes from a input deck. I did something on the IBM 650. My first weeks at the Lab I wrote a little "homework" thing for the UNIVAC. The UNIVAC was something else. The people who built the cabinet enclosing the machine must have built submarines during WWII. One entered the UNIVAC thru a "hatch". The passage from one cabinet to the next was an oval hatch with battens! The interior was stuffed with cables and gear and was illuminated by red lights in cast iron cages. I loved it. Maybe it was blue lights: battle station lights, so you don't lose your night vision.

GAM: The CDC 6600s came in 1964.

HM: So, I guess I was working on the LARC for some time. Something that was very useful: The LARC would emit a tone whenever the P-counter was active within a fifty word section of memory. You could hear the computer computing, doing its stuff. The ear is very perceptive of sound patterns. I could hear the difference equations being solved, and this enabled me to discover bugs. An off note exposed a problem and its place in the melody revealed its location within the equations and thus within the code. I once found a bug over the telephone. I was on a month-long vacation in Canada. I had found the "last" bug before I left, and assured Alan Winslow that there would be no problems. SIMON had been running for many hours and hung up the same time I checked in by phone, as we had arranged. They had a problem--it wasn't computing correctly. There was a telephone right there on the LARC's console. I had them run a few cycles while I listened over the telephone. I told them where to look in memory and to read out what that word contained. I told them how to change and to try it. It worked, fixed. The LARC had lots of radio tubes inside its chassis. Sometimes it would malfunction and you would go behind one of the chassis where the paint had worn off and give it a kick on the worn spot, and that would shake the tubes a bit and it would start right up again. This computer still had the fear of man in it, and it responded to the appropriate abuse. I liked that computer. Computers nowadays have no fear of man. There is nothing one can do to get them to work once they set their mind against it. This doesn't bode well for the future.

GAM: It was a very exciting time, all the time.

HM: Yes, it was. We were given a lot freedom to work on interesting problems.

GAM: We called it the Golden Age.

HM: Yes, it was. These were the first big computers and the first usage of them to do real things. It was exciting. Otherwise, you couldn't get people to work all day and all night for weeks at a time.

GAM: So, go on now.

HM: OK, when I arrived there in 1959, I had never heard of computers. I didn't know anything about them, but I had taken many math classes and, especially, formal logic classes. The Predicate Calculus and things like that. Essentially, a computer is just a logic machine, so I didn't have any problem understanding how to use it. The formal logic courses I had taken at Cal along with set theory and computer experience at machine instruction level here at the Lab came together into a personal intuitive gestalt. SIMON was written in assembly language, that's all there was. If you wanted things to run fast, you wrote in assembly, you'd probably pick up a factor of four to six over Fortran. In those early days, speed was an important factor. You would develop a set of routines that you could carry from one machine to the other. Even though they were in assembly language, you simply had to make a few simple changes to use them on a new machine. When a new machine arrived it came with just a minimal operating system. We had to write our own cube root routines, square root and log routines etc. The way taking a square root is taught in school is OK, if you're using pencil and paper, but may be CPU-intensive when done on a computer. There was a fellow here at the Lab, I don't remember his name, he was versed in sixteenth-century mathematics from the Renaissance, when finding cube roots and square roots was the focus of mathematics. There were many different "old" ways of doing it. Some of these ways might have been cumbersome to do with pencil and paper, but they were efficient when done on a computer (few or no divides). He coded up some of these ancient methods of finding roots and we used them.

GAM: Somebody at the Lab?

HM: Yes. I don't know what his name was. It was sixteenth century math. Felt good using that old stuff on new problems. A feeling of continuity. Like now, for instance, I'm reading a book on the foundations of differential calculus. It was written by Leonard Euler.

GAM: OK, go on.

HM: Well, then it was time to move SIMON over to the CDC 6600, which hadn't arrived yet. But there was another machine made by the same company, the 3600, and that was up and running, so I was able to write and debug a large number of subroutines that I was going to eventually use. When the CDC 6600 came, I was well on the way to having SIMON up and running. And I'm not sure if I was the first, or the second, to get a production code running. Bill Bennett, was working on CORONET. I think he may have gotten his program there first, I'm not sure. But the CDC 6600 was a very nice machine. It had visual readout that humans could read instead of having it all in a battery of binary lights that you convert in your head into something meaningful. It displayed readable text. This was my first hint that computers could do more than crunch numbers. They could also crunch words. I remember that we had serial 1 of the CDC 6600. When I got SIMON up and running on the 6600 it wouldn't duplicate answers. Every time I ran it, I would get a different answer. There was something wrong with the machine, and I spent several weeks working on it. I finally narrowed it down to a sequence of a dozen or so instructions, I could get it to fail every single time. I would bring it over to the engineers and they would open up the door to the back panel and hook up their scopes and everything, and then I would run it and it wouldn't fail. This was quite a problem, and then one of the fellows noticed that, on the big sheet metal door, there was an iron rod that ran diagonally from one corner to the other for support and, when they closed that door, this iron rod lay parallel and on top of a 27-inch wire that was there. After the first two months, when the machine was up, this metal rod that was supporting the door became magnetized. Soon, there was enough impedance so, every now and then, it would slow down the current in this wire that was lying next to it. The longer the machine ran, the more magnetized this rod became, so this was a problem that wasn't there in the beginning, but it started to show up, and became worse and worse. They put some insulation on it, and that solved the problem.

GAM: Chuck Leith, whose atmosphere model pushed the memory very hard, found that he should run it twice. If there was agreement, OK, and if there wasn't agreement he knew exactly where the problem was going to be and they'd work on it. That technique of running stuff twice was used by all the engineers to debug the machine and run routine maintenance on it.

GAM: You were working with SIMON then?

HM: Yes, I was working on SIMON with Alan Winslow, Wes Nelson, and George Bundy. SIMON was pretty well established by that time, and I had plenty of free time--things that required my time were beginning to taper off. At this point in time, the TMDS was starting to show itself and was becoming workable. And we had a machine (the 6600) with enough memory so people could keep their code on the machine as opposed to keeping it in card decks or on tape. I was assigned to A-Division at this time. Pete Multhrup, who was head of A-Division, came and said "We have this new thing called TMDS and I'm going to get you one--see what you can do with it." He had Alex Cecil come over to talk with me, to give me some ideas about what he thought we could do with it. Alex gave me some literature, I think it was about some other languages, some macro-languages, and he felt that a macro-language might be a pretty useful thing. And I took it from there. I wanted to write a language that was like an algebra for characters as opposed to an Algebra for numbers. And since I had studied group theory and formal logic I had a fuzzy idea of what I wanted to do. Sid had told me I could work on whatever I wanted to. I now think he meant I could work on any "on-going project", not on "anything" I wanted. I was thinking of something like what in mathematics is called a group. The objects of the group would be the letters of the alphabet along with numbers and punctuation etc., either as single characters or strings of characters. The group operations would be concatenation and substring. The result of these operations on any member of the group is also a member of the group. A null character, null string, and null file were added to eliminate special cases and simplify the logic. A string of computer instructions (code), operating on a string of characters (data), is itself a string of characters. Code and data are distinguishable only by context. One fills the computer's memory with code and data and points to the location of the first instruction. The next sequential instruction is pointed to by the preceding one. Thus data may become code and code data. This fuzzy thinking led to a form of recursion similar to the Lambda Calculus. Recursion is very powerful. I wanted to be able to use it interactively. A glass display like the TMDS opened a new output mode for a computer. A computer became something like a chemist's lab where experiments could be performed and results studied immediately. Change this compound or that quantity and do the experiment again and compare this result with the previous one. This is the way most personal computers are used today. I spent about nine months creating and writing TRIX. Alex Cecil, the first user, helped by testing the language and making many useful suggestions. His support and enthusiasm were material to the eventual success of TRIX. Alex used this language to write the TRIX AC text editor. Within a few weeks of its being available, everyone was using it.

GAM: It revolutionized what we were doing at the lab.

HM: Yes, it just changed everything. It was remarkable; it was very satisfying. Alex deserves most of the credit because he wrote the AC editor. He and I would work together, he would say, "I need to do this more efficiently" and I would add an argument to some command that would achieve it. We worked very well together.

GAM: It's an interesting piece of statistics. When TRIX AC was running, the time transition would count who was starting and stopping and stuff like that. Turned out that there were over fourteen hundred logins on TRIX a day, the rest of the problem solving stuff was maybe three hundred or four hundred, depending on what they were trying to do. So, the vast majority of the people found the environment good and the response excellent. They used TRIX like it was their staple--they learned how to run everything from TRIX.

HM: I wrote TRIX and Alex wrote TRIX AC. By the way, I chose that name because it's short. In those days we had these Western Union Teletypewriters, which were very slow, what you typed in you wanted to be short, two or three letters and TRIX is just four letters and one syllable. I think Sid felt I chose the word TRIX because I was using "tricks" to get the thing to run fast and, in the process, degrading the system. Actually, it was from Billy Holliday's "Trix Ain't Walking No More". It was short and one syllable which is also positive from a marketing point of view. When I was at the University of Oregon, I was teaching mathematics and I really enjoyed teaching. I was teaching mostly freshman.

GAM: Where?

HM: At Eugene. We didn't have to sell it. There was such a response--everybody wanted to learn how to use it. Everybody started using it right away and so I said I would give classes on the TRIX interpreter and I would give as many classes as they wanted, but I wanted to limit the class size to six or seven people and it most likely would be the six or seven people in the same hallway that were doing the same kind of work, so they would have the same sort of problems and the same kind of questions and they would know each other so they wouldn't be inhibited from asking dumb questions, for example. And, so, I set up a sequence of fifteen or so classes. I would go around from one building to another. I didn't have to prepare for these classes because they would be driven by the questions that this small group of people had. And since the group was small, it was more or less like a conversation I was having with these guys. They were asking questions as they came to mind perhaps from the previous question. That is a very effective way of teaching. The classes lasted as long as the guys had an interest, like a week or so.

GAM: Somewhere I heard, maybe it was from you, that the program TRIX had drawn some of its inspiration from SNOBOL, some from the thing that Moore wrote, and LISP.

HM: Yes, SNOBOL and Moore's TRAC, but not LISP. LISP came later.

GAM: There is no question about that really being good, but beyond that, it was a seamless usage on the machine. You know, you made the TMDS and the teletypes really sing. People didn't have to pause and think about do this or do that, they just naturally came out the right way.

HM: Well, when I devised that language, I wanted it to be ambiguous, as opposed to concise, because I felt that with an ambiguous language, you could write poetry, for example. You could do many more things that would be of interest to human beings if the language was ambiguous. It had about fifty rules and five hundred special cases. Two people might be doing the same thing with TRIX, but each of them might solve it a different way. One didn't understand why the other guy's stuff worked. This fellow's intuition led him this way and the other guy's intuition led him to the same results, although by a different path. I was pleased with that, that it was ambiguous. Since I wrote TRIX, I've come to understood more about the Lambda Calculus, and how useful it is. Basically, it's recursion. I read some work by Alan Turing. The idea I think he had in mind was that there is no difference between code and the data. Tell the machine where to begin interpreting what it finds there as code. Each piece of code points to the next piece (the default being the right adjacent piece). Code and data can change during run time. Data can be interpreted as code and code can become data. It is very subtle, it's very powerful and impossible to debug. Another reason that AC was successful, aside from the fact that it was a very uesful piece of code, was that Alex was very responsive to people's suggestions. As a matter of fact, many of the commands were suggested by users. It was easy to incorporate new things because TRIX was an extensible macro language, very much like EMACS. It was very satisfying work. We were working directly with the users at all levels, from secretaries down to physicists.

GAM: In the later years, TRIX AC was rewritten for every machine we had.

HM: TRIX had to be rewritten for the CRAY-1. I didn't want to use FORTRAN. One reason was that FORTRAN couldn't open binary files. TRIX could open up any kind of a file. And lots of times, people would get a file that they couldn't open and they wanted to find out why. TRIX could do that. Once an Air Force General came to Harry Nelson, who was my supervisor at the time. Harry asked me go to the cooler where there was an Air Force Colonel with a computer tape that they said had secret information on it, about nuclear weapons and where they were stored, and for some reason they couldn't read it. So, I escorted the Colonel inside so he could hang the tape on one of the machines and use TRIX to open it up and look at it. That was the advantages of TRIX being written in assembly language; at that level, it could open up any kind of a file, even if it was gibberish. It would display as gibberish, but if the person knew what the gibberish meant, he could make sense out of it. But, to get back to your question about rewriting it each time, that's true. Going from the CDC 6600 to CDC 7600 wasn't any problem, because the instruction sets were almost the same. When the STARs came out, I didn't want to put TRIX on the STARs, because I didn't think the STARs were going to succeed. Instead, I concentrated on the CRAY-1. The CRAYs came a little bit after the STARs but, at that point, I felt that what I needed to do was to write an intermediate, let's say, a machine-independent assembly as a P-code. And that way, I could write TRIX in the P-code and then bring up the P-code on whatever machine it was going to run on. The P-code could be very simple and straight forward and would be easy to implement. I actually got that up and working on the Cray-1. It wouldn't have been a good long-term solution because even the though the P-code was very good for doing the basic CPU work, the I/O problems with each different operating system, on each different computer, were going to be too much to overcome. For example, at Los Alamos, they had an operating system running their CDC 6600 that treated the disks as logical tape units. So, you had to rewind the disks, space them forward and backwards and all that sort of stuff. It was just ridiculous. No random access.

GAM: I remember those stories.

HM: Eventually, the big machines adopted UNIX as their operating system. The Lab had some very nice workstations that ran UNIX. I wrote AC (not TRIX) in EMACS LISP which is in the public domain and comes bundled with most UNIX systems. EMACS is an excellent editor written in EMACS LISP. With the LISP version of AC, lab users making the switch to UNIX had a familar editor to use. AC ran in the right half of the EMACS editor's window, EMACS in the left half. AC was, in essence, an extension of EMACS, thus AC and EMACS could both be working on the same file without any conflicts. Users could switch between the EMACS and the AC windows, using which-ever editor was best suited for the job. My last day at work, I found and fixed the "last" bug in the AC LISP code. The "last" bug because it was my last day at the Lab and thus the last bug I was going to find.

GAM: When was this?

HM: 1991. Because AC was implemented in EMACS, and EMACS is in the public domain, and it has its own copyrights, anything written in EMACS is in the public domain. AC is on my MAC at home, and I still use a few of the AC commands because they are still better than anything else.

GAM: Well, back to the evolution of TRIX. How big was it? And can you quote a measure of speed?

HM: Speed was a difficult thing to determine because it depended on the load on the machine. When they first came up, the machines were not being utilized much during the daytime. So, during the day time, it response was instantaneous. You would say, "display all occurrences of pattern P" and it they would immediately come up on the TMDS. It was similar to what we have now with our personal computers. It was that fast. When a user opened a file to edit, TRIX would convert the file into equal length line segments, that is, into a rectangular array of characters where the nth line of the array contains the nth line of the file suitably padded out with space characters. Thus the location of line n could be computed as opposed to searched for which is slower. The array format made it very easy and fast to extract columnar data found in the data dumps of the simulation codes. After the initial overhead of unpacking the file, search and replacement was very fast.

GAM: Isn't there a difficulty getting it back into the original form?

HM: No, that just required truncating the space characters off the ends of the lines and adding "end-of-line" characters.

GAM: OK. Cralle and I were doing incredibly smart things with TRIX. Using it, and operating on the dictionary we had, learning very funny things about words. Bob was good at making TRIX do strange things that were very clever and wouldn't naturally occur to somebody.

HM: Yes. When TRIX was first up and running people were still using the teletype. There was a blind fellow, I think he name was Jim Slagel, and he told Alex that certain non-printing characters would jiggle the teletypewriter in a way that he could distinguish, and so he wanted to use these non-printing characters so they could give him cues as to where he was. Normally, TRIX would filter these out. Alex put some of these non-printing characters into certain edit commands. Most people wouldn't notice they were there, but Slagel heard them and knew how to interpret them. Harry Nelson discovered a new, large Prime number, four or five hundred digits. He wanted to include the Prime in a paper he was writing, He didn't want to format it in by hand. TRIX RED formatted that number as though it were just a very large word.

GAM: That says to me that TRIX RED was around longer than I imagined initially. I thought it was something that came up rather late.

HM: No, it was there with the CDC 6600. Bob Kuhn went to Israel to give a paper and he wanted to write it in Hebrew. He did something to get the Hebrew alphabet on the machine so he could print it out. Then he needed the text to run from right to left instead of left to right. It was very easy to change the direction of the scan to do this because nothing was dependent on the scan direction.

GAM: I remember now, Calvin Moore's program was TRAC.

HM: Yes, TRAC. I got some ideas for TRIX from TRAC.

GAM: Well, I think TRIX went much further than TRAC, more than COBOL and any of those others. It was a very, very powerful thing. And I don't see any modern stuff coming along like that. Let's go back and fill in.

HM: OK, remember that you invited me to come to the Department of Applied Science and give a talk on memory allocations in TRIX? John Fletcher came and sat in the front row. I explained that, an interpretive language like TRIX, generates many symbols (names of things) that have to be stored someplace in memory, available for subsequent use. You need to have a very efficient look-up routine to access these symbols and the data associated with them. There is no limit to the number of symbols and therefore you need a robust memory allocation routine. I skimmed some books by Donald Knuth and implemented something based on things I read there. My allocation routine consisted of 256 linked lists. A hash of the symbol selected one of the linked lists. A linear search of the list leads to the symbol.

GAM: What was it for?

HM: For looking up items in a ordered list. You have a very large list of random numbers in numeric order and you want to locate number N or determine that it is not in the list. One way would be to begin at the beginning of the list and sequentially check each number and compare it to N. This method would, on average, require L/2 comparisons, where L is the length of the list. With the binary search, you'd look at the entry in the middle of the list. Because the list is ordered, you can determine in which half N is in. Then you compare N to the entry in the middle of that half of the list. Repeat as often as necessary for the process to converge to to single entry: N or not N. Each time you reduce the size of the list by a half. So, your search converges by one over two to the n. You hadn't heard about that?

GAM: I think so. At my age now, I'm not sure what I knew and when I knew it. I'm 82 now and I don't like it!

HM: You have to deal with it anyway, but you're lucky because your mind is still sharp, you know.

GAM: To some extent, my body doesn't like it either. But, continue on now.

HM: OK, I remember when TRIX was pretty stable. At the beginning, it was pretty hectic, everybody was using it. I was inundated with people phoning up asking questions, making suggestions. I was busy trying to keep up with things. After a while, things settled down, and I felt that it was time to use TRIX to do word processing. That term didn't exist then. I had written the document for TRIX, how to use it. This document existed as a deck of cards, so I could put it on the machine and print it out, but I wanted to format it in a nice format. And I wanted to be able to add to it, I needed a tool so that I could format the document that described the TRIX language. So, I started working on a word processor in TRIX and this became known as RED (Report Editor).

GAM: RED PP?

HM: RED PP was the "Post Processor. I believe it formatted the document for various printers.

GAM: Yes, was that John Beatty's contribution?

HM: No, that was Joe Rinde from Carnegie Mellon. He was here for a summer. John wrote a parser in TRIX. I'm not sure about the difference between RED and other PPs, but I wrote RED. There was a lot of work there. First, it would format one column per page. Then I upgraded it so it could format two columns on the page. You could embed diagrams, pictures, illustrations or equations and the text would flow around them. So, it started out simple, and it ended up being able to generate indices and tables of contents. When a page reference moved because of inserted text, pointers to it would follow so the reference would always be correct. The people in the documentation department eventually transferred their documentation work to TRIX RED.

GAM: What is the status now. Is TRIX running anywhere?

HM: I don't think so. The last thing I did at the Lab was implement TRIX AC with EMACS Lisp on UNIX. AC is running on my MAC.

GAM: The new architectures for these so-called supercomputers don't lend themselves at all to what TRIX needs to do.

HM: Well, EMACS will do just about everything you do with TRIX. You can write little macros and then you can build on these macros, so you can do all kinds of things.

GAM: Are you active programming now?

HM: I program just about every day.

GAM: For whom?

HM: For myself. I'm trying to make money in the stock market. I have big databases, and I have to have ways of searching these databases. I have to have ways to document, I want to be able to look at the plots, to look at the data and identify changes in trend. And, then, I have to manage the money that I do have. So, I have quite an extensive set of routines that I have written over the years.

GAM: Great, that occupies you most of the day?

HM: No, no. The market closes at 1:00 p.m. our time. So, from 12:00 a.m. to 1:00 p.m., I might be active buying and selling things. And if I'm making a lot of money, I'm motivated to program. If I'm losing money, then I read books.

GAM: That works pretty well!

HM: Yes, Keeps my brain from slacking off.

GAM: Well, is there any other stuff you want to cover at the moment?

HM: No, I can't think of anything right now.

GAM: OK, well, we'll stop right here with the agreement that if stuff comes up we will resume.