On the Heels of the Pioneers
A Memoir of the Not-quite-earliest Days of Programming

In the fall of 1956 I was an unhappy young man; I had spent years preparing for, and was now almost fully qualified for, a profession that I'd just found I did not want to pursue. I had made the elementary blunder of deciding that the life of a professor of English would be ideal for me. What could be better than getting paid to do what you loved best: reading, writing about what you had read, and trying, by imaginative teaching, to get others to share your pleasure? It was not better reasoning that taught me the folly of this idea, but experience. While completing work toward the Ph.D at Columbia, I served as English instructor, first at the University of Connecticut, then at City College of New York, and got my first experience of academia from inside. I quickly learned what I would have noticed years earlier if my nose hadn't been perpetually in a book: teaching, which I very much enjoyed, is only a small part of the academic life; and reading, when done as a duty, gives little pleasure. What would have become of me if the New Yorker had not run a story on computer programming in its issue of January 5, 1957, is a subject I still can't think about without shuddering; luckily for me, that magazine's curiosity had been aroused by a series of recruiting advertisements that IBM had been running. IBM was trying to hire and train people to be programmers, and finding it difficult to identify those with aptitude for the job. Robert W. Bemer, an assistant manager of IBM's Programming Research Department, had (as I later learned) conceived the notion that people who were good at intellectual games, particularly chess, would make good programmers. So a recruiting campaign had been mounted on that theme, with big display advertisements featuring chess knights, and copy (based on Bemer's draft) that plugged the idea that if you were good at chess, you ought to investigate this new career opportunity.

The New Yorker noted these advertisements, and sent a reporter around to learn from Bemer more about this curious profession that seemed to have something to do with talking to machines. Although the Programming Research Department had only a few months earlier announced at the Western Joint Computer Conference the release of FORTRAN, the reporter wasn't much interested in such things; it was the more glamorous computer applications of the future that he wanted to be dazzled with, and Bemer obliged, dangling before him such ideas as Russian-to-English translation, "free association by computers," and similar gee-whizzes. (After I got to know Bemer, I wondered how many of the words the story put into his mouth actually originated with him, as opposed to The New Yorker's reporter and editors; the style of speech imputed to him sounds more like the magazine's than his. But he supports the story's accuracy, writing "...anywhere the story quoted me, that is what I said.2

The story (reprinted in its entirety on a nearby page) quickly sketches Bemer ("fast-talking, sandy-haired"), then quotes him on the subject of one of the applicants attracted by the recent advertisements who knew almost nothing about computing, but "had the kind of mind we like, and will no doubt be hired by some other department of the company. He has an I.Q. of a hundred and seventy-two, and taught himself to play the piano when he was ten, working on the assumption that the note F was E ... you can see that it shows a nice independent talent for the systematic translation of values."

I read this story with just idle interest; computers, to me, were fast calculators that were used to compute trajectories and orbits, and of interest mainly to engineers. I was, for a literary type, rather knowledgeable about such things (I had attended the Bronx High School of Science, and subscribed to Scientific American, so I was Mr Science to my fellow litterateurs), but I had not imagined there was anything of use to me here. But Bemer's remarks—particularly the passage quoted—planted seeds, and these sprouted into a letter in which I told him that I was very smart, and asked for an interview.

Such was IBM's need for programmers, and so slight was anyone's knowledge of what made for a good programmer, that my letter was answered promptly with an invitation to come down for tests and interviews. I was directed to report not, as I'd expected, to IBM headquarters at 590 Madison Avenue or some such office building, but, most strangely, to a Langdon Hotel, which stood just off Fifth Avenue on 56th Street. The Langdon was an old, seedy-elegant building with an entrance so discreet that I missed it the first time past, and had to walk back toward Fifth Avenue again to find it.

I entered the small but ornate cage elevator, told the uniformed operator that I wanted the third floor, and stepped out to seek the fast-talking, sandy-haired Bemer. I had to do some wandering around the warren of rooms that IBM occupied to find him (there were no signs, either in the lobby or on any office door, to guide the stranger; this was, to all outward appearances, a quiet residential hotel for the gentry). What seemed from the hallway to be a number of separate rooms turned out to be a few large suites; apparently walls had been knocked down to make some commercially useable space out of the original hotel floor plan. I saw no computer, of course, nor any terminals, nor any machines except for some common electric calculators of the kind that might have been found in any business office. The only equipment I noted that was out of the ordinary was an array of binoculars, spotting scopes, and opera glasses, lying on desks and window sills that faced (I later learned) the dressing-room windows at Bonwit Teller, the expensive women's store on the north side of 56th Street.

