Microsoft Research Podcast - 032 (rerun) - How Programming Languages Quietly Run the World with Dr. Ben Zorn

Episode Date: July 11, 2018

This episode first aired in January (2018).In an era of AI breakthroughs and other exciting advances in computer science, Dr. Ben Zorn would like to remind us that behind every great technical revolution is… a programming language. As a Principal Researcher and the Co-director of RiSE – or Research in Software Engineering – group at Microsoft Research, Dr. Zorn has dedicated his life to making sure the software that now touches nearly everything in our lives is easy, accurate, reliable and secure. Today, Dr. Zorn tells us some great stories about bugs and whales, warns us against the dumb side of “smart” objects, shares about his group’s attempt to scale the Everest of software security, and makes a great case that the most important programming language in the world today is… the spreadsheet.

My interview with Ben Zorn was the sixth episode of this podcast, and one of the most animated. We talked about bugs and whales and mountains and forks, but mostly how all paths in computer science innovation lead back to programming languages. So I've nicknamed the podcast Six Degrees of Ben Zorn. Whether you're already connected to Ben or you're meeting him for the first time, I know you'll enjoy episode six of the Microsoft Research Podcast, How Programming Languages Quietly Run the World. How do we know where the diseases are in the world? Okay, so you have a Zika outbreak, right? The question is, how do scientists know that that might happen? How would they predict?

Can we do weather forecasting and that kind of forecasting, but for diseases instead of weather? The hard part is that technically, how do you solve that problem? He drilled that big important question down to this very simple question is, can we use a mosquito as a sensor? You're listening to the Microsoft Research Podcast, a show that brings you closer to the cutting edge of technology research and the scientists behind it. I'm your host, Gretchen Huizenga. In an era of AI breakthroughs and other exciting advances in computer science, Dr. Ben Zorn would like to remind us that behind every great technical revolution is a programming language.

As a principal researcher and the co-director of the RISE, or Research and Software Engineering Group at Microsoft Research, Dr. Zorn has dedicated his life to making sure the software that now touches nearly everything in our lives is easy, accurate, reliable, and secure. Today, Dr. Zorn tells us some great stories about bugs and whales, warns us against

the dumb side of smart objects, talks about his group's attempt to scale the Everest of software security, and makes a solid case that the most important programming language in the world today is the spreadsheet. That and much more on this episode of the Microsoft Research Podcast. So let's actually start by setting up the framework for what we're going to talk about today. What exactly do the London whale and a better mosquito trap have in common? So they seem very different. But in the end, I think if you think about the world that we're in now, software plays a key role in our lives and everything we do. And so the thing that connects these is that they're fundamental challenges, big problems. But at the core of solving those problems is the ability to use software to actually attack the

problem and make it better. I work in the field of programming languages, and we really think every day, we go to work thinking, what do we do to make software better? If we make software better, then we can make all the things that depend on software better. Yeah, so what about the London Whale? What was that situation? One of the things that's important to understand is much of the finance world runs on spreadsheets.

And spreadsheets capture a lot of interesting information, information from banks, information from stocks. The London Whale was one of these traders at J.P. Morgan, and he had a spreadsheet, and he was looking at how much volatility there was in a particular stock. And the reason they called him the London Whale was because he would make enormous purchases, a billion dollars. The Whale. Yeah, yeah, the Whale. So he did this. And unfortunately, in the spreadsheet he used, there was a bug. And so he thought the volatility of a particular stock was much lower than it really was. And so he bought it thinking, okay, it's going to stay

stable. When in fact, it swung and it went way down, and he lost literally billions of dollars. And so this was a human making a decision, but the decision was basically based on a spreadsheet. And that's a fundamental, again, we're back to software. That's the fundamental thing that links these together is the bug in the software made him lose all this money and then all the consequences. I mean, the company lost $900 billion in a lawsuit, essentially, because of that. Right. So what about mosquitoes? Okay, yeah. So let me talk about that. I think one of the things I really, really enjoy about working at Microsoft is the ability for people to have a vision and attack that vision with their

