 My name is Jasim and I'm here today to talk about recent ML. A little about me. I've been programming professionally for over about just about 10 years. And this is one of the first software that I built. Now these were easy software to build. Anyone who was not a professional programmer actually could build things that look like this. But all good things have to come to an end. So I have since worked on modern web applications front and back end. And also program with different languages including JavaScript. And most recently I've been working with a friend trying to build tools for designers and front-end developers. So one is called Teleport. It's a Chrome extension that can take any website and convert that into a sketch design. So here I'm importing the recent homepage and making some changes with it. So this allows designers to take existing websites and quickly reproduce that and play with it. The other tool that we are building is called Rotorship Code Gen. So that one converts designs made in tools like Adobe XT, Sketch, Figma and converts them into responsive HTML and CSS. What you're seeing is a sample design and this is a responsive HTML and CSS for that design. See, the generated code here is stuff that programmers like you and me can use. So it uses box model, padding, grids and flex boxes and things like that. All this stuff, the sketch plugin, the UI, the generator, everything is written in recent. But that was not the case when we began working on this product. We did not know typefp. We did not know reason. And we were mostly writing a lot of Ruby and JavaScript before we started building this. Now let me tell you a little bit about how Code Gen works. So you have an idea why we chose to switch over to reason. So here is a vector node. So this is a source data that you get if you grab a node from a design tool like Sketch or Figma. So our plugin exports this. And as you can see, you have got X and Y, you've got width and height. These are absolutely positioned elements. So to convert this into something that looks like responsive HTML and CSS like this is a pretty long journey. So we start with a vector design tree at the top left and it goes through a series of functions. And at the end you get HTML and CSS. So in each step, we decorate each of these nodes with a lot of extra information. Sometimes we merge these nodes together and sometimes change its shape and things like that. So you can see a simplified illustration here. So this is a source node and in the first pass, it might get converted into something like this. This is very illustrative. This is not what we use in real. And it might get converted into something like this next and so on and so forth. So for CodeGen, each of the node goes through hundreds of transformations, some small, some big. And the problem was it was all too much for us to mentally track because we didn't know what the shape of the node was at each point in the transformation pipeline. And this lack of mental model made it very difficult for us to make any progress on the product. We made a lot of mistakes and progress was very, very slow. So we wanted a better way to track the shape and flow of data in our system. And we sort of had an inkling that types could be the answer, which was exactly when Jordan Waku wrote react came up with the language called reason. So reason was a type language and we knew that we could convert all our transformation code into reason. And it also had something called reason react, which is a adapter for react itself. So we can mix and match our existing JavaScript code and our UI competence with reason. So that's what we did. But learning and adopting this new language was a lot of a struggle. So this was a good to look at the time. It taught us a fair amount of OCaml, but it also taught us about programming itself. But it was also a little frustrating to work through because we were writing Ruby and JS before and reason is the typed function language. So we did not have a lot of context and how to write type functional code, but the struggle was worth it. It was worth so much that now when I look back on the last 10 years of my programming, I wonder what I was doing for the first eight years before I discovered reason and type of thing. And that's why I'm so excited to be here today and talk to you about type functional programming and reason. So in this talk, I'll try to describe some interesting bits of the language, especially things that are different from JavaScript. I'll not be able to cover every single aspect, but I'll try to give you a feel for how it is to program with reason. I'll also talk about how to approach learning reason if you so choose to at some point so we can get started. So reason is a new syntax on top of the OCaml programming language. So OCaml is a very old language has been around for about 30 years and its syntax is a little different from what we are usually used to. So you can see the OCaml syntax here. So what it does is this piece of code, what it does is it takes a two dimensional list and creates a string which is an HTML table representation. You can see that function arguments are separated by a space and anonymous functions are created using the fund keyword. Okay, let's take a look at the recent equivalent of the same program. So here this sort of looks like ES six as we know it. We create blocks using the using braces. We use semicons to separate lines and anonymous functions are created using fat arrow. Underneath, however, both reason and both OCaml are the same language and have the same semantics. So I might talk about either reason or OCaml and use the words interchangeably, but most of the things apply to equally to both of them. So is this actually useful this language? What can we build with it? So when you start reading about OCaml, you will hear about Jane Street. Jane Street is a high frequency trading company and they run site about $8 trillion in 2018. All through systems built with OCaml. If you've done any SEO work, you might have heard about it. They crawl about 5 million pages every minute. And they have the second largest index of the web just after Google. All this work done through systems built in OCaml. And OCaml is also particularly nice to build compilers on the first version of Rust was built in OCaml. And Facebook is also a pretty large user of the language and especially for doing compiler work. Now these are all high high frequency trading compilers and app crawlers. These are all the traditional applications of OCaml, but we are we are here today to talk about building front end web applications. So how can we use OCaml to build front end web applications? OCaml has three major compilers. One is a native compiler, which creates very fast, very lightweight binary. So if you want to build something that you would usually use, say Golang 4, you can use the OCaml native compiler to build same software. It also has a compiler called JS of OCaml, which produces JavaScript instead of native binaries. But it supports only the OCaml ecosystem. So you can reuse libraries from the OCaml OPAM package manager, but nothing from NPM. The compiler that we want is called BuckleScript. So that produces JavaScript and you can use any NPM package with BuckleScript. In fact, it was built at Bloomberg for this exact reason. Bloomberg is also a pretty large user of OCaml internally and reason uses BuckleScript as its default compiler. You can also create native binaries using reason, but this is a use case that they support most. So for the rest of the talk, we're going to be talking about using reason with the BuckleScript compiler. So here is BuckleScript in action. This is recent code. Even though it looks a little bit like ES6, what you see here is a program that checks whether the day is 2020 April 1st. And if that's the case, it will print some message. It also uses a moment.js library that is pulled from the NPM ecosystem. Let's compile this and see how the JavaScript is going to look like. This is a generated JS code. As you can see, it uses the common JS syntax to use the moment.js library and the JS is quite straightforward. We can integrate this with our regular JavaScript because this is also a regular JavaScript. You can call external JS. You can also package this into your own NPM packages and export it. So now let's talk a little bit about reason's programming language paradigm. Reason is a typed functional language. So languages like Elm, Fsharp, Haskell, and Pioscript. All these languages share the same type system. It's called the Hindley-Miller type system. They also share a similar kind of functional programming approach. In fact, most things that we would read about reason would apply to most of these other languages and vice versa. So if you say read something about Elm and it's particularly insightful, it would also apply to reason. So when you learn reason, you're actually dipping your tools into the vast and varied world of typed functional programming. So what is typed FB? It is just being able to write our programs as a series of pure functions. And you might ask it, how is it different from regular JavaScript programming where you can also create a series of functions and you can have an outer shell, which does all the IO. So that's a very nice way of writing code, especially when you're doing React. That's how you write your React components. But reason is not only functional, it's also typed. And the types guarantee something. Perfection. Recent functions are more perfect than equivalent functions that you would write in JavaScript. So I stole the idea of perfection from Professor Saver Leroy, who's a programming language researcher and also the primary author of OCaml. And this word is used as a, in a sense of degrees, not as an absolute. So Professor Leroy says that a perfect program has exactly what it should do, no more, no less, all the time, every time and with perfect liability and forever. The kind of perfection that you can get from mathematical definitions, which software is to a large extent, or from philosophical concepts. So what can this mean in the context of our day-to-day work, building front-end JavaScript applications? There is a sample JS code. It's a, it's a function that takes an object and prints the next ID, the next user, a simple function. It's as simple as it can get. And if you pass it in an object with ID 16, you'll get 70. But does it work perfectly reliably all the time, every time? Will it ever crash in production? What if ID is null? That works. Our function is receding to nulls. But what if ID is a string? It doesn't crash, but the result is not what we want. But what if ID is an empty object? It still doesn't crash. But we get the wrong result. Now what if we have a list of users, we fetch the last user. And we pass that to our show next function. And in this case, unfortunately, the list of users is empty. What will happen? Program crashes. What is happening is something that is very common to the work we do as JavaScript programmers. We fetch something from a list or an object. And sometimes it doesn't exist. And so we'll pass it down to a deep cost stack and it crashes in runtime somewhere. And to debug this, you have to wind up quite a bit and to figure out where the problem actually originates. So it's one of the most common cases of crashes in production. Now we can keep going, but to make a long story short, there are so many ways this function can crash in production. None of these invocations will work correctly. The only way this function can work is if it receives an object, which has a field ID, which has an integer value. So why does JavaScript allow us to write code that can call this function with any other kind of data? What if we could write functions that will always work because they always get the right kind of data? It can change the way we write software. In recent, we do this with type definitions. We can think of it as a metadata about a program that describes the shape and structure of every value in the system. Here is a recent type definition. We have seen that there is a type called user, which has a field called ID, which only takes integer values. Let's now write show next in recent using this type. You can see that there is an explicit cast from the integer into the string, but otherwise this looks very similar to the ES6 that we just wrote. And it also works. We're passing in ID 15 and we're getting ID 16. Can we send this function invalid data? Can we break it like we broke our JS version? Yeah, it breaks. But this is a compile time breakage. This means no JS was generated for this recent program that we wrote. That's because a compiler found a type error in this code. It inferred that the function show next is expecting something of the type user, but we pass it to random string. The compiler knows that if this code ever ran in production, it will crash. So it simply wouldn't allow the program to get compiled or to move forward. Here is another attempt. We are passing in a list instead of an integer type error. We're passing a function, a random function instead of the user object, again a type error. We're going to keep going again. But the only way this program will compile is if we pass show next the correct data, something that fits the type definition user. So that's a number one promise of typed FB. So I want to take this opportunity to try to impress upon you the important distinction between compile time error and runtime error. This is supposed to be a JavaScript program. It won't even execute because there is a syntax error in the second line. The first line is perfectly fine. But if you run this code, it won't print that log message. It's because the parser, the JS parser parses it and figures that it's an invalid program. This is the error that I got when I tried to run this. Now this is a good kind of error because we get to know that this program is wrong very early in the programming cycle. But imagine if this program was executed despite the syntax error. You'll ship it to customers and they'll be in the middle of something, but then it breaks because you missed a parent somewhere. But that doesn't happen. When was the last time any of us lost our sleep because we worried whether we had shipped us syntax error in our code? That's not a concern anymore for us. Now the genius of reason and typed functional programming is that a lot of common mistakes sort of become like syntax errors. Because a compiler can catch most mistakes that we usually make in our programs. So here is the JavaScript program that we just wrote. This is the same JS code. We are passing in an undefined to show next because the list of users is empty. And it crashes during execution during runtime. In reason, however, this sort of error becomes a syntax error. Something that is caught during compile time. This is a reason equivalent of the same program. This won't even execute. Instead, we'll get this compile time error. What is it saying in line 12? We are calling show next and we are passing it last user and show next expect something of the type user. But the compiler is complaining that last user has a type option of a. What's happening here is that in line 11, we have tried fetching a user from the list of users. But the compiler knows that every time you fetch something from a list, it is quite possible that it does not exist. So it sets the type for last user as option of user, which means that the user can or cannot exist during runtime. So how would we write this code? We will replace line number 12 show next with the code at the bottom. They want to handle both cases where if there is a user, we will call show next with that. If there is no user, we will handle that gracefully. So option types are one of the most amazing things that I found when I started learning type. It gave me the kind of confidence that allowed me to write code the way I see fit and then refactor that aggressively and mercilessly. Because of this, a lot of my anxiety went away because I knew that if it compiles, it works. But what about logical mistakes you might ask? What if someone asks for a cup of tea and we put them coffee? This kind of programs will not be caught during compile time. There is no type error here. This is a logical error. There's no way a compiler like reason can catch it. But the interesting thing is that after years of programming and dynamically type languages, I realize that programmers are a pretty decent bunch. It's comparatively rare for us to make logical mistakes compared to clerical mistakes. Our programs are all broken. Make no mistake. But it's because it's not because you're passing something when we meant the other. It's broken because you're passing the wrong kind of data to the wrong kind of function. The reason compiler, the hover is very good at catching those kind of mistakes, which is why type functional programming languages like to claim that if it compiles, it works. So far, so good. When we say that reason can only deal with well typed data. How can it work with external data? So for example, you might have content that we read from the database. Sometimes it comes from JSON API response. Sometimes user input. We handle that in reason by passing all this data at the boundary of the application. If, for example, we are expecting something for a newer API version and we are getting something of an older API version, right? There's no way our program can handle it. So at the boundary of the system, we reject it and we send an HTTP code back. Or if the incoming data is incomplete, it might be possible for us to give a placeholder value. And then it can slot into our types correctly. So that's also fine. The point is we cannot allow malformed data into the system. Either we handle it or we reject it then and there. But if there are no issues, then we can parse it. We can sort into our types and then it hits our application code. Here we can write code with absolute confidence that there are going to be no nulls. All the functions will get exactly the same data that they expect. And all the objects will have the right shapes. So what I covered so far in this talk is a very thin slice of what type functional programming gives you. For example, we haven't looked at functional programming at all. I think that most of us who write JS already do a fair amount of FP. But reason adds a couple more things that makes functional programming a little better. Some of them are listed here and they're all worth looking at. Some other ideas, these are from types. So these are also extremely fun. The moment you have them in your code, you can write code with a lot more confidence than we're used to. And these ideas are from the book, Real World OCaml. And all these ideas are worth looking at. And you can sort of understand some of them by reading blogs and watching talks on YouTube. But the best way to learn is to actually try out reason, and experience them for yourself. And if you have to do that, how do you go about that? So that's what we'll talk about next. If you have to give reason a shot, what's the best way to learn it? First, let's see what concepts you can take away from JavaScript to reason. Except for types, reason is a much smaller language than JS. If you have been to any JS interview, you might have been asked or been asked so many difficult questions about prototype inheritance, about this, about mutation, about objects. Compared to that, a reason interview is going to be very, very simple because it's a much smaller language and the surface it is quite tiny. So what is the fastest way to learn reason? The best way is to start building a UI with recent react. So there's a recent react component that just simply has a button which says hello. And that approach will sort of go a long way. You can sort of poke your way through learning reason, but it doesn't scale forever. It's because to try to build something real with reason and you hit a roadblock, you wouldn't even know what to Google for. That's one of the problems with trying to learn a type function language. Initially, you have to go through the catalog of language features without looking for immediate application. The first phase is to learn to program in the small. You should be able to sort of FizzBus, make an AP request, compute the average of a list of numbers, things like that. And the concepts you need are quite standard whenever you are learning any new language. So you need variables and researchers and creating and applying functions, stuff like that. Now you should comb through the recent home page to understand this concept. These are written for a JS audience. They're very accessible. Next, you need to get comfortable with the tooling. You should be able to create a project and start tinkering with it on demand. And that's very important because if you want to do something, the difference between wishing to do something versus being able to do that is to set the tooling right. And in recent years, the tooling is very easy to set up. It's just four lines of NPM run webpack and you're good to go. The third thing to know is to how to program in the large. So if you have ever learned a library or a framework and you're not very confident on how to use in a production project, it's usually because you don't know how to fit that into a larger canvas. Modules are the construct that recently uses to create large blocks of code and connect them to each other. And modules are very similar to JS modules. You have got a bunch of functions and you can expose certain functions and not expose the others. And I want to stress this point when learning type functional programming, you should combine learning by poking, trying to create something practical plus learning the basics from the ground up. And the best way to do that is with the real world OCaml. It's mostly written in the OCaml syntax, but you can sort of get over very, very quickly. Now the last elephant in the room is recent commercially viable. It's just something that you can use in your workplace. So my experience is obviously being real, which is why I'm giving this talk. And I think it's very ready for production. And Facebook is already ported about 50% of their messenger application into recent. And if you visit the recent homepage, you can see a lot of companies actively trying to use it, the big and small ones. But Facebook is very far away. There is a project that is very closer to home. It's called pupil first. This is a learning management solution. You can create courses, teach students and track their progress. The entire front end is written in recent and recent react. It has a complex data model and very advanced web patterns. It is built here in Bangalore. And it's fully open source. So one of the authors, Hari is here and he had spoken last year's about recent itself. And it's a very good repository as a reference. If you want to build production applications with recent, it uses graphql and reels and has a lot of good patterns that you can pick up. So that was that talk learning to learn recent. Thank you so much.