Thanks for sharing this! I'm just getting my head around category theory (in Haskell).
I would appreciate if anyone knows of a small project out there that uses category theory to learn how to design and architect a solution (even better if it's in Haskell!)
As someone who used to use Haskell a lot, I will tell you that learning category theory isn't really going to improve your practical ability to architect Haskell code.
If you're simply curious about the mathematical structures that Haskell's standard typeclasses are named after, then by all means learn category theory.
But if you're trying to improve your ability to use those typeclasses to write real-world software, I recommend "Haskell From First Principles" and/or "Effective Haskell". And get your hands dirty writing actual programs - practice makes perfect.
Has anyone here ever used category theory in a business (or any purpose other than publishing papers)? (Don't give me "I used a monad once while programming", I mean the kind of stuff that book is about)
these kind of books are "philosophical" books. In the sense that the usage can be written/explained in other ways. For instance, monads are just a way to see that if you compose two ducks you still have ducks that behave in the same manner, but that's almost the same thing as having a class and define the composition arrow as a method.
The only difference is that with CAT you have theorems asserting what's true and what's not, with classes I don't think there's much literature. A similar reasoning can be applied to neural networks as there are very different POV: someone will look at them as ODE systems, other as a pure discrete dynamical system or as an optimization problem or whatnot.
That's exactly it, SelectMany is what in .NET corresponds to flatMap in e.g. Java. (And, unlike the parent, I don't like the narrow scope of .NET naming very much, focusing on just the list monad (a.k.a. IEnumerable).)
The idea of sharing structural properties/invariants between abstractions is something that is in my mind often, and reading the book intro resonates with me.
Domain Driven Design is essentially applied category theory:
You develop a language that models your domain, translate that into a diagram, and translate that diagram into code.
(Okay, actually topos theory since you’re going between type theories and diagrams — but you use the diagrams to move between type theories and define “equivalent structure”.)
