22 ms·

Re: applications and language comparison, see my answer over at https://news.ycombinator.com/item?id=36744384 https://news.ycombinator.com/item?id=36744384 Re:

Re: applications and language comparison, see my answer over at https://news.ycombinator.com/item?id=36744384 https://news.ycombinator.com/item?id=36744384 Re: development process - it's very similar to development in other languages. Write, compile, yell at compiler, push, complain about how slow CI is, deploy. You know, the usual. I think the most interesting difference is the _onboarding_ curve. Haskell's curve is pretty brutal, although I think most of this is because of bad pedagogy (many monad tutorials are bad, and beginners can't tell) rather than because of intrinsically difficult concepts. Some observations: 1. Empirically, zero to code review is roughly six weeks for a professional industry software engineer. It's not that much longer than other languages we've had to teach. But it _feels_ very brutal because zero to side project is roughly three or four weeks. Contrast this against Go, where zero to side project is about five minutes. 2. Having an experienced Haskell engineer on your team to start with makes a WORLD of a difference. You've gotten a type error - why? Is it because GHC is doing weird backwards type inference stuff again? Or is it because you've misunderstood this fundamental concept? Or is it because you've done a typo, and GHC has inferred a downstream site to be a type error? This sort of thing is very difficult to explain in words and in general, and much easier to pick up through experience and mentorship. If you do not have an experienced Haskeller at your disposal, I would strongly recommend starting with side projects first, and using the Functional Programming Slack (fpslack.com), who are some of the friendliest and most patient folks I've had the pleasure of talking to.

