Can you elaborate on that? People have actually written games in FP languages ([1], [2]).
[2] https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
GOAL had a fast coroutine implementation written in it that enabled, among other things, autosave while the game engine kept running without a hitch in the Jak & Daxter series.
Even when writing games in C, you end up writing many things in a very functional way by default. You have some state variables, and on every tick you advance things around in a very defined fashion, and redraw the screen.
The "default" pattern for making games is so close to functional languages already that the only thing moving to purely functional languages gives you is a tutorial on State monads.
In a way, this is a way of saying that functional languages are good for games, though...
meanwhile, OOP-style tools are extremely useful in games, because you often find yourself working with Entities with a lot of shared behaviour. The abstraction maps well to the concrete structure of a game.
Going to an FP-language will often cause you to sacrifice many OOP-centric language niceties without bringing much to the table to replace those niceties. In game programming, I think the tradeoff is much harder to justify than in other domains.
OOP is just an enormous win for games; I actually learned OOP with ZZT and Megazeux. Something simple like Pac-Man _might_ fit in a stateless paradigm, more or less, if you have a non-painful way to do I/O; but the more ambitious a game gets, the more it benefits from objects (including rule-processing objects).
MVC is also a good thing to use in gaming. For those who haven't heard yet: the model is the database and the deterministic, stateless parts of processing ("characters lose 1 point of nutrition per turn"); the controllers are the player's and any AIs' decisions (both are almost certainly stateful across rounds/timer-ticks); and the views are drawing the game (for the player) and giving a selective picture of the gameworld's state (for the AIs).
The statefulness is managable in FP generally, you could see things like the State monad in Haskell. After all, the current state is just recursive applications of the rules. Experienced users of the FP languages will feel at home
The high nesting that would end up in your data will probably mean you want to reach for deep data accessors and the like. This is managed through things like Lenses in Haskell. But that's an extremely high learning curve to basically get what you get for free with dot notation in so many other languages. If you're experienced in the language already, it's fine, but if you're just starting out in the FP language, and you had experience in iterative-style languages... ouch.
I really like the idea of applying MVC for game patterns. it makes so much sense! Going to explore that the next time I have the chance.
(Lisp also has terminology that's much easier to understand than Haskell. What exactly is a monad, again? And why would I care about monads when I already have Java?)
(And also note Bitwize's observation that GOAL is imperative with the option of doing a little FP.)
And people have written games in Erlang. [0]
https://wiki.haskell.org/Applications_and_libraries/Games
I still don't get the "aggressively unhelpful for games". FP does not mean "no state", just that state is expressed differently.
(For the aggressive unhelpfulness of Haskell, I mentioned that Pac-Man project -- and see my other posts in this thread.)
