I disagree, because the entire article rests on the premise that imperative programs are bad because they rely on shared mutable state. Here's the thing, though: every complex-enough program relies on shared mutable state; even Haskell programs[1]. Pure functional code just might outsource shared mutable state to an external database.
The solution, then, is not doing away with shared mutable state, as that's downright impossible, but with providing transactional semantics for that state. Once shared state has clear transactional semantics, the pure-functional nature of the programming language becomes secondary.
Let's imagine a programming language with perfect STM (i.e. an STM implementation that executes the most efficient code possible in every transaction). That language would have none of the problems described in the article, even if it were completely imperative. Hence, the problem is managing shared mutable state, and not existence of side-effects in general.
Pure functional programming could have been one solution to the problem, if only for the fact that it's not even a solution at all: Haskell programs still need a database. But the article assumes no other possible solutions, which is wrong. It focuses on one particular solution (which isn't even really a solution), rather than exploring many approaches. It is simply begging the question.
EDIT: I do agree that some partially-functional approaches are inherently dangerous, but I do not agree with the conclusion that the answer is going pure functional.
[1]: Except maybe for compilers, which is probably the most common complex software built in Haskell.
In either case it does not follow that pure functional programming is the answer, especially as it makes "essential side effects" (which are, well, very essential), quite cumbersome. Clojure isn't pure functional, it makes essential side-effects easy, and non-essential (or, rather, dangerous) side effects hard.
I'm not saying that Clojure is the silver bullet, it's just that the article's conclusion does in no way follow from the premise.
I would strongly look at Clojure's implementation of Atoms, Agents and Refs. IMO that is the best isolation of mutation I've seen in any language.
What do I mean by isolation of mutation? As stated above, all applications end up needing global shared mutable state (usually it lives in databases, but doesn't have to). So Rich Hickey created mechanisms to do such things safely and concisely.
Exactly. Clojure is a great example, although it doesn't offer a complete solution: atoms/agents/refs are either not general enough or not performant enough to handle many data structures well.
The solution, then, is not doing away with shared mutable state, as that's downright impossible, but with providing transactional semantics for that state. Once shared state has clear transactional semantics, the pure-functional nature of the programming language becomes secondary.
Let's imagine a programming language with perfect STM (i.e. an STM implementation that executes the most efficient code possible in every transaction). That language would have none of the problems described in the article, even if it were completely imperative. Hence, the problem is managing shared mutable state, and not existence of side-effects in general.
Pure functional programming could have been one solution to the problem, if only for the fact that it's not even a solution at all: Haskell programs still need a database. But the article assumes no other possible solutions, which is wrong. It focuses on one particular solution (which isn't even really a solution), rather than exploring many approaches. It is simply begging the question.
EDIT: I do agree that some partially-functional approaches are inherently dangerous, but I do not agree with the conclusion that the answer is going pure functional.
[1]: Except maybe for compilers, which is probably the most common complex software built in Haskell.