3 ms·

As soon as bloggers try to use the word "monad", they have a tendency to go entirely off the rails into math-heavy definitions of things which many can't unders

As soon as bloggers try to use the word "monad", they have a tendency to go entirely off the rails into math-heavy definitions of things which many can't understand (for no reason!), or fail entirely to explain what a monad actually is and leave everyone more confused than when they started, which is exactly the thing that scares most people off of Haskell.

TuringTest 12y ago
IMO the best way to introduce monads to the average programmer is to say that they are a kind of functional design patterns (which is a valid analogy if not an exact categorization). DPs in object-oriented programming are also an abstract concept that is difficult to grasp at first, but most senior programmers have already gone through it and succeeded; so liking monads to them can inspire an initial sense of confidence that will be useful when learning the concept, and provides a useful frame to understand the purpose of using monads in functional code (which unfortunately is missing in most monad tutorials).
the_af 12y ago
Have you read Learn you a Haskell? The author is extremely didactic, introducing concepts and motivation before the jargon. I don't know what about monads feels scary to some people. They aren't actually that hard. There's stuff from C++ that scares the hell out of me, but I've seldom seen people arguing "let's not blog about this C++ feature, because it may scare readers away".
- vertex-four 12y ago
  Frankly, even looking at various guides, I still can't really figure out how they work in Haskell, because there's no concrete step-by-step examples anywhere. I can't sit down and say "right, I have these two functions, one looks like `x = 1` and the next looks like `incr y = y+1`, what do I call on what to combine them with a monad, then how do I define a monad which only calls the latter if the former returns 1?", which should be the simplest case. Haskell's utterly ridiculous amount of syntactic sugar really doesn't help, and I figure its laziness probably doesn't either.
  - the_af 12y ago
    But that's precisely how the examples from Learn you a Haskell work... First the author introduces a simple problem which you could have thought of without knowing anything about Haskell. Then he writes a naive, step-by-step solution without knowledge of Monads, Monoids or whatnot (ok, maybe later chapters assume you've read the previous ones). Then, he shows how the solution he arrived at maps to Monad/Monoid/whatever. He also shows how the solution can be made "more general" than the particular problem you started attempting to solve. Give it a chance and you'll see what I mean. There's no black magic there. Also, you can completely bypass do-notation and you'll see there's nothing exceptional about monads.
    - vertex-four 12y ago
      I'm not talking about do-notation. There's plenty of black magic in Haskell. The overuse of operators and abstractions over everything makes it impossible to even figure out what a given function will be taking as parameters, never mind what a function actually does. I want to think in terms of actual, concrete pieces of data. Types are just definitions for shapes of data. I can't think at the level of "X takes a Y", I think at the level of "the x function takes the result of the y function". Haskell is obviously not the language for me.
      - innguest 12y ago
        I'd be very interested in trying to clarify some of the difficulties you're having with Haskell, if you'd be interested. I'm working on a tutorial to take people from zero to functional programming thinking and understanding the intuition, and I need people that are interested in learning Haskell but are currently experiencing difficulties grasping the concepts in order to understand which things are the common obstacles. If you're interested, please email me (my profile should have my email, if not just answer if interested and we'll figure out a way). Thanks!
  - dllthomas 12y ago
    Reading LYAH or the wikibook might be a better way to go, but I don't like it when people say "go read a bunch of stuff" to me, either, so I'll try to help... Do you want a step-by-step guide for implementing a monad, or using a monad? The first thing to realize is that Monad is a design pattern. Like any design pattern, it's more applicable to some goals than others. Could you clarify a bit? "right, I have these two functions, one looks like `x = 1` and the next looks like `incr y = y+1`, what do I call on what to combine them with a monad, then how do I define a monad which only calls the latter if the former returns 1?" The best interpretation I can come to is that you want some plumbing that will hide an implicit check that the value being passed along is 1? This would not fit "monad" well - for reasons I can get into if that's actually what you're asking.

TuringTest 12y ago

IMO the best way to introduce monads to the average programmer is to say that they are a kind of functional design patterns (which is a valid analogy if not an exact categorization). DPs in object-oriented programming are also an abstract concept that is difficult to grasp at first, but most senior programmers have already gone through it and succeeded; so liking monads to them can inspire an initial sense of confidence that will be useful when learning the concept, and provides a useful frame to understand the purpose of using monads in functional code (which unfortunately is missing in most monad tutorials).

the_af 12y ago

Have you read Learn you a Haskell? The author is extremely didactic, introducing concepts and motivation before the jargon. I don't know what about monads feels scary to some people. They aren't actually that hard. There's stuff from C++ that scares the hell out of me, but I've seldom seen people arguing "let's not blog about this C++ feature, because it may scare readers away".

vertex-four 12y ago
Frankly, even looking at various guides, I still can't really figure out how they work in Haskell, because there's no concrete step-by-step examples anywhere. I can't sit down and say "right, I have these two functions, one looks like `x = 1` and the next looks like `incr y = y+1`, what do I call on what to combine them with a monad, then how do I define a monad which only calls the latter if the former returns 1?", which should be the simplest case. Haskell's utterly ridiculous amount of syntactic sugar really doesn't help, and I figure its laziness probably doesn't either.
- the_af 12y ago
  But that's precisely how the examples from Learn you a Haskell work... First the author introduces a simple problem which you could have thought of without knowing anything about Haskell. Then he writes a naive, step-by-step solution without knowledge of Monads, Monoids or whatnot (ok, maybe later chapters assume you've read the previous ones). Then, he shows how the solution he arrived at maps to Monad/Monoid/whatever. He also shows how the solution can be made "more general" than the particular problem you started attempting to solve. Give it a chance and you'll see what I mean. There's no black magic there. Also, you can completely bypass do-notation and you'll see there's nothing exceptional about monads.
  - vertex-four 12y ago
    I'm not talking about do-notation. There's plenty of black magic in Haskell. The overuse of operators and abstractions over everything makes it impossible to even figure out what a given function will be taking as parameters, never mind what a function actually does. I want to think in terms of actual, concrete pieces of data. Types are just definitions for shapes of data. I can't think at the level of "X takes a Y", I think at the level of "the x function takes the result of the y function". Haskell is obviously not the language for me.
    - innguest 12y ago
      I'd be very interested in trying to clarify some of the difficulties you're having with Haskell, if you'd be interested. I'm working on a tutorial to take people from zero to functional programming thinking and understanding the intuition, and I need people that are interested in learning Haskell but are currently experiencing difficulties grasping the concepts in order to understand which things are the common obstacles. If you're interested, please email me (my profile should have my email, if not just answer if interested and we'll figure out a way). Thanks!
- dllthomas 12y ago
  Reading LYAH or the wikibook might be a better way to go, but I don't like it when people say "go read a bunch of stuff" to me, either, so I'll try to help... Do you want a step-by-step guide for implementing a monad, or using a monad? The first thing to realize is that Monad is a design pattern. Like any design pattern, it's more applicable to some goals than others. Could you clarify a bit? "right, I have these two functions, one looks like `x = 1` and the next looks like `incr y = y+1`, what do I call on what to combine them with a monad, then how do I define a monad which only calls the latter if the former returns 1?" The best interpretation I can come to is that you want some plumbing that will hide an implicit check that the value being passed along is 1? This would not fit "monad" well - for reasons I can get into if that's actually what you're asking.