[nmrm]

> Abstract algebra and category theory are likely relevant, especially for metaprogramming.

In general, the whole "oh yeah CS people should know some category theory and abstract algebra" is pretty hilarious.

First, it's a bit like saying "oh yeah CS people need to know the undegraduate basics and also the generalization that most mathematicians don't encounter until a couple years into grad school."

Second, most people who say this really mean "a conceptual grasp on different types of morphisms is useful". But that's like saying you need calculus in order to drive a car; or, in the case of categories, it's like saying you need two semesters of real analysis in order to drive a car.

Why not just say "knowing about different sorts of mappings is pretty useful in functional programming"? Knowing how this generalizes to more abstract mathematical objects is totally unnecessary.

[shoki]

Well, frankly you can get along not knowing the "Gang of Four" design patterns and write Java. By the same token, you don't need to know about iterables and comprehensions to write Python, smart pointers to write C++, Graph theory to use a Graph database, macros to write LISP, etc.

By analogy, you don't need to know abstract algebra and category theory to write Haskell. But as in the other cases, knowing helps.

[nmrm]

I think you misunderstood my criticism.

"Different sorts of mappings" is NOT synonymous with "category theory". Not even close. Heck, Euclid knew about "different sorts of mappings".

Most everything in Gamma et al is arguably useful for everyday programming in Java. Maybe 5-10 pages of MacLane is useful for everyday programming in functional languages.

Unless by "Category Theory" you mean "5-10 pages of MacLane", Category Theory -- on the whole -- is a horrendously inefficient way of teaching about "different sorts of mappings useful in functional programming."

Unless you want to use functional programming as an environment for doing pure mathematics, there's no reason to actually study actual Category Theory.

[shoki]

Functional Programming is a vast subject.

I've really never needed an abstraction for semigroups, monoids, meet-semi-lattices, monads, comonads, arrows or catamorpisms in Clojure, Common Lisp, Scheme, or Hy.

These concepts become more relevant when I program Haskell, Agda, Isabelle/HOL, or Coq.

I'd say a stronger analogy can be made between reading MacLane's Catagories for the Working Mathematician and reading Hoyte's Let Over Lambda; you really only need to read a little bit of these books to get the core concepts. That being said, depending on what sort of functional programming you're doing, a strong background in category theory or meta-programming can enabling (or not).

[nmrm]

> when I program Haskell, Agda, Isabelle/HOL, or Coq.

That's fair. Although Haskell is a bit of an odd man out in that list, both in terms of its nature and in terms of its typical use case.

> That being said, depending on what sort of functional programming you're doing, a strong background in category theory or meta-programming can enabling (or not).

This is where the analogy between the two books breaks down. When you're using a functional programming language as a proof assistant, category theory can be helpful. But this is far less common than meta-programming.

edit: 2nd paragraph.

[j2kun]

More simply (but hard to appreciate without going through semesters of work): know that structure-preserving mappings are the important parts.

[nmrm]

Yes. But my more important point is that you can tach about these mappings in isolation, in the context of functional programming. No Category Theory needed.

You can teach about "different sorts of mappings" in just about any setting. In fact, that's kind of the whole reason Category Theory exists. So why teach the general result when all you care about is its application to functional programming?

[j2kun]

The importance of structure preserving mappings shows up in many other places besides functional programming. I do believe context is important, but having multiple contexts is even better.

[nmrm]

> but having multiple contexts is even better.

Given the investment necessary to make this jump, I believe that the benefit outweighs the cost for most.

[j2kun]

You don't need to teach category theory proper to get the idea. So I think we are in agreement :)