Functional Programmers Hate Events

Q. Even birthday parties?

A. Especially birthday parties!

I had an interesting mailing list conversation about Closure Passing vs. Events in async programming a few days ago. Yesterday I ran across a post from Michael Giagnocavo that had a similar theme.  I don’t necessarily disagree with him.  I just don’t agree with his assertion that event-based asynchronous programming is inherently flawed.

I should just say this: I hate asynchronous programming period.  I. Hate. It. With. A. Burning. Passion.  But, just about every project I’ve worked on in the last three years has been thread heavy.

So I decided to get over it.

I thought to myself:

At some point I came across the Event-based Asynchronous Pattern and decided to create a small library that allows you to wrap asynchronous operations in an EAP shell.

Michael’s example implemented with Migo would look something like this:

public static void Main ()
{
    tg = new TaskGroup (1);

    HttpFileDownloadTask t1 = new HttpFileDownloadTask (
        "Task 1",
        "http://michaelcurbanski.com/mcu/taskwon.txt",
        Path.Combine (home, "taskwon_res.txt"),
        new object ()
    );

    t1.Completed += TaskCompletedHandler;

    tg.Add (t1);

    are.WaitOne ();
}

private static void TaskCompletedHandler (object sender, TaskCompletedEventArgs e)
{
    HttpFileDownloadTask t = sender as HttpFileDownloadTask;

    try {
        if (e.Error != null) {
            throw e.Error;  // reduces loc count, bad otherwise
        }

        using (StreamReader sr = new StreamReader (t.LocalPath)) {
            string res = sr.ReadToEnd ();

            Console.WriteLine ("Result:\n{0}", res);

            if (t.UserState != null) {
                HttpFileDownloadTask t2 = new HttpFileDownloadTask (
                    "Task 2", res, Path.Combine (home, "tasktoo_res.txt"), null
                );                            

                t2.Completed += TaskCompletedHandler;

                tg.Add (t2);
            } else {
                are.Set ();
            }
        }
    } catch (Exception ex) { DumpException (ex); are.Set (); }
}

Output:

Result:
http://michaelcurbanski.com/mcu/tasktoo.txt

Result:
                     _ _
              _     //` `\
          _,-"\%   // /``\`\
     ~^~ >__^  |% // /  } `\`\
            )  )%// / }  } }`\`\
           /  (%/'/.\_/\_/\_/\`/
          (    '         `-._`
           \   ,     (  \   _`-.__.-;%>
          /_`\ \      `\ \." `-..-'`
         ``` /_/`"-=-'`/_/
            ```       ```

Code here.

Events don’t necessarily make async code tragically unreadable! Granted, functional code is usually more aesthetically pleasing than its event-based counterpart in trivial cases.

But that’s a very simple example, Migo makes it super easy to do a few of the mundane but necessary async grunt tasks such as:

Limiting the number of concurrent operations, getting aggregate task status reports (e.g. the number of tasks currently running, overall progress, transfer rate, explosions per minute, etc), reordering tasks, etc.

I hacked together a small sample app to test some of the more interesting changes that I made while updating Migo this summer.

It’s pretty much worthless if you’re not watching the full-screen HD version.

OGG here.

You can do a lot with a little using the EAP!  The code needed to support the icon and other file downloads as part of the Migo EAP weighs in at ~100 LOC, and took about 1/2 hour to write.

I haven’t had time to document it yet, for the moment I’ll have to ask you to RTFS.

The fact that it uses the EAP, and by it’s very nature makes use of events, doesn’t necessarily make it any more or less complex.

Closure passing isn’t going to make your complicated async code inherently better and events aren’t going to make it inherently worse.  Functional code has way more sex in the syntax and underlying implementation, but, it all comes down to what you do with it.

Personally I use both. The ironist in me (i.e. the wishy washy, unemployable, dabbler) just can’t take an argument for or against either very seriously.  Most of the time they’re just too similar, both equally flawed.

I can’t wait to see what we have in 15 years.