Modeling with pure functions is difficult at first, particularly if you know imperative programming well. In fact it took me a while to get used to it. But it eventually becomes familiar, and not any harder to do than procedural or OOP. Then you start to wish you had discovered it a lot sooner.
The payoff is well worth it. Primarily because pure functions have linear risk/cost to refactor. I don't know about you, but my experience previously has been that refactors to core code can have an unknown risk of breaking other things... but not so with pure functions. When you look at a function, what you see is what you get... no mysterious external, runtime state changes to account for. Refactorability is a benefit that pays dividends for many years to come. And as I said, once it becomes familiar its not even any more work (and perhaps less) than other methods. The main trade-off is the upfront cost of learning it.
Pure functions are also quite easy to test. If all your significant decisions are in pure functions, you don't really need mocks, fakes, and extensive test frameworks. You just need to vary the inputs and check the outputs. Testing logic is low-cost and easy. Testing side effects becomes integration testing (part of CI workflow, not in unit tests).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice catch. I revised the wording.
It seem to me ok but.. really hard and annoying.
Why do FP need pure function ?
Modeling with pure functions is difficult at first, particularly if you know imperative programming well. In fact it took me a while to get used to it. But it eventually becomes familiar, and not any harder to do than procedural or OOP. Then you start to wish you had discovered it a lot sooner.
The payoff is well worth it. Primarily because pure functions have linear risk/cost to refactor. I don't know about you, but my experience previously has been that refactors to core code can have an unknown risk of breaking other things... but not so with pure functions. When you look at a function, what you see is what you get... no mysterious external, runtime state changes to account for. Refactorability is a benefit that pays dividends for many years to come. And as I said, once it becomes familiar its not even any more work (and perhaps less) than other methods. The main trade-off is the upfront cost of learning it.
Pure functions are also quite easy to test. If all your significant decisions are in pure functions, you don't really need mocks, fakes, and extensive test frameworks. You just need to vary the inputs and check the outputs. Testing logic is low-cost and easy. Testing side effects becomes integration testing (part of CI workflow, not in unit tests).