Abstract Algebra, looked at through the lens of Programming, is kind of "the study of good library interface design", because it describes different ways things can be "composable", like composing functions `A -> B` and `B -> C`, or operators like `A <> A -> A`, or nestable containers `C<C<T>> -> C<T>`, with laws clearly specifying how to ensure they don't break/break expectations for users, optimizers, etc. Ways where your output is in some sense the same as your input, so you can break down problems, and don't need to use different functions for each step.
Category Theory's approach of "don't do any introspection on the elements of the set" led it to focus on some structures that turned out to be particularly common and useful (functors, natural transformations, lenses, monads, etc.). Learning these is like learning about a new interface/protocol/API you can use/implement - it lets you write less code, use out-of-the-box tools, makes your code more general, and people can know how to use it without reading as much documentation.
Focusing on these also suggests a generally useful way to approach problems/structuring your code - rather than immediately introspecting your input and picking away at it, instead think about the structual patterns of the computation, and how you could model parts of it as transformations between different data structures/instances of well-known patterns.
As a down-to-earth example, if you need to schedule a bunch of work with some dependencies, rather than diving into hacking out a while-loop with a stack, instead model it as a DAG, decide on an order to traverse it (transform to a list), and define an `execute` function (fold/reduce). This means just importing a graph library (or just programming to an interface that the graph library implements) instead of spending your day debugging. People generally associate FP with recursion, but the preferred approach is to factor out the control flow entirely; CT suggests doing that by breaking it down into transformations between data structures/representations. It's hugely powerful, though you can also imagine that someone who's never seen a DAG might now be confused why you're importing a graph library in your code for running async jobs.
Category theory gives us a nice, high-level set of conceptual tools to try to understand and generalize over things that are hard to connect otherwise. Some people find that useful directly, other people just enjoy it for its own sake, or even for aesthetic reasons. (I think all three are totally reasonable!)
At the same time, it's actually rather more accessible than most other areas of pure math—at least at the level that people talk about it online. Basic category theory can be hard to learn because it's so abstract but, unlike almost any other are of math from the 20th century onwards, it has almost no hard prerequisites. You can reasonably learn about categories, functors, natural transformations and so on without needing a graduate degree's worth of math courses first. You might not understand the most common examples mathematicians use to illustrate category theory ideas—but it's such a general framework that it isn't hard to find alternate examples from computer science or physics or whatever else you already know. In fact, I expect most of the articles that get talked about here do exactly that: illustrate category theory ideas with CS/programming examples that folks on HN find relevant and accessible.
Pinging the https://planting.space/ people! I know some of them are on HN, at least recruiting in the past. I haven't updated my knowledge in a while, but my impression of the company was basically that they were going make money using category theory(+all math) in clever and useful ways. I think they turned toward AI a little, but they're at the root a bunch of people who think category theory is useful. Hence, the ping!
It makes it so much more complicated than what is needed to understand natural transformation. Natural transformation is just mapping between two functors. You can discover the laws yourself just from this.
Anyone who likes this might also like Stefan Miller’s paper, “a simple category theoretical understanding of category theory diagrams“, appearing in SIGBOVIK 2014. See https://sigbovik.org/2014/proceedings.pdf (starts on PDF page 65, or page 57 if you go by margin page numbers)
I hate this particular mix of prose and formalism. Too complicated to be pop-sci, too informal to be, well, formal. I got to this part:
> We know that two orders are isomorphic if there are two functors, such that going from one to the other and back again leads you to the same object.
And I have no clue what is a functor, nor order. "Functor" wasn't defined, and "order" is defined as "thin category", which in turn remains undefined.
Seems to me like in order to understand this text you already need to understand category theory. If that's the case, then why would you be reading it?
This is fun. But the bit at the beginning about philosophy is not correct. Parmenides did not believe in what we would call essences, but really did believe that nothing ever changes (along with his fellow Eliatic philosopher Zeno, of paradox fame). The idea that change is an illusion is pretty silly, and so Plato and especially Aristotle worked out what's wrong with that and proposed the idea of _forms_ in part to account for the nature of change. Aristotle extended Plato's idea and grounded it in material reality which we observe via the senses, and that's where the concept of essence really comes from - "essence" comes from the Latin "essentia" which was coined to deal with the tricky Greek οὐσία (ousia - "being") that Aristotle uses in his discussions of change.
I like it when teachers (e.g., Grant Sanderson) are careful to explain when they are trying to convey an intuition to motivate and guide some complex math, because it orients you without tangling you in all the misunderstanding that would come from extending analogies or cross-cultural/discipline comparisons too far.
But when authors start slinging around Plato and Aristotle and especially Parmenides willy-nilly alongside modern principles, they're waving a red flag... Don't get me started!
Isomorphism invariance applies to neural assemblies or syntax, not to mere symbols. The problem in math is it models. Brains do not model. Heraclitus was right if math never enters the picture to add its arbitrariness. "A man in the night kindles a light for himself when his sight is extinguished; living he is in contact with the dead when asleep, when awake he is in touch with the sleeper."
Interesting aside about the Vienna circle and isomorphism. I suspect that’s where Hayek got his idea that mind and representation are isomorphic, echoing Aristotle’s assertion in “On the Soul” / De Anima that the mind becomes the object of perception.
The natural transformation α : F ⇒ G is not specified properly b/c when expressed in compositional form you also have to specify the subscript for the natural transformation & it is an equality instead of an isomorphism, i.e. if f : a → e then αₑ ∘ Ff = Gf ∘ αₐ. There are highter categories where what he has written down can make sense but in the context of the current exposition it is not correct as written.
The author is Jencel P.? I saved this book sometime ago under the author name Boris Marinov? Is this the same person now writing under a different pen name?
24 comments
[ 1.9 ms ] story [ 45.5 ms ] threadhttps://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Category Theory's approach of "don't do any introspection on the elements of the set" led it to focus on some structures that turned out to be particularly common and useful (functors, natural transformations, lenses, monads, etc.). Learning these is like learning about a new interface/protocol/API you can use/implement - it lets you write less code, use out-of-the-box tools, makes your code more general, and people can know how to use it without reading as much documentation.
Focusing on these also suggests a generally useful way to approach problems/structuring your code - rather than immediately introspecting your input and picking away at it, instead think about the structual patterns of the computation, and how you could model parts of it as transformations between different data structures/instances of well-known patterns.
As a down-to-earth example, if you need to schedule a bunch of work with some dependencies, rather than diving into hacking out a while-loop with a stack, instead model it as a DAG, decide on an order to traverse it (transform to a list), and define an `execute` function (fold/reduce). This means just importing a graph library (or just programming to an interface that the graph library implements) instead of spending your day debugging. People generally associate FP with recursion, but the preferred approach is to factor out the control flow entirely; CT suggests doing that by breaking it down into transformations between data structures/representations. It's hugely powerful, though you can also imagine that someone who's never seen a DAG might now be confused why you're importing a graph library in your code for running async jobs.
At the same time, it's actually rather more accessible than most other areas of pure math—at least at the level that people talk about it online. Basic category theory can be hard to learn because it's so abstract but, unlike almost any other are of math from the 20th century onwards, it has almost no hard prerequisites. You can reasonably learn about categories, functors, natural transformations and so on without needing a graduate degree's worth of math courses first. You might not understand the most common examples mathematicians use to illustrate category theory ideas—but it's such a general framework that it isn't hard to find alternate examples from computer science or physics or whatever else you already know. In fact, I expect most of the articles that get talked about here do exactly that: illustrate category theory ideas with CS/programming examples that folks on HN find relevant and accessible.
This is a golden quote.
> We know that two orders are isomorphic if there are two functors, such that going from one to the other and back again leads you to the same object.
And I have no clue what is a functor, nor order. "Functor" wasn't defined, and "order" is defined as "thin category", which in turn remains undefined.
Seems to me like in order to understand this text you already need to understand category theory. If that's the case, then why would you be reading it?
If you press the Prev button at the top of the page it takes you back to Functors. Twice more and it will take you back to Orders.
Well, that's not true.
Particles, and thus facts, pop into and out of existence all the time.
But when authors start slinging around Plato and Aristotle and especially Parmenides willy-nilly alongside modern principles, they're waving a red flag... Don't get me started!