Guido van Rossum

If you have two different pieces of code that are sort of being executed simultaneously, whether it's using the parallel or the concurrent approach, if like...

A is the number of fishermen and B is the number of programmers.

But in another part of the code, A is the number of mermaids and B is the number of mermen.

And somehow that's the same variable.

If you do it sequentially, if first you do your mermaid merpeople computation and then you do your people in the boat computation, it doesn't matter that the variables are called A and B and that is literally the same variable because you're done with one use of that variable.

But when you mix them together, suddenly...

the number of merpeople replaces the number of fishermen, and your computation goes dramatically wrong.

And you think you're smart, and you'll put a lock around it, and in practice, in terms of bugs per 1,000 lines of code, this is an area where everything is worse.

Something like that.

That's not a bad idea because if you're sort of...

If you're baking cakes and you have multiple people all baking cakes, but there's only one oven, then maybe you can tell that the oven is in use, but maybe it's preheating.

And so maybe you make a sign that says oven in use and you flip the sign over and it says oven is free when you're done baking your cake.

That's a lock.

And what do you do when you have two ovens or maybe you have 10 ovens?

You can put a separate sign on each oven or maybe you can sort of someone who comes in wants to see at a glance and maybe there's an electronic sign that says there are still five ovens available.

Or maybe there are already three people waiting for an oven so you can't...

If you see an oven that's not in use, it's already reserved for someone else who got in line first.

And that's sort of what the restaurant metaphor was trying to explain.

Wow, yeah.

So we had this really old library for doing things