4 ms·

No. You need to understand monads before learning FP and you need to learn FP for understanding monads. This is chicken/egg problem. Functional programming i

by lonk 9y ago

No. You need to understand monads before learning FP and you need to learn FP for understanding monads. This is chicken/egg problem. Functional programming is overrated.

dragonwriter 9y ago
> You need to understand monads before learning FP No, you don't. You don't even need to understand them before learning Haskell, much less before learning FP using a language which doesn't use monads as pervasively as Haskell does. You obviously need to learn at least something about monads as you learn Haskell, but understanding them is not a prerequisite.
userpass 9y ago
I would lie if I said this isn't fun which is probably the reason why people do it in the first place even though their explanations might make it worse than just reading this: https://hackage.haskell.org/package/base-4.10.0.0/docs/Control-Monad.html#t:Monad https://hackage.haskell.org/package/base-4.10.0.0/docs/Contr... Asking what a monad is is like asking what an iterator is. It doesn't tell you very much what it actually does because it depends on the implementation. The iterator is just an interface. A bunch of functions that have to be correctly implemented according to certain rules. It all first started with lazyness. FP developers wanted a new modern language developed from the ground up. It should be a pure language. The haskell developers soon realised the evaluation order of a pure language must not necessarily be fixed. Eventually lazyness was born. Lazyness was a unique and very appealing feature for a purely functional programmming language. However as soon as a haskell program had to leave it's protective shell and interact with the real world lazyness turned into a double edged sword! FizzBuzzes were printing their buzzes and fizzes out of order! Chaos ensued and haskell developers returned back into the shell. After long years of work they have finally discovered it! A mechanism to force the evaluation order of a program to be partially sequential again! It is a new type of container that allows you to put another type inside it. However sometimes the only way to access the contained value is by giving the container a function that takes a the boxed value as input and returns another container with a boxed value inside! The value never escapes the box. And so was the (IO)monad born! You can now take two IO actions a and b and turn them into c which is a combination of a and b where the output of a is piped into b. Not only can we send messages to the outside world, we can also finally receive them! Everyone was happy in haskell kingdom until the imperative migrants started writing monad tutorials... (including this one) This story is fiction by the way. As a bonus for all the wasted time. another crappy analogy: A cage inside a bird is given a machine that puts birds in cages. The regular tool called functor that only replaces what's inside the cage would give us a bird in a cage in a cage! The special tool gives us what we actually want! The tool named monad gives us a bird in a cage! No nested cages!
jejones3141 9y ago
No, no more than you need to understand group theory before you learn to add and subtract or ring theory before you learn to multiply. Better to teach how to use specific monads without using the dread m-word, and then say "You know, these all have something in common" and then talk about monads, or these days work your way up from Monoid to Functor to Applicative to Monad.

by lonk 9y ago

No. You need to understand monads before learning FP and you need to learn FP for understanding monads. This is chicken/egg problem. Functional programming is overrated.

dragonwriter 9y ago

> You need to understand monads before learning FP No, you don't. You don't even need to understand them before learning Haskell, much less before learning FP using a language which doesn't use monads as pervasively as Haskell does. You obviously need to learn at least something about monads as you learn Haskell, but understanding them is not a prerequisite.

userpass 9y ago

I would lie if I said this isn't fun which is probably the reason why people do it in the first place even though their explanations might make it worse than just reading this: https://hackage.haskell.org/package/base-4.10.0.0/docs/Control-Monad.html#t:Monad https://hackage.haskell.org/package/base-4.10.0.0/docs/Contr... Asking what a monad is is like asking what an iterator is. It doesn't tell you very much what it actually does because it depends on the implementation. The iterator is just an interface. A bunch of functions that have to be correctly implemented according to certain rules. It all first started with lazyness. FP developers wanted a new modern language developed from the ground up. It should be a pure language. The haskell developers soon realised the evaluation order of a pure language must not necessarily be fixed. Eventually lazyness was born. Lazyness was a unique and very appealing feature for a purely functional programmming language. However as soon as a haskell program had to leave it's protective shell and interact with the real world lazyness turned into a double edged sword! FizzBuzzes were printing their buzzes and fizzes out of order! Chaos ensued and haskell developers returned back into the shell. After long years of work they have finally discovered it! A mechanism to force the evaluation order of a program to be partially sequential again! It is a new type of container that allows you to put another type inside it. However sometimes the only way to access the contained value is by giving the container a function that takes a the boxed value as input and returns another container with a boxed value inside! The value never escapes the box. And so was the (IO)monad born! You can now take two IO actions a and b and turn them into c which is a combination of a and b where the output of a is piped into b. Not only can we send messages to the outside world, we can also finally receive them! Everyone was happy in haskell kingdom until the imperative migrants started writing monad tutorials... (including this one) This story is fiction by the way. As a bonus for all the wasted time. another crappy analogy: A cage inside a bird is given a machine that puts birds in cages. The regular tool called functor that only replaces what's inside the cage would give us a bird in a cage in a cage! The special tool gives us what we actually want! The tool named monad gives us a bird in a cage! No nested cages!

jejones3141 9y ago

No, no more than you need to understand group theory before you learn to add and subtract or ring theory before you learn to multiply. Better to teach how to use specific monads without using the dread m-word, and then say "You know, these all have something in common" and then talk about monads, or these days work your way up from Monoid to Functor to Applicative to Monad.