4 ms·

Unfortunately, while you may not have appreciated the tone of the Haskell interaction, they are correct in their assessment from a factual perspective. This exp

by jerf 2y ago

Unfortunately, while you may not have appreciated the tone of the Haskell interaction, they are correct in their assessment from a factual perspective. This explanation propagates a number of misunderstandings of the topics well known to be endemic to beginners. In particular, I observed the common belief that functors apply to "containers", when in fact they apply to things that are not containers as well, most notably functions themselves, and it also contains the common belief that a monad has "a" value, rather than any number of values. For instance, the "list monad" will confuse someone operating on this description because when the monad "takes the value out of the list", it actually does it once per value in the list. This is the common "monad as burrito" metaphor, basically, which isn't just bad, but is actually wrong. I'm not limiting it to these errors either, these are just the ones that leap out at me.

adamddev1 2y ago
Bartosz Milewski argues that we can think of functions etc. as containers as well, if you check out his YouTube lectures on Category Theory for Programmers. Lists and functions "contain" a type.
- jerf 2y ago
  A term's utility comes from its ability to separate things into different categories. A definition of "container" that includes everything is therefore useless, because if everything a container, there is no information in the statement that something is a container. In Bartosz's case he's probably making the precise point that we can abstract out to that point and that at a super, super high level of category theory, there isn't anything that isn't a container. However, that's a didactic point, not a general truth. In general we programmers generally do mean something by the word "container", and functors can indeed include things that are therefore not containers. Moreover, I would say it's not what the author was thinking. The author is not operating on that super high level of category theory.
- edflsafoiewq 2y ago
  A list [b] is a container for bs indexed by integers. A function a->b is a container for bs indexed by as.
  - cluckindan 2y ago
    [b] is more like a blueprint for a container, and a->b is more like an assembly line of containers.
  - rebeccaskinner 2y ago
    > A function a->b is a container for bs Anecdotally, this is one of those things that's trivially true to some people, but really hard for other people to internalize. I think it's why the "container" can lead people astray- if you haven't internalized the idea of functions as being indexed by their argument, it's a really mind twisting thing to try to make that leap.
    - n_plus_1_acc 2y ago
      I can recommend learnung some scala, where HashMap extends PartialFunction
      - rebeccaskinner 2y ago
        I've never looked at scala, but that's really interesting. Do you find that's useful in practice?
    - magicalhippo 2y ago
      If I give you a function "f(x) := 3 * x", is it really that useful to talk about it as a container of the natural numbers? The reverse though is useful, a container looks like a function that takes one or more indices and returns a value or element.
      - rebeccaskinner 2y ago
        I think that understanding the (moral) equivalence is useful in both directions. In particular, I think helping people understand the "function-as-container" analogy is a useful way for people to understand pure functions- another thing that's conceptually simple but a lot of people struggle to really wrap their mind around it.
hajile 2y ago
Functions are just containers of calculations (the whole “code is data”). I don’t know why lists as values in a container would be confusing. Lots of very popular languages literally have box types which may not be exactly the same, but show that expecting containers to potentially commission complex data isn’t unusual.
- fn-mote 2y ago
  > I don’t know why lists as values in a container would be confusing. The GP makes it pretty clear - the misunderstanding is that there is one value in a container. A list has many.
  - hajile 2y ago
    That's like saying a dev would be confused that an Object can contain a list. I can't see that tripping up anyone but the most junior of developers.
- codebje 2y ago
  One source for confusion around lists is that the list monad is often used to model non-determinism, rather than just "many things". If you're thinking about non-determinism, a list is akin to a container of one item when you don't precisely know which item it is, but do know it's one of zero or more candidates. The most widely recognised example, IMO, would be monadic parser combinators. "A parser for a thing, is a function from a string, to a list of pairs of strings and things."