Tade0 3y ago
> (many monad tutorials are bad, and beginners can't tell) It appears monads truly are something you can either understand or explain, but not both. I find it suspicious. I mean, plenty of Haskell devs out there, surely it's not that hard?
- icrbow 3y ago
  It's like explaining a hand with four fingers and a thumb. The whole story is... ugh. But you can grasp enough of it to start using almost right away.
- PartiallyTyped 3y ago
  You can just say that a monad is a way to chain operations together by wrapping a value. The consumer usually doesn't need to know the gore-y details of how a monad is implemented, only the purpose of it and how to use it. A Maybe monad just says the value may be Something(x) or Nothing. You won't know until you run the computation. If you use flatmap and give a function that takes an x and gives a Maybe[x], the monad will first map into Maybe[Maybe[x]] and then flatten into Maybe[x]. The computation has not happened until you execute it and internally all the functions have been composed together. A List[A] just says, give me a function A->List[B], and I will flatmap (flatten `compose` map) it. So it maps each element into a possibly empty list of Bs, and then flattens it by concatenating them. You can define your own monads, and as long as they obey the laws of monads, you get a bunch of stuff for free.
  - icrbow 3y ago
    You say "by wrapping a value" and then confuse it with the wrapper right away. No, monads are not wrappers. Some wrappers are monads, but not all. inb4, monads are not pipes either.
    - PartiallyTyped 3y ago
      Sure, a monad is a type constructor. The constructed type allows you to compose transformations. Each monad constructs a type that behaves differently and expects different things, but in general; the monad is defined by a unit/point/return function which brings a value into the monadic context, and a flatMap function aka bind, which further breaks down to “flatten after map”. So List[_] is a type constructor, given a type T, it produces a List[T], which defines some transformations. Return creates a single element list, and flatmap takes the A->[B] applies it everywhere and then concatenates. The nice thing about the wrapper analogy is that even though it is technically wrong, it is easier for people to get it because it follows naturally from OOP and it is a sufficiently useful mental model imho.
    - jghn 3y ago
      IMO the spirit of this answer is a big part of the problem. This might not be exactly what the GP was saying but I've found you can quickly get a dev up to speed with a "good enough" sense of what a monad is. One that'd cover a vast majority of their needs, at least in the early going. But then there are always people who start popping in and pointing out how those definitions aren't quite right. Which is true. But does it matter *for practical purposes* to give a dev a useful for now mental model that they can then use to figure the rest out later? I'd say no.
- deleted 3y ago
  [deleted]
- goto11 3y ago
  Monads are a pattern for function chaining. Most tutorials go off the rails because they confuse types supporting this pattern with "being a monad". For example, arrays in JavaScript support the pattern through the `flatMap()` method, but saying "a JavaScript array is a monad" is misleading because most of what people do with arrays are unrelated to this. As a pattern it is very general. It strings a sequence of functions together, but doesn't care about the semantics of the functions or the types involved, as long as each function just return the same generic type. But many explanations take the semantics of how some particular types use the pattern and generalize from that. E.g. list and option types are monads, so monads are explained as containers. Or IO and State uses the pattern to represent side effects, so monads are explains as a way to have side effects in Haskell. This is what leads to the bizarre metaphors, like monads are boxes, monads are spacesuits, monads are train-tracks etc. Each metaphor matches some uses of monads but breaks down on others.
- embwbam 3y ago
  They’re like promises or futures, but limited to chaining only one type of thing: Maybe (optionals) - chain steps and abort if any step is empty. IO - perform IO side effects, and run the next step when this one completes. Just like a async/await. You use monads all the time in other languages! Haskell just has many more kinds and allows the programmer to make their own. I always twitch when I hear someone say you can’t both understand and teach them. Did I succeed? Also note that you don’t have to totally understand monad machinery to use them productively, only to write your own.
  - muxator 3y ago
    Humble question: > Maybe (optionals) - chain steps and abort if any step is empty. Could this be (remotely) akin to the following shell pattern? set -o pipefail cmd1 | cmd2 | ... This would either return the result of a successful execution of tje whole pipe, or return at the first command erroring out. Does it make any sense?
    - embwbam 3y ago
      Yes that’s exactly what the Maybe monad does! It would look like this in Haskell code doStuff :: Maybe X doStuff = do r1 <- cmd1 r2 <- cmd2 r1 … return rX Which is syntactic sugar for: doStuff = cmd1 >>= cmd2 >>= …
      - dllthomas 3y ago
        A sometimes important difference is that every process in the pipeline is spawned at the start, and may operate on partial input. A function returning Maybe needs to complete before we know whether it returns Just or Nothing, and we can't start the next function until we have the Just in hand, as that's the input to the function.
  - goto11 3y ago
    > You use monads all the time in other languages! No you don't. You are confusing monads with features which can be implemented using monads. In Haskell monads are used for modeling side effects, but this is not the case in other languages. In Haskell exceptions are implemented using monads, but this is not the case in other languages.
- tomsmeding 3y ago
  Instead of rising to the bait and trying to explain monads, let's talk about why it seems to be hard to explain monads. They're very general. Classes in OOP are general too — surely you can model lots of things with them — but a class always models a category of things with similar functionality, and an instance of that class is one of those things. Monads are much more flexible than that. You can model nondeterminism with monads, as well as side-effects, exception-based error handling, state, (backtracking) search algorithms, and more. Could all of those things be an instance of the same OOP class? Surely not. Yet in Haskell, 'Monad' is just a "type class" (not dissimilar to an interface / abstract class in the OOP world). Monad tutorials typically try to do one of the following things: 1. Try to explain the entirety of monads by giving a metaphor (burritos, anyone?) that only works for some of the instantiations of the pattern. It turns out to be hard to find a metaphor that covers all ground that Monad does, unsurprisingly. Personally I think this method is good, as long as you're honest about what it does not give you: an intuition for all Monad instances. It just gives you an intuition about some of them, but that could already be plenty to work with them usefully (and see 3. below). 2. Try to let the reader invent Monad by showing various instantiations and asking the reader to find the pattern. Personally I think this misses the point somewhat; yes, you can see the pattern, but that doesn't give any understanding per se. Why are those things similar, and why does it make sense to abstract over the idea? 3. Not actually explain, but instead say "work with them a bit and you'll understand soon enough". This is the one I'm most in favour of — after giving a special-purpose intuition for the monads you'll be working with as a beginner (IO, perhaps parser combinators, and not much else; perhaps lists (nondeterminism) to jump-start exploration into non-imperative monads). Note that none of these give a nice and polished answer to what a monad is. As alluded to above, the closest OOP equivalent to the kind of thing that Monad is, is a design pattern. It's a design pattern that can be encoded into a three-line definition in the language itself, and is super general.
- ilikebits 3y ago
  Here's my take on a monad tutorial: https://lobste.rs/s/7cllte/monads_part_six_really_what_is_monad#c_nbusni https://lobste.rs/s/7cllte/monads_part_six_really_what_is_mo... TL;DR: Monads are Promises and async/await, but generalized to different implementations of `.then`. You are right to be suspicious; it is _not_ that hard! I think people just get confused and overwhelmed because (1) there are many separate different concepts that are all being introduced at once, and (2) you need to learn a new debugging methodology at the same time. I think the vast majority of this problem is the huge deluge of bad teaching materials (especially monad tutorials written by people who do not use Haskell in production) and the shortage of good teaching materials. Re: 1 - some separate, orthogonal concepts that I have seen people mix up while trying to teach Haskell: 1. Effect tracking (which is a thing that we _do_ using monads, but is not intrinsically tied to monads - this would be better served by being taught as "dependency injection but stricter") 2. Non-eager evaluation (which is a language runtime evaluation choice that Haskell has made, and which motivates the usage of monads where most languages have function bodies, but is again not intrinsically tied to monads) 3. "Purity" (a more confusing way to explain 1) 4. "Mutable state" (another thing we represent with monads, but again is not intrinsic to monads) 5. Monads the math / category theory concept (don't bother with teaching this - it will not be helpful until you have intuition for writing and operating the programs themselves first, which takes at least a few months to build, and even then it is mostly useful as a source of advanced techniques for library writers rather than application writers) At work, we've developed our own set of educational materials for teaching folks the language. I'm working on externalizing them in my spare time.

