How to derive solutions like solution 2 is what category theory helps me with. It sounds glaringly obvious in the cases where the abstraction is well understoo

How to derive solutions like solution 2 is what category theory helps me with. It sounds glaringly obvious in the cases where the abstraction is well understood Mapping on lists, on trees, on Maybe, on Result are all well known at this point, because most APIs offer it. Less obvious is the fact that this applies to say, a serial interface, sensor readings, futures. If you can then express the concept of a functor in the programming language itself, you can start writing code that only relies on the fact that something is a functor. And then pass it a list, a serial interface, futures, futures of serial interfaces, etc… For example, you could potentially find use in expressing your above code as: out = makeMapped(out, [f1, f2]) Now I can just pile 18 more functions defined in a config file without having to write it out. out = makeMapped(out, configFile.createFunctions()) I’m not saying you need category theory for this, the same way you don’t need algebra every time you add two numbers, but it makes it easier to see these patterns. I have trouble finding good “practical” examples, because you can use either functors, that every experienced programmer already knows intuitively so well that the concept is ingrained. If you bring up monads, people often react viscerally. In practice, I often just take the time to write out monads without even mentioning the word or concept, and refactor code so that it leverages that underlying structure, and that usually makes things become apparent. Monads are a really good structure to cut down on absurd complexity for anything dealing with state and concurrency, and turn it into an elegant problem.sequence(step1, step2, step3, step4) formulation.