heart and soul. And I had an incredible researcher working with me. His name is Ethan Jackson. And he wanted to solve an important problem. And it wasn't a problem about money or et cetera. It was really a much more fundamental problem, which is how do we know where the diseases are in the world? Okay, so you have a Zika outbreak, right? The question is, how do scientists know that that might happen? How would they predict? And so in his mind, it's like, can we do weather forecasting and that kind of forecasting, but for diseases instead of weather? The hard part is that technically, how do you solve that problem? He drilled that big, important question down to this very simple question is, can we use a mosquito as a sensor?

So can you take a mosquito and look at what it's eaten in its meal? That blood contains viruses, and the viruses will tell you what diseases are present in the current environment. That took him on this incredible journey where he met with disease experts, he met with insect biologists, mosquito experts. He worked with field biologists to understand what their process was. How do they go now and find out where the mosquitoes are? What kinds of things are happening with mosquitoes? But the thing that he connected, you can think of this as connecting the dots. He connected mosquitoes to the cloud. So in particular, it's not just that you catch a mosquito. It's also that you have to figure out what its DNA in the blood that it ate was.

And that requires you to do gene sequencing, and it requires you to do it at scale. And so he built a trap. The project is called Premonition. The device that they created was a very, very specialized mosquito trap. And the idea is that when you catch things in the trap, you catch these very pristine mosquitoes, and then you sequence their DNA, and you send that to the cloud. And in the cloud, you decide, what did this mosquito eat? Does it have Zika? Did the animal that it bit have Ebola? And with those answers, you can then say, well, in this region, we caught a mosquito that had Zika, or we caught a mosquito that had Ebola. And in the

process of sort of asking this question and finding answers, he had to explore all kinds of interesting problems. In fact, he revolutionized the ability of field biologists to collect data about mosquitoes. This new trap, it tells you things like when this mosquito was caught. So now they can understand over the period of a day when certain types of species of mosquitoes come out. He knows the temperature. He knows the sort of environmental conditions around the behavior of the mosquitoes, which they never measured. Another thing he did, basically the mosquito trap leverages machine learning. So the trap itself is about five pounds. It has 64 individual cells. Each one has a door. Okay. And if a mosquito flies in, the trap can decide whether or not to close the door.

So it can say, if that's a house fly, I'm not interested. Don't close the door. But if a mosquito flies in, he can then figure out using machine learning that insect was the type of mosquito he wanted and he can catch it. This is like so amazing. It's too bad it's a podcast because no one can see my face right now. Well, and let me just say, this is not just some person in a lab having cool ideas. One of the things about this project is it's an incredible collaboration across Microsoft Research. So he worked with people in the hardware group. He worked with people doing gene sequencing. Actually, there's people in Microsoft Research that, you know, that have expertise in doing it fast, right, which you absolutely need to do. So this was a collaboration within the lab, but it was also externally, because we don't have people that are insect specialists or virology specialists. What was his specialty? So the amazing thing, his specialty is actually programming language formal methods. Oh my gosh. Awesome.

So he had this vision, he built this thing, he executed on it. It was an end-to-end solution, and it showed that you can aspire to these kind of high-impact capabilities. And we have this kind of environment here to really support that. I'm still thinking about how they could tell what the mosquito had for lunch. Because, I mean, it used to be just, you could spill mustard on your tie, you could tell what you had for lunch. But Chet, you ate a hot dog. When people get excited about going into computer science today, but they think maybe this will be my career, they're often attracted by the kind of buzzy, hot things like machine learning, deep learning, AI, whatever. What role does programming

languages play in that? And why would somebody think, hey, I'm going to go into research? Because your organization is called RISE, Research in Software Engineering. So, yeah, so that's a great question. And it is true that in the end, what we do is we build the things on which people build incredible solutions. So we work on software. We work on making it easier to build software, making it easier to make the software correct, make it perform well. But I think too, the way to think about it is almost all the big technological revolutions have had with them accompanied a programming language. So if you go back to the late 70s, you know, the advent of PCs, one of the things that really sold in the PC market was

