Does category theory apply to everyday programming?

Question

Haskell

I am a Scala programmer and use monads a lot. And the practical benefits of them are understandable and enormous. Option(Maybe) eliminates problems with nulls, Either allows elegant error handling, Future makes it easy to write asynchronous code, List makes it convenient to work with lists. Etc. That is, the practical benefit is easy to understand. I have stumbled across articles on category theory many times and have read, probably dozens of them. But I never understood what practical use you can get from categories if you are not engaged in proving theorems.
Can you link to articles that simply explain this, or can you give a short example of the practical application of category theory?

Answer 1

A simple explanation of TK for programmers from Eric Meyer :
For rockers, as for "smarter", Eric interprets some examples separately :)

Answer 2

Theorems have nothing to do with it, this word from mathematical terminology is simply a synonym for the word "abstraction", and without abstraction in programming, strictly speaking, you can't even write Hello World, but there are cases where there really is a problem for which there is no ready-made solution and which cannot be solve by "total" analysis because it will take a lot of time and money, in this case the programmer has to regulate his often basic type of thinking - analysis - and apply abstraction by examining the problem at the level at which he stands.
Well, for example, the implementation of a reliable communication channel on TCP, in order to "unearth" the entire implementation of the protocol, it takes months and a lot of money, not counting the intelligence of which many people also lack, so abstraction is used, here's an example, but what will it give you if you don't have your own normal tasks (and judging by the question you don’t have them in principle), then you won’t go to implement an example of my task instead.

Answer 3

Well, the most obvious example is using ready-made abstractions from TK to integrate some code with other libraries or different libraries with each other. I write about this in a little more detail here:
appliedscala.com/blog/2016/fp-in-java8-kotlin-scala
If you need a specific example, then take, for example, the Monix library. This library, among other things, provides such a type as Task - something like Future, but "lazy". If some code works with Futures, then of course you can push Task into it, but this will require additional effort. But if this code works with the Monad type class (for example, in the edition from Cats), then there will be no problems, since you can find / write the corresponding instance for both Future and Task. Here, in fact, not pure TC is used, but a combination of category theory + type classes, but in Scala they always go together.

Answer 4

A categorical way of thinking is useful. For example, the categorical description of inheritance makes obvious the difference between virtual and non-virtual inheritance in C++.
They are also trying to use TC in systems engineering , but I can’t judge how successful it is.