Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functors, Applicatives, and Monads

thecoder.cafe

Post reply on HN
Print view View original

31–40 of 90 posts

Re: Functors, Applicatives, and Monads

#31

Post by chowells »

e-dant wrote: post #27

Part of why monads are not interesting to talk about is that they’re generic enough that most explanations are incomplete, and sufficient explanations are boring and unhelpful. But the biggest reason is that they’re sort of intuitive, plenty examples exist. And then at some point someone tells you that those things are monads, but it’s in the kind of way that social psychologists make up some fancy word for crap we a…

The helpful part is the ability to abstract over arbitrary monads. That's the thing that makes it worth identifying that it's a known and well-studied pattern.

Re: Functors, Applicatives, and Monads

#32

Post by T-R »

jerf wrote: post #4

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 nota…

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

Re: Functors, Applicatives, and Monads

#33

Post by hibikir »

e-dant wrote: post #27

Part of why monads are not interesting to talk about is that they’re generic enough that most explanations are incomplete, and sufficient explanations are boring and unhelpful. But the biggest reason is that they’re sort of intuitive, plenty examples exist. And then at some point someone tells you that those things are monads, but it’s in the kind of way that social psychologists make up some fancy word for crap we a…

The fact that they are so generic is what makes people misunderstand them: They focus on 1 or 2 examples, without seeing that the same concept works in all kinds of other use cases.

People realize a list can be a monad, and they they imagine option and set are also monads. But then you have to tell them that the same applies to Future, and Either. That you can have a resource monad that closes resources.

This is when the fact that something is a monad starts to matter, because of generic concepts for transformers. Every language that has promises and lists will give you a way to turn a List[Promise[T]] into Promise[List[T]], written ad-hoc, but it doesn't have to be quite so ad-hoc. It's when you are stacking 3 or 4 different properties together that the abstract concepts matter. The lack of the abstraction is what makes some language have trouble doing more than just a little bit of functional programming, as going deeper becomes unmanageable without some help.

Re: Functors, Applicatives, and Monads

#34

Post by wavemode »

rrgok wrote: post #30
fellowniusmonk wrote: post #16

Earlier quoted context omitted.

Why are there so few practical, example and code driven tutorials? I've never run across a succinct "build Twitter with Haskell" in the wild.

Yes, I really need a real word Haskell project simple enough to understand all the math concept. Like, I don't know when to implement the Monad type-class to my domain data types. For example, taking the twitter example, if I have Tweet data type: - should I implement the Monad, Applicative or Functor type class? - How would that help in the big picture? - What if I don't do it? All these funny example of boxes, burr…

> Yes, I really need a real word Haskell project simple enough to understand all the math concept

There actually is a book with precisely that title, which provides what you're asking for: https://book.realworldhaskell.org/

> Like, I don't know when to implement the Monad type-class to my domain data types

A concrete type (such as your Tweet type) can't be a Monad. Monad is implemented on generic types (think: `MyType a`, where `a` can be filled in with a concrete type to produce e.g. `MyType Int` or `MyType String`).

Most monads are data structures like list `[a]` or structures which provide context to computations like `State s a` or `Reader r a`

Re: Functors, Applicatives, and Monads

#35

Post by agumonkey »

IshKebab wrote: post #19

The problem with Monads etc. is that they're simple concepts with extremely confusing names. Monad should be FlatMappable. Once it has the correct name it barely even needs an explanation at all.

Even though I see why it could help as introduction, I think flatmap is too narrow to express monadism

Re: Functors, Applicatives, and Monads

#36

Post by BoiledCabbage »

globnomulous wrote: post #18
burlesona wrote: post #13

I feel like Haskell is easier to use than it is to explain, and in my experience a lot of these kind of tutorial / explanations actually make things seem harder and more complicated than just working with the concepts and observing what they do. (This one included.)

I'm not familiar with Haskell and am really, really struggling to follow the article. In the case of the functor, the author doesn't explain in technical, specific enough terms the difference between "open the box, extract the value out of it, apply the function, and put the result back in a box" and "apply a function to a box directly; no need to perform all the steps ourselves." I have no idea what 'apply a functio…

The number one mistake is everyone trying to explain a Haskell concept to the general population makes is using Haskell. If someone already knows Haskell there is a good chance they know there concepts. Don't use Haskell as the language, use js to explain it.

The number two mistake people make is being aware of the number one mistake so they go write yet another Monad tutorial in Javascript (or Java or whatever...). Which is why there are so many damn Monad tutorials, all saying pretty much the same thing.

Re: Functors, Applicatives, and Monads

#37

Post by fn-mote »

hajile wrote: post #22
jerf wrote: post #4

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 nota…

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.

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

Re: Functors, Applicatives, and Monads

#38

Post by noelwelsh »

jerf wrote: post #4

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 nota…

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.

Re: Functors, Applicatives, and Monads

#39

Post by jaspervdj »

fellowniusmonk wrote: post #16
burlesona wrote: post #13

I feel like Haskell is easier to use than it is to explain, and in my experience a lot of these kind of tutorial / explanations actually make things seem harder and more complicated than just working with the concepts and observing what they do. (This one included.)

Why are there so few practical, example and code driven tutorials? I've never run across a succinct "build Twitter with Haskell" in the wild.

This talk seems like exactly what you are looking for for:

Gabriel Gonzalez - “A bare-bones Twitter clone implemented with Haskell + Nix” @ ZuriHac 2020 https://www.youtube.com/live/Q3qjTVcU9cg

Re: Functors, Applicatives, and Monads

#40

Post by hu3 »

This is how Chat GPT o1 would explain Functors, Applicatives and Monads to a PHP developer. Looks more digestible to me, supposing it is correct.

https://chatgpt.com/share/67e9b3b0-52a8-8001-87d1-d6d222a27e...

The prompt to save you a click: "I'm an experienced PHP developer, explain Monads to me using PHP exmaples." (yes I made a typo in exmaples but it worked fine anyway).

Post reply on HN