This guy may be smart, and he may have done a lot, but this article seriously smells like a troll. Isn't this exactly the sort of behavior you're not supposed

This guy may be smart, and he may have done a lot, but this article seriously smells like a troll. Isn't this exactly the sort of behavior you're not supposed to engage in? Two library calls, deep in vastly different parts of the code. And you're going to make them mess with each other? For christ's sake, they're used everywhere, they've been working fine for ages, and now you're going to mess with them, make them intertwined and thus complicated, for one stupid edge case. You know if you really wanted to do it, you could do an unsafePerformIO, but... ...I'm just not buying it. I can think of many ways that FP (not just pure FP) is deficient, but this is not one of them. The biggest problem I see with FP is that when your data model is sparse, imperative-style state change updates are just more efficient from a programming perspective. I should note that I'm not the first one to spot this. It was talked about amongst the FPers I knew in school. Lets just say each variable, every function input and function output is a vertex in a graph. When I say that the data model is sparse, what I mean is that the edge count on the vertices is small. How small? I dunno, it's a gut feeling sort of thing, or maybe someone could correct me on it.