On Mon, Jul 18, 2011 at 1:15 PM, Paul Homer <[email protected]> wrote:
> I think that programing languages are easily formal systems and thus are > bound by any inherent weaknesses. > It would be nice if more programming languages were formal. Quite a few make us play 'guess the semantics'. I suppose this is nice for those who enjoy interactive fiction. > The root idea behind what I wrote years ago was that we often think that > our way to keep up is by going up to a higher abstraction. Instead, I > thought it might be possible to go sideways. Thus the computer builds us > systems from many smaller pieces that are interchangeable, rather than us > searching for better abstractions. > I agree. This is the idea of favoring composition and integration rather than abstraction. Composition: we have a standard set of operators, and a set of useful properties. When we compose elements by use of the properties, we can inductively reason about the properties of the composite just by knowing the properties of the operands. Critically, we must not need to look inside the operands. As a positive example, we can often reason about For example, we say that safety with mutex-based concurrency-control is not compositional because we cannot predict deadlock-freedom of the composite from knowing the same high-level properties of the subprogram. Integration: it is unreasonable to treat projects as independent. We will always share libraries, services, data and domain models. Even within a given domain, there will be a lot of subtle variations between projects. The idea of integration is that it should be easy to create adapters between independently developed models in a *live, federated* system. Elements of our models and data will change on us over time. In concrete terms: integration means that we must avoid need to 'copy' the entire model and translate it as a batch process - we need something more partial, precise, and incremental (cf. Data Model Independence<http://awelonblue.wordpress.com/2011/06/15/data-model-independence/>). The primary concepts must be be orchestration and adaptation rather than abstraction. Composition and integration are both critical for scaling, for open systems, and for modular development. But we can only achieve them by sacrificing some of our ability to effectively abstract - our high level code, our diverse DSLs, et cetera must ultimately be 'well-founded' on some common semantics that guarantee a compositional nature for the integration properties. In order to achieve high levels of composition and integration, we must sacrifice some *expressive power* - i.e. we must limit which abstractions we can express in order that the remaining abstractions will integrate and compose nicely. That said, we only need to sacrifice power relative to, say, use of syntactic transforms (fexprs, et cetera). State-of-the-art in expressive power is nowhere near its potential, and we could greatly improve the expressive power of our paradigms for applications that involve scatter-gather of data, timing requirements, orchestration, ad-hoc workflows, dependencies, configuration management, or security. Arbitrary abstractions would still be available, even with expressiveness constraints. However, developers should learn new idioms, develop new models and algorithms, suitable to the shared integration and composition substrate. It is important that direct expression be sufficient for most tasks developers will encounter, or that developers at least have the ability to abstract out the bits that would be indirect. As far as candidate paradigms for the substrate: I believe that reactive dataflow systems have already proven itself. They support declarative, concurrent transforms and scatter-gather between domain models. Reactive models make it easy to abstract inversion-of-control and processes via normal objects. They can bridge the scale from embedded real-time mission-critical control systems on one end (Lustre, Esterel) to productive UIs and distributed CSCW on the other (spreadsheets, wikis, wave). Among the reactive dataflow paradigms, I am not aware of any more effective for composition, integration, orchestration, and abstraction in an open system than my "reactive demand programming" (RDP) model. RDP involves reactive behaviors to orchestrate a multi-agent system. I offer a comparison of FRP and RDP<http://awelonblue.wordpress.com/2011/05/21/comparing-frp-to-rdp/> .
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