spreadsheets. And it transformed the financial industry as we talked about. But those spreadsheets. And it transformed the financial industry, as we talked about. But those spreadsheets really redefined how business people thought about their business, how they thought about the future, how they planned and did the trends. And so I think at the core of programming languages, this ability to capture something that people want to do. So for example, C++ was fundamental in the growth of object-oriented programming. It was a way to make it so that everyone that wanted to do object-oriented programming could go to C++ was fundamental in the growth of object-oriented programming. It was a way to make it so that everyone that wanted to do object-oriented programming could go to C++. There were mechanisms in there. There were sort of frameworks that were built on top. And they could start getting their job done.

And the same thing with Java. If you want to do something on the web, you know, Java was the language. One of the reasons you know that these things are successful is because lots and lots of people start programming in them right away. Because it opens up a new frontier for new developers, for new business opportunities. And even lay people, I mean, WordPress things, you can go into the HTML and... That's right. Yes, absolutely. Markdown, the ability to combine the presentation. And again, with computation, you can embed JavaScript into web pages. Yeah, JavaScript, again, a transformative technology really enabled the whole Web 2.0, you know, the sort of the ability to do apps embedded in browsers.

And the other one, you know, this is one that doesn't, I think, get nearly enough credit. Visual Basic transformed the PC industry in the sense that it made it, again, easy for people who didn't have the deep programming skills to put together applications in verticals and sell them and make a lot of money, you know, because there was a need for those things. And the tooling that sort of the language and the programming environment made it easier for people to do that. That's so interesting. Let's talk about the spreadsheet again, because this is one of your things that I think is super interesting. And it kind of goes with the question I asked you about in an era of AI infatuation. The spreadsheet is decidedly kind of unsexy. Why is it important to program? Wait a minute, he says. Programming languages that have impact. And I have to say, there are hundreds of millions of

spreadsheet users. So by numbers, a spreadsheet is actually the most important programming language in the world. And most people don't think of it as a programming language, but in the essence of spreadsheets, you're combining data and code because you're computing on that data and presentation because you want to see the result. You want to see the chart, you want to see the table, et cetera. So the spreadsheets are brilliant in that it's very concrete. It's not like there's this abstract program and then you feed it some data. With a spreadsheet, you have the data right there and you have the computing right there. So that's why it's so accessible. But in the end, it is a program. And as such, you have bugs, you know, which is one of the reasons that, say, the London Whale happened.

But I think it's important to understand that spreadsheets, because they're so successful, are really a mechanism for people who have questions about data. And more and more people want to answer questions about data. I mean, it's like if I have personal data about my health, I'd like to be able to ask questions. I don't want to have to go to somebody to write a program to answer my question. I'd like to ask that question myself. Well, put it in a spreadsheet. If you want to figure out, can I retire now, right? You put your it in a spreadsheet. If you want to figure out, can I retire now? Right? You know, you put your data into a spreadsheet. This brings up like a host of questions, not the least of which is the Internet of Things,

where you have all of these independently. I mean, so let's say Microsoft is doing software and they do tests and verify it. And, you know, I'm guessing that's not the CRA, which is an organization that represents computer science research to the federal government. The CCC is the part of the CRA that actually is tasked with thinking about the future, thinking about trends in computer science. And the part of the CCC that I've been most active with is called the Task Force on Intelligent Infrastructure. And it looks at this question of if we embed computing into infrastructure or into, say, the Internet of Things, how does that change the world? And how do we think about that world? And it goes to what I said I was talking about before about how every company now, to get an advantage, instead of saying, okay, we're going to make our toaster better, like mechanically, now it's like, how can we use software to make our toaster better? A smart toaster. A smart toaster.

