The category design pattern

Moreover, I think a introduction using terms and ideas from category theory would be more useful, more thorough and more enlightening than an introduction to "compositional programming" without any math. It provides a nice structure and enables you to consider composition more abstractly, which lets you use compositional programming in more places.

It's a great way to encourage code reuse, even in fairly disparate domains. Haskell has some of the most versatile libraries of any language I've used by using mathematical abstractions like this. As a concrete example, there are functions like foldM which is like a normal fold except it can handle errors, state, nondeterminism or even parsing!

The abstractions are well-understood, which makes it easier to reason about. You get a bunch of theorems and conclusions for free just by formulating your program in mathematical terms. You can then easily take advantage of these to simplify, verify or optimize your code. For example, if you know that your data type forms a valid functor, you can always rewrite fmap a . fmap b as fmap (a . b), turning two passes into one! If you wrote a map-like function separately for each different type, taking advantage of this pattern would be more difficult.

You are also restricted in what you can do--any code that is generic across all categories can only use composition. This leaves you less room to make mistakes. If you write a function just for strings, you can accidentally add characters or always return an empty string or any number of string-specific behaviors. If you write a function against some abstraction like a functor, you cannot make any of those mistakes--there is simply no way to formulate them for all functors.

These abstractions are just a reification of a common pattern across a bunch of domains. Making the pattern explicit makes it easier to see and use and makes your code simpler.