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.¹
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!
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.
That’s like saying to understand object oriented programming one just needs to study Plat’s theory of forms.
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.
> Is this taken word by word from wikipedia?
You're either very naive or explaining yourself very poorly.
The monad is something about which you can reason but you cannot look inside because it is windowless. No quibbling, please.
[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...