

Category Theory: Who Needs Types? - nkurz
http://bartoszmilewski.com/2014/11/24/types-and-functions/

======
nkurz
I've read this article ([http://bartoszmilewski.com/2014/11/24/types-and-
functions/](http://bartoszmilewski.com/2014/11/24/types-and-functions/)) , and
the first article in the series
([http://bartoszmilewski.com/2014/11/04/category-the-
essence-o...](http://bartoszmilewski.com/2014/11/04/category-the-essence-of-
composition/)), and the introduction
([http://bartoszmilewski.com/2014/10/28/category-theory-for-
pr...](http://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-
the-preface/)). They've all gotten a significant number of upvotes here on HN,
but no commentary about the contents.

Reading them makes me fear that I simply lack any proper capacity for
abstraction. I liked thinking about the throwaway line that "an object should
have more surface area than volume", but there hasn't been anything else that
I've been able to grasp hold of. Nothing seems wrong, but so far, nothing
seems particularly right either. He could just as well be discussing
typography as type theory.[1]

Could someone who understands where he is going with this series jump ahead
and talk about how a better understanding of category theory has improved
their programming? Insights that wouldn't have occurred without it? I'm all
for pure math as pure math, but I'm struggling to see how he's going to make
the leap to practical programming. Or perhaps that isn't his intention?

[1] Come to think of it, his comment that Haskell accepted a double colon or
the single unicode character equivalently was one more thing I felt I grasped.
It struck me as a dangerous design decision, though.

