###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. 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 pred 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 `item`s 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**.

###Summary

All above doesn't mean that using variables is wrong. There are many things that are 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.

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](https://blog.codinghorror.com/the-best-code-is-no-code-at-all/)). You shouldn't thoughtlessly replace imperative code with them, but when they fit, they are almost always a better choice.