Are there really that many people on NH that can understand this?
I'm not trying to be snarky, I'm legitimately interested. It seems like this class of knowledge is highly specialized, yet I see posts like these high up on NH frequently.
I'm not trying to be snarky, I'm legitimately interested. It seems like this class of knowledge is highly specialized, yet I see posts like these high up on NH frequently.
It's actually a lot more accessible than it seems at first—these ideas are not complex, just abstract. Thinking at a high level of abstraction is very much a skill which requires specific training, but it's a skill worth training and, when you have it, learning things like this becomes much easier.
The same thing is true of programming, by the way: once you start "thinking like a programmer", it becomes much easier to learn a new programming language or to understand some low-level programming concepts. And thinking like a programmer is, in the grand scale of things, not that different from thinking like a mathematician!
I work at Target and we have a weekly class on algebra, category theory and Haskell because people are interested
Is Haskell (or other fp languages) commonly used at Target?
It was once a teeming garden world, but after replacing every species several times, the increasingly abstract creatures failed to thrive. Many wars were faught, poisoning the planet itself with leaky abstractions and broken factories.
They knew many years ago, the planet was dying. The most enterprisey scientists of the world gathered in secret to build a colony ship, free from abstraction. A chance to start over and build a more functional place.
And now on this new planet, they cast off the old ways of objects and threads, embracing monads and async promises for a better future. This time, the scientists reasoned, it would be better. And so they replaced their first species, the monoid.
For my own part, I find this kind of post fairly easy to digest, but that's almost certainly because I'm a Mathematician by training (PhD in numerical differential geometry, but did a lot of abstract algebra as an undergraduate). To me, a lot of the programming-related topics on HN seem to be written in some form of Ancient Greek, but they seem to be pretty popular and attract a lot of comments.
I think we have to simply assume that there are minorities of niche experts on HN, and that these minorities are large enough for such posts to do well.
This post is basically Ancient Greek to me, as you put it.
I think I largely became curious since "these types of posts" tend to be highly ranked with relatively few comments, yet they still show up frequently.
I'm also surrounded by a large number of varying types of programmers and engineers, and I get to hear evangelizing and discussion of a wide array of technologies, but pure math type stuff like this never comes up. So combined that with the aforementioned observation and I become increasingly curious how these posts do well.
What could be more practical than self-improvement?
I'll answer my own question: learning how to apply the same kinds of reasoning to improve how people interact.
Would you mind sharing?
Heh...and as I typed that, I came by some:
The concept of opposite categories is surprisingly useful & gives me comfort when worrying about messing with my mind. If my brain is simply one big personalized category, then anything it can learn can be unlearned.
The concept CT constructions have duals is also really helpful. One thing it suggests to me is anything learned accidentally (and/or temporarily) can be learned intentionally. A specific way this works: synesthesia (cross-wiring of senses, eg. seeing colors in response to hearing music) occurring accidentally, synesthesia temporarily occurring from drugs, and intentionally learning synesthesia. Dualism is a predictive tool in this case.
A way dualism helps me explain some things I've experienced is it suggests mental mechanisms (such as the creation of very different identities beyond the core identity) can fire in functional & dysfunctional ways. I accidentally spawned second & third identities, one of whom is female. It happened through a joyful process, though, and not trauma. The dissociation used is fairly superficial and the goal of creating more is as a continuous process of integrating all of them into a core identity. CT also helps me think about our relationships & how I'm growing through them.
One last example would be the law of composition in CT: if there exists A->B (an arrow from A to B) and B->C, then there exists A->C. Specifically, there exists a way to get from one mental state A to mental state Z that goes through B->...->Y and by experiencing that path, we can learn to shorten it til we can go straight from A to Z. I went through a bit of a path to accidentally create the second identity. The third one was a bit more intentional & took less time to pull off.
If that doesn't answer your question, would you be willing to ask a more specific question in terms of what you'd like to hear examples of?
The way I think about is to think of it is if "Design Patterns" helped show how to "engineer" software at the medium scale, category theory is a tool for helping us learn how to compose systems, and not just software.
I wish it were a little more approachable, but it seems like we are getting there.
There are people like Bartosz out there who really want to make it second nature.
https://bartoszmilewski.com/2014/11/04/category-the-essence-...
I mean just think, it wasn't that long ago nobody knew what the heck a lambda was ;)
We'll get there...
http://stackoverflow.com/questions/3870088/a-monad-is-just-a...
But I didn't really try to understand it.
Haskell, unfortunately, is still quite opaque to me.
This stuff is a certain brand of abstract algebra. Abstract algebra is generally of a certain degree of usefulness to a programmer in that there's a similarity in discipline. Moreover, linear algebra can be very useful to many programers who do things related to applied mathematics---nearly all of it touches linear algebra. Linear algebra is a specific form of abstract algebra and this blog takes a particularly "abstract" approach to linear algebra.
The particular tools being used here are of a category theoretic flavor. Category theory is a sibling to abstract algebra especially popular in certain fields (topology, algebraic geometry, foundations and logic). It's furthermore pretty popular in the Haskell-like FP crowd since Haskell is a rich place for exploring very high-order abstraction and category theory helps provide some language for talking at very high abstraction. For that reason, a lot of Haskell hackers have some amount of experience with category theory.
Finally, hackers with any kind of pure math background have a decent chance at having been exposed to this stuff. Even if they weren't, there's a good chance they could read it with some fluency. Math is a lot like programming where once you get your water legs you have a significantly improved time digesting related subjects even without direct prior experience.
For myself I have a bit of a math background, was drawn to Haskell for that reason, discovered category theory via Haskell, then swung full circle and read about it as a branch of pure math to learn more about foundations and logic.
Edit: thank you all for your wonderfully encouraging and useful responses. I know what I'm playing with tonight!!!
It's often thought that in order to program Haskell one must understand or use Monads since they are so often mentioned. That's often a mental hurdle for those interested in the language.
Two things to keep in mind here are:
-in the book "An introduction to functional programming systems using Haskell" by A. Davie (1992), Monads (or Functors or Monoids) aren't mentioned at all. That's because they hadn't been architected yet. Monads are not an inherent part of Haskell without which you can't learn or use the language.
-Monads are ordinary data types, even if syntactic sugar is provided. They are not a core aspect of the language.
An explanation I found most useful is http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...
One can just start programming Haskell and ignore Monads if one wants. At some point you will design them or something much like them yourself, making their understanding an "Aha!" moment.
[1] The problem with "easy to understand" is that it sometimes leads to oversimplified or wrong intuitions, but to be honest I found the book a nice -- if not immediately useful -- introduction to Haskell.
I will probably now re-read Learn You a Haskell and actually write some Haskell.
[1] https://drboolean.gitbooks.io/mostly-adequate-guide/content/
[1]: http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/ba...