And you think about, you know, for example, you know, there's your doorbell, there's Ring. It's a big company now and they sell you a smart doorbell. It'll show you video of who's at the door. You buy a Tesla. Well, Tesla has a ton of software. You're really buying software, right? Tesla sells you software upgrades and they sell that to you. So that's, you know, they basically converted selling a car into selling software, right? The Internet of Things is amazing, though, and it kind of goes crazy. So, for example, there's a smart fork. So if you look online, there's a smart fork, and it's like, wow.

But the fork has a processor in it, and it counts how many times you lift it. So you basically... Oh, I need this fork. So here's the thing. Smart objects, smart Internet of Things, they're relatively cheap. No one's going to pay $1,000 for a smart fork, right? They've got to get to market fast. Usually they're built on a software stack, which is open source. But the biggest problem is the level of scrutiny that people pay attention to with these things in terms of are they secure?

What levels of care are made in creating that software? Well, moreover, who's the fork talking to? Right. I mean, are they saying, hey, Ben's password is... Right. So here's the problem is that that fork, by definition, because it counts things, it probably talks to some server on the internet. And then I look at my wristband and say, oh, you've lifted that fork a hundred times. I mean, somebody's talking, right? Right. So these things by definition are connected because they wouldn't be smart if they were just by themselves. And you don't necessarily know what software is running on them. And you don't necessarily know if somebody's compromised that software. So for example, yeah, I don't really want to have to worry if my fork

is trying to steal my internet, my wireless password. Or letting people know you're not home. That's right. Yeah. Or it's my fork talking to the doorbell. I mean, we didn't used to have to think, is my fork trying to steal my password? But now we do. Because if you buy that smart fork, there's a possibility.

And we are in a transition with the Internet of Things where there's sort of two classes right now of quality and software. There's certified software like aircraft software, you know, on a plane. It is carefully checked, right? So you're pretty confident there. But then everything else, there's no checking, right? There's no level of certification. One of the things that I'm doing with the CCC is understanding what at the federal level, what are the right things for the federal government to be doing in this space? And in fact, they are actively working. One of the models they're looking at is using an underwriters lab kind of model. So that instead of saying underwriters lab says, you know, this electrical appliance won't short circuit and cause a fire, they're

basically saying, well, this device has reached some level of quality, which is better than just nothing. Does that include security though? Yeah. I mean, well, it goes to questions about best practices. And they're fundamental questions, like, how do you update? Like, let's say you have a device, and then it's got a bug. You know, we know about Windows Update. We know that, you know, we see PC updates frequently. But how many people update their fork, right? I have never updated my fork.

And so the question is, like, that's a problem because if there is a security vulnerability and you don't update it, then your fork is vulnerable forever. Can you get a fork patch? Exactly. And, in fact, this is not just hypothetical. One of the things that happened about a year ago was people had bought video cameras on the web, and it turned out that a hacker figured out that many of the passwords on these video cameras could be guessed. So it turns out they actually hacked about 100,000 or more of these cameras. Okay. So first of all, if you have a web camera and somebody's hacked into it, how would you even know? So that's the first problem, right? There's so much I don't know.

But the second problem is the person who hacked this leveraged all of these 100,000 or more machines to do a distributed denial of service attack. What that means is they had these cameras all send packets to a particular website to make it so that no one else could access it. And with 100,000 things, you can really shut things down. And this was a problem last year. One of the things that happens with the Internet of Things, with this emerging presence of lots of devices without security, you know, or with less understanding about how the security works, is that you can have these emerging attacks based on large numbers of devices. The scenarios you've painted are common in that people click agree on an app for convenience, right? Sure.

They don't even know what they're... Right. Yeah. So there's two kinds of problems. One is a problem where there's a bug in the software and somebody exploits that bug. It's doing things that was never intended. There's another problem, which is the software itself, say an app on a phone, has privileges that it doesn't really need. When it says, here's 10 things I'm going to do, if you want to use me, how do you know what things it really needs? Not only that, it's a binary option. I either say yes or no. Could I do five of those?

Right. So I think the good news here is that there is an evolving understanding of how to enable, like, for example, one of the strategies is you say, look, I'm not going to say that you can do it. When you need it, you ask me. Like when I'm about to use something and it says, I need to use your camera right now. Then you say yes, because you're taking you know, you're taking a picture. You understand.