If I had any conversation of significance with Bemer when I found him, it's escaped me; my next memory is of taking some standard aptitude tests that asked me to give the next item in the series 2, 4, 6, ... (they got harder than that), and to say what was to cow as lamb was to sheep. I completed these, and turned them in for grading. Some few minutes later, Bemer took me into the office of the manager of Programming Research, John Backus, and pointed out to him that while my results on the mathematics test were nothing special (by Programming Research standards), my other marks were outstanding. Backus, as I recall, just grunted occasionally while reviewing my results, but this apparently constituted approval and authorization to hire me; at least it was so taken by Bemer.

I recall only two points of the discussion between Bemer and me when he made, and I accepted, an offer of employment: I asked if I could leave a few hours early every Wednesday afternoon, since that's when my doctoral seminar at Columbia met (he said "Yes"), and he asked if I had any salary requirements, or would be content to let him fix the amount (I accepted his judgement, not having the slightest idea what, if anything, I was worth). My request for time off shows that I still hoped to get the doctorate I'd been working toward for several years. This turned out to be incompatible with learning to program, and also not to matter to me once I got caught up in my job, which happened very soon. The salary he offered me was $90 a week, which was more than I'd have dreamt of asking. All this happened on a Friday; I began work the following Monday.

It was planned that all the recruits should attend a two-week course in programming, but there were still a few weeks to go before the course started, and in the meantime we were to read some manuals, absorb as much as we could through our pores, and try to keep out of the way. My principal occupation during this waiting time was meeting my colleagues, both the veterans and the other recruits who'd been picked up during the same period. Among the veterans (or so they seemed to us new kids) was the other of Backus's assistant department managers, David Sayre; he was by training a crystallographer who had studied at Oxford with Dorothy Crowfoot Hodgkin, a Nobel Prize-winner, and was especially kind to us newcomers. (His wife Anne later wrote an engrossing biography of Rosalind Franklin, the English scientist who very nearly beat Watson and Crick to the structure of the DNA molecule.)

Another was Bill Selden, whose appearance, speech and manner made it impossible for me to think of him as anything but an English gentleman-farmer. I tried for a time to overcome this delusion, telling myself sternly that one mustn't be captivated by clichés, judge a book by its cover, and so on, only to be nonplussed when he (and his English-born wife) left IBM to breed Black Angus cattle in upstate New York.

IBM's chess-oriented recruiting campaign had attracted, of course, many who were good at chess. In fact, it had attracted Arthur Bisguier, the U. S. Open Chess champion, and soon to be a Grand Master—that is, one of the two dozen or so best players in the world. Other chess luminaries in the department, not quite as eminent as Arthur, were Alex Bernstein, a former U. S. Collegiate champion, and Sid Noble, who claimed the racy, if narrow, title of "champion of the French Riviera." So strong was the department in chess talent that someone suggested that we issue a challenge: "Programming Research versus U.S.S.R." Had we done so, we could easily have held our own on first board with Arthur, and made a respectable, if ultimately losing, showing on boards two and three. One of the lessons I can pass on to anyone who wants to use chess ability as a pointer to programming aptitude, incidentally, is that a player of the very highest caliber may find it difficult to make the transition from prince of one world to apprentice in another.

It wasn't only chess players that IBM's far-flung net had hauled in, however; one of my fellow recruits was a tall, slender young woman whose previous occupation had been high-fashion model. Burnyce Brady, with her enormous eyes, elegant carriage, and model's height, moved among us chess players and bookworms like an egret among warthogs; she also turned out to be one hell of a programmer, probably the best of our bunch. Another of my intake-group was Bob Brill, who was not so much a chess player as a chess problem-setter; he devised ingenious "White-to-move-and-mate-in-four" puzzles, and was also a writer, musician, and proto-hippie. When Brill and I first dropped in at 590 Madison for some meeting or other, the elevator starter approached us to ask politely about our destination; visitors wearing berets and carrying guitars, as Brill was, were not common in those days at IBM headquarters. (I was still in the academic uniform of the time: tweed jacket and grey flannels.) Brill and I went on to work together on several projects, some official IBM business and a few not, as will be related.

When the course for which we were waiting opened up, we spent two weeks learning the SHARE Assembly Program (SAP) language for the IBM 704. That machine was still quite new; only a handful had been delivered, and ours was only the second or third course ever held in its use. The Old Guard of programmers had grown up using the IBM 650, whose memory was a magnetic drum, and their war stories were full of the term "latency time," since a large part of their art had consisted of timing the issuing of read operations to coincide with the moments when the drum had just brought the wanted data under the read head. We young punks whose first machine was the 704, with its 32K of randomly-addressable 36-bit words, would never know the rigors of Real Programming. (I feel the same way today toward the new young punks who will never know what "turn-around time" meant to those of my generation.)

