Explaining asynchronous programming and Coroutines — Lesson 1: Routines

P.S. This was first posted on Medium, so be sure to check out the original article!

Some programming concepts are truly hard. Or at least they are at first glance. When thinking about how code is compiled and programs are executed, human mind can easily comprehend sequential like computing. But in reality, nothing bar the simplest of programs manifests in a single-threaded environment, at least in mobile applications.

However, when we start learning asynchronous programming, just by the very fact that we’re not used to things happening sometimes in the future, unexpected, we suffer tremendous cognitive load.

Which is why I’ve taken up writing this series, in hopes that terms like routines, continuations, computation, coroutines and many more, will be brought closer to you, by simple, everyday examples.

Routines

Merely delving into code wouldn’t yield much result, as it’s better to understand the foundation of asynchronous programming and why it’s paramount to all forms of software.

We’ll start off by learning what Routines are. Think of your day-to-day life. Even if you’re not a creature of habit, you’re subject to some form of a routine. You get up at a certain hour most days, either have breakfast, with your favourite beverage, or skip breakfast at all (which is bad!). Then you proceed to your daily chores, job, school or some other form of activity to fill your day.

Analysing that morning, it’s pretty much a routine. It’s something that has a beginning and something that eventually ends. In this case it starts by waking up and ends by moving on to some more important activity.

Just like in life, computer programming has it’s own routines. Mostly they start by opening an application or running a program, and end by closing the app or when the program finishes. For the sake of optimism, we’ll stick to the happy paths in this lesson.

Each routine, or more specifically subroutine, as such represents a unit which is being executed. It can be accessed through multiple points in code (for example a function can be called at different places) but it always finishes with a return statement, and it can produce a value or some side effects.

Inside the subroutine the program execution changes it’s context, this is often called scoping in programming. By accessing a different context or scope you gain access to whatever is available in that scope, but it becomes unusable once you leave.

Another thing about subroutines is that they’re computed and processed sequentially and they block further instructions until the current subroutine is done.

Looking at the morning analogy, when you start waking up, you can’t do anything else until you wake up. Waking up would be a blocking routine, which when done proceeds with another task. It can be accessed from multiple points (as you can fall asleep anywhere), and when in the waking up routine, you have access to your surroundings, or the context, such as your current bed and the annoying alarm.

Routine family tree

Just like a program or a process has to be started from another process, and it can start other processes, so can a routine, once started by another routine, generally the main program, start other routines.

Once again, tracing back to the breakfast routine, when you start to make breakfast it’s actually a bigger routine composed of smaller ones. You first have to start a routine in which you make toast. First grab a couple slices of toast. Then you proceed to put some butter on it and finally you finish the toast-making-routine by putting everything in a toaster.

Describing the entire process of eating the said toast would be a bit tiresome, but you probably get analogy. In computer science the morning routine would be called a parent routine whereas it’s individual, smaller, routines like breakfast, hygiene and putting on clothes are called child routines.Furthermore, each of the child routines can have it’s own children, creating a family-tree-like structure.

Conclusion

Subroutines as such are powerful in programming, as they allow you to wrap common behaviour into neat units of execution, which can then be called anytime, and as much as it’s needed. These constructs are mostly called functions, procedures or methods in general.

However, due to limits, like the aforementioned blocking, they are not used for heavy tasks or computation because it may cause the program to stop for an indefinite period of time. This is where asynchronous programming comes handy, but we’ll see what it’s composed of in the next lessons.

Where to go from here

Marin Benčević and I have started a Computer Science publication on Medium, so if you’ve got any interesting ideas on what we could cover in the future, or have any proposals for articles yourself, be sure to mention it in the comments below, or contact us on Twitter.

And stay tuned for the rest of the series on asynchronous programming, computation and coroutines! :]