Broadly speaking, imperative programming allows one to start coding a solution before one understands the problem.

Functional programming is generally more abstract in its approach to modelling the problem. If you get the model wrong, you will not end up with a working solution, forcing you to rethink your model.

While imperative programming allows you to reiterate towards a solution as you start to understand the problem better as you work towards it, it's obviously better and faster if your initial model of the problem is more accurate.

Functional programming forces you to create a viable model of the problem before you start. If you can extend that discipline over to an imperative language, you will need less iteration and the resulting solution will likely be more elegant.

The argument is not (or shouldn't be) about concepts, but about paradigms and discipline.

I think the most apparent example is that people recognize patterns like `fold` and `map` everywhere once they've seen functional programming.

This can be implemented in any language I guess. Most often you'll see explicit & imperative loops being refactored to shorter, descriptive code with anonymous functions, folds, filters and maps

Many people doing OO have trouble structuring their classes, splitting functionalities and responsibilities properly.

OO kind of lets you do anything you want, allowing you to store data anywhere and having any kind of flow you want. It's very easy to do something that "just works", and while there is a lot of value in that, you can keep bad habits for very long.

FP is a lot more constraining, and will force you to adapt how you think to fit said constraints.

Having to think differently offers a different perspective on code architecture, that will eventually give you ideas applicable beyond FP languages.

Many would argue the exact opposite, that OO is contraining and FP is much more free, allowing you to change your design model without having to redesign the entire model.

> Can anyone explain?

A quick example that can be faked in any language is a pure function [1]. The functions only inputs are the set of arguments, and from those arguments returns a side-effect free result. A pure function is easy to test and easy to reason about.

Contrast a pure function with an impure function that uses an objects internal state plus the arguments passed in to further tweak the state an/or return a result. It is immediately obvious the second is much harder to test and reason about. It becomes even more challenging when the object is thrown into a large system with a lot of moving parts.

Even before I really started learning about true functional programming, I had been writing 'pure' functions for years because they just made sense. Even internal private methods are simpler as pure functions. Shared state is evil for many reasons and should be avoided if possible.

[1] https://en.wikipedia.org/wiki/Pure_function

Working with functional languages has made me value and seek out simplicity in my code. Before I write a loop or create another class I'll often ask myself if there is a more simple way to solve the problem - and oftentimes there is.

You can take those concepts and use them in your designs in languages where they're missing, even if you don't use FP or logic languages where they're "native".