 I did a degree in maths and a PhD in maths and I got to the point where I was thinking I enjoy what I'm doing but it's not going to have impact on more than a tiny group of people and at the time there were interesting things going on in computing and I found out about what was happening in functional programming and this was in the early 1980s. In the UK there was a big buzz around functional programming. Partly because it's an exciting technology but it was also people thought wrongly at the time that computers were going to run out of speed they thought Moore's Law was going to fail and they thought well we're going to have to do parallel computation what we need is general purpose languages for doing that let's do it functionally so lots of exciting research in that but then processes just carried on getting faster and the functional programming stuff for that reason got set aside so there was a big big buzz around functional programming and I was at the University of Kent which working with David Turner who developed the language Miranda which was the a predecessor of Haskell pulled together a lot of ideas it's lazy strongly typed but it was also a proprietary language and in some sense Haskell was a reaction to that people wanted a language which was going to be more open and bases for research so I was there right at the beginning and did some stuff on input and output and you know as people were just beginning to understand what type functional languages were doing and then I've been doing that ever since different aspects of it in the last few years I've been looking at how refactoring works in in functional languages particularly but the way I got involved with IOHK as you know Charles was interested in talking to people from the functional programming community and I'd written a book 28 20 odd years ago on constructive type theory which has become very trendy but when I wrote it was just a rather obscure obscure area really of mathematical logic and I'd written this and E-Ray sold 1500 copies or whatever which wasn't bad for the time but then it went out to print and it's now available freely and it's that's had a renaissance and I think Charles have read this and thought oh this guy's interesting we must talk to him so I got when IOHK is really quite a small company I've been I've been talking to you for three years at least I think so that's how we got here and Charles said well how what sort of things would be interested in doing and I knew that that IOHK was interested in functional languages in general and you got other people involved but I thought writing domain specific languages was something that was going to be of interest to me and that's what we've been doing so looking at scripting but looking particularly at special purpose languages for writing financial contracts so Marlon Plutus I mean they're complementary they do different things potentially for different audiences so Plutus is the workhorse it's the the it's the thing that sits on the blockchain sits on the UT extended UTXO model a very lean a very stripped down a very precise and clear model for blockchain transactions and Plutus is the general purpose functional language that is used to write contract but it's a programming language so you know just as if people want to write a general program to work on the laptop or whatever they have to learn Java or they have to learn Haskell or whatever they have to be a coder so the same with Plutus it's a if you know Haskell if you know functional programming it's going to be pretty straightforward but you need to be a coder to work with it but once you are a coder you've got all that power at your fingertips you can you can program anything you want but there's a bigger class of users out there who are not really interested in coding they're just interested in getting particular sorts of things written and one of those one of those categories those areas is writing financial contracts there's been quite a bit of work done in the functional community there's an industry around this the investment banks of using functional languages using a little what what get called domain specific languages DSL's for describing financial contracts and what we've done with Marlowe is say well what would it be like to take one of these languages and to put it on blockchain now if you think about users there's a nice analogy here you know people say the biggest programming language the biggest functional programming language in the world in terms of users is Excel people can write Excel they build spreadsheets in Excel they write formulas or whatever in there to do a bit of computation but then they don't think of themselves as coders they're just Excel users and we we see users of Marlowe in a similar light that they're people who they know what they want to write don't try to small contracts it's something that is probably similar to what a lot of people have written before but we'll allow them to formalize that and to to get that working on blockchain so potentially there's a big user base out there who are distinct from completely distinct from the general purpose coders who will be writing in Plutus and indeed we use our Marlowe is implemented on top of Plutus so it's really a layer on top of Plutus so that's that explains you know where Marlowe fits with the other the other languages so one of the one of the differences when you go to blockchain I mean think about writing a contract if you if I drop a contract with Richard we'll write something down and if we don't obey then one of us will sue the other there's a legal system there to make sure the contract is is is fulfilled and where I there's redress if somebody if somebody doesn't doesn't follow the rules of the contract in the blockchain world or at least the world we're thinking of there isn't a legal system so the blockchain has to be the thing that enforces the contract so what we have to do is think about designing contracts in such a way that they are self-enforceable and that changes the way that we write some of the things in a contract so for example the contract might involve me paying some money to Richard we can only really make that contract work if I commit some money up front to to the contract the contract can't run we can't guarantee the contract will run properly without me making that commitment up front so we have we have this notion of a commitment but we also if we if for example I ask you to commit some money to a contract you could simply do nothing you could walk away and if I'd already committed some money to the contract my money would be locked up forever so instead of as well as commitment we have to think about timeouts I have to say come on Richard commit this money in the next 10 blocks if you don't do that then all bets are off we withdraw from the contract so we've got to think of this urgency we've got to enforce things to happen we keep things going by imposing these timeouts saying if you haven't done something by then then we'll we'll we'll take remedial action of some sort so we've added timeouts to force things to happen we've added commitments and putting those two things together with more common more common things in contract language like observing the value of something outside the price of oil exchange rate waiting a particular period asking a user to make a decision about one option or another we put those ingredients together to give you a small language it allows you to to to express a wide range of contracts so what we've got is the the language as I said which has a small number of constructs that you building blocks you can put together to build a wide range of contracts what we have to help you build those is we've built a tool called meadow that allows you to write your contract and then as it were simulated so without having to run it on blockchain without having to commit real money you can run the contract step by step see what will happen each each block and you can you can simulate user input simulate values of observables and so on and see how the contract evolve so you're able to to try the contract out try out the different alternatives without running it in for real so you get a sense of how it's going to behave and because it's a relatively constrained language you can't write it's not the general purpose language like Plutus we some bad things are ruled out by default so we can ensure that for example contract won't run forever because we have timeouts in there we're sure that at the end of this period the contract will be finished whereas a general purpose Plutus contract could simply sit on the blockchain forever doing nothing or potentially doing something doing something bad we can ensure that that progress happens in particular ways and we can analyse in advance how things will be will behave if we if we make certain assumptions about stock prices we can we can predict how the contract will behave so we can do this prediction not only can we simulate things but we can try and write proofs of how contracts will behave in all situations and say all contracts of this form if they have inputs of this sort will always behave in the right way so we're able to give these these very hard guarantees of the correctness and safety of contracts and I think that's and as I say because you work in it in a specific area rather than being general purpose okay you can't express as much but it means that you can prove more you've got more control over the contracts that you write so that's what we're doing at the moment I mean in the next few months what we'll be doing is taking Marlowe at the moment it's implemented on what's called the mock chain which is a simulation of the full Cardano SL what we'll be doing the next few months is taking Marlowe and putting it on on the Cardano SL that will be deployed we'll also be looking at how people will pay for contracts to be run we'll be looking at different application areas so we've got a lot to do in this in this area and we're looking forward to getting getting stuck in to do that