Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monads as a Programming Pattern

samgrayson.me

Post reply on HN
Print view View original

41–50 of 84 posts

Re: Monads as a Programming Pattern

#41

Post by Sharlin »

pjc50 wrote: post #30

I think monads highlight something underappreciated about programming, which is that different people regard very different things as "intuitive". It almost seems that modalities of thinking about programming are bigger, external things than programming itself. Certainly they're barriers to learning. Like Lisp, there seems to be about 10% of the programmer population who think "ah this is obviously the clearest way t…

There is a saying that the difference between poetry and math is that poetry is about giving different names to the same thing, and math is about giving the same name to different things.

Grokking monads really requires the adoption of the mathematical mindset of finding commonalities in things that at a first glance appear completely different. Tell an average OO programmer that lists, exceptions, dependency injection, and asynchronous execution all share a common structure, and they will probably give you a blank stare.

Of course, just the fact that abstracting over those things is possible doesn’t mean it is useful. In a pure FP language it might be necessary, but why should I bother with weird mathy things in my imperative language that has side effects and global state? You really have to start by explaining why composability is such a nice thing to have, and that gives the motivation for various FP patterns that are, fundamentally, all about composability.

Re: Monads as a Programming Pattern

#42

Post by tsss »

Sharlin wrote: post #41
pjc50 wrote: post #30

I think monads highlight something underappreciated about programming, which is that different people regard very different things as "intuitive". It almost seems that modalities of thinking about programming are bigger, external things than programming itself. Certainly they're barriers to learning. Like Lisp, there seems to be about 10% of the programmer population who think "ah this is obviously the clearest way t…

There is a saying that the difference between poetry and math is that poetry is about giving different names to the same thing, and math is about giving the same name to different things. Grokking monads really requires the adoption of the mathematical mindset of finding commonalities in things that at a first glance appear completely different. Tell an average OO programmer that lists, exceptions, dependency injecti…

Because in your imperative language monads can still be a useful abstraction. For example they can give you stuff like async-await or null-safe method chaining for free.

Re: Monads as a Programming Pattern

#43

Post by dkarl »

pjc50 wrote: post #30

I think monads highlight something underappreciated about programming, which is that different people regard very different things as "intuitive". It almost seems that modalities of thinking about programming are bigger, external things than programming itself. Certainly they're barriers to learning. Like Lisp, there seems to be about 10% of the programmer population who think "ah this is obviously the clearest way t…

John von Neumann famously said that in mathematics you don't understand things, you just get used to them. I think monads are an example of this, and all the attempts to make them intuitive before you use them are a huge waste of time. Many mathematical concepts are like this. Take compactness. At first, the definition of compactness seems a little random, but it's useful for proving things, so you keep using it, and after you do enough proofs you develop an intuition for it. It feels very clear and fundamental instead of random.

Once you have this feeling of obviousness, how do you transmit it to the next person? Many things can be explained, but in math it was figured out long ago that at any given time there are many things we don't know how to explain, and aren't sure we ever will be able to explain in a way that transmits understanding faster than experience can instill it. The best thing you can do for someone is give them the definitions and some problems to work on. We can't rule out that someone may eventually come up with a brilliant explanation that provides a shortcut to understanding, but we know from experience that some things persistently defy our efforts to explain them. If hundreds of people's earnest attempts to explain something have failed, then perhaps teachers should keep trying, but learners should not waste their time with these experiments; they should skip the explanations and seek active engagement with the idea through problem solving.

That's how I feel about monads. I can't absolutely rule out the possibility that someday an effective way to explain them will be found, but I think we can agree at this point that there is ample evidence that people who want to understand monads should not waste their time waiting for the right analogy to be blogged and posted on HN. They should just start programming, and soon enough they too will feel like a great explanation is on the tip of their tongue.

Re: Monads as a Programming Pattern

#44

Post by Quekid5 »

stcredzero wrote: post #39
pjc50 wrote: post #30

I think monads highlight something underappreciated about programming, which is that different people regard very different things as "intuitive". It almost seems that modalities of thinking about programming are bigger, external things than programming itself. Certainly they're barriers to learning. Like Lisp, there seems to be about 10% of the programmer population who think "ah this is obviously the clearest way t…

How do you deal with state in a language that would prefer to be stateless? Encapsulation? No one gets direct access to the state. Instead, there are methods or functions for dealing with the state indirectly, crafted to protect those outside. Answer: wrap the entire external universe and all its messy state up into an object, then pass that down a chain of functions which can return "universe, but with some bytes wr…

The person you're replying to is talking about handling mutable state in a "stateless" way. That's a big distinction.

Re: Monads as a Programming Pattern

#45

Post by Sharlin »

tsss wrote: post #42
Sharlin wrote: post #41

Earlier quoted context omitted.

There is a saying that the difference between poetry and math is that poetry is about giving different names to the same thing, and math is about giving the same name to different things. Grokking monads really requires the adoption of the mathematical mindset of finding commonalities in things that at a first glance appear completely different. Tell an average OO programmer that lists, exceptions, dependency injecti…

