I’m trying to read this carefully, but in section 1.1 I’m already lost, because the text is skimming through concepts without defining things clearly. Specifically:
Let 𝒞2 be the collection of composable pairs in 𝒞. We can describe 𝒞 with the following diagram:
I don’t understand the diagram. It doesn’t define what C1 or C0 are, nor the oC that appears on the leftmost arrow. The text doesn’t offer any explanation of the diagram, it just moves on as though it were self-evident.
(Other things it doesn’t bother to define: “collection”, “composable pair”. Both are hyperlinks, but reading math articles on Wikipedia has trained me against following links for concepts I don’t understand, because that leads to infinite regress. The “collection” link goes to a handwavey definition saying “collections are like sets but less formal”, and “composable pair”, hilariously, links to itself.)
Yeah I exited at exactly that same paragraph :/ I’ve had coworkers recommend category theory as a place to borrow ideas from, for instance as a replacement for the relational model in databases.. but I’ve yet to “get it”, maybe it’s just too big of an area to expect to understand without a ton of prerequisite math education.
I think maybe I’ve been spoiled by things like Codds paper on the relational model where it’s like a “self contained” explanation, without the hyperlinks to infinite recursion math Wikipedia
Collection is sort of a “reserved word” in math, used to mean “a bunch of things we’re talking about together”. “Set”, “Group”, “Class” all have formal definitions and imply certain properties, so “collection” is deliberately left unsued so we can talk about collections of stuff without using a technical word.
A composable pair is two things that can be composed together. f(x) = x + 1 and g(x) = 2*x form the composable pair (f, g) because you can write (f◯g)(x) = 2x+1. In this case, they also form the composable pair (g, f), because you can form (g◯f)(x) = 2x+2.
I think the diagram means “◯ (morphism composition) maps C_2 (pairs of morphisms) to C_1 (individual morphisms), dom and cod maps C_1 (morphisms) to C_0 (objects), and id^C maps C_0 (objects) to C_1 (morphisms)`.
I agree, the book is not very clear and doesn’t explain any of this well.
This bit is particularly nasty since there is rarely any clarity as soon as we get into raised decorations on composition. It’s usually just vibes based and to spring that on people in the first section of a book is… 🤢
I think the diagram means “◯ (morphism composition) maps C_2 (pairs of morphisms) to C_1 (individual morphisms), dom and cod maps C_1 (morphisms) to C_0 (objects), and id^C maps C_0 (objects) to C_1 (morphisms)`.
I sketched out a bit and I also think that’s what the diagram is trying to say. But that also means it does not contain that much of value, it doesn’t “describe C” nor does it illuminate anything else.
Many compsci books use lisp/scheme because it carries less accidental complexity letting you jump right into the topic (e.g. the volumes in the little learner, typer etc. series.) I actually assumed that when posting this and at first thought “oh dear, I should contact the author to add a sketch of Racket and necessary background.” But actually the course does define its main invariant: the expected audience’s background as “racket programmers”. Do you have any experience with lisp? (If you do, this course needs even more work!) There are definite issues with the structure (defining c0, c1 at the beginning, not mentioning them and then having them in a diagram after many paragraphs.)
I think the hyperlinks aren’t the most useful here (e.g. the course title links to itself, like composable pair).
Collection (in the Clojure world) refers to lists, vectors, maps and such, which can be sequential or not. Racket uses sequence more commonly, but terminology still mixes a bit e.g. defining sequences as an ordered collection: https://docs.racket-lang.org/reference/sequences.html Clojure lets you use the same operations on all collection types, which influences libraries like: https://docs.racket-lang.org/collections/index.html Common Lisp uses sequence for Clojure’s wider thing. You should understand a category as a data structure holding 2 collections (implemented as lists, sets or…) 1.2.1.8 compares the Proc and Set categories, where Set has functions as its morphisms (and Proc has procedures, which are… the scheme term for functions!)
Composable pairs are 2 morphisms/arrows which can combine, because one’s output matches the other’s input (e.g. correct time signatures) so you can compose them into a single func. E.g. a max func taking 2 ints outputs the bigger, which can feed into square, taking 1 int. So you can compose the pair into square-max. The key in the text was “composition is associative”. It’s basically saying you can use a chain of arrows in a category chart to make a composed func. Pair is actually not important there, just it uses pairs of morphisms/arrows/funcs as examples, combining them into a composition of 3! (hgf)
At the very beginning of 1.1 it defines C0 as objects (nodes) and C1 as morphisms (edges, links, arrows). From one implementation, the chart shows c2->c1 as mapping (via oC on the arrow) the whole category to the morphisms between the nodes. Then the domain and codomain map the morphisms to the objects. And the id maps those back to the morphisms. These composition operations are implemented in 1.2. They’re the relationships/functions/operators to get to different parts of the category data structure.
I’ve read several introductory texts on category theory and I can just about follow along here.
My main take away from what I read was that the relationship between category theory and programming is either entirely apocryphal or too theoretical to be of any use to anybody.
I tend to think that we, as humans, are simply not smart enough for category theory to be a practical starting point for reasoning while programming.
To expand a little, most people probably use some mathematical basis for their reasoning, like how if you take two numbers and you double them the bigger one will stay bigger, or if you concatenate two non-empty lists, you’ll get a non-empty list etc. We probably all have a network of facts like this in our head we use for reasoning.
If we were much smarter, we could look at a problem, or a solution and recognize that it’s a Kan Extension from some comma category to whatever and immediately derive 15 different and interesting properties about it from this observation alone, or we could say “since these concepts don’t form this sort of category, I know there must be violations of that invariant”, but we’re simply not smart enough to keep these category theory concepts and relationships in our working memory and to make these observations naturally without spending so much time as to make this exercise unprofitable.
Oh it almost certainly does. Every statement you make about a system, every requirement, every assumption induces all kinds of diagrams that have very precise and deep interpretations. Our puny brains simply can’t handle them.
and recognize that it’s a Kan Extension from some comma category to whatever and immediately derive 15 different and interesting properties about it from this observation alone
From what I understand practical category is an entirely nascent field and stuff like this is only just coming out in certain disciplines.
I can reason about our code categorically just fine, but if that means all of the code has to be in obtuse-ass Haskell to be able to do categorical manipulations with it, then it’s a non-starter for most of the projects I work in.
So I got into this stuff through Seven Sketches and I went to study on to find that they are the exception and all other math books and sources suffer from this nonsense.
Literally any math is worth studying if it’s put together as thoughtfully and accessibly as Fong and Spivak did it. Unfortunately that’s 1 in 20-50 of math textbooks, maybe even rarer.
For clarification, it does define them. The 3rd paragraph of the first chapter:
A category 𝒞 is defined by two collections: 𝒞0 of objects and 𝒞1 of morphisms. Think of 𝒞 as a digraph, where objects are nodes, and morphisms are arrows connecting these nodes. For a morphism f from an object a to an object b in a category 𝒞, denoted by f : a → b : 𝒞, its domain (source) is a, and its codomain (target) is b: dom𝒞(f) = a and cod𝒞(f) = b.
The issue’s that it’s too early and far from when they’re next mentioned in the picture.
There’s a lot of code implementing things, then exercises to implement some of the math/concepts shown. It seems to show category theory equivalents to programming concepts, teaching a different paradigm (similar to flow programming, I think, in the same way that array, stack or state machine programs are different paradigms.)
As I’ve not worked through it yet, I might be wrong, but I think the issue’s that it just plays with the data structures and ideas it reveals (like a comp sci book doing algorithms on trees or graphs) and doesn’t quite tie those concepts to practical implementation (“great, I can manipulate trees, now how do I make a useful program with them?”) The author was inspired by this: https://github.com/drym-org/qi check this for details: https://racket.discourse.group/t/todays-qi-meeting-notes/2323/4
I’m trying to read this carefully, but in section 1.1 I’m already lost, because the text is skimming through concepts without defining things clearly. Specifically:
I don’t understand the diagram. It doesn’t define what C1 or C0 are, nor the oC that appears on the leftmost arrow. The text doesn’t offer any explanation of the diagram, it just moves on as though it were self-evident.
(Other things it doesn’t bother to define: “collection”, “composable pair”. Both are hyperlinks, but reading math articles on Wikipedia has trained me against following links for concepts I don’t understand, because that leads to infinite regress. The “collection” link goes to a handwavey definition saying “collections are like sets but less formal”, and “composable pair”, hilariously, links to itself.)
Yeah I exited at exactly that same paragraph :/ I’ve had coworkers recommend category theory as a place to borrow ideas from, for instance as a replacement for the relational model in databases.. but I’ve yet to “get it”, maybe it’s just too big of an area to expect to understand without a ton of prerequisite math education.
I think maybe I’ve been spoiled by things like Codds paper on the relational model where it’s like a “self contained” explanation, without the hyperlinks to infinite recursion math Wikipedia
Because I like explaining things:
f(x) = x + 1andg(x) = 2*xform the composable pair(f, g)because you can write(f◯g)(x) = 2x+1. In this case, they also form the composable pair(g, f), because you can form(g◯f)(x) = 2x+2.I think the diagram means “◯ (morphism composition) maps C_2 (pairs of morphisms) to C_1 (individual morphisms),
domandcodmaps C_1 (morphisms) to C_0 (objects), andid^Cmaps C_0 (objects) to C_1 (morphisms)`.I agree, the book is not very clear and doesn’t explain any of this well.
This bit is particularly nasty since there is rarely any clarity as soon as we get into raised decorations on composition. It’s usually just vibes based and to spring that on people in the first section of a book is… 🤢
I sketched out a bit and I also think that’s what the diagram is trying to say. But that also means it does not contain that much of value, it doesn’t “describe C” nor does it illuminate anything else.
I’m not sure how to help/approach this but it’s very interesting because I’ve been surveying lisp pedagogy: https://www.reddit.com/r/scheme/comments/1gxovy4/im_reviewing_comp_sci_textbooks_using_scheme/ so I’ll try.
Many compsci books use lisp/scheme because it carries less accidental complexity letting you jump right into the topic (e.g. the volumes in the little learner, typer etc. series.) I actually assumed that when posting this and at first thought “oh dear, I should contact the author to add a sketch of Racket and necessary background.” But actually the course does define its main invariant: the expected audience’s background as “racket programmers”. Do you have any experience with lisp? (If you do, this course needs even more work!) There are definite issues with the structure (defining c0, c1 at the beginning, not mentioning them and then having them in a diagram after many paragraphs.)
I think the hyperlinks aren’t the most useful here (e.g. the course title links to itself, like composable pair).
Collection (in the Clojure world) refers to lists, vectors, maps and such, which can be sequential or not. Racket uses sequence more commonly, but terminology still mixes a bit e.g. defining sequences as an ordered collection: https://docs.racket-lang.org/reference/sequences.html Clojure lets you use the same operations on all collection types, which influences libraries like: https://docs.racket-lang.org/collections/index.html Common Lisp uses sequence for Clojure’s wider thing. You should understand a category as a data structure holding 2 collections (implemented as lists, sets or…) 1.2.1.8 compares the Proc and Set categories, where Set has functions as its morphisms (and Proc has procedures, which are… the scheme term for functions!)
Composable pairs are 2 morphisms/arrows which can combine, because one’s output matches the other’s input (e.g. correct time signatures) so you can compose them into a single func. E.g. a max func taking 2 ints outputs the bigger, which can feed into square, taking 1 int. So you can compose the pair into square-max. The key in the text was “composition is associative”. It’s basically saying you can use a chain of arrows in a category chart to make a composed func. Pair is actually not important there, just it uses pairs of morphisms/arrows/funcs as examples, combining them into a composition of 3! (hgf)
At the very beginning of 1.1 it defines C0 as objects (nodes) and C1 as morphisms (edges, links, arrows). From one implementation, the chart shows c2->c1 as mapping (via oC on the arrow) the whole category to the morphisms between the nodes. Then the domain and codomain map the morphisms to the objects. And the id maps those back to the morphisms. These composition operations are implemented in 1.2. They’re the relationships/functions/operators to get to different parts of the category data structure.
I’ve read several introductory texts on category theory and I can just about follow along here.
My main take away from what I read was that the relationship between category theory and programming is either entirely apocryphal or too theoretical to be of any use to anybody.
I tend to think that we, as humans, are simply not smart enough for category theory to be a practical starting point for reasoning while programming.
To expand a little, most people probably use some mathematical basis for their reasoning, like how if you take two numbers and you double them the bigger one will stay bigger, or if you concatenate two non-empty lists, you’ll get a non-empty list etc. We probably all have a network of facts like this in our head we use for reasoning.
If we were much smarter, we could look at a problem, or a solution and recognize that it’s a Kan Extension from some comma category to whatever and immediately derive 15 different and interesting properties about it from this observation alone, or we could say “since these concepts don’t form this sort of category, I know there must be violations of that invariant”, but we’re simply not smart enough to keep these category theory concepts and relationships in our working memory and to make these observations naturally without spending so much time as to make this exercise unprofitable.
Or maybe the vast majority of programming simply doesn’t require the high level of abstraction that category theory provides.
Oh it almost certainly does. Every statement you make about a system, every requirement, every assumption induces all kinds of diagrams that have very precise and deep interpretations. Our puny brains simply can’t handle them.
From what I understand practical category is an entirely nascent field and stuff like this is only just coming out in certain disciplines.
I can reason about our code categorically just fine, but if that means all of the code has to be in obtuse-ass Haskell to be able to do categorical manipulations with it, then it’s a non-starter for most of the projects I work in.
So I got into this stuff through Seven Sketches and I went to study on to find that they are the exception and all other math books and sources suffer from this nonsense.
Literally any math is worth studying if it’s put together as thoughtfully and accessibly as Fong and Spivak did it. Unfortunately that’s 1 in 20-50 of math textbooks, maybe even rarer.
For clarification, it does define them. The 3rd paragraph of the first chapter:
The issue’s that it’s too early and far from when they’re next mentioned in the picture.
Even then, the diagram is pretty inconsequential.
Cursory look, but this seems to have very little to do with programming. Most of the chapters are pure math. Is it a WIP?
There’s a lot of code implementing things, then exercises to implement some of the math/concepts shown. It seems to show category theory equivalents to programming concepts, teaching a different paradigm (similar to flow programming, I think, in the same way that array, stack or state machine programs are different paradigms.)
As I’ve not worked through it yet, I might be wrong, but I think the issue’s that it just plays with the data structures and ideas it reveals (like a comp sci book doing algorithms on trees or graphs) and doesn’t quite tie those concepts to practical implementation (“great, I can manipulate trees, now how do I make a useful program with them?”) The author was inspired by this: https://github.com/drym-org/qi check this for details: https://racket.discourse.group/t/todays-qi-meeting-notes/2323/4
This isn’t a good introduction to category theory. This is a list of definitions of lots of categories.