
Does category theory make you a better programmer? - jamesbritt
http://debasishg.blogspot.nl/2012/07/does-category-theory-make-you-better.html
======
tikhonj
I think it does. Of course, I think this as somebody who has just begun
learning about it, so I certainly don't speak from any experience :P.

Particularly, category theory seems to center around _abstraction_. I think
abstraction is essentially the core of CS (but maybe that's just because of
SICP) and exceptionally important in everyday programming. Learning this sort
of math (along with some related fields like abstract algebra) essentially
allows you to unlock a higher level of abstraction.

This can help in two ways. For one, it allows you to write more general code
and create extremely useful libraries. The Haskell standard library,
naturally, is a great example of this. Additionally, it helps with _thinking_
about conceptually difficult concepts in programming. For example, even just
the basic ideas of category theory really helped me to understand and work
with non-deterministic programming. Thinking about composing non-deterministic
functions, and how these functions behave much like normal functions, made
life much easier.

Category theory is one of the more abstract branches of math, so it's no
surprise that it lends itself to great programming abstractions. Understanding
and using such abstractions in a uniform and systematic way is extremely
useful, so I think it's definitely an area that would be beneficial for
programmers to study.

It's also fun, but that's another story entirely :).

~~~
sznurek
I was learning Haskell for last six months (part of my undergraduate studies).

It was (and is!) fun and challenging but I had hard time seeing any measurable
profits from learning what are and how to use functors, monads etc.

Until recently when I was writing asynchronous communication framework in
Python and I was searching for simple solution to sequence actions in this
heavily callback-based environment.

Now everything looks so simple... (I am looking at you, monads!)

The bad part is that many people do not know what I am talking about when I
try to describe them the design ;)

~~~
runT1ME
I had the exact same experience! A light went off when I figured out how to
elegantly sequence asynchronous calls in Scala, and it was then that I
realized I was using Monads to do so.

However, I am curious if python's solution looks ugly (since they don't seem
to have a 'do' or 'for' expression that Haskell and Scala have respectively)?

~~~
wonderzombie
I'm guessing you can't really do a 1:1, although maybe the OP can clarify.

They do stuff like this in jQuery, so I can't imagine it's all that difficult
in Python.

My initial thought would be to write something analogous to Maybe. You can't
pattern match in Python, which is a shame, but you could make it so that
foo.bar().baz().quux() will return MaybeResult, which everything involved in
the transaction inherits from. MaybeResult might have a "success" variable on
it indicating whether it ought to be treated as Nothing. Otherwise, check
"result."

This is naive but it gets you a little bit closer to fault-tolerant chaining
of interdependent methods. Not as nice as Haskell, obvs. :)

~~~
sznurek
I wrote 'monad-inspired' structure because of lack of syntactic sugar (do
notation). So it basically looks like that:

    
    
      login_action = Write('PASS') >> \
                     Read('pass') >> \
                     Guard(lambda v: v['pass'] == 'mysecret') >> \
                     Write('WELCOME')
      
      register(socket, login_action, on_success=func1, on_error=func2)
    

Of course you can develop this idea futher:

    
    
      cat = Read('line') >> Write(lambda v: v['line'])
      cat.append_action(cat)
    
      register(socket, cat, on_error=handle_error_cb)

~~~
edwkar
Nice!!

------
skybrian
In my experience, programmers who try to "think generically" tend to write
overly abstract code that just gets them into trouble and leaves a mess for
the next programmer. So maybe knowing category theory makes you a worse
programmer?

It seems like this question would be more convincingly answered by showing how
a practical program can be improved by knowing some category theory.

~~~
tikhonj
I think the opposite is true: more abstract code is _easier_ to maintain. Why?
Because the abstractions constrain what you can do in well-defined ways. Code
for your particular domain tends to be somewhat undefined. What sorts of
behaviors should you allow? What sorts shouldn't you allow? The answers are
going to differ with each domain.

On the other hand, these questions are _very_ well defined for mathematical
concepts. If all you know is that you're operating on a functor or on a monad,
the possible behavior you can rely on is based on concrete mathematical laws.
As a simple example, take lists. If you just treat lists as lists, there are
all sorts of possible problems you can run into: off-by-one errors, not
accounting for empty lists and so on. If you write code across all functors,
on the other hand, you _cannot_ make any of those errors.

Essentially, abstraction like this lets you concentrate all the possible
errors in a very small portion of your code. You can write the abstract code
assuming that the functor laws or the monad laws or whatever applicable laws
hold. Moreover, since the code is polymorphic, the type system guarantees that
you cannot do anything not provided by the abstraction you chose. Code that
does something beyond the abstraction is simply not well-formed--it relies on
properties of the type you simply cannot access.

This means that all your code will be valid given that the type behaves like a
proper functor or monad or whatever. Now the only code you have to test for
your particular domain is the functor or monad instance. Once you prove that
your monad instance follows the monad laws--which really isn't very difficult
in most cases--you know that all your abstract code _also_ works for this
particular domain. So now the only place you can have an error in is the code
making your type an instance of some type class. This should be much easier to
maintain than having a bunch of ad-hoc code for each particular domain!

In short: more abstract code is _easier_ to maintain because it restricts the
programs you can write. If you rely on as little knowledge about your
particular domain as possible, you will have far fewer places to make a
mistake. Mathematical abstractions are particularly good because they tend to
be far better defined and understood than purely programming abstractions.
Something like Iterable doesn't have the sort of mathematical laws that
classes like Functor and Monad do.