The course was good (I wish I could remember the instructor's name [added in June 2006: I'm delighted to report that some 50 years after we first met, Bob Brill and I are back in touch, and he tells me that the instructor was Dick Cole]); the student body was composed partly of IBM employees, partly of customers, all of us eager. When it was over, and we Programming Research recruits got back to the Langdon, we plunged into post-graduate work: studying the listings of the FORTRAN compiler. I'm not sure which section of it I was given; memory suggests that it was Section 5, in which actual index registers are assigned to replace the virtual registers that were employed up to that point. We paired off for mutual support—a good idea, since there were times when any of us, working alone, would have given up—and plunged into endless piles of assembly-language code. There was practically no documentation. I recall no printed comments, at least none of any value, in the listings themselves, and as for flow-charts, they were what we novices were supposed to turn out in the course of this exercise, partly to demonstrate our understanding, partly to ease the way for the next generation of beginners.

As we read the code, we flow-charted. As the flow charts grew, we Scotch-taped page to page, since we didn't know enough yet to be able to identify distinct modules or procedures that could safely be relegated to separate pages. The code didn't lend itself very readily to such treatment, in any case; this was, remember, a vast, undifferentiated torrent of assembly-language code, whose main organizing principle was not "while" or "until," but rather "Oh, and another thing!" (If you take this as a dig at the FORTRAN designers and implementers, you are badly mistaken; that would be like criticizing Lewis & Clark for not taking Interstate 80 when traveling west.) The scroll of flowcharts spilled off our desks onto the floor; it sprouted side branches; it curled back on itself. We must have seemed to spectators to be engaged in something like a quilting bee (except that real quilters know exactly what they're doing).

From time to time, we would have a moment of insight in which we suddenly understood what the author of the code was doing: entries in different tables would finally come together to accomplish something whose purpose was evident, values shunted mysteriously around from one register to another would turn out to be vitally necessary indexes to some construct that had been read out to tape pages and pages ago (magnetic tapes were being read and written continually; no disks, remember). When one of these small epiphanies occurred, we would immediately write some documentation to record it; for posterity, yes, but first of all for ourselves, before we forgot it. After we'd had one of these triumphs, we'd look for a moment when the Author, or at least one of the Authors, was free, and approach him to ask if our understanding was correct. The usual answer was, Almost. They were quite patient with us, even though it must have been evident that our questions were at least half showing off and bids for praise.

Little by little, over the course of a few months, we began to learn something of programming. Besides deciphering and documenting the FORTRAN compiler, we had little programming tasks assigned to us. Brill and I were given the task of finding the most efficient hashing algorithm for the two-hundred-odd three-character operation codes of the 704. Several years later, in my first non-technical paper (Halpern 1964), I told a story that grew out of this task . (As submitted, the paper bore the title "On the Economics of Using Computers: Reminiscences and Prophecies on the Occasion of FORTRAN's Tenth Birthday," but editors hate long titles and have no souls.) The piece doesn't deserve reprinting here in its entirety, but a sample is given below. I am emboldened to offer it in part by the fact, which I record with great pride, that it was praised by Harlan Herrick—"Funny, and true"—not a man given to bandying compliments.

A pair of us, green beginners just out of a two-week course on SAP language, were running our first program on an early 704, and got carried away when answers began appearing at the on-line printer. Forgetting our plan to take just a few lines on the printer and then switch to outputting on tape, we stood transfixed at the printer for more than 20 minutes while the results of perhaps 40 seconds' worth of computation were slowly doled out by that miserable old clunker, the 716. When the bill reached our boss (one R.W. Bemer), he took our heads, one to a hand, and brought them smartly together—the act, we decided, of a mind unhinged by grief. The ringing in our ears subsided; the idea that computer time costs money remained. Such was programmer training in the Old Days, and we survived, with a slight loss of response to tones above 15,000 cycles that would have come in the course of nature anyway.

The piece goes on to talk less cutely, but more usefully, about the reasons why the FORTRAN authors had concentrated so obsessively on producing efficient object programs even though they did not themselves believe that it was the supreme issue, and how the change in the relative value of computer time had made it even less important in the years since FORTRAN had appeared.

While Brill and I were busy with these things, high-level plans for us were changing. The grand idea behind the hiring of so many new hands by Programming Research had been, I learned sometime during this period, to enlist us in a project to write a language and compiler that would be to the commercial world what FORTRAN was turning out to be to the scientific/engineering world; this was the "COMTRAN" that is refered to in (Bemer 1957):

With the addition of more generators and additional superstructure in the language it also ceases to be FORTRAN and becomes COMTRAN as we have envisioned it.

But COMTRAN was not to be, at least not at our hands; first, its name turned out to have been preempted by some other product, so it had to be redubbed "Commercial Translator," a name that no-one could have been persuaded to use; second and more important, its function was preempted by a project called COBOL, which had captured Defense Department and computer industry sponsorship. It was decided that most of us apprentices would instead get involved in rewriting FORTRAN for the forthcoming IBM 709, which remedied some of the shortcomings of the 704's input-output facilities, but was otherwise much the same machine.

This change of direction was accompanied by relocation. We moved to 425 Park Avenue, where IBM had leased a couple of floors of standard modern office space, with cubicles in the open interior for the working stiffs, managers' offices around the periphery, and the general charmlessness that strikes a certain kind of mind as 'businesslike'. We were even required to punch in and out on time clocks (IBM still made these). No trout pulled out of its deep green pool into the thin choking air could have experienced greater shock than did we happy, innocent recruits. This was the reality of working for a hard-driving market-oriented American business, and the idyllic conditions in which we'd worked for the first several months of our employment were extremely unusual and unearned bonuses we had enjoyed only because we were nominally members of the group, already semi-legendary, that had written FORTRAN. We knew this; nevertheless, I for one never recovered from this early taste of heaven. I think my entry into the world of programming at its pinnacle has left me with expectations and standards that have affected my career and life in many ways, not all good.

I seem to have known that in leaving the Langdon, I was doing more than just changing my address by a few blocks, because I uncharacteristically took a souvenir: I still have a wooden hanger labelled "The Langdon Hotel, 2 East 56 Street, New York, NY" that is probably the last surviving physical relic of the place [added in June 2006: this hanger, along with some 15 cartons of computer memorabilia, is now at the Computer History Museum in Mountain View, California, where it enjoys a proper home thanks to Paul McJones, whose services as a volunteer recruiter and archivist the Museum is very lucky to have]. One other experience dating from Langdon days I want to unburden myself of before quitting the topic as well as the place: One morning a group of us Programming Researchers were riding up to our floor when the elevator operator, a man in his fifties or perhaps well-preserved early sixties, told us that he had been, with no advance warning, laid off (the Langdon was scheduled to be demolished soon). He mentioned how long he had been employed there—it was an impressive number of years. Now he was suddenly out of a job, with no idea what to do next. One of us mumbled something sympathetic, but we felt more embarrassment and guilt than compassion, I think. The idea that computers were going to put some people out of work had not yet become a commonplace, but the impending demolition of the Langdon, and the obsolescence of elevator operators, were events that we felt somehow to be connected with what we were doing upstairs; he was a victim of Progress, and we were par excellence its standard-bearers.

At 425 Park, the FORTRAN authors had offices one floor above the mob of ordinary, non-legendary programmers of which I was part, and to protect themselves from constant questions from those working on FORTRAN for the 709, they limited our access to them sharply; we were permitted to approach them only within a two hour window on Thursday afternoons. They themselves were engaged in an Artificial Intelligence project of some kind; it was connected with the work reported by R. M. Friedberg in the January 1958 and July 1959 issues of the IBM Journal of Research and Development.

This was very early and very naive AI work: an attempt to realize 'machine learning' by permuting sequences of machine instructions more or less at random, and then testing the output of each resulting 'program' somehow to see if it constituted progress toward some pre-established goal. I was baffled to see the greatest programmers in the world involved in a project that was so obviously ill-founded; if such permutations could yield anything of value at all, the units permuted should, it seemed to me, be programming-level functional blocks, not hardware-level instructions. In any event, nothing significant came of this effort, and the original FORTRAN team gradually broke up, its members wandering off to pursue a variety of other interests.

My interest in AI, and my highly critical attitude toward it, were aroused partly by this experience, partly by my reading of Turing's classic 1950 paper on computing machinery and intelligence, which had just been reprinted in the four-volume World of Mathematics edited by James Newman. My reaction to Turing's argument was that it was so transparently fallacious that it would either be promptly forgotten, or laughed out of court by the first critic with enough spare time to write an expose. I could not, as we all now know, have been more wrong .3.

During the period at 425 Park—roughly late 1957 to about 1959—the Association for Computing Machinery started publishing Communications of the ACM, and Bemer, still my manager, had become its editor for 'Techniques.' He needed material, and suggested that I write something on the family of table-handling subroutines I was just completing. The brief note I wrote was published in the second number of CACM (February 1958), pp. 1-3, and I thought of it as simply a filler I'd written to accommodate Bemer. Many years later I found that note, to my surprise and amusement, cited by Don Knuth in one of his landmark volumes; it seems I had been the pioneer of a particular path of technical development, and Knuth, with his exhaustive scholarship in the literature of computer science, had uncovered the note and given me due credit.

In truth, it was easy in those days, indeed almost unavoidable, to be a pioneer. Almost everything was being done for the first time: write a subroutine, and you were an innovator; write two, and you were an authority. And for the most part this was taken for granted, and most of these innovations went undocumented. This practice of inventing without publishing was especially marked in those of us whose professional character was formed under the influence of the FORTRAN team—many of whom have never appeared in print except for the paper in which they announced FORTRAN, which may be a world record for saying nothing unless you've got something to say—but it wasn't unique to us. I've often heard from programmers who were active in those days that they routinely developed ideas and techniques, under pressure of necessity, that were published years later as someone else's discovery. It's an entirely unfair advantage we scribblers enjoy that our work endures to be discovered by a Knuth when the earlier efforts of someone who just wanted to get a job done are forgotten.

Another aspect of the programming life of the time: programmers were glamorous creatures then. It was not yet the case that everyone's brother-in-law and ex-wife were "in computers." Many educated people had barely heard of computers; there were no Computer Science departments at every junior college. I was a guest during the period at a dinner party given by perhaps the most eminent woman in the world. She was of course the center of attention, but each of us was given a moment of recognition. When my turn came to be asked "what I did," I replied in a sentence or two, thinking no one at the table would understand or care, that I worked with computers for IBM, and that I was currently trying to make machines understand English. To my surprise and slight consternation, everyone at the table turned to me with excited questions, and I found that I had, temporarily, stolen the limelight from Mrs. Franklin D. Roosevelt.

There were dozens of programmers but no computer at 425 Park; to run a program, we walked over to the Service Bureau Corporation installation a few blocks north on Lexington carrying deck, tapes, and other equipment: if a FORTRAN compilation was to be run, it was wise to bring a paperback to read. I found Wodehouse and classical English country-house murder mysteries just right to help me through the quarter-hour waits while FORTRAN endlessly wrote and read tapes; they also helped to keep me in good temper when the compilation abended after much tape back-and-forthing because one of several fixed-size tables had overflowed. Along with recreational reading, it was wise to bring one's own loaders (both the upper-memory and the lower-memory kind), since the operator couldn't always locate the one you needed. After a run at SBC, we carried our decks, tapes, listings, and dumps back to 425 Park to analyze them, fix the bug, and schedule another run.

So one didn't fix bugs then by throwing computer time at them. If you had the object code representation of your faulty program (physically, a deck of "binary" cards, each card containing about 16 absolute machine instructions), and the problem was one that could be cured by changing or inserting a handful of instructions, you often chose to save time by patching the object code by hand. You could, that is, by exercising the severest concentration, hand-assemble the necessary instructions, compute a checksum and loading address, and then generate patch cards to be appended to your old binary deck.

You created the necessary binary patch cards by hand, using a machine—I think it was called the 012 Keypunch—that was a squat little paleolithic ancestor of the modern gadget that imprints your credit card information on a paper slip. You fed a card in face up, and punched into it, one column at a time, the binary code you'd computed by hand (the keyboard was purely numeric). It would advance one column every time you pressed one of its big round keys, unless you simultaneously pressed another that inhibited the carriage advance. Your keypress also supplied the power to perform the carriage movement; this was too serious a process to be entrusted to new-fangled electrical power. Using this machine was such a challenge, and evoked such intense concentration, that I don't think I ever made a mistake when creating a patch. This procedure saved you a compilation or an assembly (if you did it right), and got you back on the computer a day sooner.

It was with mixed emotions that I learned recently from the editor of the Encyclopedia of Computer Science and Engineering that in updating for its third edition some articles I'd done for the earlier ones, I needn't bother with the one on "Patch"; it was being dropped, since no one knew or cared about the subject any more. I'm mostly glad about this, but I understand better the feelings of the elevator operator at the Langdon. I've lived to find one of my hard-earned skills obsolete, and it's an experience that takes a little digesting.

After a year or so on Park Avenue, we re-organized, and moved, again—this time to the Time-Life Building on Sixth Avenue. The reorganization had Brill and me still working for Bemer, but at arm's length; he had relocated to White Plains. At Time-Life Brill and I worked for several months implementing on the 709 an idea of Bemer's for effectively tripling the capacity of a communication channel used for the transmission of natural-language messages. Bemer had observed that the speed and memory of the 709 would allow the formation of a memory-resident dictionary of the ten thousand most common words of any natural language, and the scanning of outgoing messages for the presence of those words. When one of the dictionary words was found in a message to be transmitted, it was replaced in the outgoing message buffer by its index in the dictionary. Another 709 at the receiving end, equipped with the same dictionary, replaced the index values it found in transmitted messages with the original character strings, reconstituting the message exactly.

Since the statistics of natural-language usage indicated that the ten thousand most common words of English were on average six characters long (seven with their trailing spaces), and accounted for over 80% of all the words to be found in standard running text, more than three-quarters of the message stream could be sent word-by-word rather than character-by-character. The net gain was, as noted, an effective tripling of the channel capacity.

Brill and I implemented this idea of Bemer's, and were gratified to see that it achieved almost exactly the predicted performance gain; it was especially attractive in that it did not change the message in any way, but was perfectly transparent, and therefore usable in combination with any other technique of encryption or compression. The dictionary could also be made continuously self-correcting—I think this was a refinement that Brill and I added to Bemer's idea—and we built into our prototype something of this: those words in text to be transmitted that were not found in the dictionary were not simply ignored, but recorded along with counts of their occurrences. When one of these orphans was found to occur more often than the least frequently-occurring of the words in the dictionary, the incumbent was kicked out, and the challenger installed in its place. In this way, the dictionaries (at both ends) could continuously adapt to whatever special vocabulary users might employ as the system was used .4.

Bemer threw off ideas like this in profusion; there were few months during which we didn't see a proposal from him on such things as character sets with interesting properties, generalizations of concepts such as indirect addressing, and ways of regarding and using recursion. He was equally remarkable for his manual dexterity with calculators. It was impressive enough to watch him handling one of these Friden, Monroe, or Marchant machines, but I was told that he had also increased the performance obtainable with such a calculator by devising a way to enter useful information during the carriage return, a period in which, conventionally operated, it was idle. His career at IBM might have been even more successful if he hadn't been so quick, so inventive, and so impatient with the relatively plodding minds that he generally had to deal with .5.

I mustn't give the impression that he (or any of us, for that matter) was merely an unworldly techie, brighter than was good for him; a party he threw in his house up in Connecticut has lived in my memory all these years. Like most New Yorkers, I had no car, so my wife and I arranged to be picked up by some people who were driving (Dick and Lee Ridgeway, I think). The manner in which we were picked up gives something of the flavor of the period. Our transport's route did not take it past our door, and it seemed too stodgy, too un-Programming Research, to ask that a detour be made on our behalf. So Phyllis and I, having found by reconnaisance that there was a turn-out off the Henry Hudson Parkway just a half-mile or so north of our house, walked through Fort Tryon Park, did a little clambering over a wall or two, and got to this turn-out in good time so that the car could pull in for a moment, take us aboard, and be on its way to Connecticut without delay. That, we felt, was the way Phase 5 of FORTRAN would have done it.

At Bemer's, all was happy bedlam. Bemer kept a few sheep; just enough to get his property classified as a farm for some tax purposes (such was the story I heard at the time; Bemer says now that they were for the more prosaic purpose of keeping his lawn mown). Dave and Geneva Hemmes had brought a large dog (along with a large family), and the dog found his life's dream at last fulfilled when he saw the sheep. The hysteria outside was closely matched inside, where everyone was demonstrating to everyone else the real way to drink wine from a bota, which seemed to call for saturating carpet, clothing, and hair before hitting your mouth with the stream. I seem to recall also a jam session involving Bemer at the piano and Brill on the guitar, but the strength and quantity of the Rioja have lowered a warm red veil over the details of the afternoon. My last clear image is of Dick Ridgeway, who'd driven us home again, being merrily carried into our apartment by his wife Lee (they were the originals after whom the Jack Sprats were patterned).

I mentioned earlier that Brill and I undertook a project or two on our own initiative. One was an effort to use the computer to win the "Tangle Towns" contest being run as a circulation-boosting stunt by the Herald Tribune (the last remaining rival in America to the New York Times as a newspaper of record). "Tangle Towns" offered contestants a specified quantity of each letter of the alphabet, and required of them that they form, from this stock, names of towns in New York State. Points were awarded mainly for the number of names formed, and the number of letters used; a few other factors were thrown in to spice the mixture, such as extra points for using certain letter combinations. The grand prize was $50,000, which in circa-1959 dollars was real money.

We saw this as a natural job for the computer, and the contest rules had nothing to say about the use of such aids, so we wrote a program, cleverly called "50G," to win the contest for us. 50G generated all possible solutions systematically, compared the score of the latest to the highest-scoring solution so far, and saved the better of them as the current 'best solution.' Since some town names, because of the number and combination of letters they used, were obvious winners, we forced them as part of the solution, thereby also speeding the formation of all trial solutions. To maximize program speed, we unwound all loops; if a sequence of code had to be carried out n times, it appeared n times in the program. We were aware that even hours of computer time would not suffice to exhaust the solution space, but thought that the systematic exhaustion of even a small fraction of it would probably find a better solution than anyone could generate by hand. The contest was wildly popular (every public library in the city was emptied of New York State guidebooks, atlases, and gazetteers), but we feared only other programs, written by programmers with more machine time at their disposal than we had.

The necessary hours of computer time could not, of course, be found on any machine available to us in the city, but we knew that in Poughkeepsie, where IBM built them, some 709's stood idle all night. We got permission to use one such machine, and visited the plant two or three times, each time getting runs of several hours. When we reached the contest deadline, and had to submit our solution, we found that we had exhausted something like 3% of the solution space. The $50,000 was won by a Staten Island housewife who had generated her solution with paper and pencil, working at her kitchen table.

Poughkeepsie was also the scene of a more rewarding experience for me during this period; it was where I first experienced complete man-machine rapport. I had some heavy testing and debugging to do on the family of subroutines I mentioned earlier, and, again, couldn't get the amount of machine time I needed in the city. A 709 that was used by some engineers during the day was available to me all night in Poughkeepsie, but I was told that I'd be alone with the machine, and have to serve as my own operator. I started out very slowly, but gradually developed speed and accuracy, and by the second or third night was putting on a pretty good imitation of an experienced operator, hanging tapes, loading decks, keying in addresses on the bank of rocker switches on the console, and so on as if I'd been doing it for years.

But something more than this emerged: as I spent hour after hour testing my routines, finding and fixing bugs, and pushing the tests further, I began to know exactly where the machine was in my code. I must have become sensitised to the movements of the tapes, the display lights on the console, and other cues the machine was emitting, because I found that when the machine stopped and displayed the address at which it had halted, I knew why it had stopped, and what the fix was. I'd key in corrections immediately, restart execution, and move on to find the next bug.

The intensity of my imaginative union with the machine put me in a state others have described as resulting from drugs, but there was nothing unnatural about the experience. Its explanation, I'm sure, was simple: I knew my own code very well, and now I had something like mastery of the machine. The combination amounted to true synergy, and gave me a degree of insight into what was happening that was different in kind from anything I'd known before, or perhaps since. It can be achieved, I believe, by any programmer who can afford a similar sustained and intense assault on a technical problem, with his computer as his close partner, almost his alter ego. I'm sorry for any programmer who hasn't had the experience at least once; he's missed one of the greatest things the programming career can bring.

In the world of down-to-earth programming, Brill and I found ourselves increasingly interested in the macroinstruction as a fundamental concept and construct in the development of software in general, and language processors in particular. This interest, and the work it led to, antedated Doug McIlroy's classic CACM paper on the subject, which did not appear until April 1960 (Brill and I read it when it did appear, and we kicked ourselves for having let someone else write the first paper on the subject, since we had actually advanced somewhat beyond McIlroy's position in our own thinking). Not only had Brill and I pursued, independently, McIlroy's line of thinking, but we had begun to build a macroprocessor embodying our notions, calling it "XPOP" for "eXPander and OPtimizer." (Our exposure to the culture of FORTRAN made us supersensitive to the question of performance, so the need to optimize macro-generated code was in our minds from the beginning.) Brill's career path and mine diverged widely before XPOP started generating papers and attracting attention, but it should be recorded that it began as our joint project.

