I still would vote to learn it from Milewski though. Learning this is a journey and the author of ct-illustrated is, i think, still in the middle of it.
Milewski has made that trip multiple times already. The book and his blog are great places.
https://github.com/hmemcpy/milewski-ctfp-pdf Book https://bartoszmilewski.com/2014/10/28/category-theory-for-p... Blog
I've read the first dozen chapters of Milewski so far, and while I really enjoyed the first couple chapters, his style of not giving precise definitions or statements, nor using precise notation becomes really annoying after a while and makes the book practically useless as a reference. He seems to think everything is easier to understand when it's written in lighthearted, imprecise prose.
No, not all.¹
This is why there are monad tutorials that use dozens of different analogies for monads, and nobody feels like they understand anything better after reading them. But if you use monads enough, eventually you get used to how they work and how to accomplish things with them. And then you stop caring if you "understand" them.
[1] https://en.wikipedia.org/wiki/Frog_(horse_anatomy)
[2] https://en.wikipedia.org/wiki/Frog
[3] https://en.wikipedia.org/wiki/Frog_(disambiguation)#Railroad...
The mathematical concept was in use for years before anybody decided to call it a "monad" anyway. According to Wikipedia: "The notion of monad was invented by Roger Godement in 1958 under the name 'standard construction'. Monad has been called 'dual standard construction', 'triple', 'monoid' and 'triad'. The term 'monad' is used at latest 1967, by Jean Bénabou."[1]
[0] https://en.wikipedia.org/wiki/Monadology#Summary
[1] https://en.wikipedia.org/wiki/Monad_(category_theory)#Termin...
A monad is an entity that has no purpose other than relation to itself, but can be part of a structure that employs functionality or meaning. I think the problems around this concept for most is, that causality is not a requirement yet, so things don't have to make sense to be part of constructing upon them.
An analogy in IT might be, that worrying about traversal of a graph is a problem domain in time and space and causality that involves questions around loop detection and recursion because you deal from a pov that has those constraints. But that's not a problem yet in the domain of structure as it.
This took some brain, so i hope it's a good try on explanation.
The monad is something about which you can reason but you cannot look inside because it is windowless. No quibbling, please.
That’s like saying to understand object oriented programming one just needs to study Plat’s theory of forms.
As Milewski teaches the subject, he is in a position to match both personal life, work and the topic into one book, so this is the goal, but it will entail you leaving the narrow perspective of your work. He can talk from math to math, but you have to - similar to the author of ct-illustrated - find your own way from translating your specific model into a more general one.
If you want a handle to start: Think of a line that extends into + and - infinity: It will create a circle. Even though a circle is a 2 dimensional object, it's made of infinetly many distinct 1-dimensional lines. The same is true for your work: Even though it is made out of a distinct countable number of interwoven objects in your domain, this structure is part of a bigger abstraction. Doing more work, like drawing more distinct new objects will not take you onto the more general abstraction, but thinking about what all your domain models have in common.
Try to work less, be lazy and the underlying mathematical models will appear in a language you already speak. In your case: Abstraction your work domain model into multiple clients (1 employer --> multiple employers in a similar line of work) will a) lead into your termination b) show how you can abstract your work away from 1 source of income and purpose into multiple ones.
Good luck!
I'm currently working on trees for a nested controller approach and constructing / deconstructing differing branches. So even though i don't feel stuck right now i'm always willing to take hints for taking another path.
It would seem to me that the properties of the circle are not emergent properties of a bunch of line segments; rather, the circle is something else entirely, whose shape is forced upon it by its own nature. Another example that comes to mind is the so-called "fiber bundles," whose own topology in general can be much more complex than that of a "trivial bundle" (simply the product of two spaces - the "base" and the "fiber"), although locally they all do look "trivial."
None of this, I am afraid, has much to do with what you said you are working on. In the realm of software development, the only emerging properties (or non-trivial topologies) are bugs.
As for manifolds, i am drawn to stuff like a hendecachoron and we have a new fountain in Chemnitz now called "Manifold" which is made from circles and i love it! Also the local architect of the town hall has the surname "Möbius".
So i'll take the hint to learn a bit more about topology!
https://news.ycombinator.com/item?id=28660131 (2 comments)
https://news.ycombinator.com/item?id=28660157 (112 comments)
> Because of this, mathematicians are in a weird and, I’d say, unique position of always having to defend what they do with respect to its value for other disciplines. I again stress that this is something that would be considered absurd when it comes to any other discipline.
I think this is a concept that anyone who studied anything that does not directly lead to monetizable outcomes can relate to, but it's nice to hear even those whose gifts skew to the numeric also have to contend with "Milton Friedman's Razor".
The contribution of category theoretic language to the implicit framework of a theory can't be larger than the definition of a category, which is very small. You could be asking "why use groups when sets with an associative operation exhibiting closure, an identity and an inverse are more approachable?" Abstract algebra is based on a library of definitions that refer to types of operations on sets that are simple enough to be common. A tool or a technique are not the kind of things you can find in a definition.
Rings, vector spaces and modules get a sort of instant acceptance for what they are, but categories have believers and disbelievers. I am curious about how that can happen.
That is the point here.
> CT is applied to many domains.
Yes, but in which of those does it massively help? I just looked up ZX calculus, and I am sure you can formulate that better by not mentioning CT at all.
Based on what? Sorry, but what you're saying is beyond arrogant (considering you have zero knowledge of the subject).
More on the topological data analysis:
CT is a language and a tool, meaning anything you can say in the language of CT you can say in other languages.
Like cars, if you learn how to drive it (and this one has a very steep learning curve), it gets you places faster, but you there's in principle nothing stopping you from going there walking, i.e. without specifically referring to any CT concepts.
Another practical utility of category theory is providing a common language for computer scientists, mathematicians and physicists to speak. You can imagine collaboration is not easy when everyone calls the same pattern with different names with slightly incompatible definitions that requires you to understand unfamiliar theories.
The cat theory framework is too high level to usefully exchange ideas between these fields. The consensus in academia seems to be that it is a nice "party trick" framework that has very limited insights or expressiveness in actual physics/CS problems.
It's a bit like working in a framework that has great primitives for the stuff you do a lot. Like think dependency injection for constructing instances. Saves you tons of coding time in the long run.
Of course, this point of view is probably hard to appreciate from outside the priesthood =P.
There is a category theory "school of thought" in certain subjects, but it's usually a speculative belief in the importance of category theory.
One tool for one job is a simple rule you can adapt as a systems architect allowing you to build clear structure for the problem domain you come across. esbuild comes to mind as an example - the job was solved before, but keeping one purpose in mind and writing it from scratch solves the problem WAAAY faster.
So no, no problem is solved inside the domain of product software development, but outside of it, you as a developer can (if you want and for speed) derive any structure from the absurd function instead of combining foreign frameworks.
No, this is exactly what CT is not about. (It is about morphisms.)
And he is right, because morphisms may or may not preserve structure. If you want to nitpick and create structure from the absurd function morphism - then yeah, so I think a discussion about this gets tedious. The more you look into the matter the more structure / data and morphisms merge and your point feels more like an invitation for the newbies to have a mental breakdown.
We could say the same about computers in general.
Admittedly even with a less stringent criteria I don’t have any examples. So I understand your point
CT is outside most problem domains in computation, as its outside the time and space constraints of a machine. Knowing whether a program will never finish is part of CT for software developers. So handling this case is a maybe in CT while it's a must in software (running endlessly means crashing).
There has been seen some research into the fundamentals of machine learning, using category theory approaches for computing the compositions of transformations of expressions. E.g.: simultaneously computing a gradient, the "bounding box" of the error, and other similar derivatives to improve the robustness of gradient descent.
Any computing problem that could be solved with category could be solved by brainfuck.
so the way people use “abstraction” sounds more like they are saying “a thing we (we think) are not used to”
I suspect it's hard if you don't really need it for anything. Do you really need to understand universal properties and adjoint functors and the Yoneda lemma? If you don't, you'll struggle to learn what those are.
Interestingly, experience in functional programming can help you understand category theory, but not so much the other way round. For instance: Parametric polymorphism gives you intuition for natural transformations. And natural transformations are central to every application of category theory.
The convincing applications of category theory are very mathematical. You'll find them in algebraic topology, representation theory, algebraic geometry, and non-classical logic.
I think a convincing application of category theory should involve doing calculations with category theory concepts and definitions, which involve things like: commutative diagrams, representable functors, universal properties, adjoint functors. If a whole heap of these concepts doesn't get used - and you don't perform calculations with them - then you're just reformulating something using different terminology.
Thanks anyway for the link. Very pretty.
But!! I'm not seeing ANY of that in ZX.
There is a category theory "school of thought" in many subjects, which believes without solid evidence that category theory must be immensely useful to their subject. But it's often just that: a school of thought. This is the situation of category theory in CS. My concern is that people aren't being honest about this.
> Modus ponens is a proposition that is composed of two other propositions (which here we denote A and B) and it states that if proposition A is true and also if proposition (A --> B) is true (that is if A implies B), then B is true as well. For example, if we know that “Socrates is a human” and that “humans are mortal” (or “being human implies being mortal”), we also know that “Socrates is mortal.”
This example is not an instance of Modus ponens (a rule of propositional logic), it is rather a categorical syllogism, which require predicate logic.