3 ms·

I think the lesson is that tricky concepts have to be taught by example. Some theoretically-bent people can read a definition and generate their own examples,

by kqr 2y ago

I think the lesson is that tricky concepts have to be taught by example. Some theoretically-bent people can read a definition and generate their own examples, but most people I've met need to be presented with and taught one example at a time. After a while, they just get it and the abstraction falls into place. https://two-wrongs.com/the-what-are-monads-fallacy.html https://two-wrongs.com/the-what-are-monads-fallacy.html

pdpi 2y ago
> I think the lesson is that tricky concepts have to be taught by example. The bigger insight, for me, is that they also have to be taught by counter-example. E.g. it's easy to find Functors that are neither Applicatives nor Monads (usually, because you can't produce a reasonable definition for `return`). It's surprisingly hard to find a non-contrived example of a Functor that is also an Applicative, but *is not* a Monad. Without that counter-example, it's very tricky to build the intuition for where the boundary lies.
- andrepd 2y ago
  Now I'm curious: what's this non-contrived example?
  - pdpi 2y ago
    Validation. You can think of it as shaped like Either [Error] Value, but the implementation is different. Consider this example: pure . Config <$> validate option1 <*> validate option2 <*> validate option3 Either would short circuit on the first validation error. There’s two interesting things here though: there are no data dependencies between different validations (so we don’t _need_ a monad), and it’s useful to accumulate errors to know if both option1 and option3 failed to validate (so we don’t _want_ the Either monad’s short circuiting behaviour). The implementation is pretty straightforward, too!
chongli 2y ago
Some theoretically-bent people can read a definition and generate their own examples This is what mathematical training taught me to do. It's something I wish everyone could learn to do but high school is too short to teach it to most people.

by kqr 2y ago

pdpi 2y ago

> I think the lesson is that tricky concepts have to be taught by example. The bigger insight, for me, is that they also have to be taught by counter-example. E.g. it's easy to find Functors that are neither Applicatives nor Monads (usually, because you can't produce a reasonable definition for `return`). It's surprisingly hard to find a non-contrived example of a Functor that is also an Applicative, but *is not* a Monad. Without that counter-example, it's very tricky to build the intuition for where the boundary lies.

andrepd 2y ago
Now I'm curious: what's this non-contrived example?
- pdpi 2y ago
  Validation. You can think of it as shaped like Either [Error] Value, but the implementation is different. Consider this example: pure . Config <$> validate option1 <*> validate option2 <*> validate option3 Either would short circuit on the first validation error. There’s two interesting things here though: there are no data dependencies between different validations (so we don’t _need_ a monad), and it’s useful to accumulate errors to know if both option1 and option3 failed to validate (so we don’t _want_ the Either monad’s short circuiting behaviour). The implementation is pretty straightforward, too!

chongli 2y ago

Some theoretically-bent people can read a definition and generate their own examples This is what mathematical training taught me to do. It's something I wish everyone could learn to do but high school is too short to teach it to most people.