Paul Vincent has written in a recent Blog about "manual event processing". The example brought is certainly an event processing, there are many examples of event processing -- everytime that somebody calls and I pick up the phone, it is event processing, or if I am in a middle of a meeting, looking at the screen of my cellphone and decides not to take the call - it is also an event processing. In fact, manually we are doing a lot of event processing, and this is something very typical to human behavior. However, the programming paradigms that have been constructed, did not really intend to model the human behavior, and programming was developed, starting from Assembly languages and upward, in the assumption that we are first put values into - registers, variables, buffers, databases etc - and later when we wish to do something specific we retrieve it from wherever it is and use these values. Events in old programming languages such as PL/1 (my programming mother tongue) where used to handle exceptions. We have discovered the usefulness of teaching information systems how to process events only at a later phase -- first, by using (or abusing) regular programming to process events, and recently by various COTS that help process events -- however, the tools used are still rooted in the "store and then process" world -- SQL, business rules, scripts -- are all part of the traditional programming paradigm.
This is similar, in a sense, to do word processing using a typewriter --- we still need to invent event processing tools whose primary programming paradigm will be based on event processing as a major set of abstractions - and not as implemented on top of programming paradigm that don't match ---- well, still a lot to do on this --- more later.