Monads as a Programming Pattern • Hacker News Board

Re: Monads as a Programming Pattern

#51

Post by rhizome » Mon, Aug 12, 2019, 6:22 PM UTC

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…

>A monad is a type that wraps an object of another type.

So, the Adapter Pattern, but for types?

Re: Monads as a Programming Pattern

#52

Post by diegoperini » Mon, Aug 12, 2019, 6:39 PM UTC

stcredzero wrote: post #46

Quekid5 wrote: post #44

Earlier quoted context omitted.

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

It is encapsulation with the mandatory law stating that an encapsulation of an encapsulation must be as deep as a single encapsulation.

Note that this informal statement doesn't necessarily mean you have to be encapsulating data. A behavior, a contract, an assertion, compositions of all of these etc can also be encapsulated.

Fun ideas (not necessarily true but fun to think about):

* Monads kinda convert nesting to concatenations.

* A monad is the leakiest of the abstractions. You are always a single level of indirection away from the deepest entity encapsulated within.

* What's common among brackets, curly braces and paranthesises(?) is them being monadic if you remove them from their final construction while keeping the commas or semicolons.

Very important note: You should have already stopped reading by now if you got angry to due these false analogies.

Re: Monads as a Programming Pattern

#53

Post by mrkeen » Mon, Aug 12, 2019, 6:45 PM UTC

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…

1) Adding getters and setters does not make a program stateless. Your race-conditions and side-effects just take more steps.

2) "A monad is a type that wraps an object of another type. There is no direct way to get that ‘inside’ object. Instead you ask the monad to act on it for you." Your objection to this quote is right, because the quote is wrong.

Re: Monads as a Programming Pattern

#54

Post by mncharity » Mon, Aug 12, 2019, 6:53 PM UTC

pjc50 wrote: post #35

jagthebeetle wrote: post #31

Earlier quoted context omitted.

I think I approximately understand monads, but I find the "wrap the entire external universe" type of explanation to confuse me a bit. It's just the result of one IO computation + a way of handling / unwrapping it! When trying to map (or bind :) a monad to OOP/imperative programming, it strikes me as more straightforward to think that, e.g., the IO monad is an object that encapsulates the result of a network operatio…

