Now, I think it's going alright. I have only 6 people in on this class, including one professor, but I imagine that if I teach it again in the future and advertise it a bit harder that there will be more.
It's been an interesting experience, though, because I've realized one of the big problems with trying to explain category theory: it's too young a field. We have all the definitions, but none of the metaphors. There's no coherent narrative to give you intuition. "Categories for the Working Mathematician", one of my all time favorite books, cheats pretty seriously on this front. It never gives a basic vocabulary to use to describe any of these structures, it just gives so many examples from other areas of math that you start to build an intuition; however, you have almost no words with which to explain this intuition.
I was inspired to write more about this because of a thread on reddit. I strongly disagree with the sentiment that one should be able to explain the concepts of category theory in terms of functional programming. Some ideas in category theory- such as representable functors, adjoints, hom-sets, topoi - are general enough that any attempts to squash them into Haskell code is simplifying to the point of confusion. An example of this is Dan Piponi's old post on the Yoneda lemma. While it's good and gives intuition, it's also a bit of a lie- the Haskell arrow (->) is not actually a hom-set and Yoneda is all about the relation between hom-sets and natural transformations that allows you to embed any category C into the category of functors from C to Set, a category with much richer logical structure. As much as the analogy to Haskell helps, I think it hurts by making the big, general, picture harder to see.
So is the solution to suck it up and just bang your head against Mac Lane, never thinking about how it relates to code? Of course not! Let's take a slight detour, first, before talking about what to do.
So Paul Graham has this famous essay - famous enough I don't even see a point to linking it - about "Blub programmers" and how they're blind to the powers of better tools because they only know Blub. It probably wasn't Graham's intent, but this essay is usually referenced by language evangelists to explain why some programmer they talk to isn't instantly willing to adopt their favorite language despite how awesome it is. It's a seductive explanation. The people who disagree with them don't "get it" or just aren't trying.
The more likely reason? They're terrible at explaining why their language is good.
When I was a grad student in physics, most of the grad students (myself included, much to my shame) joked about how dumb all the pre-med students were and how they never wanted to do any work, because that was the most convenient explanation for why there were so many complaints about how hard & confusing the labs, lectures, etc. were.
The more likely reason? We were terrible at explaining physics.
That brings me back to the course I'm teaching. I'm spending the majority of my time trying to figure out real metaphors for explaining category theory, especially with respect to its uses in Computer Science.
So far, the basic story I'm going with is that category theory is about "modeling structures". Functors are about instances of models in a target category. Natural transformations are ways to move between two models in a "coherent" fashion. I'm still fleshing out this language, and I don't know how terribly helpful it will be at the end of the day, but I'll be cleaning up and releasing my notes at the end of the term as one long pdf. The point is that there's still a lot of programmers, computer scientists, and even mathematicians that don't see category theory for the beautiful foundational math I see. Now, it's possible that they're all stupid or don't want to work.
The more likely reason?