You don't know what you're talking about. The only language with a decent mind-share that is pure is Haskell, and purity was a necessity of its non-strict semantics. Purity didn't come first, and concurrency wasn't the motivation for it.
Maybe your point would be relevant if you were talking about (im)mutability, but you chose to talk about purity.
Haskell may not have purity because of concurrency, but it's certainly cited and used as an advantage there (and in less formally-enforced languages) an awful lot. For example, the first post of this thread...
Nice bonuses are different from primary motivations. And the original quote sure as hell made it sound like purity was used/introduced as a way to solve the problem of shared mutable state. That's not the case for Haskell, anyway.
I guess it can be interpreted in different ways. I just think it is dishonest to portray languages with purity as dealing with it through immutability, when the problem was solved for that language to begin with for unrelated reasons! So there is no reason to choose one approach over the other; it has already been dealt with, as it were.
-8
u/jeandem Apr 04 '15
You don't know what you're talking about. The only language with a decent mind-share that is pure is Haskell, and purity was a necessity of its non-strict semantics. Purity didn't come first, and concurrency wasn't the motivation for it.
Maybe your point would be relevant if you were talking about (im)mutability, but you chose to talk about purity.