People of Language Design and Implementation

An interview project in conjunction with PLDI 2019  

 

MZ: Can you tell us a little bit about yourself?

AA: I grew up in the small town of Bowling Green, Ohio. My mother and stepfather were both music faculty at the local university. My mother put me in a program called "CompuKids" when I was in the fifth grade, where I got to go in the afternoons to the university and play with teletype computers - something like a very noisy typewriter with a big roll of paper that unspooled as you typed.

MZ: So that your first exposure to computers?

AA: Yes. I learned to program in that course, and I was so interested in it that I continued after the course was over. I kept finding reasons to hang around the university's computer science department and I eventually started taking classes. I maintained my computer science interest all through high school through my university connection.

MZ: Did you go to college to study computer science?

AA: Yes, but I was also very interested in music, and after I graduated from high school I was more focused on a possible music career. I did my undergraduate work at Bowling Green, where I majored in music and computer science, but I spent most of my time on music.

MZ: That's surprising! So you were planning to become a musician and primarily studied music in college, but you did not end up pursuing a career in music?

AA: That's right. After I graduated from college, I went to Europe for a year, where I lived in Salzburg, Austria and worked as a semi-professional musician, meaning I did pick-up work and substituted in orchestras and bands when the full time players wanted time off. I also learned German and continued studying music at the Mozarteum, a well-known music conservatory. It was a great year, but toward the end of it I realized that I wasn't that interested in pursuing the life of a professional musician after all. At that point I decided to switch completely to computer science and I applied to graduate schools.

MZ: So in Europe you made the decision that being a musician was not for you and applied to grad school. Did you go to grad school right after that?

AA: Yes. I applied to all the well-known computer science graduate programs, and I was rejected from all but one. I was very fortunate that Cornell decided to take a chance on a trombone player!

MZ: So you went to grad school. Did you have an idea what research problems you were going to work on?

AA: No, I didn't. I didn't know what research was all about. The focus of my undergraduate education was on learning to program, and there wasn't a lot of theory or exposure to research. Once I got to Cornell I realized that I had no idea what I was getting into. I didn't have a lot of the background, especially the math background, that was expected; I remember lectures where I understood nothing of what was being said. So in the first year there was a lot of catching up to do. I decided to take some undergraduate CS classes to fill in blank spots in my knowledge, and I benefited a lot from some of Cornell's fabulous teachers. By the second year I was starting to get the hang of it.

MZ: I see how you had to work hard to learn many new things in that first year. Did you develop an interest in programming languages research at that time?

AA: I did. I gravitated to programming language research naturally, I guess because I was so interested in programming. I became interested in programming tools and how they can make programming better.

MZ: So there you were, on a very different path.

AA: Yes. Graduate school changed my life both professionally and personally. I met my wife, I think on my first day at Cornell; she had an undergraduate degree in trumpet performance and we met in the practice rooms in the music building. She was also in the CS PHD program one year ahead of me. Long story short, I graduated from Cornell, married Jennifer and we moved to California to work at IBM's Almaden Research Lab. We stayed there for five years and then moved to universities. I was at UC Berkeley for 10 years and then moved to Stanford where I've been ever since.

MZ: So you joined IBM research after graduating from Cornell. This was in the late eighties?

AA: Yes, 1988.

MZ: I know IBM research had some of the greatest computer scientists working there. How was your experience there?

AA: I was hired into the functional programming group, led by John Backus. My dissertation work had been in instruction scheduling and I didn't know anything about functional programming, but I was very impressed by the people and they thought I would fit in. We were part of the theory group, which had a lot of amazing researchers. We were the oddballs in a group of CS theory people, but the lab had to put us somewhere and that was the easiest place to stick us in the organization. I really enjoyed working at IBM. The people were extremely good and very enthusiastic about all the research that was going on in the place. I don't think that kind of research lab exists today, at least not at the scale of IBM's research organization in the late 1980's. The culture was that you could either do something that was important for the company, or you could do something that was important for science, and if you were working on science it didn't need to align with the company's goals. It's hard to find a research organization today where the company's business interests aren't at least part of defining the research boundaries. It was even more ivory tower in some ways than a university.

MZ: That's almost like a CS department in a university. But you eventually left?

AA: In 1992 or 1993 IBM got into financial trouble and that triggered a transition in the mission of the research organization, which became more aligned with the needs of the business. My wife and I didn't see a good place for ourselves in that, and we decided that universities would be a better fit. We started interviewing, and she moved to Stanford and I moved to Berkeley.

MZ: After you joined Berkeley, did you see something that was very revealing to you, compared to working in an industry research lab?

AA: I learned a lot of new things when I moved to Berkeley. The faculty job is much more about working with students, much more about the selection of projects that students will help work out; because a typical project may involve several students and take a number of years, you've got to pick those reasonably well. And teaching is of course a very important and rewarding part of the job. I learned a lot from my colleagues at Berkeley about how to do all of that.

Throughout my time at IBM and at Berkeley I also saw many examples of the life cycle of research projects. Someone would tell me about a new idea, and I would think, "Oh, that'll never work. Forget that!" And then a year or two later, they would have an ongoing project where the work had become very sophisticated and I could finally see why they were right - there was something there! I think by observing many successful projects and some unsuccessful projects, as well how the ideas developed along the way, I learned what is likely to work and what is unlikely to work in research. So that was a great education.

