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.
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)).
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.
The short answer is that a category also satisfies two rules: every object has an arrow to itself (identity) and if there are two arrows (a->b) and (b->c) there is an arrow (a->c) (associativity).
Other abstractions such as functors (mappings between categories) are built upon this relatively simple foundation. You can also think about categories of categories (they can be considered an object, after all!), and so on and so forth.
Some complain about the generality of Category Theory ('It is a theory about everything and nothing!'), but its generality makes it compelling for some for study.
Well, that's because that's basically it, lol.
But I get your sentiment and, sure, there's a lot of things where this could be applied and that hasn't happened already. It's definitely a field with a prolific future, though. I've personally applied many ideas I got from there into my smallish ventures with good results.
But to me, the value in ACT is actually learning how "simple" some of the other fields could be, because it allows me to communicate with non-software engineers, and actually have them contribute to software.
I did a lot of work with state machines as composable abstractions for concurrency and flow control, and mechanical engineers were able to find some really subtle say, race conditions, just by pointing out "hey, isn't there an arrow from this to this, if the limit switch catches early?"
https://mathoverflow.net/questions/12511/what-is-yonedas-lem...
"Each of the steps is fairly compelling, except perhaps the second one, which rests on the Yoneda Lemma"
see "Kan Extensions for Program Optimisation"
I think it is a property of human cognition that if we draw an arrow from a to b, and one from b to c, that there is some kind of relation between a to c as well.
What this means concretely is that if I can draw my problem, in my domain, as a diagram with boxes and arrows, there is a reasonable chance that you can actually understand it, and actually contribute to it. Similarly, seeing diagrams from your problem domain is often sometimes I can relate to my design patterns and software architecture foundations, and I might be able to ask quite pointed questions when trying to say, build a mathematical model or build some supply chain software. Questions like “ok, but, is there an arrow from here to here?” and the answer “oh yes, that happens when we actually replenish the inventory by doing X, I forgot about that part”.
Another thing I found people do with CT is that they use it as a toolbox of abstractions that they can try to fit to a problem. Say, “oh, is there maybe a functor from petri nets to databases? ok, there is, but it’s kind of useless. Does this formulation actually work as a monad?” This is useful for finding elegant APIs to problems, say things like optics (lenses, etc…).
Only point of category theory starts when you go higher than that and deal with more abstract and generalizable things e.g monads(which again is used in other theories), bigger infinities, ordering of infinities etc.