4 ms·
> It's been said that "callbacks are imperative; promises are functional". It's true. Furthermore, callbacks structure control flow and promises structure data
by andrewstuart2 10y ago
> It's been said that "callbacks are imperative; promises are functional". It's true. Furthermore, callbacks structure control flow and promises structure data flow.
Do you have any good escapes l examples of further reading on this? I'm not sure I agree with this statement, or perhaps don't fully understand it. It seems like both cases boil down to functions as data (function pointers essentially) that are called at the end of some event or chain of events.
To me, they seem to be the exact same thing but worth promises being much more human readable.
- chenglou 10y agoTo give a brief "explanation", look at the type signature of a callback-based API: readThisFile: string -> (string -> void) -> void Usage: readThisFile('foo.txt', result => ...) You have a double void here. Which is the hand-wavy justification as to why callbacks don't compose. On the other hand, a promise's value is Promise<actualTypeOfValue>, which you can pass around as data without asking the other end what it wants to do with the value (aka decoupling). You do have the imperative action at the top to kick the whole chain into motion, but the intermediate stuff are most of the time side-effect-free. Hopefully that was clear enough to see that passing actions around is akin to controlling the flow with e.g. if-else, and that passing data around is declaring how your tubes/rail tracks/whatever analogy for monads are constructed, aka data flow.
- brandonbloom 10y agoYou can google that quote and find more, but the control flow vs data flow formulation is not widely discussed from what I've seen.
- tel 10y agoIt's widely discussed in Haskell communities, fwiw ;)