Asynchronous Functions

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Douglas: So an alternative to all of that are Asynchronous functions. Asynchronous function,s return immediately. You call it, it comes right back. There's almost no passage of time. And success or failure will be determined somehow in the future when the Asynchronous function returns. There is no solution yet. The solution might happen maybe later but not now.

[00:00:28]
So we like to use Asynchronous functions in Turn systems. A Turn is started by an external event, such as delivery of a message, or a completion of an asynchronous request, a user action, or the ticking of the clock. That a callback function associated with that event is called and it runs to completion.

[00:00:47]
It doesn't have to worry about races because nothing else will get to run until it's finished. When it returns, the turn ends. So there's no need for threads, no races, no deadlocks. It's a very reliable, very straightforward programming model. We call it turns because of games that comes from chess.

[00:01:04]
That in chess when it's my turn, I get to control the piece. You don't get to touch any pieces until my turn is done and then it exchanges. We're doing a similar thing with functions and events. But when you're using turns it requires that you have to follow the iron Law of Turns which says you must Never block.

[00:01:25]
You must Never wait. You must Finish fast. If you have any code which can't, which has to block or has to wait or can't Finish quickly. It has to be isolated and run in a separate process. It is not allowed to run in the Turn system. So that's a cost right.

[00:01:41]
It means, you're allowed to run some code but there's some code which you're definitely not allowed to run. We usually do this in an Event Loop. Event loops are Turn based systems. And they come with Pros and Cons. The Pro is a huge Pro. It is Completely free of races and deadlocks.

[00:01:59]
And that's a huge advantage. Any system that applications should never be written. I think in systems that use threads because it's just too hard to reason about them and it's too unreliable. Another Pro is that there is Only one stack and we reuse that stack on every Turn.

[00:02:18]
So it's extremely memory efficient which is of no interest at all. Again, because memory is so cheap. The fact that we're memory efficient is irrelevant. What's more important is that it is Very low overhead. Because all we're doing in the Event Loop is take something off an Event queue, hand it to a function, let it run take the next one so on.

[00:02:38]
So there's very little overhead. Whereas in a threaded system, you're doing lots of locking, you're doing lots of process switching, and context switching. Which are the most expensive things at CPU know how to do. In a term base system, you're not doing that you're just pull something off the queue and running it, pulling it and running it.

[00:02:55]
It's also a surprisingly Resilient programming model. If a Turn fails, it's usually the case that the program can still go on. For example, if you ever take any web browser and open up the debugger and just go wading out into the Web. You're gonna see for almost a constant string of failures.

[00:03:15]
It's amazing how much failure is going on in web pages all the time. But if you don't have a debugger open, you don't see it. Now, in a threaded environment when one of those, when something fails, then there'll be an exception in one of the stocks in one of the threads will get on wound and it'll try to recover.

[00:03:35]
But that thread may now be in an inconsistent state compared to the other threads because it's lost all of this context. And so, that could lead to cascading thread failures. And so, it tends to be a fairly brittle model. Whereas, what we see in web browsers is as long as there is any button that still works and the user can find it.

[00:03:53]
There's a good chance they're going to be able to complete the transaction and never know that the thing has been failing hugely behind the scenes. Now, there's some important cons here. The most important con is that Programs must never block commit turns must finish quickly that we have to obey the law of turns, that is definitely a con but it's something that has to be respected.

[00:04:16]
Also, another con is that Programs are written inside out and that makes some people cry. They call it, it's inversion of control. It's unnatural, it's an unrealistic way to write programs which we can't do it's too hard and [SOUND]. But actually it turns out it's not hard. It's actually pretty easy.

[00:04:38]
So we do things in Event driven systems, they're Turned based, there's No pre-emption which is really good that makes them very reliable. We associate Events with actions. And it turns out, despite the people who are complaining that it's very hard inside out and unnatural. It's actually very Easy and in fact beginners can do it.

[00:04:55]
It's actually very hard. And in fact, it's how all user interfaces are implemented even on systems that have threading. Because it just turns out this is the best way to implement a User interface. Threading has Event loops and Asynchronous programming has a long history. It was done in real time systems, in experimental systems and game systems for a long time.

[00:05:23]
It doesn't get into the mainstream until the Macintosh. Macintosh is the first consumer device although it's kind of expensive for a consumer device. Which is programmable only in a Turn based manner. Prior to that, everything has been using blocking IO going all the way back to 4chan. And our memory of this is that when Apple introduced, and Steve Jobs introduced the Macintosh in 1984.

[00:05:51]
It changed the world, and turned Apple into one of the world's most successful companies. And that's not actually what happened. This machine came very close to bankrupting Apple. And part of the reason was that they couldn't sell very many and the reason for that was that they couldn't convince programmers to write programs for this machine.

[00:06:12]
Because they'd never seen an Event Loop before and didn't understand how to write programs in that model. And they were complaining it's unnatural, it's too hard, it's inside out, [SOUND], we're not gonna do it. Instead, they wrote for MS DOS. Which was horrible and crappy. One of the worst things ever imagined which outsold this by several orders.

[00:06:35]
It was just ridiculous. So the thing that changed this, which turned this machine into a success, was HyperCard. HyperCard was a system that was built by Bill Atkinson. Bill Atkinson had written, QuickDraw, which was the graphics layer of the original Macintosh. He also wrote the first paint program called, MacPaint.

[00:06:58]
It's hard today to recognize it as a paint program because it only had two colors black and white. But it was a very it came free with a machine and when you bought a Macintosh that was literally all there was to do with it. And so, people did a lot of stuff with that painting called it art.

[00:07:17]
His next program was HyperCard. He took MacPaint and allowed it to work on several pictures at the same time, only one of which would be visible. He called these pictures cards and that a file was a stack of cards or a stack. And then, he got the idea that he could put buttons on the cards and wire those buttons to behavior and put fields on those cards and allow those fields to contain text.

[00:07:41]
Which he could then search for and process on. And then, he added an Event driven programming language to that called HyperTalk. Which was an Event driven programming language. Everything in it was events and you would say things like, on key up, on mouse down and so on, and beginners loved HyperCard.

[00:08:08]
They got all into a HyperCard. They were writing stuff. They'd start with very simple little Event handlers and then start doing stuff that was much more sophisticated. Inventing whole new classes of applications that all ran into HyperCard. There were predictions that HyperCard was going to be the future of software development.

[00:08:26]
And it might have, had Apple not run it into the ground. Atkinson originally demanded of Steve Jobs that it be distributed for free with Macintoshes. And Jobs agreed, and that's how they did it for several years. Once they saw how successful it was, they decided we need to figure out how to monetize this.

[00:08:46]
And in the process of doing that they killed it to death. But it worked and it inspired stuff that happened in the browser. In fact, you see that home thing that the comps concept of the home page came out of HyperCard