MZ: You mentioned your wife joined Stanford after leaving IBM Research and you later also transitioned from Berkley to Stanford. So you were closer to your family.

AA: Exactly. The desire to consolidate the family in one place is what caused me to move. Life was fine when it was just me and my wife and we were living in between the two places and both commuted during the day. But once we had school-age kids, the logistics of having children going to school in a town fairly far from where either parent worked were daunting. We ended up moving to the Stanford area so that our kids could go to school close to where my wife was working. But then my commute became longer and I didn't want to spend time in metal boxes that I could be spending with my family. So we decided that we would both apply to a number of schools (including each other's) and see if we could be in the same place. We were fortunate enough to both end up at Stanford. I really enjoyed being able to see my wife during the day when we were in grad school and at IBM, and after a decade where we worked in different places it was very nice to be in the same building again.

MZ: I'm glad you had more family time together.

AA: The family time was always a priority for us. Spending time together was always the number one thing.

MZ: You had two kids, right?

AA: Right. They're both graduated from college now. The younger one just graduated this year. They were both computer science majors. My son is working in the industry. My daughter will be starting graduate school in the fall. Their other interests are travel and outdoor activities, which were always our family's interests.

MZ: It is awesome to travel with family. What is the most memorable trip you have been on?

AA: In 2007-8 we took leaves from our jobs and traveled for a year with our kids. We backpacked through Southern Europe and Morocco, we rented a camper and drove around the Andes in Chile and Argentina, and we rented a sailboat in Thailand and sailed in the Andaman Sea and up to Burma. We finished with a long distance walk on the John Muir Trail in California. We've done many other trips, but that was certainly the longest one, and one where we got to some unusual and remote places.

MZ: In math and physics, they have some grand open questions. What do you think is the biggest open problem in the PL community?

AA: I'll give you three. I think everything in programming languages and software revolves around correctness, performance, and the productivity of programming. Much of the research we do, I believe, addresses one or more of those three topics.

The verification of software is a huge open problem. It's so gigantic that I think we sometimes lose sight of how much of a real problem it is in the world. For example, the current issues around computer security impact people's lives every day, at all scales from individuals to nations. Now, computer security involves many issues beyond software security, but clearly software security is a major component, and the crux of software security is establishing that software has certain properties - i.e., verification. We already understand the fundamentals of how to do verification, but clearly there is a long way to go to reach the scale of adoption that is needed, and figuring out how to accelerate that process by making verification easier and more economical to use is still a big challenge. I believe it will happen. It's a long process but you can see the progress, and you can see the momentum building. So that's one.

Next is performance. Performance was regarded as something of a dead topic for many years. In the 1990s there was a period when CMOS technology was advancing so rapidly and so predictably that there was no incentive to work on software-based performance improvements. Any new programming model or optimization tool took years to mature, and meanwhile the hardware would race ahead, carrying the already mature tools with it, usually to the point that new software technology simply couldn't keep up. Now hardware improvements have come to a stop; the underlying hardware technology is not getting any faster. So, quite suddenly, software-based performance improvements, meaning languages, compilers and optimizations of various kinds, have become very important, and in fact are essential to future performance gains. A good example is the current activity in improving the performance of deep learning systems, which is grounded in parallel programming and program transformations. More generally, looking at the difficulty people have developing high performance systems and considering that they usually don't end up with a system that achieves something close to the maximum performance possible, my conclusion is that a lot more work will be needed to make future high performance systems programmable at reasonable cost.

Then the third grand challenge is programmer productivity. Programming is very expensive today, and as programming spreads to more and more walks of life, we'll need to find ways to make programming more productive. I think there is a good analogy with the history of writing and arithmetic. In the Middle Ages there were professional scribes who wrote and read documents for the vast majority of people who were illiterate. As European societies grew and became more complex, scribes became a communication bottleneck and there was a transition where eventually pretty much everyone learned to read and write at least a little bit. Most of them didn't read and write nearly as well as professional scribes, but there was a lot of benefit to society in not requiring most communication to go through a small number of expensive people. More recently societies reached a point where many or even most professions required at least a basic knowledge of arithmetic and so it became worthwhile for everyone to learn some math. Arguably the same thing is happening now with programming; many professions already benefit from at least a little knowledge of programming, and there clearly aren't enough programming professionals to go around. But how are we going to make programming easy enough and productive enough so that very large numbers of people can reliably do simple programming tasks for themselves? It's another big challenge.

MZ: Those are indeed big open questions, and it is very inspiring to relate history to the present. Do you have favorite results/ideas from the last decades of research?

AA: If I listed all the ideas that I really liked my answer would be too long. But I can tell you what sort of results interest me the most. It's been said that in every research topic there is a special place for the first, the best, and the last. While there are examples of all three that I appreciate, I find I'm most often drawn to work in "the first" category, papers that introduce something new and unexpected (or at least unexpected by me). I find I frequently learn new techniques and perspectives from such papers, and even if it takes years those ideas eventually find application in my own work.