Turning into Silicon
Further Episodes from Programming's Early Days1

My drive across the United States with my family in June of 1961 to take up my appointment as Head, Computer Applications Research, at the Palo Alto Research Laboratories (the Lab) of Lockheed Missiles & Space Company (LMSC) was an eleven-day odyssey that included a full squall in West Virginia, a mechanical breakdown in Missouri, and a number of other events that may be worth recounting some day, but we arrived safely in Palo Alto on June 12. Having arrived, we very nearly turned around and drove back. For openers, it was one of the hottest days ever recorded for that town, hitting 106 degrees at its peak. The good news continued with my discovery that the Computer Center of LMSC was having one of its periodic flaps: the US Navy, our chief customer, was unhappy with us because we were not producing satisfactory results in some data-processing project, and there was a demand that some of us researchers move south some 10 miles to Sunnyvale, the site of the main LMSC manufacturing plant and the Computer Center, to help out temporarily. My LMSC sponsor, Dave Hemmes, was one of those affected by the Navy's wrath, and his welcome to me was somewhat diluted by his understandable preoccupation with working his way out of the current trouble.

Because of the flap, I learned on my first day with LMSC the harsh truth that the Computer Center people down at Sunnyvale were not friendly toward their colleagues at the Palo Alto Lab, which they called "the country club." First, we playboys got to work on the more glamorous research projects, many of our own devising, while they sweated over the big, dull, bread-and-butter Government contracts; then we twisted the knife in the wound by drawing part of our support from income they had earned. It was the principle of the thing; money itself was not yet a big issue, since this was before Vietnam, military research funds were plentiful, and LMSC was on a roll, having recently brought the Navy's Polaris program in successfully. In the event, very few of us at the Lab were actually drafted for Sunnyvale duty, but the fact that it was seriously considered for a while, and the feelings on the part of the Computer Center people at Sunnyvale that it brought to the surface, were lessons and warnings about the future, if I'd had the wit to recognize them.

Turn-around time had been an important consideration when I'd worked for IBM in New York; it was an obsession at the Lab. This was the era of huge mainframe machines enshrined in locked, freezingly air-conditioned inner sanctums at the Computer Center (these mainframes—at first IBM 7090s and 7094s, later Univac 1108s—were "huge" only in the volume of space they occupied; in computing power, they were inferior to the desktop machine on which this memoir was composed). Around these machines stood ranks of tape drives, each in a free-standing man-high cabinet; just outside the machine room, as an outer line of defense, stood the sorters and interpreters and reproducers required for punched-card handling. (All programs and virtually all data, it must be borne in mind, were entered into the computer via a punched-card deck, either directly or after a card-to-tape procedure.) The Lab, despite the fact that virtually all its projects involved computing, was not thought to merit its own computer (it finally got a tiny system of its own—an IBM 360 model 30—in December 1965).

We in the Lab got computer service by punching our programs into cards, filling out detailed instructions for the operator on what to do with the card deck, and putting the resultant package in a bin to be picked up by the courier who made two round trips per day between Palo Alto and Sunnyvale. This courier was never stayed by snow or sleet, because such things simply are not allowed in the San Francisco Bay region, but could be stayed by practically anything else, especially traffic on the Bayshore Freeway (US 101). Our precious decks, representing the most advanced work of a major research laboratory, were bounced around in the back of a beat-up panel truck for which the ten-mile trip was a grueling expedition, and whose schedule became a major factor in the planning of our days. Sometimes the need to get another run on the computer compelled us to chauffeur our decks down to Sunnyvale ourselves, at the cost of an hour away from our desk or lab benches.

The duties of my new position had never been clearly defined. My boss, Bernie Rudin, had sketched a role for me as the Lab guru on programming languages, a walking talking encyclopedia of what was going on in the technology, but he was not, luckily, insistent on this—filling such a role would have been, if possible at all, a full-time job that precluded doing any original work—and I interpreted my charter, as any true researcher would, to mean that I was to proceed to follow my own vision. This was, in my case, XPOP, the macroprocessor-based programming system that Bob Brill and I had started building in our IBM days. With the small group that reported to me (Tony Stiegler, Bill Mead, and Marian Miller), I continued the building of XPOP. There were no specs; I had only a vision, but it was a vision that never failed to suggest to me what was to be done next.

