Event based versus Data based Programming

 

Over the years our landscapes have significantly changed, shifting from monolithic to client server to now cloud based microservices architectures : 

Along the shift to cloud based microservices, programming styles have also changed and in this short blog I will focus a bit on programming paradigms by discussing: Event based versus Data based Programming

When I started programming in the mid-1980, only a small number of so-called “programming paradigms” where available – most notably imperative languages [1] or better procedural / functional languages like C++ developed around 1980 as well as Modula and Ada.  For me the work that Bjarne Stroustrup did related to programming was hugely influential – his book “The C++ Programming Language” issue in 1985 was in of my first IT books and it was the start of my IT career.

Today, 30 years later, there are between 25 and 30 different programming paradigms. Everything from “action” and “agent oriented” to “symbolic” and “Value-level” and there are two that are quite important today: Event based, and Data based programming.

One of the main paradigms that is fairly well known and used is event-based programming (EBP); in EBP we develop code that includes pre-defined business logic that follows a certain predefined flow of events – first “do A”, then “B” and then “C” if “X=1” else “do D”. It is how many of us learned to programme / code. The logic is easy to learn and there are many programming languages that supports this paradigm.

One key drawback is, however, the fact that when the sequence of events changes, the logic has to be modified. The only way to modify the sequence of events is to modify the code. And this can be time and cost consuming. You will have to start a project including finding the budget to pay for the changes. You will have to design the changes, develop the code changes, test them and implement the change. All of this can take days or weeks and will cost time and money.

A different approach to programming is to use a data driven programming paradigm. With data driven programming the flow is in the data that is provided; the code does not contain any business logic and instead the flow is controlled by the data. awk and sed are two good example of data driven programming. Both use the parameter you provide as the data as well as the instruction of what to do with that data. The advantage of data driven programming is that if the business logic change all you need to do is to change the data you are providing to awk or sed.

Nothing is perfect, and also data driven programming has some implications. Most notably data driven programming can lead to more complex setups, as you are combining data “payload” and event instructions. In other words, the data you provide is the “real” data – like first name or postcode – and the instructions what to do with that “real” data like – “-i -d”.” /f=2” – meaning to insert the name spilt by “.” with an error handle f2. Again, awk and sed are good examples.

Whilst data driven programming has also been around for a long time (awk and sed is a UNIX based command) most applications developed are using event based. But there are more and more requests to investigate data driven programming/architectures. As mentioned before, data driven programming can be more complex. However, designed properly complexity can be reduced and for certain areas data driven programming might be more beneficial.

Thanks for Reading