Which I've done. Yeah. Can I access your photos? Okay. Because I want to edit that photo. Exactly. So I think there is hope there in the sense that the understanding of how people interact with software, how you can make software more understandable, you know, is evolving.

One of the things that you could say is it's a success story in the sense that people are using these things for so many different activities, you know, so many apps on the phone, so many apps on the computer. The fact that people want to use software for all these purposes and that we have to understand what that means and how to control that more. So if I get a smart fork and I decide I want to upgrade it and they say, we don't support that anymore, are we just... Well, no, this is a real concern. And I would basically say to upgrade it. And they say, we don't support that anymore. Are we just? Well, no, this is a real concern. And I would basically say, and in fact, you know, the FBI provided a public service announcement saying, look, if you have Internet of Things devices, then you should put it on a separate network. So this is one of the things they're telling people. It's like, have in your home now, have your network, which is like your computers and all your stuff that you're using that you really need, and then everything else put on a separate network. But who can do that? I mean, I don't even... No, this is, I understand, and it is a concern. You people are

technopolists in a good way, I'm hoping. But I think sort of, this is an analogy of the Wild West. Right now, we're just seeing what all the problems that can emerge. Over time, I think, you know, for example, wireless routers might actually have these two networks sort of automatically configured in such a way. In fact, even now, I think routers will give you guest networks, but you have to know to use them and you have to understand the configurations. Listen, you need to be Wyatt Earp in this wild west. So let me talk a little bit about a strategy we can go toward that. So there's a project in the group. It's called Everest.

Which group? In my group, Rise. And what they're trying to do is think about not just writing software, but writing software so that it's fully verified. So what does that mean? Actually, fully is too strong a word, but verified for important properties. And so what does that mean? So in particular, what they've taken on is there's a communication infrastructure that connects a web browser and a server. It's called HTTPS.

You might have seen it. It's sort of. Yeah, I think it's secure when I go there. Right. You get a little lock that says, you know, the communication between your client and the server is encrypted, secure. You know, you can send your bank account numbers or your credit card numbers, and no one who's listening in can understand that. So that HTTPS is actually a lot of software. There's an implementation of it in the open source called OpenSSL, and it's used widely.

In fact, a couple of years ago, there was a major problem with OpenSSL called Heartbleed, which made the news because it turned out that people could look in on your computers through this Heartbleed bug. And this was a problem with OpenSSL. Was it a bug or a hack? It was a bug in the software that then people figured out how to exploit. And it was unclear how widely exploited it was because it's very hard to tell if people had been using it. Anyway, so OpenSSL is an implementation.

And what the Everest team said was, look, we're going to build an equivalent version of OpenSSL, but we're going to make our version verified for the important properties, like the cryptographic properties. These communication protocols have many layers. They include many different encryption algorithms. And the properties you need to prove include things like, well, you can't have a memory safety violation, which is the kind of thing that Heartbleed exploited. That's a very basic property. But the higher level properties are, if two people are talking at each end of the line, we're going to guarantee with this proof that there's no way that an attacker can listen in. It doesn't matter how the attacker tries, they're not going to be able to hack the software to decrypt these messages. That's a very challenging problem because it's a combination of proofs, essentially looking at each line of code

and saying, what are the possible ways that this can go wrong, but at a scale of thousands and thousands of lines of code. And the ability to prove things about thousands of lines of code is actually very difficult. If you think about these proofs, we're talking about literally hundreds of thousands of formulas all connected together to form the proof, and then saying, yes, we can prove that that set of formulas actually is satisfiable. There is a way that this could be true and that no human would be capable of doing that. No way. So that Everest is one of the projects that's come out of RISE. That's right. Yeah. So RISE is a group, I co-manage it with Tom Ball, Research and Software Engineering. It's a group of researchers and developers. We collaborate on a number of

