
Category theory for beginners - lelf
http://www.slideshare.net/kenbot/category-theory-for-beginners
======
j2kun
The best exposition I've found for demystifying category theory is the first
few chapters of Paolo Aluffi's Algebra: Chapter 0 [1]. The central emphasis is
on universal properties, which I see most treatments for beginners de-
emphasize or ignore (as these slides do). From my experience, universal
properties are the main tool for unifying and abstracting concepts into the
language of categories. Aluffi uses category theory to unify the treatment of
groups, rings, modules, linear algebra, and then goes on to more abstract
category theory. I have also written a bit on this [2], regrettably choosing
ML as the language of implementation.

[1]: [http://www.amazon.com/Algebra-Chapter-Graduate-Studies-
Mathe...](http://www.amazon.com/Algebra-Chapter-Graduate-Studies-
Mathematics/dp/0821847813)

[2]: [http://jeremykun.com/2013/04/24/introducing-
categories/](http://jeremykun.com/2013/04/24/introducing-categories/)

~~~
imh
I'm a big fan of that book, but there were a few too many important proofs
"left as exercise for reader" for my taste.

~~~
ColinWright
From my experience, if you don't work through those proofs that are "left as
exercise for reader" then you won't ever really come to understand the
material. It's working on proofs that gives you the mastery.

It's like learning music theory without ever composing and performing. It's
like being a eunuchs in a harem; knowing how it's done, seeing it done, but
unable to actually do it.[0] You need to do it to gain any real understanding
and/or ability.

It's like reading about programming, but never actually writing programs.

[0] [http://www.goodreads.com/quotes/33229-critics-are-like-
eunuc...](http://www.goodreads.com/quotes/33229-critics-are-like-eunuchs-in-a-
harem-they-know-how)

------
cheatsheet
I scanned through the first 50 slides or so. I've read and drawn out the first
few chapters to myself of "Categories for the Working Mathematician", so for
me - this was a very nice presentation that graphically illustrated the key
forms and key semantics.

I look forward to reading the code parts.

But I have to agree with other posters - it took a lot of studying to get to
the point where I can understand your slides. I think by the time you can read
mathematics like this, it is because you already understand it verbosely.

As for people who don't agree that this is for beginners, I don't think you
will be able to feel like you get it until you sit down with the work and
stare at it a lot until it makes sense to you. It sounds stupid and silly, but
that's the only way I can really communicate how to learn this stuff with a
feeling of adequate understanding. The simplicity and elegance of the pictures
do not adequately convey how difficult this stuff is to comprehend, especially
if your mathematical foundation involves reasoning about real things. It is
descriptive of abstract layers of terms, and the relationships they construct.
Category theory is essentially the math of maths.

------
commutativering
A serious question, and one not meant to cause offense: why is category theory
being pushed so aggressively? I've seen numerous "Category Theory for
Dummies"-style posts here over the years that all imply CT is somehow
extremely relevant to working programmers in ways that other branches of
mathematics like analysis or abstract algebra apparently aren't. Considering
that most programmers have never rigorously studied even formal logic or set
theory, both of which are directly applicable to formal methods, electrical
engineering, and relational database theory, wouldn't those subjects be better
studied first?

Instead of clicking through a 209-slide PowerPoint presentation you likely
won't be able understand, I suggest reading these free books on those
subjects:

[http://www.fecundity.com/codex/forallx.pdf](http://www.fecundity.com/codex/forallx.pdf)

[http://i.stanford.edu/~ullman/focs.html](http://i.stanford.edu/~ullman/focs.html)

[http://www.people.vcu.edu/~rhammack/BookOfProof/](http://www.people.vcu.edu/~rhammack/BookOfProof/)

~~~
orbifold
I believe it is part of the gradual realization in the commercial software
development community that object oriented programming is a dead end on one
hand and the fact that category theory captures abstractly patterns of
composition, which with enough reflection yield elegant and efficient software
designs.

Trivial examples are things like Map-Reduce, the first step describes is done
by applying a monoidal functor

T B -> T A,

the fact that the functor is monoidal allows for the work to be distributed
across lots of nodes with no communication, the second step uses some
associative algebra

T A -> A

to compute the final result, associativity allows for easily parallizable
computation of subresults.

~~~
im3w1l
I'd argue more people know that we can use parallelism when reducing with an
associative binary operator, than understand what a monoidal functor is.

------
keslag
As a beginner, I can assure you that without someone explaining the point of
the arrows, this is most certainly not for beginners.

~~~
aidos
Right, so can someone explain what the hell these slides mean? I studied a lot
of abstract mathematics at uni but I wasn't exposed to category theory, and
these slides aren't helpful.

They start off with objects, what are they? Are they sets? I'm going to assume
they're sets. Then the arrows represent mappings, something like a function
that takes an input and maps to stuff in one of those other objects (set of
objects?). Then the codomain is the set of objects you can get to by calling
that function on the domain of objects.

Am I in the right ball-park here?

~~~
xyzzyz
Ah, the joys of learning math from slides without the talk the slides were
helpers to.

The objects here are not necessarily sets, and the arrows are not necessarily
functions -- this is actually one of the points of category theory, to
abstract the notion of morphism away from set theory. This becomes necessary,
when in your regular mathematical life you encounter morphisms which are not
strictly functions, but nevertheless in many ways behave as such. Best example
would be the homotopy classes of maps between topological spaces. Homotopy
classes do not map points from domain space to codomain space, but
nevertheless you can compose them, there's a homotopy class of identity, which
acts as an identity on composition, sometimes there are homotopy classes that
are inverses and so on.

If this sounds complicated and unnatural, that's because it is: it is
pointless to learn category theory before learning where and how it is useful.
This is completely opposite order than in which it was conceived, and totally
misses the purpose the category theory, which is to make everything clearer,
to reduce the number of notions, to make it easier to notice analogous
behavior between separate concepts, to reduce number of repeating arguments.
Learning what a morphism or functor or natural transformation is, without
having tens of examples of these notions, only increases the number of
concepts without a corresponding increase in understanding.

My advice is, if you want to learn category theory, learn algebraic topology
first, or at least abstract algebra (groups, rings, modules, fields).
Otherwise, you'll see very little purpose, and very little use.

~~~
nrinaudo
I disagree with your last point, to some extent.

While not strictly necessary, learning a bit of category theory makes FP
abstractions such as functors and monoids a bit more accessible.

I can't disagree with the fact that learning category for that sole purpose
sounds like a lot of work for too little benefit, though.

------
enord
This is a top-down approach starting with CT fundamentals and connecting them
to CS concepts/patterns after 150 slides.

The air is thinner near the top of the abstraction ladder and more or less
unbreathable for people who don't spend considerable time in the Ivory Tower.

~~~
muaddirac
I think if I were attempting to make it more accessible for beginners, I would
start with a concrete example of a category (like Set) and introduce the
concepts in what is, for most people (programmers in particular) familiar
territory, and then attempt to show how abstracting those concepts is useful
and applicable in other situations.

------
losvedir
These slides do the same misleading thing all the other slides I've looked at
do: show examples where there are only an arrow or two between objects. I
still don't really understand category theory, but one breakthrough I had was
when I realized that two objects can (and often do) have LOTS (or even
infinite) arrow between them.

For example, in a category of "types", each object could be a type (e.g.: int,
float, list(int), etc.), and each arrow could be a function between those
types.

With that example, just think of all the arrows between, say, string -> int!
There's "length()", "md5()", "to_i()", etc. And don't even get me started on
the "identity" arrows of string back to itself (upcase, downcase, strip, etc).
We're talking gazillions of arrows.

~~~
tfgg
So, on slide 33, the "+1" and "bestFriend" arrows are identities of Int and
Person? On slide 35 it says that identity is associated with the identity
function, but to me that means a function that returns what you give it,
rather than "+1", which gives you the next number. So the identity of Person
just means any function with the type signature Person->Person?

~~~
orbifold
No, the identity id:A->A is characterized by the property that for all arrows

f:B->A and g:A->C

(P1) id . f = f and (P2) g . id = g, in particular it is unique, since if
id':A->A had the same property, then

id' = id . id' = id,

where the first equality follows by (P1) and the second by (P2').

~~~
tfgg
Ok, I think I got the wrong idea that the identity was any arrow pointing back
on to an object. Thanks.

------
cfeduke
If I didn't have a couple years of shipping Scala code into production I'm not
certain I'd understand the slides by themselves. (Having audio and/or video to
go along with the slides would be a great help!)

I don't have a math background, but write a lot of Scala anyway. These slides
filled in the blanks in a lot of places for me though largely because I could
relate to how I've written code.

This is an excellent resource and its piqued my interest in learning more
about category theory.

------
Xophmeister
See also Bartosz Milewski's very nice WIP blog series[1] on category theory
for programmers.

[1] [http://bartoszmilewski.com/2014/10/28/category-theory-for-
pr...](http://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-
the-preface/)

------
alfonsodev
is there any video/audio that complements this slides ?

~~~
throw7
That is my question. I'm not sure how I'm supposed to learn anything from a
powerpoint presentation (the worst way to convey any type of information).

------
akeck
If two categories are related by a functor, does that imply that the first
category is isomorphic to the second category?

(I'm very new to this topic, but I have an applied math background.)

~~~
j2kun
That's half of it. If you have another functor going the other way, with some
properties on how the two functors relate, then you get what's called an
equivalence of categories. [1] Basically, you need both ways to compose the
two functors to be "equivalent" to the identity functor in each category
(equivalent as shown by a reversible natural transformation).

[1]:
[http://en.wikipedia.org/wiki/Equivalence_of_categories](http://en.wikipedia.org/wiki/Equivalence_of_categories)

------
serve_yay
As thankful as I am that this was made and published, I find only slides with
no talk very difficult to try to learn from. I kinda wish slideshare wasn't a
thing :/

------
runT1ME
I am a bit confused, I had thought there could not be multiple isomorphisms
from object A to object B. I thought an Iso was an epi and mono, doesn't that
mean the arrows must all be the same? Thanks in advance if someone wants to go
through all the ways I'm misunderstanding. :)

~~~
nrinaudo
if f is an isomorphism between A and B, it simply means that there exists f-1
such that f(f-1) = idB and f-1(f) = idA.

I don't think anything in this definition allows us to conclude that there can
only be one such f between A and B. Indeed, if A and B are sets of identical
cardinality, I'm pretty sure you can create n! isomorphims between the two
(where n=|A|). Drawing a picture of of two sets with two elements each should
let you see it.

~~~
runT1ME
Oh. I think I was confused, arrows can be equal (extensionally so), but not
the 'same'.

------
ryanobjc
This is an ok introduction, but for a much much better introduction check out
the book "Conceptual Mathematics". It does a little better than using abstract
words like 'objects' (which has a particular connotation for programmers).

~~~
nrinaudo
It also takes bloody ages getting to the "good" parts like monoids and
functors :)

------
kenbot
Hi everyone, author here.

One thing to remember is that each slide had a lot of verbal explanation
around it, so I'm not surprised that it's confusing by itself!

We took a video, so hopefully it turns out OK so we can put it online.

------
im3w1l
Could someone explain slide 90-92 to me?

I know what map does and I know what a functor is, but I don't know scala, so
I can't understand what the slides are saying.

~~~
nrinaudo
Well, they're a bit weird. I'm not sure why the signature of map magically
changes between slide 91 and 92 and find it very confusing.

Slide 90 is straightforward: Functor is a trait (sort of like an abstract
class) that takes a type parameter F, where F is a type constructor that takes
one type parameter.

Examples of such type constructors are List (used to create List[Int],
List[String], ...), Set (Set[Int]...), Option (Option[String])...

The Functor trait declares a map method that, for any two types A and B, take
an instance of F[A], a function from A to B and returns an instance of F[B].

A concrete example: F is List, A is String and B is Int. map takes a list of
strings, applies a function that turns strings to ints (say, strlen), and
returns a list of ints - the Functor instance for List replaces each of its
elements by applying the specified function to it.

A functor in FP really is an endofunctor in the category of types, in which:

\- objects are concrete types

\- arrows are unary functions

That is, a functor in FP must map:

\- concrete types to concrete types

\- unary functions to unary functions.

In slide 91, you see that map maps instances of concrete type F[A] to concrete
type F[B] - List[String] to List[Int], for example.

In slide 92, you "see" that map maps functions from A to B to functions from
F[A] to F[B] - it lifts strlen into a function that takes a List[String] and
returns a List[Int].

I'm assuming that slide 92 is meant to show partial application of map, but it
really could be made clearer. The author probably explains things more while
giving the presentation, but the shift from slide 91 to 92 really is a bit
handwavy and magical.

Hope this clarified things a bit, but feel free to ask for more if not, I'd be
happy to expand on / correct the parts that you still find obscure.

~~~
im3w1l
Yeah, that helped clarify it alot :)

Just one question to check my understanding. That definition of a Functor is
not completely general right? Since it always takes an object _ to an object
F[_].

Like one functor could be to compose an arrow with addition of 0.5 . And that
would map X->int arrows to X->double arrows, right? But that would not be
compatibe with the Functor trait?

~~~
nrinaudo
I'll be using pseudo code and skip over some technical details that are
entirely irrelevant to this conversation in my answer. I hope I understood
your question correctly and not answering something else entirely.

First, a functor doesn't go from A to F[B] but from F[A] to F[B]. A to F[B]
looks suspiciously like something a monad does, a topic we don't want to get
into.

Your example is a functor that maps unary functions to unary functions by
composing them. It's a good if slightly complicated example: unary functions
have two type parameters (A and B in A => B), while the slide's Functor only
takes one. That is, you want to write a Functor[A => B], but you cannot, or at
least not directly.

What you do is fix one of the parameters. You don't write a Functor for all
unary functions, but a Functor for all unary functions whose parameter type is
C (for concrete): Functor[C => A], where C is a concrete type and A the
functor's type parameter.

This functor's map method takes an instance of (C => A), a function f: A => B,
and yields a function C => B. The only non-pathological implementation of this
is composition: C => A => B

What I just wrote makes it sound like you need to write a Functor
implementation for all possible parameter types, but that luckily isn't true:
writing a function that yields a Functor[C => A] for any given type parameter
C is trivial. I'll put the code here just to show it is, but you don't really
need to understand it:

// I know the C => ? isn't standard Scala, I'm using kind-projector syntax to
make this readable. implicit def functionFunctor[C] = new Functor[C => ?] {
override def map[A, B](fa: C => A)(f: A => B): C => B = f compose fa }

To go back to your concrete example: you just need to get functionFunctor[X]
and call map on (x => x * 0.5) to get your function from X to double. Note
that some technical details are skipped (partial application, calling the
binary function map with a single parameter), but I arbitrarily deem them
irrelevant to my point.

~~~
im3w1l
You misunderstand my question. I realize in hindsight how it was ambiguous.

I used the word "object" like it is used in slide 55. Functors map objects to
objects and arrows to arrows. I.e. arrow is the (co)domain of the functor, and
object is the (co)domain of the (co)domain of the functor.

