I do agree with you on the general principle of not using state arbitrarily. As I see it, this is an example of the still more general principle that code shoul

I do agree with you on the general principle of not using state arbitrarily. As I see it, this is an example of the still more general principle that code shouldn’t depend on anything without good reason. The more dependencies are involved, the harder it is to maintain or reuse code, to run automated tests against it in isolation or review it formally to check the logic, and so on. However, where I sometimes have a slightly different view to some functional programming enthusiasts is that I don’t see state as some sort of inherent evil. My interest is in writing code that is correct, maintainable and efficient. Writing pure functions is one possible technique to help reach that goal, but to me it is only a means to an end. In particular, it is only one case of the more general principle that stateful resources and effects acting on them should be specified clearly enough that bad things provably can’t happen, but they don’t need to be emphasized or restricted any more than that, particularly if it means compromising on other areas such as readability.