There are plenty of ways to model state in functional programming, and I’d say most of them are…
Yuri Albuquerque

I use FRP for UI in games. I even use things like Map<>. I’ve been reading up on Rx and Elm and Most. Cool stuff, and useful for some things.

And it’s just not fast enough for some things, like mutating a world state for any nontrivial world size.

I just listened to a podcast about ImmutableJS, where they were saying that it’s plenty fast enough because when they create a new copy of an array or map, they’re referencing most of it and just modifying a part, meaning that it’s O(log n). For the kinds of things you deal with in a typical web page (with n<50), that can be fine. Even for server code that doesn’t execute very often (i.e., once per request) it can be fine.

But going from O(1) (with a really small constant) to O(log n) (with a larger constant) for nontrivial n (say a thousand or more entities) and repeating that operation a few thousand times (update position, changes in state, AI calculations)…in much less than 16.6ms, so you can keep your 60FPS update rate… And then there’s the exploding memory requirements, assuming your immutable model never throws away old data, and/or drowning in GC overhead to dispose of those branches that are being generated at 60FPS… Heck, for serious game development the norm is to create memory pools just to avoid memory fragmentation which can kill a game that someone’s been playing for a few hours.

I’ve developed games for 30 years. As cool as some of the functional approaches to UI are, games are much more than fancy UI with animations, and functional just doesn’t hold up as the only paradigm. Yes game developers have things to learn from FRP and similar paradigms. But I repeat, There Is No Silver Bullet.

Like what you read? Give Tim Mensch a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.