Article Preview

COLUMN

Asynchronous Programming

Getting your mind out of sequence

Issue: 8.6 (September/October 2010)
Author: Marc Zeedar
Author Bio: Marc taught himself programming in high school when he bought his first computer but had no money for software. He's had fun learning ever since.
Article Description: No description available.
Article Length (in bytes): 15,940
Starting Page Number: 71
Article Number: 8610
Resource File(s):

8610.zip Updated: 2010-09-02 08:14:41

Related Link(s): None

Excerpt of article text...

If you're an old school programmer like me (I dabbled in high school in the 1980s), you probably learned to program in a sequential fashion. The switch to event-driven programming, like on GUI systems, was no doubt a tough transition. Event-driven programming is naturally asynchronous in that your program isn't running through a list of steps but waiting for events to trigger actions. Asynchronous programming is confusing.

Sequential programming, or batch programming, is simpler to understand. It's just a series of steps, one after the other. When you add branches for conditionals (if-then-else decisions), you might need a flowchart to diagram the whole mess, but there's still an obvious flow to follow.

An event-driven program is much harder to diagram. By definition, a event-driven program does virtually nothing out of the box. It's just sitting there, waiting for something to happen -- even if that's just as simple as the user clicking a button. If there is a choice of buttons, then each of those choices can lead down a different path. For instance, one choice could create a new document, and within that document all sorts of new options are available, such as the ability to add or modify content. But the program is always at the mercy of the user, who is driving it.

...End of Excerpt. Please purchase the magazine to read the full article.