Hacker News Reader

Comment by jnordwick | Hacker News Reader

My general problem with Haskell articles and such: they are written as if you already understand Haskell. They make total sense if you know the language, but if you are trying to learn are mostly useless if not more confusing. Or even worse, they devolve into dense academic prose even when writing introductory articles.

Sometimes they even use Haskell as if you already know it to try to explain it.

I'm still looking for a basic article that describes monads well. My first few languages were all functional too, so that isn't the problem. I even still use APL derivatives.

View on HN

This was the article that finally made monads "click" for me when learning Haskell:

https://slpopejoy.github.io/posts/Effectful01.html

Actually, monads are pretty easy to understand, but learning to use them is harder.

Imagine two functions :

A -> k B B -> k C

Can you turn those into

A -> k C

Such that you can just think of it as functional composition? If you can, k is a monad.

The catch is, knowing what a Monad is is a bit like knowing what a saxophone is... the real problem is learning how to play it.

Cool. What does `k` stand for? A function?

A higher-level type (which is a function, if you allow functions in your type system). Examples:

List of a

One or zero of a

A randomly chosen a

A function that takes an s and returns an a and another s i.e. s -> (s, a) aka "a stateful computation returning a) A routine that reads a file and returns an a.

In each case, the point is that you can a) write code that acts as if the k isn't there and hence b) re-use code between all of these things without changing it.

I'm going to take the opportunity to recommend http://www.cis.upenn.edu/~cis194/spring13/. Do all of the exercises, even the really basic ones. What you learn by the end will blow your mind.

Thanks, I'll try it out! Is it applicable for someone with zero Haskell experience? Am I supposed to join a class which starts somewhen or how this site works?

It's literally just Brent Yorgey's lecture notes. Read the notes for week 1, do the exercises, repeat. I learned Haskell from scratch using it. Use stack and a random text editor.

What it won't do is make you fluent in modern Haskell. That would be a much longer course.

However, I guarantee that if you work through it you will have some great "Wow" moments.

Thanks! It is on my todo list now!

Just relax a little bit, the OP post is essentially notes from someone learning the language, not a "greybeard"

Read this: http://learnyouahaskell.com/chapters

Just don't skip chapters and read from the beginning to the end.

You advice here may be good; am not questioning that. However, question does come why can't there be a shorter explanation for people who already know programming. Most people are unable to explain it well, or at all, leading me towards a belief that they don't get it themselves as yet.

You can explain what a monad, for example, is, in one sentence, but it is useless if you don't show how it is used.

Similarly, you may know what eigenvector, or derivative function, is, but without practice you can't understand why you may want it.

I'm not looking for a single sentence explanation or definition. I'm willing to read more, and the structure you suggest of showing precisely worded definitions along with positive and negative examples would be great! However, I would not want to start with reading how to install a compiler, how to add two numbers in Haskell, etc.

I have similar issues elsewhere when people start with hello worlds and getting started in introductions to projects and programming languages without spending enough time on what the thing is about.

> why can't there be a shorter explanation for people who already know programming.

Why can't you learn chinese very fast if you already know a handful of european languages ? The answer is the same : the underlying concepts are different.

