Note this important sentence at the end of the introduction, which I overlooked at first, causing confusion:
I’ll assume knowledge of categories, functors, and natural transformations.
Asking as someone with only vague knowledge of those concepts – knowledge that was acquired only due to curiosity about the meme phrase – is it common that people would understand those three concepts in category theory but not the concepts explained in this blog post? For example, is there some common type of analysis that requires knowledge of categories and functors but not knowledge of bifunctors or monoidal categories?
As Corbin says, the first three topics in many introductions are categories, then functors between categories, then natural transformations between functors. I chose to take them as given because a) the article was getting long enough already and b) Haskell programmers curious about the meme words have probably seen Haskell versions of those concepts in their regular programming or research.
Categories are usually the first defined concept when studying category theory, and functors and natural transformations follow afterwards. (Historically, natural transformations were the main definition; categories and functors are auxiliary concepts.) For example, the Wikibook for category theory has them as the first three chapters, and the Rosetta Stone paper has them in the first four definitions. They are a common starting point.
You will not often encounter categories without any monoidal structure whatsoever. It’s just too easy to take two data and form a pair, and that’s often all that’s required. Some folks prefer to work only with operads because of this, and think of categories as degenerate special cases of operads. The best way to understand operads is with a pictureor two.
I learned the beginnings of Category Theory during Math grad courses and saw many concrete examples of categories, functors, and natural transformations in other Math domains; yet I did not understand the details of why Haskell Monads are called Monads until I read this blog post. That’s partly because I haven’t yet seen a reason to care about Category Theory in a software context, but in any case I probably wouldn’t have come up with this explanation on my own without a lot of effort.
Thanks. What would really pique my interest is an example of a real software problem where Category Theory concepts make it substantially easier to reason about.
Both pieces of text are using the browser’s default serif font thanks to the CSS .math {color: #000;font-family: serif}. In both Chrome (broken) and Firefox (working), the default serif font is “Times”.
Interesting. Do you have any suggestions on how to fix this? I try not to have strong opinions about which font to use because I want to leave that choice up to the user agent.
Note this important sentence at the end of the introduction, which I overlooked at first, causing confusion:
Asking as someone with only vague knowledge of those concepts – knowledge that was acquired only due to curiosity about the meme phrase – is it common that people would understand those three concepts in category theory but not the concepts explained in this blog post? For example, is there some common type of analysis that requires knowledge of categories and functors but not knowledge of bifunctors or monoidal categories?
As Corbin says, the first three topics in many introductions are categories, then functors between categories, then natural transformations between functors. I chose to take them as given because a) the article was getting long enough already and b) Haskell programmers curious about the meme words have probably seen Haskell versions of those concepts in their regular programming or research.
Categories are usually the first defined concept when studying category theory, and functors and natural transformations follow afterwards. (Historically, natural transformations were the main definition; categories and functors are auxiliary concepts.) For example, the Wikibook for category theory has them as the first three chapters, and the Rosetta Stone paper has them in the first four definitions. They are a common starting point.
You will not often encounter categories without any monoidal structure whatsoever. It’s just too easy to take two data and form a pair, and that’s often all that’s required. Some folks prefer to work only with operads because of this, and think of categories as degenerate special cases of operads. The best way to understand operads is with a picture or two.
I learned the beginnings of Category Theory during Math grad courses and saw many concrete examples of categories, functors, and natural transformations in other Math domains; yet I did not understand the details of why Haskell Monads are called Monads until I read this blog post. That’s partly because I haven’t yet seen a reason to care about Category Theory in a software context, but in any case I probably wouldn’t have come up with this explanation on my own without a lot of effort.
You may be interested to learn that every programming language has an associated native type theory and categorical structure.
Thanks. What would really pique my interest is an example of a real software problem where Category Theory concepts make it substantially easier to reason about.
i didnt read it but does it include the fact that category theory monads are much more general than haskells version
Reporting a website bug:
When viewing the linked story in Chrome 108 on macOS, but not in Firefox 109 on macOS, some symbols are displayed as empty squares.
For example, this sentence with the up tack symbol (representing the bottom type)
looks like
And this sentence with a rightwards arrow
looks like
Both pieces of text are using the browser’s default serif font thanks to the CSS
.math {color: #000;font-family: serif}. In both Chrome (broken) and Firefox (working), the default serif font is “Times”.I do not observe these issues using Chrome (both 108 and 109) on MacOS 12.6.
Interesting. Do you have any suggestions on how to fix this? I try not to have strong opinions about which font to use because I want to leave that choice up to the user agent.