The point of IO is to defer execution (making it lazy).
Deferring execution allows us to make pure functions from impure functions.
We prefer pure functions because they are easier to reason about.
The impure function has dependencies which are "tricky" because they are not deterministic.
It means, the impure function has side-effects and may return a different value or affects other functions.
Dangerous stuff better to avoid.
IO helps us to move a burden to the caller.
In Haskell like pure functional application, IO functions are only in composition root aka main.
Everything else (our app) is pure.
This is weird. Why we need move a burden to caller. I mean this is different from the DI in OO programing: If we just use a thunk to wrap the "side effect", the side effect is just there, when caller call the function in main, every side effect just executes. i don't know what problems do IO solve.
The point of IO is to defer execution (making it lazy).
Deferring execution allows us to make pure functions from impure functions.
We prefer pure functions because they are easier to reason about.
The impure function has dependencies which are "tricky" because they are not deterministic.
It means, the impure function has side-effects and may return a different value or affects other functions.
Dangerous stuff better to avoid.
IO helps us to move a burden to the caller.
In Haskell like pure functional application, IO functions are only in composition root aka main.
Everything else (our app) is pure.
Watch this youtube.com/watch?v=cxs7oLGrxQ4&t=...
"IO helps us to move a burden to the caller."
This is weird. Why we need move a burden to caller. I mean this is different from the DI in OO programing: If we just use a thunk to wrap the "side effect", the side effect is just there, when caller call the function in main, every side effect just executes. i don't know what problems do IO solve.
DI in OO makes functions/class methods easy to be tested at least