 So, I'm here to give a talk, share my experience about working on Elixir and what I find people go wrong when they program Elixir, mostly when they come from some OOP-oriented languages. So, about me, my name is Nikhil More and I am presently working for Volances and I am presently staying in Ahmedabad. So, I am on Twitter as Nikhil Arias, Google as Nikhil More 54. Also, I am an active member of Pune Elixir and Erlang Group. We have a few members from the group present right over here. It is one of the most active community in India for Erlang and Elixir. So, let's start with FP versus OOP. We have a lot of debate that is always going on if FP is better or OOP is better. But really in my sense what I feel is OOP and FP are just two coins, two sides of the same coin. So, in my experience or to put in a simpler way, OOP and FP are two different tools and these two different tools are used to perform different tasks. So, it's like say you can't use a needle to cut a stack of hay, something like that. So, you have to select OOP or FP depending upon your own needs and requirements and the case as per it is. So, when we learned about OOP, we came across various characteristics. Some of these characteristics are OOP has class. Classes, when they are instantiated become objects. Classes have the following features. They have encapsulation. They have inheritance, polymorphism, abstraction. We did this in Java C++. So, when we try to compare FP with OOP or when we migrate from OOP to Elixir specifically, we have a notion in mind that modules are very much closely analogous to classes, but it's not. We seem to compare these two because they are collection of data, but they change mostly in one thing that in classes data is mostly private and you can access these private members only through public methods. But in modules, the data is not private. You can directly access the data and you don't need any specific setter methods or getter methods or any other methods to access or modify any of this data instances. So, modules are not classes. Then when we are working in FP, when we are working in Elixir, there are no objects created. We don't call objects to throw any methods. So, if we have a student, we don't initiate the student with student 1 and then call its get or set function by student 1.get in Elixir. The method over here does not bind to the data objects in Elixir or in any FP language. So, the functions are not bound to any class. So, you don't need to actually have to be in that class or in that environment where the class is instantiated and call it through that object. So, functions are not bound to any class. You can call a function that is in any module that is available in the environment and modules are not inheritable as classes are inherited by the children. So, as I have just spoken about the methods, the methods are not really called with reference to any object. They can be called by module.function and passing the parameters. And the code and functions in FP are detached. They are not tightly bound to each other. So, when we talk about functions in function in FP in Elixir, everything is immutable. When we create variables over here, the term variable is actually confusing in FP paradigm because they are not actually variables. They are sort of what we can say constants in Java. So, once you initiate a variable, it cannot be reassigned, the value. The value of a variable is not reassigned or overwritten. You in Erlang actually a new variable is a new memory space is allotted to the variable with the new value. The functions are idempotent and they always return the same value. So, here idempotency means that given a set of inputs to a function, they will always return the same value even if you try the function any number of times. And functions show referential transparency. So, each function will return a value and if we replace the value that is written by this function somewhere else where the function is used, it will always give the same results as if the function was executed in that place. So, now moving to object oriented and FP comparison, here I am taking an example of a simple account and with just a method to deposit some amount into that account. So, this would be something that can be a Java code for this account code, account class. So, we have a private integer account number. We create a private account balance for the account and we have show method and deposit method. We put our validation over there if the account goes down when we, sorry, if the deposit amount is greater than zero, is it positive or not and we add the balance and return it. And this balance is updated into the class. So, what we can see over here is that account balance is directly accessed through the deposit method and it updates this value within the body itself of the function. There is nothing written over here. The effect of this deposit function is that it actually accesses the memory location and overrides the value of account, account balance. So, everything is within the code. So, the class encapsulates the members, data members and the methods. So, when we convert this code into LXR code, we would do something like this. We would destruct with account number and say I have set the account balance to zero initially and then we have a function to deposit the account number. The same process goes over here. This is just a one-to-one mapping from Java code to LXR code. But what I would do is I would just put a check over here so that the type of account, the type structure account pattern matches with the account number so this data structure can be updated. If this data structure is not of the account type, it won't be updated over there. It would throw an exception. So, now we are moving to the next point that is inheritance. We have a separate class called saving accounts and we have a checking account. Both these have the same body, the same structure as the accounts. So, for inheritance, here is the checking account. Everything is the same. Just the class name changes. So, in Java, we create a super class account and then we try to create the children classes using saving account that extends this account and checking account also extends this account. So, this would be somewhat if we try to map one-to-one to LXR code. This would be saving account structure. A similar structure would be for checking accounts but here I try to reuse the code because in both the modules for saving accounts and checking accounts, we have the same function that would be repeated twice. So, I take this common function outside into a helper function and I can use this function anywhere in the code. So, it is not just for this account but I can have this deposit account for something else also. Now, due to lack of time, I have tried to compress the ideas of polymorphism and abstraction together into one but it would be a quick one. So, here it is polymorphism. We have class account that we have defined earlier. We also have saving account and checking account but now we have added a new class that is overdraft account but overdraft account has a separate function deposit for the deposit. The method in overdraft account is a bit different because when we deposit into this overdraft account, it would actually calculate the interest part and it would deposit the remaining principal part into the overdraft account. So, the java code would be something like this. It would show us we would have a separate deposit method that would overwrite the original deposit method that was in the account class. So, here we are having the same savings account and the same checking account. The depth module for an OD account is created over here and we would easily pattern match if the account is overdraft account, we would try a different method set of function to calculate the overdraft account deposit and we can actually utilize this pattern matching to overcome the to overwrite the already existing function because the parameter type for account is different. So, while we write a program in elixir, some points to be kept in mind is code dry and not wet. So, I usually try to separate out the reusable components into a separate class and use it as much as possible because when we write redundant code, what happens is that we may change when the business logic changes, we may change the code at one part and we may miss out some of the other codes due to oversight or maybe because we don't know because it was coded by somebody else. Then second part is I try to always split the task into smaller functions. By smaller functions, I mean functions that are complete by itself. So, it does not mean that smaller means you have to break it down into smaller functions, but a function that can sufficiently describe a proper method should be going over here. You should name your functions descriptively. So, the function should speak out for itself. The function name should speak out for itself. If we have a feature for pipes in elixir, try to use it at maximum and you should document your code very well even though your functions are descriptive, but there might be some places where documentation and comments are required. So, your code should have this comment. If you have any questions, I think this was just for a basic overview. I hope I have tried to communicate very well about my thoughts to you. If you have any questions. Well, are there any questions for Nikhil? No questions? I actually had a question. Yes. Okay. What's your experience with the like the IDs and stuff like from Java is a pretty decent set of tooling like IntelliJ is pretty fully functional. There's a lot of stuff built into the IDs. I mean, I know it's not really relevant to your talk, but something that was curious about. I worked with Java on Eclipse. How is the tooling in elixir? Tooling, you can have add-ons in sublime or VS code. They are pretty much good because you don't have to add everything that is there into your ID. You can selectively add as what you want and you can compare and you can just use it. So, basically sublime goes well and VS code also goes well. Thanks. That's all. Any other questions? Thanks, everyone. Can we have a round of applause for Nikhil, please?