Live data from Hacker News

List is a monad

alexyorke.github.io

71–80 of 187 posts

Re: List is a monad

#71
post #50

I think the most intuitive description for a monad I've ever seen is 'flatMappable'. Context: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Usually articles that describe them in a very Math-y way go above my head. But the definition above was immediately clear (I saw it on HN). I think this article is a bit more approachable than others I've read, but it still gets very confusing near the end.

Reminds me on an analogy for a monad I once heard. Not sure if it is correct because I lack the mathematical understanding to verify. Anyway, a nested To-Do list is (allegedly) a common form of a monad. Say I am trying to clean my whole house. Well, I could have an item for a task like cleaning the kitchen that has each task I need to do in the kitchen in order for the kitchen to be cleaned. I can do the same for the…

Yes, your understanding is correct. It's literally calling map() on an array, followed by a flat().

Sorry, I should have added more context to my post. I edited my post and added a link to the MDN definition of the flatMap function.

Re: List is a monad

#72

I think this adds more confusion than it removes. A list is not a monad. A list is a data structure; a monad is more like a "trait" or "interface." So you can define a List type that "implements" the monad interface, but this is not an inherent property of lists themselves. That's the sense in which a list "is a" monad: the OOP sense. Haskell's List monad provides a model for nondeterminism. But that certainly isn't…

Hi, I completely agree. "A" list isn't inherently a monad, and that is where my metaphor starts to fall apart a bit (my post title furthers this issue.)

I can clarify this earlier in part 1 or 2 instead of in to-be-written part 3.

Re: List is a monad

#73
post #38

Earlier quoted context omitted.

What can a Haskell monad do that a Python class cannot? 99% of all monads I've seen only facilitate local state manipulation.

This may be a dissenting opinion, but... Haskell tried to avoid mutable state. "Local state manipulation" was not really a thing you could do in Haskell, deliberately. Then someone figured out that you could (ab)use a monad to do that. And because that was the only way, whenever they needed to manipulate state, Haskell programmers reached for a monad. So it's not "what can a Haskell monad do that a Python class canno…

[dead]

Re: List is a monad

#74

I expect the author has done this knowingly, but the title is rather painful for a mathematician to read. A list is not a monad. List is a monad. A list is an algebra for the List monad.

Thanks for the feedback! I can definitely rename the post soon as a first step, although this may require rewriting a chunk of the article to more accurately reflect the fact that List is a monad, and not "a" list.

I could make this distinction in part 3 (not written yet) although I want to balance not misleading readers, but not overcomplicating it too early on.

Re: List is a monad

#75

Earlier quoted context omitted.

After reading your comment, I've made it my mission to understand it. Although I have no idea what you're talking about, you make it sound intriguing.

First off, I'm not sure it's even worth it to understand this stuff... Second, someone should be along to slam it soon enough and insist I've missed some gibberishy business that you'll never understand. With those caveats in mind, here's a more intensive scala-based monad tutorial I made: https://github.com/zaboople/techknow/blob/master/scala/monad... But really, don't burn up too much of your short life trying to c…

It' really worth understanding. I studies Haskell and Scala to write better Python, Typescript, and Java, and it did help.

The whole thing about JS's Promises becomes way clearer when you see that they are a monad, except for one discrepancy (they auto-flatten themselves). It leads to much shorter and clearer code when doing pedestrian frontend stuff.

Re: List is a monad

#76
The amount of people who tie themselves into knots to understand this pointless concept is very funny to me. I am 16 years into a successful software engineering career without learning what a monad is an it never held me back. Turns out I can use lists and optional types and all that jazz without it.

I mean really. Look at posts like this[0]. What does this give you? Nothing, in practical reality. Nothing.

[0] https://news.ycombinator.com/item?id=44446472

Re: List is a monad

#77
post #5

As far as monad tutorials go, this one seems quite good. I like the categorization of monads between "containers" and "recipes". However, I personally think that monad tutorials tend to give people the wrong impression and leave them more confused than they were before, because they focus on the wrong thing. A monad is not a complex concept, at all. IMO a more useful way to present the topic would be with one separat…

Thanks for the feedback! I didn't expect my post to garner a lot of attention. I am totally ok with rewriting part 1, potentially to make it more concise to prevent confusion (wow, this post is super long, monads must be complex!) is what I'd like to avoid.

I can reproduce the double line issue in part 2, this was my mistake and I missed it as part of my editing process. I'll delete part 2 while I make the corrections.

Re: List is a monad

#78
post #69

Earlier quoted context omitted.

This may be a dissenting opinion, but... Haskell tried to avoid mutable state. "Local state manipulation" was not really a thing you could do in Haskell, deliberately. Then someone figured out that you could (ab)use a monad to do that. And because that was the only way, whenever they needed to manipulate state, Haskell programmers reached for a monad. So it's not "what can a Haskell monad do that a Python class canno…

This is not historically how Haskell was developed. Haskell didn't try to "avoid mutable state". Haskell tried to be (and indeed succeeded in being) referentially transparent. Now, it turns out that you can't uphold referential transparency whilst having access to mutable state in the "traditional" way, but you can access mutable state if you introduce monads as a means of structuring your computation. So, they're ce…

But historically, wasn't there a fair period of time between Haskell insisting on referential transparency (and therefore not allowing traditional mutable state) and monads being introduced as a way to deal with it? That was my understanding of the history.

And if so, then it seems fair to say at least that monads were a way to get around the limitations imposed by a desirable feature of the language...

Re: List is a monad

#79

While I can understand the desire to draw a metaphor, there are better approaches than saying, "A List Is a Monad". The statement as-is breaks pretty much immediately because, while there is a canonical list monad, there isn't a list monad, there are in fact several[1]. There are several more correct ways of phrasing the idea among: "List can be given a monad instance" "List forms a monad with pure and bind as define…

Although there can be other monads (and stuff other than monads, such as ZipList) that can be made with lists, I think that such a monad would not necessarily be a "list monad". (Your link [1] has several examples of this.) You are right that it does not mean that "a list is a monad" and that your other phrasing is better, but it does not mean that "there isn't a list monad".

To me "a list monad" often subtly implies "one" list monad. I wasn't very clear, but the point I was trying to make was more along the line of singular vs plural. Thanks for pointing out the discrepancy.

Re: List is a monad

#80

A monad is not a container! It’s a way of composing functions if they have an effect. You tell how to inject a value in that effect (unit) and how to compose two functions that have that effect and that’s it: programmable semicolons.

Thanks for the feedback, I totally agree that monads are not containers. From an OOP perspective, they have some properties that make them, in some sense, sorta like containers, e.g., they contain a value like the Maybe monad. I still agree that they are not simply containers. I can clarify this in a revision to part 1 soon.
Post reply on HN