> Personally, I think imperative code is more intuitive. It matches how people think of operational behaviors.

The masses agree with you, apparently. That's why they sit in their cubes all day writing the same god damn re-implementation of map over and over again

    List<String> result = new ArrayList<>();
    for (int i = 0; i < list.size(); i++) {
        result.add(input.get(i).toString());
    }

instead of

    input.map(_.toString)

because functional programming is confusing.

Quite true.

I still don't understand why recursion is confusing to learn, as for me it was obvious from day one. Then again I am good at maths.

Additionally, I had lots of fun doing Caml and Prolog when I was at the university.

So even though I tend to do the typical boring enterprise JVM/.NET/C++ stuff, I do welcome the FP contamination of those ecosystems. :)

However on my last project, I had to rewrite some LINQ stuff back to plain imperative code, because few people on the team could manage it (LINQ). :(

I don't think recursion itself is difficult for most people to learn. The hard part is translating recursive functions into procedures. The imperative coding is what makes it confusing.

That's another problem with imperative programming; it tends toward DRY violations.

The solution using map is more intuitive, once you know what map is.

I agree with you, as well, that the functional style should be used far more often than is the case. I just think that one shouldn't assume that our way of doing things is inherently more intuitive, even if it is most often better.

The code that the functional programmer produces is a more direct expression of the programmer's thoughts. The author thinks "I want to map this list using this transformation" (although perhaps not in those exact words). The author is never thinking "I want to create a new list, then for each index between zero inclusive and the list size exclusive, apply this transformation, append the result to the list I created, and then jump back to the call site providing that list as a return value." The imperative programmer is first thinking functionally and then translating that thought into procedures instead of directly writing expressions that match the thought (and like you said, it's just because they haven't learned the word "map" yet). Isn't that pretty much the definition of "unintuitive"? First thinking one thing, and then requiring conscious effort to think another thing instead?