I am asking myself that question regularly, as I'm trying to get more comfortable with "real" category theory. My background is programming, and I've become familiar with a lot of the applied CT (functors, monads, monoids, applicatives, ...).

I think the point of category theory, especially applied category theory, is recognizing what can be further abstracted as an arrow and an object. This turns something that originally is complex and has no apparent structure into a simple dot and arrow, again. Then rinse and repeat.

For example, you can take a for loop that applies a function to a list and then creates a new list. You can't "easily" add another for loop that then applies a second transformation. But if you recognize the functor from the category of types to the category of types, then you can formulate your 2 composed for loops as `list.map(f1 | f2)`, and everything is "trivial" arrows and objects again.

Turn that into a function that returns a list, and you want to concatenate the result. "Annoying" to write, you have to flatten your list. Recognize the monad, back to a simple composition of two morphisms, even though the morphisms encapsulate a lot.

Learning and applying CT I think is recognizing which things can be conceptualized as a morphism, which then magically makes things appear "simple." Yet it is only simple if you have done that recognition work, and more advanced concepts in CT are there to assist you.

> For example, you can take a for loop that applies a function to a list and then creates a new list. You can't "easily" add another for loop that then applies a second transformation.

This is quite unconvincing.

Easy solution 1: add a second loop which takes the first loop's output and transforms it with f2.

Easy solution 2: realise you are doing one transform after another and replace out.add(f1(x)) with out.add(f2(f1(x)).

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.