Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Jonathan Edwards: Programming Futures and Declarative Objects

24 minutes, 16 seconds


Right click “Save as…”

"The biggest problem with programming is that we don’t agree on what the problem is", says Jonathan Edwards, who is first and foremost a practicing programmer. Jonathan also spends a great deal of time thinking about how to evolve the languages and tools programmers use to solve increasingly complex problems in general purpose computing. He is currently a Research fellow at MIT, and I caught up with him at Emerging Languages Camp 2010 shortly after his talk on Declarative Objects (see the PPT or PDF slides). His thoughts on a potential future direction for general-purpose programming are quite compelling. In a nutshell, Jonathan is thinking about an object-oriented model-view declarative programming world. Discussing this idea, he states, "First, restrict pointers with a new object model that uses nesting and binding. Second, prevent cycles with a new form of dataflow based on the Model-View architecture."

Look through the PPT or PDF linked to above, press play, and open your mind a bit. See what you may see. The programming languages rabbit hole is deep. We seem to be hovering at a comfortable position, yet the problems we face will require us to move further down the tunnel to discover new means of algorithmic expression and code design. Jump in.



Follow the discussion

  • Oops, something didn't work.

    Getting subscription
    Subscribe to this conversation
  • bryaneddsbryanedds An ​individuali​st is he who is saving himself from all those who are saving the world.

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

  • bryaneddsbryanedds An ​individuali​st is he who is saving himself from all those who are saving the world.

    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.

  • Bent Rasmussenexoteric stuck in a loop, for a while

    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:



    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.

  • William Staceystaceyw Before C# there was darkness...


    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? 

  • bryaneddsbryanedds An ​individuali​st is he who is saving himself from all those who are saving the world.

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

  • CharlesCharles Welcome Change

    Elaborate... The purpose of Jonathan's quest is that of designing a general purpose tool to help compose (as in write) programs that solve problems of a general purpose nature. I don't see how domain specificity applies here.


  • ChevalN2Cheval Why not null?

    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.

  • bryaneddsbryanedds An ​individuali​st is he who is saving himself from all those who are saving the world.

    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.

  • bryaneddsbryanedds An ​individuali​st is he who is saving himself from all those who are saving the world.



    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...

  • William Staceystaceyw Before C# there was darkness...

    @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.

Remove this comment

Remove this thread


Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.