People of Language Design and Implementation

An interview project in conjunction with PLDI 2019  

Isil Dillig

Interview with Isil Dillig

Isil Dillig is an associate professor at the computer science department of the University of Texas at Austin where she leads the UToPiA research group. Her research interests are program analysis and verification, program synthesis, and automated logical reasoning.

 

MZ: Can you tell us about yourself?

ID: I'm originally from Istanbul, Turkey, and I grew up there until I finished high school. I'm the only child in my family, and both of my parents are academics. I went to an American high school in Istanbul, and then I moved to the US to attend college at Stanford. To be honest, when I was a freshman, I didn't really have much of an idea about what I wanted to major in. So, I did a lot of exploring. I considered majoring in various things like math and chemical engineering and physics, and it took me a while to finally decide that I wanted to do CS.

MZ: How did you figure out your interests in computer science?

ID: When I was in high school, I hadn't taken a computer science class , so I didn't really have much of an idea as to what being a computer scientist really entailed. Fortunately, Stanford had this culture where you were encouraged to explore a bit before declaring a major, so I ended up taking classes from a bunch of different departments, including some introductory computer science classes. I really liked that CS had a good mix of math and coding, so I eventually I decided that computer science is the right path for me.

MZ: How did you get started in research?

ID: As an undergrad, I ended up doing research with Alex Aiken who later became my PHD advisor. In particular, I spent the summer of my junior year doing research in program analysis, and I really liked both the research area and the process of doing research. After that experience, I decided to pursue a PHD in programing languages. During my senior year, I wasn't taking a lot of classes and I was doing a senior Honors Thesis, so I was able to focus on doing research before I even started grad school.

MZ: Was grad school right after that?

ID: Yes. Since I ended up doing my PHD in the same place where I did my undergrad and with the same advisor, it was a pretty seamless transition.

MZ: Aside from computer science and programming languages research, do you have other hobbies?

ID: Yeah, I do. I generally like being outdoors and traveling. I like to hike a lot. I also like scuba diving and photography.

MZ: How long have you been into photography?

ID: I've been into photography since high school. Back when I was in high school, I took a photography class, and I used to like working in the dark room. Then once digital SLRs became available, I switched to digital photography and I've been enjoying that ever since.

MZ: What kind of photography do you like and why?

ID: I like landscape photography because I like capturing all the cool places I see while hiking and traveling. I travel to places like Patagonia, the Rockies, the Sierras, and various national parks to combine my passion for the outdoors and photography. I also post some of my pictures on Flickr.

MZ: That is pretty cool! Please share the link and I will check it out.

ID: https://www.flickr.com/photos/isildillig/albums

MZ: Now let's also talk a bit about technical stuff. Given that you have been working in the area for a while, has your research philosophy changed over time?

ID: To some extent, yes. Looking back at my earlier career, I picked some research problems by looking for nails that fit whatever hammer I was interested in. These days, my research philosophy is the other way around. I really like to start with the problem and then I'm pretty confident that we're going to find the right hammer as we go along. In other words, I'd say I'm much more problem-driven than technique-driven compared to when I started as a researcher. Perhaps one consequence of this is that my research got more interdisciplinary over time because I now get a lot of inspiration from problems in security, databases, and even machine learning.

MZ: How do you get inspiration for problems and research ideas?

ID: Generally speaking, there are two ways I get inspiration for problems. One inspiration is the obstacles that I and my students encounter while working on a previous project. That is, sometimes we're working on one thing and we solve part of the problem, but there are orthogonal problems that we don't get to solve during that project or maybe the solution isn't as general as we want. For instance, for some of our program synthesis work, we started out solving one specific kind of synthesis problem, such as data wrangling or imputation, and then we said, "Well, how can we generalize this technique? Can we come up with a more general framework that can work across different application domains?", and that led to a bunch of synthesis projects I've been working on in the past few years. Another way I get inspiration for research ideas is learning about people's pain points during software development Whenever I hear or read about difficulties and pitfalls people encounter while I programming, I ask myself "What can I do as a programming language researcher to address this?" In my experience, this has also been a good way to find new research problems to work on.

MZ: You mentioned that you got inspiration from security, databases, and machine learning. I also have noticed that you have a PLDI paper on verifying neural networks.

ID: Yeah. We have a paper on verifying robustness of neural networks. So, roughly, in this context, robustness means that the network's classification doesn't change when you make small perturbations to an input. In our recent PLDI paper, we propose a new verification algorithm for proving robustness. The interesting thing about this paper is that it uses a combination of abstract interpretation and machine learning to solve the problem. In particular, we use abstract interpretation to try to verify the property, and we also look for counterexamples using a machine learning technique known as projected gradient descent. On top of that, we use another machine learning technique called Bayesian optimization to figure out how to do abstraction refinement. In this way, our solution comes full circle from ML to PL to ML...

MZ: It is interesting that it is both PL for ML and ML for PL. It seems like this interdisciplinary interaction between ML and PL is creating a strong current. What's your thoughts on how programming language research can have bigger impact in these other domains?

ID: Yeah, I do think that there are many interesting problems in this space. I already talked about one of them, but another thing that interests me in this space is PL techniques to simplify data science and big data analytics. In this context, the ultimate goal is to gain insights from data using machine learning but, it turns out that in practice, most people spend 80% of their time doing what's considered to be the janitor work of data science, which involves cleaning, wrangling, and imputing the data. A lot of recent work in my group uses program synthesis to automate these tedious aspects of data science and analytics, and I do think that PL has generally a lot to contribute in this space.

MZ: That's interesting. Automating some of these tasks can make a lot of data scientists' life easier.

ID: Yeah, I agree. To quantify how useful automation is in this context, we actually did a little user study for a PLDI paper from two years ago. In this study, we collected a few data wrangling tasks and asked professional data scientists to perform these tasks within an hour using all the available data wrangling libraries in R. Interestingly, most of the participants were not able to solve these tasks within one hour, but our synthesizer completed them in just a few minutes!

MZ: I'm sure the participants were pretty impressed. Overall, what's your suggestion to make a PL-ish contribution?

ID: In my opinion, there are two different ways to make a PL-ish contribution. First, you can make a PL contribution by making it easier for people to write correct code, either through language design or program synthesis or program verification and so on. Another way to make a PL-ish contribution, in my opinion, is to apply ideas from PL to solve problems in a different field. So, if your solution has either of those traits, then I consider that to be a contribution to programming languages.

MZ: Do you think there are grand open questions in the PL community, like those in math and physics?

ID: I think programming languages and computer science are a bit different from fields like math and physics, because, in PL, our goal generally is to make it easy for people to write correct code and develop reliable software. Generally speaking, the field of computing is continuously evolving, so I think that problems that are important also keep evolving. There are some underlying fundamental ideas that we keep using and that we're going to keep improving, but I also think that the problems that are very useful and relevant do tend to change over time, perhaps unlike in math or physics.

MZ: Do you have some all-time favorite ideas in the PL area?

ID: Yeah, definitely. I come more from the formal method side of programming languages, so one of my favorite ideas in that space is counter-example guided abstraction refinement. Personally, I find this idea really appealing in two different ways. First of all, it provides a unified and clean framework for both verification and falsification. In other words, it allows us to synergistically combine the search for proofs with searching for bugs, and I find that very appealing. Second, based on all my previous experiences, I've come to be a big believer that there isn't one universal program abstraction that works everywhere. So, I also find it very appealing that this framework allows us to automatically find good abstractions that are tailored to a specific problem and to the property that we want to prove.