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

JavaScript Promises Discussion: Make Them Monadic? (2013)

github.com

Post reply on HN
Print view View original

21–30 of 79 posts

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

#21

Post by djtriptych »

nawgszy wrote: 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…

Agreed, it was a HUGE improvement over callback soup.

The only cleaner methods I’m familiar with are CSP (as implemented in clojure and go, and to some extent in JavaScript with libraries like RX and Bacon). Basically you’re treating steams of events as first-class values. That’s a rather functional/mathy way to treat concurrency/parallelism but I’ve found it illuminating.

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

#22

Post by mikewhy »

I'm confused, and am not very knowledgeable about FP (though I am very interested in it).

Can anyone explain how the 3 bullet points in the issue aren't already in Promises?

> Promise.of(a) will turn anything into promise.

This just looks like `Promise.resolve(a)`

> Promise#then(f) should take one function, not two.

That's applicable, but you could try limiting yourself to only using one argument.

> Promise#onRejected(f): move onRejected to prototype instead of second arg.

`Promise#catch(f)`?

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

#23

Post by Nadya »

dahart wrote: post #10
rockymadden wrote: post #4

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…

"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 explanation already suffers from the first quote: they're incapable of explaining them.

I had read 30 or 35 different monads-for-Javascript tutorials/guides/explanations before I finally thought I grokked it. None of them have helped and I'm still not sure my understanding of them is correct.

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

#25

Post by dboreham »

maximexx wrote: post #5

> JavaScript Promises Discussion: Make Them Monadic? No, just totally ditch them! I can't help to hate Promises. Sometimes I have to work on a code base that is completely baked with them, it's just a nightmare. With the stupid async await implementation things haven't got any better.. Now they expect me to write async calls in a try-catch block!?! With JS I prefer to use simple callbacks until they come up with a pr…

I think you'll find that the proper solution to this problem is : threads. (or actors, goroutines, CSP if you want to call them that instead). Promises and callbacks are something you'd do if you have an execution environment lacking threads (which is true of Javascript).

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

#26

Post by tel »

mikewhy wrote: post #22

I'm confused, and am not very knowledgeable about FP (though I am very interested in it). Can anyone explain how the 3 bullet points in the issue aren't already in Promises? > Promise.of(a) will turn anything into promise. This just looks like `Promise.resolve(a)` > Promise#then(f) should take one function, not two. That's applicable, but you could try limiting yourself to only using one argument. > Promise#onRejecte…

The issue with `of` is that it special cases when `a` is already a Promise. Promises try hard to not be nested (a promise of a promise) but that nesting is critical for algebraic properties.

The then issue is multifarious. On one side, splitting the two uses makes the algebraic justification for then more clear, but it's not a big deal. The real issue is that `then(f)` does different things when `f` returns a Promise. This breaks in the same way that `of` did—you need to be able to discuss nested promises.

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

#27

Post by marknadal »

I was never on the promise bandwagon because they never did anything useful other than create hype with developers around using a more functional approach - which is good, but promises themselves add no benefit.

For instance, people previously would do:

```

start(x => doA(y => doB(z => doC(end))))

```

When they could have just used named functions, with promises or not, it is just that promises was hype that taught them good programming skills:

```

doA = x => doB(x)

doB = y => doC(y)

doC = z => end

start(doA);

```

As with promises:

```

start.then(x => x)

  .then(y => y)

  .then(z => z)

  .then(end)
```

The only real value of a promise now is being able to use `await`, which is the real first-class language magic.

However, the future isn't even with promises, so there is no need to change or modify them. The future is chain reaction programming, also goes by the name of observables/FRP/stack-based-cocatenative-programming/railway-programming.

Programming Chain Reactions is great, because they can also downconvert easily to `await`, so you get the best goodies of all the world.

We've implemented observable/FRP/chain-reaction programming as the default API in https://github.com/amark/gun , it is really quite pleasant language abstraction. However, FRP/etc. hasn't quite hit "mainstream" hype yet, so developers do not know what they are missing out on. Once you try it and it "clicks", you realize the future is truly bright. :)

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

#28

Post by Lazare »

turbohz wrote: post #3

This is an old discussion (which I had followed for years). The proposal, afaik, was never accepted into Ecmascript. So we ended up with half baked Promises. In a particular nodejs project I worked on, I overrode the native Promise implementation with the one provided by Pacta, but was not ideal (promises returned by other modules where native, ...) Not doing nodejs work anymore, but I'm still rather disappointed abo…

Yeah. Native promises are usable, and they're okay...

...but with only a few small changes they could have been much better, and it's frustrating to see proposal to make them better back when that was an option denied out of hand with such arrogance and (to my mind) lack of understanding of what was even being discussed. The linked thread of comments has not aged well over the years.

(And it's doubly frustrating now that the (excellent!) async/await syntax has now been built on top of it. What a wasted opportunity.)

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

#29

Post by Lazare »

nawgszy wrote: 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 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.

The issue with Promises is they could be a LOT better, and they're not for no good reason. Yeah, they're better than callback hell, but anything would be better than callback hell. "Hurts less than stabbing yourself with a screwdriver" should be a baseline expectation, not a recommendation. :)

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

#30

Post by Lazare »

maximexx wrote: post #5

> JavaScript Promises Discussion: Make Them Monadic? No, just totally ditch them! I can't help to hate Promises. Sometimes I have to work on a code base that is completely baked with them, it's just a nightmare. With the stupid async await implementation things haven't got any better.. Now they expect me to write async calls in a try-catch block!?! With JS I prefer to use simple callbacks until they come up with a pr…

I have a number of criticisms of Promises, but I think your point is utterly wrong.
Post reply on HN