To clarify my above comment, since most responses are tangential... I’m comfortable with abstraction. I only want to see a hard/confusing solution become easy w

To clarify my above comment, since most responses are tangential... I’m comfortable with abstraction. I only want to see a hard/confusing solution become easy with category theoretic ideas. (Need not even be an “everyday” problem; all kinds of examples appreciated) One possibility I can imagine is that in a highly compositional language like Haskell, where structural patterns could be factored out as libraries, identifying patterns in a new problem means that you can now just use the library to take care of the structural “boilerplate” when writing code to solve the new problem, and focus purely on the domain-specific tidbits... in a sense allowing maximal code-reuse and convenience. It’s not Luke one couldn’t have solved the problem without categories — it’s just that there’s less “design pattern” boilerplate and correctness guarantees. I guess this is what it means to “make the trivial into trivially trivial” :-) Tho approach is then not very useful when you’re interested in solving only a single problem. But if you want to solve many problems, then this approach gives HUGE leverage towards reducing incidental complexity in code, and should be particularly useful when designing frameworks/libraries/DSLs/etc for maximal reuse.