Why usage of assignment operator or loops discouraged in functional programming?

Question

If my function meets below two requirements, I believe function Sum to return the summation of items in a list where item evaluates to true for given condition qualifies to be referred as pure function, isn't it ?

1) For given set of i/p, same o/p is returned irrespective of time when function is called

2) It does not have any side effect

public int Sum(Func<int,bool> predicate, IEnumerable<int> numbers){
    int result = 0;
    foreach(var item in numbers)
        if(predicate(item)) result += item;
    return result;
}

Example : Sum(x=>x%2==0, new List<int> {1,2,3,4,5...100});

Reason I am asking this question is because I see almost every where people advising to avoid assignment operator and loops because it is imperative programming style. So what can go wrong with above example which makes use of loops and assignment operator in context of function programming ?

Answer 1

What is it in functional programming that makes a difference?

Functional programming is by principle declarative. You say what your result is instead of how to compute it.

Let's take a look at really functional implementation of your snippet. In Haskell it would be:

predsum pred numbers = sum (filter pred numbers)

Is it clear what the result is? Quite so, it is sum of the numbers meeting the predicate. How is it computed? I don't care, ask the compiler.

You could possibly say that using sum and filter is a trick and it doesn't count. Let implement it without these helpers then (though the best way would be to implement them first).

The "Functional Programming 101" solution that doesn't use sum is with recursion:

sum pred list = 
    case list of
        [] -> 0
        h:t -> if pred h then h + sum pred t
                         else sum pred t

It is still pretty clear what is the result in terms of single function call. It is either 0, or recursive call + h or 0, depending on pred h. Still pretty straighforward, even if the end result is not immediately obvious (though with a little bit of practice this really reads just like a for loop).

Compare that to your version:

public int Sum(Func<int,bool> predicate, IEnumerable<int> numbers){
    int result = 0;
    foreach(var item in numbers)
        if (predicate(item)) result += item;
    return result;
}

What is the result? Oh, I see: single return statement, no surprises here: return result.

But what is result? int result = 0? Doesn't seem right. You do something later with that 0. Ok, you add items to it. And so on.

Of course, for most programmers this is pretty obvious what happens in a simple funciton like this, but add some extra return statement or so and it suddenly gets harder to track. All the code is about how, and what is left for the reader to figure out - this is clearly a very imperative style.

So, are variables and loops wrong?

No.

There are many things that are much easier explained by them, and many algorithms that require mutable state to be fast. But variables are inherently imperative, explaining how instead of what, and giving little prediction of what their value may be a few lines later or after a few loop iterations. Loops generally require state to make sense, and so they are inherently imperative as well.

Variables and loops are simply not functional programming.

Summary

Contemporarily funcitonal programming is a bit more of style and a useful way of thinking than a paradigm. Strong preference for the pure functions is in this mindset, but it's just a small part actually.

Most widespread languages allow you to use some functional constructs. For example in Python you can choose between:

result = 0
for num in numbers:
    if pred(result):
        result += num
return result

or

return sum(filter(pred, numbers))

or

return sum(n for n in numbers if pred(n))

These functional expressions fit nicely for that kind problems and simply makes code shorter (and shorter is good). You shouldn't thoughtlessly replace imperative code with them, but when they fit, they are almost always a better choice.

Answer 2

The use of mutable state is generally discouraged in functional programming. Loops are discouraged as a consequence, because loops are only useful in combination with mutable state.

The function as a whole is pure, which is great, but the paradigm of functional programming does not only apply at the level of whole functions. You also want to avoid mutable state also at the local level, inside functions. And the reasoning is basically the same: Avoiding mutable state makes the code easier to understand and prevents certain bugs.

In your case, you could write numbers.Where(predicate).Sum() which is clearly much simpler. And simpler means less bugs.

Answer 3

While you are correct that from an external observer's point of view, your Sum function is pure, the internal implementation is clearly not pure - you have state stored in result which you repeatedly mutate. One of the reasons to avoid mutable state is because it produces a greater cognitive load on the programmer, which in turn leads to more bugs^{[citation needed]}.

While in a simple example like this, the amount of mutable state being stored is probably small enough that it's not going to cause any serious issues, the general principle still applies. A toy example like Sum probably isn't the best way to illustrate the advantage of functional programming over imperative - try doing something with a lot of mutable state and the advantages may become clearer.