Tade0 3y ago

> (many monad tutorials are bad, and beginners can't tell) It appears monads truly are something you can either understand or explain, but not both. I find it suspicious. I mean, plenty of Haskell devs out there, surely it's not that hard?

icrbow 3y ago
It's like explaining a hand with four fingers and a thumb. The whole story is... ugh. But you can grasp enough of it to start using almost right away.
PartiallyTyped 3y ago
You can just say that a monad is a way to chain operations together by wrapping a value. The consumer usually doesn't need to know the gore-y details of how a monad is implemented, only the purpose of it and how to use it. A Maybe monad just says the value may be Something(x) or Nothing. You won't know until you run the computation. If you use flatmap and give a function that takes an x and gives a Maybe[x], the monad will first map into Maybe[Maybe[x]] and then flatten into Maybe[x]. The computation has not happened until you execute it and internally all the functions have been composed together. A List[A] just says, give me a function A->List[B], and I will flatmap (flatten `compose` map) it. So it maps each element into a possibly empty list of Bs, and then flattens it by concatenating them. You can define your own monads, and as long as they obey the laws of monads, you get a bunch of stuff for free.
- icrbow 3y ago
  You say "by wrapping a value" and then confuse it with the wrapper right away. No, monads are not wrappers. Some wrappers are monads, but not all. inb4, monads are not pipes either.
  - PartiallyTyped 3y ago
    Sure, a monad is a type constructor. The constructed type allows you to compose transformations. Each monad constructs a type that behaves differently and expects different things, but in general; the monad is defined by a unit/point/return function which brings a value into the monadic context, and a flatMap function aka bind, which further breaks down to “flatten after map”. So List[_] is a type constructor, given a type T, it produces a List[T], which defines some transformations. Return creates a single element list, and flatmap takes the A->[B] applies it everywhere and then concatenates. The nice thing about the wrapper analogy is that even though it is technically wrong, it is easier for people to get it because it follows naturally from OOP and it is a sufficiently useful mental model imho.
  - jghn 3y ago
    IMO the spirit of this answer is a big part of the problem. This might not be exactly what the GP was saying but I've found you can quickly get a dev up to speed with a "good enough" sense of what a monad is. One that'd cover a vast majority of their needs, at least in the early going. But then there are always people who start popping in and pointing out how those definitions aren't quite right. Which is true. But does it matter *for practical purposes* to give a dev a useful for now mental model that they can then use to figure the rest out later? I'd say no.
deleted 3y ago
[deleted]
goto11 3y ago
Monads are a pattern for function chaining. Most tutorials go off the rails because they confuse types supporting this pattern with "being a monad". For example, arrays in JavaScript support the pattern through the `flatMap()` method, but saying "a JavaScript array is a monad" is misleading because most of what people do with arrays are unrelated to this. As a pattern it is very general. It strings a sequence of functions together, but doesn't care about the semantics of the functions or the types involved, as long as each function just return the same generic type. But many explanations take the semantics of how some particular types use the pattern and generalize from that. E.g. list and option types are monads, so monads are explained as containers. Or IO and State uses the pattern to represent side effects, so monads are explains as a way to have side effects in Haskell. This is what leads to the bizarre metaphors, like monads are boxes, monads are spacesuits, monads are train-tracks etc. Each metaphor matches some uses of monads but breaks down on others.
embwbam 3y ago
They’re like promises or futures, but limited to chaining only one type of thing: Maybe (optionals) - chain steps and abort if any step is empty. IO - perform IO side effects, and run the next step when this one completes. Just like a async/await. You use monads all the time in other languages! Haskell just has many more kinds and allows the programmer to make their own. I always twitch when I hear someone say you can’t both understand and teach them. Did I succeed? Also note that you don’t have to totally understand monad machinery to use them productively, only to write your own.
- muxator 3y ago
  Humble question: > Maybe (optionals) - chain steps and abort if any step is empty. Could this be (remotely) akin to the following shell pattern? set -o pipefail cmd1 | cmd2 | ... This would either return the result of a successful execution of tje whole pipe, or return at the first command erroring out. Does it make any sense?
  - embwbam 3y ago
    Yes that’s exactly what the Maybe monad does! It would look like this in Haskell code doStuff :: Maybe X doStuff = do r1 <- cmd1 r2 <- cmd2 r1 … return rX Which is syntactic sugar for: doStuff = cmd1 >>= cmd2 >>= …
    - dllthomas 3y ago
      A sometimes important difference is that every process in the pipeline is spawned at the start, and may operate on partial input. A function returning Maybe needs to complete before we know whether it returns Just or Nothing, and we can't start the next function until we have the Just in hand, as that's the input to the function.
- goto11 3y ago
  > You use monads all the time in other languages! No you don't. You are confusing monads with features which can be implemented using monads. In Haskell monads are used for modeling side effects, but this is not the case in other languages. In Haskell exceptions are implemented using monads, but this is not the case in other languages.
tomsmeding 3y ago
Instead of rising to the bait and trying to explain monads, let's talk about why it seems to be hard to explain monads. They're very general. Classes in OOP are general too — surely you can model lots of things with them — but a class always models a category of things with similar functionality, and an instance of that class is one of those things. Monads are much more flexible than that. You can model nondeterminism with monads, as well as side-effects, exception-based error handling, state, (backtracking) search algorithms, and more. Could all of those things be an instance of the same OOP class? Surely not. Yet in Haskell, 'Monad' is just a "type class" (not dissimilar to an interface / abstract class in the OOP world). Monad tutorials typically try to do one of the following things: 1. Try to explain the entirety of monads by giving a metaphor (burritos, anyone?) that only works for some of the instantiations of the pattern. It turns out to be hard to find a metaphor that covers all ground that Monad does, unsurprisingly. Personally I think this method is good, as long as you're honest about what it does not give you: an intuition for all Monad instances. It just gives you an intuition about some of them, but that could already be plenty to work with them usefully (and see 3. below). 2. Try to let the reader invent Monad by showing various instantiations and asking the reader to find the pattern. Personally I think this misses the point somewhat; yes, you can see the pattern, but that doesn't give any understanding per se. Why are those things similar, and why does it make sense to abstract over the idea? 3. Not actually explain, but instead say "work with them a bit and you'll understand soon enough". This is the one I'm most in favour of — after giving a special-purpose intuition for the monads you'll be working with as a beginner (IO, perhaps parser combinators, and not much else; perhaps lists (nondeterminism) to jump-start exploration into non-imperative monads). Note that none of these give a nice and polished answer to what a monad is. As alluded to above, the closest OOP equivalent to the kind of thing that Monad is, is a design pattern. It's a design pattern that can be encoded into a three-line definition in the language itself, and is super general.
ilikebits 3y ago
Here's my take on a monad tutorial: https://lobste.rs/s/7cllte/monads_part_six_really_what_is_monad#c_nbusni https://lobste.rs/s/7cllte/monads_part_six_really_what_is_mo... TL;DR: Monads are Promises and async/await, but generalized to different implementations of `.then`. You are right to be suspicious; it is _not_ that hard! I think people just get confused and overwhelmed because (1) there are many separate different concepts that are all being introduced at once, and (2) you need to learn a new debugging methodology at the same time. I think the vast majority of this problem is the huge deluge of bad teaching materials (especially monad tutorials written by people who do not use Haskell in production) and the shortage of good teaching materials. Re: 1 - some separate, orthogonal concepts that I have seen people mix up while trying to teach Haskell: 1. Effect tracking (which is a thing that we _do_ using monads, but is not intrinsically tied to monads - this would be better served by being taught as "dependency injection but stricter") 2. Non-eager evaluation (which is a language runtime evaluation choice that Haskell has made, and which motivates the usage of monads where most languages have function bodies, but is again not intrinsically tied to monads) 3. "Purity" (a more confusing way to explain 1) 4. "Mutable state" (another thing we represent with monads, but again is not intrinsic to monads) 5. Monads the math / category theory concept (don't bother with teaching this - it will not be helpful until you have intuition for writing and operating the programs themselves first, which takes at least a few months to build, and even then it is mostly useful as a source of advanced techniques for library writers rather than application writers) At work, we've developed our own set of educational materials for teaching folks the language. I'm working on externalizing them in my spare time.