different kinds of projects across the spectrum. So we work on software engineering problems, like how do we build software more effectively? How do we deploy software more effectively? How do we help developers understand where the problems in the code are or what problems they should maybe do a code review for? So that's one end of the spectrum. The other end of the spectrum is we think about the formal foundations of software. So we're trying to ask questions like, what does the software mean exactly? How do we translate essentially a program into math and then use what we know about math to prove what that program is going to do or not do? And unless you get that kind of level of understanding, we're going to be in a world where we do have these bugs. We do run into problems where somebody deploys software and

things like OpenSSL, which is widely deployed, and it's a problem with devices because once it gets deployed on, say, routers, all of a sudden, it's very hard to update, right? It's very hard to fix the bug. So what you really would like to do instead is verify the software before you deploy it, right? And that verification requires a deep understanding of what the software is, how to reason about it, how to prove things about it, and the tools. One of the key things about Everest is it about it, how to prove things about it, and the tools. One of the key things about Everest is it builds on top of a tool called Z3, which is a very, very powerful tool used not just by people in my group, but by people all over the world,

thousands of citations to the work, where if you have a problem that you can specify as a sequence of constraints, like X is greater than three, Y is greater than two, X plus Y is less than 53, it will actually take that and then solve it. It'll say, here's a value for X and Y that will make this thing true. Or if it's not possible to make it true, it will say it's not satisfiable. So Z3 is a mechanism on which people build that helps people think about complexity of logic at a scale that is unprecedented. Yeah. You're here doing this. My mind is going into all the other things that I have, and I know how expensive it is to test software. So is anything, this isn't even a question I had on my list, but you've just prompted me to think of all these developers out there doing smart objects with their own code

and probably just shipping. Sure. Are you guys doing anything to make it less expensive or more easy? Right. I think what you see in the world of software is people want to reuse code. They don't want to write their code from scratch. Right. So a great example is cryptography algorithms. Right. When you think about cryptography algorithms, it's very hard to write that code. It's actually, in performance, it's critical because encryption and decryption, you know, is something that you don't really want to do, but you have to. And so it's got to be fast. But the problem is that if everyone had to write their own cryptography algorithm, most of them would probably be wrong because it's very, very, you know, you have to be super smart to get it right. So what you'd rather do is actually do it once and then verify it and then use the

verified thing. And everybody could use that verified thing. I mean, one of the nice things about open source is once it's available, there's no barrier. So what we're trying to do with Everest, actually Everest is an open source project. We're trying to build bigger and bigger components that people can use and reuse instead of having to try to do it themselves. What are the unique challenges for software engineers now that maybe they didn't face 30 or 40 years ago? Great question. You think about a software developer in say 1990 or 1995, where they're thinking about building a desktop app. Like it's on the desktop, doesn't talk to anything.

It's the UI, it's maybe the logic, et cetera. But you think about the developer's life now and how totally different it is. And one of the key things is you're building a service, right? You're not building something that sits on somebody's desktop. You know, if it crashes, okay, that one version goes down, but everyone else's is fine, right? When you build a service, it's running 24-7. It's got to always work.

And if it crashes, everyone, all your customers all of a sudden don't have something. So the developer's life is much, much more complicated now. But it's also, I mean, the beauty of the service model is the kinds of things that you can do, you know, with a service, it empowers, you know, software dramatically. So it's harder for the developer. You've got all these new things to think about. You know, there's the deployment process. How do I sort of, you know, make sure that as I deploy it to more and more people that it still has the right quality, etc. But I think at the core of the job is still, you know, is the software right? Does it perform well? You know, and is my customer happy?

I would imagine that's one of your major goals in Microsoft research, Rise? Absolutely. I mean, the whole investment we have, you know, I mentioned we talk about software engineering. So that's the process of building software. Talk about formal methods, that's really figuring out what the software should be doing and making sure it's doing that. And I think another part is actually helping developers. One of the really successful collaborations we've had in MSR in my group is that we have a really talent individual, Mark Maron, who worked on something called time travel debugging. Okay. Okay. So let me say a few words about this.

