Coroutines make robot code easy

Coroutines are covered in Knuth's first volume. And, I confess, I think I went years thinking he was just describing method calls. Yes, they were method calls that had state attached, but that felt essentially like attaching the method to an object and calling it a day.

Seeing them make an odd resurgence in recent years has been awkward. I'm not entirely clear that they make things much more readable than alternatives. Reminds me of thinking continuations were amazing, when I saw some demos. Than I saw some attempts at using them in anger, and that rarely worked out that well.

Also to the point of the article, I love being "that guy" that points out that LISP having a very easy "code as data" path makes the concerns expressed over the "command" system basically go away. You can keep the code as, essentially:

    (DriveForward 0.5 48)
    (while (NotCarryingBall)
        (Grab)
        (pause 2)) 
    (DriveBackward -0.5 48)
    (Shoot)

With god knows how much bike shedding around how you want to write the loop there.

Of course, you could go further for the "pretty" code that you want by using conditions/restarts such that you could have:

    (DriveForward 0.5 48)
    (Grab)
    (DriveBackward -0.5 48)
    (Shoot)

And then show what happens if "Grab" is unsuccessful and define a restart that is basically "sleep, then try again." Could start plugging in new restart ideas such as "turn a little, then try again." All without changing that core loop.

In a world where most programming languages have async/await style abstractions this stuff is pretty applicable IMO

> I think the way to go is to have a queue of events/inputs and use that because the ordering and debugging is much better and you don't get the same web of jumping to different parts of the execution.

If you just have stream of events that need to be decided upon in order you're in a very happy place; complexity strikes when you want to run handlers for them in parallel to cut on latency, and those handles also need to do multiple things that can be done asynchronously to cut on latency.

Message passing works well here, you can just send a bunch of requests to various components then just wait for each at the moment they are needed; async/await is essentially a very bastardised version of it (and usually stuck in single thread in most implementations so no parallel computing)

Python is slated to become a choice for the 2024 season: https://wpilib.org/blog/bringing-python-to-frc

The coroutine approach shines for complex business-logic.

Consider this example algorithm, of several async steps,

1. Download a file into memory

2. Email a link to a review web page.

3. Wait for the user to review.

4. Upload the file to a partner.

5. Update a database.

You could implement this as callbacks. Callback from each step leads to the next being triggered. Downside - your business logic is spread across all the callbacks. You could mitigate this somewhat by defining a class with one method for each step, with those methods being defined in the same visual order as the algorithm. Then have each callbacks call a method. (The article shows something different but similar with its Command autoCommand pattern.)

Tricks like this only go so far. Imagine if the reviewer user had a choice of pressing 'approve' or 'reject' on the webserver interface, with the algorithm changing depending on their answer. How do you now represent the business logic so the programmer can follow it?

Such changes are easy in coroutines. Here is the algorithm with that variation in coroutine code,

    async def review(review_id, url):
      file_content = await download_large_file(url, review_id)
      ws_review_id = await create_webserver_review_page(file_content)
      await email_the_user(ws_review_id)
      result = await get_webserver_user_response(ws_review_id)
      if result: 
        await upload_to_partner(file_content)
      else:
        await alert_failure(review_id, file_content)
      await update_database(review_id, ws_review_id, result)

You state that callback code gives you easy visibility to what actually happens - yes, they do. When you read callback code, it is natural to follow business-logic to system calls. Coroutine tends towards code of layered business-logic and abstraction.