Comment by lkuty | Hacker News Reader

Comment by lkuty | Hacker News Reader

I would complement it with:

- Scott Wlaschin's Railway Oriented Programming (ROP): https://fsharpforfunandprofit.com/rop/ and https://fsharpforfunandprofit.com/posts/recipe-part2/

- Scott Wlaschin's The "Map and Bind and Apply, Oh my!" series at https://fsharpforfunandprofit.com/series/map-and-bind-and-ap... and its concept of an "elevated world".

- And for Elixir Programmers, Zohaib Rauf's "Railway Oriented Programming in Elixir" at https://zohaib.me/railway-programming-pattern-in-elixir/ based on Scott Wlaschin stuff.

- https://wiki.haskell.org/All_About_Monads. The introductory part (7 first pages of the pdf).

- Brian Beckman: Don't fear the Monad https://www.youtube.com/watch?v=ZhuHCtR3xq8

- Philip Wadler's "Monads for Functional Programming" at http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/ba...

- HN comment: https://news.ycombinator.com/item?id=16446139

ROP is a good way to introduce the Either monad without ever talking about monads, functors and co. Moreover it is highly useful.

My takeaway from all this is that monads are kinda hard to explain. If something is hard to explain, that further suggests to me that it's probably the wrong abstraction.

(Personally I find the railway abstraction makes a lot of sense, but maybe that's just me.)

There is an element of truth to this, but they are easier to use than explain.

Part of the hardness comes from people wanting to use monads as an entry point to category theory.

People get hung up on the terminology, but I’ve found if you don’t use the words functor and monad and just focus on the actual use case, second year college students learning functional programming for the first time can grok this concept.

The way I have found success is to have them write a program first where a monad would be useful, and then ask them to implement it without monads. They will identify the need for a monad themselves, and then you can show them the tool they want. Then they use it to solve the problem, and at that point you start giving them a more rigorous theory.

This is roughly Socratic programming teaching! It's for this reason that I think one of the better monad explanations is this one:

http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...

Monads are simple enough to explain them in a single blog post; the problem is, nobody can agree on which blog post.

I assume I'm displaying my ignorance, but it feels almost tautological to me.

Oh, well, being easy to explain is a feature. Monads lack this one (so do pointers, mutable variables, recursive functions, macros., Boolean logic, Boolean values, metadata..)

Still, that's far from the most important feature for anything you will use daily.

I disagree that anything on your "so do" list is hard to explain. At least, I feel like I understand all of them, but I still don't understand Monads. And I've probably spent 10x the amount of time reading (and still not comprehending) Monad tutorials than I have all of the other concepts combined.

Have you tried to explain them to somebody learning to program?

Explaining things to people that already knows them is always easy.

Yes I have, I helped teach some CS courses in college, plus I myself learned them in my very earliest days of programming. It's pretty common for those to be among the first concepts taught.

I'd say that your list is full of things that have practical examples when you consider how real, physical computers work. Boolean logic can be shown by example by showing physical transistor circuits, and I'd argue that people can understand them quite easily. Pointers/variables can be shown by explaining how memory addressing works on real machines, and what CPU instructions correspond with the actual code you're writing.

Monads however, seem to be this purely abstract mathematical concept that comes from CS-as-a-math-discipline, which although useful, requires you understand ton more theoretical background before you can approach it. At least that's my experience -- I still don't understand them and every tutorial I've read either makes them look like magic (ie. doesn't actually explain them) or tries to take a mathematically rigorous approach and I get lost in the weeds.

I know intuitiveness is very subjective, but I'd wager that by numbers, many more people are able to understand pointers/mutable variables/macros/boolean logic/etc more easily than they can Monads.

You don’t need much of any theoretical mathematical knowledge to understand monads. What you need is comfort and experience reading mathematical definitions. For most people, that means they’ve studied a lot of math. The famous John von Neumann quote is bang on here:

Young man, in mathematics you don't understand things. You just get used to them.

—- John von Neumann

I agree. Almost all of the difficulty is just not getting how mathematicians think or communicate.

Honestly I think a lot of effort is wasted starting with this stuff rather than more motivated examples... But the interest is the harder thing to come by, so at least they're learning something.

I don’t mean to stir the pot here, but that’s a pretty unhelpful comment.

You could basically rephrase it as “you don’t need a lot of math, you just need a lot of math”.

> Monads however, seem to be this purely abstract mathematical concept that comes from CS-as-a-math-discipline

Well, if they were, all those people wouldn't be trying to understand them.

