 So I really started by being interested in psychology and how the mind works. And what programming languages are really about is, well, you've got this idea of what you want the program to do. How can you express that most directly? And the mind, of course, is a very messy thing, so trying to turn that into something formal that you could maybe even prove properties about is a really interesting question. And that has kept me occupied for my whole professional career. So Plutus is the smart contract language being developed by IOHK for the Cardano platform. There's been quite a lot of discussion recently about smart contracting languages based on ideas from the functional programming community. So simplicity has come out and Mickelson has come out. And it's really great to see ideas from the functional programming community and the formal methods community being picked up and put to use. Now both of those are extremely low level languages. Plutus is more a higher level language. It's sort of a simplified version of Haskell, which is seeing wider and wider use, including implementing a lot of the Cardano platform itself. So it's a bit of a higher level language. We have a slightly lower level language called Plutus Core that it compiles into. But it's still at a higher level than things like Simplicity and Mickelson. Both of those rely on navigating a stack or navigating a data structure to get at all your variables. We just have named variables, so it's much more familiar, easier to use. And we think that even below that, the compiler can deal with all that. So the people reading it don't need to worry about it. Haskell belongs to a family of programming languages called functional programming languages. And in most programming languages like Java or C++ or whatever, you're mainly concerned with a word of memory. And you write things into that one word of memory. And then you have to keep track for all the words of memory of what's there right now so that you know what's going on. Normal mathematics doesn't work that way. In normal mathematics, you just have values. And you have functions that act on those values and return to other values. And there's no notion of a store that's back there whose contents may change. It all just depends on what values you give to the function. So functional programming works off that very simple idea. It says there's no store that gets changed. We just have ways of describing values and we pass those values around. And if you're used to the other style of programming, you might be surprised that that style works, but it works very well indeed. And it's not always finely attuned to getting the last ounce of efficiency out of the computer architectures that we have. But in fact, computers have gotten really efficient. It's fine. What's usually much more important when you're writing a program is not can you get out the last bit of efficiency. But much more importantly, especially in the blockchain and cryptocurrency world, doesn't do what you want it to do. So functional languages are actually much better than that. Turns out if you look at financial institutions, at banks, at places doing electronic trading, more and more of those are moving to using functional programming for exactly this reason. It's easier to make sure that you get the answer you expect. Is it fair to say that Haskell is more like math? Yes, including the fact that developers get scared of it. If you write anything in italics, it looks like math. Developers go, ooh, I can't do that. And I'm really surprised that they have that reaction. Because they can do JavaScript. And JavaScript sometimes involves a lot of little, picky, tiny rules that are quite illogical, right? There's this whole tradition of saying what over various JavaScript programs whose behavior is really hard to predict in advance. Mathematics is much more logical, and it's actually easier to deal with, I think. But it's taking a while for developers to discover that. Because they think they can't do it, but in fact, it's easier. Some developers are intimidated by Haskell. And then others love it and are really getting into it. I hear from people all the time who basically are saying, I'm a developer, I'm trying to learn Haskell. Can you give me a job? Now that I'm working for IOHK, maybe that'll be more likely. So there are two related areas. One is programming languages. I work in the functional programming part of that. And then closely related areas called formal verification. So the idea in formal verification is you use logic to write down a description of exactly what your program is supposed to do. But there might be many ways of doing that. And that description's not necessarily going to be efficient at all. And then you can write a program to do it. It's really easy to write down the description of how to turn a internal data structure, say an abstract syntax tree, into an actual string that represents your program. Now what a parser does is the exact opposite of that. That's a much harder process to describe. So if you're writing down the formal description, you just say, here's how you unparse it, that's easy. And then you say, I want the inverse of that, which is also easy to say. Then when you're writing a functional program, you'd actually write the parser, which is much more work. Then you want to prove that the parser really is the inverse of the unparser. And that's where we use standard proof techniques. We now have a lot of systems called proof assistance that let you write out a proof and check that the proof is correct. The idea of proof was developed long ago by the ancient Greeks. But a lot of the techniques we use were actually developed just in the 1900s or 1800s just before the stored program computer came along. But what they were getting at is, what is something that would be easy for a computer to check? That was actually their idea of what logic was. So perfect. Now we have computers. Now we can check the proofs. So that's what a proof assistant does. There are various proof assistants around there, more than a dozen of them. But there are some that are becoming quite popular. Another one is called Agna. Agna, in fact, is just like Haskell on steroids. It grew out of Haskell. But it let you do proofs as well as writing the programs. So what you might typically do is write a program in Haskell and then do a proof of it in Cocker Agna. Teams have proved entire operating systems. They write it out in Haskell, translate it to C, do a proof that the translation from Haskell to C is correct, and then prove properties that they want of that operating system. There's a team in Australia that did that for an operating system called SEL4. So it's quite impressive what you can achieve with this. A different team took a C compiler and proved that correct using Cock. That was a team led by Xavier Leroy at Inria. So the whole stack of computing now, we can actually prove it correct. It's really expensive to do this. It takes a lot of work still. You wouldn't normally want to write a program and prove it in that way. But if your program is manipulating millions of dollars as many programs on a blockchain are, then it's probably worth the cost. And that I think is why there's renewed interest in formal methods from this community. And I think it's a very positive development. And I'm pleased to be working for IOHK because IOHK and particularly Charles Hoskinson really seems to be leading the way. It's saying, wait a minute. There's all this stuff out there that we can use. How do we go about using it?