OO code can work as reasonably effective good glue code for even older pre-OO procedural code, or even produce usable wrappers for big messy globs of assembly,

OO code can work as reasonably effective good glue code for even older pre-OO procedural code, or even produce usable wrappers for big messy globs of assembly, should you have the misfortune to own that sort of mess. So I would say that your bizarro world would need to presuppose that functional code had dominated from the first instead of any imperative code, which may have been what you meant. However, my suspicion is that imperative code, at it's most basic, is the natural form for the first computer code to take, given development of simple, early processors. My intuition could be wrong on this point, of course. In general, though, if you have particular operations in an imperative program that are more useful to reason about using a functional methodology, it's easy to use OO code as glue code wrapped around it (in C#, F#, Scala, etc.). By contrast, adding bits of imperative code inside a functional program requires careful thought and planning to keep from breaking the rest of the program through unexpected side effects. So my suspicion is that OO is ultimately a better "glue paradigm" than FP. And why I suspect that ultimately, object-functional languages are likely to succeed more broadly in the real world than pure functional languages.