Interesting how the post doesn't mention the word "side effect" once.
To me, all of this could be summarized by "no side effect".
To me, all of this could be summarized by "no side effect".
whip(cream)
whipped_cream = whip(cream)
While they could have mentioned it, it wouldn't really change the message.
To me (someone who really doesn't like FP as a religion), FP is about function application: everything should just be "pure" function calls taking values (not references) and returning values; immutability is indeed a corollary of that, static typing really isn't (isn't Church's original LC untyped, btw?).
* If you don't have side effects, you can't do anything.
* Haskell can do things? Then it has side-effects, so it's not functional.
* Computer getting hot is a side-effect.
* i++ is not a side-effect, because I intended to do it.
For me, the essence of FP is the minimization of global state
For example, Java collections are mutable, but enough ink has been spilled about the dangers of shared mutable state, that there are various recommended defences, e.g. make defensive copies when you return collections to a caller. Or use one of the immutable collections that will throw a runtime exception if someone tries to mutate it.
Now consider if you wanted to evaluate 3 + 5. Should you throw an exception which tells the caller off for trying to change the value of 3? No, the caller just wanted 8!
This is what's missing with the 'just make things immutable' approach to FP mimicry. I want to be able to combine collections together. The Java standard library Set<> still doesn't have union and intersection for christ's sake.