Yeah, purely functional programming can approach an academic exercise. Real-life programs are different, the hosting of mutable state is inherent in many tasks

Yeah, purely functional programming can approach an academic exercise. Real-life programs are different, the hosting of mutable state is inherent in many tasks and programs, and cannot be avoided so it makes no sense to trick the language into doing something that it can't easily do. But functional programming doesn't need to mean all purely functional programming. Functional programming is easy to reason about but it can only be useful as long as it's only applied to the part of the program for which it is a fit. That's quite like how object-oriented programming is a perfect fit for programming user interfaces but not necessarily to managing a data flow. Write as much in functional style as possible. That will form a nice set of tools upon which you can build. If you need to modify state, you might be able to parameterize a pure function and handle the updates outside but if things get too complex, just pass in a struct or a dict. You can always refactor the function into smaller functions that are, again, purely functions. It's just a matter of drawing the line where it's simplest. Just as it doesn't make sense to write a program using only global state and gotos it doesn't make sense to write a purely functional program. (And it doesn't make sense to write a program using only objects, either. I'm looking at you, Java.) There needs to be an interface between the functional code and the code that has side-effects. I like Clojure there a lot. It supports mutable state but makes access to it explicit and controlled. It also support writing a function that looks pure but internally uses a temporary mutable store for data crunching, which is then explicitly finalized before it's returned back as an immutable piece of data.