To quote Joe Armstrong:
> I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. If you have referentially transparent code, if you have pure functions — all the data comes in its input arguments and everything goes out and leave no state behind — it’s incredibly reusable.
The analogy with OOP is that (ideally) you don't need to know how it works internally: you just use the external interface.
Consider a function f that itself relies on being able to call function g. In FP, you have to either bind by name, which introduces coupling on par with OO ("the jungle"), or you make it parametric, so f doesn't know anything about g per se, but somebody does―perhaps f's caller, or its caller, etc. OO is parametric, too, but in that case they live as slots on the objects, rather than being passed as arguments.
People can try to squidge this end of the problem and find that it shquoshes up on the other side, or vice versa. There's no real escape from the problem of dealing with state.
Probably the real silver bullet boost to productivity will come when we adapt program execution environments to our dumb brains by way of VR. Think of something like a cellular automaton such as von Neumann's universal constructor:
https://en.wikipedia.org/wiki/Von_Neumann_universal_construc...
... only in 3 dimensions. When we want to debug a program, we project it into a 3-dimensional space, and we trace its execution the way you can look at something progressing through the assembly line on a shop floor, with pieces that you can reach out and touch, and even pick them up and mark some with blue dots and some without, etc. That looks a lot more like OO than FP.