> result of one IO computation But for many people, they will be used to IO returning nothing, or error values they can ignore. So the case has to be made as to why you need a monad there at all. (I've just had the slightly disturbing realisation that C++ streams are also monads .. the documentation never uses this term.)

> I've just had the slightly disturbing realisation that C++ streams are also monads

Re: Monads as a Programming Pattern

#55

Post by mrkeen » Mon, Aug 12, 2019, 6:59 PM UTC

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.

True, but you've only written about them as data types, which misses the monadic part. What makes them monads is that you can join any Optional> into an Optional. Likewise you can join a List> into a List. It is that principled 'smooshing down' of the data types that makes them monads.

Re: Monads as a Programming Pattern

#56

Post by atombender » Mon, Aug 12, 2019, 7:00 PM UTC

diegoperini wrote: post #52

stcredzero wrote: post #46

Earlier quoted context omitted.

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

It is encapsulation with the mandatory law stating that an encapsulation of an encapsulation must be as deep as a single encapsulation. Note that this informal statement doesn't necessarily mean you have to be encapsulating data. A behavior, a contract, an assertion, compositions of all of these etc can also be encapsulated. Fun ideas (not necessarily true but fun to think about): * Monads kinda convert nesting to co…

Any references that explain the "converts nesting to concatenation" idea? I find it fascinating, in particular because I write a lot of code that works on deeply nested data structures -- structs of values (which can be structs) or lists of values. The distinction between struct, list and value and the need to treat them differently in code is interesting and annoying, and goes beyond merely working with functors and applicables. I don't understand lenses at all, but I understand monads.

Re: Monads as a Programming Pattern

#57

Post by fizixer » Mon, Aug 12, 2019, 7:05 PM UTC

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…

I see what you're saying. Unfortunately that's not the only problem with monads. Monads have two problems:

- They're explained badly.

- Once they're explained well, many (including me) think it's a bad idea (not the monad, the motivation behind its use in pure-FP).

You start with a pure functional formalism, because you like to be stateless. Then you realize that avoiding statefulness is impossible in computing. So you try to shoehorn state into your stateless state of affairs (no pun), while at the same time refusing to admit that you're not stateless anymore.

The larger issue: some folks appear to think that imperativity is a subset of declarativity.

What that really means is that, they're saying that, computing is a proper subset of math.

And by that, what they're really saying, is that actions are a subset of words.

In other words, if you write something on a piece of paper that describes some action in the real world, (roughly speaking) that action happens or is supposed to happen automatically.

That's now how the world works. That's not how computers work. And I'm sorry to say that's not how programming works.

Computing is not a subset of mathematics. And Mathematics is not a subset of Computing. Same goes with Physics (Physics is not a subset of Mathematics, despite there being way more math used in Physics than CS).

Physics, Computing, and Mathematics are the holy trinity of the reality that we live in. You have to give each of the three the respect they deserve, and only try to make connections between the three, and NOT try to make any of them a subset of the other.

Re: Monads as a Programming Pattern

#58

Post by eli_gottlieb » Mon, Aug 12, 2019, 7:29 PM UTC

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…

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

But then you start running into the nasty issue that when you need to compose multiple monads, you find out that monad transformers don't always commute!

Re: Monads as a Programming Pattern

#59

Post by andrekandre » Mon, Aug 12, 2019, 7:30 PM UTC

fizixer wrote: post #57

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…

I see what you're saying. Unfortunately that's not the only problem with monads. Monads have two problems: - They're explained badly. - Once they're explained well, many (including me) think it's a bad idea (not the monad, the motivation behind its use in pure-FP). You start with a pure functional formalism, because you like to be stateless. Then you realize that avoiding statefulness is impossible in computing. So y…

> Computing is not a subset of mathematics. And Mathematics is not a subset of Computing. Same goes with Physics (Physics is not a subset of Mathematics, despite there being way more math used in Physics than CS).

if i understand you correctly, are you saying that mathematics in the classical sense is not “computing” (von neumann machines?), just as math is not physics, but math is used to model physics

then the proper way to think about the problem is: can there be a math that models actual computing (does that include physics?) as it is today, and is that what we already have in our programming languages today?

and finally, maybe your main point is, with purely functional languages, there is a math invented (lambda calculus?) to describe a stateless ideal that is shoehorned into a reality that it doesn’t describe?

apologies for the random thoughts, just trying to grok everything ^_^

Re: Monads as a Programming Pattern

#60

Post by fizixer » Mon, Aug 12, 2019, 7:51 PM UTC

andrekandre wrote: post #59

fizixer wrote: post #57

Earlier quoted context omitted.

I see what you're saying. Unfortunately that's not the only problem with monads. Monads have two problems: - They're explained badly. - Once they're explained well, many (including me) think it's a bad idea (not the monad, the motivation behind its use in pure-FP). You start with a pure functional formalism, because you like to be stateless. Then you realize that avoiding statefulness is impossible in computing. So y…

> Computing is not a subset of mathematics. And Mathematics is not a subset of Computing. Same goes with Physics (Physics is not a subset of Mathematics, despite there being way more math used in Physics than CS). if i understand you correctly, are you saying that mathematics in the classical sense is not “computing” (von neumann machines?), just as math is not physics, but math is used to model physics then the prop…

I think what I'm trying to say also goes by a well known aphorism by Alfred Korzybski: The map is not the territory [1].

We like to model stuff in computing and stuff in physics, using mathematics. What we're really doing is creating maps (math models) of the territory (computing, and physics). We notice there is some part of the stuff not fully mapped, so we make our map more complex and more elaborate. We keep making our map more and more complex not realizing that not everything about the territory can be mapped, because territory has an existence independent from the map. No matter how complex we make the map, it cannot explain away the territory itself.

What pure-FP advocates are claiming is that that pure-FP is all that's needed for computing. Then they notice (or someone points out) that there is stuff like computing state that is not pure. The pure-FP people go 'no problem, we have monads'. But now they've made pure-FP more complex, and it's not pure anymore. And it now depends on external execution to happen to have state updated. What they appear to be doing is trying to explain away imperative and stateful aspects of computing, which are there as an inherent part of the computer, existing and running in the real world.

You might be interested in a past discussion here [2].

[1] https://en.wikipedia.org/wiki/Map-territory_relation

[2] https://news.ycombinator.com/item?id=17645277