At some point in the period under discussion—1959-1961—we reorganized yet again, and Brill and I found ourselves reporting to Bill Heising, a FORTRAN expert (but not one of its authors) whose training had been in chemistry. Bill was a high-level, widely respected technical man, whose style was as low-key as Bemer's was high, and who, as our manager, was almost as distant as Bemer, up in White Plains. We might have cruised along endlessly in this mode if IBM had not had one of those periodic mental seizures that large organizations mistake for ideas: this time it took the form of an announcement that we software folk located in the city would, in the near future, be moved up to Poughkeepsie so as to be in closer touch with the hardware people. The notion that software and hardware people should be located together so as to achieve closer understanding and collaboration is by no means without merit, but IBM completely disregarded the human side of it. To many of us—more of us, it turned out, than even I realized—the idea of relocating from New York City, the center of the world, to the dreary company- and college-town of Poughkeepsie, was either too funny or too sad to be contemplated.

If I'd had more experience, I'd have known that this was just a trial balloon by management, and not something to fret over, but I knew no better than to assume that, since management had announced it, it was going to happen. And since I knew I didn't want to go to Poughkeepsie, I started looking around at alternatives. One of these was RCA, which was advertising for people in my business (although the fact that their display advertisement in the Times called the products they wanted to build "compliers" wasn't reassuring).

