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

Question

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.

Answer 1

I think the importance is best demonstrated by comparing to an OO approach

eg, say we have an object

Order
{
    string Status {get;set;}
    Purchase()
    {
        this.Status = "Purchased";
    }
}

In the OO paradigm the method is attached to the data, and it makes sense for that data to be mutated by the method.

var order = new Order();
order.Purchase();
Console.WriteLine(order.Status); // "Purchased"

In the Functional Paradigm we define a result in terms of the function. a purchased order IS the result of the purchase function applied to an order. This implies a few things which we need to be sure of

var order = new Order(); //this is a 'new order'
var purchasedOrder = purchase(order); // this is a 'purchased order'
Console.WriteLine(order.Status); // "New" order is still a 'new order'

Would you expect order.Status == "Purchased"?

It also implies that our functions are idempotent. ie. running them twice should produce the same result each time.

var order = new Order(); //new order
var purchasedOrder = purchase(order); //purchased order
var purchasedOrder2 = purchase(order); //another purchased order
var purchasedOrder = purchase(purchasedOrder); //error! cant purchase an order twice

If order was changed by the purchase function, purchasedOrder2 would fail.

By defining things as results of functions it allows us to use those results without actually calculating them. Which in programming terms is deferred execution.

This can be handy in of itself, but once we are unsure about when a function will actually happen AND we are fine about that, we can leverage parallel processing much more than we can in an OO paradigm.

We know that running a function wont affect the results of another function; so we can leave the computer to execute them in any order it chooses, using as many threads as it likes.

If a function mutates its input we have to be much more careful about such things.

Answer 2

The key to understanding why immutable objects are beneficial doesn't 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. That's easy. It would take effort though to work out y as it's 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 isn't 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.

Answer 3

what can go wrong in context of functional programming

The same things which can go wrong in non-functional programming: you can get unwanted, unexpected side effects, which is a well known cause of errors since the invention of scoped programming languages.

IMHO the only real difference on this between functional and non-functional programming is, in non-functional code you will typically expect side-effects, in functional programming, you won't.

Basically if it is bad, it is bad irrespective of OO or functional programming paradigm, right?

Sure - unwanted side effects are a category of bugs, regardless of the paradigm. The opposite is true as well - deliberately used side effects can help to deal with performance issues and are typically necessary for most real-world programs when it comes to I/O and dealing with external systems - also regardless of the paradigm.

Answer 4

I just answered a StackOverflow question that illustrates your question fairly well. The main problem with mutable data structures is their identity is only valid at one exact instant in time, so people tend to cram as much as they can into the small point in the code where they know the identity is constant. In this particular example, it's doing a lot of logging inside a for loop:

for (elem <- rows map (row => s3 map row)) {
  val elem_str = elem.map(_.toString)

  logger.info("verifying the S3 bucket passed from the ctrl table for each App")
  logger.info(s"Checking on App Code: ${elem head}")

  listS3Buckets(elem_str(1), elem_str(2)) match {

    case Some(allBktsInfo) =>
      logger.info(s"App: ${elem_str head} provided the bucket name as: ${elem_str(3)}")
      if (allBktsInfo.exists(x => x.getName == elem_str(3))) {
        logger.info(s"Provided S3 bucket: ${elem_str(3)} exists")
        println(s"s3 ${elem_str(3)} bucket exists")
      } else {
        logger.info(s"WARNING: Provided S3 bucket ${elem_str(3)} doesn't exists")
        logger.info(s"WARNING: Dropping the App: ${elem_str.head} from backup schedule")
        excludeList += elem_str.head // If the bucket is invalid then we exclude from backup
        println(s"s3 bucket ${elem_str(3)} doesn't exists")
    }

    case None =>
      logger.info(s"WARNING: Provided S3 bucket ${elem_str(3)} doesn't exists")
      logger.info(s"WARNING: Dropping the App: ${elem_str.head} from backup schedule")
      excludeList += elem_str.head // If the bucket is invalid then we exclude from backup
}

When you are accustomed to immutability, there is no fear of the data structure changing if you wait too long, so you can do tasks that are logically separate at your leisure, in a much more decoupled way:

val (exists, missing) = rows partition bucketExists
missing foreach {row =>
  logger.info(s"WARNING: Provided S3 bucket ${row("s3_primary_bkt_name")} doesn't exist")
  logger.info(s"WARNING: Dropping the App: ${row("app")} from backup schedule")
}

Answer 5

The advantage of using immutable objects is that if one receives a reference to an object with that will have a certain property when the receiver examines it, and needs to give some other code a reference to an object with that same property, one can simply pass along the reference to the object without regard for who else might have received the reference or what they might do to the object [since there's nothing anyone else can do to the object], or when the receiver might examine the object [since all of its properties will be the same regardless of when they are examined].

By contrast, code which needs to give someone a reference to a mutable object which will have a certain property when the receiver examines it (assuming the receiver itself doesn't change it) either needs to know that nothing other than the receiver will ever change that property, or else know when the receiver is going to access that property, and know that nothing is going to change that property until the last time the receiver will examine it.

I think it's most helpful, for programming in general (not just functional programming) to think of immutable objects as falling into three categories:

1. Objects that can't won't allow anything to change them, even with a reference. Such objects, and references to them, behave as values, and can be freely shared.

2. Objects that would allow themselves to be changed by code that has references to them, but whose references will never be exposed to any code that would actually change them. These objects encapsulate values, but they can only be shared with code that can be trusted not to change them or expose them to code that might do.

3. Objects that will be changed. These objects are best viewed as containers, and references to them as identifiers.

A useful pattern is often to have an object create a container, populate it using code that can be trusted not to keep a reference afterward, and then have the only references that will ever exist anywhere in the universe be in code that will never modify the object once it's populated. While the container might be of a mutable type, it may be reasoned about(*) as though it were immutable, since nothing will ever in fact mutate it. If all references to the container are kept in immutable wrapper types that will never alter its contents, such wrappers may be passed around safely as though the data within them was held in immutable objects, since references to the wrappers may be freely shared and examined at any time.

(*) In multi-threaded code, it may be necessary to use "memory barriers" to ensure that before any thread can possibly see any reference to the wrapper, the effects of all actions on the container would be visible to that thread, but that's a special case mentioned here only for completeness.

Answer 6

As has already been mentioned, the problem with mutable state is basically a subclass of the larger problem of side effects, where a function's return-type does not accurately describe what the function really does, because in this case, it also does state mutation. This problem has been addressed by some new research languages, such as F* (http://www.fstar-lang.org/tutorial/). This language creates an Effect System similar to the type system, where a function not only statically declares its type, but also its effects. This way, the callers of the function are aware that state mutation may occur when calling the function, and that effect is propagated to its callers.

Answer 7

I made a C# example: passing mutable values

   public class Program
    {
        public static int sum(List<int> list)
        {
            int sum = 0;
            foreach (var item in list)
            {
                sum = item + sum;

            }
            return sum;
        }

       public static int sumAbsolute(List<int> list)
        {

            for (int i = 0; i <list.Count; i++)
            {
                list[i] = Math.Abs(list[i]);
            }
            

            return sum(list); 
        }

        static void Main(string[] args)
        {
            var list = new List<int>() {
                -1,-2,-3
            };

            Console.WriteLine(sumAbsolute(list));
            Console.WriteLine(sum(list));
            Console.ReadKey();
        }
    }

So the outcome of both functions is now 6. And of course this is not correct