The interview date is unknown
MSM: How did you get involved? When did you encounter UNIX?
Condon: I don't know. I mean I guess I was in. I moved out of physics and moved into a project for Hank MacDonald. Local area switching, and that was in room 13. It was in this hallway on the fourth floor. That was one of the systems used on some of the computers. Later on there were other people who had small operating systems running on Honeywell 516s. It didn't really do any real numerical computing. It was just an operating system that somebody else provided that had the right properties and was easy to use. I've never been much interested in the operating system. When I finally did join this group, which were really because of political personality problems with Hank MacDonald in Division 13, I came over and asked Sam Morgan for a place to sit and something to do. From there Sam found problems. So I was learning UNIX at that time with commands that were there.
MSM: When was that?
Condon: I don't know, maybe fifteen years ago.
MSM: The early 70's.
Condon: Yeah, the early 70's. Anyway, Bob Moore who was in the group would come around and say, "How do you understand what these commands do? The manual pages aren't all that clear." He would say, " What do you think is the reasonable thing to do?" Try some experiments with it and find out. I think that was a very interesting clue. At least his philosophy and some of the other people's philosophy, of Dennis's also, of how system commands should work. It should work in a way that is easy to understand. It shouldn't be a complex function. Which is all hidden in a bunch of rules. The field of cognitive engineering with the idea, I think the concept of cognitive engineering is in later or was independent of these guys. The idea is that people form a model. You present them with some instruments, tools, like a facet, electric stove or something like that and demonstrate how it works. They then form in their heads a model that shows how it works inside to help them remember how to use it in the future. It may be a totally erroneous model of what is going on inside the black box. What in fact is going on inside, I think Bob Morrison is telling me, I know he felt this way, is that the black box itself should be simple enough. Such as when you form a model of what is going on in the black box that's in fact is going on in the black box. Write a program to try and outwit and double guess what they're going to want to do. You should make it such that it is clear about what it does. Nobody's ever talked about it. As far as I know, I'm the only one that's ever discussed it.
MSM: Maybe other people will.
Condon: You tell me.
MSM: It's interesting. It's of a piece of what people have been saying. Indeed a piece of what myself felt as I've encountered it. This notion of people forming models and things. In an idea some engineers grasp it whether they verbalize it or not and others don't. A fellow, Don Norman was doing this.
Condon: Yeah that's exactly cognitive engineering.
MSM: Talking about the design [interrupted]
Condon: Most of it's bullshit but there is a core of good ideas you have to pay attention to.
MSM: It's funny because I was thinking of Don Norman as I was driving up here today. I heard him give a talk last year. I went out to dinner with him and one of the things that bothered me about the talk was that I somehow felt I knew all this. I wasn't being surprised and I wasn't being told anything that brought me up short. Now, to some extent because, when I do the history of technology, I am conscience of the models people use and one of the themes in my course is to get students to learn to read the artifacts around them. Some sense these are statements. Any piece of engineering design is a statement. By the designer without the user. What is it going to be used for? Who's going to use it? What does that person have to know? What can that person learn? Who is it going to be used with? Is the person going to be using it alone or in conjunction with other people? These are all embodied in an engineering design. They, maybe a lot of them, default assumptions and they may be wrong. But, they are there. Maybe it's because I tend to think about this. Although, I must say in a couple of cases there are objects that tell you what they do and there are objects that don't. A door and its got a handle and you can grasp it. It already tells you, you're going to open the door towards you. You just have to play with it. You have to push away. If its got a twist handle on either side you're not getting any information out of it. That I found an interesting notion. There is a problem of user interface. How much can a machine tell you about the user? One of the things that Bob Morris remarks that what you think is reasonable. What you expect the reasonable thing to do is play around.
Condon: Go play with it yourself. Natural phenomena that I'm trying to figure out. He has a certain way in mind of how programs could be constructed. Because, I have no problem with doing experimental physics and trying to figure out what god intended and because he does things in simple ways. Einstein said God isn't malicious. Hokum's Razor doesn't work. Most programmers on the other hand are malicious. Doesn't work unless the guy who wrote the program write ID==. (Laughing)
MSM: Doug Ross says, somewhere in one of his writings, "Nature has no problems. It's only humans who have problems understanding nature." (Laughing) None the less there's a shared, well like Bob Morris says something like, do what's reasonable. What's reasonable depends on a community of people. One community will find one set of things reasonable and another will find another set reasonable. He was making assumptions about what you would take to be reasonable behavior on the part of the computer. The basis for that is that people at Bell Labs tends to think about problems the same way. Did you, for example, have the same expectations as other people? Let me phrase it in another way. When you started using computers what was your model?
Condon: I understand mostly what goes on in that black box all the way through wave equations through the circuitry. My problem was to abstract away the detail. Literally, yeah I know what goes on. How the servos work to run the arms of the disk drive, coding.
MSM: There's a jump from knowing at that level to interacting with the model of computing that the machine presents as opposed to its physical characteristics. What model of computing did you bring with you?
Condon: The assembly language code on the 650. As a kid I even worked with serial mercury delay lines. (Laughing)
MSM: You go back that far.
Condon: As a kid.
MSM: Where was that?
Condon: (not clear) We lived on the grounds and we could see them just over a hundred yards. (Laughing)
MSM: So you grew up with these machines?
Condon: Yeah, but more of electronics in general. Computing was just another branch of electronics engineering.
MSM: You say you came over here from area 13.
MSM: Why did you choose area 11?
Condon: No, no. All that's...
MSM: You came in this as twenty...
Condon: No, no. At some time we added the, ten or twelve years ago, we added the extra digit and everything began with two ones. It was called eleven. It used to be called one. The old system 13 became the new system 113. (Laughing) When I first came to Bell Labs I was in metallurgy. Fifteen, one-fifteen, ok. I came at about the same time as the split. It used to be physics, metallurgy and chemistry all under one executive director. Pysics became one executive director. Chemistry and metallurgy became the other executive director. I did solid-state physics and metals at low temperatures for about five years. Got interested more in the electronics engineering. The project of how we should do telephone switching in the local area network. What is happening in the sixties was in the decades prior to that. Technological advances made great strides in reducing the costs of transmission. Which meant that we were making money hand over fist in transmission. We just could not walk up to the FCC fast enough and get them to get the rate reductions fast enough. So that in fact we were not doing eight percent, nine percent on our money. As we were supposed to be doing. If opposed to doing twenty five percent even though every time we came closer to a rate reduction to get it back. But, technological progress was much faster than political progress (Laughing). We were forced to make all this money. (Laughing) A lot of that money was turned back toward research and development of transmission systems. What was going on in the local area to get it from the central office out to the home and what was going on in the home and the new local central office building has changed since the mid forties. Even that technology most of which had been done prior to the Second World War. Most of the design of the No. 5 Crossbar was done prior to the Second World War and wasn't reviewed much or anything, sort of pressed in. Manufacturing techniques were updated and pressed into service in a hurry after the Second World War. It hadn't been changed until now. There was work on ESS no. 1, which was viewed as a high features and of metropolitan market out for suburbia. So, it was taking a look at what could be done in a central office-switching department for that part of the company that hadn't been looked at. There was nobody developing since it didn't make money. So, we found some things and what the major thing that we found was that you had to look at the whole problem. The traditional way of cutting up between local and on premises equipment and main distribution frame and switching and what not, had to all be looked at. Which got nowhere in this company. Outside plant was done at Palmdell and local area switching was done at the Indian Hill and there were some outside plant things done in Merrimack Valley and the instruments themselves were done at Columbus and Chicago. The lines had been drawn and you could not go back and look at them again. But, we had no difficulty when we were done publishing a few papers because the guys at the Indian Hill said, "Let em publish, let em lead the competition astray." (Laughing) We had great influence in Telecom and Northern Telecom and whatever Western Electric is called now. Great run for the money on ESS No. 5.
MSM: Northern Telecom has just installed a telephone system for Princeton. Keep our fingers crossed. Those of us who have single lines can make connections with the computer, as of the beginning of this week, nobody with a multiple line unit could make contact with the computer. They make contact, but they couldn't get the signal back.
MSM: You are supposed to be able to take everything off the jack in our office. I want to see it. (Laughing)
Condon: Yeah. Those change-over things are really severe. Really severe problems. You hire special people. I remember ten years ago, Fitzgerald did something. He had been promoted to a rather grand office in front of the new building. I had known him because he had been interested in something about aids for the handicapped. Which was also a nasty problem inside the Bell System or what's left of the Bell System. A friend of mine Dave Hagglebacher was up there with him. He was glad to have somebody to talk to. He's a pretty big guy now. It turns out, he was official spokesman for software XYNZ and a few other things. He had nothing to do. Doesn't go to any meetings, doesn't get any memos, he can get right up there and say, "I'm not aware of any such plans." (Laughing) I know nothing of that sort. That's what his job was. He had three years to go before retirement. Spending all his spare time playing the stock market out of his office.
MSM: Imagine having a job where it is a job not to know anything. (Laughing) When you came over from 13 to 12, got into this group as you put it to find friends in the project. Why did you pick this group? Was it just because you knew Sam or did you have something in mind by coming over here?
Condon: Well I'm much more involved in hardware. Understanding the analog, the digital and the digital analog conversion problems, all those filters and determine if the right current is flowing or not flowing through the customers line. It's sort of a system to understand the hardware system that I am interested in. It was the only other group in research that was doing this sort of thing. The other option was to stay in 13 and move to Holmdel. The nature of the problem was management of 13. It was real trouble. MacDonald was the assistant director and the director was about to retire. Stay in 13 and stay in that laboratory and move to Holmdel. I was moved, although I hadn't experienced engines myself there were a number of people around to say that it was eventual. I was the fifth or sixth department head to work for. I was there for three or four years. A good finishing point.
MSM: This was switching systems.
Condon: Switching systems.
MSM: I never thought of this area as being, at least from what you're saying now, as being particularly hardware.
Condon: No, It's not. In fact the only guy who was doing it was Sandy. In fact, when Sandy came and started doing data communications I lent him my technical assistant. Who was in the second quartile of technical assistants that were in my group. I had a large number of TA's, STA's.
MSM: Did you bring your group with you?
MSM: You came over by yourself and set up the group?
Condon: That was one of the other things I felt was wrong. Is that the Hat project of big hardware project, research type of thing ran into the same type of thing that the stories you hear about the pyramid. Up near the top of the pyramid, you can't use all of your people. So, the only other thing to do was to start another pyramid. (Laughing) I had this army of people that keep busy and when it comes time to write up the project, really what did we prove, and what did we find and all that sort of stuff. There are twelve guys out there who can't contribute to that. They have to be kept busy. The right way to do research is to build the intrastructures such as to make it such that people could do their hardware project and then use it. Sandy had done a very interesting thing to it. He started out, he called it the draw package. Steve Wong picked up and called it UNIX Design Systems. So as to get the computer to do a lot of the trunk work, helping you design something, designed something and get it through the wire map stage. I had tried to export that. I had seen it and tried to have it picked up at Denver Labs. Just couldn't get the ideas across. Sandy had put it together. In those days the Tetronix 4014 terminals had storage units eleven by seventeen inches. Landscape and he used that as the graphics input, and those cost 15 or 17 thousand dollars back then. So, it's quite an expensive terminal. Yet, it's cheap compared to an STA. So, Sandy's idea was that the designer himself sits as Sandy did at the terminal to manipulate the knobs and do that type of thing. But out at Denver the NDS level designers scribbled on a piece of paper and handed it to a STA to make a modification to his drawing. What they did was replace the paper work with the STA, and went to the sign up sheet and signed up for the 4014 terminal. (Laughing) It was still not clear what the feedback mechanism was, whether the hardcopy came out of the computer and went back to the MTS for checking. It was still the old structure. Just the SDA's using this new tool which was meant for Sandy himself to use. It was built because Sandy wanted me to build hardware and so with being in this division and Sam Morgan's laboratory. There were no TA's. The TA had reported into my department. Later he was transferred over. I guess at the same time he was promoted to MTS. Switched over to Sandy's lab. It seems to be the other Sandy picked up on that. People write programs around here because they want to use them. Can hold an existing operating system on the PDP7 because it had operating system in order to run the programs. The PDP7 actually belonged to me. When I was a (unclear)
MSM: But it's yours
Condon: Yeah, but I got rid of it fast.
MSM: Had that PDP7 been used or what? It was a graphics workstation but it wasn't running Sandy's programs.
Condon: That's right. That was before Sandy even worked here. PDP7 was bought for graphics or something or other that Bill Minkey wanted to build. Bill Minkey was one of those guys (unclear). The PDP7, Kent and Dennis kept fooling around with it. That was something that they did. There was another PDP7 that we had enacted. That was a connector. It was called STARE. Xerox LDX long distance xerography. It was a facsimile system and was really quite impressive. You had to have these private wire things that did several hundred kilohertz bandwidth. Hank had this idea of a specialized machine to do the raster conversions. That was actually contracted out to Xerox to develop that. They were interested because of the product. They never did make it into a product. Since Xerox had IBM machines they built this thing with an IBM connector. This PDP-7 acted like a connector with one end acting like a TE635 tape system, acting like an IBM 360 tape system, and the PDP-7.
MSM: When you took over as department 13. Dick Cannon, and Dennis were already working on that PDP-7? How does one end up working on another department's machine? Do you say, I'd like to use your machine?
Condon: Well, I don't know.
MSM: They were on it.
Condon: Yeah, fancy graphics stuff.
MSM: But, your department maintained it?
Condon: You know, begger's market.
MSM: It's not always the case.
Condon: You do if the budgets are really tight it tends to get that way. You know, when things aren't tight, not a problem.
MSM: And they came all the way to 12? Did you look for a project in 12's area?
Condon: Yeah, cause I knew that I was interested in special purpose projects and one of the first things they did was take a look at project with Al Aho's stuff. Possibly the use of a special purpose machine to pattern recognize, GREP. Those things don't fit into UNIX. You got the problem in multi processing and the same in restoring the state of those machines. You have an extra piece of hardware. It has to be enough for the few registers in the floating point. There will continue to be problems in the co-processors. The microprocessors now delete induced instructions that machines tend to have a large register set. All operations are done between registers. So, there's a tremendous amount of internal states associated with a process. Which then needs to be tucked away when you do a process swap. Floating point tubes are separate in it own set of registers. If you are going to do anything complex you want a double precision floating point registers, sixty-four bit things that move across the bus in addition to 32 bit things. It's getting to look like we're turning around in a circle once again. Where in fact, multi processing systems will be made, such that there may be fewer of your micro processors and your multi processor, physical processor. Which are actually doing the time sharing type of thing. Swapping and changing processors and it's often batch for the other pool of fax machines over there. Just won't do the thing. Nothing happened to them. Then I worked with Ken on Chess where its not a problem. Because there be one chess game going on at one time. It's not practical to make the rule that there is only going to be one search of the dictionary at a time. The first chess machine did not make much significant improvement in chess. It violated the rules of UNIX. It was one that touched the hardware directly.
MSM: It doesn't help their creditability?
Condon: It doesn't help on the CHAOS creator, and a tape unit and it crashes and it never gets anded back. That's the real reason why user code goes through system calls to get to hardware devices. Either the whole system crashes or it kept track of the resources. Some days we had ashes but most of the time we kept track of the resources. That's the real reason why user code goes through system calls to get to hardware devices. That adds enough extra cycles that you don't want it to. You know it was Camden who made the rules, it was Ken Broker who made the first piece of chess hardware.
MSM: What implications does this system set for hardware design? Is there, there's LISP and then there was a LISP machine. Is there a kind of UNIX machine?
Condon: I'm really not the person to talk to on that. But, there were some starts in that direction. Steve Bourne thought that it would be interesting to specialize design of a machine that knew about C, not about UNIX. That would make it easy to compile. I don't think that turned out too much different. PDP-11, C is nothing but an assembly language for PDP-11.
MSM: It was the nicest assembly language he's ever programmed. (Laughing)
Condon: For a PDP-11, certainly not for an IBM machine which has six bit characters, pack six bits per word. It's not a language for a 709 or a 7894.
MSM: We have it up and running on our 370. Have you ever tried that IBM requirement version? I have no idea what was happening.
Condon: But then Steve was unhappy with the computer aided design tools that Sandy had built.
MSM: Why was that?
Condon: That they just were not powerful enough until he got off onto working on the design tools themselves and never did much on building the machine, the C machine. Steve did a very good job of improving the design package. He added three things, they were all in circuit design macros, CDM's. It was a macro capability, you could define a page of schematic diagrams as a macro and substantiate it on another page where it looked like a box like any other chip. He did a library look-up with a method that retains the library private to change PIN mnemonic names into the actual physical numbers that the physcial side needs. Then he introduced arrays of names such that you could have a single line of a name which expanded out to 32 names and then you had a 32 bit address and that could be wired into a single box with four names on it and ray of 10's on that that would expand out eight ways. All this would expand out 32 ways to match the 32 names of the signals coming in. It automatically generated it down to the physical level such that everything was connected up. A lot of the older hardware people still refuse to do that. They will draw the whole thing out. You can't do that without introducing error.
MSM: So your happy your using the tool.
Condon: Yeah, yeah I am happy. Part of the problem was when you come around to debugging the circuit, you get the scope probe onto searching a key number. It doesn't do much good to have the schematic diagram with mnemonic. Clock pin on this chip here. So the documentation is a bit harder to deal with. But I think I have found my own method to handle that.
Condon: There's a steel cabinet nearby, in the lab someplace. So, all the schematic diagrams and a catalog of the names and number translations, but only for the parts that I am using on that job. And that's a standard thing all written in a Shell script. Find out what chips you're using for that job, make the catalog on pieces of paper which then get laid out flat on magnets and that steel door. My lab is down this hallway. I had a big project where the two steel cabinets were not in a convenient place. So, I had a ten foot white board installed across the hallway from my lab. Across the hallway is the graphics side. So, I used the white wall, the wall had lights installed. Floodlights in the ceiling that would point down to it and get illumination. Steve did the design package. But then never did build the machine. Then I believe that Steve Johnson started off doing something about a C machine. But, it was about that time the 68000 chip came out so he got off working on his old deal, working on compilers. The portable C compiler was always slow and produced bad coding. I don't know what went on. I think the idea was he made this common machine. You figure out a machine which has the operations that you find in all machines before it becomes a fairly minimal machine.
Condon: Then you compile for that. That generates code for the specific machine. Sort of like reducing your problem to the idea of the Turing machine and then emulating the Turing machine in your real machine. It is just going to lead to slow, bad code. But, that's his field and somebody else's feeling and I really shouldn't be commenting on it.
MSM: Well, it's interesting to how it looks, well after all, it comes back to this notion of what's reasonable?
Condon: Yes. (Laughing)
MSM: That I think there is a theme behind it that Ken talked about during lectures. During the lecture Ken talks about software that can code and write a program that will write itself. He said the B compiler was essentially written in B. The C compiler was written in C. UNIX is not written in UNIX , it's in C. And the idea I gather is to get down to the absolute minimum and wind up writing them all in assembly language emulator to get the whole thing to bootstrap itself. What struck me when I first encountered UNIX and C was that it seemed strange it should be running on a VAX-11. That's the one we are using down at Princeton. Because the whole philosophy of UNIX seems to stay out of assembler. Get a VAX handbook, look at it, magnificent structures. The assembly line which programmers dream. But how many of those calls will any C compiler ever call on these assembly language routines and solve a problem? That's what I had in mind when I asked about it. The C machine, the UNIX machine, in my sense the RISC machine.
Condon: It's not clear what RISC is. RISC is a term like artificial intelligence. It's a jargon word that tends to get used for everything. Because the VAX has three address instructions and most of the project what you call RISC now only deal with operations between two registers or three registers, and certainly not with the memory locations. Then Johnson started out with and dropped it. Then we got the young summer student Dave Dixel and the young tiger was ready to take on the world and he was going to design the computer. He worked for Steve Horn for awhile. I don't know I wasn't involved with him. But, then later he came and worked with us and worked with Ray and made the CRISP chip, all that's left has gone to SUN Microsystems. We were having a difficult time following up on the CRISP project. I don't think we found the correct team to work together. It's a single chip microprocessor with quite impressive speed. You know, technology keeps advancing such that it's outdated now. However, there is a, they do have several concepts in there and I would really do a disservice trying to remember it. The basic idea is that they have caches. First one is that they have a cache which holds it in decoded instructions. A full Ninety six or a hundred bits of micro code and the mechanism by which small loops just stay inside that cache and execute out of that cache. So that it doesn't have to decode those instructions. There's the in front of that, prefetch and decode unit. I get a kick out of it, down inside that level it looked like a 650 because part of the micro code instructions were the next micro code instructions. (Laughing) We were going at that Full width. My goodness we have seen that before! (Laughing) Then there's another cache, called the stack cache and that's what makes it a B machine if anything because of the way C uses the stack. The idea is that a certain region of the stack is kept in this cache on chip. It is a certain block.
MSM: Sam is pushing very hard.
McIlroy: If you are at all interested in the technology transfer part of this thing you can meet those people.
MSM: Thanks, Doug.
Condon: Yeah that's fine. So think of the stack as a big long piece of paper with quotations on it. There's this little window which it you can slide up and down and what's in the window is on chip memory. Most of the time you're going in up and down on the stack if the cache is big enough you just stay on chip. But then there is a set of special instructions and automatic stuff such that if you actually start down further than the window, it automatically moves down there, flushes out the stuff that's on chip and the main memory and then, VAC is always before read anyway. So, there are some special instructions there to help out on Stack management. There are variants on that whether you have two stacks, one for the user and one for Kernel space. There are some real subtle tricks that you l have to do about process swapping. System calls and process swapping. Now the advantage of this is the difficulty with most of the RISC projects which have large register sets on chip, is that as technology improves you get a finer line and you are able to put more on a chip, but you're not able to put more on chip. They can't put more registers on chip because they don't have any way to talk about it unless you change the width of the machine too. Or you're reserving for the future. Where is this concept of these caches. Just make the caches larger and then you have less transfers to off the memory.
MSM: Is there a point at which you had to think about computer design as opposed to start to think about computer design? The sorts of things you are talking about sound like the sort of thing that would go on. Whole line of Microprocessing research got started up at a certain point. Was it going on when you came over here, or was it always a part?
Condon: Yeah, it was going on here. I think that's the way you manage research. At least around here it is that you sought people and you bet on them and also if they wanted change too. Steve Horn decided that at one point learning hardware design and learning how to do the hardware to build up special purpose processor to do a special processor for C was the correct thing to do. Never finished that, but he did a good job on introducing new concepts into computer aided design. What you do to change the direction of research you want it to go into to is by the type of people you hire. Sometimes we have had announcements from the top, look more in that direction. Some people sort of pick up the change, start studying in that direction and start moving in that direction. Mainly it's what people themselves want to do.
MSM: How has this influenced your own choice? You say it's okay to catch your breath, but then stay.
Condon: Yeah, and I'm interested in hardware design and I am still interested in that kind of thing of how to put together the infrastructure and what should the infrastructure be that you have to create in order to get some hardware project done. What you need to do without having to have a hundred people on your staff. So, that you can still do it with the eye level of MTS. Only a very few support people here. Because, when you start going in those directions it's chaos out there as far as computing goes. It's like, how do I transfer my data to you. Write it on this piece of paper and kick it with a steam hammer. (Laughing) We will enter it in our computer. How should I put it on a piece of paper, this piece of paper looks like a FORTRAN coding form.
MSM: It is interesting because if I hear you right you were looking for the sort of thing in a hardware design, and a software design.
Condon: That's right.
MSM: Which is a shared environment.
Condon: That's right and I'm still trying to work on what Steve Horn started to do. I mean he had come through and he knew what to do. Behold, to expand out names was exactly like the shell. The same guys so it's that concept of thinking about how you want to set things up so that you will get the work done. Which are an important thing to do and an important thing to try and to get the younger guys to step back and do the metal level.
Condon: Very few people do that. They get in there and do the work. There are very few that think about what is the tool you want to make in order to get it to work. They're used to doing that at the (not clear)
MSM: Certainly that is what struck me.
Condon: Even as a kid. It wasn't by my father, it was by other people. Even as a little kid I was taught, there was a guy, instrument maker, who taught me to think, you want to make a tool to do the job. So, there was one time when a data kit went bad and what it was a power supply that went out. First time in ten years or so, data kits had a power supply that went bad and they just couldn't and so now how do we change our power supply? We have gotten this new power supply and there is a bunch of guys standing around and there was no screw driver which we'd reach down in there and I said "Oh yeah, I know what to do". Went upstairs to where Max Matthews had a wood shop, took a big old file with wooden handle on the end and went over to the grinder and ground down a cold chisel point and reached in their with a hammer and whacked off the edge of the screw and boosted out the power supply. (Laughing) Gee, what a wizard Joe is. But everyone does it around here at the some level, but at getting a screw out Joe is a wizard.
MSM: This is fascinating because we're back to models of thinking and what has struck me is the software tools concept. Its seeming roots in the machine tool industry. When I asked Doug, whose paper on mass produced software was one of the papers that got me going on this question. With all this software crises around, what are these production models people are using. So, when I was talking to him about it in June I said, "what images did you have in mind." Thinking in terms of a screw cutting machine, but you have to develop the tool. And when I was thinking of mass-produced software designing tools that would allow us to turn out models of varying ways. It was a good thing, it didn't work. There is that tool making model that seems to underline dealing with humans. That it is a toolkit. What you do working on UNIX is crafting tools. It looks like the machine tool industry. One of the...
Condon: Well no, it's got to be the instrument maker. Because, the machine tool industry is also all tied up and going out and doing market surveys and seeing how big the business will be. If you do that, I don't know what happened to that file that was ground into a cold chisel, come back into the bin of files. Only used once. Removed the power supply, if you had to do the marketing survey to find out it never would have gotten done. But, we would still be standing around that cabinet taking the whole thing apart and doing it with the tools out of the stock room.
MSM: One of the interesting models from the 19th century was the growth of the American Tool Industry. How do you start off with a machine tool industry as of 1845. Each factory had its own machine shop. Design machines for their particular factory. By the end of the century you have an American machine tool industry that numbers some 500 concerns. As he investigated he found the phenomenon known as convergence and that is that the sewing machine Company came to one of these machine tool companies and said, "Well we need to drill a hole, I need to reproduce those twist drills." The machine tool industry designs a special grinding machine that grinds out twist drills. That machine company has learned how to build a generic machine tool for grinding out twist drills in various sizes which than the sewing machine people pick up, and the bicycle people pick up and so what comes out it is generic, generic product. But, then leads to rapid defusions of this particular technology. By and large it seems to be what the software industry has lacked. Some mechanism for getting generic experience, generic tools out of special solutions. The UNIX seems to be one of the areas that have succeeded.
Condon: Yeah, it's how you get rid of things too. Ask Doug, I don't know what the answer is. But, I'm sure there must have been. Every system has it. Something to bring the file on the screen. Some place or other somebody discovered that the command to catanate two files into a third file name when you left off the file names defaulted to your terminal with only one file. You didn't need the special command any longer. You threw out the old command that just listed a single file onto your terminal. (Laughing) Right now, Doug has some news item on the computer saying it is getting too thick and proposes throwing these things out. I don't recognize a one. (Laughing)
MSM: It's time to clean out the cellar, the garage. What do you use this tool for, I haven't the faintest idea. The way you described it though, I take it you still haven't got your headquarter equivalent of the UNIX environment.
Condon: No, and it has to be one of those continuing things. The manufacturing technologies that are out there keep changing what you want to do. They change their interfaces too.
MSM: Unix has never seemed to be a visually oriented system. Is that a part of the problem?
Condon: Yeah, it was a hot topic fifteen years ago. Editable graphics packages. Talked and talked and talked up the idea and nothing ever happened. There is no such thing and everything is so dependent upon the device. I really don't feel that a pen plotter, where you change the pens and what not and Sony Trinitron tube where you have to lay it down in raster scan order, fills colors and the pen plotter draws these little fine lines. Subtract away the differences between the two. (Laughing) I never believed in this and I still don't. Nobody gives papers on it any longer and I certainly don't see any commonality. What I just spoke of was just output devices, when your talking about interactive graphics type of thing. That, I don't know if anything will ever shake out.
MSM: Over here you write, the problem is finding a language to describe the process of design. So you can talk about designing language even though talking about is ultimately a two or even three- dimensional layer.
MSM: I am surprised that Brian and Day talk about typesetting as a problem with language. They did ultimately was to devise a language to talk to others. Is it correct that engineers are searching for a language to talk about, talk about circuit design?
Condon: I think that's what we know what Sandy did was a good job and what Steve did and it has evolved and I think we're in fairly good shape of our own type of things. I see standards committees about this information go in this column and this information goes in that column. Committees that are meeting this year, it seems sort of strange to me. (Laughing) But, that's what they're trying to bang out, a standard by which it can transfer a formal standard, to transfer information format from one manufacturer to another. Because the existing ways are just absolutely terrible. The Gerber language which is pretty standard for the circuit work. Originally this machine ran with stepping motors and you could do horizontal, vertical sweeps, forty-fives only. We had this set of optical apertures and some of them you could have an incandescent arm so it was a brush you drew with. It has these wonderful commands done in its level and changed to apertures so and so. Later they got fancier and had to fill spines. It was getting pretty unwieldy because it all grew out of the original language for the stepping motors. Very interesting numerical notation where the units were thousandths of an inch. Since you are making circuit boards everything comes out in multiples of a hundred. So, naturally it's a numeric system where you could strip trailing zeros but you can't strip leading zeros. Because the biggest unit we that we could talk of was 99.99. Five nine thousands of an inch, if you talk about one inch your going to put (Laughing) Any more trailing zeros to strip than leading zeros then they have to carry that across historically and in everything else they do. That's one of the standard languages that allows you to double expose or do things together and cut away anything that was already there. Ever Gerber doesn't use the language built around that stepping motor technology. But, they don't even make their film exposures that way. Everybody wraps the film on a drum and does a raster scan conversion in the computer and then uses a little laser on a screw thread moving down to expose the film. That's the technology that's taken over some. If you want real precision, you keep the film flat rather than wrapping it on the drum. Real precision is better than a thousandth of an inch. That's a thousands of an inch film six feet on a side, that's one big raster scan conversion which they do it and lots of maps are made with that technology these days. Even when you get to the half tone shading on the map a half tone. Another graphics exchange is that all language that was used to drive a 44T raster display, or not raster but vector command language. That flattens the world, there's no structure. You're handed one of those things on the computer, the only thing you could do is plot it out and let a human being sit down and figure it out what the structure is and re-enter it. That's what that world looks like. (Laughing)
MSM: That's the one your trying to get around?
Condon: Yeah, so I essentially shipped film.
MSM: What time is it? It's one o'clock.
MSM: Go to lunch.