Because in your imperative language monads can still be a useful abstraction. For example they can give you stuff like async-await or null-safe method chaining for free.

Which is exactly my point about composability.

Re: Monads as a Programming Pattern

#46

Post by stcredzero »

Quekid5 wrote: post #44
stcredzero wrote: post #39

Earlier quoted context omitted.

How do you deal with state in a language that would prefer to be stateless? Encapsulation? No one gets direct access to the state. Instead, there are methods or functions for dealing with the state indirectly, crafted to protect those outside. Answer: wrap the entire external universe and all its messy state up into an object, then pass that down a chain of functions which can return "universe, but with some bytes wr…

The person you're replying to is talking about handling mutable state in a "stateless" way. That's a big distinction.

The person you're replying to is talking about handling mutable state in a "stateless" way. That's a big distinction.

How so? Why is it such a big distinction? Why isn't that just encapsulation? "Handling mutable state in a 'stateless' way" is basically just Smalltalk style Object Oriented programming. (As opposed to Java or C++, which has some differences.)

Re: Monads as a Programming Pattern

#47

Post by malinens »

noelwelsh wrote: post #13
mbrock wrote: post #6

I think for newbies there are two separate aspects to explain: first an intro to algebraic structures perhaps using groups as an example, then monads in particular. It’s important to emphasize that algebraic structures are abstractions or “interfaces” that let you reason with a small set of axioms, like proving stuff about all groups and writing functions polymorphic for all monads. With monads in particular I think…

You really don't need to introduce groups or other algebraic structures to understand monads, and if your goal is to teach monads I believe it is harmful to do this. The average programmer is much more likely to encounter monads (e.g. error handling, promises), than they are to encounter groups in an abstract context. Unnecessary maths will drive people away. Making a big deal of axioms, reasoning, and all this stuff…

Until functional people stop speak so elitist ("me" vs average programmer), people will be driven away from these concepts

Re: Monads as a Programming Pattern

#48

Post by aeorgnoieang »

rkido wrote: post #25
zug_zug wrote: post #24

I guess I don't get all this "monad" stuff. This article talks about 3 types of monad. An optional, a list, and a future. However an optional is really just a list constrained to size 0 or 1. And a future is often called "not truly a monad." So I question the value of explaining this abstraction in great detail over so many articles when people struggle to come up with more than 1 concrete example of it (Lists), an e…

> However an optional is really just a list constrained to size 0 or 1. What?

The sentence you quoted would make more sense if you interpret "is really just" like a mathematician, i.e. they're 'equivalent' in the sense that you can 'map' everything important about either in both directions.

More concretely, "an optional" is something that either 'has a value' or 'does NOT have a value'. So it "is really just a list constrained to size 0 or 1" in the sense that an optional that 'does NOT have a value' is equivalent to a list of size 0, i.e. a list with no contents/members, and an optional that DOES 'have a value' is equivalent to a list of size 1, i.e. it's 'value' is the single/unique member of the list.

Think of statements like 'is really just' in the sense that an integer between 0 and 255 'is really just' 8 ordered bits – they're 'equivalent' in the sense that you can map all possible values of those integers to all possible values of 8 ordered bits, and vice versa, and (importantly in a mathematical sense) in a way such that every integer is mapped to a single set of 8 ordered bit values and every set of 8 ordered bit values is mapped to a single integer. In mathematics that's often described as an 'isomorphism' which is, in working programmer terminology, just a way to convert back and forth between two sets of values 'perfectly and losslessly'.

Re: Monads as a Programming Pattern

#49

Post by secure »

toastal wrote: post #12

I get the intention but it's even harder to understand with this Java/C# syntax. I feel like if you're gonna talk about FP you should probably highlight along the Haskell or Scala code (or similar) and provide OOP stuff for reference in case it's not clear. It ends up being so verbose that I don't many people see the 'point'.

To me, reading examples in a syntax I’m familiar in helps me much more than reading them in a language where the concept might be elegant to express, but hard for me to get into.

I think it’d be best to include examples in a number of languages with a lanugage selector, actually. That way, people who are fluent in functional languages can read that version, and others can read the one they are more fluent in.

Re: Monads as a Programming Pattern

#50

Post by [deleted] »

dkarl wrote: post #43
pjc50 wrote: post #30

I think monads highlight something underappreciated about programming, which is that different people regard very different things as "intuitive". It almost seems that modalities of thinking about programming are bigger, external things than programming itself. Certainly they're barriers to learning. Like Lisp, there seems to be about 10% of the programmer population who think "ah this is obviously the clearest way t…

John von Neumann famously said that in mathematics you don't understand things, you just get used to them. I think monads are an example of this, and all the attempts to make them intuitive before you use them are a huge waste of time. Many mathematical concepts are like this. Take compactness. At first, the definition of compactness seems a little random, but it's useful for proving things, so you keep using it, and…

[deleted]
Post reply on HN