They are applied on Haskell (and Javascript, Rust, C#... but they are way more visible on Haskell). Write some Haskell and you will get them.

What would be my motivation for learning Haskell other than learning monads? Learning an entire programming language (one that expressly states practicality as one of its non-goals and ostensibly only exists to advance type theory) just to that I can learn a concept that only appears useful in that language, seems like a waste of my limited time.

It's "write some Haskell", not "learn Haskell". It's much harder to learn Haskell than understanding monads, you just need to see how some look like on practice.

But, well, I don't have any reason for you to do that. You just asked how, and I gave you a way. If you don't have any interest in learning it, there's absolutely no problem, but posting "I never really tried, but that thing is bad because I haven't learned it already" FUD is pretty bad.

My contention is that people are learning monads because they’re on a journey to learn Haskell, then when they finally grok them, they turn around and say they’re this big important thing that all programmers should understand, because Haskell showed them how important they are.

But so far, no monad tutorial has made a good case for why they’re actually useful, other than for learning Haskell. And most advice for how to learn them sounds exactly like what you said: “oh if you still don’t get it, you just need to write more Haskell.” You can see why that’s a bit of a disappointment, right?

Basically, you have people making this argument:

    - monads are important outside of Haskell
    - to understand why, you have to learn them
    - to learn them, you should write Haskell

Which I’m sure you can understand comes off as a bit unconvincing.

Oh, ok. If you want to design a language nowadays, knowing monads (and other abstractions) is absolutely necessary, even if just to reject them in an informed fashion.

If you want to use a language to program, knowing them will help you with approximately nothing, because most languages either have awful ergonomics for that kind of abstraction or bring them on much more limited ways that you are better learning how they specifically apply to the language than the general concept. If you learn the general concept, the specific cases will be easier, but unless you plan on learning several languages, it's not worth it.

Anyway, one large exception is if you plan on doing heavily abstract C# libraries. The C# support for monads is almost as general as Haskell.

My advice: Try these two tutorials:

http://www.jerf.org/iri/post/2958

https://philipnilsson.github.io/Badness10k/escaping-hell-wit...

The first one I think cuts through all of the crap surrounding them. They're just a design pattern. And the second one helps motivate them, showing the many contexts where the design pattern many apply.

If you're still confused after having gone through these, and want to understand, shoot me a message (email in bio) and we can hash it out.

I'm curious how much time you're spent "doing monads" compared to reading about monads. The reason that I bring this up is that monads didn't click for me until I had hands on experience with a few different monad instances and could see the abstraction take shape in different ways. If that doesn't apply to you, that's ok too. It's fun to understand other people's methods of conceptualization.

I have no idea how much time I’ve spent doing monads because I still don’t know what they are. It’s possible I’ve done “monadic” things in the code I already write, but I have no idea.

I don’t know any Haskell at all, and it seems to be the only language out there where people think monads are a thing you need to learn, so I definitely have no motivation to learn them outside of curiosity.

But I am curious about them, enough to read every tutorial I come across about them. But I still have no idea what they are.

It's definitely possible you've already done monadic things in code. If it's any consolation, I would not have ever been able to grasp monads by reading tutorials alone and the monad laws are simply too abstract for me to have envision a concrete usage. I learned without touching Haskell at all and it's my opinion is that Scala + Cats is a much easier onramp to monads than Haskell.

You sound like a kind and curious person. If you ever want a one-on-one walkthrough please reach out to me (email in bio). Everyone deserves the chance to understand something if they want to.

> so do pointers, mutable variables, recursive functions, macros., Boolean logic, Boolean values

I disagree -- these all seem pretty easy to explain to me.

Monads are very easy to explain to anyone used to reading mathematical definitions. It’s the people without a math background that struggle so much. They insist on all of these real world analogies. The problem with that stipulation is that monads are too abstract and general to have a real world analogue.

They are a fantastic and incredibly powerful abstraction though. Their mathematical properties, termed the monad laws, make sure of that.

You can also explain them as interfaces, although as you said it gets harder when you get to the "why".

I have a strong mathematical background, I get the definitions, I understand very well the typical examples like the IO monad, yet I frequently have a hard time following more complex monad use examples. Especially transformers. So, I suppose it is not enough to understand the definitions, you really need to think of them as some form of a language.

I think that’s the case with any concept in computer science or math. It’s easy enough to explain integration to someone using simple examples like f(x) = x^2 but it gets a lot more difficult when you introduce Stokes’s theorem and differential forms.

Most of the people complaining about monads are not in your situation. They are struggling to grasp even the most basic examples because they understand concepts only by analogy to other things they already know and monads don’t map to anything they know.

> It’s the people without a math background that struggle so much.

You mean like most programmers?

Quoted from Bartosz Milewski's 'Category Theory for Programmers chapter 20:

Let me set the record straight: The whole mysticism around the monad is the result of a misunderstanding. The monad is a very simple concept. It’s the diversity of applications of the monad that causes the confusion. As part of research for this post I looked up duct tape (a.k.a., duck tape) and its applications. Here’s a little sample of things that you can do with it:

- sealing ducts

- fixing CO2 scrubbers on board Apollo 13

- wart treatment

- fixing Apple’s iPhone 4 dropped call issue

- making a prom dress

- building a suspension bridge

Now imagine that you didn’t know what duct tape was and you were trying to figure it out based on this list. Good luck! So I’d like to add one more item to the collection of “the monad is like…” clichés: The monad is like duct tape. Its applications are widely diverse, but its principle is very simple: it glues things together. More precisely, it composes things.

===

Also would like to recommand: Functors and Monads For People Who Have Read Too Many "Tutorials" http://www.jerf.org/iri/post/2958

I got a feeling that Monad has no good metaphor to real life objects. Trying to make up an analogy just makes things worse.

When I realised that everything following a couple of simple laws was a monad, I started to notice them alot and was also able to implement them. The tutorials with pictures or analogies like containers only made me confused.

Quantum mechanics is a bit hard to explain, but it turns out to be quite a good model of our physical observations.

Monads are hard to explain, they are _not_ hard to use, and use with great effect. Option#{map, flatMap} changed how I approached programming, and did not require a full understanding of why they existed or what they were a part of.

Reply on news.ycombinator.com