• DOI:10.1145/954092.954488
• Corpus ID: 35605565

Robert W Floyd, In Memoriam

@article{Knuth2003RobertWF,
  title={Robert W Floyd, In Memoriam},
  author={Donald Ervin Knuth},
  journal={SIGACT News},
  year={2003},
  volume={34},
  pages={3-13}
}

• D. Knuth
• Published 1 December 2003
• Computer Science
• SIGACT News

Nobody has influenced my scientific life more than Bob Floyd. Indeed, were it not for him, I might well have never become a computer scientist. In this note I’ll try to explain some of the reasons behind these statements, and to capture some of the spirit of old-time computer science. Instead of trying to reconstruct the past using only incidents that I think I remember, I will quote extensively from actual documents that were written at the time things happened. The remarks below are extracted from a one-hour keynote speech I gave to the Stanford Computer Forum on 20 March 2002; many further details, including images of the original documents, can be seen in a video recording of that lecture, which has been permanently archived on the Internet by Stanford’s Center for Professional Development [scpd.stanford.edu]. As in that lecture, I won’t attempt to give a traditional biography, with balanced accounts of Bob’s childhood, education, family life, career, and outside interests; I believe that the intriguing task of preparing such an account will be undertaken before long by professional historians who are much more qualified than I. My aim here is rather to present a personal perspective. My first encounter with Floyd’s work goes back to 1962, when I was asked by Computing Reviews to assess his article “A descriptive language for symbol manipulation” [Journal of the Association for Computing Machinery 8 (1961), 579–584]. At that time I was studying mathematics as a second-year grad student at Caltech; he was working as a programmer-analyst at Armour Research Foundation in Chicago. Since I had recently completed a compiler for a subset of ALGOL, and had read the writeups and source listings of several other compilers, I was immediately impressed by what he had written [see Computing Reviews 3 (1962), 148, review #2140]: “This paper is a significant step forward in the field of automatic programming. Over the past few years, simple algorithms for analyzing arithmetic expressions have been discovered independently by many people. But conventional methods for explaining such algorithms obscured the essential facts. Floyd has developed a new notation which lets the trees be distinguished from the forest, and which admirably points out what is really going on in a translation process. An algebraic compiler can be described very precisely and compactly in this notation, and one can design such a compiler in Floyd’s form in a few hours.” In essence, Bob had introduced the notion of productions as an organizing principle for programming, anticipating to a certain extent the future development of so-called expert systems. My own work on programming was merely a sideline by which I could pay for my college education and prepare to start a family. During the summer of 1962 I wrote a FORTRAN compiler for a small UNIVAC computer; this work had almost no connection with what I viewed as my future career as a teacher of mathematics, except that I did spend one fascinating day studying the efficiency of “linear probing” (the simple hash table algorithm by which my compiler maintained its dictionary of symbols). I had never heard of “computer science.” My whole attitude changed, however, when I met Bob for the first time in person at the ACM conference in Syracuse at the end of that summer. We became fast friends, perhaps because we had both learned programming in the late 1950s by sitting at the consoles of IBM 650 computers. Bob showed me some work he had been doing about mathematical techniques for verifying that a program is correct—a completely unheard-of idea in those days as far as I knew. The accepted methodology for program construction was quite the opposite: People would write code and make test runs, then find bugs and make patches, then find more bugs and make more patches, and so on until not being able to discover any further errors, yet always living in dread for fear that a new case would turn up on the next day