 I'm Ranjeet Singh and today I'm going to talk about is Immutability Matters. So I'm a junior in GINA at C42 and this is my first job actually after Cadmix. So the first thing we learned over there was immutability. So immutability, I had been writing like imperative code for past five to six years since after high school and immutability was the first concept which they introduced me to and immutability. They told me that, what immutability actually matters and where should we use it? Immutability, what it means is when you define an object or when you define, when you declare an object, its state shouldn't change and this what defines immutability for an object. This can be implemented in any language. It's not specific to Ruby or any other language like Java. So immutability, your code is actually full of immutability and you have to make it explicit and your code is going to have like, your code is going to have constraints and those constraints are immutable. Like Mike Farley has already told about that. Okay, your code is full of immutability and declaring all these immutable objects is really hard because writing immutable code is really hard unless you are doing, you are paired up with somebody who already has some experience with the pattern or with the convention around immutability. So recently we did a POC for a company and we found out that Ruby strings are immutable. So I'm being new to Ruby, so I did this noob mistake. So here's a function which is taking a path which is the original path and the other path it is appending the other path to the original function by using a shovel operator. And so I just created a user path and a guest path. So what happened to my route? All of a sudden I have a route which is kind of a path right now and what happened to my home and my home is also being changed over here. So we fixed this piece of code by applying a freeze to our string constant and using a plus congetination operator. Yeah, this is good enough. So another code review and a piece of modifications to our code. So another, which is Ruby replacement for congetination. It just uses string interpolation over here. So this is considered to be a good production code right now. Now another thing which I was introduced for us, Ice9, which has a deep freeze operation. So deep freeze with Ice9. What it does is suppose we have a lot of business constraints and we have an interest stable. All of a sudden we have two threads which are one is calculating loan and other one is calculating something different which is a cost price for any other future and diverse companies having. So how do we control all these interest rates for a current instant of our system? One way of doing that is to apply deep freeze. This is another implementation for deep freeze. We can directly apply it to this one and there's needed to be one more requirement which is needed to be added with Ice9 and an extension to an object. So immutability. It is actually based off three different principles applied together to build your value objects. So the first concept which we came around was constructability. Constructability is the first principle which came around 1950s to 1960s and this concept was introduced in mathematics. Later on this whole concept was moved to programming and other object oriented principles. So since Michael Alperi has defined constructability as you in object graph, whenever you are adding another object that object shouldn't have dependency on any other object which is already which is not being added to the object graph yet or you don't have dependencies or which is not ready yet right now. And here's one declaration for it. How do we define a node for a graph? A graph has a value and a couple of edges. These edges should be immutable and you can just pass in over there. You shouldn't have a setter or any other function which is mutating these edges and this is how you implement a node. This node can be our object, can be our email system or a person. Person data can be also defined like that. You could have name and his email address and his business address and all the other fields. Being only described inside a constructor. Constructors are hard to define because as soon as your system will increase, all these enterprise systems have already really big constructor. Oracle guideline is to use a constructor which only has close to seven fields and we try to constrain this thing. So this is why we introduce abstractions and different classes are introduced. So if you have address which contains more than eight to nine fields, then we combine a couple of phone numbers and combine a couple of addresses to a single address and then we pass on to a constructor. This thing looks like a CS101 course but yeah, it is hard to do in a bigger system. And second is equality. This concept had been around for a while but Henry G Baker or Henry Baker had introduced it correctly from functional to imperative to any other programming paradigm where our object can be defined by its value. An object which, this is one way of doing it in Ruby, where you have an object, self. I want to compare it with other self and first thing I wanna try is, okay, do you belong to my class or are you of my type? And second thing I wanna ask is, are you me? So these two principles are very much extracted from mathematical principle which is reflexive and transitive or same type system since we have principles with type systems that defines that, okay, if one type is of another type, then it is important that these two types are needed to have the same behavior or the same type of relationship with each other. Self thought value, this is the third kind of comparison over here. This one is a third kind of comparison where we are checking for values and since we had already overrided the equals operator, we also wanna overwrite EQL and hash for our hash maps or our maps to work appropriately. So the third principle which is single responsibility principle, SRB, this is important over here is because most of the problem we get in designing and immutable classes, we do declare too many fields to it. This is so simple, but it has become the major pain to a lot of code bases, a lot of Java. So I belong to a Java code base background. So a lot of Java code bases are designed around that. Even Java allow you to declare a public constructed by default. So this is kind of a big problem right now and it's hard to do, we need to consult principal engineers to ask for, okay, our classes, whatever classes we had defined, are they good enough or are they not? So responsibility comes into play. These three principles will help you to design a immutable object, but another pattern or another consulting you can take it from is try to learn about, okay, I'm gonna ask my customer that if this object is really defining a domain, if one person is different from another person, by changing their email address or by changing their some other fee. And this had been my real problem in my past projects that I had to take a personal information from one service to another service and there we had to do matching based of their email addresses. And we only had email addresses to match between these two services. One service was Gira and other service was OpenAir. So this had been around for a while which is imperative shell and functional code or functional code and imperative shell. So functional code is your hardcore domain, which is your hardcore engineer. This is why you hire engineers. Imperative shell is something you designed around, okay, we have designers to decide whether the state will change or not. So using these concepts will improve your code base in terms of code quality. So you're always following the guidelines which are provided to you. Another thing it will provide is code reusability. These two are basic object oriented terms. As soon as you start practicing these, you're gonna get, okay, my code quality is improving. Is my performance is also improving? Your performance is going to drop a little bit for a while, but sooner or later, you're gonna find out that that performance decrease is actually increasing your code base and code maintainability. And it will make your code safer for defects. So what are other benefits? Simple design. Simple design as in a dog is constructed of legs, mouth, and sound whatever he makes. It is not constructed of anything else which is related to some other animal or some other bird. Simple test. You only need to check for equality between two objects that you can do with by overriding the equals operator. Concurrency is the biggest issue out there. When you have two objects shared between two threads, that creates a race condition that if one object is modifying that object and another thread is also modifying that object, then which of the modifications we're gonna take it from there. So concurrency is also there in online transaction processing or software transactional memory which uses various version of objects to handle that problem. In Rails, we can create immutable objects but those are based off another gem which is immutability. And cyclic reference is so, so the major problem with immutability which happens is cyclic references. If one object is referring to another object, then it creates a cyclic reference between those two objects and one object can't exist without the existence of another object. You need to have those two objects to communicate with each other. This is very common. So I already have designed out an example for you which is game of life. So I'll just pick up examples from there. So what are the liabilities around this immutability concern? Is design must be completely substituted to immutability. So since you start using immutable objects, you need to design every other object as immutable objects unless it is an entity. So all of your value objects are needed to be immutable, otherwise the whole pattern is going to cause you problem with, okay, I'm gonna handle another object with another way and I'm gonna handle another object with another pattern. So it is quite common to do and it's the first mistake as a new, as a junior ingenious we make every time. Sometimes it's hard to figure out, okay, what's the correct design? Should I be using a cell with a live and a dead state or should I use a cell with a coordinate? With a coordinate or its location? Another problem we get is immutable data is always slower. It will be slower. So it will be horribly slower if you have bigger systems. But it will help you in terms of maintainability in the sense that later on you can optimize upon the section of system which is slower. You can add constraints to a couple of functions or couple of modules to tell them that, okay, hey, you can mutate data, but hey, you can't. And this thing, and you can also mark those methods as bang or with a bang and Ruby or any other operator. There's always a trade-off. So a lot of libraries are already designed around mutable objects and immutability is hard to get. One of the libraries which is designed by us is RSpec HTTP. It completely uses immutable objects, but it is hard to achieve immutability. It is kind of a holy grail for us also. We had been doing it for a while, but it is hard for us. And to make it work, we try to shrink out the section which are mutable, the mutable section of the program. And deletion is necessary because of caching. If you have immutable data, you keep on caching objects. You keep on caching objects in memory. Or even if you're writing to a database, you keep on creating records for it. And sometimes in the, maybe you wanna delete a history. Same thing which happens with get also. Sometimes we need to delete commits and we need to branch out to some other branch and wanna delete another branch. So what for the next generation? Next generation as we being junior engineers, languages. So I just found out that these languages help you to learn the previous, all the research-based programming patterns. Our language is, yeah, it's hard to learn. You can start with Haskell. There are already online courses on Haskell. You can start over there. Done by the best teacher out there is Eric Meyer. And I think it's on edX. And Clojure is a production-based language. And OCaml, I had seen in more academic side of things than being on a production kind of project. And what are the different gems you can use in your Ruby code? So it doesn't matter that you wanna use a different language to design your functional code. You can easily use Ruby with these gems. These gems will help you to make your code a little bit functional, but not completely functional. So Hamster is a persistent data structure library which provides persistent data structure. So as simple as when I add an element to a list, it will just, it will return me another list. Another is values. Values will help you to create value objects easily. And third one is Ice9, which will decrease your objects. If you have mutable objects, then it will just create immutable objects for you. So these are three books which are helpful in learning these concepts. When it's DDT design, domain-driven design, another one is Pragmatic Programmer and Passionate Programmer. I think I made a spelling mistake over here. So these three books are, I think, a lot of programmers are already read about. And I think it is good to go back to them and learn about more concepts from there. So since preparing this talk, I went through a couple of talks, which is Simplicity Matters by Rich Hickey, Immutability, Immutable Ruby by Michael Farley, and Java Past, Present, and Future, given by Josh Block. So these three talks are actually important talking about software principles. What are the different frameworks you could use? One is Spring and Juice. So I come from Java backgrounds. So Spring is one of the frameworks which implement most of the concepts which are defined in DDT. So it is good to use some framework like that. If you're not using this one for your Rails application or any other application because it is a Java framework, but still you can learn a lot of concepts around Spring and Juice. Juice is a dependency injection framework. It provides dependency injection for your classes. So this was my talk and thank you to y'all.