With this year’s PLDI just around the corner, it’s a great time to get to know a few people in the programming languages research community, especially since we won’t be meeting each other in person this year. People of PL is a series of three interviews conducted to mark PLDI 2020, and continues in the same vein as the People of POPL and the People of Language Design and Implementation interviews that were done by Jean Yang, Brandon Lucia, and Minjia Zhang.

In this edition, John Wickerson meets Mike Hicks, who is a professor in the Computer Science Department at the University of Maryland.

J: Tell me about the journey you took to get to your current position.

M: I went to Penn State University as an undergrad, and graduated in 1993. I thought I was just going to get a job, but one of my professors took me aside and said that I should consider grad school, which I really hadn’t done. I decided to go get a job after all, but I kept thinking about the possibility of grad school…

J: What was that job?

M: I worked for a company called ARINC that built telecommunication systems for airlines. We worked with lots of low-level, embedded systems that didn’t have memory management units. There were lots and lots of bugs. I ended up building a bunch of software tools to try to diagnose failures. That led me to wondering about ways I could do this more generally, so that I wasn’t reinventing the wheel every time.

So when I did eventually go back to grad school, that was the thing I was interested in. The first thing I studied was garbage collection. The idea that memory management could be done automatically was amazing to me, because when I was working in industry, that’s where most of the errors were coming from.

J: Did your time spent working in industry have a big impact on how you’ve approached your academic career?

M: It certainly did. I didn’t start as a Computer Science major – I switched into it from a different kind of engineering, because I found that I really loved programming. Then while I was in industry, I felt frustrated by programming, because of these failures. So I was motivated to learn how to program better, and I would say that’s sort of been my goal ever since, for the last 25 years.

I remember when I’d just started as an Assistant Professor at Maryland, a student came up to me after a lecture and asked if I had worked at that company. I said yes, and he said, “Well I was an intern there over the summer and I was using your code!”

J: Cool!

M: I was deathly afraid – I thought he was going to say that I had written terrible code, and what was I doing being a professor, or something like that! But actually he told me that he had been using the debugging tools that I written to diagnose memory failures. The company was still using these tools seven years after I wrote them! And that gave me even more motivation for building better tools and designing better programming languages.

J: What’s your current research problem, and how did you come to it?

M: Let’s see. I have several projects, most of which involve trying to find ways to build better, more secure software. One project is with David Tarditi from Microsoft Research on a language extension called Checked C. The thing that I like about Checked C is that it’s sort of an admission that people who have huge amounts of legacy code are unlikely to do a wholesale switch from C to something that’s safe. Rewriting something in Rust or Haskell is just too much to ask. And the automated approaches to adding safety, like AddressSanitizer or other research tools like SoftBound, add a lot of overhead, so people don’t use those either. Yet buffer overruns are still the biggest cause of bugs today. It’s very disheartening, in some sense. So what Checked C aims to do is to incrementally make your legacy codebase better. It’s a dialect of C, where if you annotate everything you’ll have a spatial safety guarantee, but you don’t have to annotate everything.

J: I see. You’re aiming for “little bit of effort, little bit of pay-off”, in contrast to traditional, full-on verification where you have to put in a huge amount of effort before you see any pay-off at all.

M: But how to evaluate that, how to show that quantitative pay-off? I’m not sure we know how to do that exactly. We did have a paper that formalised an idea of “blame” for Checked C, so that you know that if something goes wrong in your Checked C program, you can blame the unchecked code. So it’s, sort of, relatively sound. Ultimately, we’d like to fully formalise the Checked C system, and we have aspirations to extend the CompCert compiler with Checked C annotations too.

Actually, I am the technical director at a startup company related to Checked C. It’s called Correct Computation, and part of its mission is to improve the Checked C ecosystem. We’ll see how that works out.

J: Is this your first startup experience?

M: Yes.

J: How are you finding it?

M: It’s different. You’re trying to do something useful, not just something you can publish. I hope that we’ll work with Microsoft as they deploy Checked C in their services. There’s interest in doing this sort of thing at Amazon as well, so that you can have safety assurances on IoT devices connected to their cloud. Checked C is an easier ask than, say, asking people to rewrite stuff in Rust.

J: You mentioned that you had several research projects going on?

M: Yes, the other side of my research is on programming languages and verification for quantum computing. To that end, we have built an optimiser for quantum circuits – circuits that are built from quantum gates. Our optimiser can reduce the number of gates or the number of qubits that you need for your program. Also, quantum programs, like any program, might have bugs, but it’s particularly bad in the quantum case because quantum circuits have noise anyway. When you get a wrong answer, it’s hard to tell if that’s because of noise or because of a bug.

J: So you want a verified quantum compiler?

M: I want a CompCert for quantum programs, yes. It’s very exciting, and I think this is a place where there’s increasing interest. We just had a workshop called PLanQC, which was very popular – we had 85 participants. I think the time is now for folks to get involved, and there’s a lot we can do.

J: What’s your favourite part of your job?

M: My favourite part of my job is that it’s not one thing. If I was just writing code, or just doing research, it would not be as satisfying as also teaching. I feel like I learn so much by teaching, and I get such a rush from seeing students get excited about what I’m talking about. But on the flip side, if I was only teaching, I think I would get bored quickly – I’d want to learn new things. I think teaching and research mutually reinforce each other.

