1.2 What is Contextual Programming?

It's About 'When'

In the last section, paradigms were described as a "way of thinking". Contextual Programming is intended to help a programmer think more on 'when' data will be changed instead of 'how' it will be changed (Imperative Programming) or 'what' will be done to change it (Declarative Programming). A programmer will still need to define the 'what' and 'how', but when practicing Contextual Programming those concerns are not at the forefront of the programmer's mind.

More specifically, when practicing Contextual Programming, data take the form of contexts. Contexts can be evaluated by operations which manipulate the contexts per some logic when the contexts qualify per some condition(s). Behaviors can encapsulate operations, grouping them together and permitting reactive evaluation; that is, evaluation that occurs automatically when there is a specific change to the behavior's contexts. As with operations, contexts are only associated with a behavior if they qualify per some conditions.

Contexts that are associated with one another through their behaviors can be organized together as compositions. Given that which contexts qualify for which behaviors varies based on whether contexts qualify for the conditions of a behavior, a composition's contexts are temporal and very dynamic. Compositions with other specified contexts can be evaluated by operations, for which they must collectively qualify.

All of these constructs and their relationships lead to very flexible scenarios for when logic may occur, and it's this 'when' that a programmer will likely be focused on when practicing Contextual Programming.

If the above seems like a lot to take in right now, that's because it is. It's a rather condensed explanation of the paradigm and will be explained throughout the remainder of the book with practical examples. However, it's important to have this high-level explanation in mind to see the big picture as all of the smaller parts are discussed.

Building on the Analogy

In section 1.1, an analogy was given as a more real-life example of the differences between Imperative Programming and Declarative Programming. This analogy can be extended with the concept of Contextual Programming.

"What did you do to determine this truth?" the programmer asks.

"I counted the ducks." replies the person.

"How did you count them?"

"One at a time. I had considered mentally grouping them by 3s though, and then counting the groups and adding the remainder."

"When did you count them?"

"I updated my count as each duck landed in the pond."

As the person stated this, another two ducks landed in the pond while one waddled onto the shore. "There are now eight ducks in the pond." the person says.

"It appears you already understand programming paradigms. You declared to me what you did, described your imperative through how, and defined the context to specify when, so that I know it is a current truth." says the programmer.

To What End?

In a practical sense, by structuring a program based on 'when':

• The logic that guides the program can be more decoupled. Instead of explicitly stating what logic should occur next, thus coupling that logic to the current flow of logic, a programmer declares that some context(s) should be evaluated by whatever logic is qualified to evaluate it.

• Relationships between data constructs become temporal, based on when the data meet certain conditions. This makes some data-oriented concepts (e.g., data management and injection) that are traditionally difficult in other paradigms inherently supported.

• The state of data and its potential relationships/manipulations are already known with conditions for conflict being explicitly declared, so parallel programming can be inherently supported.

• Data that should be considered for behaviors (and thus, must persist outside of the current stack of operations) must be explicitly activated and explicitly deactivated. This is similar to manually allocating/deallocating memory but is a practical concept towards solving the programmer's problem instead of a new concern. In essence, this means that garbage collection or other means of memory management are not necessary as the programmer is already doing those tasks without realizing it.

• All data are manipulated through limited side effects that can be managed through reactive operations. This results in code that is conceptually consistent throughout its various uses across an application but with a security that is usually limited to more restrictive coding practices.

• Logical constructs can be named to the advantage of the programmer, since they usually aren't explicitly called elsewhere in code. This lessens the burden of making succinct but meaningful names, while enabling more self-documenting code.

In general, Contextual Programming is conceptually more applicable than other paradigms when developing highly dynamic and interactive applications; applications that maintain a lot of constantly changing (in parallel) data that demands specific responsive logic based on the current application state.