One thing that made it difficult to me was that I didn't explicitly realize for a long time that there were two things to understand: what a monad is and why they are useful. Most explanations tell why it's useful, but it really clicked for me when I read through the book "Haskell Programming from First Principles" (Julie Moronuki, Christoph Allen) [1] and got to the monad chapter, which if you read the previous chapters explains really clearly what a monad is.

The way I understand monads: some data structure plus 2 functions, "return" and "join":

- "return": wraps something with the data structure. (no relation with the return keyword you are used to in most languages)

- "join": joins 2 layers of the _same_ data structures into one.

And that's it. It's just that simple what a monad is: in java it would be an interface with just these two methods.

Examples:

- "return" for List: takes a value and returns a List containing just that value.

- "return" for Maybe: takes a value and returns Maybe value.

- "join" for List: takes a List of Lists and returns a flattened List (2 outer layers joined).

- "join" for Maybe: takes Maybe Maybe value and returns Maybe value.

I think what makes these functional programming concepts hard to grasp most of the times is that communicating the boundaries of abstract concepts is hard in general, even if the concept itself is really simple, like a monad can be for a programmer.

As for why monads are useful, the explanations you can find online give a lot of examples. Just think of all the times you may have used flatmap for arrays: that's just map followed by the "join" for arrays, which is sometimes called flatten. The other operators you see used in haskell, like "bind" (>>=), can be derived from "join" and vice versa and are just conveniences to write code with less noise, like flatmap is.

Recap: monad is the name of the concept for things that have a "join" and a "return" functions defined. Basically "join" is the distilled concept of what a monad is.

[1] https://haskellbook.com/

(edit: formatting)

This is very relatable :) A workmate and I have fun making variations of "A monad is just a monoid in the category of endofunctors!" and sarcastically suggest the other tries OCaml, Haskell, or Idris when something isn't going their way.

When you have some spare time write a function that returns a Maybe<Value, Error> and see what a pain it is to compose multiple of them.

Then, try store your programs state by passing it as a function argument to every function so it stays available for the lifetime of the program (no mutable state? This is basically what happens)

After realizing what a pain this is and wishing for boilerplate, look at the State monad. This is what did it for me :)

I don't see why I would ever want to do the first one in real life, when exceptions exist.

I'm honestly not even sure what function composition is, or why you would compose two functions instead of just explicitly making a new function that calls the two original ones.

The second one makes more sense because of the rumored bug-freeness of side effect free apps, but it seems like for that too, you'd need to understand a lot more than just monads.

Function composition is connecting the output of one function to the input of another. In math it is (f ∘ g)(x) = f(g(x))

Or in javascript:

function f(x) { return x + 1 }

function g(x) { return x + 2 }

f(g(1)) === 4

In functional languages like Haskell function composition is made easy, because functions can be partially applied. Partial application means that given a function that takes two arguments, I can call it with one argument and it will return a function that takes one argument which returns the result. Whereas in languages like javascript it is difficult because functions can have different numbers of arguments and there's no way to partially apply them or flip their arguments, so it is difficult to chain functions together. And because javascript functions aren't pure, they may not have any result which can be composed with other functions. In a functional language, functions are more like the functions in math. In most non-functional languages, functions are more like a procedure of commands. For example, the javascript function logMe(x) { console.log(x) } doesn't return anything. So it can't be composed functionally, and is not like a "real" function.

JavaScript has closures. When you want to partially apply something(Which is technically never, because we would probably describe it in different words and think of it differently) we just make a new function.

When we want to "compose" two functions, there's f(x){return a(b(x))}.

It doesn't matter if the signatures are different, you don't need any nice logical idea of composition, you just explicitly build the new function that does what you want.

I would say that is a lot easier than real composition, because real composition requires you first learn to see and think in terms of patterns you would want to compose in the first place.

Also, function chaining doesn't use intermediate variables. Named variables are like free documentation. With composition you have to actually remember what you're doing. Making everything explicit makes it easier to comment what's happening.

