That's also my experience mentoring and working with a range of talented programmers. Functional programming is great when you wrap your head around it, but it

That's also my experience mentoring and working with a range of talented programmers. Functional programming is great when you wrap your head around it, but it's a significant mental drag to understand. I haven't met people who honestly find it easier, if anything, it's more bragging rights that you can do it. (And useful bragging rights, when you can hack monads, lensing, folds, etc. you can solve some very challenging problems.) I will make an observation in defense of functional programming: when you start to get "data pasta" (my term for the data equivalent of spaghetti code) where objects are linked all over the place and side effects abound, it becomes similarly incredibly difficult to reason about. What starts out simple quickly leads you into a trap. That's my motivation for designing a functional language that uses typical imperative control structures, which are then translated into a functional form. I think you get a very simple mental model: imperative control, referential integrity and locality of effects. It also forbids pointers and recursive data structures; that was originally just so I could guarantee that reference counting was sufficient, but I'm now realizing that once you add a simple "path" type, you can do everything you want, but it also helps to avoid highly complex structures that are difficult to reason about. "Immutable harder than mutable." You can have both, though: https://pypi.org/project/pyrsistent-mutable/ https://pypi.org/project/pyrsistent-mutable/