JavaScript Promises Discussion: Make Them Monadic? (2013)
github.com
github.com
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.
...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.)
[1] https://github.com/fantasyland/fantasy-land
[2] https://github.com/promises-aplus/promises-spec/issues/94#is...
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)
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 ```Promise.all([])```, and there's pretty limited complexity with the way a Promise always returns a Promise.
I find the simplest way to use them is to define a class that has a few data properties you'd like to track.
class Handler {
constructor() {
// shared variables can be set / reset here
this.defineInitialState();
}
executeAction() {
return (
this.promiseFn()
.then(() => this.anotherPromise())
.then((passedArgument) => this.promiseExpectingArgument())
.then(
// success case
() => this.successHandler(),
(err) => this.errorHandler()
)
);
}
}
I don't know about this async / await keyword stuff, and if you have to wrap it in a try/catch block, that's unfortunate but also seems like it's not the end of the world. After all, isn't the Go language constantly requiring you to say "if err != nil <your code>"? Explicit error handling isn't even a bad thing.
Anyways, this is just my opinion, it's fair to have your own, and maybe other languages handle asynchronicity more gracefully, but from what I've seen this is a clean way to wrap async OR sync code in a context that makes it always behave predictably and readably.
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.
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. :)
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?
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!
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()
)
Are you suppose to instantiate the handler class and call it?
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
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:
Like? I am genuinely interested in knowing the drawbacks of promises and places where a callback like structure is more favourable. By the way, I am not contradicting you, just trying to learn.
Not sure I'd want to use a promise there :)
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.
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?
A simpler, gentler introduction is available from https://www.manning.com/books/functional-programming-in-java...
> At a glance it just feels super complex, academic
Agreed, because unfortunately, it is. (I might substitute "complex" with "hard" -- the ideas are actually very simple; understanding the big picture of how they fit together is hard)
> It's not at all clear why I should be thinking about my JavaScript algebraically at all times, or what the practical advantages are.
The main goal is to be able to write more and more code as pure functions -- this is hopefully an accepted best practice: functions with minimal inputs and no tangle of global state/context are far easier to reason about, test, and with proper data design, reuse.
But you quickly run into an issue: how can I write pure, stateless functions when dealing with inherently stateful surroundings (IO, DOM, database, etc.). That's what all this category theory jargon is about.
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.
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]
https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti...
The short version is: don't stare at explanations trying to grok it. Start hacking and keep an eye out for patterns.
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.
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...
https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti...
If you want to understand monads, start hacking and watch for patterns.
> 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.
Yeah, and here's my take on why it looks like that:
First, the terminology is all borrowed from mathematics, hence the academic tone. People can debate on the merits of this; I think it makes more sense when you're making tools for folks who are already familiar with the usual notation, but e.g. if you're not dealing with people who are already accustomed to the way physisicts talk about things, "p" is probably not the best variable name for momentum, traditional as it may be.
The authors of that document seem to have gone even farther in that direction than the Haskell folks -- Setoid? really? It's just fing equals! even Haskell calls it Eq. At least they kept Ord.
Also, the design looks to be basically transliterated from Haskell. There's been no attempt to adapt it to either javascript's strengths or its weaknesses. For example: Conceptually a monoid is a special case of a category, but it's fiddly to abstract out the commonalities in Haskell because of the way the type system works. In javascript you could basically collapse the two, with id == empty and concat == compose. You might still want a blurb in there somewhere about the differences; not every category is a valid monoid, but there's no reason to have a whole separate hierarchy with different method names. * The whole TypeRep thing they talk about is a complication that is unnecessary in Haskell; having methods that aren't attached to an extant value is just a non-issue, because the compiler can figure out which one you mean based on the types.
The libraries were designed around Haskell, and they lose something in translation. One of the things that kept in that thread was why not build some experience using these patterns before writing a spec? I tend to agree.
The other thing is that it is a big pile of abstractions. Even when working in Haskell, though I am more or less familiar with all of the type classes on that chart, I've only really had call to use 9 of them. Including Eq(Setoid) and Ord. The abstractions can definitely get to be a bit much.
There is some real use for this stuff; here's one I find kindof shiny:
https://apfelmus.nfshost.com/articles/monoid-fingertree.html
...but I would say these abstractions are as applicable to day to day programming as the rest of computer science -- no more and no less.
I'm with you on the complexity allergy thing. Lately I've been doing some stuff in elm[1], and the simplicity has been a wonderful breath of fresh air coming from Haskell. I might recommend it if you're curious about functional programming. Some of the same ideas are sprinkled throughout the libraries; every time you see a function called "andThen," there's a monad lurking there, but because elm doesn't have type classes, you won't find anything called Monad. The flip side is you end up writing more boilerplate than you would in a language that can abstract these things away.
[1]: http://elm-lang.org/
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)`?
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.
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 to give the slightest fuck.
That's a seriously toxic attitude to have.
People are using monads and other FP concepts daily to simplify "day to day dev work" (here's an example [0].) The fact that it's more or less mainstream to write off a concept because it sounds "academic" is worryingly anti-intellectual in a profession that is allegedly based in analytical thinking.
> 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 are some in the linked github thread (which had to be reposted repeatedly until people actually stopped and read them, btw.) It's about being able to write DRY code that abstracts over not only promises, but anything else that forms a monad, like arrays, optional values, and so on.
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.
There's a page called "Monad (functional programming)" on Wikipedia https://en.wikipedia.org/wiki/Monad_(functional_programming) suggesting that the term "moand" or "moandic" is widely used and understood.
There's no page called "contextual function."
There's a page called "Orthogonality (programming)" on Wikipedia https://en.wikipedia.org/wiki/Orthogonality_(programming) also suggesting that the term "orthogonal" is widely used and understood.
The page for "Unrelated" is about a movie.
There's a page called "Immutable Object" on Wikipedia https://en.wikipedia.org/wiki/Immutable_object suggesting that the term "immutable" is widely used and understood.
"Fixed" and "constant" have distinctly different meanings from "immutable."
Wikipedia isn't really convincing to me. There's no page for contextual functions because it's not really new, exciting, unique, or notable. I feel the same if you call that "monads". I can implement them in decades old programming languages. Same for immutable. Existed long before anyone called it that. We used it without having to have some catchy moniker that nobody understood outside the family.
Basically, I want to stop alienating project managers, product managers, and customers with weird jargon.
The things you might need jargon for are things that they shouldn't have to concern themselves with. If you use more familiar words but arrange them in unfamiliar ways, you'll cause the same confusion as by using jargon, except someone might believe they understood when they really didn't.
If you feel like you need to refer to programming concepts when talking to non-technical people, you're doing it wrong. Instead of talking about "immutable"/"constant"/"fixed", say that you made changes to prevent data from being altered accidentally. That's something they care about, not how exactly you did it.
Sure, but they become terms in titles of change requests, features, bug fixes, etc. It leaks out whether I want it to or not. And customers ask "what does this mean?" Or sometimes, forgivable but less polite equivalents.
It sounds like you probably already know this, but "fixed" and "constant" usually refer to concepts very distinct from "immutable". And "contextual function" would confuse everyone. (A monad isn't a function, and certainly not one influenced by some outer context). Similarly, "orthogonal" and "unrelated" aren't synonyms. (X and Y axes are orthogonal, but they're often related. That's why we plot things).
In every field, there will be people who over-use technical terms for status signaling. But those terms usually exist for a reason beyond that, and avoiding them as a sort of counter-signaling doesn't help anyone. It's just playing the other side of that game.
Usually the common term means the same things as a lot of things…that's both why they're common, and why they're less useful in a technical context.
Some other examples that come to mind are "electricity" (current, voltage, power…?); "size" (area, volume, mass…?). Just because an engineer or physicist might talk about volume doesn't mean you have to be a physicist to talk about it too. It also doesn't mean that, not being a physicist, the familiar word "size" means the same thing they're talking about.
Really:
> @pufuwozu can you show with a concrete example why you can't write the example code you posted with promises?
Why couldn't him just give a concrete example of what he was claiming that was impossible?
Anyway this was a nice thread to follow while it happened.
IMO the next big thing will be Observables.
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. :)
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.
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.
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.
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.
You can handle asynchronous code in JS in four ways: callbacks, Promises, generators, and async/await. In the former two, errors are dealt with in a non try-catch way, to the programmer, because either you pass the error as the first callback parameter, or the VM handles error passing for you and you deal with it in a catch block. The latter two you must wrap code that may fail in a try-catch block (or just not handle the exception). You can stick with callbacks, but it's generally easier to read well written Promises, and in a lot of cases async/await make it even clearer. The only time that it can be confusing or difficult is if you want to do multiple await calls simultaneously.