That is just not the case. I have worked, full time, as a functional programmer coming up to 15 years, in different langauges. Actual functional programming and

That is just not the case. I have worked, full time, as a functional programmer coming up to 15 years, in different langauges. Actual functional programming and not merely doing web programming with React. "[...] pure functional programming whilst still functioning." I mean, what is this? When I read what you are saying here, you are saying that an "advanced codebase", whatever that means, using functional programming leads to centralized state and distributed components. And you know this because the codebase you are thinking about has this software architecture. I have been in such codebases too, they tend to be frontend and maybe that is just the way you have to do it, maybe not. But this is not a property inherent to functional programming. Solving problems with a component or object concept as a central abstraction for "a thing" is the OOP way. I know this because this is how I spent the first half of my career. You think you need a _substantive_ onto which you perform verbs. Nothing wrong with this though, I am not picking a fight with OOP. I can offer what I refer to when I talk about FP so that we can at least have a real thing to disagree over :) 1. model the domain and interactions with it with strong types such that neither interactions nor state can represent values outside of the domain. 2. parse, don't validate 3. Use modules, stateless collections of declarations, to organize stateless functions. No this. No self. 4. No magic code. I.e.: no null checks, no magic number checks, no arbitrary logic in four places that together make up the fact that prices can have taxes. Abstract it and "store" these runtime decisions using typed values, use functions that accept these typed values to force use of the aforementioned types. 5. Control the side effects. This does not mean that you have to use Haskell or monads or anything like that. Just that managing it is a good thing. 6. #5 implies keeping track of state. I.e.: no, you may not just willy-nilly read it from the persistent store, cache or file.