Live data from Hacker News

JavaScript Promises Discussion: Make Them Monadic? (2013)

github.com

31–40 of 79 posts

Re: JavaScript Promises Discussion: Make Them Monadic? (2013)

#31
post #23
post #10

Earlier quoted context omitted.

> It also has adheres to Fantasy Land, Static Land, and has defintions for santuary-def. I think I understood a couple words in that sentence, like "it" and "has". :P Looking up fantasy-land, I found https://github.com/fantasyland/fantasy-land . I would like to better understand these monads everyone is talking about. But, just to be super honest -- and possibly completely wrong -- the terminology is really off-putti…

"Once you understand monads, you immediately become incapable of explaining them to anyone else” Lady Monadgreen’s curse ~ Gilad Bracha" If you'd like to go down a rabbit hole of category theory look up the phrase "A monad is just a monoid in the category of endofunctors, what's the problem?" - a fun quote that a lot of monad explanatory tutorials will quip. Not that it will help - because anyone writing a monad expl…

Here's a half baked explanation, as in just the flatmap part.

map is understood in javascript.

So you 'just' need to make the leap to flatmap. Which is mapping something and flattening the result.

So still you need to learn is what flatten is. But that's not too hard to learn.

Try the funfunfunction video [0]

[0]: https://m.youtube.com/watch?v=9QveBbn7t_c

Re: JavaScript Promises Discussion: Make Them Monadic? (2013)

#33
post #17

I am surprised to see so much venom against Promises expressed here. I am young, but I began coding (as a profession) just when Angular 1 was popular and I remember callback hell was a real thing. A few years later, I use Promises a lot, and they work really well. The way errors bubble is logical and easily controlled, it's almost impossible to throw an unhandled promise exception, doing 'parallel' tasks is easy with…

I started programming professionally around the same time but I'm surprised that you think Promise.all([]) makes things easy. IMO Promise.all([]) is nice until you start supporting proper error handling.

Re: JavaScript Promises Discussion: Make Them Monadic? (2013)

#34

Fun fact: the JS library Fantasy Land [1] got its name from that discussion [2]. [1] https://github.com/fantasyland/fantasy-land [2] https://github.com/promises-aplus/promises-spec/issues/94#is...

I am so happy to know this lineage, thank you!

Re: JavaScript Promises Discussion: Make Them Monadic? (2013)

#35
post #17

I am surprised to see so much venom against Promises expressed here. I am young, but I began coding (as a profession) just when Angular 1 was popular and I remember callback hell was a real thing. A few years later, I use Promises a lot, and they work really well. The way errors bubble is logical and easily controlled, it's almost impossible to throw an unhandled promise exception, doing 'parallel' tasks is easy with…

Can you explain a bit more what your code is doing?

Are you suppose to instantiate the handler class and call it?

Re: JavaScript Promises Discussion: Make Them Monadic? (2013)

#36
post #23
post #10

Earlier quoted context omitted.

> It also has adheres to Fantasy Land, Static Land, and has defintions for santuary-def. I think I understood a couple words in that sentence, like "it" and "has". :P Looking up fantasy-land, I found https://github.com/fantasyland/fantasy-land . I would like to better understand these monads everyone is talking about. But, just to be super honest -- and possibly completely wrong -- the terminology is really off-putti…

"Once you understand monads, you immediately become incapable of explaining them to anyone else” Lady Monadgreen’s curse ~ Gilad Bracha" If you'd like to go down a rabbit hole of category theory look up the phrase "A monad is just a monoid in the category of endofunctors, what's the problem?" - a fun quote that a lot of monad explanatory tutorials will quip. Not that it will help - because anyone writing a monad expl…

Because the point is mostly lost on the unrelated analogies most tutorial writers use. A monad is a mathematical construct. Trying to explain them in terms of what makes sense to you, because your analogy results from your understanding, isn't likely to be more helpful than outright accepting what they represent, mathematically speaking, then putting that to use in your code.

Re: JavaScript Promises Discussion: Make Them Monadic? (2013)

#37

Fun fact: the JS library Fantasy Land [1] got its name from that discussion [2]. [1] https://github.com/fantasyland/fantasy-land [2] https://github.com/promises-aplus/promises-spec/issues/94#is...

Ive been following Fantasy Land since times immemorial, but I never knew thats where the name came from (even though I followed the legendary discussions around the spec back in the days). Only today when I reread it did I notice the fantasy land call, and told myself "Omg...THAT is where it came from!"

Re: JavaScript Promises Discussion: Make Them Monadic? (2013)

#38
post #17

I am surprised to see so much venom against Promises expressed here. I am young, but I began coding (as a profession) just when Angular 1 was popular and I remember callback hell was a real thing. A few years later, I use Promises a lot, and they work really well. The way errors bubble is logical and easily controlled, it's almost impossible to throw an unhandled promise exception, doing 'parallel' tasks is easy with…