I went to an RCA interview, and asked for Mr Smith (or whatever), as their letter had instructed me to. Mr Smith later turned out not to be Mr Smith; that was a generic name adopted by all their interviewers for a given group of jobs, but that silliness paled before his questions, one of which was "How would you rate yourself as compared to the people you've worked with?" I told him that I was by far the weakest of them, and then—after a dramatic pause—mentioned the names of those people, supposing that this would reduce him to stunned awe. How I could have been so foolish as to suppose that a man who wasn't sure of his own name would know those of the FORTRAN authors, I can't now imagine; all he understood from my reply was that I was by my own admission a poor performer.

Another question from "Mr Smith" was "How many years experience have you got in circuit design?" I reminded him that I was there in answer to their advertisement for compiler writers; he said he knew that, and repeated the question. The cap to this farce was that some weeks later, after I'd dismissed the interview as a bad dream, I got an excited telegram from RCA, telling me that I was badly wanted at their Moorestown, New Jersey plant, and asking me to present myself there for an important meeting. When I arrived, I found no one knew who had sent the telegram, or why I might be wanted. The experience made me realize how lucky I was to be with IBM.

My literary habits came in handy at this point. I had been reading Henry James, and a pungent line about Poughkeepsie from Washington Square came back to me when IBM told us it was to be our new home (I felt it especially appropriate to enlist James in my support; he would have loved computers and word-processing software—he was one of the first writers to use a typewriter, demanding only that it offer a voice interface):

