Whether it's threads or async functions, my experience is that people generally suck at asynchronous programming. They're not very good at conceptualizing it, understanding and predicting race...
Whether it's threads or async functions, my experience is that people generally suck at asynchronous programming. They're not very good at conceptualizing it, understanding and predicting race conditions, and mitigating issues ahead of time.
It's kryptonite for many programmers. Though to be fair, those same programmers frequently do well with pointers which is a subject that still throws me off and I'm glad I don't have to deal with. Everyone has their strengths.
Here's a quick rundown: You're a manager at a store. Sometimes you need to have an employee grab something for you, in which case you need to wait for them to return. At other times you just need...
Exemplary
Here's a quick rundown:
You're a manager at a store. Sometimes you need to have an employee grab something for you, in which case you need to wait for them to return. At other times you just need to send them off to work on a task and you don't really need to wait around for them, that way you can head off somewhere else and do your own thing. These are referred to as "synchronous/sync" and "asynchronous/async" processes, respectively.
Sometimes, however, it gets complicated. Sometimes you want to ask employee A to grab something for you, but employee A starts to grab it and realizes that they need to have employee B go off and do their own thing first before that thing you wanted can be retrieved (e.g. maybe employee B needs to move a bunch of pallets out of the way of the door employee A needs to get into), which could take any amount of time and employee A can't just wait around doing no work at all but you're an impatient manager and don't want employee A to just come back to you empty-handed after making you wait that whole time.
There are ways of resolving this dilemma, but they can be pretty ugly. Your store has started putting new processes in place to try to handle this problem better, too, but it's kind of hacky and is really just the same thing as before but it's hidden behind a few extra procedures tacked onto the mess. Some stores have better processes in place for this kind of thing, like a paging system where the employees and manager can easily keep in touch and get each others' attention when needed, or the manager telling employee A "if you have to wait for a bit, that's perfectly fine" so employee A doesn't feel pressured to come back immediately.
JavaScript is the store you're managing.
(It's not really a perfect analogy, but I'm tired and this is the best I could come up with in a short amount of time.)
It's great analogy, don't sell yourself short. It's not a one-to-one representation, but it tells the story enough to make people understand, and that's all analogies are really for.
It's great analogy, don't sell yourself short. It's not a one-to-one representation, but it tells the story enough to make people understand, and that's all analogies are really for.
Whether it's threads or async functions, my experience is that people generally suck at asynchronous programming. They're not very good at conceptualizing it, understanding and predicting race conditions, and mitigating issues ahead of time.
It's kryptonite for many programmers. Though to be fair, those same programmers frequently do well with pointers which is a subject that still throws me off and I'm glad I don't have to deal with. Everyone has their strengths.
Can someone ELI5 what is going on here?
Here's a quick rundown:
You're a manager at a store. Sometimes you need to have an employee grab something for you, in which case you need to wait for them to return. At other times you just need to send them off to work on a task and you don't really need to wait around for them, that way you can head off somewhere else and do your own thing. These are referred to as "synchronous/sync" and "asynchronous/async" processes, respectively.
Sometimes, however, it gets complicated. Sometimes you want to ask employee A to grab something for you, but employee A starts to grab it and realizes that they need to have employee B go off and do their own thing first before that thing you wanted can be retrieved (e.g. maybe employee B needs to move a bunch of pallets out of the way of the door employee A needs to get into), which could take any amount of time and employee A can't just wait around doing no work at all but you're an impatient manager and don't want employee A to just come back to you empty-handed after making you wait that whole time.
There are ways of resolving this dilemma, but they can be pretty ugly. Your store has started putting new processes in place to try to handle this problem better, too, but it's kind of hacky and is really just the same thing as before but it's hidden behind a few extra procedures tacked onto the mess. Some stores have better processes in place for this kind of thing, like a paging system where the employees and manager can easily keep in touch and get each others' attention when needed, or the manager telling employee A "if you have to wait for a bit, that's perfectly fine" so employee A doesn't feel pressured to come back immediately.
JavaScript is the store you're managing.
(It's not really a perfect analogy, but I'm tired and this is the best I could come up with in a short amount of time.)
It's great analogy, don't sell yourself short. It's not a one-to-one representation, but it tells the story enough to make people understand, and that's all analogies are really for.