,
5 tweets,
1 min read
Read on Twitter
The thing to remember about "monads" is that they are not a thing. I mean, it comes from the attempt to apply abstract math to concrete programming. This can be a useful abstraction in some ways, but makes your code unreadable by anybody else who doesn't grok the abstraction.
You could tease out one simple bit about monads and easily explain them, but then person who understood your explanation would be totally lost when confronted with all the other complicated bits.
I mean, take an array of objects, apply a function that returns a smaller array (e.g. "all students with a grade B or higher"). Congratulations! You've got a monad! But no, this simple example won't really help you understanding monads.
This is why, if I were a hiring manager, I'd make the applicant write a monad in x86 assembly language on the whiteboard. Academics understanding abstract theory tend to useless in practical areas like writing assembly. And vice versa. Those who do both are golden.
So my advice is this: don't seek to understand monads, it's not worth it. You aren't going to get it without a deep dive into abstract math, like "category theory", and in the end, it's not going to make you a better programmer, because nobody else will be able to read your code.
