JavaScript Promises Discussion: Make Them Monadic? (2013)
1–10 of 79 posts
Re: JavaScript Promises Discussion: Make Them Monadic? (2013)
#2What about it?
Re: JavaScript Promises Discussion: Make Them Monadic? (2013)
#3This 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 about how Ecmascript promises were ultimately delivered.
Re: JavaScript Promises Discussion: Make Them Monadic? (2013)
#4For 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.
Re: JavaScript Promises Discussion: Make Them Monadic? (2013)
#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 proper async await without try-catch and Promises bullshit. Callback hell happens not because of the callback principle itself. It exists because it's too easy to keep nesting functions. Most devs simply don't know how, or are too lazy, to apply good patterns for using callbacks.
Re: JavaScript Promises Discussion: Make Them Monadic? (2013)
#6> 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…
This. Every time I try and get up to speed on those things it's like, "wtf? this is actually better?"
Re: JavaScript Promises Discussion: Make Them Monadic? (2013)
#7> 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…
> Now they expect me to write async calls in a try-catch block!?!
What do you mean? In my experience, the use of async/await leads to much cleaner code for I/O driven tasks like querying APIs and databases. Yes, I do have a try/catch at the top of the callstack to catch and log unexpected errors.
Re: JavaScript Promises Discussion: Make Them Monadic? (2013)
#8> 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…
Having seen several codebases go from using arbitrary callbacks (two? One with an error arg? Why not both?) To promises/asynchronous/await it's hard to see your point. The code is cleaner, there is no callback hell with await, in fact no callbacks at all. And yes, you do need to use a try/catch block where appropriate.
Stop trying to emulate a try/catch with ridiculous nested callback passing that inevitably leads to the function not being called and data being lost. Just stop.
Re: JavaScript Promises Discussion: Make Them Monadic? (2013)
#9> 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…
> Now they expect me to write async calls in a try-catch block!?! What do you mean? In my experience, the use of async/await leads to much cleaner code for I/O driven tasks like querying APIs and databases. Yes, I do have a try/catch at the top of the callstack to catch and log unexpected errors.
async/await worries me, not for abstract language reasons but because it hides complexity in a way not friendly for junior engineers.
I imagine a lot of code that should be thought out and made parallel being forced into a synchronous flow.
Note that promises aren't a ton better in this regard, and come with a ton of confusion themselves. In short, async is hard.
Re: JavaScript Promises Discussion: Make Them Monadic? (2013)
#10For 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-putting. At a glance it just feels super complex, academic and completely divorced from practical coding. I get vibes of enterprise java class hierarchies looking at this stuff.
I hope I'm wrong, and I really am interested to learn more about it, but I can see from the OP's linked thread that I'm not alone feeling this way. It's not at all clear why I should be thinking about my JavaScript algebraically at all times, or what the practical advantages are. After decades of coding, I'm just getting more alergic to complexity, and this feels like complexity.
What are some good online resources that might help me change my mind and see the light?