6 ms·

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 accompa

by psyc 5y ago

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 suspect the real problem is that, as a C/C++/C#/ASM programmer, I lack concepts that are strict prerequisites, and people underestimate the importance and/or existence of those prerequisites. What I did was I gave up and no longer click those articles.

lwerdna 5y ago
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.
giraffe_lady 5y ago
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.
exdsq 5y ago
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 :)
- eternityforest 5y ago
  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.
  - alexmingoia 5y ago
    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.
    - 8note 5y ago
      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.
    - eternityforest 5y ago
      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.
eternityforest 5y ago
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.
spellcard199 5y ago
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/ https://haskellbook.com/ (edit: formatting)
orthoxerox 5y ago
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/ 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?"
ParetoOptimal 5y ago
> 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.
hemloc_io 5y ago
This video explained it really well when I was learning Haskell. https://www.youtube.com/watch?v=t1e8gqXLbsU https://www.youtube.com/watch?v=t1e8gqXLbsU

by psyc 5y ago

lwerdna 5y ago

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.

giraffe_lady 5y ago

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.

exdsq 5y ago

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 :)

eternityforest 5y ago
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.
- alexmingoia 5y ago
  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.
  - 8note 5y ago
    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.
  - eternityforest 5y ago
    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.

eternityforest 5y ago

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.

spellcard199 5y ago

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/ https://haskellbook.com/ (edit: formatting)

orthoxerox 5y ago

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/ 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?"

ParetoOptimal 5y ago

> 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.

hemloc_io 5y ago

This video explained it really well when I was learning Haskell. https://www.youtube.com/watch?v=t1e8gqXLbsU https://www.youtube.com/watch?v=t1e8gqXLbsU