Functional programmers don't need to know category theory
Functional programmers don’t need to know terms from category theory.
Understanding terms like “functor”, “applicative”, and “monad” doesn’t help you solve problems. What does help is understanding the functions they involve.
Here’s what I mean:
Let’s say you’re implementing a type:
type MyType a
There are any number of functions you could implement for working with MyType.
Here are a few you might consider:
1️⃣ map
map : (a -> b) -> MyType a -> MyType b
map applies a function to a type’s parameter.
Examples:
Maybe.mapapplies a function toJustvalues of aMaybeHtml.maplets you transform themsgtype produced byHtml msg
🤔 When to write map?
Will MyType be parameterized with types that commonly need functions applied to them, like msg?
If so, consider writing MyType.map.
2️⃣ andMap
andMap : MyType a -> MyType (a -> b) -> MyType b
andMap allows a type variable to be a function whose arguments are partially applied.
Example:
Json.Decode.Pipeline.requiredlets you define fields to be decoded, one by one, via pipeline application.
🤔 When to write andMap?
Will MyType’s type parameter need to be constructed piece-by-piece using partial application?
For instance, is MyType is meant to be used for data validation or decoding?
If so, consider writing MyType.andMap.
3️⃣ andThen
andThen : (a -> MyType b) -> MyType a -> MyType b
andThen allows combining values that might or might not be present.
Examples:
Maybe.andThenlets you map and combineMaybes.List.concatMaplets you map and combineLists.
🤔 When to write andThen?
Does MyType have a case where its type parameter is not present?
Will that type parameter’s value need to be combined with another?
If so, consider writing MyType.andThen.
So, what does this all have to do with “functors”, “applicatives”, and “monads”?
Why don’t we leave that to the mathematicians?
This post was originally a Twitter thread as part of Ship 30 for 30.