The idea of the macroinstruction seemed to me to be a fundamental principle of software development. It enabled any user to package in a standardized way any routine he had written, so that it became part of the very language he was using, available to him and others thereafter. In short, it had the spark of life: it could grow. It offered the road upward to a state in which programmers would never have to code anything that any programmer had ever coded before, but could simply use the fruits of their predecessors' efforts as building blocks in creating larger and more wonderful structures. It would in effect make all programmers collaborators and beneficiaries of each other's work, and let them escape from the limitations of both assembly language and compiler languages. Assembly language offered infinite flexibility, but at the cost of re-creating the world from scratch in each program; a compiler language offered a high degree of immediate usability, but at the cost of restricting its users to one application, as understood by the compiler's author. The macroprocessor, it seemed to me, combined the virtues of both assembly and higher-level language systems, and transcended them by far in its potential.

The assembly language knows nothing of growth, and the compiler deliberately forswears it; in spiritual terms (this is, recall, a vision I'm speaking of) assembly language is too innocent to practice growth, compiler languages too corrupt. The compiler I see as a special case of the macroprocessor: it too is a programming system that lets its user write in a "higher" (more application-oriented, less machine-dependent) language, but the compiler trades away the principle of growth, the readiness to be taught new operators and operands, in exchange for easy and immediate applicability in one specific niche. It appeals to those—and this class includes all of us, at least part of the time—who want quick results with least effort, even if at the expense of longer-range benefits.

If my advocacy of the macroprocessor seems to be more impassioned, and to spring from sources deeper in the psyche than is usually the case with technological proposals, that is because it is, and does; I see the tensions among the various kinds of language processors as analogous to certain political and moral conflicts, and they arouse in me something of the fervor that attends such larger issues. This, however, is my private vision, which I asked and expected no one else to share; the grounds on which I built my public case for the macroprocessor were quite concrete and non-ideological. I fully recognized, too, that the macroprocessor as then known (and as known today, for the most part) would need to be augmented with the amenities that programmers had come to expect, such as problem-oriented notation and highly efficient code, as well as mechanisms for the control of communication among macros, debugging, and so on. I saw no conflict between these features and the macroprocessor idea; indeed, some of them were easier to implement or more powerful in effect when integrated into such a processor. For more on the concept behind XPOP, and details of the features it included, see [Halpern, 1990], chapters 3 and 5.

While building XPOP we achieved Artificial Intelligence, and passed the Turing Test, without even trying. The assembly-language instructions that formed the body of XPOP's macros included comments; when the macros were invoked, these comments were copied into the object programs with the instructions. The instructions varied, of course, from one appearance in the object program to the next, since the macrocalls invoking them provided different parameters each time, but the comments never varied. It struck me that such boilerplate comments were not informative, and that if comments contained dummy parameters for which actual parameters were substituted at each invocation of their macro, they would be more useful. I made the necessary change to XPOP by removing one or two instructions—the instructions that turned off parameterization at the end of the instruction field—and reworded the comments to use the new capability.

I displayed XPOP's new capabilities to Gordon Uber, another researcher in the Lab, in the form of a listing showing differently parameterized calls on the same macro producing different comments. I thought the feature was worth a small smile, mostly at my expense for having noticed the obvious so late. But it got a much bigger reception; Gordon, to whom I'd shown the result without explanation, reacted as if I'd produced the Philosopher's Stone. His face lit up with wonderment, excitement, even awe; I had created an intelligent system! Like a fool, I told him how it had been done; his face fell as low as it had been high a moment before. Gordon, incidentally, was no naif; in fact, he was an AI researcher working under the direction of Maury Halstead. XPOP, in fooling him into thinking it possessed intelligence, passed a more stringent test than that posed by Turing: Turing called only for fooling a layman, XPOP fooled an AI pro. I may write up this experience more formally, and claim the Loebner Prize on the strength of it 2.

Most of our daily activities were not quite so exalted as the creation of artificial minds; fixing program bugs was our staple diet. We wrote XPOP in assembler code—specifically, in the Fortran Assembly Program (FAP) language. Given the turnaround-time situation, it should be clear why we worked hard to avoid bugs, and regarded every one as a small disaster; a bug that took two or three days to find and fix was a major disaster. A bug that took a week to deal with was almost unthinkable, but it happened to me. To mark critical points in XPOP, I had used the 7094's "sense lights"; these were switches that had the useful property of being both programmable and visible, their state being indicated by console lights. Since we programmers did not attend the running of our programs, we depended heavily on operator actions carried out for us according to instructions that we sent down with our decks, and it was convenient if those instructions were put in terms of actions to be taken when the sense lights were in some specified configuration.

I had coded a routine that reported its successful completion by setting one of the six sense lights off, and failure by setting it on. In run after run, I found that by all other indications the routine had successfully completed, but the sense light stayed stubbornly on, triggering the program halt I had provided for the failure case. I worked over this bug as I have never worked over one before or since; I studied my code, and mimicked the computer with paper and pencil, until my eyes wouldn't focus. For a full week I sweated over it, coming to believe not in artificial intelligence but in artificial malevolence. The solution finally occured to me when I reread, for perhaps the sixth time, the FAP manual's 3 description of the op codes for turning sense lights off and on, and noticed for the first time the slight asymmetry between SLF, "Turn sense lights off," and SLN, "Turn sense light on."

I had been trying to turn a particular sense light off, using the address field to select it, just as one did with SLN to set a light on, or with SWT to test a light. But the SLF instruction did not follow the pattern of its two brothers; it permitted no selection of an individual switch, but turned all sense lights off. Why, then, you ask, did my code generate a false failure case? After all, if all lights were turned off, that may have caused other potential problems, but at least the light I wanted off would have been so set, wouldn't it? Your question is a natural one, but shows you have forgotten the Law of the Malevolence of Things in General. The SLF instruction, although not following the pattern of its brethren in syntax, did follow the same logic internally. Even though no non-zero, sense-light-specifying value was permitted in its low-order three bits, they were nevertheless ORed in when the instruction was processed. When I mistakenly tried to select a particular sense light to be turned off, the value I supplied had the effect of selecting that light just as intended—and also of turning the instruction into an SLN.

I reproduce the page in which the FAP manual records this interesting little quirk, since no one with a healthy mind should believe a word of this story without supporting evidence. Note that to FAP, the only distinction between an instruction that turns all lights off, and one that turns a specified light on, is whether the last three bits of the address field evaluate to zero or some other number—it paid no attention to the mnemonic, which was just a placebo for the programmer.

This misadventure drove home for me the truth that our systems are at best resistant—in the sense at least of not failing catastrophically—only to single errors; when two errors occur at once, most systems are overwhelmed. A well-designed system may foresee all single problems, and make some provision for each, but the possible permutations of errors, taken two at a time, are beyond our conception, let alone our graceful handling. In the case of this bug, one of the errors was mine—had I read the manual with perfect attentiveness, the facts were there to see—the other error was the system designers'.

They had in fact committed a triple sin: first, by offering two mnemonic op codes that, although opposite in meaning, generated the same object code; second, by failing to draw the fact to the user's attention in the most emphatic way possible, instead recording it in the weakest possible way, merely by use of a plural "s" in the description of one where the other had the singular; and finally, by being so user-sadistic as to provide that, when he fell into the trap, the result would be to invert the sense of the switch while letting the program run on without the slightest hiccup, diverting his attention from the true cause to an infinity of possible errors in his program logic. In one sense, of course, the FAP designers were quite advanced: they had created a single generic sense-light operation, "Do something to one or all of the sense lights, as specified by the operand." This was very clever, and decades in advance of the state of the programming art as it was then—but they might have warned their hapless users that they were introducing Object Oriented Programming
.
I mentioned bad feeling between Sunnyvale and Palo Alto; a case in point is provided by the Ray Moore episode. Some of the financial support we researchers received was from the Sunnyvale Computer Center, and the Lab had to submit reports to them on the work accomplished with their money. For the most part this was purely pro forma; until Vietnam, the government money came through regularly, and individual researchers had little involvement in the funding process, which was handled by our managers. However, one worker in the Lab, Ray Moore, did have trouble on one occasion getting his funding extended, and the appeal process required that he make a special oral report to the director of the Computer Center, who alone had the authority to reverse the ruling that had denied him continued support. The denial of funds to Ray greatly surprised me, because his work had always seemed to me among the most promising and important being done at the Lab; the requirement that he plead his case in person was particularly bad luck, because he wasn't very good at explaining to laymen what he was doing.

Ray was doing advanced work in interval arithmetic, a technique for dealing with the fact that the numbers worked with in applied mathematics are always inexact, and that the inexactness must be recognized and controlled if numerical results are to be useful. The technique calls for representing every numeric quantity as the pair of numbers that are the end points of the smallest number-line segment that encloses its true value.

If, for example, a measurement of V produced a value of 5.23 volts, plus or minus .05 volts, V would be represented in interval arithmetic by the pair (5.18, 5.28). Then every arithmetic operation that had to be performed on V would be carried out not on the measured value, but on the pair of numbers known to just bound its true value. Every such operation would likewise yield a pair of numbers instead of a single number, with the same property of bounding the true value. Done properly, the result of an interval-arithmetic computation with inexact numbers is a pair of numbers that represent the range within which the true value of the result lies—the narrowest possible range, given the degree of error in the original measurements.

The advantage of interval-arithmetic computation is that no lengthy and difficult error analysis is needed, as it would be after ordinary calculations. In interval-arithmetic calculations, the error-analysis process is built into the computation algorithms, and its outcome is reflected in the numerical results obtained. The usability of the technique depends on keeping the computational burden manageable; since every step of computation involves at least twice as many numbers as ordinary arithmetic, the amount of number crunching can become unacceptable unless clever means of minimizing it can be developed. Ray Moore's work was finding such means; he'd already had enough success to have published some well-received papers on it 4, and it was this work that the people at Sunnyvale had decided not to support. There was general indignation in the Lab at the thought that Ray's work had been refused continued support, and gloom at the thought of his trying to talk them into reversing their decision.

Ray made his pitch to the director of the computer center, a choleric little butterball who'd been a professor of chemistry somewhere; he listened with little understanding or patience to Ray's story, but finally he thought he got the drift: Ray was impugning the veracity of his computers! His words, practically verbatim, were, "Are you telling me my computers are giving the wrong answers? How was your last paycheck—did it have the right numbers on it?"

Ray Moore left Lockheed not long after that exchange took place, joining the Mathematics Research Center at the University of Wisconsin to do research on the brain. I suppose his Lockheed experience must have raised in his mind the question of how humans could live without that organ.

As XPOP took shape, I began writing papers about it. The first of any consequence was on the use of XPOP as the basis of a language for Command & Control applications. C&C is not today an application thought to need a specialized programming language; in the early '60s it was. A small literature had grown up, written largely by people at the Institute for Defense Analyses, the System Development Corporation, and the RAND Corporation, describing the requirements of such a language, and evaluating existing languages for their suitability. I began to look into that literature out of little more than curiosity; LMSC was of course heavily involved in all aspects of military electronics and computer usage, so the topic was one I wanted to get some understanding of, but didn't feel I had anything to contribute to. After reading some of the studies that had been published by institutions like those just named, however, I began to think that XPOP did have something to offer the C&C community, and wrote a technical report 5 that surveyed the C&C programming language literature, and proposed XPOP as a better basis for a C&C language than any of those recomended in that literature. So it was in the very specialized role of C&C programming system that XPOP first came to the attention of anyone outside a small circle at LMSC.

The specific proposal made in my technical report was never adopted, if only because the whole idea that C&C required a special language petered out, but its publication had some valuable consequences for me nevertheless. Richard Goodman of Brighton College of Technology, England, then editor of the Annual Review in Automatic Programming 6, wrote to say

A copy of your Technical Report ... has just filtered through to us via SDC, and yesterday Mike Woodger and I read it with very great interest and, indeed, fascination. ... In the meantime, we are so interested in your ideas that we are contemplating the possibility of its use on our own ICT 1301...

and Richard Hamming, then Head of the Numerical Methods Research Department at Bell Telephone Laboratories in Murray Hill, New Jersey, wrote

I have recently seen a copy of your Technical Report ... and would like to get a couple of copies to send to friends who would certainly profit from reading your words of wisdom (although I happen to disagree with part of it and think that you paint too rosy a picture of XPOP).

The appearance of the Report also led to invitations to contribute to Datamation, then virtually alone as a semi-popular journal of computing [7 8 9], to the publication of technical papers in the refereed literature, and all the other forms of recognition that usually greet an acknowledged technical innovation.

Not everyone was pleased at these signs that XPOP was having some success. The Sunnyvale Computer Center had a few research projects of its own going on, and some of their researchers saw my work as dangerously competitive with theirs. Their feelings manifested themselves in two incidents. The first was a visit to my office by Maury Halstead, the best-known of the Sunnyvale-based researchers, for the purpose of discouraging my pushing XPOP as a C&C programming system. In particular, he wanted me to withdraw a paper on XPOP in the C&C role that had already been accepted by the Fifth National Winter Convention on Military Electronics. Halstead —he was well known then, and some of his work is still cited occasionally—told me that I was venturing into a discipline of which I knew nothing (this was true), and that I would only make a fool of myself (I feared that this, too, could be true). It was to save me from hurting myself, he told me, that my friends down at Sunnyvale had deputized him to come up and talk me out of my rash and presumptuous plans. He also told me that my scornful words about some other peoples' projects and papers had caused much resentment (another truth), and seized a copy of the "XPOP Manual" that he noticed on my desk to show me the kind of offense he was talking about.

This Manual was physically unusual: I customarily illustrated XPOP's progress by a FAP assembly listing that showed some macroinstruction input, and the code it produced in response. The examples were heavily commented, and, together with my accompanying oral explanations, showed my boss and others at the Lab what had been accomplished. As the project proceeded, the listings grew longer, and the comments more numerous, until I realized that with just a little more work, the listings could become a manual. It turned out to take far more than just a little more work, but eventually I had a 111-page manual, with references, tables, and all the usual apparatus of a such a document—but it was still an assembly listing that recorded an actual computer execution of an XPOP program. Its chief drawback was its visual monotony; it was all capital letters in the graceless IBM printer font, reduced on a primitive copier to 8.5" x 11" pages from standard line-printer size. Despite my efforts to make it readable, it was something of an eyesore. In the Introduction, I acknowledged this weakness, and, trying to find some compensating virtue, pointed out that its humble origin as a record of an actual execution at least "kept the writer honest."

It was this statement that Halstead waved in my face; I gathered from his garbled words (he was not perfectly calm) that this was a charge of dishonesty directed at all who did not similarly document their work. I don't recall what I said to him; probably something quite ineffectual, since my ability to respond to such attacks is hampered by my inability to believe, at the moment, that the attack is really happening. I made no formal complaint at this most unprofessional behavior, but did tell one of my Lab colleagues about it informally; he was infuriated, and caused a memo to be sent to Halstead's boss, with what result I never did find out.

The other incident in which my Sunnyvale friends were able to show their regard for me was their drawing the attention of John Nash, LMSC's Vice President for Research, to the only unfavorable review of an XPOP paper I can recall. I had gotten, over my years with LMSC, many expressions of interest in and admiration for that system, and for the papers expounding it, but had never heard a word of recognition from Nash or anyone in higher Research management. But finally the consecutive-hit streak was broken: Computing Reviews (June 1965) gave a paper of mine to one Bruce Silberg, and he gave it a bad review, in both senses. Silberg dwelt particularly on the notation-defining features of XPOP, in the belief that I'd invented them simply because I was unacquainted with Backus-Naur Form, and he wrote sadly about his embarrassment at having to point out a case of utter incompetance.

Most of the review was too subjective to refute—if a man claims to feel embarrassment, who can contradict him? At one point, however, he did make a statement that was testable: he claimed that XPOP's parsing mechanism would be unable to deal with a command in which actual parameters were given in an order different from that of the dummy parameters in the macro definition—and he was demonstrably wrong. He had simply failed to read the passage where I dealt with exactly that situation, and showed how easily XPOP coped with it. I protested to the editor, pointing out that the circumstances were exactly those in which CR's policy called for a second review, but got the usual response one gets to these things; first, long silence; then, when it became clear that stonewalling wouldn't work, a weak and incoherent reply whose real meaning was "Please don't expect us to live up to our own announced principles; if we do justice in this case, we'll have to do it in every case!" (Eventually, almost a year later, the paper did receive another notice in CR, from Peter Ingerman, in which none of the points at issue were dealt with. I was left feeling weary and disgusted.)

This review of Silberg's was the one that someone in Sunnyvale had taken the trouble to forward to Nash, and he in turn sent a tart little note to my Lab management, observing that one person at least seemed to feel that my work left something to be desired. My immediate manager and I had some grim fun in composing a reply to this. We lamented our bad luck that just that one review out of so many had found its way to his desk, and undertook to remedy the deficiency by providing therewith a number of other opinions, several of them in the form of unsolicited letters from well-known computer scientists (the attachments were lettered, and went from A to K). This was fun and games, but I've wondered since then just what other damage my Sunnyvale friends did my project that I never knew about; it's hard to believe that the two incidents that took place right in front of my eyes were their only attempts.

Of course, Halstead had been right in charging me with wounding the amour propre of a number of other researchers. When I saw little merit in someone's work, I did not trouble to hide my opinion; my way of dismissing what might have been someone's life's work with a few cool words must have caused pain on more than one occasion. It may have been something like this that accounts for a remark made to me at a conference during these years: I was one of five or six panelists seated behind the usual cloth-draped speakers' table up on the platform, waiting for the chairman to open the session. Another of the speakers, John Gosden, then well known in programming-language circles, got up from his chair at the opposite end of the table, and deliberately approached me to say in my ear—these are very close to his actual words—"I just want you to know how much we despise you!" I'm fairly sure he said "we," but he didn't identify the parties for whom he was speaking. I had never criticized his work, nor had much to do with him in any way (perhaps that was my chief sin?), so that there was something impressively impersonal about his utterance, as when in Greek tragedy the chorus delivers a judgement.

Although XPOP and its derivatives attracted much favorable attention, including that of the Department of Defense and the intelligence agencies, it never became a money-earning product. This was due largely to my ineptness as a salesman. It must be understood that the Lab was not a business, with a marketing and sales staff; it was more a kind of craft fair. It was in effect a big tent under which each of the researchers had a stall to display his wares; for the success of those wares he was almost solely responsible. I was a rotten salesman; the quintessential propellor-head, I felt that the sheer beauty of what I had to offer should sell it. I was arrogant (it was unconscious, innocent arrogance, the most offensive kind), I was uninterested in other peoples' problems, and if a prospect didn't respond quickly enough, I dropped him and went chasing after one of the others. The only reason that my project had survived as long as it did was that it was largely government money that was supporting it, not LMSC's; until Vietnam, money for research projects like mine was plentiful. But then Vietnam did happen, and those funds started drying up; LMSC responded by issuing heavy hints that projects that weren't paying their way should start looking for other homes.

At just about this time (early 1967), I was invited by IBM to speak at a conference 10on macroassembler technology, an in-house IBM event held to acquaint IBM's macroassembler developers with what was being done elsewhere. IBM's definition of macroassembler technology was commendably broad: my fellow speakers included Niklaus Wirth, whose PL/360 was like XPOP in attempting to combine in one package the good features of both higher-level languages and assemblers. In my case it also served as a tryout for consideration as an IBM recruit, and I evidently passed the test, because after my presentation IBM offered me a position in their Assembler Language Department and Mission at San Jose. (The "Mission" part of the title meant that the organization was not only a development group, but was the company's designated center of competence for the technology they worked in, with some authority over IBM work in that technology wherever it was pursued.) The approval of an IBM vice president was required before I could be hired; I had defected once, and the company did not lightly restore fallen souls to grace, but mercy was found for me, and, to my own surprise, I became once more an IBMer.

To my even greater surprise, I found that, having re-hired me, IBM had no idea what to do with me. I had expected they would want me to build an XPOP-like processor, or at least advise on the incorporation of some of the features of my system into some macroassembler already under construction, but they gave me no clear charter of any kind; with respect to XPOP development, my second tour with IBM was a waste of time. In retrospect, I'm appalled at having allowed my time to be wasted, but I have no one to blame: I naively believed that way up above me were People Who Knew What They Were Doing, and who would, in their own good time, reveal why I had been called back to IBM, and show me that the apparent confusion and aimlessness concealed a deep and well-laid plan in which I would find a proper place. In fact, IBM had, in hiring me, exhausted its creative impulse. It now waited for me to tell it what it needed to do, while I waited for it to reveal its deep plan. It was a pathetic loss for both of us, but more serious for me, a mortal.

One of the few good things that came out of this second tour with IBM was a period of friendship with John Backus, who commuted to an office at the San Jose site a few times a week from his home in San Francisco. He had been my first department manager at IBM in the late '50s, and my nominal manager for a year or so afterward, but I had hardly seen him between the day in 1957 when he approved Bemer's proposal to hire me, and the day in 1961 when I left IBM. Having nearby offices at San Jose brought us into fairly frequent contact; he and I fell into conversation a few times, discovered some common interests (other than Fortran!), and began to visit each other's homes. My wife and I enjoyed a friendship with John and his wife, Barbara Garlits, for a number of years.

One good thing was accomplished for IBM, too, during that strange becalmed period: I helped IBM recover from the PL/I fiasco. The PL/I project had started during my first tour with the company, in New York, as a way of avoiding the dreaded "proliferation of programming languages." The cost of developing and maintaining programming languages had impressed IBM management deeply, and they were willing listeners to the argument that the way to minimize this cost was to develop one language that would support virtually all important users, replacing Fortran, Cobol, and even, to a great extent, assembler language. During my years with LMSC, IBM's PL/I effort had proceeded, and had produced a language that did indeed include just about every feature that Fortran and Cobol offered, as well as a good deal else.

The guiding principle behind its design seemed to be the same as that of the original Fortran compiler—"Oh, and another thing..." The difference was that in the case of Fortran, for all practical purposes the first real compiler, dependence on that principle was quite understandable; its designers were inventing computer science as they went, and doing it brilliantly. The PL/I designers had no such excuse; they had the examples of Fortran, Cobol, and a dozen other languages before them, and they had the benefit, if they had chosen to avail themselves of it, of criticism from many others with hard-won experience in language design and implementation. But they apparently saw the only threat to PL/I's success as coming from its possible functional incompleteness: as the Fortran designers had feared only that someone might say "Look at that redundant store instruction in that object program; Fortran can't produce good code!", so PL/I's seemed to fear only that someone might say "Here's something I could have done in language X, and PL/I has no equivalent feature!" So they piled feature after feature into it—and "piled" is the right verb—producing the kind of creature that is usually cobbled together by a mad scientist, using a brain dug up by Igor, his devoted but somewhat addled assistant.

I had paid little attention to PL/I during the years of its development; I was busy with my own work, which lay at the opposite end of the spectrum of programming-language concepts. If anything, I rather welcomed PL/I, in the same way that a revolutionary welcomes a crisis in capitalism: it will be painful, but it will show up the rottenness of the System, and speed the revolution. I don't need to depend on memory for this, because I still have the letter sent me on December 10, 1965 by R. N. Southworth, editor of the PL/I Bulletin, soliciting my views on the language. My response ran:

PL/I represents, I think, a fundamentally bad strategy. Its language, far too rich for most applications, is at the same time far from universal; the resulting compromise is a language not quite right for anything. This is the inevitable consequence of its designers' error of aiming toward a universal language of conventional implementation rather than toward an open-ended processor capable of translating a growing variety of languages. ....the weight of IBM is enough to ensure that PL/I will be widely implemented and strongly urged upon us; how many programmers will voluntarily abandon FORTRAN and COBOL to use it is a very different question. If it is to find widespread use, I suspect it will come about only through a strong IBM sales-pitch to non-programming middle and upper management on the economic virtues of a single-language shop, followed by much arm-twisting of working programmers. In one way I welcome PL/I: I think it will provide a massive test of my hypothesis on what's wrong with closed processors. In the hope that its failure will speed the coming of the age of mammals, I welcome this last and greatest of dinosaurs.

PL/I, in short, was someone else's mistake, and not even an interesting mistake; there wasn't much either to fear or hope for from it. On the one hand it was a sad waste of money and talent, but hardly unique as such; on the other, it was clearly going to be so enormous a flop that it was just possible the programming community would learn something from it, but there was no guarantee that even a failure on that scale would be a 2x4 big enough to get that mule's attention. By "failure" I didn't mean that PL/I would not amount to a viable programming language—given the resources devoted to it, it could hardly help achieve that status—but that it would not achieve its announced objective of replacing all the other major languages. The idea had been that instead of supporting n languages (n = 3, 4, or 5), IBM would have to support only one; it was obvious to some of us that it would instead require that IBM support n+1. The saddest news for IBM was that PL/I was not bad enough to disappear from the face of the earth, but was just good enough to attract some users, gather a constituency, and become, like Fortran and Cobol before it, impossible to abandon. If only it had been a total failure, absolutely unusable as a programming system, IBM would have been able to cut its losses, but the damned thing wouldn't even have the grace to die.

When I rejoined IBM, however, my detached attitude fell away fast; now it was not just a piece of misguided technology, but a potential disaster for the company I worked for. IBM was so sold on the "single language" idea that it had publicly announced its coming withdrawal of support for Fortran and Cobol; this announcement was made, if my memory can be trusted, by an IBM vice president at a Spring Joint Computer Conference in Atlantic City. This struck me as one of the worst ideas ever heard of. Here was IBM, with something close to a stranglehold on the computing market, telling its customers that if they stuck with IBM hardware, all their heavy investment in Fortran and Cobol programs was going to be lost! The other manufacturers' marketing people must have thought they'd gone to heaven, what with IBM handing them an opportunity like this. All they needed to do was to assure the market that they were going to support Fortran and Cobol till hell froze over, and then set up extra phone lines to take orders from defecting IBM customers. How IBM, a company almost universally considered to be the most market-driven in the industry, managed to miss this obvious consequence I can't imagine, but they did.

Since assembly language was also to be replaced in large part, if not entirely, by PL/I, we in the Assembler Mission were given a chance to be heard at one or two meetings of the Corporate Language Strategy Committee (this may not be the exact name, but it's very close) in New York. I circulated at one such meeting a memorandum pointing to the marketing problem that IBM was making for itself, and managed to restrain my exuberant vocabulary for once, entirely forgoing such terms as "imbecilic," "fatuous," and the like. Instead, I produced a sober, restrained position paper, full of comforting terms like "market share," "prudence," and "defensive posture" (I must have been really impressed by the gravity of the danger to have so successfully disguised my voice). I overheard enough of the comments that were made about this paper in private conversations among other attendees to know that several of them were quite impressed by it; to what extent it was instrumental in causing IBM to retract its virtual suicide note I don't know, and probably never will, unless some ex-IBMer in a position to know is moved by this account to tell the story. In the meantime, I enjoy speculating that I may just have saved IBM from loss of its leadership position in the computer industry—not a bad reward for re-hiring me.

Saving IBM from Chapter 11 served to alleviate the boredom for a while, but the episode passed with the company still having no plans for me, and I was too green—still—to know that when the ball is loose, you grab it yourself and run with it. So I was a willing listener when I got a call from Kai Magleby, a man I'd never heard of before, telling me that he was starting up a computer division for Fairchild, and would I like to head up the software part of it? And so it came about that I resigned from IBM for the second time, which makes me, I think, a member of a rather exclusive club.

1 This is the second installment of a memoir whose first part appeared in these Annals for xxxxxx, 1991. It can for the most part be understood, I think, on its own, but some passages will inevitably have less meaning for those who have not read its predecessor.

2 The Loebner Prize was established in 1990 by the Cambridge Center for Behavioral Studies to further the scientific understanding of complex human behavior. The Loebner Prize Medal and a cash award will be given annually to the designer of the computer system that best succeeds in passing a modern variant of the Turing Test." (quoted from the official brochure)

3 Moore, Donald P., FORTRAN ASSEMBLY PROGRAM for the IBM 709/7090, 709/7090 Data Processing System Bulletin J28-6098, IBM Corporation, Data Processing Division, 112 East Post Road, White Plains, N.Y. September 1960. 78 pages. The page reproduced here is p. 18.

4His results were collected and published in Ramon E. Moore, Interval Analysis. Englewood Cliffs, NJ: Prentice-Hall, 1966.

5A Programming System for Command and Control Application, Technical Report 5-10-63-26. Sunnyvale, CA: Lockheed Missiles & Space Company, 25 July 1963.

Of this first edition there were two printings, the first of 100 copies and the second of 50. A second, revised edition was published in September 1964; the foreword says "The text has been thoroughly revised for this edition, almost no page being unchanged. The changes, however, have been solely for the purpose of elucidating obscurities in the argument and incorporating advances made in the XPOP programming system; I have seen no need to retract or qualify any material point made in the first edition. After a year's exposure to criticism from both users of C&C systems and advocates of other programming systems for C&C work, I feel more certain than ever of the soundness of the argument presented here."

6The correspondence that sprang up between us as a result of this letter led Goodman to ask me to join him in reviving the ARAP, which had ceased publication in 1965. I accepted, and we starting planning (via airmail) to reorganize the publication, and make new arrangements with the publisher, Pergamon. Just as these efforts were about to bear fruit, Goodman died. For some months, we in the U.S. who had been working with him were in shock—we'd had no inkling of his fragile health. Eventually we got in touch with Pergamon, and make fresh arrangements in which I and an associate (first Christopher J. Shaw of SDC, later Bill McGee of IBM) served as co-editors, with a distinguished board of associate editors. We brought out three volumes of ARAP under these arrangements, in 1969, 1971, and 1974.

7"Computers and False Economics," Datamation, April 1964, pp. 26-28.

8"Evolution of the Programming System," Datamation, July 1964, pp. 51-53.

9"XPOP: A Command and Control Programming System," Datamation, November 1964, pp. 39-48.

10The conference was entitled "IBM Macro Assembler Conference"; it was held May 1-3, 1967, at the Los Gatos Lodge in Los Gatos, California. By the time the proceedings appeared (date unknown, but probably 6-8 weeks later), I was an IBM employee.

11See "From the Macroprocessor to the General Processor," in my Binding Time. Norwood, NJ: Ablex Publishing Corp, 1990.
\new
================================================
* conversion from 7094 to 1108

* Grosche on the Sawmill Parkway

* Wattenberg episode(s)

* Bemer as coiner of "software factory"

* X3.4.2 membership

* publishing Bemer's ALGOL paper