 So, why we created this project is because we reacted to all of them. So, everyone, I am Zahedra, a software engineer at Dustbin. So, those who don't know Dustbin are SDK powers, 100 million devices. And you may have seen the rotating logo at one Swiggy app, Kettle, and Amazon app. And we also help build deep and we have 20 million customers like that. And we are also building Dustbin, which is like UTIA for petroleum. Yeah, so this talk is about the space story. How we started with the app Etergs and then in our quest to improve the programming of our company, help the pressures and find better ways to program. And ultimately, we defeated, we couldn't use it. So, we had to build an alternative and be in an order. So, we started using the app Etergs in late 2015. And we were quite happy with it. We were building dashboards and mobile issue web components with it. So, it was going very well. So, we liked the paradigm, how it was going. And we also JavaScript shop. So, in the back end also we had Mojiz. So, yeah, we are running JavaScript everywhere. So, in the quest to find better programming, we were looking at various frameworks like these, like how do we improve it. So, the senior people in our company mainly came from Georgia and Scala. So, we anchored on functional programming. So, we decided to use functional programming constructs in JavaScript and we are using like Ramda and RxJ, if you've heard, FRP like systems. So, we also looked at languages that combined with JavaScript. Because our main question was JavaScript. So, we looked at JavaScript. We looked at L. We must have a lot of element. We may not have a lot of team. So, yeah, so, we were quite interested in JavaScript, isn't it? And so, we were looking at just the area power and payments. So, what happens is, let's say a bank, a bank doesn't support something today. They don't support 4DP today. So, then what do you do? You have to make some changes, right? You can't do SDK updates. You can't, like, write some Java code and use it. And you can't do that. And you don't expect, let's say, and Swiggy and all the world that same old time. So, what we needed was the ability to dynamically push some changes. Let's say some small UI tweaks, somewhere to tell the users, right? Or change some flows. So, that was one constraint. In other words, that SDK size has to be between 150 and 100K. So, that was another main constraint that we had. So, initially, we were experimenting with SDKs by confidence. We were using React feedups and all those things. Maybe React native could solve our problems. Because the main issue with SDKs by confidence is that animations are not that smooth. The light factor is not that good. So, when we made the hello world apps for React native and it is good. Like how React native is React, native is Angular. So, the hello world apps were 7MP. So, that was not possible. The live view overhead was around 6MP. So, we knew we can't do that. So, yeah, that was pretty big. In this period, we tried to figure out why it was so big. So, it turns out that in React native, they built their own JavaScript engine. So, rather than using any other way, they wrote native Java code and created a JavaScript JavaScript executor. So, that was the main reason why the size was so big. Another thing was they wrote a lot of native problems in Java. So, these were the two main reasons why the size was so big. Like 6MP overhead. So, we had to build our own alternative. So, we called it history why. And we found a different way of approaching the same problem. So, it turns out that was pretty good in terms of size. Why is that included in your APKs? But P is that much. And the current overhead is over 35kb. So, if you just include this, that's how big the SDK size is. So, how did we do that? Why is it so small? So, what we did is we used the native engine that comes under the app Android. This time, the Android updates. The Chrome also updates. So, it depended on Google to update the Chrome and take care of security and all that. So, instead of hitting as the JavaScript engine, we did that. Also, another thing is to remove most of the native code. What we did is we used something called detection. This is what I'm indicating. So, detection is the ability of a public program to examine, to inspect and modify some structure data at runtime. So, basically, you have a lot of power at runtime to manipulate things. So, you don't have to write things. You can write a lot of generic stuff that can at runtime be a bit tricky. So, the main issue why people don't use detection is performance. Because a lot of your work is being done at runtime. So, things will be slow. So, we kind of solved that by optimizing the functions that were being called a lot. And we were also casting the beauties that quality created. So, when you handle beauty. So, then we came and we had three weeks of time. And most of the company is actually special. We have very few experienced people. Mostly special and in terms. So, we have a team of specials. Especially, I was going to production and it was pretty hectic. And it's a different day. And so, as I said initially, functional program was the answer. Because of being experienced people, we did have a new update. We found Tearscape, the perfect language for us. Because it had the best of both worlds. Haskell and JavaScript. So, how many of you have heard of Haskell? Tearscape is a pure functional programming language. And it has very strong typing. It is pretty much a dialect of Haskell. And all the good. And it is also backed by category. So, the good thing about Haskell and Tearscape is that the background and the ads app, it is all these actions that are used in it. And type story is good. So, normally, we didn't think much of what types we are going to Tearscape. But, four times we leave on type if, when you have time, because of the program. It helps reduce the bugs that occur. And also the pressures. It helps them a lot in building the application. So, the first thing we did was, we did something called dual language, which is a TSM. So, normally, when you have an application, let me make a transaction app. So, the transaction app selects you from A to B to C to D. So, if you do, let's say, show user function. If you show something, user chooses something. Then you show him, okay, you want to achieve this. I will fill this data. You look at that data thing. It shows the scale. So, it is different. When you are finding, you help the user achieve their goal. So, these are transaction apps. So, what do you do? You basically help the user achieve their goals. So, what we did is, we tried to make a PSA that makes it very easy to do that. So, this is how it works, right? So, they run a call line. It's flashing. You find that most throughout applications are like this. They follow this path. It's flashing. And we load the input from this path, output from this path. We make some data call, create operators. They show those operators in the UI. And they view it for the user to select one operator. The user selects one operator here. And they show another screen asking for the mobile number then mobile number screen. How can you see that? The status screen is made up of this. There are two possibilities in that screen, right? There are two possible actions. One was user could submit or user could upload. Similarly, let's say some other part. Same. So, normally when you are building a screen, they will say when you are trying to code the types, right? So, they will say we have to solve that problem. That is what all can happen in the screen. You will go into coding before you write your functions itself. In your type, you will be able to specify, okay, this is what I want. This is what you are thinking in your head. It helps with that. And it helps with basically all the F conditions that I do. On this R status screen. So, this was the flow language that we did. All right. So, next what we did was on top of that, on top of Pressure UI, we made a sketch plugin. So, what we did is allowed designers to design directly different. That is, there is no designer developer handle. The designer directly, whatever the designer developed, designs is what the user gets. Okay. So, let me show you one thing. You may have got a sketch app, right? So, this is what most people use to design. So, I have a demo screen. So, as you can see, the app is now here. And this is not just web, mobile web. It is also an Android and iOS app. So, the designers just made these things and it was actually directly getting converted to media. So, you can see this is what changed. And then, as you can see, these are mobile, like this concept there. Plus iOS and Android. All of them can just from one design type. So, that's the main benefit. And we are still developing this. Like how designers prefer to have their fix to perfect device. Now, they know whatever they are developing, there's not going to be any margin change or something. It's going to be directly what the user gets. So, this is the main benefit. Because then, they're not going to be happy with, let's say, a designer developer forgets to make some change that they really want to be there. That's one big benefit. We are also starting a school of functional programming at Jespe. So, as you can see, certain parts in Askel and all these similar languages are quite hard because the learning power is steep. So, we found ways to teach specials. Functional programming very fast. So, our only aim was to quickly get them onboarded to monayas and all these functions that seem very hard. But, actually, it's not that hard and pretty powerful. So, zero to monayas in one hour. So, these are the things that we are trying to develop inside the company to help each other. And we also created the simple DSL that we saw. Without having deep functional language a product person can also see what the app is. They can make modifications with the flow language. So, yeah. So, how I told you about Jespe's storing. So, this is also my story of how I just came out of college as an intern and I started with this project, the story I started with this. And I got obsessed with it. And so, I used to go at like 4 a.m. in the morning something. And so, I even gave up because it was so hard. Basically, certain parts were I thought technically not possible but it turned out it was. So, all I want to say is that let's say you are stuck in some project and it's looking very hard. Even though I was an intern if you just push through, right? It still doesn't matter that much. Like, as long as you figure it out or if you look at it from a different perspective you'll find a solution. So, that's what I wanted to say. So, if you guys want to contribute to Presto or check it out. It's on YouTube right now. And if you guys can send a new video to that if you have any questions, tell me now.