T-R 2y ago
Thinking too concretely about monads as boxes might make the behavior of the ListT monad transformer seem a bit surprising... unless you were already imagining your box as containing Schrodinger's cat. I can definitely understand the author taking offense to the interaction, but now that a lot more programmers have had some experience with types like Result<T> and Promise<T> in whatever their other favorite typed language with generics is, the box/container metaphors are probably less helpful for those people than just relating the typeclasses to interfaces, and pointing out that algebraic laws are useful for limiting the leakiness of abstractions.
noelwelsh 2y ago
One can start with a partial explanation and expand it cover all the cases as learning progresses. This is how most learning takes place. I expect your primary school teachers introduced numbers with the natural numbers, instead of, say, transfinite numbers. Students learn Newtonian physics before relativity. It's completely fine to build an understanding of monads as operating on containers, and then expand that understanding as one encounters more cases.
- _jackdk_ 2y ago
  An intuition of monads built on "flattening" nested layers of `m` is easier to teach and works for more monads.
_jackdk_ 2y ago
I agree. The "container" intuition for Monads leaves you stuck when you try to contemplate IO (or even Promises, these days), because the "bind" operator looks like it does something impossible: extract "the" `a` from the `IO a`, when you have no idea what it is. (Trust me, I spent a long time stuck at this point.) Better to think of Monad as "Applicative + join" (you need Applicative to get `pure`). If you think of Monads in terms of `fmap` + `join :: Monad m => m (m a) -> m a`, then you don't need to imagine an "extraction" step and your intuition is correct across more instances. Understanding `join` gives you an intuition that works for all the monads I can think of, whereas the container intuition only works for `Maybe` or `Either e` (not even `[]`, even though it _is_ a container). You can define each of `>>=`/`join`/`>=>` in terms of `pure` + any of the other two, and it is an illuminating exercise to do so. (That `class Monad` defines `>>=` as its method is mostly due to technical GHC reasons rather than anything mechanical.)
- jerf 2y ago
  I prefer the "join" approach for beginners too, but >>= has become so pervasive that I feel bad trying to explain it that way. Turning people loose on monad-heavy code with that approach still leaves them needing to convert their understanding into >>= anyhow. One does wonder about the alternate world where that was the primary way people interacted with it.
  - _jackdk_ 2y ago
    I think you don't have to teach people to program with `join`, but just that `m >>= f = join (fmap f) m`. It explains away the "get a value out" question but teaches the most common function from the interface.
Tainnor 2y ago
In general, in abstract mathematics no analogy or "intuitive concept" of something will ever replace the rigorous definition. That doesn't mean that imperfect analogies can't be useful, though. You just have to use them as a starting point instead of stopping there. I think the container analogy can be useful up to a point. There is (potentially) something of value wrapped in another type (e.g. an integer "wrapped in" IO) and we usually cannot access it directly (because of various reasons: because IO is special, because a list may be empty, etc.), but we can string together some operations that manipulate the contents implicitly.

by jerf 2y ago

adamddev1 2y ago

Bartosz Milewski argues that we can think of functions etc. as containers as well, if you check out his YouTube lectures on Category Theory for Programmers. Lists and functions "contain" a type.

jerf 2y ago
A term's utility comes from its ability to separate things into different categories. A definition of "container" that includes everything is therefore useless, because if everything a container, there is no information in the statement that something is a container. In Bartosz's case he's probably making the precise point that we can abstract out to that point and that at a super, super high level of category theory, there isn't anything that isn't a container. However, that's a didactic point, not a general truth. In general we programmers generally do mean something by the word "container", and functors can indeed include things that are therefore not containers. Moreover, I would say it's not what the author was thinking. The author is not operating on that super high level of category theory.
edflsafoiewq 2y ago
A list [b] is a container for bs indexed by integers. A function a->b is a container for bs indexed by as.
- cluckindan 2y ago
  [b] is more like a blueprint for a container, and a->b is more like an assembly line of containers.
- rebeccaskinner 2y ago
  > A function a->b is a container for bs Anecdotally, this is one of those things that's trivially true to some people, but really hard for other people to internalize. I think it's why the "container" can lead people astray- if you haven't internalized the idea of functions as being indexed by their argument, it's a really mind twisting thing to try to make that leap.
  - n_plus_1_acc 2y ago
    I can recommend learnung some scala, where HashMap extends PartialFunction
    - rebeccaskinner 2y ago
      I've never looked at scala, but that's really interesting. Do you find that's useful in practice?
  - magicalhippo 2y ago
    If I give you a function "f(x) := 3 * x", is it really that useful to talk about it as a container of the natural numbers? The reverse though is useful, a container looks like a function that takes one or more indices and returns a value or element.
    - rebeccaskinner 2y ago
      I think that understanding the (moral) equivalence is useful in both directions. In particular, I think helping people understand the "function-as-container" analogy is a useful way for people to understand pure functions- another thing that's conceptually simple but a lot of people struggle to really wrap their mind around it.