J: Yes, I feel the same.

M: The thing I don’t like about my job…

J: Aha, you anticipated my next question!

M: …is administrative, political stuff. I mean, I appreciate that service is important, and I want to contribute and participate, but it does wear me down. I like doing it to some extent, but sometimes I’m bad at saying “no”, and I just feel overwhelmed by it.

J: If you were not a computer scientist, what would you be?

M: That’s a great question! I think I would want to be doing something where I’m learning a lot, and where I get to be creative. The thing I thought I wanted to be, before I became a computer scientist, was an artist. When I was in high school I used to draw comic books. I lived in San Diego, and I used to go to the San Diego Comic-Con.

J: I’ve heard of that one!

M: And then when I got to college, I started playing music. I played drums in a band for a long time. I feel like all these things are related – whether you’re making music, or programming, or writing a beautiful paper – there’s a very creative process there. That creativity is really important and valuable to me.

J: The comic stuff sounds fascinating. I’m picturing superhero-type comics, is that the sort of thing you made?

M: Yeah, I was interested in the dark, noir style of comics, made by artists like Frank Miller, which are actually similar to a lot of the superhero movies you see nowadays. The dark, foreboding Batman, or Daredevil beating up people on the streets with all the shadows and everything. Not just the knock-em-out, Adam West kind of format.

J: Cool. Do you ever find a way to integrate comics into your academic work? Perhaps not in the paper itself, but you could put some comics into your slides, right?

M: That’s a really interesting idea. My youngest son, who’s 15, is actually an artist and he likes to draw comic books. So I’m getting more familiar with the genre again because of him. So, who knows, maybe I should think about doing that.

J: I remember Erik Meijer from Facebook had some beautiful hand-drawn slides in his keynote at PLDI 2018. His talk was really memorable because of that.

M: Yeah you’re right. It would take a lot of time, of course, but you’ve planted a good seed, and I’ll keep it in mind.

J: Nice. And you said your music was drumming? Any other instruments?

M: I played the guitar a little bit also, but drums were the focus. It’s been great to be here at POPL 2020 in New Orleans because I really like jazz music, and I’ve seen a few acts this week. That said, I don’t play music nowadays as much as I might like to. The thing I actually do a lot is Ultimate Frisbee. I think exercise is important for clearing your head so you can solve problems.

J: A good Frisbee to the head can really clear things up.

M: Right!

J: Now, you’ve been attending SIGPLAN conferences for quite a while?

M: The first academic conference I ever went to was PLDI 1996, which was in Philadelphia. I was a student volunteer, and it was incredibly exciting to be there.

J: And how has the field changed since then, would you say?

M: I’d say that the biggest thing is scale – these conferences are all much bigger than they used to be. That changes the flavour of the conference because it’s far less likely that you can meet up with everybody working in your area. And you can’t attend all the talks you might want to, because they’re double-tracked. But on the flip side, there’s a huge amount of variety and excitement – all the workshops, the mentoring sessions, the live-streaming and recorded talks. I think they’re all improvements.

I do wonder whether we’re getting as much out of conferences as we think we are. We continue to tie our publication process to the conference system. All of the top papers for people’s tenure cases are published at conferences, which means that people have to keep going to events like these. And I do wonder, especially now that we’re thinking more about our carbon footprint, what is the cost/benefit of that? I don’t know the answer. There are many good things in my career that have happened as a direct result of me physically being at a big conference like PLDI. Could they have happened some other way that is less expensive? It seems like the coronavirus is giving us a chance to explore that question, as many conferences are going to go virtual.

J: What was your first programming language?

M: BASIC. I learned how to program on an Apple II computer when I was in elementary school. Then my family got one too, and I learned to program games and things on it while I was in middle school and high school.

J: What sort of games?

M: I did text-based adventure games, like Zork, which was popular at the time. In trying to program those kinds of games, I learned about basic data structures, and about not allocating your line numbers consecutively…

J: You mean you have to space them ten or so apart so you can later add extra lines between them?

M: That’s right. Though you can still run out of line numbers. A funny thing with the Apple II was that the memory for the display was just above the memory used for your program. So if your program got too big, it would corrupt the screen. You could buy utilities that would wrap your program around to the memory that was above the screen. Which made me wonder: why did they lay out the memory that way in the first place?

Anyway, BASIC was my first language, then in college I learned FORTRAN, Pascal, and C. At grad school I learnt Standard ML, and I remember a moment of real joy when I learnt about Church numerals.

J: Ah yes, it’s a joy to show somebody Church numerals for the first time.

M: That was when I really fell in love with functional programming. I still like C programming, but functional programming is my favourite. When I write code these days, I often turn to OCaml.

J: And how much programming do you do in a typical week?

M: I don’t do as much as I would like. I program sporadically. I’ll do some programming while I’m designing student assignments, for instance. I usually don’t write code during a research project, though, because then I may become a bottleneck or potential point of failure. That said, I do find myself regularly writing code for Checked C, and doing it in C++ no less!

J: Thank you very much, Mike!

M: Thank you, that was fun.

Disclaimer: These posts are written by individual contributors to share their thoughts on the SIGPLAN blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGPLAN or its parent organization, ACM.