Jonathan Edwards: Programming Futures and Declarative Objects

It would be nice to find a nice mid-point between imperative and functional programming. And no, Scala is not it

And on that note, Jonathan Shapiro's BitC seems to be doing some ground-breaking work toward that end.

Very interesting interview. I too have a very hard time working with async callback code. The presentation side of silverlight is awesome. But its reliance on WCF ramps up the complexity far too much.

Scala is a multi-paradigm language: object-oriented, functional and imperative. There's not really a "mid-point" (what does that mean), but you can mix features as you like.

Now the mention of aliasing immediately led my thoughts to Bertrand Meyer's paper on the theory and calculus of aliasing.

There is an interesting paper on functional reactive programming (FRP) that uses scala:

http://lamp.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf

It is interesting in that it demonstrates a little of what Jonathon Edwards was talking about. By the middle of the paper I was excited about FRP and DataFlow programming in general, but by the end of it I was trying to wrap my head around the complex compositional relationships I would now have to manage. If you were to use instead a declarative model, a large portion of the complexity could simply be represented by implied relationships in a declarative expression.

In defense of scala (though I personally have a love-hate relationship with the language), scala has an expression-based syntax, not a statement based one (like C#, not counting LINQ). This single distinction makes custom declarative programming models a natural part of the language, and in fact this is one of the features that are critical to implementing internal DSLs in scala. For example, you can (and some have tried already: http://github.com/vladimirk/scalalinq/) implement things like linq in scala without using any custom syntax or compiler plugins - just plain scala.

Interesting.

1) Isn't this bring a form of sql to the desktop?  Declaritive and data driven language?  Linq?

2) Declaring the data first sounds like we can still learn some things from Cobol's declarations section.  Declare the data tree first. The data is the application model.  A tree would seem to solve a few other problems regarding transactions and rollback and locking.  With a tree, the runtime can know what the locking order is by tree order.

3) Couldn't you start experiments on this idea without boiling the ocean?  I mean a framework like Rx can express some pretty progressive ideas without have to start from a new runtime and language.  It could take five years or more just to get the point of being able to experiment with the core ideas to see if it any of them work.

4) Haven't people like Jim Gray solved some of this on server end using parallel pipelines, trees and folk-joins? 

This was what I was wondering too, staceyw. It seems like a simple DSL might be more appropriate than a new general purpose lanauge...

I totally agree with Jonathans ideas but would suggest taking them even further in the form of DSLs on VMs so that there are the base layers; mark up with bindings view layer, declarative code behind layer, optional program smarts business layer and data management layer.

The view would be markup language agnostic as long as it understands bindings and has a provider to communicate with the View VM. Ie. You could declare a text box or red cube if the markup supported it in XAML, html or VRML and it would display as needed.

The super code behind (SCB) would be a declarative domain specific language (DSL) that provided attributes, behaviours, triggers, events landings, and bindings to the data management layer and/or program smarts layer.

An optional program smarts layer (PSL) would be programming language agnostic as long as it compiled to an IL that could be used by the SCB. Basically it is the foreign code access layer that can do all the dangerous stuff like access file system directly, internet, C libraries, etc. How you would be able to do this would be similar what I said in Brian Beckman’s monads and coordinate systems where the VM would declare binary landmarks that the language assembly provider would work out how that relates to its types and structures, then be sandboxed in an security overseer.

The data management layer (DML) would be about organising access points to data sources that you could declaratively work with. This would enable you to add data access points to text/xml files, sql/object/no-sql databases, data services, etc. as long as each data point had a provider that we could declaratively read/write to. Eg. In the PSL you could use LINQ to query data from a text file merging it with sql server data and a web service. The SCB would display the data as it arrived and signalled to the SCB that more data is on the way to display as such in the View. The DML would also have its own code behind DSL that could be called to perform data source specific features. Ie. Non-read/update/add/delete operations.

That's how I would describe my idea of programming futures.

You just defined a DSL I think.

Perhaps the use of 'Domain' in DSL is a misnomer. What is special about a DSL is not the domain it covers, but the specialized forms of expression it provides to solve a specific class of problems (in this case, defining dataflows). The class of problems don't necessarily have to apply to a specific application domain AFAIK, though that's a common usage.

In short, a DSL captures an expression model. That expression model can be conveniently applied to one or more domains (assuming the DSL is well-motivated).

I've only written a couple of DSLs, though, so someone please correct this if there is a more concrete or better definition.

Functional Reactive Programming is indeed an alternative approach, and one that is being actively developed. My reaction has been similar to yours: it just seems very abstract and counter-intuitive to me. The most important thing for me is being easy to understand and use, because programming is already hard enough. I also think it ends up punting on the hard problem of coordinating the changes from different events that may influence each other via side-effects.  But maybe I just don't get it, or they will eventually work it out.

Stacey, the limitation with SQL, LINQ, et. al. is that they solve the problem of reading data, but not modifying it. If you want to modify the data, you are back to imperative programming. DSL's leave you in a similar situation: if you want to modify complex data, you end up recreating the control structures of an imperative language. We just don't know of any good alternative yet. I am basically trying to do the same thing for modification that queries did for reads: invent a declarative semantics that has nice compositional properties.

edwards,

Using a declarative approach, perhaps there's a way to specify the outcome (state delta or some such) of desired changes under certain conditions instead of invoking mutating operators / imperative statements directly. Since you'd be specifying the outcome declaratively, presumably it can be done within a DSL. I've not implemented such a feature before, however, so I don't know if it will actually work...

@edwards.  Maybe I am not thinking right.  But sql has Insert/Update/Delete.  Linq could have an Update if they add it (add Update next to Select as an extention method?).  Maybe you need something more specific to trees.  Please keep us updated.  Could also bounce ideas here in Tech forum as you never know what some crazy 9er will inspire.