Nevertheless, he had offered her a home under his own roof, which Lavinia accepted with the alacrity of a woman who had spent the ten years of her married life in the town of Poughkeepsie.

I ran off dozens of copies of this passage on the copying machine of the day [added in June 2006: the machine was probably a Ditto] (it made smudgy copies in purple ink, but I worked hard at their quality, and the few in my possession today are still legible). I dropped copies anonymously in everyone's mail slot, and they caused some amusement. They may even have had some effect, because, as I learned several months later, long after I had left, IBM got so much resistance to its planned move that it was forced to cancel it, and all my friends and colleagues remained safely in the city.

I don't know how my search for a job came to the attention of Dave Hemmes, a Californian who had been lured east by Bemer, only to be driven back to California by New York winters, slush, and frozen pipes. But somehow he learned about my situation, and put me in touch with the right manager at the Palo Alto Research Laboratories of Lockheed Missiles & Space Company. I flew out for an interview there; it was my first trip west of the Mississippi, and my first flight on a jet (as new and glamorous as computers). I got an offer of a position as "Head, Programming Application Research," and accepted it.

So ignorant of the part of the country we were heading into were we that we fancied we'd live in San Francisco—west coast equivalent of New York, as we saw it—and I'd commute to Palo Alto. (A magazine article told me that it was "always topcoat weather" in San Francisco, so I bought a second topcoat. It hangs in my closet today, thirty years old and brand-new.) Phyllis and I bought our first car—a 36-horsepower Volkswagen Beetle—loaded the roofrack with supplies to be used en route, settled our daughter Leda, two years old and still in diapers, inside, and headed west.

