There are a lot of problems with this piece, like there are always problems with these OOP/imperative vs. FP posts. > Both humans and machines are really good

There are a lot of problems with this piece, like there are always problems with these OOP/imperative vs. FP posts. > Both humans and machines are really good at implicit state attached to time. That may be true for machines; they always know where all their state is. But we humans are terrible at managing state, especially implicit state, especially when we have to reason about how it changes as time passes. We can't keep all that state in our head, and as soon as a system gets reasonably complex even simple values mutating get hard to juggle in our puny minds. I would venture to guess, unscientific as it may be, that a majority of bugs in software have to do with humans not being able to reason effectively about state. Pure functions taking immutable data in and spitting out new values eliminate many of the challenges with managing state. It's vastly simpler for us humans to understand what's going on with our state when we deal with chaining together a bunch of functions manipulating data immutably, and push managing mutable state out to the very specific points at the edge of the system. It's not a silver bullet--but it helps. And it's not weird at all, once you're used to it; quite the opposite. > Writing functional code is often backwards and can feel more like solving puzzles than like explaining a process to the computer. > I'm writing this blog post because I ran into a related problem recently. C++ templates are accidentally a functional language. Functional programming advocates can't even agree on a definition of what functional programming is, and I'm even less sure what the author intends. What they have chosen to highlight is not what I recognize as functional programming; while I think it's good the author wants to talk about immutability as one facet of FP, it seems pretty bizarre that they claim that functional program often dictates you write your code backwards, or that they choose an already implemented solution and their attempt to refactor it functionally using C++ templates as a place to critique functional programming in the real world. More generally, the big problem with these articles is that they fundamentally focus on the wrong things. Whether someone has issued a blistering indictment of OOP and all its failures as a methodology or we get a piece like this, we end up arguing over nonsense because we don't have a standard definition of OOP or FP that everyone can agree on, and it's the wrong level of abstraction to be arguing over anyways. What we should be talking about are specific language features and what they bring to the table, including how they interact with other language features, how they are implemented in various environments, etc. What does immutable data do for us? How can pure functions help us reason about our code better? What kinds of type systems are out there, and what positives or negatives do they have in different contexts? Does encapsulation bring anything to the table or is it a net negative? Etc. I'd encourage anyone considering writing yet another glib takedown of OOP or FP to take a step back before they put text to screen and consider instead discussing specific features that have widely agreed upon definitions and how those programming language features lead to certain outcomes, without making a dramatic overarching statement about the weirdness or badness of OOP or FP. Pieces like this only further reinforce the superficial pop culture that currently dominates our industry.