This is a curse which keeps affecting large groups of programmers, to read about some pretty looking abstraction and then wanting to use it everywhere regardless if it is suitable or not. I'm thinking of Design Patterns, CQRS, complex microservice architectures etc.
This point seems to be repeated with every new mathematics.
> It's a pretty abstraction, but I don't see actual results from it.
It has applications in physics and is widely used in computation, particularly for reasoning about composition of programs with side effects. With respect, if you don't see any actual results, you haven't been looking.
With respect, if you think any category-theoretic results were necessary to author even 0.01% of the code executed in computation globally, you're willfully deluding yourself.
I will also claim that their use is only going to grow with Rust adoption and Java adopting lambdas and functional APIs.
You said "It has applications in physics and is widely used in computation". Category theory is not widely used by those who program computers and thus produce computation in them.
> I will however claim that, despite being unnecessary in principle, quite a bit more than 0.01% of code executed globally did make use of category theoretic abstractions because they are so useful (depending on how you measure this of course). Pretty much any program written for .NET and Scala makes use of monadic composition.
And like clockwork, you provide the bog-standard argument for why knowing category theory is important: you point out how many people productively write software without knowing anything about category theory (or even abstract algebra).
Saying that people use category theory to write software without knowing it is like saying they use Maxwell's Laws to write software: so reductive it loses all relevance to productive conversation. That's bad, unless your goal is to make the conversation unproductive.
Computation is bigger than just programming in industry. "Computing" has always referred to the overall discipline of computer science.
> you point out how many people productively write software without knowing anything about category theory (or even abstract algebra).
That wasn't my point at all. Read again. They can have even more productivity if they used category theoretic abstractions.
> Saying that people use category theory to write software without knowing it is like saying they use Maxwell's Laws to write software
Good thing that's not what I said either. You're making a habit of this.
People can understand a structure, in that they can grasp its semantics and its application, without knowing it's canonical name.
There's actually a bit of harm too: the abstract nonsense seems to make it harder to reason about execution speed and makes it very easy to write very slow code. I know a lot of people have a hard time being able to predict the speed with which, say, Haskell code will run.
As an example, consider the theory of Containers [0]. A container is an abtract mathematical model of some kind of data structures (such as lists, trees etc.). Like most mathematical structures they form a category. Further more, each container gives rise to a endo-functor Type → Type. In fact they form a full subcategory of such functors.
For instance the list endofunctor L : Type → Type can be seen as a generic data structure which takes a type parameter, A, and gives the type of lists of elements of A, namely L(A). The functor structure is the generic map function which to each f : A → B gives a function map f : L(A) → L(B). These kinds of generic maps are almost always natural transformations, which tells you a lot about their properties. Knowning these things makes it easier to reason about your code.
These are ofcourse very simple examples. For more elaborate applications of containers, see zippers — which involve an adjunction in the form of a differentiation structures. In layman's terms, zippers are datastructures with holes in context.[1]
[0]: http://www.cs.nott.ac.uk/~psztxa/publ/cont-tcs.pdf
[1]: This master thesis has a readable introduction: https://www.duo.uio.no/bitstream/handle/10852/10740/thesisgy...
print("hello ");
print("world")
That might seem like a small thing, but it isn't. In theory, so far as I understand, specifically in denotational semantics, the next best alternative is continuation passing, which adds an extra parameter and return value to the actions and is generally awkward.
The big advantage, though, is practically, in lazy programming languages like Haskell. In that case, the alternative was world passing, where the entire (metaphorical) universe is passed to the action to allow normal parameter passing conventions to sequentially associate the actions. (In contrast, monadic IO does the same thing, but hides the world in the definition of the monad.) The result is sequential code that we all know and love.
Then it was discovered that other bases than the (metaphorical) IO world made for meaningful, useful monads: the maybe monad aborts a computation on the first error, for example. And other data structures like lists...well, go look for a paper with a title like "turn your failures into a list of successes" and we were off and running.
[Edit]
And I'm thinking of the wrong Wadler paper. Try some of the ones from here [1], starting at the bottom.
Fundamentally, category theory is seen as some sort of holy grail of programming. The hope is that learning about only one API will let you interact naturally and composably with any interface conforming to that design.