Bemer, Robert October 1957. "The Status of Automatic Programming for Scientific Problems," Proceedings of the 4th Computer Applications Symposium, Armour Research Foundation, pp. 1-12 (the line quoted is on p. 7)

Halpern, Mark April 1964. "Computers and False Economics," Datamation, pp. 26-28 (the passage quoted is on p. 26)

Halpern, Mark 1990. "The Turing Test and the Ideology of Artificial Intelligence," in Binding Time. Norwood, NJ: Ablex Publishing Corp., pp. 1-29.

Kahn, David 1967. The Codebreakers. New York: Macmillan.

Even an injection of the wonder drug of modern business—the electronic computer—failed to stem the decline [of commercial cable codes]. Robert W. Bemer of I.B.M. proposed placing a business vocabulary in a computer memory and assigning digital "codewords" to its words and phrases on the basis of frequency—shorter groups of digits for the common phrases, longer groups for the less used ones. The computer would automatically encode the message. Bemer called the idea "digital shorthand" and found that it would compress a message to one third its normal length, thereby in effect tripling the capacity of a communication link. But though the method was technically feasible, economically it never got off the ground, and the code business remained moribund.

Kahn attributes the failure of commercial codes to the rapidity with which they become obsolete. The world and its terminological needs change too fast, he says, for the process whereby such codes were traditionally compiled, and this slowness to adapt killed them. This may well be true, but it cannot be the reason for the failure of Bemer's idea, as implemented by Brill and me. As indicated in the text, our program continuously updated the dictionary on the basis of actual message traffic. (We had also conceived of, but not implemented, a further feature whereby lengthy messages needing very specialized dictionaries could be prefixed by a code instructing the computers at both ends to install them.)

5Bemer retired from IBM in the position of Director of Programming Standards for the corporation; no mean achievement. But in my view he was a natural-born entrepreneur, not a corporation salary-man. Had his career put him in Silicon Valley in the '80s, he'd have talked some venture capitalist into grubstaking him, and become another Bill Gates or Steve Jobs.