I really like your sentiment, but I'm not sure if "OO was invented for X" or "FP was invented for Y" is right.
They are abstract paradigms that were created with very little connection to their underling usage at the time (FP in particular stems from a mathematical background, but most of OO as well).
Rather I would say more then "OO is more suitable for GUI" and "FP is more suitable for compilers" (though I'm not sure if I agree with that)
This isn't true about games; FP isn't a bad fit for them. Games can be written in FP, and there are some interesting things you can do with it, it's just that it's obviously less explored and more "researchy".
- Clean Game Library, using Clean, an FP language with a different philosophy from Haskell's: http://cleangl.sourceforge.net/
- For my (abandoned :( ) master's thesis, I was also writing a platformer in Haskell and was doing just fine. I abandoned it because I'm lazy, not because of FP :P
I guess the main problem is that FP can encode updatable trees with direct pointers from parents to children, but it can't encode updatable graphs with direct pointers, and in some applications you really want that.
I don't know. I have actually tried writing a game using Haskell. Admittedly, it was an absurdly simple platformer, and I left it unfinished, but it was a joy to write it. FP helped with both high and low-level code organization. I didn't hit any walls writing it (maybe I would have later on, of course). Had I continued it, I would have tried using FRP techniques, which was ultimately the whole point of the thesis, but never got around to trying them.
I think it's one thing to argue from theory ("this can't possibly be practical!") and another to actually try your hand at it and see whether it works or not :) My semi-informed guess is that it does. I don't expect to see AAA games done in Haskell any time soon, but that's for completely unrelated reasons!
IIRC, Carmack himself seems to be warming up to the idea of using some pure FP techniques in games. Of course, not everywhere.
I'm not convinced GUIs can't be built with functional programming techniques. My GUIs (in Android and more recently with React) generally tend to follow a unidirectional data flow, where the view building is really a dumb passthrough of massaged data that's stored in a local DB (like SQLite). The view state could be represented ENTIRELY by a JSON object, e.g. and since it's all stored locally, it's replayable if something goes wrong.
Configuring and assembling a GUI out of an existing GUI framework, and writing that framework in the first place, are two different use cases IMO. OOP works a lot better for the latter case.
Don't try to use OO for compilers or formal verification. That's what FP was invented for.
Don't try to use OO or FP for operating systems. That's what imperative languages were invented for.
Anyone who insists on a single style for the whole software industry is probably underinformed and overconfident.