If I may ask, why is the HN community so interested in this particular topic?
I studied Math and have basic understanding of Category Theory... could someone point me to a text relating Categories and... something related to computers? What am I missing?
Yeah, I also have a mathematics degree and don't really get the fascination that computer people have with category theory. I have never been particularly impressed with their claims of applicability. It seems to just complicate things for very little benefit. It's a pretty abstraction, but I don't see actual results from it. People use ugly, practical things like git, not beautiful categorical abstractions like pijul.
> Yeah, I also have a mathematics degree and don't really get the fascination that computer people have with category theory.
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 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.
Good thing I never made that claim. 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.
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.
> It seems to just complicate things for very little benefit. It's a pretty abstraction, but I don't see actual results from it.
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.
Yes. I don't think knowing about category theory makes you more proficient in using or designing functional languages either. Lambda calculus has much more obvious utility. Even things similar to monads can be described more simply without abstract nonsense: state is just another variable that you are passing along in your functions. The best books on Haskell do not dwell on category theory.
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.
Category Theory organizes mathematical concepts, and a lot of the concepts there are applicable to Computer Science.
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]
I really enjoyed learning about the so-called "combinatorial species" [1]. It is another good example of what you are describing. And this idea of differentiation as putting a hole, it just blows my mind every time i think about it.
The short answer is category theoretic monads. Once upon a time, Eugenio Moggi realized that monads could be used as the formal basis for assembling sequential actions. For example, when you write
print("hello ");
print("world")
you expect the output to be "hello world" and not "worldhello " or something weirder. Moggi realized that the semicolon there was a monadic operation that arranged for the two outputs to be printed sequentially.
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.
CT concepts and relations between them are used to design (or have influenced) libraries/APIs and even some language features in several programming language communities, especially those using a 'functional' paradigm. Take a look at Haskell, Idris, Scala (with the scalaz library or whichever took over its place today),...
The big application I'm aware of is structured recursion schemes: http://maartenfokkinga.github.io/utwente/mmf91m.pdf ( implemented in Haskell by the recursion-schemes library ). Used carefully they allow a very lightweight/concise way of expressing transformations of tree-like structures, which is the essence of compilers (and of a lot of other programming, particularly when you start working in DSLs and regarding everything as a compiler).
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.
