Reactive Programming Treats Variables Differently than Imperative Programming - Montana Webmaster

Reactive Programming Treats Variables Differently than Imperative Programming

“… in an imperative programming setting, a := b + c would mean that a is being assigned the result of b + c in the instant the expression is evaluated, and later, the values of b and c can be changed with no effect on the value of a. On the other hand, in reactive programming, the value of a is automatically updated whenever the values of b or c change, without the program having to re-execute the statement a := b + c to determine the presently assigned value of a.”
~ Wikipedia

This idea feels an awful lot like passing by reference, instead of passing by value. Are we going back to C? I asked this question on And, the answer will lead to further discussion, “Reactive programming doesn’t pass data by reference, in the contrary it is an anti-pattern in Functional Reactive Programing.The reason why the value of a is automatically updated whenever the values of b or c change, is because it’s implementing the Observer pattern“. To understand what all that means, we need to understand the terminology.

What is a design pattern?

We discussed Design Patterns in a class taught by Dr. Joel Henry in CS grad school. Dr. Henry described a problem that exists in a new field like computer software engineering. People have been building bridges and buildings for thousands of years. You can look at a building whether it’s a pyramid or a skyscraper and it follows well-known design patterns. Also, the materials and pieces that go into the construction are standardized. In software development, the design patterns and pieces are relatively new, pretty much less than a hundred years old. And, there is not general agreement on which parts and pieces are “good” and which are not so useful: anti-patterns.

What is an Anti-Pattern?
A visual description of antipattern from

“An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. The term, coined in 1995 by Andrew Koenig, was inspired by a book, Design Patterns, which highlights a number of design patterns in software development that its authors considered to be highly reliable and effective.”
~ Wikipedia

That definition combined with the statement above would seem to call reactive programming “usually ineffective and risks being highly counterproductive.” Not a very happy start to learning about reactive programming. So, is anti-pattern part of a programmer war, or is it a functional description?

The answer may be that anti-pattern is both part of a programming controversy and a functional description. The image at the right came from an article called “Functional programming in Javascript is an antipattern” by Alex Dixon. On the one hand, he is recommending a different pattern. On the other hand, he describes how functional programming keeps him in the weeds.

What is the Observer Pattern?

When you need specific information right now! Other information is not time critical. For me, politics and sports scores fall into the not-so-time-critical side. On the other hand, if out-of-town family is coming through town but the time is uncertain, and we are serving them dinner, I need to know as their plans and circumstances change. There are many situations like these in programming. And, what is critical is depended on the unique specs of the system.

One of the main uses for reactive programming is to update data. You certainly don’t want one part of your website saying one thing and another having old information. Facebook is like that. While you are responding to a post, 2 other responses may pop in before you are finished typing. With reactive programming, the whole page doesn’t reload, just that particular spot. So, is the software pushing the changes into your browser, or is the browser pulling them from the software? Which side is “observing” … watching for changes?

“The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods.

It is mainly used to implement distributed event handling systems, in “event driven” software.”
~ Wikipedia

That description means that if something changes, it notifies the related/dependent structures about that change.

We Still Don’t Know Whether It’s Pass by Reference or Pass by Value

Even if reactive programming uses the Observer Pattern, it could be pass by value or pass by reference. The point of the Observer Pattern seems to be that the object that has the change notifies the related objects of the change. So, it could notify them by sending a new value, or it could notify them by prompting them to check for new values in a reference.

Sigh … back to square one.

Besides posting to StackOverflow, I posted on my Facebook page, and received this reply

Yes, it is a form of passing by reference, but not just to the variables.

Actually, the := is not, there, an assignment. It is rather creating an alias, or implicit function, or, if you prefer, a macro.

You are really saying

Def a=f(b,c)

I think it has the benefit of creating magnificently baroque and hard to find bugs.

At the very least there ought to be a clear indication of whether something is a conventional variable, or an alias, or macro.


Reactive Programming in Python



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.