Purely functional programming, that is. Not functional programming per se. With that corrected, I agree with the guy.
However, his critique shouldn't be surprising to anyone but blind believers. Paradigms and features all have comfort zones and none of those is large enough to cover even nearly everything.
Analogously to strong/weak typing and dynamic/static binding, you rarely only want either. You either start with strong and/or static and build yourself dynamic and/or weak behaviour by hand. Or you start dynamically and later enforce certain type constraints deemed appropriate. There are a few holy wars in between but you can raise above that.
Similarly pure functions and impure state management ought to support each other, not fight each other. Pure functions are pure, clean, and functional so that mutations can be sparse and well-controlled. Conversely, the state must be destructively updated in some place by the impure code so that the pure functions are relieved from having to bother with it.
Similarly you can start at either of the pure and impure ends but you're bound to end up somewhere in between for any useful program.
You can start with pure functions and build something with them and worry about saving the state later. The original author is right in that that I often start with the latter and feel somehow guilty when writing the state. I shouldn't! Personally, I've noticed that this approach too often equals gigantic mutations on huge, monolithic states that yield huge, monolithic new states that you have to store somewhere.
Alternatively you can start with impure code and clean out stuff into pure functions as you learn how the program evolves. Each time I do this in, for example, Python I get the sense of how fucking brilliant I am. I should do it more often! Personally, while "erring" on the impure side at first I've noticed that the resulting program is often more beautiful as pieces of pure art rise from a pool of impure goo.
However, his critique shouldn't be surprising to anyone but blind believers. Paradigms and features all have comfort zones and none of those is large enough to cover even nearly everything.
Analogously to strong/weak typing and dynamic/static binding, you rarely only want either. You either start with strong and/or static and build yourself dynamic and/or weak behaviour by hand. Or you start dynamically and later enforce certain type constraints deemed appropriate. There are a few holy wars in between but you can raise above that.
Similarly pure functions and impure state management ought to support each other, not fight each other. Pure functions are pure, clean, and functional so that mutations can be sparse and well-controlled. Conversely, the state must be destructively updated in some place by the impure code so that the pure functions are relieved from having to bother with it.
Similarly you can start at either of the pure and impure ends but you're bound to end up somewhere in between for any useful program.
You can start with pure functions and build something with them and worry about saving the state later. The original author is right in that that I often start with the latter and feel somehow guilty when writing the state. I shouldn't! Personally, I've noticed that this approach too often equals gigantic mutations on huge, monolithic states that yield huge, monolithic new states that you have to store somewhere.
Alternatively you can start with impure code and clean out stuff into pure functions as you learn how the program evolves. Each time I do this in, for example, Python I get the sense of how fucking brilliant I am. I should do it more often! Personally, while "erring" on the impure side at first I've noticed that the resulting program is often more beautiful as pieces of pure art rise from a pool of impure goo.