> That being said, Haskell is not well suited for things like games. It's just not the right paradigm.
is that really true? i feel like a game ought to fit into a functionally pure paradigm much better, because a game should really only depend on player input, and that can be modelled much easier as RenderIO (WorldState b -> PlayerInput a -> WorldState b) , but not having actually written any, this is just my assumption...
Well, obviously, a game state can change even if a player had no input. So you would have to have some concept of an empty player input on your model. (Also, modern games often require pulling from databases, remote servers... It's not just about transforming game states and rendering them any more.)
The problem with games are that they have a lot of state, and a lot of loopy state. You end up in a place where you have a set of entities which are organized into a graph and you need to traverse this graph and destructively update some elements in a way that is visible immediately to all elements. You can do this in Haskell, but... It won't be easy. Definitely much tougher than doing it in C, and at the end of the day your game written in idiomatic Haskell will be more complicated and less performant than the C solution.
John Carmack thinks there is potential in Haskell or other functional languages for game dev, so much so that he ported Wolfenstein 3D to Haskell as a summer project.
Haskell seems to be really nice for data structure transforms. A game can be modeled as such. But, it appears to me Haskell is used in programs which do a few large transforms whereas games do hundreds to thousands transforms per second. Games usually want to be mutable and using immutable language probably means there will be considerable effort in fighting against language features.
Ocaml and F# are more forgiving (some would say more practical) since they employ mutability as first class design element.
is that really true? i feel like a game ought to fit into a functionally pure paradigm much better, because a game should really only depend on player input, and that can be modelled much easier as RenderIO (WorldState b -> PlayerInput a -> WorldState b) , but not having actually written any, this is just my assumption...