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

Monads and Intensionality – Lucid is not an aberration

billwadge.wordpress.com

Post reply on HN
Print view View original

11–20 of 38 posts

Re: Monads and Intensionality – Lucid is not an aberration

#11

Post by lmm »

ezrast wrote: post #10
greydius wrote: post #2

It's unfortunate that so many people in the software profession have a negative attitude towards these concepts. Despite its unfortunately alien name, monad is a great abstraction for patterns that come up often in this field. > So what is the IO monad, the most famous of them all? IO is the State monad where the state is the entire universe.

I don't have a negative attitude towards the concept of monads nor one informed by its funny name (where did you even get that notion? Programming is filled with jargon). I do have a bit of a negative attitude towards evangelists who expect people to be impressed by ideas whose significance they routinely fail to communicate. Functional programming enthusiasts seem to really want the rest of us to care about monads b…

* Tracking which things need to happen in a database transaction

* Gathering statistics (multiple different cases)

* Authentication

* Async pipelines (I found iteratees much easier to learn than "reactive streams" because they're just monads)

Essentially any time you find yourself with a "cross-cutting concern", something you'd be tempted to use an "aspect" or "decorator" for, you probably want to use a monad. And there's a lot of complicated language features that you can just remove (or reduce to syntax sugar) if your language has monads instead: https://philipnilsson.github.io/Badness10k/escaping-hell-wit...

Re: Monads and Intensionality – Lucid is not an aberration

#12

Post by 0DHm2CxO7Lb3 »

ezrast wrote: post #10
greydius wrote: post #2

It's unfortunate that so many people in the software profession have a negative attitude towards these concepts. Despite its unfortunately alien name, monad is a great abstraction for patterns that come up often in this field. > So what is the IO monad, the most famous of them all? IO is the State monad where the state is the entire universe.

I don't have a negative attitude towards the concept of monads nor one informed by its funny name (where did you even get that notion? Programming is filled with jargon). I do have a bit of a negative attitude towards evangelists who expect people to be impressed by ideas whose significance they routinely fail to communicate. Functional programming enthusiasts seem to really want the rest of us to care about monads b…

> I don't understand why having a formal model for that commonality is so important.

So generic libraries can be built and abstracting frequently used operations over many different data types. I've never implemented a monad myself outside of a toy project and am by no means an expert, but it's quite nice to be able to transfer certain knowledge on lists to options or futures. Similar to generic interfaces like a collection interface, so whether you are working on a set or a list you know that 'get' or 'exists' can be used.

Re: Monads and Intensionality – Lucid is not an aberration

#13

Post by goto11 »

ezrast wrote: post #10
greydius wrote: post #2

It's unfortunate that so many people in the software profession have a negative attitude towards these concepts. Despite its unfortunately alien name, monad is a great abstraction for patterns that come up often in this field. > So what is the IO monad, the most famous of them all? IO is the State monad where the state is the entire universe.

I don't have a negative attitude towards the concept of monads nor one informed by its funny name (where did you even get that notion? Programming is filled with jargon). I do have a bit of a negative attitude towards evangelists who expect people to be impressed by ideas whose significance they routinely fail to communicate. Functional programming enthusiasts seem to really want the rest of us to care about monads b…

> I don't have a negative attitude towards the concept of monads nor one informed by its funny name (where did you even get that notion? Programming is filled with jargon).

It is a really weird idea which goes back to Simon Peyton Jones himself. Quote: Our biggest mistake was using the scary term “monad” rather than “warm fuzzy thing”.

I love Haskell, but the condescending attitude of some of it's adherents are off-putting. If some programmers don't grasp the wonder of monads, surely it can only be because they are scared of the word.

Re: Monads and Intensionality – Lucid is not an aberration

#14

Post by tsimionescu »

lmm wrote: post #11
ezrast wrote: post #10

Earlier quoted context omitted.

I don't have a negative attitude towards the concept of monads nor one informed by its funny name (where did you even get that notion? Programming is filled with jargon). I do have a bit of a negative attitude towards evangelists who expect people to be impressed by ideas whose significance they routinely fail to communicate. Functional programming enthusiasts seem to really want the rest of us to care about monads b…

* Tracking which things need to happen in a database transaction * Gathering statistics (multiple different cases) * Authentication * Async pipelines (I found iteratees much easier to learn than "reactive streams" because they're just monads) Essentially any time you find yourself with a "cross-cutting concern", something you'd be tempted to use an "aspect" or "decorator" for, you probably want to use a monad. And th…

Well, this shows one simplistic partial syntactic solution to a few common problems. Partial because it does not handle errors in the continuation example, and simplistic because it only works at the function level, it's not clear how this would look like when 'distributed' through a large code base, like cross-cutting concerns typically are. Not to mention, it's not clear how to compose all of these separate solutions - how will the do notation work if you have a list of continuations that can each return optional values that return errors if something is not authenticated?

Note, I'm not claiming that these problems are not solved by monads. I'm arguing that the article you showed gives me no information on how really complicated problems are actually solved, it just shows a neat bit of syntax sugars that works on a few toy problems (again, that's what's shown, not claiming that this is all that 'do' is).

Re: Monads and Intensionality – Lucid is not an aberration

#15

Post by tsimionescu »

0DHm2CxO7Lb3 wrote: post #12
ezrast wrote: post #10

Earlier quoted context omitted.

I don't have a negative attitude towards the concept of monads nor one informed by its funny name (where did you even get that notion? Programming is filled with jargon). I do have a bit of a negative attitude towards evangelists who expect people to be impressed by ideas whose significance they routinely fail to communicate. Functional programming enthusiasts seem to really want the rest of us to care about monads b…

> I don't understand why having a formal model for that commonality is so important. So generic libraries can be built and abstracting frequently used operations over many different data types. I've never implemented a monad myself outside of a toy project and am by no means an expert, but it's quite nice to be able to transfer certain knowledge on lists to options or futures. Similar to generic interfaces like a col…

Sure, but what generic libraries can you meaningfully built above optional, list, either, futures? Do-notation is one, but what else?

Re: Monads and Intensionality – Lucid is not an aberration

#16

Post by lmm »

tsimionescu wrote: post #14
lmm wrote: post #11

Earlier quoted context omitted.

* Tracking which things need to happen in a database transaction * Gathering statistics (multiple different cases) * Authentication * Async pipelines (I found iteratees much easier to learn than "reactive streams" because they're just monads) Essentially any time you find yourself with a "cross-cutting concern", something you'd be tempted to use an "aspect" or "decorator" for, you probably want to use a monad. And th…

Well, this shows one simplistic partial syntactic solution to a few common problems. Partial because it does not handle errors in the continuation example, and simplistic because it only works at the function level, it's not clear how this would look like when 'distributed' through a large code base, like cross-cutting concerns typically are. Not to mention, it's not clear how to compose all of these separate solutio…

> Well, this shows one simplistic partial syntactic solution to a few common problems.

It's not just syntactic - the different cases genuinely do implement a common interface.

> Partial because it does not handle errors in the continuation example

Nor does the non-monad version, so it's a fair comparison.

> simplistic because it only works at the function level, it's not clear how this would look like when 'distributed' through a large code base, like cross-cutting concerns typically are. Not to mention, it's not clear how to compose all of these separate solutions - how will the do notation work if you have a list of continuations that can each return optional values that return errors if something is not authenticated?

Sure, but again, a problem that exists even more strongly if these are implemented as (non-monad) language features (e.g. if my language has both continuations and exceptions, what happens when some continuation-based code throws an exception).

The point is that you can get rid of a whole bunch of complex language features and language keywords, and write everything in terms of plain functions and values (in particular, the result is that you can refactor fearlessly because everything follows the normal rules of the language). You don't have to look at anything large scale to see the benefit of that.

Re: Monads and Intensionality – Lucid is not an aberration

#17

Post by lmm »

tsimionescu wrote: post #15
0DHm2CxO7Lb3 wrote: post #12

Earlier quoted context omitted.

> I don't understand why having a formal model for that commonality is so important. So generic libraries can be built and abstracting frequently used operations over many different data types. I've never implemented a monad myself outside of a toy project and am by no means an expert, but it's quite nice to be able to transfer certain knowledge on lists to options or futures. Similar to generic interfaces like a col…

Sure, but what generic libraries can you meaningfully built above optional, list, either, futures? Do-notation is one, but what else?

Essentially any library function that takes any kind of callback benefits from being able to take a generically-effectful callback. There's plenty of mileage in basic things like database row mappers.

If you want fancy examples, things like generic data structure traversals (I use a cataM like https://github.com/ekmett/recursion-schemes/issues/3 all the time). Another good example is iteratees - you can define an effectful source, an effectful sink, or an effectful transformation stage in a stream pipeline, which makes it very practical to have very small reusable pieces. Since it's using the generic monad interface you can define an intermediate stream transformer even for some custom effect that you wrote yourself, but be confident that everything will be plumbed together correctly.

Re: Monads and Intensionality – Lucid is not an aberration

#18

Post by ezrast »

lmm wrote: post #11
ezrast wrote: post #10

Earlier quoted context omitted.

I don't have a negative attitude towards the concept of monads nor one informed by its funny name (where did you even get that notion? Programming is filled with jargon). I do have a bit of a negative attitude towards evangelists who expect people to be impressed by ideas whose significance they routinely fail to communicate. Functional programming enthusiasts seem to really want the rest of us to care about monads b…

* Tracking which things need to happen in a database transaction * Gathering statistics (multiple different cases) * Authentication * Async pipelines (I found iteratees much easier to learn than "reactive streams" because they're just monads) Essentially any time you find yourself with a "cross-cutting concern", something you'd be tempted to use an "aspect" or "decorator" for, you probably want to use a monad. And th…

Thanks, those are good examples. The linked article underscores my point though: the author takes four disparate ideas and reduces them to the exact same code in each case. All that code tells me is that there are monads going on; that's no good to me if I can't tell what those monads are actually doing!

Also, for what it's worth you can get rid of a lot of those same language features with good old OO methods. See Crystal's each[1] and try[2] methods, for example.

I don't mean this to be a tit-for-tat and do appreciate the response. You've inspired me to try and make use of a state monad in some Ocaml I've been playing with. Cheers.

[1]https://crystal-lang.org/api/0.35.1/Indexable.html#each(&)-i... [2]https://crystal-lang.org/api/0.35.1/Object.html#try(&)-insta...

Re: Monads and Intensionality – Lucid is not an aberration

#19

Post by tome »

goto11 wrote: post #13
ezrast wrote: post #10

Earlier quoted context omitted.

I don't have a negative attitude towards the concept of monads nor one informed by its funny name (where did you even get that notion? Programming is filled with jargon). I do have a bit of a negative attitude towards evangelists who expect people to be impressed by ideas whose significance they routinely fail to communicate. Functional programming enthusiasts seem to really want the rest of us to care about monads b…

> I don't have a negative attitude towards the concept of monads nor one informed by its funny name (where did you even get that notion? Programming is filled with jargon). It is a really weird idea which goes back to Simon Peyton Jones himself. Quote: Our biggest mistake was using the scary term “monad” rather than “warm fuzzy thing”. I love Haskell, but the condescending attitude of some of it's adherents are off-p…

Haskellers regularly hear complaints of the form "you should have called it 'Mappable' instead of 'Functor' -- that would have made it much easier to understand" or "you should have called it 'Chainable' instead of 'Monad' -- that would have made it much easier to understand", so I don't think we can say that this purely comes from a position of assumed superiority.

Re: Monads and Intensionality – Lucid is not an aberration

#20

Post by kstenerud »

greydius wrote: post #2

It's unfortunate that so many people in the software profession have a negative attitude towards these concepts. Despite its unfortunately alien name, monad is a great abstraction for patterns that come up often in this field. > So what is the IO monad, the most famous of them all? IO is the State monad where the state is the entire universe.

We don't have a negative attitude towards these concepts; we just don't have a damn clue what these concepts even are, or how they're useful. And thus far the FP crowd haven't been very effective in communicating this.

I'm still waiting for THE article that actually explains how this stuff works in an accessible way, without resorting to a bunch of haskell code (for which you need to already know FP - catch-22), an assumed proficiency in category theory, heavy maths, esoteric toy problems that don't touch the real world, or technically correct yet unapproachable jargon ("A monad is just a monoid in the category of endofunctors, what's the problem?").

Could you imagine teaching BASIC with "A variable is a container for values, which are themselves elements of a set of constrained possibilities. You assign to variables by collapsing the set into one possibility." That's what most FP articles feel like.

To have success in communication, you need to speak to your audience where they are; not where you wish they'd be.

Feynman was able to do this for physics; hopefully someday someone will do it for FP, and then you'll find us MUCH more receptive to the message.

Post reply on HN