 A very quick introduction about myself. I've been making software for the last 15 years and mostly working on building large scale systems in companies like Amazon Trilogy and last five years I've been running a company called JustPay, was introduced to Clojure maybe five to six years back and that's when I kind of got enlightened about how much programming can be much more fun, right? And Clojure is like a clay in which you can, Lisp is like a clay in which you can make art. And yeah, from that this is a story about how I transformed into a Haskell guy from a place of not having types to, from the art to the math. And also the journey, what made us do that, right? So that's a little bit about me, about the company that I run. So we run a company, how many of you have heard about JustPay? Yeah, okay, most of you have, I believe, used it, right? You guys are using software which is written using functional programming. So we have been, we are a company in which most of the people, 90% of the people are freshers and a lot of them are interns and there are very few, very experienced people who are guiding and there is no middle management and there are no traditional architects in our company. And you can imagine how to run such a company, right? With the traditional way of making software, it's almost impossible. And the challenge that as a payments company we face in India is, as you see, typically a payments company like, you can imagine MasterCard, Visa, Stripe, et cetera, in the U.S., looking at them as very big, but in India, the unit economics, it's almost, you have to give your software for free. And we have to have enormous scale and enormous diversity of software. We have to build a lot of vertical solutions. So we can't just make an API and say, like for example, Stripe makes nice APIs and that is enough to run as a business. But here we might need to do transportation solutions, retail solutions, certain types of B2C apps for some large B2C guys in which payments is a major part, et cetera. So we ended up actually making a lot of apps and with a lot of freshers and interns and we were not able to manage the complexity. And you guys can imagine making an app like Beam. How many of you have heard about Beam? Yeah, so Beam is made by us and Beam runs a functional code. So to develop reliable apps with freshers and also as a company, we really like enabling people. In fact, before Jasper, I wanted to start an education company. And at that time, I didn't want to teach the wrong stuff to people. I wanted to actually run a company and see what is the right thing. And now I feel like I've found something that I can teach people. We are also starting something called Jasper University in which we are gonna teach Haskell to thousands of people. So this talk is a bit about the journey towards how we are getting there and how we are gonna solicit support from you guys for that, right? So the first thing is like attacking the problem of building apps using functional programming. We built an internal framework which is like React Native, which is like how to build apps using JavaScript. And that was our first entry into making apps. At least we went into a language in which functions are first class citizens, not Java, so JavaScript. And last year, we have been extremely into making apps using JavaScript. And we have been introducing the monadic way of writing flows, et cetera, in building apps itself. And that gave us the taste of how nice functional programming can be, right? So as you all know, I think a lot of talks would have been talking about it these days. The complexity of our systems are continuously increasing. The complexity of the world keeps increasing. But the incidental complexity, the unnecessary complexity or the complication is actually increasing even further than the real complexity, right? And that is very clear. And app development is a very narrow problem. We were able to isolate these problems, right? The first thing is the event-driven programming model is absolutely not something that is scalable. And especially for transactional apps, which 80% or 90% of the apps are just transactions. It's just like flows. Like A, B, C, D, flows like that, take action A, action B, action C, action D like that in a sequence. And you don't need a complex event-processing type system. You actually rather would need a way in which you can easily represent a sequence of actions. Like a normal C program in which you can write a main function and say like read system call, write system call, et cetera, right? How it actually goes and waits and flows. So that is a much, much better programming model. I will come to that later. And the event-driven programming model is also not composable. So the code becomes like a spaghetti and like it's spread over everywhere and you are not able to see the building blocks which can be taken and reused. And I believe that most of the current frameworks, especially since we were in JavaScript, it's almost a pop culture. Everything is focused on getting started quick. And there is no focus on solving the fundamental complexity problem that I talked about. So here we started seeing though it was a very big jump, started seeing this is not gonna scale at all. And the industry is not at all even looking at moving towards something like Haskell, right? The level of theory that is in language like Haskell or the community like Haskell. So we started investing and we saw that after some time it was, though it takes quite a bit of effort to get it into Haskell, we found that it is really simplifiable. In fact, we went into category theory and my belief is that most of the complexity that we see around us is embedded in our brains in some other form, maybe as motor skills, et cetera. And if category theory is going to really represent the fundamentals of mathematics, there has to be a small transformation or some isomorphism between my brain and category theory or anybody else and functional programming or that things like monads, functors, et cetera. None of the monad tutorials are that easy, right? But I couldn't take it. I thought like I can make something which is understandable to a fresher or even a non-programmer. I'm still in that quest. We'll come to that in a bit. So the thing is about getting to the fundamentals and making those fundamentals understandable, right? And wire apps are again too many things. Everything is fragmented. Like if you take front end, back end, persistence, how do you make external service calls, analytics, the way you write business rules, how you handle infrastructure, everything is different. We started seeing why not see everything as functions, even including infrastructure. So yeah, this needn't be this way at all. And we anchored on enabling freshers and product managers to start writing code. Start writing concise code almost like equations or like English. And we saw that we were able to do that with functional programming language like pure script. And the language of our choice is pure script. I'll come to why we chose pure script given the other alternatives. And we had to choose a domain specific language which is built on top of pure script which is something that is going to be natural. As I said, we have to make these strong theories accessible to normal users, right? A way to do that is create a DSL, a domain specific language. And most of the interactions in an app is pretty much like this. It's just about a conversation between the user and the system. So imagine a typical app in which typically it starts with a welcome, it tells something to the user, it asks certain things, it constrains certain option and still asks or it asks and like allows you to do an autocomplete or a search. You might delight the user with something, you will thank the user, you will cross cell, you will notify, et cetera. Why not all these become accessible verbs or simple functions that are composable and easily usable like Lego blocks for a normal user? And if you look at the system, there is typical things that you read only data you fetch. You detect certain things in a system where whether a mobile is like dual sim or single sim, et cetera and bunch of CRUD operations around data. You do a lot of workflow like operations, et cetera, which are the system verbs. So it's not enough to just create the verbs which are required. We have to find a way in which they become composable. So just to take an example, an app like Beam or any payments app, I'm just taking, we are a payments company, we build a lot of apps in which there is this step called onboarding. Whenever you first get into the app or the signup process, right? For example, in an app like Beam, there is an introduction, there is a mobile verification and then there is a creation of a virtual private address, a payment address. So why can't we just write it as, so this is like a, we call it a fishbone diagram, which is nothing but a function hierarchy, a composition of functions, but it is a format which our product managers understand, right? So to see the Beam onboarding is like an introduction, verification of mobile create VPA, introduction is nothing but three screens, a welcome screen and step one, help, step two, help. Mobile verification is either verify the mobile by sending an SMS or verify the mobile by sending an OTP. If one of the options doesn't work, it fails. It is like a distinction, it is an R and it goes to the next option. And if you look at the verify mobile number, ask the customer for mobile phone, then call an API. So this is the conversation. It's talking to the user, talking to the system. Then there is a Lego block which actually is a polling mechanism for the local inbox for OTP and then it shows the success. So sounds very simple, right? That any business person can actually put things together. So why is it not already done this way? Is a question to ask, right? I think the core innovation that we did is making the user interface, the way in which you talk to a user, using a screen as a simple function called that waits and continues. For example, you can just do this, saying ui.choose operator from the list of operators and the return value comes to an operator. Using a continuation monad. How many of you know about monads? Awesome, and continuation, yeah? So you guys can imagine something as simple as this. This is how a code for a bill payments flow looks like. So our idea was the entire app should be written in one page or at least what we call as the control center of an app. For example, our features of the app like send money, receive money, onboarding, maybe these are separate files. So typically our apps are composed of three, four files and it is actually readable by a product manager. We are even teaching designers to code right now and I'm even teaching my admin to code or office admin. Well, it is understandable. People who don't know English also because they can see the app and oh, this is how it is and this is how the code is and both are similar, they are able to understand. And well, we had people, some of the people around the world also have been contributing to us in this platform and they flew to India and they have been calling, we are just debunking all the myths because they saw our QA. We call this as the, this is a continuation monad to write apps. We also have a Selenium wrapper in which you can run test cases. And our entire QA team, bunch of them are manual testers, they became Haskellers directly. So this is how simple we can make the code and make it accessible to users, though it's Haskell. In fact, you guys definitely know that when you write functions like this which are pure and this is written using a free monadic DSL. How many of you have used or heard about free monads? So it's pretty much like function composition, just that free monads helped us look at our functions a little bit more like data and decompile some of the internal types. You can actually look up free monads or we can also discuss it offline. It's quite, the theory is pretty complex but that is what helped us in making the DSL so simple at the higher level. And it's almost, it's readable and it reads like a narrative and this is another way in which you can write even without the, you can just like keep piping the statements, the return value of statement after statement into the next. And the continuation monad of pure script also supports the alternate operator so you can actually have our flows. You can have, for example, in a screen you have a call to action which is like a pay button but you have an auto-completer. The auto-completer also has to be active, the pay button also has to be active so you can have parallel flows. So all that we just got it for free. Sure, more about pure script. Okay, all of you guys are into Haskell so you know about composition, how state management is done great and the conciseness, clarity of functional programming. Continuation also you know. The great thing about pure script when you come from Haskell is that the runtime is JavaScript. Pure script really compiles to very, very clean JavaScript which is readable, which gave us a lot of confidence because whenever you use a language which compiles and when it's actually not such a, the community is growing right now but when we started using we still had questions on whether will there be bugs because, what about the stability because we are gonna use it in very, very serious apps, right? But the great thing is like we, it's really, really done well. Pure script is really done well and it has actually taken the best things of Haskell and used. In fact, most of the types will sound like category theory types in pure script and since it is JavaScript and we were a JavaScript company which already have been running JavaScript in front and back and it clearly fit well with us. All right, so then the next thing about the apps, we were talking about the goal tree till now. So overall what we see is the fragmentation that I talked about in apps. You can just have three building blocks and unify everything around these three building blocks. One is like the UI hierarchy which is a spatial tree which can again be function compositions. You can actually use a pure script, a library like Smolder or something to kind of build the UI hierarchy. What we talked about in detail sometime back is the flow hierarchy, the business logic. That is again a time-based tree. That is like a tree of time, like it's functions which are going from state one to state two to state three like that. So the interesting part about the goal tree is it is not only about the UI which I talked about. You can just do, the UI can flow into the backend and come back. We even eliminated the concept of APIs. Why can't we just call the function which just ends up running in Node.js and you don't even need to know, right? So this remote.payable will just be a payable function in another file which just essentially runs in the backend. But like for a developer, they don't need to define API. They just need to tag it saying like, okay, expose this as an API. So we unified the front end and the backend rather than imagining that we have to create APIs, etc. So our idea is in the future, writing the entire front end backend, everything like an equation, right? Within the same file. So the right parts will run in the backend, the right parts will run in the front end. A lot of inspiration for this came from a library called transient in Haskell. We haven't used it much, but like the ideology of transient, the ambition of that was mind-boggling for us. Like from the UI to workflows to even data computation, everything can be just done as flows was what it was showing. And in fact, that is kind of the approach that we are taking. We have unified the backend. We are also like adding to this DSL how we can do scraping. For example, sometimes we have to scrape some websites. So that can be again a monad which just is a parser monad, right? And doing SQL, that's another monad. So everything is just the same language augmented with little bit different, different types of DSLs, but it's all flow. So the third thing is types, which all of you would be familiar. So we are looking at unifying the entire app with the same set of types. So the backend, frontend, and even the database, all of these will have the same types. So that we can minimize transformation or even if some transformation happens, only in the fringes transformation should happen. Sometimes between the UI and the flow, transformation might happen, even that we are unifying. We are trying to create lenses on top of our core types, which can attach to the UI. And in the external API calls, transformations will happen. So we are building tooling in which from our core types to the external API, those transformers are automatically created. Okay, so why pure script? And as I said before, I've come from the Lisp camp, right? And for a lot of time, for almost two years, I've been asking, are people learn Lisp, learn Lisp, and people get into Lisp and say, it feels like JavaScript, okay? So one thing that I realized is, I think JavaScript itself, we have been using Ramda.js and bunch of functional libraries. And JavaScript itself started giving certain things which Lisp gives, except if a person has gotten a lot of experience in making forms like an artist. I think Lisp was not that suitable. Maybe for me what I felt is I learned a lot of, maybe five, six years before I went into arts a bit and started learning a bit of arts. And Lisp really kind of synced up with me in that mode, right? So even before making Presto, my first thing was like creating a Lisp macro to kind of represent flows. And that is what I have been floating around with my team saying like, oh, this is how the flow should look like. But our team just took sweet JS of JavaScript, which is like, which transforms. You can write macros and they were able to actually write the same syntax in JavaScript and show like, okay, you can auto-generate what you want in JavaScript. So in that regard, we were able to achieve, though not at the level of Lisp, but most of the stuff in JavaScript itself. But as a ever-increasing team size, maybe I see like at some point of time you will be having 1,000 people. Right now we are around 120 or 100 engineers working with us and all of them are in Haskell. When we increase the scale, it is impossible to not have types is what we started realizing. So that's when Haskell started making more and more sense where there will be a framework team and they are gonna define the DSL types, core types, et cetera. And there will be a army of developers who will start using the framework and start slowly learning more and more and getting into the framework team. So we were able to establish something like that, right? And that is not possible in the Lisp world in which each one will create their own small languages and it will diverge and it's maybe for a three, four member highly high-profile team it works, but like to create a large army of developers who are again doing really, really good software, I think the Haskell way is the best is what we have seen. And GHCJS is definitely an option that we considered, but it is unlike PureScript, it has a large runtime. Since we are an SDK company, you would have seen us in most of the apps like Uber, Amazon, et cetera, right? They would not be fine with us taking a large runtime and putting in their apps. So we had to have like less than 100 KB size SDKs. So there in itself, GHCJS was not an option that we were able to choose. And also the runtime had, it had more features, but like there were also stability issues is what people who are using it were saying. So in that regard, PureScript was the best choice and so far we have been very, very happy with it. So the architecture options. As you have seen, we have been using the continuation passing style, but the whole industry is looking at reactive, going the Elm way, right? So in fact, before using the CPS style, we have been using Redux. You would have heard about Redux, right? So it's great for dashboard-like apps or single-page apps with high out-of-order interactions, but most of the transactional apps are sequential interactions. And what we ended up seeing is unnecessarily we are having a global state and like having a big state machine to say like go from screen one, screen two, screen three. And there was so much confusion when those started increasing in size. Then I thought like CPS is just like the stack is helping me in remembering the state and unrolling the state whenever it is not needed, which is a normal function call, right? And obviously it made sense for a transactional app to choose the CPS style, but still FRP is something that is important. What we are seeing is that in the apps we are building, the base is actually a flow. For example, somebody will log in, a customer will sign up, let's say log in, and then go to the home screen and the home screen might have some kind of rich interaction. Maybe that part alone can be an FRP. It's like a small Elm widget. But the Elm widget will be a small part of the flow. It'll go to that widget and it might get out of that widget. But the fundamental framework or the backbone is a CPS style in which some of the leaf nodes could be a small FRP implementation. So that is something that we are augmenting to our system. Yeah, so what are the challenges? Definitely we have been taking people, even including me, I have not been the typical Haskell, right? I got into Haskell with a practical use case and we have made it work, but in the process, I think we faced a lot of challenges. The first is people look at it and like why are you choosing PureScript? Like people will come and join our company and they will ask like, why is it so different? Should I really learn it? Will it be useful across in the industry? All these questions. And you might have seen this infographic. I just picked it up from another place. That initial learning curve of Haskell is really, really extreme, right? So one thing that I have been working on is how to give in one hour a kind of intuition to people to reach the monads, right? In fact, what I started seeing is, first I talk about the richness of looking at things as functions, even as philosophy. Like even if you get to quantum theory, et cetera, everybody says like everything is, you shouldn't see things as nouns. You should see things as verbs. So even starting to see everything as verbs and kind of understanding everything as functions and looking at function application and function composition as the first two pillars, right? And then people start seeing, oh, everything is a function composition. This is a function application. And then you see different types of function applications. Pure data type and a function application. It's a normal application. Then if the data type becomes a structure or a context, right? It's a functor and an innocent function. It typically says structure and innocent function is a functor, right? And a structure and a little bit naughty function, right? It's a monad. And people start easily remembering that. And one is like just anchor them on certain, some of these concepts, because once you start showing the type signatures in the right way, maybe you need to swap the type signatures and show, if you guys are, because the monad bind operator has a swapped version of the functor's F map, right? Once you start showing it, people just immediately get comfortable within an R, right? And then start showing the use cases of monads. Oh yeah, just using monads, you can write like almost like we are writing a scheduler or CPS is like a scheduler. You see, this is how you write a parser. It's like semicolons in, and it is bridging statements together. And you start telling them saying, like, all these are pure functions. How, see, this is the backbone in which impurity is mixing. And immediately in an R, people are immediately getting that confidence that they can learn. And we have had success with this. And we are even teaching in other companies and all, and it is working. And the DSL that we made is very easily accessible, because without knowing what is continuation and all people can start making apps. For example, I'll quickly show you, like this is a app that is made out of this much of code, right? You're just showing a splash screen. You are calling an API to get the list of mobile phone operators, and then you are showing a screen to choose the operator, ask for the mobile number, ask for the amount, and call the API. So it is showing a list of operators, and I am entering the mobile number, and then entering amount, and the API gets called, and this is the final screen. To make a app like this, it is that easy, right? And if they want to, if you want to change it, let's say you can say, I am just skipping a screen, for example, here. It's as simple as that. In fact, we can, typically, this auto-reloads also. I've just skipped the mobile screen. So it's as simple as that. To make an app, it's just like a C's main function in which you are just writing statements, and people don't need to know what is a monad to do this. They think this is assignment operator when they start. That's okay. Yeah. Yeah, so the next challenge we had was typers, right? This is something that, when we were building the framework, we had a lot of, because right now we have been six months building it and it has really gotten to a level where without knowing the internals people can use, but the types errors are not contextual. It is gonna point to some wrong, different place other than the real error, and it is going to say something else, but the, which is not easily understandable to people, right? And people have been, a lot of times people will get stuck for half a day debugging one type error, especially in the initial stages when they are learning Haskell. Second is there was a concern on decrease in spontaneity. Like, again, from, if you look at it from an artist's perspective, you want things to be malleable. When you want to do something, you just do it and it shouldn't complain. And this was a major concern for me, will it decrease the creativity of the team, right? It's still something that I think about, but we have been mitigating these problems so far and we have some more ideas also. One is like, what we saw is like, if you force type annotation, basically PureScript gives you warnings, but while checking in our Githook, we have just like disabled warnings. That was good enough to just annotate all declarations with explicit types. That itself kind of started making a compiler point to, reasonably point to the right place where the typers are. And the other thing is typically, after one or two months, we start seeing the spontaneity. In developers, like they kind of, their muscle memory and their subconscious gets used to when they see some kind of error, they know what it is. Or sometimes they just, while typing itself, they just make it such that errors don't come. This has been happening, we are seeing by experience. And since we have really gotten to the high level DSL with a free monad, certain types of internal types are not bubbling up. In fact, AFF doesn't bubble up to the top. Like a lot of state management, everything is done below the free monad interpreter. So that has relaxed the type problem for us. So the big benefits. First thing is we are seeing like, there is a big shift in dev culture. So this is something that I've been struggling for the, like two years before like, really how to get people to think abstractly, how to give that thought process to people saying like, you can learn so much from nature, look at mechanical engineering and you can bring things in, you can learn certain things from art. I've been like trying to do much more vaguer things to get developers to get into doing better abstractions. It worked to some extent, only it's not easy. It takes years to build. Rather, I'm seeing that the Haskell is like a learning track. It's like to some extent that my brain hurts that thing is there, little bit of thorns are there. But if you push people into it, right? They get out with a different mindset. After few months, we start seeing like people really wanting to write apps like equations. And they are finding commonness between all types of things. For example, the send money flow and receive money flow. They're saying, oh, most of the things are common between send money and receive money. I'm going to abstract it out, right? So lots of things otherwise, which we had to push as experienced people, did you do this, did you do that? We are not required to do that right now. And people are enjoying it and doing. That's an amazing thing that I'm seeing. Through experience, it's amazing that we are seeing. We didn't expect that to happen automatically, but a group of people at least are doing it and we are making them the champions who are spreading that culture to the rest of the team. And we have seen people don't browse internet these days. Otherwise, it used to be like most of the time, like see answers outside, right? Anyway, there won't be much pure script answers outside. So everybody's figuring things out themselves. They completely stack over flow usage is gone, right? And we don't need, in fact, I'm not able to hire traditional architects because our one or two year experience engineers have gone like five to 10 years ahead in my opinion. So that's amazing. That's what Haskell is giving us. Very, it's a intangible thing, but it's amazing. And our development speed has really increased because of what I said right now because of this culture. And we also write Java script and pure script. Now any bug, people first go and check JavaScript only. Pure script is like no bugs and refactoring. This is again a very subtle thing. Like we are, we have, we are now thinking big ideas and those big ideas, we are able to take iterative steps. Like whenever I used to think big ideas, I will, in thinking itself, I would want to really converge and that used to be, that used to take a lot of time. Now like we take, okay, let's do this and see and then we can refactor. So that kind of thing culture again has come in. That gives us a lot of flexibility. We will talk about some of the future things that we are planning to do and we are taking certain, okay, maybe this is a possible solution. Let's do it and see any way we can refactor. So that flexibility has come in into the team. And because of the conciseness and the DSL, we are enabling product managers to at least review the code and they can write pseudocode also and they make these diagrams that I showed, the fishbone diagrams. And I say earlier said PureScript is also giving us the small app size. And we have access to all the JavaScript libraries. That's also a great benefit. So apps in production, the UPI SDK that we have built, which is powering a lot of apps, is built using PureScript. The latest version of JustPaySafe is written using PureScript. There is offline payments app called JustPayFuel, which is spreading in all the petrol pumps and gas agencies that's in PureScript. Beams, new features. We have also volunteered to do education app for teachers. That is also for the government. That is also done in PureScript. And we have built a bunch of internal tooling, including a web editor that we are writing, a PureScript editor that we are writing. That is also written using the same framework. Next is we want to extend what we are doing in our company to outside. So we are starting JustPay University and this is going to focus on functional programming and making apps using this framework. And the roadmap, we have already done this sketch plugin, where, so this is not exactly PureScript. This is right now in JavaScript and JSX, but we are looking at moving it to the UI structure using a library-legs-molder. But the idea is that we want non-programmers to start contributing to making apps. So the flow editor can again be done in PureScript. In fact, we are also, we have started a fun project to do using virtual reality code browser of PureScript. It might also, I think it will happen. It's a moonshot type project, but the next thing is we are looking at what if we make apps like Google Forms? Can we make apps in one day? Because we are seeing a lot of patterns in types of apps where we can have reusable components and we can just plug and play and immediately, for example, data collection. There are a lot of data collection apps. There are transactional apps, which is again data collection and doing a distributed transaction. Really speaking, it's UI distributed. Everything in between should be abstracted out. And there are communication apps. There are reporting apps. And all of these, you can just have a lot of pre-made functions which you can just compose and immediately you will have the app ready. So we are trying to find those abstractions. And I think we can reach one day apps. And one of the other things that we see is external APIs. A lot of times they are messy. And from QuickCheck, we got some inspiration of trying various values. So for example, when we take a lot of payments APIs, bank APIs and all this like documentation will say something, the reality will be something else. So we are looking at auto caller and auto figure, it will figure out types in itself. So we are creating a tool like that and we are doing something like GraphQL in pure script. And the type errors, we are seeing if we can plug in something into the compiler where contextually, because our framework is going to have certain types of some types for the screen, certain types of some types for the error messages. So we can actually show the right error based on the type of some type. It can say like you are missing a, handling one of the responses of the API rather than saying like unsafe partial of pure script. We are creating a web ID and remote collaboration tools, especially for Jasper University, because we want to, again, first is type errors. If 1000 people are using our ID and like who is actually struggling in type errors, some, we can have a small team which is helping them out remotely. And we are also looking at certain tools to convert our JS code into pure script code. At least semi-automatic. Some parts we are seeing like JavaScript can be directly converted to pure script. Manually, we need to code up some types, but a lot of functions can be converted. Another very, very interesting thing also we are looking at is what if the entire system, including the front end, back end, everything can be looked at as a reactive system. This is another R&D project that we are working on around Presto, which is like, for example, imagine a chat app. What if it is just like functions in which the mobile phone input one of user one is connected to one of the inputs of the function. Users choose text field. Input field is somehow connected to the second parameter of the function. Maybe the third parameter is the history database and the output is like the real, the chat, right? And that is sent to a transformer and it is just connected to the screen of the customers. So what if we start thinking about the entire app like a small composition of functions or a circuit diagram like this? So what we are seeing is the front end, client, server, in-between servers, everything can be abstracted out by just like having few buses. Like maybe having a web socket in which a bus is on top of which a protocol is there, in-between machines may be using Redis PubSub. So we are also, we see that this is also a easy extension that is possible. Even an Uber app can then be written like a equation which is of this size, which is actually communication between a user and multiple drivers, then drivers getting connected and then streaming of data between them, right? Which is, if you actually think about it, in fact this is inspired from pure script behaviors that was running on the browser. We thought like why not it just encompass the entire system, right? Conceptually we are seeing it's possible we have started to work on it. Yeah, so that's it. We have a lot of ambition around this platform and we are looking for collaborators. If you guys have any questions, we'd be happy to answer. So we are in the back end also, we are using pure script only. So right now we are not using Haskell? We are not using Haskell. Actually, we didn't, in fact, issues-wise as I said, generally regarding types, type errors and the learning curve, few other things. Pure script is a bit evolving language. Sometimes there are breaking changes, we have to migrate but that is okay because again having types we are able to easily refactor. We, in fact, we haven't been using Haskell in production. What we do some toy projects in Haskell to learn because there is a lot of learning resources in Haskell and we keep bringing those into pure script. Yes, correct, correct, right? Yeah, in fact we have been looking at the FRP creator, I think, call in Eliot. So we have been following that way of doing FRP and there is a Haskell library called React to Banana and we have been taking that approach and pure scripts behavior approach is also similar to that and there are lots of other approaches. Elm is also something that we like. Reflex, I haven't seen it in detail. We have used Redux, which is like Elm. So we are mashing up something in this framework itself where we call it active widgets. Like just like we were saying like in our in our CPS continuation monad we can show a UI, but instead of it being a static simple UI it can be an active widget, which can be a streaming data into it or it can also be highly interactive FRP system. So we are taking the React to Banana approach and the pure script behavior approach. Yes, yes kind of in fact I think halogen as you say is a bit more sided towards building UI. We are looking at the presto's flow to be something which is independent even of the UI. Right now it's primarily used for mashing up the UI flows and as you said it is going to extend to the backend and as we were discussing also about scraping, et cetera we are also doing IoT extensions. So what I see is the flow paradigm is something which is more than the UI. And halogen is in fact more focused on the UI. They are also using AF of monad continuation monad only, but kind of focused more towards making the UI development really, really easy. Highly out of order interactions like a complex dashboard. Like the home page of like the main page of the dashboard where like where is which user can do like A, B, C, D, B, C, D, A, any of these order. At that time we have to make that into a FRP widget. And from that maybe a user action will again get into flow and come back to FRP. But the FRP itself is started by a flow. So FRP is sandwiched by hold it by the flow and on top of which also it can go and come back to flow. So this is the model we are thinking about. So we are just open sourced. Currently it is open sourced for education because we did a free education project and for that we had to open source. We are I think in next 10 days you can see like fully all those figured out. We are in the process of doing it. So it is the aider is what we use. Like typical how errors are handled in Haskell. Is it about just the what are you talking about the business errors or make sense? Yeah, so in fact we have ability to that's a good question. In fact we have the ability to switch back even think about back button, right? We have to rewind the state, right? If you take a code like this. If user actually clicks back button in this line in the amount page, it has to go back to the mobile number screen. So we have implemented the state monad to go back and we have the option of making checkpoints and going back to different states and from that that can proceed. So both in terms of users choosing to do back button or errors, right? In fact what you can do there are ways in which you can put this in a block and you can do retries. Typical errors are retries. So we see a pattern of retrying the entire flow. For example you can take this whole thing and make it into a subflow and you can actually have retry logic around it. So we see like there are patterns in handling errors. One is like typically retry the entire flow once more or do an alternate flow and come back and retry. So we have constructs for those. Yeah, I agree. Agreed, agreed. In fact I can see whether I have some code around. In fact I can show you some more real code in which it will be a little bit more complex while it's handling errors. Okay guys, thank you.