As already mentioned, they're a lot better than callbacks (well, for certain cases. There are still places where callbacks are better).

The problem is that this is a field that has been heavily studied, and there are great solutions to this problem that also solve countless other problems, and interop well with each other. The way promises work, they solve that ONE problem but throw away the rest.

If you have the choice between 2 mostly equivalent solutions to solve a problem, but one of the solutions also solve 10 other problems with essentially no drawback, why would you choose the former?

This is probably already linked in this thread somewhere and is also probably was prompted someone to post this old issue to Hacker news, but this is a good explanation of the problem:

https://staltz.com/promises-are-not-neutral-enough.html

Re: JavaScript Promises Discussion: Make Them Monadic? (2013)

#39
post #10

For those looking for monadic Promises, I’d suggest taking a look at Fluture ( https://github.com/fluture-js/Fluture ). It’s a wonderful library and with do-notation, ability to work with callbacks, nodebacks, and Promises, I haven’t looked back. It also has adheres to Fantasy Land, Static Land, and has defintions for santuary-def.

> It also has adheres to Fantasy Land, Static Land, and has defintions for santuary-def. I think I understood a couple words in that sentence, like "it" and "has". :P Looking up fantasy-land, I found https://github.com/fantasyland/fantasy-land . I would like to better understand these monads everyone is talking about. But, just to be super honest -- and possibly completely wrong -- the terminology is really off-putti…

The thing is the general problem with software development right now:

What we know is "intuitive and simple". What we don't know is "off-putting and academic".

Terminology is incredibly important in computer science. If you make something that's kind of like a promise, but not "quite" a promise, and call it a promise, a lot of problems wil arise when people use your code or try to debug it. Monads are pretty simple (they're a heck of a lot simpler than promises). The terminology manners because they're all about interop. If you make something like a monad, but it's not quite a monad, you essentially lose all the benefits (that's the problem with promises).

Fantasy-land is a specification. It's meant for implementers, not for users. The important part is that people who build libraries that should work with other libraries also conforming to the spec, work well with each other. Take a look at some of the very simple constructs you might be used to, and how they are specified on the TC39's github. I'm quite familiar with the spec and I have trouble reading it, but I'm not the target audience. For the users, there are simpler resources.

As for the terminology, inheritance, polymorphism, overloading are all words that a lot of people are familiar with. I'd say the terminology is way worse, and the concepts are often a lot more complex, but people are used to them because it's what they're taught. Java put in monad-like constructs in their Optionals, and it's a lot friendlier...except when trying to compare 2 libraries doing the same thing using 2 different 'friendly' terminology, it's hell. It's not about being academic or elitist, it's about being precise. Something I can google for without having to sort through 16 pages of unrelated crap.

Google for monads, you'll get a lot of relevent material. Google for "optionals", and now you have to precise which language you're talking about, and in some cases potentially which library.

If you want a friendlier intro, look up "Functional programming in javascript" by luis atencio. It's fantastic.

I also always liked this tutorial: https://medium.com/@tzehsiang/javascript-functor-applicative...

At the end of the day, you don't need to know what dynamic method dispatch is to use it. Only the implementers need to :) This is the same thing.

Finally, yeah, some stuff look like "enterprise java". And there's a reason "enterprise java" existed: not all problems are easy. Some companies have hard problems to solve. Maybe it wasn't the best way to solve those problems, but a vanilla Rails REST api probably is worse. That doesn't mean everyone needs those solutions, but its nice that they exist. In this case, most people wouldn't have felt much difference if promises had been monads. But for the people who need monads, they're worse off by the current state of things.

Re: JavaScript Promises Discussion: Make Them Monadic? (2013)

#40
post #10

For those looking for monadic Promises, I’d suggest taking a look at Fluture ( https://github.com/fluture-js/Fluture ). It’s a wonderful library and with do-notation, ability to work with callbacks, nodebacks, and Promises, I haven’t looked back. It also has adheres to Fantasy Land, Static Land, and has defintions for santuary-def.

> It also has adheres to Fantasy Land, Static Land, and has defintions for santuary-def. I think I understood a couple words in that sentence, like "it" and "has". :P Looking up fantasy-land, I found https://github.com/fantasyland/fantasy-land . I would like to better understand these monads everyone is talking about. But, just to be super honest -- and possibly completely wrong -- the terminology is really off-putti…

I tried my best to write a series of posts [0] demonstrating functional programming concepts using practical examples. I've found that Javascript is actually a decent language for learning about currying and monads, etc, because it affords you the ability to pick up a little bit at a time. You can learn one little trick and use it to improve your existing code before picking up another.

The nice thing about Monads is that once you learn the interface then encountering another is no big deal: you already know the API and how to use it. And it turns out this pattern is quite common.

[0] https://agentultra.com/blog/mostly-practical-functional-prog...

Post reply on HN