I work at Target and we have a weekly class on algebra, category theory and Haskell because people are interested. It's a mix of programmers learning some of the math and mathematicians learning some of the programming :).

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

Wow, Target sounds like it has a nerdier crowd than Facebook.

This is the most unexpected thing I've ever heard about Target.

That sounds awesome!

Is Haskell (or other fp languages) commonly used at Target?

I don't work there, but my understanding is their supply chain automation/optimization uses Haskell.

Is this at the HQ in Minneapolis? I hope to move back to MN someday (to raise the younglings) and you make Target sound awesome!

Currently we're a small team mostly based in Sunnyvale, but we're also partly distributed and have some people in Minneapolis. This has been a bit awkward for the class specifically because teaching people over Hangouts turns out to be hard, but there is certainly some cool work going on in Minneapolis.

As someone in the Twin Cities, BAH, I was hoping to find more haskellers around. Oh well, I'll keep trying to get more FP stuff in where I work at least.

Nah, it's in the south bay. I've been to some meetups there.

The last of the astronauts stared back at a tiny spec in the sky, their old planet, J2EE.

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.

I'd be surprised if there are more than a handful, but I often wonder the same thing about posts about systems programming and, well, basically anything that mentions Rust in the title.

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.

I see. I'm coming from the other side. I do microcontroller and embedded development.

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.

It's worth mentioning that I come to HN explicitly searching for a mix of interesting reading in my field(s) and Ancient Greek. I think it's super important for me as a mathematician working in technology to try and understand what clever people in other fields find interesting and important. I don't understand it in any sort of depth, and I don't expect myself to. I would imagine that a lot of folks from "your side" probably have a similar attitude to mathematics.

I'd be more interested to know whether there's a practical use of understanding it on this level. I wanted to learn about monads and wrote some smaller Java examples using streams and flatmap. You can see the benefit and understand how it's implemented very easily. However, the academic explanations and notations were not helpful and I'd argue made understanding the concept needlessly complicated.

I'm slowly developing a systematic framework for programming the human brain with foundations in category theory. I've gotten a lot of useful mileage out of what little I've learned about category theory. It contributes to my intuition about how to reprogram my brain. I'm convinced we'll be teaching it to children in the future, once the programming framework is better developed and understood.

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.

I'm curious to hear of a few examples of how you're doing that.

Would you mind sharing?

I gave some examples in my comment at the bottom of this thread. If you're asking for specific ways I'm using CT in the context, it's mostly as a way to model my experiences and find bits of insight here & there, so specifics are a little hard to come by.

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?

I really find it difficult as well, and I think it is a lot to do with the nomenclature that surrounds the field. Sometimes I feel it's almost kept obtuse on purpose.

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...

THANKS! This is great. I watched the first 3 videos in the series and will finish the rest this week. I love his energy and his ability to explain this stuff.

I only know this famous quote:

http://stackoverflow.com/questions/3870088/a-monad-is-just-a...

But I didn't really try to understand it.

It's hard to understand because it's utterly unenlightening. It's a restatement of the definition. It's like saying "the number two is just the sum of one and one." It's trivially true yet utterly fails as an explanation because it requires more concepts to convey the exact same content.

I would argue the concepts of monoid objects and the category of endofunctors on an object are simpler than that of monads, so this description does help. I come from a math background and had never seen this quote before, and I think it has given me a definition of (mathematical) monads that I can remember.

Haskell, unfortunately, is still quite opaque to me.

I guess I'll raise my hand by commenting.

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.

No, but those who feel like computer scientists rather than programmers do aspire to.

It's very hard to make use of any of it, I don't get it either. It's not like you need to understand monads (the category theory idea) to use monads (the PL idea) in, say, Haskell.

I love pure programming. But the thing that makes me hesitant to try to learn something like Haskell is that it feels like I need a math degree to understand the concepts and terms. For a while I thought I was just not that smart. But I realise that all these things are just kind of really complicated.

Learning Haskell, if you just want to hack and build a program, is not really complicated and you don't need a math degree or to be particularly smart. You just need to understand it won't be like writing other languages you learned before. That doesn't make it more difficult, just different.

Good to know. I think I get too into my head when reading about it all. Monads? Monoids? Functors? Oh my!

Edit: thank you all for your wonderfully encouraging and useful responses. I know what I'm playing with tonight!!!

It's common.

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.

I know the current consensus seems to have moved away from this recommendation [1], but have you tried reading the (free online!) book "Learn You a Haskell for Great Good" (http://learnyouahaskell.com/)? It provides an easy to understand and uncomplicated introduction to monads, monoids, functors, and everything you find scary about Haskell. You won't be able to write full-fledged programs with it, but you won't be scared of these concepts anymore.

[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've found Professor Frisby's Mostly Adequate Guide to Functional Programming to be the best on ramp. He builds up the concepts carefully till you are using applicative functors and it's always very practical and applied.

I will probably now re-read Learn You a Haskell and actually write some Haskell.

[1] https://drboolean.gitbooks.io/mostly-adequate-guide/content/

I cannot agree more. This book is awesome!

Philip Wadler published this paper[1] titled 'Monads for functional programming' that serves as a good introduction on the subject and is very accessible. It is enumerated through with concrete examples such as 'error handling' using Monads and maintaining 'state' via the State Monad.

[1]: http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/ba...

Just a note, this post has nothing to do with Haskell.

It's specialized but also very general (abstract) without contradiction. I'm finding NLP applications of monadic parsing as in "Monads for natural language semantics" by Chen though still theorical afaik. They thrive to enrich compositionality starting from programming language denotational semantics resulting from a version of a recursive descent parser obtained by monadic parsing as studied by Wadler.

Persevere, it will make sense eventually. But then again when can one say to really understand things.