Live data from Hacker News

JavaScript Promises Discussion: Make Them Monadic? (2013)

github.com

41–50 of 79 posts

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

#41
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…

The hardest part for me when I was new to Promises was that multi-layer promises would magically vanish. It was so counter-intuitive from every other programming paradigm — nested loops, deep/complex objects, and functional closures.

I lost several days struggling against the concept until realizing that Promises were intended and designed to work differently than every other aspect of the language.

Can you imagine the language stripping out a nested returned function and instead executing it and returning the value? That’s what Promises will do.

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

#43
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…

Why does everything discussing something you personally like have to be “venom”? People here have serious, thoughtful ideas about how they could have been much nicer and why they represent a missed opportunity. Sorry but I’m just tired of every critical thought needs to be painted as overly negative and therefore worth dismissing.

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

#44
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…

If you're working with Promises as glorified event handlers, then yes, it suits that use case well. The problems that arise later, though, have to do with composability, cancelation, and scheduling.

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

#45

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

Another fun fact: the guy who mocked devs asking for monadic Promises later "championed" and subsequently withdrew the TC39 proposal for Promise cancelation, presumably after realizing that it's impossible to shoehorn into the current spec cleanly.

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

#47
post #12

Such a dumb discussion. One guy saying “Here’s a proven design”, someone else calling it “Typed Language Fantasyland”.

It's not a dumb discussion at all. Callback hells and managing threads synchronously/asynchronously as desired are a big deal.

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

#49
post #48

I wonder why we have to resort to terms like monadic, immutable, orthagonal, etc, in our field so often. I feel weird and elitist using these terms when more common ones suffice and are understood by my customers.

whats a better term here?
Post reply on HN