what can go wrong in context of functional programming if my object is mutable?

what can go wrong in context of functional programming if my object is mutable?

I can see the benefits of mutable vs immutable objects like immutable objects take away lot of hard to troubleshoot issues in multi threaded programming due to shared and writeable state. On the contrary, mutable objects help to deal with identity of object rather than creating new copy every time and thus also improve performance and memory usage especially for larger objects. One thing I am trying to understand is what can go wrong in having mutable objects in context of functional programming. Like one of points told to me is that the result of calling functions in different order is not deterministic. I am looking for real concrete example where it is very apparent what can go wrong using mutable object in function programming. Basically if it is bad, it is bad irrespective of OO or functional programming paradigm, right I believe below my own statement itself answers this question. But still I need some example so that I can feel it more naturally. OO helps to manage dependency and write easier and maintainable program with the aid of tools like encapsulation, polymorphism etc. Functional programming also have same motive of promoting maintainable code but by using style which eliminates the need for using OO tools and techniques - one of which I believe is by minimizing side effects, pure function etc.

The key to understanding why immutable objects are beneficial doesnt really lie in trying to find concrete examples in functional code. Since most functional code is written using functional languages, and most functional languages are immutable by default, the very nature of the paradigm is designed to avoid what you are looking for, from happening. The key thing to ask is, what is that benefit of immutability The answer is, it avoids complexity. Say we have two variables, x and y. Both start with the value of 1. y though doubles every 13 seconds. What will the value of each of them be in 20 days time x will be 1. Thats easy. It would take effort though to work out y as its way more complex. What time of day in 20 days time Do I have to take daylight saving into account The complexity of y versus x is just so much more. And this occurs in real code too. Every time you add a mutating value to the mix, that becomes another complex value for you to hold and calculate in your head, or on paper, when trying to write, read or debug the code. The more complexity, the greater the chance of you making a mistake and introducing a bug. The code is hard to write; hard to read; hard to debug: the code is hard to get right. Mutability isnt bad though. A program with zero mutability can have no outcome, which is pretty useless. Even if the mutability is to write a result to screen, disk or whatever, it needs to be there. What is bad is needless complexity. One of the simplest ways to reduce complexity is to make things immutable by default and only make them mutable when needed, due to performance or functional reasons.

Комментарии

Популярные сообщения из этого блога

Как преобразовать вертикальную запись в горизонтальную?

Skipping acquire of configured file 'contrib/binary-i386/Packages' as repository … doesn't support architecture 'i386'

How to delete a folder in remote Windows from Linux