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
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
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
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
GAM: It was a very exciting time, all the time.
HM: Yes, it was. We were given a lot freedom to work on interesting
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
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
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
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
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
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
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
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
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
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.
For information about this page, contact us at: firstname.lastname@example.org