3 ms·
Im just going by the formal definition of purity 1. Its return value is the same for the same arguments (no variation with local static variables, non-local
by lbj 8y ago
Im just going by the formal definition of purity
1. Its return value is the same for the same arguments (no variation with local static variables, non-local variables, mutable reference arguments or input streams from I/O devices).
2. Its evaluation has no side effects (no mutation of local static variables, non-local variables, mutable reference arguments or I/O streams).
As soon as I/O is involved, functional purity is technically broken and since any real-world system will have I/O I consider the quest for purity to be a fantasy in the same vein as developers who invest a lot of resources in "proving" their functions.
- mbrock 8y agoFunctional purity isn't broken by Haskell-style I/O. In Haskell, I/O is not done through side effects, and I/O effects are not functions, so your points 1 and 2 are not violated. It's not a "fantasy." You just don't understand it.
- platz 8y agoThe post is really talking about choosing the best kind of composition to solve problems in (purity was a by-product of being mathmatical). You guys are arguing over the monadic io that he dismisses in the first couple couple paragraphs. All he really cares about is achieving program composition.