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:
I went into more verbal detail in the actual presentation; the argument is something like:
1) Programming is maths
2) Programming is about abstraction and finding patterns
3) CT describes abstract patterns in maths, and is therefore directly applicable to everyday programming.
4) (Exposition of Categories, Functors, Monoids)
5) Comparison of the mathematical concepts to equivalent programming concepts
6) Composability is a huge advantage for software in the large and the small; categories and monoids capture the essence of composable patterns.
7) Abstraction is hugely important for software; it allows to only know what we need, and no more. Category Theory gives us deeper, and dare I say, simpler abstractions. We can find underlying patterns and commonalities that we might have missed otherwise.
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.
Its riding the haskell bandwagon to some degree. By borrowing ideas from category theory they have some really nice abstractions in practical code. But then it gets more confusing so you want to loop back and see what the actual definition of a "monoid" is, or understand "functors". Even if haskell's idea of functor isn't 1 to 1 with category theory's.
> Bottom is a member of any type, even the trivial type () [...] If it were not, the compiler could solve the halting problem and statically determine whether any computation terminated
You can imagine function composition and identity don't work too well on things that never complete.
The biggest confusion for me is why people try to switch from set theory to category theory.
Like sure, I could start calling my functions arrows instead. And my higher order functions - functors, natural transformations or what ever. But what is the gain from doing this?
I agree. Working programmers who want something to apply would be better off studying approximation algorithms, combinatorial optimization, mechanism design, computational geometry, or the many other topics that get little space on HN.
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://i.stanford.edu/~ullman/focs.html
http://www.people.vcu.edu/~rhammack/BookOfProof/