hajile 2y ago

Functions are just containers of calculations (the whole “code is data”). I don’t know why lists as values in a container would be confusing. Lots of very popular languages literally have box types which may not be exactly the same, but show that expecting containers to potentially commission complex data isn’t unusual.

fn-mote 2y ago
> I don’t know why lists as values in a container would be confusing. The GP makes it pretty clear - the misunderstanding is that there is one value in a container. A list has many.
- hajile 2y ago
  That's like saying a dev would be confused that an Object can contain a list. I can't see that tripping up anyone but the most junior of developers.
codebje 2y ago
One source for confusion around lists is that the list monad is often used to model non-determinism, rather than just "many things". If you're thinking about non-determinism, a list is akin to a container of one item when you don't precisely know which item it is, but do know it's one of zero or more candidates. The most widely recognised example, IMO, would be monadic parser combinators. "A parser for a thing, is a function from a string, to a list of pairs of strings and things."

T-R 2y ago

Thinking too concretely about monads as boxes might make the behavior of the ListT monad transformer seem a bit surprising... unless you were already imagining your box as containing Schrodinger's cat. I can definitely understand the author taking offense to the interaction, but now that a lot more programmers have had some experience with types like Result<T> and Promise<T> in whatever their other favorite typed language with generics is, the box/container metaphors are probably less helpful for those people than just relating the typeclasses to interfaces, and pointing out that algebraic laws are useful for limiting the leakiness of abstractions.

noelwelsh 2y ago

One can start with a partial explanation and expand it cover all the cases as learning progresses. This is how most learning takes place. I expect your primary school teachers introduced numbers with the natural numbers, instead of, say, transfinite numbers. Students learn Newtonian physics before relativity. It's completely fine to build an understanding of monads as operating on containers, and then expand that understanding as one encounters more cases.

_jackdk_ 2y ago
An intuition of monads built on "flattening" nested layers of `m` is easier to teach and works for more monads.

_jackdk_ 2y ago

I agree. The "container" intuition for Monads leaves you stuck when you try to contemplate IO (or even Promises, these days), because the "bind" operator looks like it does something impossible: extract "the" `a` from the `IO a`, when you have no idea what it is. (Trust me, I spent a long time stuck at this point.) Better to think of Monad as "Applicative + join" (you need Applicative to get `pure`). If you think of Monads in terms of `fmap` + `join :: Monad m => m (m a) -> m a`, then you don't need to imagine an "extraction" step and your intuition is correct across more instances. Understanding `join` gives you an intuition that works for all the monads I can think of, whereas the container intuition only works for `Maybe` or `Either e` (not even `[]`, even though it _is_ a container). You can define each of `>>=`/`join`/`>=>` in terms of `pure` + any of the other two, and it is an illuminating exercise to do so. (That `class Monad` defines `>>=` as its method is mostly due to technical GHC reasons rather than anything mechanical.)

jerf 2y ago
I prefer the "join" approach for beginners too, but >>= has become so pervasive that I feel bad trying to explain it that way. Turning people loose on monad-heavy code with that approach still leaves them needing to convert their understanding into >>= anyhow. One does wonder about the alternate world where that was the primary way people interacted with it.
- _jackdk_ 2y ago
  I think you don't have to teach people to program with `join`, but just that `m >>= f = join (fmap f) m`. It explains away the "get a value out" question but teaches the most common function from the interface.

Tainnor 2y ago

In general, in abstract mathematics no analogy or "intuitive concept" of something will ever replace the rigorous definition. That doesn't mean that imperfect analogies can't be useful, though. You just have to use them as a starting point instead of stopping there. I think the container analogy can be useful up to a point. There is (potentially) something of value wrapped in another type (e.g. an integer "wrapped in" IO) and we usually cannot access it directly (because of various reasons: because IO is special, because a list may be empty, etc.), but we can string together some operations that manipulate the contents implicitly.