Am 14.03.2013 22:20, schrieb Anthony D. Baye:

>
http://stackoverflow.com/questions/2704652/monad-in-plain-english-for-the-oop-programmer-with-no-fp-background/2704795#
> 2704795

I guess this one about wraps it up nicely (emphasis added):

--------------------------------
Monads are typically used to solve problems like:

     * I need to make new capabilities for this type and still combine 
old functions on this type to use the new capabilities.
     * I need to capture a bunch of operations on types and represent 
those operations as composable objects, building up larger and larger 
compositions until I have just the right series of operations 
represented, and then I need to start getting results out of the thing
     * I NEED TO REPRESENT SIDE-EFFECTING OPERATIONS CLEANLY IN A 
LANGUAGE THAT HATES SIDE EFFECTS

(Note that these are basically three ways of saying the same thing.)
--------------------------------

With the whole OO concept being /centered/ around operations with 
side-effects (namely modifying the object's internal state), this boils 
down to saying that monads are NOT NEEDED in an OO language. (Or, in 
other words, that monads do something that is already inherent in the OO 
concept anyway.)

I think it might also be fair to say that monads are a way to express 
certain OO ideas in functional languages.

Post a reply to this message