Re:Total Functional Programming (2004) [pdf]
by mightybyte on Thursday March 07, 2024 @07:48AM
(#39628426)
There are many situations where the extra constraints on pure functions are very useful. Pure functions can't segfault. They can't overwrite memory used by other parts of your program due to stray pointer references. They can't phone home to Google. Verification and optimization is often much simpler when you know that some functions are pure. Reactive programming frameworks that execute callbacks in response to events can cause really weird bugs if the callback mutates state somewhere. I could go on and on. Nobody is arguing for pure functions all the way down. A program's top-level functions will usually be side-effecting, and then you can call out to pure code any time. In practice, a surprising amount of application logic can end up being pure functions.
[ Parent
| on HN ]
Re:Total Functional Programming (2004) [pdf]
by thfuran on Thursday March 07, 2024 @08:06AM
(#39628593)
>Reactive programming frameworks that execute callbacks in response to events can cause really weird bugs if the callback mutates state somewhere
What's the point of a callback that doesn't mutate state somewhere?
Re:Total Functional Programming (2004) [pdf]
by mightybyte on Thursday March 07, 2024 @08:34AM
(#39628846)
It allows you to separate non-stateful business logic from the stateful update logic. Reactive frameworks usually handle the state mutation for you, eliminating the potential for UI glitches where something that depends on the updated state doesn't get recomputed/redrawn.
Re:Total Functional Programming (2004) [pdf]
by andyferris on Thursday March 07, 2024 @08:24AM
(#39628750)
A lot of “dependency injection” type frameworks run this way.
The framework or runtime calls your function, and the return value tells it what to do next.
Prominent examples include React and Excel.