Monday, April 29, 2013

John C. Reynolds, June 1, 1935 - April 28, 2013

Yesterday, John Reynolds passed away. I had the privilege of being one of his graduate students, and much of what I know about what it means to be a scientist is due to his example. I just want to share a few small anecdotes about him.

  1. When I was a new graduate student, I began working on the project which would eventually become my thesis. When I described one of my early approaches to this problem, he asked a series of questions about how I would handle one sticky technical point after another, and I showed him how the language and its semantics were carefully set up so that this issue in question could not arise. After I finished my explanation, he nodded thoughtfully, and told me, "Neel, you've done some very good engineering, but engineering is not science! Good engineers develop a sense of how to avoid obstacles -- but a scientist's job is to face them head-on and flatten them."

    This made a really big impression on me. As academic computer scientists, we have two great luxuries: we can choose what to study, and we can spend as long as necessary studying it. As a result, our ethical obligation is one step removed from solving problems: our role is to produce understanding, so that engineers (indeed, all of society) have new methods to solve new classes of problems.

  2. Once, John told me about some of his work at Argonne National Laboratory, where he designed the COGENT programming language, which he told me was what convinced him that he should leave physics to do computer science. He said that while today he could (indeed, many people could) design much better languages, he would always regard it fondly, since it was his first successful language design.

    I asked him what made it successful, and he told me that there was another scientist at Argonne, who used it to write some simulation code. When John read the program listing, he realized that he could not understand how the program worked, since it relied domain knowledge that he lacked. So this was John's definition of a successful language design: if you have a user who has used it to write a program you couldn't have, your language has succeeded, since it has helped a fellow human being solve one of their own particular problems.

    I've always liked his definition, since it manages to avoid an obsession with nose-counting popularity metrics, while still remembering the essentially social purpose of language design.

  3. Another time, I asked John what he thought about object-oriented programming. He told me he thought it was too soon to tell. I burst out laughing, since I thought he was joking: Simula 67 is considerably older than I am, and I thought that surely that was sufficient time to form an opinion.

    But he insisted that, no, he was not kidding! From a formal, mathematical, perspective, he did not like object-oriented programming very much: he had studied various formalizations of objects in his work on Idealized Algol and on intersection types, and found they introduced some unwanted complexities. However, so many excellent engineers still thought that objects were a good idea, that he was unwilling to dismiss the possibility that there was a beautiful mathematical theory that we haven't discovered yet.

    I thought this was a great demonstration of Keats's negative capability, but what makes it really impressive was that John married it to a profound intellectual rigour: I've never known anyone who could produce counterexamples faster than John could. While he tested every idea ruthlessly, he never closed himself off from the world, giving him a rare ability to make judgements without passing judgement.

I haven't really said anything about John's enormous scientific achievements, because the deepest lesson I learned from him is not any one of his theorems, but rather his fundamentally humane vision of science, as something we do for and with our fellow scientists and community.

Ars longa, vita brevis, but together we make a chain through the ages --- and more links of that chain than most can claim were forged by you, John.


  1. Though I wasn't one of John Reynold's graduate students, I did have the fortune of taking his class on Hoare logic and separation logic. Like Neel, I think the greatest thing I learned from him was his vision of science and the world.

    He was one of the most humble people I have ever met, yet probably the most brilliant! I remember once asking him about how he discovered the simply typed lambda calculus, and he said it came to him in an afternoon. It was nothing, really—after all, Girard was the one to discover F_sub and show the correspondence between the two. From that point on, whenever people would say of someone, "well, X has the right to be arrogant because he/she is so brilliant," I would provide John Reynolds as the obvious counter-example. :)

    Early in my graduate studies, I quickly noticed a trend that is familiar to most programming languages researchers: John Reynolds discovered just about every important problem in the space about 20 years before anyone else even realized its importance. You will often see text of the form, “This problem has been considered by many researchers, e.g., [Aaa92, Bbb95, Ccc98, Ddd05], though it was originally discovered by Reynolds [Rey71].” And not in just one area, but many, ranging from intersection types to polymorphism to subtyping and coercions.

    Some professors hold themselves in very high esteem and insist that others defer to them with great respect and admiration. We all held Reynolds in great esteem and respected and admired him, but it was because he was always willing to listen to others and wanted to see what he could learn from them. For instance, once he introduced himself to one my academic siblings, Ciera Jaspan, when she was still a student at CMU. He said (and I paraphrase), “I don’t know you, but I’ve often seen you talking to my students, so I should learn more about you. Who are you, and what do you work on?” (She, of course, knew him, but was a bit intimidated by his expertise!)

    When teaching separation logic, he spoke of the broken “frame property” in his and O’Hearn’s original work on the logic. I liked his wry and amusing characterization: “Well, we know less than we did before, but more of what we know is actually true.”

    Once he gave a presentation showing how you would use separation logic to verify the behavior of an XOR linked-list (which stores both the previous and next pointer in one field, using a bit manipulation trick). Someone asked, “yes, you can verify this, but why would you want to verify such a terrible program?” To which Reynolds responded, “ah yes, but once you have verified it, it’s not a terrible program anymore!”

    Reynolds was a great man and a great scientist, and he will be very missed.

  2. I only spoke with John a few times, but I always enjoyed our conversations. I never managed to get a chance to probe him more deeply about his 1975 paper, which I believe captures some of the essence of object-oriented programming. He didn't call them objects, he called them "Procedural Data Structures". Its still a great read, as it also contains the initial seeds of "expression problem". See
    This work, along with Zilles "Procedural encapsulation: A linguistic protection technique" in 1973 were the first steps toward clear descriptions presentations of objects independent of particular programming languages.

  3. Thanks for this great post, Neel.