I don't see why this is true, and perhaps it's because I don't have a full enough concept of functional programming.
In any language, why can't we write functions that don't modify the arguments, offer the same return for the same arguments, and modify no internal state when called? And then compose those functions together to form a full working program?
Here here. I am consistently baffled as to why this approach and OOP are apparently mutually exclusive, and why functional programming must be more than the approach quoted here.
Functions/methods as small/deterministic as they can be, judicious type checking, separation of concerns...maybe I'm dumb and/or inexperienced, but this approach seems perfectly fine to me, at least for the domains in which I work.
OCaml has an OOP system in place. C++ has lambdas, some "monads," etc. You can do functional programming in C#, TypeScript, even Java these days. People have even written libraries in Haskell that let you do OOP if you want.
Jack of all trades, master of none, is how I think of it. It becomes complicated trying to be a language that appeases all programmers. The C++ specifications, ECMAScript, etc are all enormous.
The Haskell 2010 report is quite small by comparison. The R6RS specification is smaller. When you have fewer things to consider and a smaller audience to appease you can do a whole lot more with much less.
When you go all in with a language that is built on functional programming principles first and foremost, you end up with a very different language than if you start with procedures and statements. You can emulate functional programming in C but it requires discipline and you don't get any feedback from the type system, compiler, or tools unless you write them yourself. When you write code in Haskell you get all kinds of feedback and the mental energy you used to spend on discipline can be used elsewhere.