With examples can someone demonstrate how lazy evaluation is different than reactive programming. Alternatively, are they very similar?
Given c = 3; both approaches would seem to involve implementing b = c + 2; at least internally regardless of how the code looks as int b() {return c + 2;}. In both cases it’s not known what b is until its value is required, then the calculation occurs.
What would the name be that describes this approach?
So reactive programming uses or simulates lazy evaluation? Languages with lazy evaluation are programmed in a reactive way?
You seem to be confusing lazy evaluation and reactive programming as being at the same “logical level.”
To me, lazy evaluation is a language facility that allows the existence and manipulation of infinite data. (Data that has a sort of “finite structure” but is infinite in the sense that you can pull off as much as you want and still have some left over.) If you scratch your head a bit and try some examples, you will see that having lazy evaluation is good in the presence of infinite data structures because you don’t “loop forever” when using these values. (Though there are other uses for lazy evaluation as well, there are certainly some performance gains to be had at times.)
Wikipedia defines reactive programming:
To me, this doesn’t really go with lazy evaluation at all. Lazy evaluation just means that you only compute as much of an answer as you need to do more work, and then keep around a holder (typically called a “thunk”) that will let you do more work when you need it so you can compute more answers. (By the way, this ability to pull off “as much as you need” is exactly what allows you to play with infinite data using lazy evaluation.)
By contrast, reactive programming allows you to define — succinctly — how data flows will be propagated. (For example, a reactive framework would let you set up that example you gave without explicitly having to implement it using callbacks and function pointers.) But in reality, this line is very fuzzy. There are certainly reactive frameworks in imperative languages: most people will call GUI frameworks reactive.
By contrast, in functional reactive programming(FRP), you declaratively specify reactive data. This is implemented “under the hood” using the laziness of the Haskell language (in that particular case) because that is the method most amenable to doing updates (since it most directly fits that paradigm).
But in language like C or C++, you typically do reactive programming via function pointers or callbacks, without an explicit notion of lazy evaluation. Sure, there will probably be some laziness under the hood to support this kind of stuff, but you aren’t really at the right semantic level to make that distinction, and in this case you can usually use lazy ‘tricks’ to speed up the reactive framework (which ostensibly updates something — say the GUI — on demand as the user uses more pieces of it).