I find that category theory often starts to feel like Inception math, where it’s very easy to lose track of what “level” one is operating on. The statement “category of endofunctors” is a good example; for someone with a very visual intuition like myself it feels like something that simply cannot be visualized, or is akin to visualizing a 5d hypercube.
> The statement “category of endofunctors” is a good example; for someone with a very visual intuition like myself it feels like something that simply cannot be visualized, or is akin to visualizing a 5d hypercube.
Follow this recipe and don't skip any steps:
1. Understand what a category is. Objects and arrows between the objects, composition of arrows, identity arrows.
2. Understand what a functor is. Associate each object of one category with a corresponding object in a second category. Do the same for arrows.
3. Understand that an endofunctor is just a functor where the first and second categories are actually the same category. These are the functors that show up in programming: Maybe/Option, List, etc. The objects of the category are types and the arrows between them are functions.
4. Understand what a natural transformation is. In programming terms, a natural transformation is like a generic (in the OOP sense) function. Example: length : List<T> -> Int is a common natural transformation that takes a list and returns its length, and it works for any type of list (i.e., for all T). This particular natural transformation goes from the List functor to the constant functor that maps every type to Int (see how T doesn't show up in the return type in this example).
5. If natural transformations go between functors, consider making a category where the objects are functors and the natural transformations are arrows. This is the "category of endofunctors" you're looking for. If you have trouble visualizing it, any category can be visualized as a directed graph: the nodes in the graph are endofunctors like List, Option/Maybe, etc. and the edges are natural transformations like "length".
Each step will require you to Google something, stare at its definition, and spend time with examples. The one mistake that everyone makes is thinking that they should understand the phrase without first learning the constituent words. There's nothing mysterious or clever or tricky going on. You just have to know how to break it down into an incremental curriculum (which I've done for you here).
I know what each of those things are. The problem is that there isn’t a tidy image (at least I haven’t come up with one) that combines all of it.
Yes, visualizing a category is easy: directed graph. Visualizing a functor is also not much of a stretch. But combining these two? Not sure what image is appropriate.
> The problem is that there isn’t a tidy image (at least I haven’t come up with one) that combines all of it.
I don't think you should expect there to be an image that shows all the levels of abstraction at once. The image should only show you the level of abstraction that you're currently concerned with: in this case, endofunctors and the natural transformations between them.
What you're asking for is akin to asking for an architecture diagram of a distributed system that somehow also shows you the circuits inside the CPUs.
The point of abstraction is to package up details into a box and forget about them, for the purpose of managing the complexity as you reason at a higher level.
I find that category theory often starts to feel like Inception math, where it’s very easy to lose track of what “level” one is operating on. The statement “category of endofunctors” is a good example; for someone with a very visual intuition like myself it feels like something that simply cannot be visualized, or is akin to visualizing a 5d hypercube.