And somehow all these programmers who never care about performance because “computers are fast” become micro-optimizers, willing to restructure every line of code to save a few KB of RAM and rare handful of ms for a context switch.
If you’re talking about the course where you write a linked list, hash table, quick sort, etc. That’s pretty basic and fundamental stuff. And I don’t know why you would like programming.
If you’re talking about the course where you prove the runtime of an algorithm using mathematical induction techniques, well that’s more of interest to mathematicians and researchers. Learn what you can, know where to look back if needed, but it’s ok.
> you disable every single button that allows the user to do something else before the previous operation completes.
Wow you mean the whole program becomes unresponsive? Crazy!
To address your main point, yes, scrolling, hover, etc can continue to work. But now you genuinely have two things your program is doing at once, and these must be coordinated.
A gui framework typically handles this, with a separate thread (or separate OS process). So your thread that responds to events can block while the render/refresh continues doing its thing.
With this design the problem goes away. Instead of writing code that disables the ui, issues a callback, waits to respond, you just literally write:
If (!file.delete()) {
Showerror()
}
This is the kind of code you can read, and put breakpoints on.
Hang implies there is something you are not responding to.
Let me ask again. What are you imagining your main thread should be doing while it is waiting for essential data?
responding to new inputs means changing state. But your program is already in another. Two separate program execution states are best described by two separate threads.
> crash
Crash early, crash often. If invariants can’t be maintained, don’t pretend otherwise.
What is your program going to work on while it waits for the task? Usually nothing. You need to read some data before analyzing it, etc.
While you wait the OS can switch to other threads.
The only question here is whether you want to return that time to the operating system or to your language runtime.
> they’re just hiding the complexity
async/await feels helpful because you can write normal code again! If else, for loops, etc.
Oh wait that’s also what the UNIX operating system does. It abstracts away all this blocking and context switching so you can write normal code.
> If adding async to a function is too much
The authors point is a good one. You essentially have two languages and classes of functions. The regular version and the async version. Lots of duplication and a tendency for everything to become async.