Ensō: Don’t Design Your Programs, Program Your Designs

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone

William R. Cook is the author of today’s guest post where he presents his work on the software development system Ensō. Enter William.

Ensō: Don’t Design Your Programs, Program Your Designs(DDYPPYD, pronounced “dipped”)

This note is a explanation of the goals and strategies that guide the development of Ensō, in the form of a manifesto. While many of these ideas have been implemented and validated to some degree, Ensō is a work in progress, so these statements should be taken as goals and hypotheses, not established facts.

Ensō is a new software development system based on definition, refinement and integration of executable specification languages. The combination of “executable” and “specification language” may seem an oxymoron. However, by restricting the expressive power of specification languages, which model “what” not “how”, it is possible to fully automate the computation of the “how” given the “what”. Examples of executable specification languages include BNF, SQL, Excel, Datalog, and make. Ensō has many connections to existing work on Model-Driven Development (MDD), Domain-Specific Languages (DSLs), Language-Oriented Programming (LOP), Language Workbenches, and program synthesis. However, Ensō embodies some significantly different design decisions than other systems. The differences relate primarily to the role of transformation of models. In particular, Ensō rejects the common approaches for 1) model to code, 2) model to model, and 3) generic transformation languages. These topics are discussed in turn below.

Ensō is based entirely on interpreters not compilers/translators. Code generation is completely avoided, because it is complex and unnecessary. Ensō hypothesizes that interpreters are easier to develop, maintain, extend, and combine than compilers/transformations. As examples, both the Ensō data modeling language [1] and grammar language [2] are interpreted on the fly. Ensō implements interpreters using ordinary object-oriented code. By defining interpreters as objects, traditional object-oriented composition and inheritance techniques can be used to extend and combine language semantics. For example, a state machine modeling language may reuse an expression language for conditions and actions, or secure data model interpreter may wrap the standard data interpreter. This was one of the failures of 4GLs: while they provided powerful execution strategies, it was not possible for users to modify the execution strategies. An interpreter embodies a strategy for execution of a modeling language, but there can be many different strategies that are useful for different purposes and situations. For example, a parser and pretty-printer are two different interpretations of grammars. In Ensō both syntax and semantics are first-class concepts that can be reused to create new languages.

Ensō is based on external languages rather than embedding. An external language is one that has its own syntax and semantics, independent of any other language. An embedded language is defined as a library within a host language. Embedded languages typically reuse features of the host language, including variable binding or control flow. Successful embedding typically requires advanced host language features, either for composition or reflection, as found in Haskell, Ruby, or Scala. There are many advantages and disadvantages in the choice of embedded or external DSLs. Ensō seeks to overcome some of the traditional limitations on external DSLs. For example, the Ensō parsing model makes creating new languages easy. More importantly, Ensō allows languages to be composed and reused, much the same way that embedded languages reuse features of the host language.

It is often useful to transform one model into another model. But there are two important uses cases which Ensō treats very differently. For Functional Transformation, the goal is simply to obtain the final model. For Semantic Transformation, the mapping has additional semantics besides producing a result.

A Functional Transformation is simply a function from the input language to the output language. In this case, Ensō uses an appropriate general-purpose programming language to write the transformation. For example, transforming a grammar by removing pretty-printing annotations is a simple function to define. Depending on the situation it might be easier to generate text that represents the result or to construct the result abstractly. For such functions, Ensō uses an appropriate general-purpose programming language, rather than a specialized transformation language.

For Semantic Transformation, the mapping has additional semantics behind simply creating a result. For example, a grammar can be viewed as a bidirectional transformation between text (or token streams) and an abstract object graph. The grammar is not a simple transformation function. As another example, a User Interface can be viewed as a transformation from an object model to a presentation model, where the changes to the presentation model are propagated back to the object model. The additional semantics means that a custom interpreter is needed for semantic transformations. A general-purpose transformation language would not help.

Thus in either case, for Functional or Semantic transformation, there is no need for a general-purpose transformation language, like ATL.

Ensō rejects the false dichotomy between graphical and textual models. A graphical editor allows manipulation of a graphical visualization of a conceptual structure. Graphical editors should be easy to construct for models that have useful visualizations. The same graphical editing infrastructure can be used by programmers to create user interfaces and visualizations of other kinds of data. Textual structures are another presentation of abstract structure. It should be possible to augment a textual presentation with graphical information, so that the text can be loaded into a visualization. Ensō supports both text and graphics equally well, and integrates them so that one can have both at the same time.

Ensō strikes out on its own rather than building on existing standards, including UML and EMF. Ensō rejects the OMG practice of “standardize first, use later”. Trying to create a standard that satisfies everyone leads to feature bloat and complexity. The goal of making UML universal has also led to inclusion of ad-hoc and complex extension mechanisms, which further complicate the standard. Instead Ensō focuses on modularity of languages and features. Eclipse is a powerful and practical platform with many advantages. However, it is possible that much of its complexity is accidental rather than fundamental. If so, it may be possible to create an extensible integrated development environment with orders of magnitude less code and complexity than in Eclipse. To find out, Ensō will create its own IDE rather than build on top of Eclipse. Evidence from Newspeak, Cloud9, and Smalltalk suggest that this is possible.

Ensō sees no value in the idea that “everything is an X” for any value of X. Some things are best described as models. Other ideas are best described in code. Some models are structural, others behavioral, others define transformations. Code is good. Some concepts are best represented in text, others with pictures. The question is not how to force everything into a single conceptual model, but rather how to express each idea in the most natural and useful way, to highlight essential complexity and avoid accidental complexity. Ensō seeks a way Out of the Tar Pit [3].

Finally, Ensō is implemented in itself. This allows all tools written for the system to be reused in creating applications, and tools and libraries developed for applications to be reused in the creation of the system. It also means that the core languages and strategies that define the Ensō system can be modified to extend the functionality of Ensō. Smalltalk has shown the benefits of such deep reflection. Ensō provides a similar level of reflection, but in a more controlled way, as the system has a well-defined bootstrap process. Ensō is bootstrapped from Ruby, and is available today for experimentation. Ensō welcomes new collaborators. Ensō already has significant functionality, including schemas, grammars, diagram editors, a web application framework, and access control. But Ensō is definitely pre-alpha, so if you want to play with it please expect to be working with a moving target. http://enso-lang.org

[1] Alex Loh, Tijs van der Storm, William R. Cook. “Managed Data: Modular Strategies for Data Abstraction” To appear SPLASH Onward! 2012. http://www.cs.utexas.edu/~wcook/Drafts/2012/ensodata.pdf

[2] Tijs van der Storm, Alex Loh and William R. Cook. “Object Grammars: Compositional & Bidirectional Mapping Between Text and Graphs” To appear at the International Conference on Software Language Engineering (SLE), 2012. http://www.cs.utexas.edu/~wcook/Drafts/2012/ensogrammars.pdf

[3] Ben Moseley and Peter Marks. “Out of the Tar Pit”. http://shaffner.us/cs/papers/tarpit.pdf

If you liked this post, you should subscribe to the blog feed or facebook page and follow my thoughts on twitter about software development or web design and social media .

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone
No answers

Reply

Your email address will not be published. Required fields are marked *