~~~
skybrian
I'll agree that if you have an important invariant then it's nice if the
compiler can check it. But the question to ask is: where did these constraints
come from? How do you know they're true? What if they change?

If they're business requirements: can you undo them if the business changes?
If they're environmental constraints: do you really know mobile phones or
browsers or the server OS that well, and what do you do when a new version of
the environment comes out and invalidates your assumptions?

Generally speaking, it seems better to take our inspiration from scientists
doing empirical work, rather than from mathematicians. Use tests to figure out
how the code you depend on really behaves, not how you wish it would behave.

------
strlen
This is a very well written post and I have a great deal of respect for its
author. I also happen to find Category Theory to be extremely beautiful, but
its beauty (much as the beauty of many other theories in physics and
mathematics) does not rest upon its applicability to programming.

The ultimate answer to the question is more nuanced: understanding functors
and monads is probably only moderately correlated with programming skill and
not just in an enterprise software context (would it be of any use to an
embedded programmer or a kernel hacker?). Additionally, using and applying a
limited subset of category theory in practical context (lifting, functors,
monads) does not really require understanding category theory per-se, although
I'd imagine it's a good "gateway drug" (learning Haskell had this effect on
me).

------
DanielRibeiro
Yes. It can also make you a better topologist, physicist and logician, as this
paper states it[1]: _Physics, Topology, Logic and Computation: A Rosetta
Stone_

This paper is also a very good introduction to Category Theory.

[1] <http://math.ucr.edu/home/baez/rosetta.pdf>

------
justincormack
You don't need Category Theory to tell you that there is a duality between
structs and unions, any C programmer could tell you that.

Mind you I spent a lot of time working with Haskell in an academic environment
and never understood the first thing about category theory. Especially those
bloody diagrams that were supposed to be proofs.

It is entirely possible to understand functional programming and abstraction
without understanding any category theory...

~~~
j_baker
I disagree. I think that if you understand functional programming and
abstraction, you understand a certain amount of Category Theory even if you
don't know to call it "Category Theory".

~~~
lubutu
Analogously, "you don't need maths to tell you that one and one is two."

~~~
DanWaterworth
As soon as you have an understanding that one and one is two, you have maths.

------
michaelfeathers
Every new way that you can impose a schema on the world helps you as a
programmer, as long as you know that it is just another way of looking at
things.

------
pgcosta
One of my CS teachers is very bold on saying that understanding program
calculation can increase the quality of code, though he fails completely to
help his students apply the knowledge he "preaches". Anyway is a very
intelligent guy(genius like), and is making a book on the subject (still
incomplete). Here's the link if you're interested:
[http://wiki.di.uminho.pt/twiki/pub/Education/CP0809/Material...](http://wiki.di.uminho.pt/twiki/pub/Education/CP0809/MaterialApoio/pdbc_part.pdf)

My teacher does bring up interesting points, such as the lack of programming
quality these days, and the lack of precision in what should be very precise
and defined, namely "software engineering".

------
nnythm
It seems like you get most of this stuff from a basic abstract algebra course.
How does category theory help me beyond what I got from modern algebra 101?

edit: this is from the perspective of someone who knows a little abstract
algebra, and wonders if it would be sufficient to brush up on my algebra to
get these ideas, which seem a little familiar, or if category theory is really
important to get these ideas. I'm not trying to be a contrarian.

------
patrickmclaren
Although some aspects of Category Theory will apply to Programming, it seems
to me to be a slight abuse of language in that the majority of the theory does
not correspond to physical and/or digital systems.

More importantly, Category Theory is a language that allows you to describe
behavior and qualities, abstractly; it does not prescribe a specific
methodology.

------
Confusion
Do any of the following awesome programmers know _and purposefully use_
category theory:

\- Linus Torvalds

\- Joshua Bloch

\- Fabrice Bellard

\- John Carmack

\- Alan Kay

\- Peter Norvig

\- Paul Graham

\- Rich Hickey

If not, then I think there are many different things that would make you a
better programmer, before learning category theory is worthwhile to learn.

Let's also ask the reverse question: name an awesome programmer, preferably
with an open source example of his code, that knows and uses category theory.

~~~
jonsen
Did any of the following awesome scientists know and purposefully use
calculus: Galileo, Kepler ...

~~~
Confusion
Calculus didn't exist in their time, so it couldn't be used by them. Moreover,
much progress has been made in science, partly due to calculus. In fact, an
awesome scientist today is much more powerful than an awesome scientist back
then.

Can you show examples of practical progress made in computer science due to
category theory? A bugfree web server, a secure web browser, an OS perhaps?

------
conformal
this is a bit of a stretch in that the concepts used in category theory are
surely useful to programmers, but in reality programming is often sufficiently
complex that category theory is too general to apply. you can spend all day
drawing diagrams about morphisms, direct products, pullbacks, etc but the real
work is in coding the api, not drawing pretty pictures.

most programmers don't have the time or inclination to complete an
undergraduate degree in mathematics, which is essentially a prerequisite for
taking a legit category theory course. category theory is usually taught at
the graduate level.

category theory definitely helps in theoretical physics :)

------
taybin
Yes, in the same way learning anything can make you a more well-rounded
person. Learning category theory would also make you a better basket weaver.

~~~
slurgfest
But short of evidence (say, a randomized controlled trial) there is no reason
to believe that the baskets would be better in any way.

~~~
bluekeybox
But at least you will know what a braided monoidal basket looks like and
whether it is rigid enough to belong to the strongly ribbon category.