Sadly, there is no easy shortcut to understand these concepts. The best that can be done (and it's hard enough already), is to make learning entertaining.

The line of reasoning you have is correct as such, however, I find the analogy to be less than perfect. I do not need to be taught how to setup my computer for Haskell compilation or how to add numbers in Haskell to understand what is a monad.

Eh, I think you can skip most of the chapters if you've learned functional programming before. The important things to learn are typeclasses and higher kinded types.

I think half of people failing to understand monads are people failing to understand typeclasses or HKT while trying to learn about monads. Once you get those, all you need is the Monad typeclass definition and a huge pile of motivating examples.

Yet people learn best from examples, so I don't get why every monad explanation is in reverse like that.

The Z is Y. The Y is an X that does W. ...omitted... Here's C, B and A. Now you understand!

First comment in this thread is exactly like that. Definitions, not explanations.

And then after telling you how monads are different than map for things that are _not_ lists, a bunch of follow up comments talk about... Lists.

Pedagogy does not work like that. What is it about haskell that ruins people's ability to explain things?

>The Z is Y. The Y is an X that does W.

I'm not saying you shouldn't use examples to learn, I'm saying you should probably learn X and Y (type classes and HKT) before you try to learn Z (monads). Use as many examples as you like to learn them, but if you don't understand type classes and HKT, you will probably struggle to understand monads.

> What is it about haskell that ruins people's ability to explain things?

Haskell is the most maddening language to learn purely because of the community around it.

I've noticed the same thing - Haskellers are terrible at describing them. I'm not at all a Haskell expert, but I think I understand enough of Monads to explain them.

Yes they are as simple as people claim they are, and if you've done any functional programming you may already know them.

1. Imagine a datastructure and a value. In this case we'll use "List" as the datastructure, and "Int" as the value. So [3,4,5]. It's type is List<Int>.

2. Next we'll take "f" as a function that converts a single value to a list of values (ie a datastructure of our values). In this case the function takes a value and outputs a list of 3 copies of the value.

ex. f(8) = [8,8,8] The type of f is: Int -> List<Int> // Takes in an int, and returns a list of ints.

Also imagine a function "g" that does the same thing but makes 5 copies of the data. ex. g(7) = [7,7,7,7,7]

It has the same type as f: Int -> List<Int>

3. How we apply the function to the data: Frequently when we have lists and functions over their values we will call map over them. _.map(f, [3,4,5]) = [[3,3,3],[4,4,4],[5,5,5]]

Notice that we don't get out a list of ints (type: List<Int>), instead we have a list of lists of Ints (type: List<List<Int>>).

We also often like to create/compose chains of these functions to create a pipeline to transform the data. So normally we would want to do something like: r1 = _.map(f, [3,4,5]) r2 = _.map(g, r1)

But we can't. r1 is of the wrong type to pass into the second map. r1 is a List<List<Int>>, but the g is expecting a List<Int>. So how do we fix this.

How do we turn [[3,3,3],[4,4,4],[5,5,5]] into a flattened list of ints? We append them.:

[3,3,3] ++ [4,4,4] ++ [5,5,5] // where ++ is list append in this language

the end result is [3,3,3,4,4,4,5,5,5]. Which is perfect. This is now something that we can pass into the _.map(g, ...) above.

We first 'mapped' transforming List<Int> -> List<List<Int>>. Then we "flattened" so that List<List<Int>> became just List<Int>. This allowed us to run map with g next.

This combination is bind.

Now the absurd part. If you've used something like C#'s linq there is a function that does this. It's called "SelectMany()". SelectMany is bind. It converts each element in a list to a new list, then flattens and appends the nested lists into a single list.

Bind is nothing more than SelectMany().

The only notable piece is that bind is abstract. There are different incarnations of bind for each datastructure. SelectMany is the bind for Lists. There is a different implementation of bind for "Maybe" type. Or other datastructures.

And a Monad is nothing more than a datastructure that supports SelectMany/bind. List is the one that you use all the time. The selectMany concept generalized to any datastructure is the concept of bind + a Monad.

This seems too simple. Then what is all the business of using them to contain side effects, like the IO system? Others talk about controlling program flow.

What you described is flatMap in Java, or join() in other languages. Somebody above went into the CPS transform of a program. I'm so lost at how simple this is versus how complex all the descriptions are.

>This seems too simple.

There is a reason people say monads are simple.

The comment you are replying to is describing the concrete example of the List monad. To answer you direct questions, it is probably better to look at another example: the State monad.

The idea behind state is simple. Suppose you have a bunch of functions that you want to call in sequence. This is a simple enough problem; just do f(g(h(x))) or `h(x) |> g |> f` [0].

Now, suppose that, in addition to piping a value from one function to the next, we want to keep track of additional state. For example, maybe we want to use a psuedo-random number generator in some of the functions and have to keep track of its internal state. One way to do that would be to simply modify each function so that the returned value includes the state; but this quickly becomes unwieldy. The State monad provides a way to automatically thread the state through the functions. So we can do:

    put initSeed >>= h >>=  (get \currentSeed -> g currentSeed) >>= (get \nextSeed -> f nextSeed)

or (with a bit of syntactic sugar:

    put initSeed
    h
    currentSeed <- get
    g currentSeed
    nextSeed <- get
    f nextSeed

in this example g and f would be expected to call put to update the internal state.

Now, suppose you want to keep applying a function until some condition becomes true about the state. In this case, it makes sense to talk about a while loop:

    while (get >>= \state -> state =/= 7) f

The above snippet will repeatadly bind f until the internal state is 7.

It turns out, that we can implement while in terms of only the Monad interface:

    while condition action = do
        x <- condition
        if x then (action >> (while condition action))
            else return ()

It turns out that most control structures can be encoded into monads in this way.

The IO system is a bit hacky. The idea is that the universe is a big state machine. So, when we do `println "Hello World"`, we are not causing a side effect, we are just updating our internal state to say that we printed "Hello World". Simmilarly, getLine just peaks into our internal state to see what the input at the current time has always been. Of course, for some reason, GHC does not give us the full get or put functions for the IO monad; but they could exist in theory, and that is enough to pretend that side effects do not exist.

[0] Not actual haskell because we can't agree on a name for the pipeline operator I am calling "|>" here.

That's the thing with powerful abstractions: they apply to so many things that seem unrelated, that it may be difficult to see the connection. But that's where all the power lies: being able to use a common abstraction across so many different problems gives you extremely powerful means to express generic operations.

Say you wanted to iterate over a list of image files and apply a transformation to them. In haskell, doing that work synchronously and doing it asynchronously can use the same function, just in a different monad, because the definition of bind determines the execution strategy.

The monad abstraction provides a way to encode a dependency between "operation 1" and "operation 2", or inject behaviour between "element 1" and "element 2" when processing a data structure.

The type signature of bind is "m a -> (a -> m b) -> m b". It might look complicated, but it states "given a monadic value with an inner type of a, and a function from a to a monadic value with inner type of b, you will get a monadic value with inner type of b"

This can be used to access data "inside" a type where you might not have direct access, in such a way that bind determines how the access happens so that it can enforce things like "The preceding IO must have been finished" or "The future must be completed" or "The list values must be concatenated" or "You must compose the continuations properly" or "If any operation results in Nothing, the result is Nothing"

Haskell IO is the usual example of this. Since the IO type is opaque, you cannot construct values of IO yourself directly. An IO String (such as getLine) represents an IO operation that results in a String value. Similarly, the "putStr" function (of type String -> IO ()) is a function that takes a string and results in an IO action that "does something and the value does not matter", or in this case, prints the string to the screen.

However, you can't just compose getLine and putStr directly, because the types don't match. You need to get the value "inside" getLine first.

This is what the bind function allows you to do. And it's defined for the IO type, in such a way that IO ordering is enforced. You can't not use bind, because you have no way of accessing the String value inside getLine without it.

I don't know if my explanation helps. The seeming "complexity" of monads arises from the fact that you can apply the same simple abstraction to so many different things, often in seemingly unintuitive ways.

Just to expand a little bit upon the sibling comment.

Let's say you need a function that maintains internal state. Now, in non-pure languages, you could that by simply referring to some global variable, but let's agree that's bad. So how can you model internal state purely?

Simple, your function takes the current state and produces a new state, along with its result. So, a pure function like:

    f(String) => Int

turns into the stateful function:

    f(String) => (State => [Int, State])

I.e. a function that returns a function that takes in a state and produces a result and a new state.

Cool, but now let's say we have another function g:

    g(Int) => (State => [Double, State])

Let's now say we want to compose those two functions:

    let result = g(f("5"));

However, this won't work, becase f produces (State => [Int, State]) but g expects Int.

So, here's bind for the State monad (implementation is not important):

    bind(State => [a, State], a => (State => [b, State])) => (State => [b, State])

If we define a "type alias" (just a synonym, so we don't have to type that much) for a stateful function:

    type StatefulFunction<a> = State => [a, State]

and then replace the above bind definition with it:

    bind(StatefulFunction<a>, a => StatefulFunction<b>) => StatefulFunction<b>

you can see that is has the same structure as flatMap!

    flatMap(List<a>, a => List<b>) => List<b>

With the type alias, f and g would then look like this:

    f(String) => StatefulFunction<Int>
    f(Int)    => StatefulFunction<Double>

So now, here's how you compose f and g:

    bind(f("5"), a => g(a))

In Haskell, there's syntax sugar for bind, so the above turns into

    do
      a <- f "5"
      g a

which is very similar to a conventional language:

    {
       a = f(5);
       g(a);
    }

EDIT: forgot result type in bind and flatMap.

That at least gives me a base. I did wonder why you say flatmap is

> flatMap(List<a>, a => List) => List

but that isn't the same as bind, since bind took two functions and flatmap takes a list and a function.

However, I do kind of understand. Compare this to the (currently) 3 responses below that quickly turn into text mush simultaneously treating me like an idiot who has never understand abstraction before or treating me like I'm been programming Haskell for a decade.

At some point I'm just going to cut my losses and ignore Haskell. It isn't the language, but the less that elucidating community support.

Compare again:

    bind(StatefulFunction<a>, a => StatefulFunction<b>) => StatefulFunction<b>
    flatMap(List<a>, a => List<b>) => List<b>

Look at the structure. Don't pay attention to what List or StatefulFunction actually are, that's not important here. The thing to focus on is that if you can provide this kind of general function for something, then that something is probably a monad.

I.e. a function that takes in Something<a> and a function from a to Something and produces Something.

So why is this pattern so useful that everybody freaks out about it?

Well, that syntax sugar I showed you at the end, let's look at it again:

    do
      a <- f
      b <- g a
      h b

The general idea here is that "a <- f" is translated into bind(f, a => ...). The whole block would turn into

    bind(f, a => bind(g(a), b => h(b)));

Bear with me. Now, let's look at one more example:

    bind(Optional<a>, a => Optional<b>) => Optional<b>

Optional<a> is just a data type that maybe contains an <a>. Think of it as a safe replacement for null. So, bind for Optional looks at the first argumenta and passes it on to the function and returns its result, if the Optional is not empty. If it is, bind also returns an empty Optional.

Now let' say we have a bunch of Optional producing functions:

    getUser(userId)    => Optional<User>      // user may not exist
    getAddress(User)   => Optional<Address>   // user may not have entered an address
    getStreet(Address) => Optional<Street>    // address may be weird

Now ok, what would we do in a language without monads?

   user = getUser(userId);

   if (user.hasValue()) {
     address = getAddress(user.getValue());

     if (address.hasValue()) {
       street = getStreet(address);

       // do something
     }
  }

Well, that's not great. But because Optional is a monad and we have that nifty bind sugar, that's how that code would look like in Haskell:

    do
      user    <- getUser userId
      address <- getAddress user
      street  <- getStreet address

Much better.

More generally, it turns out monads are literally everywhere. The guy that talked about CPS transformed programs being monads is right - that's the continuation monad.

Let's look at that. If you know node.js, you know that its API is basically asynchronous:

    fs.open(path, callback)
    fs.read(fd, ..., callback)
    fs.close(fs, callback)

Now, let's read some file in node:

    fs.open(path, function(fd) {
      fs.read(fd, ..., function(result) {
        // do something with result

        fs.close(fs, function() {
          // file closed
        }
      }
    }

Well, that's ridiculous. But becase we have the continuation monad, we can write exactly the same thing in Haskell:

    do
      fd <- open path
      result <- read fd

      // do something

      close fd

So why are monads so useful? Because they are so general. They can be used to abstract over many many things that exhibit the basic pattern (S<a>, a => S) => S. Not to mention that when you write a function to generally work with monads, it will work for ANY monad. List, State, Maybe, Cont - doesn't matter.

There's not much more to it than recognizing that pattern. That's it. Once you see that that's literally it you'll start seeing monads everywhere :)

> Let's say you need a function that maintains internal state. Now, in non-pure languages, you could that by simply referring to some global variable, but let's agree that's bad.

Instead of Stone Age ideas like global variables, you could create a Lisp or Javascript closure, or use a C++ functino. Do monads offer a big enough advantage over those approaches to justify the endless trouble of learning them?

In Lisp, you should use a global variable when you need a persistent module-level state, and let your defun forms be top-level forms:

  ;; bad
  (let ((s (make-state-thing)))
    (defun function () ...)))

  ;; good
  (defparameter *s* (make-state-thing))

  (defun function () ...)

That defparameter might be defvar: it depends on whether you want to re-initialize the state variable when a new version of this module is loaded, or keep the old value.

Speaking of which, with the let, you don't get that decision. For the defun to have its effect, the form has to be evaluated. Every evaluation of the let instantiates a new binding for s in a new lexical environment, end of story.

Even if we have the defparameter, we can redefine function while keeping the same state.

It's also easy to inspect the state. A the REPL, just evaluate its name: there it is. You don't have to whip out a closure environment inspector.

defun is a "stone age" tool anyway, which destructively overwrites a global function binding. Wrapping it with a captured lexical environment is a form of situational irony in programming (if not indeed verbal).

Maintaining state was just one example. See my other comment [0] for others.

Regardless, you can't maintain state with closures in a pure language. You could close over some local "variable", but that variable would be immutable. In an impure language that would work, but then you're back to managing global state, even if that state is not defined at the top level (i.e. global in the sense that different closures could still have access to the same piece of state, concurrently).

[0] https://news.ycombinator.com/item?id=13965917

EDIT: just to clarify, monads manage state purely. I.e, instead of writing:

    function statefulFunction(state) {
      (a, state1) = f(state);
      (b, state2) = g(a, state1);
      (c, state3) = h(b, state2);

      return (c, state3);
    }

you can write:

    statefulFunction = do
      a <- f
      b <- g a
      c <- h b
      return c

But the resulting function is still pure, i.e. (state) => (c, state).

> This seems too simple.

So this is one example of a Monad. Go through the same process with different "datastructures" to see the power of it. First try with a "Maybe" monad, and then a "State" monad. The generalization of that idea is the monad.

The power comes not from the complexity, but from the realization that this simple idea applied in alternate contexts (ie on different datastructures) allows many powerfull solutions to problems.

The idea is fundamentally simple - applying that same simple idea in different contexts provides the value. It is a simple idea, it's just impressive how many different contexts it works in to solve problems. Problem domains that we normally would have felt have nothing in common.

> I'm still looking for a basic article that describes monads well.

I really like this one: http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...

Try this one. Haskell in pictures: http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...

http://dev.stephendiehl.com/hask/#monads

Are you serious?

> Monads are not complicated. They are implemented as a typeclass with two methods, return and (>>=) (pronounced "bind"). In order to implement a Monad instance, these two functions must be defined in accordance with the arity described in the typeclass definition:

This is a great example of what I just said: it uses complex Haskell code and functions to describe a monad. If you already know what it assumes you know, you most likely already know what a monad is.

If I define this in c++ lingo words barely change.

You take a c++ parent class with two virtual methods. These methods are "return" and "bind". In order to implement a monad instance you must derive from this parents class and implement the virtual methods.

What is bind and what is return? What do they do?

I was translating your quote to c++ lingo not defining functions.

return takes a value and returns an instance of your template class containing the value.

bind takes an instance of your (template class A) a function of (type a ) to (template class B) and produces a value of (template class B).

If you don't care about the "laws" your definitions are expected to follow thats it.

The idea bind is you take a value of a template class such as (std::vector<Int> type) the value {3}, then based on value either pass it to the next function or return it.

one definition of bind would be if the vector is empty return it, if its not empty pass it to this function and return the result of that function.

return is just a way of placing a value into your template container class.

I posted that because I think it's the best you're going to get.

Monads can be two things: (1) a concept in category theory, (2) a rough implementation of that concept in a programming language.

If you want to learn about monads from the category theory perspective, great! This is really hard though, I wouldn't recommend it for most people (and haven't really even succeeded myself).

If you want to learn about a specific programming language's implementation of monads, you will naturally have to know how that language works. This road is far easier than category theory, but still requires knowing (for Haskell) what a typeclass is, what a higher-kinded type is, etc.

It sounds like you want an explanation without prereqs from either category theory or Haskell. If you google for monad tutorials you will find dozens of quick explanations, but I personally don't think this is a good way to actually understand them.

Describe monads to Lisp, Scheme, APL person.

You can do that with the y-combinator but why not monads?

Because these languages lack a way of discussing something at the right "higher order" as Monads. You can implement them, but there's no word for the kind of thing a monad is. There's not even a real word for a type.

You need types. Then you need "higher order types" or parameterized types. Then you need a way to discuss a common set of operations which appear repeatedly for some of these parameterized types and it can't be OO-like.

You can exemplify the operations in, e.g., Lisp, but you have a hard time "talking about" the thing.

---

In Scheme, monads are the answer to the following question:

The functions (define (pure a) (list a)) and (define (join ls) (foldl append (list) ls)) are related to lists in the same way that (define (pure a) (lambda (k) (k a))) and (define (join z) (lambda (k) ((z k) k))) is related to CPS-transformed programs. What is the commonality?

Here is monads in JavaScript https://curiosity-driven.org/monads-in-javascript

Here you go, monad explanation in CLOS:

http://www.kylheku.com/cgit/lisp-snippets/tree/monads.lisp

Apologies for there not being a use example for the state transformer monad/comprehension. I can whip one up if needed.

To understand monads one must first understand monads.

I'm not even saying that a bit sarcastically. I've read countless "tutorials" and even tried messing around with Haskell in an attempt to grok monads. According to the link shared by GP comment, my understanding is still completely wrong.

There is a reason there is a joke about it.

"A monad is just a monoid in the category of endofunctors, what's the probleⅿ?" - James Iry, taken from [0]

[0] http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...

I consider that quote to be a demonstration of the simple/easy axes referenced in a relative of this comment. It demonstrates that monads are simple things, since endofunctors, categories and monoids are all simple concepts.

As a scala developer the thing which got me on my way was the explanation "something which has a flatMap method". That's not entirely true but it gets you in the right ballpark.

Well, you really should know the amount of Haskell it assumes you know (typeclasses, maybe infix functions, arity etc) before learning about Haskell monads. Otherwise you're learning multiple concepts at once - why not learn about those other concepts in other contexts first? The Stephen Diel article even lists the prerequisites explicitly.

My favourite monad explanation is Tikhon Jelvis's at https://www.quora.com/What-are-monads-in-functional-programm..., but reading through it, it does assume some prerequisite knowledge about Haskell.

Simple /= easy. Complex /= hard.

Monads are very simple. They just aren't easy because most people don't have the base of terminology. When you grok them you'll laugh because you'll realize how simple and powerful and obvious they seem in hindsight.

This is the reason so many people write monad tutorials after they learn them. It's actually really weird. Does anyone else have some examples of things they learned which seemed really difficult but turned out to be really simple in hindsight?

> They just aren't easy because most people don't have the base of terminology

That's like saying a giant, complex library with a nice, tight API is 'simple'. It's not, the complexity is just hidden.

Same thing with monads. Once you understand some of the machinery of category theory, or really grok functional programming, then yes, monads are 'simple', but all the complexity lies in getting there.

I think you're confusing complexity with learning curve. Complex things can be made easy to learn, if, for example, you have "a nice, tight API." Monads are the opposite. They are simple things that are difficult to learn.

Why would something be difficult to learn if there wasn't complexity underneath it?

There are lots of things that are simple to state, like the fundamental theorem of algebra, but the machinery behind it is complex.

A simple thing can be difficult because understanding why it works may be nontrivial. However, it remains simple (by definition) if understanding is not affected by complecting factors such as side-effects or the global state of the system. A pure function is always simple, even if it implements a difficult algorithm.

I hold the opinion that complicated things can never be truly easy: they can only have the appearance of ease until there comes a time that you must understand all the complexity.

Because it is far away from what you already know.

Haskell is a fairly simple language, but it very difficult to learn compared to a language I would consider much more complex like Java, because you cannot reuse as much of what you have learned from other languages. All the monad implementations are just a few simple lines of code, and understanding monad is just a matter of reading a few, reading the rules, and doing enough with them until their utility clicks. However, the type of abstraction they are and the way they are used are very different from the programming you are used to that they seem harder to learn.

I'll provide an example in math. Linear algebra is much simpler than calculus. Yet we teach high school students calculus but not linear algebra. Why? Because a lot of the complexity in calculus can be hidden away behind some hand-wavy definition of a limit and consider basically only smooth functions. That way, we have engineered our math classes to avoid the complexity underneath, and we have high school students finding calculus to be easy to learn.

the latter phenomenon occurs at least three or four times over in good (rigorous, proof-based) math classes.

I've had this happen for

- everything from linear algebra (at least 20 things) - all kinds of stuff from mathematical optimization - inequalities, which are really difficult until something "clicks" and then when to apply them becomes obvious, cauchy-schwartz and jensen's in particular - induction (this was a long time ago / early in my math career) - diagram chases - the entire typeclass stack from FP (functor applicative monad, then all the monad interfaces) - huge chunks of axiomatic probability and measure theory (what do sigma algebras really mean, what is a good definition for integration, what is continuity of measure, dinkin's pi-lambda theorem) - and so it goes on

I am still waiting on some of the following things to click so that I may abuse them productively as well:

- LLL - yaos min-max theorem - lots of results from logic

I surmise this happens for monads and freaks developers out because it's one of the few pieces of serious math (i.e. no handwaving, given as a rigorous construction, etc) most people come across, so the phenomenon catches people off-guard.

If you like this thing, do more math!

I do like this thing! I love math. I tutor young people in math at a local school. I've applied to an undergrad math program at Toronto and Waterloo as well. Hopefully I can get in...

>> Simple /= easy. Complex /= hard.

Beautiful insight. I now realize that simple and complex are about the concept being learnt, and easy and and hard likely to be about the process of learning. There would be correlation in general, however, not always. :-)

I have seen many examples of things which are easy at the end, but the process of reaching there was hard, sometimes because of initial ignorance of my own or of mankind overall.

Beautiful insight

I wish I could take credit for this one! I learned the distinction from a (rather famous) Rich Hickey talk. [0]

[0] https://www.infoq.com/presentations/Simple-Made-Easy

continuations? closures?

things that are very similar to other things when expressed concretely, but actually exist at different levels of abstraction? things that are counter-intuitively awkward to express by way of examples, because too many things are examples, sometimes in multiple subtly different ways?

adjunctions (etc.) in category theory seem like 'above paragraph : the movie', but i can't claim to understand them in full generality so i'm unsure.

> Does anyone else have some examples of things they learned which seemed really difficult but turned out to be really simple in hindsight?

Sure: everything.

Everything is complicated until you learn it, and then it looks simple in hindsight.

You're just confirming what OP said: it's not easy to come across an article explaining monads or Haskell that doesn't implicitly rely on the fact that the reader already understands monads or Haskell.

>Monads are very simple. They just aren't easy

Yeah, we don't care for simple. Can you explain them in an EASY way?

Lots of people already have. The problem is that those who try to read up on it haven't built the conceptual bridge to get there. Monads are a simple piece but they sit atop a tower of simple pieces, none of which can be skipped. People who hear about Haskell try to jump in and learn them without having the foundation they need. They see the superficial similarities between Haskell and other languages but fail to grasp the more significant differences: higher-kinded types and type classes.

>Lots of people already have. The problem is that those who try to read up on it haven't built the conceptual bridge to get there.

No, as someone who understands monads (and not thanks to the explanations usually given) the real problem is that most explanations are crap and needlessly complicate the matter. Including every one I've read thus far (well, up to when I made my comment) in this thread.

It's as if they can't lay off Haskell notation and concepts for a moment to give people the overall picture. People, stop mentioning "functors", "monoids", ">>=", "bind" etc in your Monad explanations. Also drop the Haskell function definitions.

Even fmap shouldn't be taken for granted (as something already known) in a Monads explanation. Just describe what it does, giving a simple example. And when talking to Javascript programers use types and names of types that they already know, such as "array", not List. Even such simple terminology distinctions like those matter.

>They see the superficial similarities between Haskell and other languages but fail to grasp the more significant differences: higher-kinded types and type classes.

The whole magic of explaining is to give an idea of the "significant differences" without requiring any foundation beyond what an average blub programmer already has.

The condescension bugs me a little: I must not have enough background, Haskell is too high-level for me, etc...

I'm a pretty good developer, and my language skills are all over the place. I did a lot of Scheme and Lisp early on. I used to try all the turing tarpit languages. I do mostly C++ and Java systems work now. And my current learning is Go and Rust. I've literally written my resume in PostScript years ago, and I still use APL-derived languages. I read and learned lambda calculus over a cross country business trip even.

And even with this background I find Haskell at times inscrutable, more often than not because somebody is trying to give me a description filled with unknown terminoligy and lines of Haskell itself I have no idea what it means.

There concepts aren't foreign to every other languages. Show them to me in pseudo-lisp, and I'm sure I'll do a pretty good job of picking them up. It looks like you could even describe monads in C by passing around opaque pointers, with some caveats.

Reply on news.ycombinator.com