There is always a loss of information when dumbing down high-level abstractions. Some of that loss is noise in the form of formalisms. It is particularly hazardous if you do so using “lets you do blerp with blarp stuff things” expressions. At least unwrap the formalisms into plain English, not an approximation about “stuff” and “things”.
A while ago, I wrote a longer piece explaining my stance on the subject.
When functional programmers try to explain basic ideas like semigroups or functors, they often find themselves in an apologetic mire of simplifications. This is doomed to fail. Give concrete examples of how a functor works. Don’t illustrate them as operations that can map stuff in boxes to other boxes. Invent a problem and solve it using a functor. After all, they’re such a basic concept, even those writing non-functional code end up doing them all the time.
I couldn’t agree more with that quote—I’ve heard far too many box-metaphor explanations of variables and other concepts for my own good… I liked the rest of your article as well. While reading the first few paragraphs, I couldn’t help but be reminded of EWD 1036, which I highly recommend reading if you haven’t already.
What does the author mean when they say “Applicative lets you stuff the function itself inside a container, otherwise it’s almost identical to Functors.”?
Reading https://en.wikibooks.org/wiki/Haskell/Applicative_functors makes it much clearer what it should be, but I still don’t know what they are doing with that swift code (note I do not know swift, but I am familiar with C++, C#, etc).
We didn’t need another explanation of what these things are; that just ends up being mechanical. It’s much more important to know what they’re for. I get much more out of hearing that “monads are a way of encapsulating state” than I do from hearing that “monads have something to do with flatMap”.
There is always a loss of information when dumbing down high-level abstractions. Some of that loss is noise in the form of formalisms. It is particularly hazardous if you do so using “lets you do blerp with blarp stuff things” expressions. At least unwrap the formalisms into plain English, not an approximation about “stuff” and “things”.
A while ago, I wrote a longer piece explaining my stance on the subject.
I couldn’t agree more with that quote—I’ve heard far too many box-metaphor explanations of variables and other concepts for my own good… I liked the rest of your article as well. While reading the first few paragraphs, I couldn’t help but be reminded of EWD 1036, which I highly recommend reading if you haven’t already.
What does the author mean when they say “Applicative lets you stuff the function itself inside a container, otherwise it’s almost identical to Functors.”?
Reading https://en.wikibooks.org/wiki/Haskell/Applicative_functors makes it much clearer what it should be, but I still don’t know what they are doing with that swift code (note I do not know swift, but I am familiar with C++, C#, etc).
We didn’t need another explanation of what these things are; that just ends up being mechanical. It’s much more important to know what they’re for. I get much more out of hearing that “monads are a way of encapsulating state” than I do from hearing that “monads have something to do with
flatMap”.