Asynchronous Life

Been thinking about asynchronous programming lately. When I’m learning something new and complicated–in this case, very complicated–I like to try to integrate the concepts with other concepts that I currently understand (or think I do).

So an asynchronous call is like email. You fire off your email and [then should] immediately continue on with your work. Certainly, when you get a response, you may well use it and do stuff with it, but until then, you can work on other things.

On the other hand, a synchronous call is like IM. When you’re in an IM conversation with someone, you are waiting on them to provide a response before you can continue.

I would say that communication using Twitter is asynchronous in nature, the number of API calls/minute has increased to the point where we can choose to “block the caller” (stare at Tweetdeck) until a response is received.


Off-topic: I really think threads should not be abstracted away when doing concurrent programming. How else does one explain the difference between synchronous and asynchronous programming? Threading and multiple call stacks should actually be the conceptual foundation upon which we learn about and understand programming and program execution.

It is key to understand an executing program as a running process and not as something that persists by itself through time. I’ll probably write a post about this and end up incorporating my full-blown process ontology into it. (Why did that last clause sound so dirty?)

Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: