so if your method showMeMoney returns IO Int instead of Int, that would solve the issue because any call to showMeMoney would not 'pay respect' unless you run the monad, right? I'm trying to see why a monad would solve this issue.
Yes and no, `Monads` on their own don't solve the issue, is the `IO` datatype the one that propose one solution to this issue (is not the only solution, and as with everything they all have tradeoffs). The `IO` datatype solves this problem because of what you described, by not longer executing the code but rather just being a description of the program to be run we recover RT; until the point the `IO` is run, that is why we say that should be the end of the world. Now, orthogonal to that we can also prove that the `IO` can form a `Monad`, this is irrelevant for the RT discussion but it has a big impact in the code we write, because `Monads` (and many other typeclasses from CT) give us tools on how to compose those `IO` together. That is why we can summarise FP on RT + composition; those two thins are what allow us to build bigger programs on top of small ones. With pure functions you have composition out of the box, the moment you add some context datatype like `Option` or `IO` we lose that out of the box composition; but `Monads` allow us to recover it. Note that this mix of `IO` with `Monads` is sometimes called "Program as values", where the main benefit we gain is being able to express control flow as functions.
No such thing as a dumb question! Use Decimal types or specialized libraries for money. The reason is that Doubles (the standard floating point standard) can't fully represend tenths and hundredths and maintain precision with math operations.
The "Mob Boss" analogy had me cracking up throughout the video. :LOL!
Thanks Daniel, for the RT explanation!
(mob boss accent) Appreciate it!
so if your method showMeMoney returns IO Int instead of Int, that would solve the issue because any call to showMeMoney would not 'pay respect' unless you run the monad, right? I'm trying to see why a monad would solve this issue.
Yes and no, `Monads` on their own don't solve the issue, is the `IO` datatype the one that propose one solution to this issue (is not the only solution, and as with everything they all have tradeoffs).
The `IO` datatype solves this problem because of what you described, by not longer executing the code but rather just being a description of the program to be run we recover RT; until the point the `IO` is run, that is why we say that should be the end of the world.
Now, orthogonal to that we can also prove that the `IO` can form a `Monad`, this is irrelevant for the RT discussion but it has a big impact in the code we write, because `Monads` (and many other typeclasses from CT) give us tools on how to compose those `IO` together.
That is why we can summarise FP on RT + composition; those two thins are what allow us to build bigger programs on top of small ones.
With pure functions you have composition out of the box, the moment you add some context datatype like `Option` or `IO` we lose that out of the box composition; but `Monads` allow us to recover it.
Note that this mix of `IO` with `Monads` is sometimes called "Program as values", where the main benefit we gain is being able to express control flow as functions.
@@luismiguelmejiasuarez2020 Thanks. Even I barely understand the topic, I feel it is knowledgeable.
Hi Daniel, a dumb question: as you mentioned in the video, we shouldn't use primitive types for money in practice. And what's the proper way to do so?
No such thing as a dumb question! Use Decimal types or specialized libraries for money. The reason is that Doubles (the standard floating point standard) can't fully represend tenths and hundredths and maintain precision with math operations.
@@rockthejvm Thank you, Daniel!
Thank you
💖💘❤💕💗