
Categories from scratch - mmastrac
http://staff.science.uva.nl/~poss/categories-from-scratch.html 
======
freyrs3
For those interested in a little more rigor, there's a great series of
lectures on the subject that was just posted online from Steve Awodey, who
wrote one of the best introductory texts on the subject.

[https://www.youtube.com/watch?v=BF6kHD1DAeU](https://www.youtube.com/watch?v=BF6kHD1DAeU)

------
daffodil2
The article argues against overly formal approaches, but I actually think it
errs too much in that direction. When I'm studying a math thing, at some point
I need you to shut up with the English words and simply describe the object in
terms of sets, functions, relations and properties. Categories stopped being
mysterious for me once I realized they were just multigraphs with a certain
algebraic operation defined on edges (composition) such that edges with
certain properties (identities) were stipulated to exist.

~~~
rfrey
"Categories are just multigraphs with composition and stipulated identities on
edges, what's the problem?"

Just kidding, I appreciate the trailhead. :)

~~~
sanderjd
Ha, I actually read his last sentence as sarcasm initially and thought
"haven't I heard this joke..." only to find that you had already referenced
the one I was thinking of:

"A monad is just a monoid in the category of endofunctors, what's the
problem?"

~~~
daffodil2
I didn't mean to imply it was trivial to understand, but it's no more
difficult than the formal definition of, say, a derivative (which involves a
limit, and hence an epsilon-delta construction, which in my experience are not
so easy to fit in your head at first). Understanding what a multigraph is
should be doable.

~~~
sanderjd
I totally agree with you, but jargon of all kinds just sounds funny to people
unaccustomed to it, regardless of its difficulty to understand!

------
nmrm
> More specifically, the common explanatory route to approach categories is
> usually: “here is a formal specification of what a category is; then look at
> these known things from maths and theoretical computer science, and admire
> how they can be described using the notions of category theory.” In
> practice, quite a few people only adopt conceptual objects by abstracting
> from two or more contexts where the concepts are applicable, instead.

(Note the instead.)

I understand the author's point, and perhaps these examples are easier to
follow for non-math people.

However, to be fair, this approach is the approach taken by pretty much every
single description of Category Theory I've read. One of the first things
MacLane does is provide a bunch of relevant and familiar examples (groups,
rings, etc).

~~~
freyrs3
The examples the author chose are kind of hand-wavy, unix pipes in full are
obviously not categories. But I recognize how hard is to come up with examples
that aren't contrived and that programmers can relate to without knowing much
mathematics.

That's the inherent difficulty in discussing category theory solely in terms
of programming, it's hard to see the forest for the trees if you don't have a
bunch of well-defined categories you can draw examples from and interrelate.

In an undergraduate course one would typically start with examples from
algebraic topology which has a lot of great cross-categorical relations, like
how the homology group of a topological space is an example of a functor from
the category of groups to the category of topological spaces.

~~~
nmrm
> That's the inherent difficulty in discussing category theory solely in terms
> of programming

Worse, I don't see any point in categorical models if you want to think solely
in terms of programming.

> one would typically start with examples from algebraic topology

My initial exposure was along these lines as well, although the idea of a
"course" in category theory seems a bit odd (not in the sense of wrong or bad,
just not common-place).

Talking about categories in the context of everyday functional programming
(even where the connections are correct) always seemed abstruse and a bit
silly. If you're not using categorical models, what's the point (other than
giving fancy names to things)? And if you don't have some background in
algebra or topology and a specific research goal, why build the models?

~~~
freyrs3
Well I mean, there is a lot of utility in programming with categorical
concepts in Haskell. There's plenty of libraries in the Haskell ecosystem that
wouldn't even exist if it weren't for drawing upon category theory for
guidance. Pipes is probably the best example of this school of thought on
library design. [1]

My point was mostly that I don't think there is a path to really understanding
the full generality of category theory through functional programming alone,
one has to go learn the pure mathematics as well.

[1]
[https://hackage.haskell.org/package/pipes-4.1.1/docs/Pipes-C...](https://hackage.haskell.org/package/pipes-4.1.1/docs/Pipes-
Core.html#g:2)

------
acbart
+1 for actually providing meaningful contexts! This is right in line with
Situated Learning Theory, to think about how your audience is full of
Engineers that want relevant examples rather than abstract math.

------
hardwaresofton
This is fantastic. I just read through it and it is a fantastic diversion from
the usual descriptions of category theory

I scoffed at the "we'll explain it in computer terms" notes at the beginning,
but that caveat really helped.

------
solomatov
This post is useless. The most important notions of category theory, namely
universal mapping properties, natural transformations and adjoints aren't even
mentioned.

~~~
bronxbomber92
It's useful for intuitively conveying the notion of what a category actually
is. I think many people don't even get past this point. So that in and of
itself seems useful to me.

~~~
tluyben2
Exactly; even though I understood it before; it's hard to convey this to
people in 'normal' language. I think this page does that well.

