I feel like I’m being promised a burrito.
A burrito is just a strong monad in the symmetric monoidal category of food, what’s the promise?
That maybe I’ll get a burrito.
JavaScript Promises Discussion: Make Them Monadic? (2013)
71–79 of 79 posts
Re: JavaScript Promises Discussion: Make Them Monadic? (2013)
#72Fun 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.
Having followed the promise cancellation proposal pretty closely, especially when it came to a close, it sounded more like he got sick of the pushback (specifically mentioning push back internally at Google) if my memory serves. I won't pretend to speak for him, but I don't recall him withdrawing the proposal because he didn't think his solution was correct. He just didn't want to deal with the detractors anymore.
Of course, it was a solution to a problem he created, so... (to be fair, the JavaScript world was very different then than it is now, in the same way ES6 classes would probably work very differently if they were designed today)
Re: JavaScript Promises Discussion: Make Them Monadic? (2013)
#73I 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.
I'm not sure what you're getting at, can you expand?
I work a lot with databases, so say you're trying to write an object and its children in some sort of one-to-many relationship to the DB.
You can write a Promise chain like
startTransaction()
.then(() => writeParent())
.then((children) =>
Promise.all(children.map((child) =>
writeChild(child)
))
)
.then(
// handle success
endTransaction(),
// handle error
cancelTransaction()
)
Re: JavaScript Promises Discussion: Make Them Monadic? (2013)
#74I 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?
Yeah, exactly. Say you have an API request that is persisting a chunk of data to the database, like a few dependent data items.
This way, you write the API request to just be a simple function invocation of the class you instantiated:
(req, res, next) => {
apiHandler = new APIHandler(args);
apiHandler.saveData(req.body)
.then(
// success
() => res.status(200).json(apiHandler.getResponse()),
// error
() => res.status(400|500).json(apiHandler.getErrorResponse())
)
If you're just making simple create / update / get requests, it's less valuable, and you can just return a Promise from somewhere. Hopefully that gave you an idea of my motivations
Re: JavaScript Promises Discussion: Make Them Monadic? (2013)
#75I 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…
But how could they "be a LOT better"?
I see this being said, but from what I've seen async handling is generally not very graceful; with that said, Promises are a very simple but powerful API that seem to handle the problem fairly elegantly.
That is why I'm surprised. I just don't know what the alternative is supposed to be! Can you point me to a language and a library that you would say does a better job of handling asynchronicity than Promises?
Re: JavaScript Promises Discussion: Make Them Monadic? (2013)
#76Earlier quoted context omitted.
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…
That just raises more questions. Can anyone here give a concrete example of a real world problem that is more cleanly solved with these changes to the Promise spec? There's a lot of talk about FP and type theory here, and none about actual work. To me, all this stuff is still in the "cool to play around with at home" category. But until it affects day to day dev work, there's a whole set of people that aren't going t…
Just responding as op, but pka nailed it.
If you're writing every line of code directly then these all feel like conveniences. If you write code that's more generic then they become exponentially compounding edge cases.
Re: JavaScript Promises Discussion: Make Them Monadic? (2013)
#77Earlier quoted context omitted.
> 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…
But how could they "be a LOT better"? I see this being said, but from what I've seen async handling is generally not very graceful; with that said, Promises are a very simple but powerful API that seem to handle the problem fairly elegantly. That is why I'm surprised. I just don't know what the alternative is supposed to be! Can you point me to a language and a library that you would say does a better job of handling…
I think this sums of my issues with promises quite well:
https://staltz.com/promises-are-not-neutral-enough.html
Re: JavaScript Promises Discussion: Make Them Monadic? (2013)
#78Earlier quoted context omitted.
> 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…
But how could they "be a LOT better"? I see this being said, but from what I've seen async handling is generally not very graceful; with that said, Promises are a very simple but powerful API that seem to handle the problem fairly elegantly. That is why I'm surprised. I just don't know what the alternative is supposed to be! Can you point me to a language and a library that you would say does a better job of handling…
Elixir, for one. It's only when I started properly learning other languages than JS that I started seeing how much better a lot of things could be. I say that with a lot of affection for JS, but JS style Promises are among the things that I don't miss.
EDIT: To elaborate a bit, what I don't like about (JS) Promises, in hindsight, is that 1) they seem to infect my entire codebase, and 2) making non-async code async is usually nontrivial. In Elixir it's basically a matter of 'telling' a function or an entire module to go do it's thing in another process and report back when done. It means in many cases I only need to change the caller side of things and the code that runs async itself looks the same as the sync code. And that's not even the best part of (Erlang style) processes!
Re: JavaScript Promises Discussion: Make Them Monadic? (2013)
#79Earlier 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…
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…
While I agree, I've also found that it can be a danger. I thought I was all about the functional programming until I used languages that 'required' it. It was only then that I realized I'd been using non-functional escape hatches all over the place.