Lambda the Ultimate

No Ifs, Ands, or Buts: Uncovering the Simplicity of Conditionals. Jonathan Edwards.

Schematic tables are a new representation for conditionals. Roughly a cross between decision tables and data flow graphs, they represent computation and decision-making orthogonally. They unify the full range of conditional constructs, from if statements through pattern matching to polymorphic predicate dispatch. Program logic is maintained in a declarative canonical form that enforces completeness and disjointness among choices. Schematic tables can be used either as a code specification/generation tool, or as a self-contained diagrammatic programming language. They give program logic the clarity of truth tables, and support high-level direct manipulation of that logic, avoiding much of the mental computation demanded by conventional conditionals.

Many of us are skeptical of "visual programming", but also intrigued by the impact that powerful development tools might have on language design. This represents an interesting compromise. It addresses a pervasive problem in a novel way, and this is a paper with many interesting and accessible ideas. I look forward to seeing an implementation.

Jonathan posted this on his blog, where there are already several comments.

[I'm not sure where to put this... Seems like plain-old "Paradigms" is the best fit...]

I've just finished a paper submission on live programming languages and how live programming is realized in SuperGlue. Any feedback is appreciated. Here is the link:

http://lamp.epfl.ch/~mcdirmid/mcdirmid07live.pdf

Because the paper has inlined movies, it is best read in a later version of AcroRead with QuickTime installed.

Abstract:

A dynamic language improves programmer productivity through flexible typing, a focus on high-level programming, and by streamlining the edit-compile-debug cycle. Live languages go beyond dynamic languages with more programmer-centric features. A live language supports live programming that provides programmers with responsive and continuous feedback about how their edits affect program execution. A live language is also based on declarative programming constructs such as rules or data-flow connections so that programmers can write less code. A live language should also provide programmers with responsive semantic feedback to enable time-saving services such as code completion. This paper describes the design a textual live language known as SuperGlue. SuperGlue is based on reactive values known as signals that are supported with declarative data-flow connections and dynamic inheritance. Through signals and dynamic inheritance, SuperGlue supports live programming, declarative programming, and responsive semantic feedback. We demonstrate live programming in SuperGlue with a working prototype.

The Service Modeling Language (SML) provides a rich set of constructs for creating models of complex IT services and systems. These models typically include information about configuration, deployment, monitoring, policy, health, capacity planning, target operating range, service level agreements, and so on. Models provide value in several important ways.

1. Models focus on capturing all invariant aspects of a service/system that must be maintained for the service/system to be functional.

2. Models are units of communication and collaboration between designers, implementers, operators, and users; and can easily be shared, tracked, and revision controlled. This is important because complex services are often built and maintained by a variety of people playing different roles.

3. Models drive modularity, re-use, and standardization. Most real-world complex services and systems are composed of sufficiently complex parts. Re-use and standardization of services/systems and their parts is a key factor in reducing overall production and operation cost and in increasing reliability.

4. Models represent a powerful mechanism for validating changes before applying the changes to a service/system. Also, when changes happen in a running service/system, they can be validated against the intended state described in the model. The actual service/system and its model together enable a self-healing service/system – the ultimate objective. Models of a service/system must necessarily stay decoupled from the live service/system to create the control loop

5. Models enable increased automation of management tasks. Automation facilities exposed by the majority of IT services/systems today could be driven by software – not people – for reliable initial realization of a service/system as well as for ongoing lifecycle management.