Overanalyzed

Active and Reactive programming

October 24, 2008 at 6:46 pm | In Technology | No Comments
by Chris Davenport

Imperative languages like C and java and just about everything else I use are very demanding. You use the languages to say things like “do that”, and it does. Deeply fulfilling for a type A personality, I’m sure.

But it lacks something. Other languages, like lisp, prolog, etc.. have different concepts. I don’t know the computer science term for it, I think it’s “functional”, versus “imperative”, where you define what you want to happen, but not when. I think I can get a handle on it if I think in terms of actions.

Active versus reactive. C programs are active, Lisp are reactive. One might wonder how a Lisp program gets anything done, since it’s not acting, just reacting. “This R2 unit’s got a bad motivator”. But really, Lisp reacts to you, to the program being loaded, all sorts of things are around to react to.

Computers, however, do both. At the low levels of hardware, you have a CPU that responds to a clock signal and loads and runs instructions. Reality, you see, is reactive, so we put a clock trigger on it so that it’s always reacting, thus appearing active.

But that’s not changing. Well, not much. CPUs now actually chill for a while if they find an instruction to do so. In the meantime, we have an active CPU that is running instructions, and we also have hundreds of signals for asynchronous events. Interrupts for user input, system status, device communication, timers, all sorts of asynchronous stuff happening. And it’s all treated like the exception to the rule. Generally, that’s handled with fakery. Instead of actually responding to the interrupt event, you just make note the event happened, then when your regular imperative train comes around, it’ll pick up and deal with it then. And you hope that the time you spend making note is so small that there’s no perceptible loss of responsiveness.

I find it odd that when you get down to writing a GUI application or game or basically anything beyond a number-cruncher, you end up creating a special thread to actively wait for events, ironically enough. What you end up losing there is the ability to respond to multiple events.

If you get a pretty good platform going, with a good understanding of Interrupt handling and events, then it’ll probably provide a way to make your event thread, or it’s own event thread, as is increasingly common, chill out until the event actually happens, so it doesn’t go Noober on you asking if the event happened yet. Unfortunately, you’re often stuck with just the one thread, so here we are again handling asynchronous events synchronously, to the detriment of all. God help you if that thread dies or gets locked up, confused, spammed, or otherwise too distracted by acting reactive to actually react.

Now we have system designers eager to throw extra CPU cores at us, and our imperative design methods and languages, and lesser extent platforms, make it hard to do anything with or even think about except as multiple chugging-along trains, still with just one track.

Now I’m not a fan, and I never learned it, but a language like Lisp or SmallTalk seems to get things mostly right on that front. All the events are written almost as closures, and there’s nothing stopping them from happening simultaneously. Very elegant, very distributable, very scalable, for event driven things. Computer Scientists and Mathematicians get to be very happy, because it’s a minor tweak to make the language provable. But for actions, well, it gets weird again. You end up having to react to actions like the act or begin command being issued.

Just so you don’t think I’ve gone 100 miles off the reservation, think about the last webserver app you wrote. Maybe it started just generating some pages, with a database backend, but was basically doing everything on-demand. Somewhere along the line, you probably had to create some kind of service or hack or application or something to do something that needs to happen when there ISN’T a web request driving it. Update your database, delete cookies from users who just wandered away half an hour ago, invoke the Enterprise Java Bean your user requested, whatever.

It’s likely that at that point you wrote a service. Joel Spolsky writes about a “service” in his web application that waits for a user to load a special “go do maintenance stuff” URL, and the maintainer has to sit there and refresh while the thing gets “maintained” until the page returns something different. Jeff Atwood writes about a clever hack used to schedule events to run later in the webserver, using special tricks to get it to run without a user request.

It’s also likely at this point you discovered you needed the context of your application outside the webserver, which is often the reason to attempt to develop it within the web server itself, conforming to the reactive framework.

Or maybe you web-enabled your application that used to just chug. So you have it stop chugging every 30 minutes and write a special file with it’s latest status or apply another clever trick so that when the webserver is asked, it can pretend to actively generate the answer, conforming to the chug-along framework.

Honestly, it seems to me that right answer is in between these two. Write up some stuff that chugs along doing whatever it is you want done, and some stuff that responds to things that happen, and get a nice interaction layer between the two.

Last time I did it, I wrote a webservice and an application that both used the same database. Web service would show users what’s up, make changes, whatever. System service would use that information to generate tasks. It wasn’t ideal, the two really couldn’t communicate well. It was almost, but not quite, Model-View-Controller, except I had one model with two viewcontrollers. Only leveraged part of the pattern. If I’d known better, I would have done more.

I don’t know of any languages that mix the concepts. Most pick one and hack the other in. Imperatives are more popular because they’re easier to understand, functionals because they’re easier to prove and generally hard to derail.