Regular programming is to math as cooking is to chemistry. Functional brings the math back to programming. Math is useful but also hard.

In OOP, more often you're doing the equivalent of:

if crinkle(a(b(x,68), modes.FOO).bar.baz(9)): x = foo() else: x = wipe(7).bar()

And I think it's a lot nicer to just spell it out with meaningful variable names, instead of trying to compose it like an equation.

Not every step has a meaningful name. And usually you already have the name of the function. For example:

    let batter = mix(water, flour)
    let saltedBatter = add(salt, batter)
    let risenSaltedBatter = letToRise(saltedBatter)
    let bread = bake(batter)

on the other hand:

    let bread = bake(letToRise(add(salt, mix(water, flour)))

The first example leads to awkward names and useless variables. The second example feels cleaner to me. Interesting that you take cooking as an example: recipes usually don't name most of the intermediate steps, they describe the actions you take and the ingredients you use. Most recipes also use composition a lot. You start with your actions/functions (cut, cook, bake, dice, etc) and you do a recipe out of them. You don't create new "functions" (actions) specifically for each recipe.

Recipes are a lot closer to configuration DSLs than code though.

You have standard functions like bake and boil, and they don't tell you to use clean utensils or how to turn the stove on, because an cooking is basically just a few dozen standard functions, end condition rules, etc.

If you think of them as programs, the composition they use isn't the same as functional languages, because the individual steps are unstructured and there's no generalized abstract pattern defining what a RecipeStep is or what composing two of them means.

You wouldn't say add(flour(add(salt,empty))), you would say "add flour, salt, water, and yeast".

"add" can take either an ingredient or a list, and it's pretty encapsulated, since it dynamically selects a way to measure the ingredient based on what it is, what utensils you have, etc.

It could trigger dozens of unrelated code paths based on state, and probably includes error recovery.

Functional might be nice for implementing the internals of that add() function, but in OOP the idea seems to be that it's a pretty minor detail, since add() is only written once and rarely changed, but used millions and millions of times all over the world for a decade.

Usually when people talk about "the beauty of functional" I get the impression that they're not really doing a whole lot of "One really smart function that knows exactly what to do" level abstraction.

It seems like they'd literally be composing together their own variations of what "add" is, as needed from the raw findMeasuringStrategy and checkPantry functions instead.

I feel, in your example, that the first code block is infinitely more useful to the maintainer than the second. It literally tells the reader what each step is *supposed* to do.

That second example tells the reader that it is doing, which may or may not be what it was supposed to be doing.

As a maintainer, I prefer knowing that:

    (add(salt, mix(water, flour))

is supposed to result in a salted batter, which the first code block tells me but the second one does not.

My whole point is that sometimes intermediate steps don't have good names. I often have to apply multiple transformations to a collection, but only the first and last step have a name because the intermediate steps are just that. "salted batter" is not a thing, it's just a placeholder name because you needed a name. You will never use "salted batter", you'll only use ingredients and bread.

> You will never use "salted batter", you'll only use ingredients and bread.

For write-only code, sure, that's great.

It's irrelevant when I am tracking down a bug - the label 'saltedBatter' tells me what that intermediate result is supposed to be.

If, when debugging, I find that `add(salt, batter)` results in something else[1], using your convention it is literally impossible to tell that the value is supposed to be `saltedBatter`.

There is literally no way to tell if the intermediate values are correct. Maybe each caller in the composition chain can throw an Exception?

The point is, the variable names are helpful.

> but only the first and last step have a name because the intermediate steps are just that.

That describes the entire program :-)

In all seriousness though, it's because you intend to describe steps in the process that throwing away all labels for the intermediate steps makes sense.

You're describing verbs. We don't need to know the in-between verbs for a verb. When you call `driveTo()`, it is not necessary to know all the verbs involved in that action, it is enough to know that it will attempt a certain action.

Verbs answers the "what we are doing" questions.

Variable names answer the "Why we are doing it" questions - `saltedBatter = foo (bar(), baz);` tells the reader why foo is being called.

We don't even need to know the steps involved or even what the other variables (used as parameters) should be. Assigning the result of a function to a variable ensures that the maintainer knows if that variable ever holds the wrong value.

I think where a lot of this value (variable-names) is lost is in enterprise development - the names are never helpful, they're just a differently-cased version of the type. Like these gems I see daily:

    SomeClass someClass = foo();
    List<OtherClass> otherClassList = bar();
    ....
    return baz(someClass, otherClassList);

So, yeah, I see your point if all you ever see is enterprise-grade naming conventions. OTOH, if those above two lines were written as:

    SomeClass needle = foo();
    List<OtherClass> haystack = bar();
    ...
    return baz(needle, haystack);

you, as the maintainer, know exactly what that last line is supposed to do, and if it isn't doing that, then you know it's a bug.

Compare with this:

    return (foo(), bar());

Or, if you wanted descriptive function names:

    return (calculateResult(), userSubmittedList());

Brevity is not a virtue in programming languages and/or programs. It's probably why Haskell is still not even a rounding error as far as popularity goes.

[1] Maybe `doubleSaltedBatter`, in case an upstack caller used `saltedWater` in place of `water`, or perhaps `pepperedBatter` in case a caller switched out the salt for pepper.

> Brevity is not a virtue in programming languages and/or programs.

Real world Haskell code isn't the codegolf you are implying.

In fact, I think real world Haskell devs overcorrect and make code too verbose.

Also, "brevity is not a virtue in programming languages" is something I disagree with.

Walls of verbose code are just so damn mentally taxing. Especially hen you finish reading and saybto yourself "all that code just to do X?".

> Functional brings the math back to programming. Math is useful but also hard.

So is working with an edifice of unprincipled ad-hoc abstractions, but many seem to prefer pushing that debt on tomorrow them or others.

JavaScript has bind() on functions which works well enough. You can partially apply arguments, but I don't think you can project them to a different order.

Maybe this article will explain my point about errors a little, it also covers function composition, and I think is approachable. I guess the only advice I have for you (or anyone) with monads is to look at concrete examples first and not care about the theoretical bits. Intuition comes from use. Is it useful to know in non-functional languages? Probably not; you'll use them without realising and probably make them yourself without realising!

https://medium.com/swlh/monads-in-python-e3c9592285d6

A function that can return a value or throw an exception is pretty similar to Maybe<value,error>

I'm not clear why the next function in the pipeline would need to know about the error rather than the caller, but that happens with promise chains too

> I don't see why I would ever want to do the first one in real life, when exceptions exist.

Exceptions usually aren't typechecked.

Lots of languages only let you throw stuff if explicitly declared.

Which ones? I'm not aware of any that has only checked exceptions, at least in the mainstream ones.

I've been pretty deep in to functional programming for years including implementing my own little lisp with macros and all that shit and I still couldn't confidently tell you what a monad is. I read those articles sometimes when I come across them and feel like I understand a little more of... something... and I mean I have some intuition for what they are but still I don't really get it and never have.

I remember one time I found an article that explained it. For a brief moment I thought i understood. But I didn't see what was in any way interesting about them, so that probably requires a whole other level of knowledge.

All I know is they contain values and you can pass them functions, and somehow by doing this you can write fully pure programs with supposedly fewer bugs, and Haskell programmers seem to not understand why this is hard.

> Still don't have even the vaguest beginnings of a clue what the fuck a monad is, after reading 50 articles promising to make it simple, as well as their accompanying 500-comment HN threads.

I have an article i'm about to publish that will have a lot more real world examples... hopefully it can bridge the gap.

It'll also have exercises, which are honestly the most important part of understanding.

I am a C# programmer, and this series by Eric Lippert really helped me to understand what the fuck a monad is: https://ericlippert.com/2013/02/21/monads-part-one/

It explicitly tries to answer the question: "I’m a C# programmer with no “functional programming” background whatsoever. What is this “monad” thing I keep hearing about, and what use is it to me?"

This video explained it really well when I was learning Haskell.

https://www.youtube.com/watch?v=t1e8gqXLbsU