Thought: Reactive Programming
"Data binding" isn’t a sexy term. Most object-oriented purists and computer science majors I’ve met like to stare down their nose at it, as if it were all about drag and drop, and limited to the likes of MS Access and VB6. If you want to look smart, don’t talk about data binding 
If, like me, you find data binding intriguing, but want to appear interesting at dinner parties, have a read about Reactive Programming and Functional Reactive Programming on Wikipedia:
Reactive programming is a programming paradigm oriented around data flows and the propagation of change. This means that it should be possible to express static or dynamic data flows with ease in the programming languages used, and that the underlying execution model will automatically propagate changes through the data flow.
For example, 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. In reactive programming it could instead mean that we set up a dynamic data-flow from b and c to a. whenever the value of c or b is changed, then a is automatically updated.
The query operators in SyncLINQ are designed to allow exactly that. While LINQ takes operations on collections and turns it into a language construct. SyncLINQ takes synchronization of data and turns it into a language construct.
Where LINQ is designed for collections (non-collection queries are performed using regular language constructs), SyncLINQ introduces non-collection Operators, like this:
IBindable<bool> requiresApproval = sales.Sum(s => s.TotalPrice)
.If(total => total > 5000M);
Like the reactive system described by Wikipedia, the SyncLINQ operators create data flows between the sum of the sales, and the requiresApproval value, with the use of a predicate. Customer removes an item from their cart? The change is propagated, with no work on your side.
With the current focus on Rich Internet Applications, sooner or later, reactive programming will become an every day part of your programming experience. I hope that SyncLINQ will make it sooner
Filed under: Binding
Hi Paul,
just wanted to let you know that you are right. We had a big RIA application and no Linq and had to build a complex pipeline system to do the kind of stuff you do here.
I found another project: continuos linq and suggested (and actually contributed) a way to do ‘continuous’ aggregations. They are very important.
Reading your posts about SyncLinq it seems to be exactly what I needed back then, and possibly better implemented than continuousLinq. I’m sure I’ll use it in next projects.
Keep up the great work!
Ruurd
i never considered ‘databinding’ to be unsexy at all; infact it’s my preferred method almost every time. i don’t associate it with drag and drop programming at all.
Yes, a spreadsheet is like this as well.
If you are really interested in data flow programming,
check out Microsoft’s Robotics. There is a visual programming tool that does what you are saying. Even better if check ou this research project called Ptolemy II. http://ptolemy.eecs.berkeley.edu/ptolemyII/index.htm
It is this type of programming that Windows Workflow should be doing, but isn’t. Workflow should be doing data flow.
@Ruurd,
Glad I’m not the only one
@Will,
I was thinking about Excel just last night. Excel is often described as functional, but it’s also reactive - cells depend on cells, so when one changes the others know to update.
Thanks for the link to Ptolemy II - I’ll have a read.
[…] And whenever the inputs to the query change - a new order is placed, or the total price of an order changes - the query is re-evaluated and the result will reflect the change. It’s a reactive data flow. […]
Data flow is important and should be maintain. using spreadsheets is really a big help and user friendly too.