Am I crazy that I never understood the point of talking about monads? It just seems like a trivial pattern. It's like having a Subroutine Pattern, or a Variable Assignment Pattern. I'm all for investing in better primitives, but do these kinds of libraries really help vs implementing them from scratch with language primitives inside your (inevitably more complex) domain code?
The big problem with monad tutorials is that you can't talk about them without understanding the motivation behind them, and that comes from purely functional languages (i.e. Haskell). When you're not allowed to touch IO, use `null`, exceptions don't exist, there is no global state, and all of these things have a common pattern to them, then you can motivate their use and talk about them. In my opinion, there isn't much of a point in talking about them without those things. There are some neat tricks (`flatMap` etc...) but without proper motivation, it's not likely to stick, and the idea seems relatively useless.
So what you're saying is that these purely functional languages are so restricted that if you want to do anything useful in them, you _need_ this concept that nobody on the internet is able to actually explain.
Makes me want to use purely functional languages even less.
While this statement seems like common sense, there are plenty of examples of limitations creating a better language. I am quite happy that nobody can write goto in code that I have to work with.
> So what you're saying is that these purely functional languages are so restricted that if you want to do anything useful in them, you _need_ this concept that nobody on the internet is able to actually explain.
What do you define as useful? Reading a file and taking the first line maybe? Here's what you need to know:
Start ghci (I'm using stack[0], if you don't have stack you can also just use `ghci` here).
cody@cody-G46VW:~$ stack ghci
Using resolver: lts-2.16 from global config file: /home/cody/.stack/global/stack.yaml
Configuring GHCi with the following packages:
GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> import Control.Applicative ((<$>))
Prelude Control.Applicative> readFile "/etc/issue"
"Ubuntu 15.04 \\n \\l\n\n"
Prelude Control.Applicative>
Now we are going to use the $ sign which allows you to avoid extra parenthesis.
Prelude Control.Applicative> let add x y = x + y
Prelude Control.Applicative> let subtract x y = x - y
Prelude Control.Applicative> add 5 (subtract 3 5)
3
Prelude Control.Applicative> -- now using $
Prelude Control.Applicative> add 5 $ subtract 3 5
3
Prelude Control.Applicative> -- what's the point of me teaching you the $ operator?
Prelude Control.Applicative> -- it's similar to one we'll use to apply our lines function to what readFile returns
The duplication of fmap is getting kind of tedious to me. We can use function composition to avoid it. I'll use the add and subtract function definitions from above, but I'm sure it's obvious what those do.
Prelude Control.Applicative> let addFiveSubtract3 x = (add 5 . subtract 3) x
Prelude Control.Applicative> addFiveSubtract3 0
Now you know (hopefully) how function composition works, how can you use it for real stuff?
Prelude Control.Applicative> -- back to reading files and stuff
Prelude Control.Applicative> fmap (head . lines) (readFile "/etc/issue")
"Ubuntu 15.04 \\n \\l"
Remeber that seemingly pointless detour to teach you what $ does? Let's try using that.
There is an infix version of fmap called <$> which you might notice resembles $ with the addition of square brackets, kind of like it's in a box or something. Try removing `fmap` and replacing `$` with `<$>`. I'll wait here.
Now how can we print it out? Well, let's see what our type is:
Prelude Control.Applicative> :t head . lines <$> readFile "/etc/issue"
head . lines <$> readFile "/etc/issue" :: IO String
Something to know about Haskell is that it's okay to be naive and pick functions whose type signatures look like they do what you want. There are even search engines[1][2] that take type signatures and give you functions.
How could we go from `IO String -> IO ()`? Well, IO is a Monad (thing which follows some rules as defined by typeclasses). A monad defines a few things as you can see here:
But remember, we aren't interested in intimately understanding all that stuff... just in getting our functionality working. Maybe later we can circle back and figure stuff out at a deeper level.
The first function defined is >>=, whose type is:
(>>=) :: Monad m => m a -> (a -> m b) -> m b
What was that type we needed again? Let's compare these two:
(>>=) :: Monad m => m a -> (a -> m b) -> m b
If we look at the type of our function getting the first line of a file:
head . lines <$> readFile "/etc/issue" :: IO String
We see that it can fit into the m a part of this:
(>>=) :: Monad m => m a -> (a -> m b) -> m b
IO String
Keep in mind that m means Monad, as is specified in the typeclass constraint to the left of `=>`.
Now we can specialize our type signature to:
(>>=) :: Monad m => IO String -> (String -> IO b) -> IO b
What's an `IO b`? `a` meant anything so what does `b` mean? `b` actually means anything too, but a was already taken in the earlier part of the type signature.
If we look at the type of our putStrLn function:
putStrLn :: String -> IO ()
You might notice it fits into the second part of our new specialized type signature:
(>>=) :: Monad m => IO String -> (String -> IO b) -> IO b
String -> IO ()
aside: () is kind of like void, at least that's how I think of it. It's actual name is unit.
Cool, now notice that I put parenthesis around the infix function to make it a prefix function. Let's take those parenthesis off and use it as a proper infix function:
We could have also used do notation and the `<-` or "draw from IO to variable on the left, taking appropriate actions as defined by the Monad context you are in in the case of a failure". So if you are in the Maybe monad's context, a failure will cause a break (using imperative terms) and return Nothing.
There, now you know how to use monads and functors to some degree for a real problem and know the minimum knowledge (as far as I can tell) necessary. Why do all of this just to read the first line of a file?
Now that you know how the machinery works it's pretty simple and gets you composability and referential transparency.
Want to know more about Functors and Monads (maybe even applicatives O_o)? Check out Functors, Applicatives, And Monads In Pictures[3].
Dude, if you wanted to open a file and read the first line, then just do so. What you're doing is try to derive this simple task in a cery complicated matter full of weird symbols that, even if you don't believe it, are not entirely obvious. People who want the first line of a file want something that expressed that in an obvious matter, not with a baggage of functional programming theory.
> Dude, if you wanted to open a file and read the first line, then just do so.
After knowing how the Monads and Functors work, I can:
putStrLn =<< head . lines <$> readFile "/etc/issue"
There are advantages to separating pure and impure functions. Pure functions can be tested more aggressively with property testing for instance. They can also be optimized more agressively.
Most of the errors in software in my experience come from impure functions, so handling it in a principled way seems to reduce bugs.
> People who want the first line of a file want something that expressed that in an obvious matter
I feel like you mean to say "want something that expressed that in a familiar matter". The Haskell definition I used at the beginning of this comment is obvious to someone familiar with the basics of the programming language.
> not with a baggage of functional programming theory.
What functional programming theory? To put this into OOP terms this is just working with well defined Objects that adhere to an interface and whose failures are encapsulated in a sensible way.
edit: I agree it's harder to see or explain these advantages. Please give the tutorial I posted a quick once-over and let me know what you think. If you have specific criticisms about smaller and more specific pieces I think we could have good discussion.
To be honest I'm constantly re-assessing whether it's worth having to deal with the "baggage" of Haskell as you refer to it. However I go back to using other less principled languages and things simply don't ever seem to work out as well.
This is crazy talk. Scala (and .NET to a lesser extent) both make use of special language features for making monads easier to deal with, and neither of them forbid side effecting (IO). For comprehension and LINQ comprehension are both monadic comprehension for the operations flatMap and selectMany!
Monads are a fantastic way of handling errors, composing parsers, handling concurrency, parallelism, callbacks, and many other non-IO related things.
I'm not saying side-effecting IO is the _only_ thing that motivates the idea behind Monads, it's just one of the big ones. I mentioned more than just that, and the use cases you mentioned are also big motivators.
Great point, most are removing the force behind the emergence of the pattern. To add insult to injury, they explain it magister, by throwing concepts first, instead of bottom up, like non Haskell tutorials do (javascript, elisp, ...) that don't have advanced type system / Monad 'a, that blurs the mind, only choreography of a bag of lambdas.
> I'm all for investing in better primitives, but do these kinds of libraries really help vs implementing them from scratch with language primitives inside your (inevitably more complex) domain code?
Yes - the best way to build complex things is out of simple primitives. A lot of the time, making a custom type be a monad simplifies the logic - that is, you'd want to implement the monad operations (and support do notation) anyway. Calling them by their standard names makes it easier for other people to read your code, and being able to use generic library functions like traverse (which work for any monad) with your custom type is just a bonus.
I suppose it's nice to have a bunch of generic monad functions already implemented for you. Stuff like do-notation, applicative, sequence, mapM, join, etc.
