 Okay, we are, are we live? Okay, good. All right. So Ravi, if you can take on the proceedings now that we are live and then you can hand it over to me. All right. Welcome everybody. Well, stories are powerful and today is a very special day. I think we have a very interesting story for us today. I'm Ravi. I work at a small consulting company called Nelenso. I've had the opportunity to work with just a few years ago and that's when I met women for the first time. I think women has a very refreshing take on problem solving. He'll talk to you about the very smallest details, the most foundational pieces of technology. He'll talk to you about data types. He'll talk to you about files, bytes and at least in my initial conversations. I think why, why is this CEO talking to me about data types? And just as I'm about to think this, he'll, he'll talk about the abstractions that you can build on top of all this thinking. If you, you know, do it in a certain way and how those abstractions will, you know, you escalate those abstractions to frameworks with those frameworks and then he'll enumerate the different sort of business problems that it will solve. He'll say, you know, this and this and this. And then that's when I realized that I think this might be the most like the thing that really sets him apart and the ability to bring together mechanical sympathy and platform thinking. Also, when, when doing this, Vimal puts a lot of trust in people. I've seen him multiple times just say this is the problem. And this is the extremely difficult, maybe, but also simple, composable and scalable solutions for it. Right. And then he'll just trust people to do it. And I think this is really reciprocated by the teams that he does as well. And it shows in the way the teams operate. Yeah. So, and sometimes these solutions aren't here. Sometimes there are other people's but he's able to bring focus of like shine light on them as necessary. One of the decisions I think that Vimal and just they have taken has been the focus on functional programming. And that is today's topic. This focus that they've had on functional topic, sorry, functional programming, especially with Haskell and Periscope has a couple of side effects. The process of building platforms that are used at scale by millions of people, you know, just building these systems in Haskell, quietly without doing much like just doing that by itself. I think that does a lot both for just pay and I'd say for Haskell as well. For Haskell, it busts some of the myths and it's 2021. I think as a Haskell developer, it's a bit tiresome to hear people tell you, it's impractical to solve real problems at this point. I feel like that's overdone. And I think we've seen enough of how that's untrue. But for those who still need it, I think just pay who still need to see it. I mean, just pay does that. And I'm a bit nervous to say this, especially knowing that Simon is going to be on the stage and also, and that it can be misconstrued but I think I'd like to say we've avoided success at all costs and we've been successful as just pay. So that's a good example. For just pay, I think it gives them the strategic advantage of being able to build these platforms with confidence. Just pay is able to build and invest in these platforms and there's a lot of them on the just pay tech page. You should just go see the few ones I've seen closely in the time of work with them. As to the app development framework where you use DSL to describe flows and, you know, what you want to model basically business flows. There's vision, the data streaming platform, there's automated regression testing system. All of these things have nothing specifically to do with just pay or with FinTech or anything of that sort. These are very general platforms that I think they've been able to use well to do like big things. And maybe the biggest side effect and not really talked about as much would be the, and I don't know if this is intended or unintended but the effect on the community itself. I think we're fostering a community of as skill developers and, and exposing almost a whole generation to the language and the ideas, which is very powerful. Don't get me wrong, there are a lot of other companies that are using Haskell, but maybe not all of them are as approachable or accessible from at least where I am in Hyderabad. And that I think is incredibly powerful. I think we'll see the ripple effects of that in the future as well. And I'm excited to see that. So, and with that, I think we want. Awesome. Thanks, thanks a lot Ravi. Thanks, thanks for the kind words and welcome Simon, very inspiring to have you here. I will give you my story. It's about stories. Simon, I would also, as we just discussed, want to hear your story. I wanted to start the education company before just pay. And I know you're also interested in education for kids. Education for the college folks is what I thought I can understand. And it naturally world is full of business logic problems. And we wanted to naturally tended towards how to create better ways of solving problems. And I just discovered I just found that I don't know enough to educate. So I wanted to learn myself. And one of the inspirations at that time was how do you program, how can your program truly represent the problem that you're solving itself. How can you succinctly write a program, which is looking like the form of the program form versus functions so got inspired into the form of things a bit into art also and what got into that. And started my journey in Lisbon closure closure is a practical side of this. We were able to use in our previous company and had success with it. And also saw some issues with scaling teams with that. But the idea still, still, even after eight years, it's stuck with me and we are still exploring and building good building material, the right building materials for the future, because technology is exponentially growing. And the complications are also growing more than the complexity with which technology is growing. And I've seen in one of your talks, you talk about how the mechanical engineering is very visible and how Eiffel Tower gets built and it feels grand, but how all the programs that we are working on are much, much, much more grander. But it is all happening at atomic scale and we are not able to see it. Yes. Yes. And, and the way we are making is through programming. So this programming is a very physical act. So the, so you have to enjoy the tools that you're working with you have to create these intermediate forms, which help you to. In fact, I look at you are extending yourself through these new. Ravi mentioned about something called mechanical empathy, like, I have to, that's a new word to me, maybe, maybe it's that's that's what we are trying to find how to use machines in the right way. Still, still it's a big question wanted to ask you about those questions also and in the way we discovered Haskell. First, when I looked at Haskell, I thought when nanotechnology is going to happen, we are going to use Haskell. That's, maybe that's like maybe 10 years ago I would have thought that way. And it's we are here we are using. We have like, probably like 500 K to million lines of code in Haskell right now and it is all in production. How many million 5 to 10 million. No, 500 K to a million. Haskell is very concise. Yes, yes, indeed. Yeah. So, and in this journey, we are first my personal experience has been, I have learned a lot of deep, maybe philosophical concepts by understanding has to be questioning it. Why, why should some and product be at equal level. What is this, when you're modeling the ontology or the data around the world, this sum of products, looking at modeling the system as a sum of products was such a, you know, mysterious thing to me and I've really gone deep into understanding that chat with my team, why your program can be looked at as, you know, like and or three and it and another thing is looking at the program as a bunch of data transformations. Another, your, the vein, why are there type classes we used to have big debates, why classes compile time polymorphism versus runtime polymorphism, various other kinds of polymer morphism. So after learning Haskell, when we look at anything new that happens, any new language which comes up, right, which in fact could be a DSL, which we used to think it's something completely different. Now we are able to easily see, okay, this is like one instantiation of what we already have in Haskell, right. So, it's really helping us go deep, Simon. And also, one of your collaborators, Phil Valder, in one of his talks he talked, he said about we started 30 years ago and nobody was there and nobody was scaring about it we still stuck to it, because the kind of the depth or well that that's what I want to learn from you and I kept you going in that it felt like we are discovering something you're just not making up something. Yeah, yeah, Simon would like to hear from your experiences this way of going deep after what you feel as deep, we are all after it. What has been your journey, which made you stick to building a system for 30 years, and it is it is like classic art. That's what I call tell our people it is like it's like how classical music is taught in India. You should learn Haskell that way, right. So what made you create this artwork for 30 years, we would like to learn that from you Simon. Great. Sure. Okay, so we should go to it. Yes. So what inspired you Simon from childhood? I always ask people like what, how are you as a kid? Yeah, so I think from an early age, I was interested in, you know, in maths and science and in building things, you know, I spent a long time taking bicycles apart and putting them back together. I completely failed when I got to internal combustion engines I once took a small motorbike apart but when I put it back together it didn't work. So I resolved that I do not have a kind of, you know, that that that visceral relationship with internal combustion engines that some people have that can just make them work. So bicycles was it but then when I was at school in my, I guess, early teens, that was around the time that microprocessors were first being invented by the Intel 4004 came out a four bit microprocessor came out when I was at school. So for the first time, you could get a complete computer on a chip and program it yourself and that was amazing at school, we did have a computer but it was one computer made by IBM, not the IBM PC this is what this is now 19, the early 1970s. It was a good so the so called IBM schools computer it had 100 memory locations. So you had to fit your program in 100 instructions. So I knew that I was interested in electronics and computing. It was kind of like a hobby, but it was in the very early days of individuals being able to do that. So that was kind of how I started to get interested. Awesome. And you saw correspondence between the internal combustion engine and computers. One is very tangible you can do something with your hands computer is much more abstract and symbolic. How did you bridge these two? Oh, I don't know. Well, as I said, it was never very good at internal combustion engines. I think I liked electronics and computing because you could make things that nobody had ever made before. You could build a piece of electronics that did something new. You could build a computer program that did something new. And it was a kind of like a very flexible creative medium in which to express yourself. And yet it's sort of precise and it's not kind of like the qualitative aspects of art. It really, you know, really repays logical thinking. It's a very if you get it wrong, you know, it's a very remorseless and emotionless taskmaster. You know, it just gives you the wrong answer. It doesn't doesn't accuse you just do what you want. Sure. Sure. Awesome. And Simon, when you when you look at a typical computer, it is based on the Turing machine. If you look at the way memory works, we typically the old way in which we used to program if you look at a hardware and you start writing C programs. Or even if you mostly see programs, a bit of assembly. When we understand it, the model of the programming model is I'm assuming I used to feel it very imperative. Very imperative. Yes. Yes. So how did you transition? Oh, well, so for a long time, I assumed that, you know, this imperative mode because it was the way that you wrote programs. That was what programming was about because, you know, I, I, my first, you know, computers didn't even have assemblers. Let alone programming languages. Right. You wrote in machine code. You typed in hex. So, you know, it was registered transfer and all that. You were very close to the machine in those days, very close. So the first time that I encountered functional programming was when I went to a short course given by Arthur Norman, who was a professor at Cambridge University at the time. We're just four lectures. And he gave a course that described functional programming and I was a complete revelation to me. Just a total revelation that you could, you could write programs in a using pure functions rather than using this sort of imperative do this and then do that style. At first, I thought it was just, you know, it's like, I often say to people that functional programming that the way that it's most familiar to them is spreadsheets. Right. They write formally that don't have side effects. But implicit in that is that it's an extremely limited programming medium. Right. You don't think of Excel as something you could write a, you know, a international payment system in. Right. But so the revelation to me was that the functional programming is not just is is chewing complete. And that is you can do anything in it and that it, but it completely forces you to reimagine the whole task of writing programs. And that was so I learned this at university. And at that point I became, you know, I suddenly was like this sudden revelation in which you think, oh, you think the world is this way. And then you look at it from a different direction then and everything seems different because you're looking at it from a different angle. And I would say it's what I describe as a radical and elegant attack on the entire enterprise of programming. So I think of it not just as just another programming language, just another way to, you know, explain to a computer what you want, but something that is radically different. And that was I found very engaging as a, you know, as a 20 year old undergraduate, right, because everybody likes to encounter radical things. Absolutely. And the way you are describing you saw the future and the depth in there. And I think I saw a future. I don't think I thought at that moment, this is going to be the future, but I thought there's something really interesting here. Right. And that really worth pursuing. At that stage, it seemed very academic, right? Very eye-retired. Nobody thought you could program anything useful using functional programming. It was more of a kind of elaborate academic exercise. And that's, you know, the succeeding, I guess, four decades have been about turning it into reality. And the great privilege that I've enjoyed is being able to work in a university context initially, and then at Microsoft Research and have people not just be willing to, but actually pay me to pursue that one idea of purely functional programming, you know, and see where it takes, see where it goes. That's a great privilege, I think. Great. Simon, a question there. So initially, when you said how you had been hacking hands on versus functional programming and the machine, the four bit machine is also something like you are hacking with it. Oh, very much. Yes. That's not theorizing. And when you encountered functional programming, this is another way of looking at things. That's maybe the other side of you, which is like the theoretical side of you. But it was still hacking, right? I always wanted to make a computer execute functional programs, right? I wasn't so interested in the theory. I wanted to program in it. So, you know, I started to write programs in Sassel, which was David Turner's functional language. And I was interested in how Sassel was implemented and it was implemented in terms of these S and K combinators. And at the time, just around that time, John Backus gave his Turing Award lecture in which he said his, the title of his lecture was, can functional, can programming be be liberated from the von Neumann style? And he was describing his language, FP, which was a point free functional programming thing. But he also said, this wasn't in the title. He also said, maybe we should design new computers whose instruction set is functional somehow, whatever that might mean. Essentially, all computer architectures designed to execute functional programs and list machines were kind of like that, right? But they actually built hardware. And at Cambridge, some colleagues of mine built the so-called machine called SCIM, the SKI machine, which was a microcoded engine designed only to execute SK combinators. So, S and K and I were its machine instructions. So, this was also quite radical because it said, we should not only reimagine programming, we should reimagine computational models and perhaps reimagine computer architecture. And retrospectively, I think that was a mistake, right? That we need to reimagine computer architecture, but it was very energizing at the time. Awesome. And then, still, imperative programming was ruling the show for the next few decades, right? Oh, yes. I'm assuming maybe that was for performance reasons or maybe it got an early start. Or do you see any other reason why imperative programming was still the one which industry was pursuing and getting successful at? Oh, well, imperative programming has a very close and symbiotic relationship with the hardware, right? So, in functional programming, there's a much bigger gap between the program you write and the program that's executed. And so, in some ways, that's good because it's a very high-level programming language. On the other hand, it's not so good in the sense that you have less control over what the machine does. So, maybe you have less knowledge about exactly when things will happen or what resources it'll take to make them happen. So, particularly in the early days when machines were very resource constrained, I mean, we think nothing now about machines with gigabytes of memory. But in those days, a machine with 16 kilobytes of memory was considered quite large. Right. So, resources were very tight. So, you couldn't just... So, that, I think, militated in favor of imperative programming. And also, in functional programming, we have no notion about how to do... How do you combine functional programming, purely functional programming, with input output, right? Because after all, in the end, every program exists to do something in the world, right? If it has no side effects, then all it will do is increase global warming by heating the world up without doing anything. So, it took a long time to figure out how could we make... How could we marry side effects with functional programming? That led us to monads. But that was 20 years later. So, it was slow. And even now, I think the... Another very attractive feature of imperative programming is the way in which the objects with their encapsulated state, it feels as if they model very nicely the state and mutability of objects in the real world. Right? So, in one sense, you can say that's modeling very nicely and very directly what happens in the real world. And indeed, many, many books have been written about. You know how you can take your world world concepts and sort of model them as objects. So, there's lots of plus sides to imperative programming. Sure. So, I think that's why it became dominant early and to state dominant for a very long time. But I think that functional programming, it seems to me... I think it's a long-term trend, right, functional programming, that over time, the costs of imperative programming become slowly more and more clear. And the benefits of functional programming become more and more important. And the costs of functional programming become less and less important. So, and it may be to do with scale. So, if you want to build a building out of bananas, you were talking about the right building materials for the future, right? If you want to build a building out of bananas, well, you can build a small building without too much trouble, right? If you want to build bigger buildings, then maybe you get very clever at hooking bananas together. Increasing amounts of your effort go into sort of clever banana hooking mechanisms, right? And I'm awed and to a certain extent shocked and dismayed by how much of the human effort and ingenuity has been devoted to mitigating the bad effects of imperative programming. So, if you think about viruses and what viruses do is they poke at things in the stack because you're going to index a raise out of bounds, right? So, if our language is from the beginning and prevented these things happening, we wouldn't have any of these weaknesses. But enormous, truly enormous quantities of human ingenuity have been poured into applying very sophisticated sticking plaster to some things that, as it were, should never have happened in the first place. That's the hooking bananas together carefully. And I don't want to discount them. And these are truly remarkable, you know, research projects and acts of engineering. But it's a source of regret that they should have been necessary. Absolutely, I agree, Simon, especially when we are scaling with a young team where a lot of people are learning the right approaches from the start to really help us. I hope so. I hope so. Yes. And it becomes as our scale becomes bigger, has become more ambitious in the scale of things we can build because one of the exciting things about computer science generally is that unlike engineers, engineers are limited by the strength of steel and, you know, and how big a building can you build when you can build it, you know, 500 meters tall, but not 20 kilometers tall, right? We can build buildings that are 20 kilometers tall, right, in software. There is no limit to what we can do except our inability to manage complexity. And I think functional programming becomes, you know, is really helpful, is a huge weapon in managing complexity. And so that's why I say I think it will become more and more important as we scale up. Absolutely. Absolutely. And one more point, Simon, when you mentioned about how imperative programming is close to the hardware. So even that could have also got me during my initial career completely. It's all about algorithms. We are always thinking about memory jumping anywhere in memory, right? Yeah. So it's for a small algorithm, it's fine. But the reality is not that reality is local. It's not non-local. Again, just going abstract and talking about it, which if we, I would have thought about all of that to take a bet on which is closer to being real. One is the hardware is there. The other is conceptually functional programming is why, what is purity? Purity is about clearly abstracting it out. And that's how the real world works. Space is not like in one place you can see everything. There are non-local things are eventually consistent. So large scale systems in distributed systems, you have to really design them to be independent. Yeah. So in a way functional program in the depth of it is showing that. Like when you call a function, you don't need to worry about it. It is completely independent. It will never touch anything else. Touch anything else. Yes. And the concept of a memory being as if it is like you can jump anywhere is not close to the real nature of things. Yeah. The summer is very far away. Yes. Yes. Yeah. Pat Heland wrote a paper whose title was the best title I've ever seen on a paper. And here it is immutability changes everything. I love the title because it it says that programming with values rather than with mutable state completely changes the way you think. Not only about programming but in his view everything else. So my focus has rather been on programming. His focus is broader. He's thinking about log based file systems rather than update in place file systems. He's thinking about databases that maintain logs of transactions rather than mutating the database in place that you can do backup and recovery. And he gives in a numerous examples. So he's saying that we should not just look at programming through the lens of immutable values. But we should look at the whole of computer science and the architecture of the systems we build through that lens. Sure. Great title. Great title. And we see that happening in a lot of systems. Every lot of things are moving towards log based. There are lots of names for it. But yeah. In fact functional programming as you know is a long term trend it is getting into even in the Java world. A lot of large scale systems. Yeah. Yeah. Another interesting sort of way to a lens to which to look through imperative functional programming versus imperative programming. And this is rather a retrospective way to reimagine it is to to see as you mentioned that there's Turing machines on the one hand which Alan Turing first articulated but his supervisor his own supervisor Alonso church but for the Lambda calculus. And I now in retrospect I don't think this is the way they thought of it but I now think of functional programming is growing out of the Lambda calculus. Indeed the Lambda calculus is at the heart of GHC and and Haskell and imperative going out is growing out of the Turing machine. And these two computational models are interchangeable that is they can each emulate the other so they're equally powerful but they give rise to very different models of programming. And what I like about that is it says, again, that functional programming isn't just a, you know, just another programming language. It's rooted in a, you know, a set of principles of sort of foundational principles, but ways to think about programming that is that is that means it sort of is not just a fashion it's somehow deeply rooted in logic and mathematics. Absolutely. Absolutely. And another point about you mentioned about how objects feel like the real world. In fact, even using functional programming when we build real life systems at some level we are going to abstract out state. So it doesn't need to be these micro objects all having states it could be a microservice which could have its state. Yes, and it could have its logs and the log based system it could have its content summary of the logs which is its state. It's kind of a mix of functional and you can look at how Alan K put object oriented programming as much more closer to message passing. Yeah. And indeed Erlang takes that sort of view really doesn't it. So Erlang is a great admirer of Erlang as being a sort of functional language but which but which led on top of the functional language is the this system of processes to communicate through messages and of course the processes, you know, have their internal status they process excessive messages. I really like that model. Absolutely. We have also learned a lot from Erlang model. What we saw is, since other systems like service measures, Kubernetes, etc, which are helping us create lots of microservices cheaply. Should we go so much micro as a Erlang process or can we have a little bit bigger service, which is written in Haskell. Yeah. So practically for us, we are able to combine all these approaches and, in fact, it has multiple of these aspects. And the fundamental foundational building material is functional programming but we do learn from the object oriented programming world too. Yeah. And let me just mention the thing that I learned from Erlang it took me a long time to realize this for about, you know, the first five years of Erlang's existence. Well, it's a kind of functional language with message passing and it kind of not not that cool. But then I realized it has this amazing insight that I completely missed, which is that it takes failure seriously. So in Erlang a process sends messages to other processes and the messages may be lost. The other process may die. And it's not just that that, of course, in any system, you know, things may get lost or die, but Erlang has a way to monitor and recover from such failures. So processes can monitor each other, can find out if they failed and spin up new processes. They have a kind of philosophy, a programming philosophy of fail fast. So if a process, something unexpected happens, just kill the whole process, no elaborate exception handling mechanism, just die, right? And you just that process dies. And some some other process elsewhere, which is monitoring it says, Oh, dear, that Charles died. I better recover in some way. That's their exception handling mechanism. So I think I have not seen any other programming language that takes such a systematic approach to failure and latency. I mean, with cloud haskell, we tried to do the same kind of thing essentially to steal it from from Erlang. But I think it's looking closely at the specifics of Erlang's failure model. I think it would be a good thing to do. Right. How exactly did they did? What monitoring did they put in? How does it work? How do they make systems resilient to failure? Very impressive, I think. Absolutely. The supervisor hierarchies and considering that in the real world, how Haskell, yes. So that is the bridge between, you know, how the view Haskell takes, which is much, much more static compile time versus used to have a phrase called production is the playground used to in just pay, how do we get to production? Right. And there can be faith because we after a point it is asymptotic for us to optimize in terms of either for well performance or for bugs, etc. We need to create systems, take the 80-20 rule and create systems where major failures are avoided, but still we have to monitor for all these long tail of things that could happen, which we never avoid. Yeah. And in which points will it happen? So in fact, in my view, Erlang takes an approach where they could be more aggressive in thinking it can happen anywhere. In reality, it happens in certain places. Yeah. And if you take, as you mentioned, take the right approaches of Erlang, the Beam VM and like use that. Yeah, we are yet to see something equivalent to that in the in the microservices or the Kubernetes, the cloud world, hoping to see something there where we can just plug in Haskell and get the Erlangs other facilities through the framework. Yeah, that runs. That's an interesting line that I've, I mean, so, so, Scala's ACA system is called a take so long ideas, transplants them into Scala. And Cloud Haskell was meant to be, you know, Cloud Haskell project and its libraries were meant to be an attempt to transplant the same ideas into a Haskell setting. But it never really caught fire. I don't quite know why I thought it would be wildly successful, but it's completely wrong. So maybe maybe that's something that just pay can do is a producing is what I think we need to say would be helpful would be a really robust, widely usable, you know, open source freely deployable, sort of distributed Haskell that we in the cloud Haskell sense there's a paper about it that says here's how you can program a distributed application using Haskell in the same way that you can in Erlang or ACA. Yeah, the thing I liked about Erlang is it took a position about failure. It said our position is we're going to divide things into processes and the processes are the things that die and they have their own memory space. And, you know, there's no worry about cross process pointers, you know, it was restricted and just as Haskell takes a position purely functional programming know we won't have random side effects and that does. And that is painful sometimes. So Erlang takes a position about partitioning and failure. And that is awkward sometimes, but it's a position which has a, you know, in integrity. I think I think as payoffs. So, I think quite compatible with Haskell. I think you could do Haskell plus the Erlang model. Yeah. Sure. Definitely would be happy to explore that same. Yeah. And, and if you can reuse a lot of the standard tools which are evolving in the cloud industry and somehow combine and make it practical. Indeed. Yeah. Well happened. Awesome. So, and Simon, you wanted people to ask questions. Yes. Yeah. Indeed, somebody has somebody's you see in the chat. So, you know, I'm told us somebody said explain monads and what is the future of Haskell so I don't know where you want to go with either of those. We could see if anybody has got questions they want to ask verbally. It's up to you. What would you like to do? I think we can maybe cover. I have a question. If you go ahead, Santosh. Yeah, yeah. So, I think this is something which you haven't touched about you have been talking about, you know, the kind of history and how Haskell came about and so on. The question is, you had this connection between category theory and more ads, and you used more ads. If I understood correctly, to solve the problem of IO. Mm hmm. My question is, how did this connection evolve and was it a slow evolution? Whether in papers in between or is was it a sudden aha moment? Well, I can tell you that there was was definitely an aha moment about monads. When Phil wrote his paper called, I think it was comprehending monads, in which he first drew the connection between the work that Eugenio Modji had been doing on monads in logic, and said what Modji's, what Modji was doing could be directly played out as a programming paradigm in a language like Haskell. That was a complete revelation at the time, and it was a very much an aha moment. And then, I think Phil and I then worked or I think I then said to Phil, but oh, but if we use took the approach you're describing in comprehending monads, then we could do side effect in computations and do update in place arrays and IO and that led to our paper, imperative functional programming, which was, which first, first said, let's use monads to do IO. So at that stage, it was no, we weren't thinking about category theory at all, really, maybe, maybe Modji was, I certainly was. So it was very much about, here is a way of thinking about programming, really, that can enable us to mix imperative stuff and functional stuff in a single programming, in a single program without the imperative stuff polluting the functional part. So the big worry was, if you have a language like Haskell, a lazy language, and you just said, oh, well, never mind, let's just have side effects as well, which is what happened in ML and what happened in Lisp. In Lisp, you have set queue, and in ML you have whatever it is, you know, bang, you have reference cells. So if you mix that into a lazy language, you get something that's just a mess because you don't know exactly when things are going to be evaluated. So you don't know exactly when the side effects are going to take place. And that means you don't know whether you will have incremented X yet or not. So laziness meant that there was a very strong motivation for us to stay pure and we had no idea initially how to mix side effects into that. And with monads, we for the first time found a way to use the type system is the type system so important here, because it's the type system that allows us to start oil and water, the oil and the water, the oil of imperative stuff could mix with the water of the functional stuff without the two getting sort of, you know, shmushed up together in a huge mess. That was then to answer your question about category theory. I think, oh, then sorry, the next step, I'm not quite sure when this took place was a huge revelation for me was when we learned that we could abstract over type constructors. So we've been familiar with parametric polymorphism for a long time because ML had promoted that, you know, you could have a function with type for all a list of a to list of a that's the type of reverse. We had not had functions which had type for all m m of int to m of int. Right, that was a completely new idea that you could abstract over a type constructor, in this case m, rather than just a type like a hint that was some and the discovery that you could not only do that, but you could, you could, you know, still support type inference and so forth. And then we could do you could combine that with the idea of type classes which we already had, like from numeric using for numeric stuff, and that gave us the monad type class. That was quite serendipitous that sort of combination of ideas. I don't think it sort of was a was a big revelation at the time. And I think then the connections to category theory occurred a bit. I mean, maybe in some people's minds they were there all the time, cleverer people than me. But, but I think it only became a sort of widely understood way of thinking about. You know, monad and functional applicative and so forth, rather later that people said, oh, there's this big body of work on category theory that maps very directly to what we're doing. So that was, and that was very was reassuring in one way because it says, oh, all of this stuff that we've been dreaming up is actually rooted in, you know, mathematics and type theory. There's a sort of principle reason for supposing it's not just a way to do it, but in some some sense, the right way to do it. And also it gave us a good guide for for what to do next. So I don't think category theory tells you what to do next, but it's a sort of if you if you think maybe I'll try this and you can then say what is, you know, how does that show up in the category theory world. If it's a good fit, you think that might be the right thing to do. It's a poor fit, you think less so. So, but mainly, I would say that that work was done by people other than me. I'm very much a category theory consumer. I'm not a category theory producer. I find it very hard to think in thinking category theory myself. Yeah, and just a little bit about the connection between a monad and an IO monad. I mean, I mean, how did you figure that I also was a monad because how did you figure that out? That's a question that requires me to think about what happened 25 to 30 years ago. I think you probably probably the best answer to that question is to look again at the paper imperative functional program. But it was written at exactly that moment. Right. That was the moment which I first understood Phil and I first understood that we could do side effects through monads. I think it was pretty, you know, it was pretty soon after Phil wrote Comprehending Monads, which was 100% him. It was great revelation to me that I realized that we could connect the two. And then I talked to Phil a lot and to John Launchbury and we sort of solidified it. So I can't quite remember the order of which things happened, but it was one of those things that, you know, two months later, it was kind of obvious in retrospect. It can't quite remember how it came about. Thank you. I'm conscious that somebody on the YouTube channel asked to explain monads. I think there are so many tutorials about monads and different ways of thinking. Monads are like an elephant that, you know, one person describes one leg and one person describes the trunk and one person describes the tail. It's very hard to give a way of describing monads that are truly satisfying to everybody. My own personal journey was very much through, oh, list is a monad. Oh, maybe is a monad. Oh, IO is a monad. Oh, once I've got three things, I can start to see three concrete things. I can start to see, oh, there's a common pattern here that I could rather than having two, maybe other things will be monads too. And then maybe I can start to write, and this was the miracle of type classes, I can start to write functions that will work over any monad. Right. So it's not just it's like a design pattern. It's like, this is one of the things I like about Haskell and its type system and functional programming is that it's not like the gang of fours design patterns for object oriented programming, which is a very good book, but it was about a way to think about object oriented programs. And a design pattern wasn't a library, a piece of executable code, a type class or a piece of code. It was a way to think about it. You could see, you could see if you look at some code, you can say, oh, that's the visitor pattern. And you look at another piece of code, say, oh, that's the visitor pattern. You look at another people got this visitor pattern again. But with Haskell, we were able to say there's a type class that says what it means to be a monad and that you can write functions that will work for any monad. And that was a truly, for me, a truly revelatory moment. Great. So Simon, your last point is about the ability to express ideas in Haskell. Yes. So that is, we talked about systems scaling, how functional programming helps there. The next is about the ability to express your ideas as close as possible to how you would want to express. Right. In fact, that is one of the primary reasons we got into functional programming. Yeah. Yeah. So in fact, we wanted our product managers to understand code. That's how I started because a lot of business logic that we write the people who are very interested are the product managers and you can, you also mentioned about Excel being a functional programming language. Yeah. I've even seen R, there are some frameworks called Deployer, etc., which is very much like SQL. Yes. That's something that a person who wants to really get the job done and not get into, as you said, the nitty gritties of unnecessary complexities or complications. And indeed, I've been engaged in a crusade within Microsoft because I've been working for Microsoft for the last, well, 23 years. I've been trying to make the case within Microsoft that Excel, which is already a functional programming language, but a rather weak one, should become a real functional programming language. And indeed, you may, that sort of, you know, we've made some progress with that, some real progress because you'll know that Excel this year now includes Lambda and it is real Lambda. It's not a fake Lambda. So I'm really quite excited because I think that there's a real possibility now and this is not just, it's not just an isolated feature. I think, you know, the Excel team have really got hold of the idea of functional programming as something that end users can do, right, in a very familiar context with the programming environment that they know and love. Right. And then we can, but we can raise the ceiling. So rather than them being stuck with, you know, various strong limitations on what they can do, let's raise the ceiling so they can do more or less any functional programming in Excel. And that would be, that would be truly amazing, I think, not statically tight, but, you know, it's still a big step forward. Absolutely. And, and these realizations are happening because of language like Haskell, which is, as you mentioned, it has been a big experimental playground for ideas and still. Yes. Yep. The deep ideas are holding and lots of other languages are getting influenced now, including Excel. I think that's not something to take for granted. I think it's quite remarkable. And I can take note, I think it's a serendipitous thing. We're just lucky that somehow Haskell has turned into a language that has survived. I mean, there are not, there are not many 30 year old languages that are in a state of very active development, right. Excel is older than Java. Right. And so Haskell is incredibly active state of development. And I think it's because it's got these, these deep principled roots. So it's taken a very unusual development trajectory. Sure. And Simon, in that regard, regarding express ability, what is the deep roots and the bottom up understanding that it's a revelation, you are seeing it and you can see that this is the foundational block which will lead to something that is the right expression at the, from a useful, at a useful level, right, from a, to build a product. The other is like coming from the other side. I have a problem in hand, and maybe my brain is thinking about some UI screens. It is thinking about, I want to talk to this user, as if I'm talking thinking from a people perspective. Yeah. So the bridge between that and the computers. Yeah. That's where DSLs come in. Yes. Yeah. You've been inspired by some of the messages that Alan Kay had promoted there. There is a talk called programming and scaling where he talks about how something like Adobe software can be written in maybe a few hundreds of lines of code, the core pieces. If you have the right outlook to the problem, if you look at it in a particular way. So there is that much use there. So if you just take it for granted that the current ways of expressing the current building blocks, right, current libraries for example in Java and just build it it will be much, much bigger versus you completely think about the problem from a top down perspective. Don't worry, you have any limitation and just think about the problem and you will find a new way of expressing it. So we have also been very inspired from that and Haskell had that middle ground where one of the one of the problems I encountered there with the bliss list like I might get into a fantasy and I might discover monads again. I might discover functors again and think it's something else and it will get fragmented and then the team grows there are when you open up creativity there is fragmentation of ideas whether it's from the roots or is it something which will come and go. What was a problem when you think top down, but the but the even the top is an anchor, the top is something which is very convergent it's real, right, yeah, the root is an anchor. So it has always been a fight and an opportunity for us to really think our anchor is the real problem in hand. I want to forget everything and think about how do I want to express this idea. And then take the real toolset which is malleable and which is from the roots we have the trust in the toolset and it has to be in that regard the toolset being very expressible is very, very important right. And this is this is an area we are trying to even more learn this is this idea is we are not there yet not not to where it can be right. Yeah, do you can ask do you use some software transactional memory in any of your systems at all your million lines of code. Do you use STM. So we don't use the transactions are we are using other systems which support transactions. We don't do that in the application server we do that in a database or a system like read this interesting because I think one of the things that I found. It's a very nice STM is a very nice illustration of the the way in which functional programming can make imperative programming better. So STM was very popular about 10 or 15 years ago, you know in all mainstream program but it's it's fallen out of use, because in an imperative language software transactional memory relies on logging. Reads and writes to memory. Well, of course, in an imperative language, every read or write to memory in principle must be logged, or it's somehow there's some overhead associated with every read or write to memory. In in STM Askel, well, we only need to log we or have overheads for the reason rights to transactional variables, and they're very explicitly notes read T bar and write T bar. And so there are kind of like about a million reads and writes to Ram that are not affected at all for every one read or write to a transactional variable. And so, again, by the type system keeping the keeping separate all the mutation of the stack and the heap that goes on anyway, and the mutation of local state via IOFs, keeping it separate from the transactional variables. We could make an implementation of transactional memory which I think is hugely beneficial for concurrent programming hugely beneficial, we can make an implementation of transactional memory that actually scales. So, STM comes out of the box in Haskell, but it's it's sort of barely used at all in in mainstream programming. So I think it's a very but but and yet it is all about side effects. Right. So, STM is about mutating shared memory between concurrent processes. So, I really like the way that illustrates the, the sort of the symbiosis not just the coexistence but the positive symbiosis make, you know, each making the other better that the functional and imperative parts have. Sure. Sure. Absolutely, Simon, and I still look at STM also as maybe to build reliable systems still putting that in that category, right. Yeah. Yes. And in terms of the ability to express, which again Haskell is beautiful in that regard. And the way the building blocks are designed like you can write a Fibonacci sequence in a line of code. At least as an example, you can show that and such a thing is not because of leasing as it's possible. There's a lot of emphasis on it is close to math in that regard. Yeah. When we look at product managers, engineers, they want to write in their natural language they want to get it like English. Yeah, a lot of our focus is about, okay, it doesn't need to be that concise, but it has to be readable. How to write code, which just feels like you are just reading a book. Yeah. Yeah. Well, as long as. Yeah. And DSLs make it, you know, in particularly embedded DSLs in Haskell make that sort of. They're not always, they're not perfect, but they get you, they can get you quite close to that kind of ideal. Sure. And, and that real world is never perfect. So we are okay with that. So if that express ability for that particular problem in hand is we are able to achieve that simplicity for that particular problem. So that that is again a big reason again types help us in refactoring a lot to get closer to the problem that we are modeling the problem also keep changing. Yeah, I think that's super important if I was to see people who often have the debate about what's important about static types and there are lots of things like you know getting your program right and identifying bugs and compile time rather than one time. But for me a huge thing that you mentioned earlier when we were talking but that is not so commonly talked about probably is that types static type support fearless refactoring. I've noticed that if you have a million lines of Ruby. It is seldom refactored in a major way after 10 years later. Right, so because it's so difficult 10 years later all the original developers have left, you know, you have some knowledge about how it works but you think if I, you know, completely refactor how this library or this software component works. How will that affect the rest of it. It's very hard to be sure. But with a statically type language, you can you can support fearless refactoring we I'm sure you do that in your million lines of code and we certainly do that in GHC all the time GHC itself is 30 years old and we're doing you know heart lung transplants all the time in GHC. That's partly what it keeps it keeps it live. And I think that's a that's an ability to support fearless refactoring makes software much more long lived means it's not just a five year development followed by a 15 year sort of increasingly anxious maintenance period. It's a it's a living piece of software. Absolutely agree Simon and we have to feel it and to be frank, I used to think types could be an impediment to expression. It could, you know, maybe with dynamic languages we can express anything we want and it doesn't prevent us from, you know, errors. That is it lets us it's a bit relaxed used to kill that had that fear initially when we started with Haskell. But in fact the benefits of refactoring it's it's just we have to do it and see it and we have had tremendous advantages and one show for team members are here and a lot of them have been the beneficiaries of that and I've been in the other world of not having that ability and the whole way of, in fact, in just pay people can we take large changes in in like one or two weeks prince and such confidence is there, which is absolutely helping us. It's interesting to know the reason the reason you're saying that you thought that type systems might be an impediment and the truth is that weak type systems are an impediment by weak ones. I mean, simple ones, in expressive ones. Right. So, for instance, if you if you don't have polymorphism, you have to write a different function to reverse a list of characters than to reverse a list of booleans. And that's no fun. I mean, you clearly can see the type system is preventing you from writing the program that you want. And that I think is why people like dynamic languages, because there isn't a type system preventing them writing the programs they want. And it's not just the book is not to hack it's legitimate. It's absolutely legitimate to say I want to reverse a list once, not once for each element type. So, part of the long term research trajectory of Haskell has been to say, let's try and make the type system more expressive so that it can more accurately express the programs that our users people like you want to express. So, it's not just an exercise in academic, you know, strength or sophistication, right, it's an exercise in increasing utility of static types by making them more expressive and I've been very, it's always a kind of an encouragement and surprise to me that some of the most exotic features of Haskell's type system are used most in industry, not in university. Because they care about longevity and refactoring and and expressing in very tight. Sure. So in some ways, I think that Haskell is engaged, there's this sort of two big experiments that Haskell is exploring. One big experiment is, can you take purely functional programming programming with values and really scale it up to to do large scale applications like your like yours. And the second is, can we make a static type system that is expressive enough that it no longer feels like an impediment, but rather feels like a, a, you know, a benefit right so one of the way which can feel like a benefit is it's kind of like a design language, right. You write down the type before you write down the functions and the data types and so it's almost like it's it's that it's an executable design language. So that's that's those are the two big experiments that we're exploring, I think. Absolutely like modeling a problem with types has become naturally we didn't think about it but it is naturally it has started happening that you mentioned about infecting with good ideas. A lot of us are including me like when we think about a problem it's a good way to abstract out the problem not worry about the details what are the let's start with the types. And yeah, there have been a lot of instances where I've got our product managers, take a shared worksheet and we all start typing together. Yeah, and yeah, in fact, a couple of couple of questions in just keep it on the chat as well. In the chat there's some people asking questions as well so you should keep it on those two. Sure. Okay, what projects are you working on Simon in Microsoft? Me now so I've So I spent about a day week working on education. And that's still that's very important to me because we've made major changes in the way that we think about Computing education for children in England at least and the UK in general. And I think that by and the major changes really thinking of computer science as a foundational subject that you we think of like maths or natural science that all children learn rather than thinking of it as a kind of vocational subject that geeks can learn to get a good job in just pay or or even a utilitarian subject that everybody should learn so they can use a spreadsheet and a word processor. So now we think of it as a foundational and that's a big shift in perspective. So that's a kind of like a day week of my time I spend quite a lot of my time on GHC and Haskell because GHC is used by a lot of people and And lots of people have suggestions for making it better and report bugs I spend a lot of time doing code review. So I write code every day in GHC. Well not every single day but most days and submit lots of requests of my own so I still I still one of the privileges I have is that many people by the time they're 63 they're no longer allowed to write code, you know, their managers, but I still have one of my greatest professional successes I think is that I've reached the age of 63 and I still have nobody reporting to me. So I still get to write code. But I've also been working with them with colleagues on them in the machine learning bits of Microsoft so I've been spending time thinking about automatic differentiation. And we've just written a paper called in a provably correct to higher order automatic differentiation which is on my homepage so you can look at my homepage and look at publications tab you'll see this paper. I'm really proud of this paper this automatic differentiation is a very crowded field there's a lot of work there at the moment because of its applications in machine learning. So it's kind of crowded field but it's it's I find a lot of the papers hard to understand and and there are a lot of really good implementations that even harder to understand. This paper is my attempt to express some of this understanding so you might enjoy it. But my colleagues I'm also working with colleagues on applying machine learning to program optimization. Like could we imagine a compiler rather than handwriting all the optimization steps. Could you imagine that we could learn how to optimize a program. That would be kind of cool. It's extremely challenging. But that was the that's the aim of the project. Harsha is asking how do you embed business logic and types and put larger constraints on how people write code. Maybe a question for you more than me actually. Sure and Ravi is asking about a question about ESL's. Maybe both are related ESL's and how do you use types for business logic. Ravi you want to ask your question. Yeah, yeah I actually think that quite a lot of correlation but my question was specifically about women you had said that you sit and I've seen this also but you sit with product people and then you sometimes go to the extreme. So you know saying this is the type and these are the things we do with it or this is the flow of things etc. One thing we just spoke about was the constraints that I put on you and the but also what a powerful type system gives you versus a weak one right. Do you think that or sorry another place this is coming from is also that as a product company that's you know working quickly or passed. There are a lot of ideas around what to build or what to do. Do you think the process of working with the types has helped refine those ideas or structure those ideas or keep them in check even because sometimes people say random things and yeah I was wondering if this approach has helped. Sure, sure Ravi I'm just reflecting back and a couple of things are coming to my mind. We have not been very theoretical into I've tried to get into theory with the time I have but the theory has always been just asking a question is the revelation that Simon talks about do I also feel it. It has to be simple the deep things have to be simple. So why is why is there something called a type constructor wise can the world be represented as like products and some distinctions and compositions and diversions. So I one is I do some of this thinking and some of these thinking have been you know it becomes so common sense equal that I can discuss with our product managers that has been one. The second is the art of Haskell itself. So even if I don't know what a type is after sometime just like music you get used to the syntax and you just start writing your hand just starts writing and I have seen when we it's natural people don't know it's types but like you can just say you know shape is equal to a circle of. You know the center and. The radius or rectangle of the two points etc right so it just people don't need to know it is a type so it just feels like this is a kind of an abstraction that people are able to. You know we sometimes would just say let's just think about our infrastructure and just say it's a composition let's just model our infrastructure. And we need a language we need a way to model it and the Haskell syntax turn turned out to be just something that we can use in a in just the whiteboard so it starts like that and it is they don't need to know that it's even types right and. In that. In that way it has naturally it's just working that's what I saw and the product managers don't. Well it's Haskell it's Excel doesn't matter to them it is like okay this is how you write. You just you can just and these production tools it just feels like these rules in fact the BNF and see I'm sorry I'm probably loosely connecting many things but to us. What matters is we are really understanding the problem that we are solving and we need to write it down in some form a flow chart doesn't help but that this type syntax was helping right in one side deeply and with some of the product managers we. Discuss about you know what world is full of these hands on ours let's just think about the UI as like okay this is going there is a conjunction of steps and there are diversions. Somehow we can see this pattern everywhere so we just wonder like that about the problems we are solving so Haskell has helped us in that way and the syntax has also helped us in. Just in a very spontaneous way representing what we are trying to trying to understand right and model. So. And when when it comes to a developer when when we have me and the product managers when we have written this down they fill the gaps and make it working right. Does that answer your every. Yeah I think. Sure sure. And well Harsha's question on types and putting constraints. Larger systems. So it has been where should you put constraints and where should you keep it open it has been an art and there is a question I would have for Simon also I we have taken much more of the some of the more basic I think so maybe our experts in Haskell could. Correct me the basic. The basic. Building blocks of the type system itself has given us that 80% benefit and whenever we have something special which is happening next. That is a little bit of less of my involvement people are able to I think fill those gaps for example when we want to model DB types and we want to represent more information there the type system itself can help I think people are filling it. But. It has it has been in this Simon one of our you talked about education that that's an area where we need advice on some of the things in Haskell are the fundamentals are simple so my I've been sticking to that and whenever we go into the advanced area just like any art form. Take take you're learning a musical instrument you have to practice you have to have a kind of or take martial arts that are the several levels of you get to black belt in karate. Like it has to be we need specialists who can get good at it at the same time can talk the simple language so when we go deeper into types. During that process we might again take the next 8020 which is like another simple concept we discovered which everybody can understand. So for us to really utilize it as you are mentioning about your the next the long term is going to be making type system or express expressive. So some of those newer ideas we would need to have experts and we need to train them to for them to get in and bring it back to. Something that everybody else can understand in a simple way right. So Harsha's question in that regard is and also Ravi's question both of them are very broad and we are constantly learning there and looking forward to more approaches to. Yeah I think also there's a as an important role that is not that companies like yours can play here which is developing abstractions right so express those libraries so I'll take you know lenses as a classic example right so which I think you know Ed commit kick and some you know some building on early work by some other people kicked off but I think it's sort of popularized it. The idea of a lens as a sort of pointer into a data structure that sounds a bit imperative right but but by thinking of it in this value oriented declarative way could say no lens just is a it has a type right a lens from A to B gives you a sort of know a B value inside an A value and then you can compose lenses together there's a rich algebra for how to compose lenses and it goes very far very far right and yet. But you. And yet all of this is built just in ordinary Haskell right but to understand the lens library you need you need more than just. To understand Haskell right you need to get some understanding of the abstraction what what what is the intuition behind lenses because if you look at a program written using lenses it just looks like line noise you it's completely incomprehensible. But once you have understood the abstractions and the vocabulary of functions that manipulate those abstractions then it all reads very. Perspicuously, so I think what I'm trying to say is it's not just in the language design I think Haskell is sufficient sufficiently rich medium it's like a you know it's like the paint. And then you can paint pictures with the paint and the but the artist to paint the pictures is as creative as the person who created the paints perhaps more so right. And this is the role that you guys play right you guys build the libraries and sometimes they'll just be well it kind of gets the job done sometimes it will be here is an interesting abstraction that we can reuse again and again. And you know generalized in some ways and share with other people I'd encourage you to think creatively in terms of open sourcing stuff that you do. And open sourcing it any you know in a way that says we hope we built this because we think it can be you know applied in much wider context than we are using them in do you see what I mean I think that's a really that's a thing the whole community must do don't rely on the language to do all that. Absolutely and it's also related to how you mentioned you discovered more nuts that you started seeing the pattern and then you generalize it. Yes, yes and the type system allowed you to do it. In fact. Yes, Simon. Yeah, yeah, no that's fine. That's exactly it. Yeah, yeah and the questions that Ravi and her share asked it also like we are iterating that way. When we are the type system is helping us in refactoring it's helping us in modeling and along the way we are able to understand the problem better and model it better. And that has been our experience and as you said about getting into the depth of things and then seeing the simplicity. When we are growing our teams we need to have some of the specialists who can go into the depths and simplify and yeah, let ourselves and the community benefit from it. We that that's maybe the next area of investment for just me. I'm quite interested in whether you and this may not be a question you can answer now but you can you'll maybe explore in the future is that there's one direction for Haskell's development. This is partly in response to a question that somebody said is what's the future of Haskell is we're growing more you know the type system is slowly growing more expressive right in the direction of dependent types. And some people would have a vision that says Haskell should become a full spectrum dependent type language like actor or Idris. And but an alternative possibility is that we should sort of fill out the envelope of what we have to sort of know to make everything fit together and make sense and have all the features that you'd sort of expect given the ones that we have already to make it a sort of coherent whole but then maybe use something like liquid Haskell. Do you know about liquid Haskell as a way to sort of slightly outside the language way to reason about Haskell programs from meta programming if you like. And I don't know which of those is better but I think there's a risk of making ask the type system so complicated so sophisticated and therefore complicated that it becomes out of reach to ordinary programmers so. I don't know that there's a two sort of possible parts and I genuinely don't know which is the better. Sure. And then two questions like this Simon we are in the practical side your second point of make Haskell more accessible and we are able to make it accessible in our small universe by by making DSLs there are lots of people who might not know about Monarch but yes so that that is working out. And creating our system such that so we have the we have made us like a training program for people to get started fast and like you cross few walls it just becomes very natural for example today evaluation of rust versus Haskell after crossing a little bit. Initially Haskell might look difficult but like then rust started looking difficult we. Yeah so that that was a very natural like I was open to see okay community is growing and it shouldn't be my push for Haskell like but our people felt no Haskell is easier and many many advantages. So then one of the questions was what can we learn from rust is something that we also sometimes for the community when we are large enough we can help there. At the same time for your question about know the type system. I've slightly tried to understand dependent types and a lot of times these conflicting sites which is like will it get complicated or will it will there be a simplicity in the complexity right sometimes you have to get there to know it it is an unexplored area right we should also do that so. That's how I would say I am not an expert there but like okay if the intuition is pointing you towards it you should go after it right. And in terms of reasoning about programs is another area where I don't know I haven't you know worked on liquid Haskell but that is the next that we ourselves are building tools since. Programs are looking like data transformations we have been very interestingly we have been taking the AST of the programs looking at it like data we are using our and like creating you know graphs tables etc. Yeah, and since there is a lot of the types systems the meta structure of the program given our domain understanding also this is something that I have been doing this month. Get the AST out and I'm just looking for a meta structure for a particular we want to refactor and since the programs are well structured it considering purity and all of that right I didn't even think about all that like it's just happening that we are one of the things is can we look at our program like data and. Yeah, yeah, and we're getting a much better libraries and tools for manipulating Haskell programs as data now like the Haskell language server is a huge step forward. And and in a better we're trying to decouple the the Haskell syntax tree from data type from ghc so becomes an independently useful library. In its own right and we're trying to make our messages more into a data type so that they can be understood by by not just by the compiler you know reporting textual messages but can be understood by a program that is manipulating a Haskell program. And the Haskell foundation you know that's why you know that the Haskell foundation is a sort of we should just mention it in this this conversation it's a it's because it's a big event of the last 12 months really. And it's very much that's because previously the Haskell community is consisted of lots of highly motivated individuals and little groups but with no no they often a bit disconnected from each other now the Haskell foundation exists as a kind of umbrella body to try to help the community cohere a bit more with the particular motivation that as Haskell becomes mission critical to companies like yours. Right it's not really okay for it just to be is not okay for you to rely on you know a random volunteer who's you know doing things in his spare time because it becomes mission critical to your company. Right so we need a bit more durability bit more reliability to the to our Haskell infrastructure and I think the foundation is a is a sort of user focused and and you know an application focused group to try to make Haskell into something which you can use the mission critical applications in the kind of context you'll be describing. Absolutely Simon that has been a great development last year and we would we are we are working on participating in it. Yes yes I know you're going to be a sponsor that's really good I'm really pleased about that. Because it's yeah because I really feel it's very important to me the Haskell foundation is not something that that someone is doing to the world but is something that or something that someone is doing to the Haskell community but is is owned by the Haskell community is part of the Haskell communities directly supported by and sponsored by and and indeed run by the Haskell community. It's a it's you know should be the very essence of an open source project, not something that's being done by one group to another group. Some more questions. There's Bishkash gosh. Yeah, yeah. I think Vinayak gosh he's asking. Yeah, when did you start GSC and you're in university. How did you manage to stick to it for so many decades, despite there being so many distractions in computing space. Well so relatively easy questions to answer yes so I didn't start GSC when I was a university student know I left university left university in 1980. And at that stage GSC that stage Haskell didn't exist, you know we hadn't even thought of it but I was I was by that stage I knew I was interested in lazy functional programming. Because I've learned that in my you know sort of 1979 80 at Cambridge University that's with these lectures by Arthur Norman and my colleagues that I'd work with I did a dissertation project about functional programming. Then I worked for a small company for a few years and there was a very great summer school in Newcastle that was all about functional programming that I went to. But it wasn't until I went to University College London as a lecturer. I think what an academic job. That was in about 1983 or 1984 and I worked there for seven years. And that was when there was a you know the birth of lazy functional programming as a research that strand came along so I went to conferences. I met lots of colleagues and and then after a while we had the idea of developing Haskell. That was in the late 1980s so and even then of course GSC didn't exist because that we were just giving birth to the language. So I guess GSC started more or less around the time I went to Glasgow in 1990. But at that stage we had got Haskell pretty much designed and so we needed a compiler. So we started to write the Glasgow Haskell compiler in Glasgow. How do we stick to it for so many decades despite being so many distractions? Well, it's a great privilege being a university academic means that you are allowed to indeed encourage to focus on things that you personally think are important and valuable and stick to them if you want. Some people are nimble they move around research space and you know do a research project for a while and switch to something else. And I think that's very impressive that they exhibit this sort of polymorphic ability to do make contributions in many areas. I have chosen a different implicitly chosen a different path which is to stick to one thing. What can we get from purely functional programming and just stick to it like glue and I've been privileged to get a succession of research. I've had to write grant proposals and so forth but I've been given research grants and continued academic posts until about 1998 that allowed me to do that. And then at Microsoft research, Microsoft research again continued to allow me to do it. So I feel as if it's a great privilege but it's also a choice that I've made just to stick to it. I think the fact that I've been able to is something I'm very grateful for. Great. Simon in that follow up question could be how do you like if you personally feel something is important? How do you find that? How do you find what it is? Yeah what is it that you would want to stick to? Oh well I don't know. So yes some people have a kind of you know a vision for the future you know their next three research challenges that they want to tackle. And I've always been more of a one step at a time person. So I did kind of know somehow that I wanted to end up in computing even though I did a maths degree. At the time I did my degree you couldn't really do a computer science undergraduate degree. And because it was my hobby I thought I should do something harder anyway like maths. But so I kind of knew I wanted to do computing then at Cambridge I learned about functional programming and I then I just sort of fell in love with it. It was like an addiction I just thought it was fantastic. So that was a great stroke of good fortune because some people find it takes much longer to find out the thing that they love. So I can't really give a very good answer to how do you find the thing that you love? Except that and it's easy to say in retrospect not very easy in prospect. But to say to everyone listening you know try lots of things and be open to new ideas until you find something that really turns you on. But it's not I don't think it's easy to just dream it up. I think you have to it kind of comes to you but and the way to be the way to come to it is to be open and to try lots of things. That's my personal approach rather than being very you know plan it out. I think it's difficult to plan for inspiration. And Simon one more follow this is very important because I feel lots of youngsters are there and they like relating to what you mentioned when you from the from the 4 bit microprocessor you went and saw functional programming being discussed and you saw the future there. And there is definitely somebody who is into it and you are able to it's kind of a chain of inspiration in a way. Yeah. So in that regard what is going to be the future of programming. You're also working on ML that. I mean machine learning not ML or language machine learning machine learning where maybe I might naively think about it as OK well the world already has is full of patterns and like we are making the computer go and find the patterns. So an approach the approach of programming itself is different versus we thinking DSL we are personally trying to connect to the problem and trying to really understand. Try to go deep and trying to express through a programming model trying to model the problem right in one of your talks you mentioned these are two different approaches. So considering machine learning is becoming deep learning machine learning is becoming very popular and very successful also for a category of problems. What do you see as the future of programming. The reason also being that everything is going to run software in the future. We can see that because of yeah that's a discussion inside just maybe talk about it. Why is that's going to happen because because the atoms are so small it's like so so small that you can do so much. We have just scratched the surface right now. Yeah everything is going to run software. So I think I think the at the moment is because AI is you know machine learning is so been has been so recently successful and it's so much flavor of the month. You'll find politicians and journalists saying oh well in the future we won't have any programmers machines will just learn for themselves what to do. I don't really believe this I think I do think that machine machine learning is really interesting because it is another radical. And and I hesitate to say elegant but at least radical and completely different completely left field attack on the enterprise of programming where you think of programming as how do I tell a computer what I wanted to do. Right so so machine learning you tell a computer what you wanted to do by presenting with a lot of examples and expecting it to infer something from those. And that's very different to either functional programming or imperative programming and for certain class of applications as you say it's much more effective machine learning is I mean. Just as you're writing in Haskell it would be doesn't make it any easier to write a Haskell program that would recognize cats. Right that's how would you you know say they got pointy ears at the top and maybe eyes at the bottom but no some cats are you know upside down. Building a cat recognizer. Machine learning is obviously the right way to do that it's the fact that it's become feasible of late is partly due to better understanding but also a lot to do with vastly increased computational power. So I think that machine learning has a note not just a place but a really important and central place in our armory of weapons for telling computers what we want them to do. But I don't see it as being taking over the entire enterprise I think there are enormous tracks of applications for which it's going to be much more appropriate to you know write code that says what you want. You know if you're writing a word processor you're just not going to write a word processor by you know presenting it with lots of examples of people were doing word processing and expecting it to come up with a word processor nonsense. So I think the programmers jobs are safe. And I think we need to be quite thoughtful and careful about how we deploy AI because it's as you know as we all know it's subject to all sorts of learning biases. And I think we I think there's also an enormous amount of suck it and see going on right there's a lot of compute power being taken to just try out you know 1050 100 and 10,000. And a million different machine learning models for a particular problem and seeing which works best, and we can't predict which will work best we just try it and say oh well it seems to be better if I have, you know, five neurons in this layer and 500 in that layer and if I organize things in this in this way. So it feels that feels a bit unsatisfying to me that we're very experimental machine learning at the moment, but I hope and and somewhat believe that things will improve there that will get better at knowing what will what will work and what will not. So it's a rich and exciting area but it's I don't think it's going to. I think it will be profoundly influential. But I don't think anybody it just pays going to be out of the job as a result. Yeah, and your answer is very insightful Simon especially considering the hype also around some of the AI. Yeah, yeah, it's tremendous hype it's clearly overhyped. Yeah, yeah, and at the same time, some of its achievements are truly truly remarkable. I did not believe that a computer would outperform a human at go for another decade. I would just gobsmacked by AlphaGo it's really impressive that that's just a that's a qualitatively astonishing achievement. Sure, and and one other very meta thinking is about we are we can look at as a cellular beings right and things from us within us we are able to express or deep within us we are able to understand and we should not miss that quality that is a message. Keep telling two people and in that regard, even when machine learning things are working. Yes, we have to go learn but this side of especially a bet on Haskell is about expression understanding an expression and our bet in that direction itself is because this is this is a direction which is showing a lot of potential. That but but if the question of let's go and understand a problem deeply and model itself would be questioned, especially given the hype. This message is very important to us, Simon, thanks for the insight. Yeah, yeah, couple of more questions. Nikhil is asking Microsoft research has a project called Orleans Orleans project. Do you think this model would be valuable to the Haskell community? Yeah, I don't really know Nikhil I don't know much about Orleans and a bit I know of it certainly. So it's a it's a kind of an actor model in the same so it's in the same design space as a line. And they but they have what they call virtual actors that have what they call perpetual existence and automatic instantiation and automatic scale out and so. And it's implemented as a you know, but the this this Microsoft team implemented as a library now an open source library. So I would treat it as being a you know if you were going to get into thinking about what would how can we build a sort of distributed model of computation for Haskell in the in the style of cloud Haskell or lang I would definitely look at Orleans as well. But I cannot claim to be an expert on it. I think it's just a valuable thing to look at. Yeah, one, one more question. Shri Harsha is asking about teaching FP in colleges. So right now, FP is not taught in colleges. How can we introduce and can there be a roadmap for it? Yeah, I think you'd probably be a better you and your, you know, your colleagues would be able to answer that question better than me because I'm not somebody who has a lot of experience in teaching functional programming. You know, I do, I give lots of research talks but they're all to people who will almost all to people who already know functional programming, or else they're at a very high level for people who know nothing at all. We're talking in very general terms about you know it's like Excel. So it's I, I sort of my aspiration would be what I would really like to do is to teach children functional programming using Excel to begin with right I'd like them to. So I sort of believe in my heart that an early exposure to functional programming in a very sort of accessible way. I think of Excel as being the sort of paradigm for that would be there's at least a plausible hypothesis that that could favorably influence children's learning, but I don't have evidence for this. And I'm very cautious about making claims about education because it's complicated. And I certainly in my work on developing education in the UK. I've not tried to promote functional programming at school. Because the first thing to do is to promote programming at school. And I've been going with the flow which is that most teachers are familiar with languages like Python and scratch and that since they're widely available, well supported and already familiar with that seems like a good place to start. I'd love to. There's a few books and a few people who've been working on teaching functional programming to children. So, but I think I don't like waffling about things I don't know about so I'll just say that you should really ask other people about the, you know, how best to teach functional programming in what order to approach the concept. And it's probably different when you're teaching it for the first time to somebody to a young person maybe who doesn't know much programming at all. It's probably different to when you're teaching it to an experienced imperative programmer who has quite a lot to as it were unlearn right on the way to learning functional programming style. But I do think that it makes that for those folk, but even for people who are going to continue as imperative programmers mainstream programs today. I think they write better imperative code when they have become familiar with functional programming when they've understood that alternative way of looking at the entire enterprise. I think that affects it infects the way they think about their programs further afterwards in a very constructive and good way. Absolutely Simon what you mentioned at last there is there are really deep ideas from the roots, such ideas which are going to remain for a long time. That is the revelation that you're talking about. And people who understand he's also a functional programmer. So when we go deep that there are maybe I've been trying to or wanting to do it. Maybe if there are volunteers we can start. We want to start a course and maybe tie up with a lot of a lot of other education companies are there in India and they have been asking for us for a functional programming course. That would be great. Yeah, and you should be good to do it in a thoughtful way that is producer course and then do quite a lot of evaluation and field trials. Maybe try it in different ways or do it in a small group with them to have a lot of feedback. But I don't think anybody you know that there's a lot to learn I think about what the best you know how early do you introduce types do you go types first or do you say let's not talk about types for a bit. I don't know I that there's a lot of interesting conversations to have there. Absolutely Simon and colleges have been asking even they could make it even a credit course that is a course for which they will give credits. Yeah, yeah, and that that's that's there and we need to innovate here. We need to innovate here. One my my intuition says just just like how we are saying for children we need to your heart says that to me Haskell feels a lot like learning music personally to me because I don't have answers to my why brain doesn't have enough answers. Why purity doesn't have an answer only after having a lot of experience. I'm able to understand why it is important. But if a lot of times we are definitely recipients of condensed wisdom in through various ways. And it is our responsibility to understand the depth of things and package it in a way such that the right messages people are infected with the right messages. And how to creatively do it and that's something we would love to experiment with and yeah right in the colleges. Well, India has a you know long tradition of excellence in education. So I think if you partner with a you know with some good schools you'll get you put you could you know you could do something that was well bleeding. Awesome. All right. All right, Simon. Is that Zainab do we have more time. We could go on for another 15-20 minutes and then wrap up. Sure. All right. Simon. What is your advice to youngsters in different ways you've given a lot of insights and as you are talking about youngsters, the school children that is one. People who are in colleges who are like like how you got inspired and you stuck with Haskell for a long time. We are trying to find ways of doing something similar in the application domain. How can we take important problems and we can work on it for a long period. It would be interesting to see ideas like how you mentioned about Cloud Haskell. Are there other ideas that people can come and volunteer. Youngsters can come and they can spend time maybe they might be ready after two years but if they start exploring an area the future directional areas that what you have in mind which could be directional for the young people out of colleges. That's always kind of hard question to answer because it sort of speaks to the, as I was saying, I'm a person who tends to think one step at a time, you know, rather than having a grand vision. But I think maybe I could say something about process. So I think what for me gives rise to ideas is working with other people. So rather than an individual youngster or student working on their own. And this is again something which may be employers like that you can create a context for is to almost like not exactly hackathons, but maybe, you know, projects where you have a group of youngsters and a mentor from from just pay maybe a problem that just pay has or, you know, that isn't mission critical or you'd be working on it directly or cells but would be happy to see some programs. And get people because I've got enormous respect for the creativity and innovation that young people can have if they're given a problem and can work with with each other and with them and so on and so forth. So I think the sort of Haskell summer of code is a, I think Google still sponsors this or some other mechanism is sponsoring in this is that's then what that then people make identify projects and find a mentor and carry it out over the summer, maybe, again, you know, little groups could do that. And maybe again, you could offer some mentorships or ideas to help to help, but sometimes what what is hard for an individual is to feel, oh, I'm not significant enough I could produce a project for the, you know, the Haskell summer of code. I'm not important enough. But perhaps given the, the context of an employer in your in your country with some mentors you might feel more confident, perhaps. So I suppose I'm, I'm, I'm sort of generally trying to say, exploit the sort of, you know, that the local ecosystem I think people feel safer and more creative when they're working with with colleagues that those culture and context they understand you're more likely to fit with them. So that you can, you can sort of play a role in just paying other companies like you can play a role in helping to incubate this kind of creativity among young people. And are there such opportunities with Haskell Foundation too? Yes, maybe even run just thinking, you know, if you had, if you were running a number of summer projects, you know, you could then have a, you know, an in-person meeting or something that you would you get them sort of together because it can be quite, quite rewarding. For a young person who's, you know, maybe has a very, very, very local context to suddenly, you know, be invited to some meeting, you know, that which they meet other like-minded people, you know, in the, with the shelter and support of an employer. That can be quite life-changing, actually. So not, yes. The foundation, I think the foundation will be is, I think would be, this is the kind of something I'm completely thinking aloud here, right, but something like a, you know, you know, an Indian summer of code thing or even an international one or something or a summer school that you run. Those would all be kinds of things which I think you could imagine saying, well, we'll do the legwork, but we could, you know, do it under the auspices of the Haskell Foundation. So it's sort of part of that greater, the greater plan. The Haskell Foundation, remember, is very small in staffing terms. There's only two people work for the Haskell Foundation. So we can't do a lot, but it's quite good at connections and signposting and also a sense that we're doing this. If you do something as part of the foundation, it becomes clearer, we're doing this for the common good, not just to increase our bottom line, which people are always concerned about when companies do things. They would ask, is it just to, you know, is there a hidden agenda, right? If you do it as in partnership with a foundation, people are a bit more confident that somebody at least has looked and think, no, there's no hidden agenda here. Sure, sure. And Simon, when you talk about communities in India, Haskell and Zainab heading Haskell, they have done an excellent job. They have done a lot of diverse set of problems. They used to run physical conferences now and taking a lot of online events. Yes. And we are looking at partnering with them and looking at doing more for functional. That would make a lot of sense because you don't want to replicate these things. You want to partner with them and make them more successful. Yes. Yep. And are there any project ideas? For example, this direction where you said writing Haskell programs, not just APIs, not only available for the compiler, but ability to reason about the program with another program. So projects like that, would there be more volunteers? Is there any way people can join as volunteers, prove themselves, fixing bugs? Oh, yes. So, well, so, you know, there's some big projects that run. There's a GHC itself, and we're always looking for more people to help with GHC. It's a big and sometimes intimidating piece of software, but there's quite a lot of, you know, more routine things that people can join in and help with and get mentorship on larger things. There's the Haskell language server. I'm not sure quite what the project is, but all the groups that will be working on IDEs for Haskell have sort of glued joined together. And that's a big engineering exercise. There's a lot of work to do there. I'm sure they'd be thrilled if more people wanted to help. And that must have, I'm sure that's got lots of, you know, it's more like a constellation of tools rather than a single piece of integrated software in the way that GHC is. There's Cabal, which I know is under-resourced. Cabal is an incredibly important packaging and distribution system for Haskell. And Stack, which is a, and the GHC-UP project, these are all, you know, really important parts of our ecosystem, which people rely on, and sort of assume are well-resourced by a smoothly humming team of, you know, full-timers, but actually are done, you know, in the spare time of volunteers who have other jobs. So I think probably with all of these projects, if you, you know, somebody approached them and said, you know, how can I help you get a very friendly reception? Okay, guys. And similarly on the Haskell Foundation Runs, you know, Haskell Discourse Channel, which is also another communication medium between people in the Haskell community and asking there, but I think it, what doesn't work so well is a completely open-ended question about how can I help in Haskell space generally, right? It's best to kind of identify a little piece of Haskell space where you think, ah, I'm really interested in that. And then see, then ask a sort of more focused question from a smaller subgroup. Otherwise there's a danger, you'll ask a very open-ended question and not get very many meaningful replies and then think you're being ignored, which is not really true, but it's just that it's hard to answer a super general question. But I do stress that Haskell is very much an open-source community. There's, you know, there's, and that means that it functions, you know, completely, the community is precisely the sum of all the people who contribute to it. There isn't really much of a headquarters. The Haskell Foundation performed some sort of modest coordination role, but we really rely on everybody. And I think because it can be hard for individuals to get involved, then I think that's another role for maybe organizations like Haskell, or the ones that you described, or perhaps even JustPay or others, to serve as kind of like brokers to say, well, we've got a group of people here who are keen to contribute, but they're finding it hard to find a way in. So maybe maybe we could, you know, speak with a collective voice and say, you know, there's a bunch of 10 people who'd like to like to help, you know, could we take on some perhaps more substantive project in a more reliable way? You know, and I think that would be another model that I think could be quite helpful. Absolutely, Simon. We should absolutely explore that. And JustPay would be happy to work on such a model too. It gives that stability and long-term projects we can take as you mentioned. Yes, yes, that's right. And it's a bit difficult. There's always a feeling that, I mean, if I'm, you know, brutally honest, if somebody approaches me out of the blue and says, I'd like to work on Haskell's type system, then, you know, my heart, as well as being pleased that somebody wants to work on Haskell's type system and GHC in particular, I do have a worry that it could mean a long, you know, period of lead-in and mentorship and training before they get to the point of being able to do anything. And then they might, you know, well, they get a job and suddenly they're not available anymore. So the sort of the economics of open source systems that, you know, have these complexities behind the scenes was maybe if you had a group of people and perhaps coordinated by an employer or a group that said collectively we have, you know, even though people may come and go, we expect to have collectively, you know, five to 10 people's worth of effort, not full-time, but as, you know, as volunteers and that will help coordinate and marshal and manage. That would be a different story. Do you see what I mean? Managing a large open source projects are quite complicated to manage because precisely because they consist of large numbers of people with practically no central brain. So it's kind of like a large distributed intelligence. So any extra nodes in this sort of amoeba, an extra nodes of intelligence that can help coordinate local patches is really helpful and it's not at all. People might worry, would that be usurping the role of the central HQ? Well, not really because the belly is a central HQ. So be it be a be a new one in the network. If I can come in here for just a moment question, both for women and Simon. What is it possible that we could come out with something like Haskell light, you know, a lighter version of Haskell. So, you know, it serves two purposes. One is to get in new people into Haskell and even for education purposes. I mean, I have seen attempts in those directions like recently I saw IHP, the integrated Haskell platform. So I don't think it is, I mean, I mean, it's supposed to be simple and so on, but it's really not, you know, when you actually try to get into it, it's really not. Is there a possibility, you know, if somebody could, you know, set up a standard, you know, okay, this is what is Haskell light, this is what's going to be in it. Like we won't have type classes and we won't have more nets. We will of course be using them, but that will not be seen by the programmer and you have this. I mean, so if you have a language like that, you know, for that to be successful, you need somebody to take responsibility and come out with a standard, you know, a paper or an RFP or something like that. So what is the possibility of that? Because if somebody comes out with an RFP, okay, this is what Haskell light is going to be, then surely there will be a lot of open source developers who will work on it and come out with it. So we just need somebody responsible to take over and, you know, define that Haskell light. I mean, do you think that's a possibility or do you think it is something that will work or what do you think? Personally, my instinct is to doubt it. So there have been various attempts to do sort of Haskell light like things like NHC and UHC and Helium and indeed hugs originally, which was implemented in CN implementation of Haskell, but it proved very hard to sustain them because people would use them for a while and they think, oh, I want some of the facilities that GHC has and then they transfer and then they, so they never grew a sort of viable user base. I mean, the hugs did, but it was, I think it didn't have enough implementation support in the long term. So, you know, though each of them had an innovation, you know, in the case of NHC, it had really good profiling facilities. In the case of Helium, it's got very good error messages, type checker error messages and so forth. So they all had something specific to offer and yet it's very hard to sustain programming language implementations in the long term. I think I'd be more optimistic about something like Elm. So Elm is very like Haskell and it's been very successful. The whole conference is about Elm, but it's focused around a particular application domain, which is extremely successful. And it's very hard to predict these successes. So I'd be, you know, why was Elm successful? Because, you know, who knows, it just sort of, it was a nice mixture of tasteful language design, heavily influenced by Haskell, but being willing to both radically subset it and increase it in some ways. But also, you know, that met a particular need at a particular time. And maybe there'll be more of those, but I'd be less optimistic about a kind of language specification first approach. Let's just design a subset of Haskell. I fear that you put a lot of effort into designing it and maybe implementing it and then find nobody used it, right? Start from the other end. So I have to say, I would, in a way, in an ideal world, I'd prefer to have more Haskell implementations to compete with GHC. But in practice, the world of programming seems to be that to have for a language to be useful in production, it has to do, it has to have a very large surface area. GHC does all sorts of things these days, you know, finalizers and multiple garbage collectors and foreign function interfaces and graphical user interfaces and who knows, the surface area becomes very big. That's very hard to replicate. So it's hard to build another competitive Haskell implementation. Lovely though that would be. And I fear that a small subset one, unless it was solving a particular application need and doing it really well, like Elm would never gain traction. So be my guest, but I'm not very optimistic. I got it. Thanks. Yeah. I do accept what you say that it is a, it's a fact that GHC is so enormous and Haskell is so enormous is a bit of a problem. It's just, I don't think it's a problem we can legislate away. It's more like, you know, use Elm, you helium. Sorry, go on, go on. Yeah. Yeah. And an answer to that is we even started with Elm. We started with Elm, pure script and then Haskell. Yeah. Yeah. And interesting. Right. So you, you've, and did you continue to use them both? No, Elm was just to study. Immediately we realized that we needed something more. I see. We wanted to, it was more towards, we wanted to express logic in a particular way. Yeah. Elm was a limiting then only pure script helped your script was because we had that requirement for the UI first. Yeah. Then after getting used to pure script, Haskell was. Right. The gateway drug to Haskell. Yes. I should have mentioned pure script as well as an another example of a successful innovation that a particular need. Yeah. And, and in terms of making it like Elm that is being making it accessible to people inside just pay when a new person joins they don't need to know everything so they can come into the headquarters and maybe they just go and start. Turning some knobs, which without knowing all the others scaffolding around. So that, that is something that in our experience if there is a killer app like Elm, just focusing on a use case. Yeah. That's an approach. Yeah. Yes. Even if there is a Haskell project that people can contribute to, maybe that is a way to learn Haskell. Right. Or a framework in which, yeah, maybe, maybe take Pandoc and let's write some. Yes. That's right. So libraries, libraries and abstractions. Actually, when I said abstractions earlier, I meant libraries really. That's a very productive innovation space, I think. Sure. All right. Great. Great. Great. Great. Great. Great. Great. Great. Great. Great. Great. Great. Great. Great. Great. I mean, if you're in your 20's or if you're at your 20's, you would want to invite a lot of contributors. Simon has talked about a lot of areas where you folks can, you know, learn and contribute. Like, we are part of that. Amiba and the headquarters. You guys can learn and you know, our personal experience has been though, I don't go to a lot, but that the depth of understanding of many concepts in programming itself in it. many concepts in programming itself, where the future of programming will go, etc. Haskell has helped me. One is the output of what we accomplish. That also we have been able to do and where is the world going to go in programming. Like Simon, you mentioned about some of the insights where programming should go. Some, even to understand that better programming methods are important. And that is why we chose Haskell to improve people. I personally do improve myself. And whatever I feel is right when I'm really feeling when something is right, that's what you're also doing. You're sharing it with the world to a small extent. We are trying to do that. And hope all of you folks learn from this conversation. And indeed, we can maybe have another one in a few months time, which is more driven by the questions from our current participants than by you and me. Yeah, sort of solicit many more questions in advance, perhaps. Yeah, good. Cool. Thanks a lot, Simon. Okay, great. Be really nice talking to you. Thank you. Thank you, Simon. Thank you. Thank you all. Thanks a lot of fun. Good. Well done, all of you. Make Haskell fly in production. That's really good. Absolutely.