So time travel debugging. This is a vision that developers have had for years and years, which is if there's a bug or if there's a crash or something, instead of like starting over and seeing what happens, I really just want to step back one step, you know, back in time. So what happened that got me here? Technically, that's a really hard problem because to do that, you have to actually remember everything that happened between when the program started and when it crashed. And so even though this has been a vision for many years, actually giving it to developers to use in a practical way has never happened. Now, this is before Marc Maron and time travel debugging. So Marc basically said, look, in JavaScript, which is a very widely used language, we can build a mechanism inside the JavaScript

virtual machine that captures enough information efficiently enough that now we can enable developers with that go back button. This is a collaboration. So this is Mark in research. This was his vision. But he said, look, you know, it's not going to just be enough to write a paper. I want to make sure that this is actually in Chakra, which is the Microsoft JavaScript virtual machine. So he went to the Chakra team. He talked to them. He sat with them. And at this point, time travel debugging is now part of the open source chakra release. You know, that's really inspiring to know because it feels like a common theme I'm hearing is that people are talking to other people, seeing how can they bring in expertise

from other areas within different groups, even in the research group. Right. And no, absolutely. And one of the things I think that's really exciting is, you know, especially with the success of AI is it opens up new collaborations, you know, interactions with groups that we didn't used to interact as much with, partly because of these questions I mentioned, but partly because, you know, it's always exciting. And, you know, every time you have this kind of shift in the way people think about the complexity, new problems they can solve, new ways to solve it. One of the things that's really exciting about the AI technology is it does change what it takes to build these models.

If you say, well, I need a developer to write the code, that's one thing. But if it's a, I need labeled examples to train, that's a totally different set of skills. And it changes who can do it and how you do it. And so every time these changes happen, it's a new cycle and we get to do all these fun things again. Right, right, right. That's so interesting. Well, listen, let me wrap up with asking, because I'm really interested about who comes here. What do you look for in somebody that you

would like to come here and work with you and rise? Well, I think there's a couple things. I think we look for people who are broad thinkers, that really, like I said, they go to the heart of the problem. One of the things we offer at Microsoft, which is really different than an academic experience, is we have incredible depth in the product teams. So the product teams are dealing with real problems every day and sort of thinking in terms of, you know, that's an opportunity for the people that come here, the researchers that come here.

That's something they just can't get in the academic world. You know, you want people that embrace that, that they basically look as broadly as possible at sort of how they can impact, you know, the world, the company. In the end, like I said, we look for people to build stuff, people who want to think about solving problems, sharing solutions, you know, having people use those solutions and get their hands on those things. And so the sort of the expansiveness, the willingness to work and learn across disciplines, I mean, one of the things that we have is a huge resource. You know, Microsoft Research has incredible depth, you know, compared to almost any academic department in the world. If you're here and you don't step across the hallway and start talking to people doing things, you know, very different than you, that's just a missed opportunity. Right.

So I think those are the kind of things that, you know, resonate when I look to hire people. Obviously, we have a lot of visibility in the academic community for the things we have done. People come to us with an understanding of the kind of expertise and the kind of strategy we use to solve important problems. You know, something like Project Everest is a great example where security is incredibly important. You know, it has enormous visibility. It's an expedition, which is basically a multi-lab effort. So it's not just people in RISE. It's people in Cambridge. You have Sherpas?

Yeah, right. So it's a team effort. But I think one of the things about that is it reflects an understanding. This is such an important problem. And it's not just an important problem for Microsoft. It's an important problem for the world. And in fact, you know, understanding how to do this process and understanding what tools are needed and, you know, what can and can't be done, you know, is really going to be very important for the whole software ecosystem in the next 10 years. The fun thing is

that, you know, every day is a new day. We get to have really exciting collaborations. It's a dream job. I mean, it's one of those things where working with the talented people that I work with every day is the best possible thing you could imagine. Ben Zorn, you're a rock star. To learn more about Dr. Ben Zorn and the wide, wild world of programming languages, visit Microsoft.com slash research.