The city of New York has issued a 3 cents value stamp for its 300 anniversary, I am not in the stamp printing business, and wonder how long stamps will survive, but the blogger tool tells me that this is my 300 posting on this blog, in almost two years. Since recently I am dealing in languages, today I'll share some thoughts about declarative programming and its implications on event processing. John Bates told in his DEBS keynote about his experience, in the assumptions they had when developing Apama in the lab, and how these assumptions were slightly changed when got out of the lab. This is a phenomenon that I know well from a few times over my life that I have been involved with getting ideas from the lab to reality. Of course, the closer that your assumptions made in the lab are to reality, the faster time-to-market you have, and better success probability. Among the opinions that I used to hold is that declarative programming is always superior on imperative programming, in imperative programming, people need to work difficult needlessly, while in declarative programming, programming is more elegant and easier. I did not really changed my mind, however, reality shows that its ain't that clear cut. Getting to a neighboring area, it is well known half-secret in the business rules industry, that while all BRMS products support RETE style declarative inference rules, most users prefer to use a more imperative looking "sequential rules; I think that the reason is that in inference rules the flow is hidden, each rule is defined individually, and the flow is derived from the fact that some rule derives some fact, and some other rule has such a fact in its conditions, but this makes all the programming as "programming in the small", and the "programming in the large", controlling on how various rules relate to each other, does not exist in this programming style. It turns out that it is important for users to have visibility, and even control on the programming in the large aspects. Coming back to event processing, I believe in a combination of declarative programming for the programming in the small, i.e. to define any individual event processing agent, and making the programming in the large, i.e. the event processing network, explicit. This is not really an imperative model, since the EPN can be implemented in various ways, but it is not pure declarative either. We see that this type of programming model is getting traction.I'll discuss the various dimensions of event processing languages in depth, in further postings - stay tuned.
Here is a picture I got recently from Matty Cooper, from EventZero, who made all the way from Australia to Nashville to attend DEBS 2009. This picture was taken during the event processing language tutorial
