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

51–60 of 90 posts

Re: Functors, Applicatives, and Monads

#51

Post by BoiledCabbage »

timeon wrote: post #42
BoiledCabbage wrote: post #36

Earlier quoted context omitted.

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

> 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. I was lucky seeing this before hitting submit button. Phew that was close.

Glad I could help you out there.

Re: Functors, Applicatives, and Monads

#52

Post by rebeccaskinner »

mncharity wrote: post #49
rebeccaskinner wrote: post #20

Earlier quoted context omitted.

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

> really hard [...] leap Two stepping stones might be array getters (function that's array-ish), and arrays with an indexed default value function (array that's function-ish)?

I've recently started writing a series of blog posts (https://rebeccaskinner.net/posts/2024-10-18-dictionaries-are...) trying to explain the idea and my approach has been to explain the idea using comprehensions. I haven't had a lot of people review the post yet, and I still have at least one if not two more follow-ups before it's done, so I'm not yet sure how well the idea will land.

Re: Functors, Applicatives, and Monads

#53

Post by yodsanklai »

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…

> should I implement the Monad, Applicative or Functor type class?

You rarely have to implement these type classes. But you need to understand how they work since many libraries use them. If you do IO, error handling, concurrency, use containers, option parsing and so on, you'll have to use these type classes.

For your own types, nobody forces you to implement them. If it turns you can make your type an instance of some type class, you may be able to reuse existing code rather than reimplementing it. And it will make the program more readable too.

Re: Functors, Applicatives, and Monads

#54

Post by rebeccaskinner »

magicalhippo wrote: post #44
rebeccaskinner wrote: post #20

Earlier quoted context omitted.

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

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.

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.

Re: Functors, Applicatives, and Monads

#55

Post by yodsanklai »

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.

FlatMappable doesn't capture what a monad is. For instance, you can do async programming using monads. Doesn't relate to FlatMappable.

I think you don't see the need for a new name if you don't grasp the concept. It's like in mathematics, you have tons of algebraic structures, like monoid, groups, fields, rings. They all represent categories of things which share some properties. You don't want to name the category by a one of its representatives, that would defeat the purpose of introducing an abstraction.

Re: Functors, Applicatives, and Monads

#56

Post by VirusNewbie »

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…

But if people understood monads they wouldn't be bending over backwards to shoehorn specific syntactic sugar just for error handling.

Re: Functors, Applicatives, and Monads

#57

Post by mncharity »

Hmm. I've not yet seen a topical presentation which embeds a tweaked chatbot. Graphics, video, interactive graphics, each provide additional leverage beyond text. So too might "something to talk over the topic with". Something with a punch-list of insights to be conveyed, and misconceptions to be probed for.

Monad education is rich in flawed models and incomplete appreciation, and also in meta discussion of these. Might this lend itself to a interactive socratic-y tutor? Could the world use a... new and improved monad tutorial?

Re: Functors, Applicatives, and Monads

#58

Post by yodsanklai »

rthnbgrredf wrote: post #2

This reminds me of https://www.adit.io/posts/2013-04-17-functors,_applicatives,... I think over the recent years, there's been a rise in typed languages that support functional programming like TypeScript and Rust. It will be interesting to see if this trend continues in the context of AI assistant programming. My guess is that it will become easier for beginners, and the type systems will help to build more robust p…

Yes, type checking works very well with AI since typing provides a step of verification. The more precise the type system is, and the more guarantees you can have. At some extreme, you can entirely specify the program with types. So if the program type checks, it is guaranteed to implement its spec and you can trust the AI. I assume the AI will have a hard time to write the code though. But I had very good results in Rust, less in Haskell. I think it's also because the Rust compiler gives more meaningful error messages, which helps the AI to iterate.

Re: Functors, Applicatives, and Monads

#59

Post by chowells »

BoiledCabbage wrote: post #50
chowells wrote: post #26

Earlier quoted context omitted.

Nah. Lots of people know what monads are. And critically, they don't write monad explainers. This is because if you understand the fundamentals well enough to understand an explanation, monads are so trivially straightforward that the definition is 100% of the explanation you need. Learn about how Haskell denotes types. Learn about higher-order functions, higher-kinded types, parametric polymorphism, and bounded poly…

> Learn about higher-order functions, higher-kinded types, parametric polymorphism, and bounded polymorphism. Except that's not the case because most people know all of those concepts from their main language, and don't know what a monad is. Higher order functions yup. A function can take a funtion as an argument and correctly assign the argument type (unless C where you can finagle it but it's not first class). High…

I assure you, most people cannot tell you the difference between bounded polymorphism, parametric polymorphism, and whatever their language thinks polymorphism means. (The latter is not the same as either of those.) Most people cannot handle the idea of talking about an unapplied type constructor, because their language of choice cannot do that. Maybe the number of people who can think in higher order functions has reached the majority by now. Some good ideas eventually do spread.

But most of all, people do not understand how Haskell's type system works. It is incredibly precise and concise documentation. When you do use a function? When you have its inputs and need its output. Sometimes things are defined in terms of concrete types and need further explanation. But when talking about incredibly generic interfaces like these, that's 90% or more of the necessary documentation.

Learn how that works, and you'll see why there isn't much to say about Monad.

Re: Functors, Applicatives, and Monads

#60

Post by _jackdk_ »

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…

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

Post reply on HN