Hacker News Reader

Comment by gabesullice | Hacker News Reader

I've referred to this blog post at least twice a year since I read it 6 or 7 years ago. Not because I need to explain monads, but because the "monad tutorial fallacy" [1] is an incredibly useful concept to be aware of when trying to convey knowledge. I encourage you to read about it :)

[1] https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti...

View on HN

That reminds me of giving the advice, "Just do what comes naturally," to beginners. That's the last advice someone who has spent years building up an intuitive model needs, but it's terrible for beginners.

https://putanumonit.com/2021/09/10/rules-for-noobs/

Just do what comes naturally is great advice for beginners. See the pottery class parable: https://www.industryweek.com/leadership/companies-executives...

tldr: Pottery class, 2 groups. 1 group instructed to make the perfect pot (graded by quality of 1 best pot). 1 group instructed to make a bunch of pots (graded by pounds of clay used).

At the end of semester, the group who was trying to make as many pots as possible also produced the single best pot of the class.

Lesson: You need reps. Lots of reps. You really do just gotta do what comes naturally, get feedback, then do more. Doing is the only way to learn tacit skills.

You can read about the best way to ride a bike for 10 years and achieve nothing. Or you can spend an afternoon failing a lot until you can ride a bike. Software architecture and code structure are similar. You just gotta produce piles upon piles of code and see what works.

"Get feedback" is the key part here. When feedback is "just do what comes naturally", you will not get better.

Yes and feedback can be from your own experience of building upon the code with your next task.

The problem with this is that you will often end up with something that seemingly works (barely), but the way you got there precludes you from advancing further.

I heard this presented as a photography class. Doing a quick search shows that it's from a memory plot in "Atomic Habits" by James Clear.

The story features Jerry Uelsmann and having his class of photographers either work by quantity or quality of shots.

The specific example I remember was "you can only take 1 shot" vs "take as many as you can"; and the lesson being /the group that did many reps had ultimately better photos/.

> Doing a quick search shows that it's from a memory plot in "Atomic Habits" by James Clear.

The post I linked predates Atomic Habits by 10 years :)

That is "do what comes naturally for a long time". Is education about efficiently and effectively transferring thousands of years of invention and practice insights or about letting everyone build civilization from first principles?

Holy moly, I am so triggered.

I have never seen so many kids harmed by bad pedagogy as “just do what comes naturally”. My daughter’s PE teacher gaslit her into thinking she was left handed with this advice and just created the belief that she was inept.

99% of what we do doesn’t come naturally, that’s why we are the most adaptable and successful megafauna in the history of the planet.

Learning is the essence of humanity.

Edit: you will be happy to know I fixed my daughters throwing technique with evidence based double blind tests to show her I knew what I was talking about and then taught her how to throw.

This is advice often given to me to try to entice me to dance, which I hate doing, and nobody believes me that "what comes naturally" is getting off the dance floor and not dancing!

Haha, yes. My confidence dancing was terrible for years because of similar advice. Turns out all the girls and boys who were good had been practicing! Who would have thought.

Recently I've been thinking the important thing is that advice is always highly context sensitive, so throwing out "good advice" without qualification or discernment leads to a lot of harm.

Take (again) dating advice: Saying something like "you shouldn't put so much emphasis on someone's looks" may help someone who is unsuccessful at dating and puts an inordinate emphasis on looks in their selection process. But if someone who already had a balanced view on looks that hears the advice, they may take it to heart and try dating people they have no physical attraction to and find less success.

> Advice is a dangerous gift, even from the wise to the wise, and all courses may run ill.

Quote from a famous wizard.

For a long while now, I've been trying to write a monad tutorial I'm actually happy to give people as an entry point, and that point is precisely why I haven't put anything out there yet. It's also the reason I keep trying: there's something important to be learnt there in terms of communicating tricky concepts.

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

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

Now I'm curious: what's this non-contrived example?

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!

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.

A technique I've had a reasonable amount of success with when teaching formerly imperative programmers is focusing on the constraints that force something like a monad to exist (the "you could have invented it yourself" teaching approach):

1. One of the main points of functional programming is that your computations are the results of pure functions -- enabling niceties like thread-safety, type-safety, ....

2. That view of the world is imperfect because some interactions (like responding to user input) require a _sequencing_ of events.

3. Imperative languages accomplish that task easily. They just write the events in the sequence they want them executed. With constraint (1) though, your only option for sequencing is function composition. Whatever interface you choose, it _has_ to use composition somehow.

4. Monads are one of many possible solutions, and they're the one we happen to have standardized on. They're convenient because you can wrap up all that compositional nonsense into something that feels a lot like the mutable objects you're used to when you actually apply them in your code.

That explanation skips over a lot of details, but it helps people build the initial spark of intuition to attach all the rest of the ideas onto. The mechanics of a monad, their capabilities, the available syntax, ..., don't seem to be the main stumbling block in my experience.

Yes, this post is classic. My answer to Brent's "monad tutorial fallacy" is https://mightybyte.github.io/monad-challenges/. It was inspired by The Matasano Crypto Challenges that Thomas Ptacek & others created awhile back which, instead of trying to teach you cryptanalysis, guides you down the path of actually doing realistic cryptanalysis with a series of challenges.

Reply on news.ycombinator.com