Comment Feed for Channel 9 - Jonathan Edwards: Programming Futures and Declarative Objectshttp://video.ch9.ms/ecn/previewImages/100/563930_100x75.jpgChannel 9 - Jonathan Edwards: Programming Futures and Declarative Objects&quot;The biggest problem with programming is that we don’t agree on what the problem is&quot;, 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, &quot;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.&quot;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.
Enjoy. enTue, 03 Mar 2015 20:33:13 GMTTue, 03 Mar 2015 20:33:13 GMTRev9Re: 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

]]>
http://channel9.msdn.com/Blogs/Charles/Jonathan-Edwards-Programming-Futures-and-Declarative-Objects#c634166747370000000
Fri, 06 Aug 2010 06:58:57 GMThttp://channel9.msdn.com/Blogs/Charles/Jonathan-Edwards-Programming-Futures-and-Declarative-Objects#c634166747370000000bryaneddsRe: Jonathan Edwards: Programming Futures and Declarative Objects
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.

posted by SteveRichter

]]>
http://channel9.msdn.com/Blogs/Charles/Jonathan-Edwards-Programming-Futures-and-Declarative-Objects#c634166899430000000
Fri, 06 Aug 2010 11:12:23 GMThttp://channel9.msdn.com/Blogs/Charles/Jonathan-Edwards-Programming-Futures-and-Declarative-Objects#c634166899430000000SteveRichterRe: Jonathan Edwards: Programming Futures and Declarative Objects
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.

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.

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?

posted by staceyw

]]>
http://channel9.msdn.com/Blogs/Charles/Jonathan-Edwards-Programming-Futures-and-Declarative-Objects#c634167127490000000
Fri, 06 Aug 2010 17:32:29 GMThttp://channel9.msdn.com/Blogs/Charles/Jonathan-Edwards-Programming-Futures-and-Declarative-Objects#c634167127490000000staceywRe: Jonathan Edwards: Programming Futures and Declarative Objects
This was what I was wondering too, staceyw. It seems like a simple DSL might be more appropriate than a new general purpose lanauge...

posted by bryanedds

]]>
http://channel9.msdn.com/Blogs/Charles/Jonathan-Edwards-Programming-Futures-and-Declarative-Objects#c634167333880000000
Fri, 06 Aug 2010 23:16:28 GMThttp://channel9.msdn.com/Blogs/Charles/Jonathan-Edwards-Programming-Futures-and-Declarative-Objects#c634167333880000000bryaneddsRe: Jonathan Edwards: Programming Futures and Declarative Objects
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.

C

posted by Charles

]]>
http://channel9.msdn.com/Blogs/Charles/Jonathan-Edwards-Programming-Futures-and-Declarative-Objects#c634167347160000000
Fri, 06 Aug 2010 23:38:36 GMThttp://channel9.msdn.com/Blogs/Charles/Jonathan-Edwards-Programming-Futures-and-Declarative-Objects#c634167347160000000CharlesRe: Jonathan Edwards: Programming Futures and Declarative Objects
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.

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.

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.

posted by bryanedds

]]>
http://channel9.msdn.com/Blogs/Charles/Jonathan-Edwards-Programming-Futures-and-Declarative-Objects#c634167464140000000
Sat, 07 Aug 2010 02:53:34 GMThttp://channel9.msdn.com/Blogs/Charles/Jonathan-Edwards-Programming-Futures-and-Declarative-Objects#c634167464140000000bryaneddsRe: Jonathan Edwards: Programming Futures and Declarative Objects
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.

posted by edwards

]]>
http://channel9.msdn.com/Blogs/Charles/Jonathan-Edwards-Programming-Futures-and-Declarative-Objects#c634168027460000000
Sat, 07 Aug 2010 18:32:26 GMThttp://channel9.msdn.com/Blogs/Charles/Jonathan-Edwards-Programming-Futures-and-Declarative-Objects#c634168027460000000edwardsRe: Jonathan Edwards: Programming Futures and Declarative Objects
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.

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

posted by bryanedds

]]>
http://channel9.msdn.com/Blogs/Charles/Jonathan-Edwards-Programming-Futures-and-Declarative-Objects#c634168083260000000
Sat, 07 Aug 2010 20:05:26 GMThttp://channel9.msdn.com/Blogs/Charles/Jonathan-Edwards-Programming-Futures-and-Declarative-Objects#c634168083260000000bryaneddsRe: Jonathan Edwards: Programming Futures and Declarative Objects
@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.