 I'm here with Ram Nalo, GS, and I'm going to cover some basic functional programming theories as well. And so just some fun facts. I'm John, and I'm a founder and engineer in DOS. We are a digital wealth solution platform, and you've probably heard many others, but so we are another, and we are doing some wealth management stuff. Enable you to access world-class shared fund house with a fractional cost. And our fund and the stack is highly relying on functional programming, and we don't have low-dash dependency, we don't have a lot of imperative stuff, especially our selectors and also the reducers. You know, because of the nature of React and Redux, the unidirectional way of flowing your data and the way that Redux handle the events using the event-solving pattern, so we think functional programming fitted very well with the reducers and the selectors. So I'm going to cover those and give you some code snippets as examples. Sorry, my clicker is not working. Okay, great. So what is functional programming? So it's just a programming paradigm mapped from a lot of mathematical functions. So a lot of people are making the jokes that how to learn functional programming, they will say, oh, just to get a PhD of computer science or PhD of mathematics, then you'll know functional programming, which is not necessarily true. And so today I'm going to try to sell some of my two cents about why functional programming could be something you should look into that. And so functional programming is more about being declarative, expressive. You don't care about how to achieve something. You'll care more about how are you going to transform the data and what are you going to do with this stuff. So, you know, if you have written Java, like some other object-oriented stuff, like those procedural programming, it's more focused on, I get specs from the product manager and look into my code base. How can I tweak my code to achieve this goal? But with the functional programming, you'll care more about being declarative. You'll care about the reuse of your functions. And the function is the first-class citizen in this paradigm. So this is just a snippet of one of the earlier joiner of our team. And one day he just opened the code base for the first time, and he read the code. He's like, wow, this is really cool. Everything seems very elegant. So if in the traditional way of handling track catch, you'll probably spend a lot of lines just to draw the track block. But after that, you can actually, you have to have a catch block. Then you have a final block or something else to get the error code from the object. So with the functional programming stuff, you can just basically do it with this way. So you'll track catch, you'll try to parse the JSON or some string to JSON object. If it doesn't work, you give a default value, which is an empty object. And after that, you pass that value to this function. It takes out the error code from that object. So it works just like that. And it's like writing an article. It's very expressive. So the first thing I want to share about the functional program is purity. So pure is very important when you're writing a function in the functional programming paradigm. What is pure? It basically means when you give the same input, it always generates the same output without producing any set effects. So it's just like a mass function. So I'll give you some really simple example. You have a function that is at. It takes in two parameters, a and b. And you just sum them together and return that. So if you evaluate them for two times with the same arguments, you're going to get the same output. So this is pure because it doesn't modify anything that is shared. It always gives you the same output. The huge benefit of that is that you can easily do memorize. You can easily do testing on top of that because it's pure. So the next example, I'm going to show you what is impure. So this function declared with a Latin syntax is a mutable. And we'll assign a primitive number one to it. And in your incremental function, you actually take out a parameter n and you just sum a and n, return that. But meanwhile, you do the plus equals so your a is mutated. You are modifying a shared state out of your function scope. So if you evaluate incremental function with the same parameter for two times, you generate a different output, two and three. So this is impure. We should try to avoid that when you are writing some functional stuff. But it's very difficult in practice, actually. So another two examples using the built-in array functions. So slash is actually a pure function because this code actually takes out the first element from the array one, two, three. And it returns you a new element that is inside an array. So it doesn't modify the original array. But if we look at the impure function, which is splice, we seldomly use that, but actually it's one of our interview questions. So splice basically takes out the first element and it returns you the first element. But meanwhile, it modifies the original array. So your original array becomes two and three instead of one, two, three. So it's modifying something outside of the functions control. So that's why it's impure. And another good example is master random. You don't pass any parameters, but if you call it two times, it gives you two different outputs. So it's unpredictable. So that's why it's impure. And maybe it sounds something from Mars. I don't know, but actually if you are writing React, you are dealing with a lot of pure stuff every day, especially in your reducer. When you try to mutate a Redux Store, you're not going to mutate the original Redux Store. What you're going to do is you copy that entire thing and you plug the new thing and return it as a new stuff. So this is a popular example from Redux official documents. So when you add a to-do in your reducer, instead of calling state.push to add a new to-do object into the array, you're actually using a spread operator to copy the entire state into a new array and you put the new to-do at the last position of this array. So basically you are doing something pure. Because the nature of Redux is more like an event-solving pattern, you don't care about what's the current value of that. You care more about what are the events that is modifying my store. So because of the functional purity stuff, it's more easy for you to predict the next value, next snapshot of your store. That's why Redux is just doing like this. And the next thing is set effects. So what are the set effects? So just now we talked about if you modify something that is shared out of your functions control, that is definitely a set effect. So some other set effects are real programming life, like you'll read a file from the system and you'll write that, that is a set effect. Or you call a remote API to modify something, that is a set effect. And also if your function is calling a function that has set effects, then your function also has set effects. So I'm not saying that having set effects is something wrong. It's just something you should try to avoid that when you write your pure function or functional stuff. There are many different ways to manage your set effects, your functional stuff. Like you can use Monad in Haskell, you can use Saga in Redux, you can use Reactive.js, which is observable to manage all the set effects. So what I'm saying is that using set effects is nothing wrong, it's not forbidden. It's just that you have to be careful when you are writing functional programming about that. And so just now we talked about the purity. Same input, same output, and no set effects. So this one is another important thing, it's called a curring. So curring basically means you transform a series of arguments into a chain of functions that each function takes one single argument. So you keep accumulating all the arguments until you get enough arguments to generate the output. Then you return the evaluation of that. So don't worry, it sounds really alien sometimes, but I'm using some example. So add is actually a function, the same add function as we talked about just now. So instead of picking two arguments and sum them together, we actually write a function that takes one argument A and returns a function that takes in another argument B. And after we get both A and B, we return A plus B. So the benefit of using that is you can do partial application. It's going to make your function more reusable. So for example, you have a very generic add function. It can add any numbers. But what if you want to do add one, which is increment. So you just declare partially you just partially apply that to the add function. You do add bracket one. And the next time we will call increment, it always add one into the second argument. So it's the equivalent version of calling this add bracket one, bracket two. That's current. So you may be wondering why I should bother about current when I write a function. So because current enables you to write a lot of point-free style code. So in Wikipedia it's called Taxis Programming, I think. So I'm going to show you some code snippet that is doing point-free. So this is a water function. It takes in a parameter. And the count is a function from Rambda. You can think it as a switch condition stuff. So it actually takes in a parameter and pass it to the first predictor, which is equals zero. So you basically typify that whether this parameter pass into water function equals zero. If it's truthy, then you return water freeze at a zero central degree. Then if it's not zero, you actually pass to the parameter to the argument to the second one, which check if it's equals to 100. If it's equals to 100, you return water boils at 100 center degree. And the last one is a placeholder from Rambda. It's a cap T. It means regardless of what you are passing to me, I always return truth. So this is like a default statement in a switch block. So this means if it's not zero or 100, I just use the string template to print that value. And the same for the second one. It's eligible to vote. You're taking a parameter H and you pass it to its over 18 then it both of them satisfy satisfy your predictor, you return true. So if you don't use curry, you are going to write it in this verbose way. So you're basically just stupidly passing the same value to the second position of the argument. Yeah, just like that. So you are repeating yourself many times, but it doesn't help much. So that's why this is called a point freestyle where curry can help. When your code base grows larger and larger, you'll find out if you use point freestyle, your code base is going to be cleaner and more readable. Of course, the downside is that if a person doesn't have enough functional programming experiences, he could get lost because he will look at this code and see, oh, this looks like a good article. It's really expressive. It's very clean. However, where are we passing the arguments? I don't know. I didn't see anything. I didn't see arrow function. So basically, that's a currying. Yeah, maybe you are still feeling lost if you don't have experience in curry, but just spend one or two hours reading some ramda documents or YouTube videos talking about a curry. You'll find that it's nothing. It's just some mathematical stuff to make your code looks better. Okay, so this is an example from our production code. So before we apply functional stuff, you can see we use switch block. Basically, it takes in a risk tolerance and we turn some properties for our front-end. And yeah, this is quite long. I didn't count how many lines are that. But if you look at the functional way of rewriting that, so we just call it derives that properties from risk tolerance and we are even using memorize for that. Why? Because we are writing pure function. We are confident that, given the same argument, it will generate the same output. So you can use... you can sacrifice some memory space to increase your evaluation speed. One common interview question being asked in those companies are like, write a program to generate the Fibonacci numbers. So if you use this pure function stuff to evaluate that, you can just wrap it with a memorize stuff. So it can reduce time complexity because you memorize the arguments. If you hit the same arguments, you don't bother to evaluate the logic. You just return whatever is stored in the memory. Okay, so the next... the last concept about functional programming I want to talk about is function compensation. This is a key thing in function... function programming. So function compensation, basically means you are applying a series of function and the second function, the latter function always takes return from the previous function. So basically you are changing the evaluation of that. And if you write it in a priorative way, which is at the left-hand side, if you are a Java developer or Python, you'll probably see this many times. You actually pass the X to a method F and you get the results, you pass it to method G and you pass the result to method H. So you nest a lot of brackets. And with a functional way, they compose. Because compose in math is from right to left. So you read that function from right to left. It means, oh, I evaluate X with F. I get the return and I pass it to function G. And I get the return I pass it to function H. As you can see, it's easier to read. The first thing, the second thing, you focus more on implementing your data transformation functions instead of how you achieve your goal in a priorative way. There's a key difference between functional programming and procedure or say, in priorative programming. So I'm going to give you an example of compensation. So you'll get a function F. Actually, it's a brush, something to blue. And you'll get another function G, return, wealth, miss. And you apply that function. You actually get a lot of things. Maybe you haven't watched that movie, but I haven't watched it as well. I just get this picture from Reddit. So, yeah. So this is actually a function compensation. And if you write it in program, it's just simple like this. So you have a compose from red to left. And to Aladdin function is compose F and G. So you're just called to Aladdin. You pass a person to that. Then you become Aladdin. That's it. So you hear more about how to transform that. And, yeah, some people may being picky here. They are doing it anti-human because why I have to read it from red to left. It's fine. You can use PEP from left to right. But if you want to look looks like more elegant, you just do compose. Just to pretend you are really good at functional programming, just use compose. So some more examples in our production code. This is from our selectors. So if you are familiar with selectors, it makes you a state and it generates some values you can use in your components. So, yeah, I have nothing to explain here but it's just expressive. The code tell what it does by itself. So one benefit is that, for example, for this snap it, maybe a little bit too small. I actually don't know how to zoom, sorry. So, yeah, so basically I get this portfolio self-selected. You have get a portfolio ID. So if you look at the compose, both of them share the function called get investment plan. So that's the beauty of functional programming. You tend to make your code more reusable. And when you compose that, it works like magic. It works like you plug all the pipeline together. You just bring in the water. It somehow just flows to the end of your pipe. You don't care what's going on in the middle. Yeah, so that's all about functional programming. The last awkward thing I want to talk about is functor. You may feel why I bother with the functor because it sounds like another area to me. But the functor basically means so the simple definition of functor is that something you actually have an object has a map method. That's a simple way. It's not always correct. So the better answer is the functor actually is an object based on functor laws. So the two laws are identity law and associativity law. So I'm going to give you two really simple code example to demonstrate what they are. This sounds fancy, but they are really simple. They are created by some mathematic PhD to try to scare our like me, like average person, but actually it's not difficult. So identity law, it means that you have an array of elements and you have a map method. So you just return itself in your map function. If it generates the same thing as your original array, for example it means this base identity law. Basically it means your map doesn't do anything magically. So this is identity law. Just apply the map function to return itself. The second law is associativity. So associativity means for example here we have a function f it takes in x and plus 2 and the function g takes x and the function f multiplied by 2 and the function g plus 2. So you just do this. You have the something you want to evaluate if it's functor. You just call the map function of that and apply g and then you call the map f. So basically in this case you basically plus 2 here which you get 4 and you map it by multiply 2 so you get 8 which is this one. And if you look at the right side instead of changing the map of itself you just do it in one map by composing all the functions. So if you get the same output which is the same output here basically you compose g first so g means plus 2 you get 4 and then you compose f so you get 4 multiplied by 2 is 8. So you the left and the right of your strictly equal sign are actually the same. This is associative law. So array in javascript is definitely a functor. Some people say promise is also a functor because you can change dozen but strictly speaking it's not really a functor. You can search on google there are explanations about that. And the last I'm going to show you something really fancy this is something I have never seen before until I worked on an open source project about blockchain. It's one of the biggest blockchain wallets in the world so their codebase is entirely in javascript but they are doing a lot of hot-cold stuff in the javascript. That's amazing. So this is something I learned from their codebase they use a class called a tagged union I'm not from a mathematical background or a computer science so I have never really learned this concept before but after learning their codebase I found it's really amazing. So basically tagged union someone call it disjoint union or some types so it basically means you have something you can declare different types in an object so it's not like a java java if you define class that class itself is a type. So in this way in tagged union you can have an object that object can contain different categories, different types when you use that object you can only use one type of it. So I'm going to talk about why this is really amazing so in your UI design for example if you are calling an API you tend to design four states if your designer is good so you have an initial state you have a loading state you have a success state you have an arrow state so this is an actual design of our product so we have in our reset password flow after user clicks the reset email a reset password link in the email the React app is actually at the initial state so the component will trigger the action to verify the one-time URL because you want to make sure it's safe it's not expired, right? so you call an API basically when you are calling the API it's loading and if the API say oh this URL this reset password token is not expired it's still valid you show this success page to enable users to set his new password otherwise you show a failure the viral message say oh your token may have expired or something so this entire process is an asynchronous API call and to use tagged union or some time to solve this problem we are using a library called daggy so there is a function called tagged sum you can declare something just with these four types inside the object not ask loading failure success that's it so how does it work with the React Redux? for the user you have a not ask the function mapped to an action and when it's invoked it actually set mutates the value of this remote object to not ask so for example when your component is rendering you just set it to not ask because you are not calling API you haven't called the API and then if it's loading you just set remote.loading if it's success you just call it and if it's failure you pass remote.failure with that that's it in the reducer and we are using SAGA to manage our set effects so I'm showing a code snippet of SAGA so this one we get a reset password talking from action payload and we call the loading function loading action so the loading action will flow to reducer and it will call this one the loading so it will set to remote.loading and if the API returns success 200 you basically put a success action and bypass the response into this action so it flows to this method this block in your reducer you basically set the remember we talked about that this is an object that can have different types so success is one of the type you basically setting the type of that value and if there is something that you know expected happen you just set it failure to this code block in your reducer you set it to failure then you are going to come back to this UI design so after you get all this how are you going to use that to render the code so it's just as simple as this you use a selector to get the remote object and you call this category function category theory is another big stuff in functional programming I'm not expert so I will not talk about it but basically you call this category function you say oh if this remote object this type class if it's success category I render password form if it's not asked I show a loader if it's loading I also show a loader if it failed I show an error message so this force data is actually mapped to this react design this design for the react it works just seamlessly like that so our API costs are actually relying on this remote object and you can even change that you can change that to make it look like a monad so you can change that your render function say if verifying reset password is success you actually render set password form in your render password form you can make it as a category so if you haven't after you successfully verified your reset password token you render this and before users start setting the new password you actually render this one this is the reset password form you were saying just now and if user clicks set my new password it will just show a loader if it failed it will show an error component if success it will show a success component so you can change this stuff your designer may like this workflow design all the time but for developers if you don't use this kind of category type to implement that you'll probably end up with a lot of switch keys if else check if this status is that I render this but with this remote object that we are doing here today you can easily do this category or conditional rendering easily because all your design basically just follow these four states that's worked very well with tagged union so if you search on Wikipedia there is another type called the product types that is something else but if you are interested you can just do it by yourself so one of the last thing is so I didn't really touch a lot of ramda but in the code snippet actually all the functions are from ramda most of them I actually like to use the productivity tool when I implement ramda so I'm an off-red guy sorry this is not clear and this is just the off-red so if you want to search for a ramda function that you know the function name but you don't know the exact arguments you just say ramda what is win function so it tells you oh it's a test final argument by passing into given predict function blah blah if you hit enter it will just open the documents of that it's really my work body in everyday coding life and I mean if you want to do something fancy you can even say oh I don't know the exact name of this function but I want something taking an array and it gives me another array am I doing any typo here yeah so you can say I want an array it gives me another array so it actually show you all the functions to kind of achieve the function signature you are asking for this is really cool and I love off-red I'm a paid user so I think that's all yeah with that end of my meetup session so any questions I'm not an FP expert but I will try my best yeah please hmm hmm hmm hmm hmm hmm hmm right right so actually that's a really good example sorry good good good comment good question so we did face some challenge but we were having three frontend developers and we are getting one more one guy left so all of them so far actually are enjoying a lot of learning functional programming I think because of nature functional programming is more it's actually enforcing you to think more when you are writing program so people really enjoy that but to business people they are like oh why you are if they don't know what is functional problem they may be like oh why you are rewriting your code into functional stuff what is a business value of doing that so that part I would say is more challenging than asking your developers to do functional programming because usually your developers will be like oh this is something new really cool I will learn that by myself but for business guys they are like don't bother do that just deliver what you want our customer will be happy so that's actually a challenging part but if you really want to know how to handle that I think hiring the right people is very important if you hire someone that is really lazy he doesn't want to do anything new it's never going to happen if you ask him to learn what is curry what is composition that's impossible I think that will probably be my answer but learning functional stuff is really interesting I enjoy myself of doing that a lot and I have seen our team members enjoying doing it a lot so they really change a lot of code into functional way by themselves sorry yeah definitely yeah thank you yeah thank you okay any other questions okay I think yeah thank you