Notes on the 8th OOPSLA Workshop on Domain-Specific Modeling, part II (Sunday Afternoon)

In the afternoon sessions, everything began to blur together: several of the 20-minute long presentations (often in broken English) were either overly specific or only vaguely comprehensible to me. As the morning’s coffee overdose began to wear off, I slipped into a muddled despondency.

The most dynamic presentation (literally!) was by the guys that did “ModelTalk: A Framework for Developing Domain Specific Executable Models”. Atzmon Hen-tov gave a rundown of the overall design; then Lior Schachter walked through a ten-minute change to an existing web application. These guys weren’t academics stuck up in some ivory tower. They maintained over twenty systems with a team of over fifty developers. They needed to deal with an environment of pervasive customization while delivering frequent updates.

This was a whirlwind demo, but I gather they were building in a style more along the lines of the spirit of CLOS and Smalltalk than the typical Java approach. They wanted to be able to extend the models without having to recompile binaries. What would happen is… if Java didn’t have an object specification for a specific model, it would just use something similar in its place:

Well... let just use this object over here instead!

Well... let just use this object over here instead!

I think they referred to this as dependency injection. Code completion, automatic syntax checking, and dynamic error checking were demonstrated– stuff in the model DSL’s had exactly the same level of tool support as the straight Java side. The developer appeared to jump back and forth between the two contexts with ease. (The crowd seemed to be fairly impressed by this feat.)

These developers emphasized repeatedly that their productivity gains were primarily due to their declarative and interpretative approaches. Now, I was probably the dumbest person in the room… but I just couldn’t understand how someone excited by this architectural approach could possibly stay committed to using something like Java. My impression was that they were investing huge amounts of developer effort in order to work around the inherent limitations of the Java language. You’d think that there would be other platforms out there that would be a little more friendly to a dynamic approach to handling their requirements.

One thing they said that was telling was that, because of their interpretative approach, they could use new classes at run time as long as they didn’t need any new behavior. (What they were trying to avoid was having to recompile the binaries.) This didn’t make any sense to me. If you’ve got “new” classes without new behavior… then really all you have is old classes with new property values. This leaves an impression that these guys were bending over backwards to deal with DSM and XML specifications just to work around Java’s pathological type system– and they weren’t really gaining anything from the DSM that a more traditional data-driven architecture could give. Surely I missed an important point in there somewhere….

In another session, the speaker talked about how people tend to wrap a DSL around a specific framework… but then what do they do when they begin to outgrow the framework? (They also had a cool slide for this point.) After the presentation, Steven Kelly noted that you could wrap the framework in a very thin DSL… and then your main DSL should just talk to that instead of going directly to the framework: this way you could switch frameworks without having to modify your DSL– all changes would be restricted to the thin “buffer” layer. One of the other attendees dismissed this strategy with a wry remark: “There’s nothing in CS that cannot be solved by simply adding another layer of misdirection.” In an informal discussion afterwards, I mentioned that this was an idea presented in the classic SICP as a linguistic abstraction barrier. Nobody in our corner of the room had heard of the famous “wizard” book, though.

Here’s a sample section that illustrates how the idea is described there:

“Map is an important construct, not only because it captures a common pattern, but because it establishes a higher level of abstraction in dealing with lists. In the original definition of scale-list, the recursive structure of the program draws attention to the element-by-element processing of the list. Defining scalelist in terms of map suppresses that level of detail and emphasizes that scaling transforms a list of elements to a list of results. The difference between the two definitions is not that the computer is performing a different process (it isn’t) but that we think about the process differently. In effect, map helps establish an abstraction barrier that isolates the implementation of procedures that transform lists from the details of how the elements of the list are extracted and combined…. This abstraction gives us the flexibility to change the low-level details of how sequences are implemented, while preserving the conceptual framework of operations that transform sequences to sequences.” — SICP Section 2.2.1

The point is made much more forcefully in Abelson and Sussman’s video lectures but you should get the idea. “Linguistic abstraction barrier” sounds really cool, but it really is the most basic component of defensive programming. If I have an object model that I have to interact with a lot– and that is likely to change drastically due to new developments– then it’s crazy to embed calls to that object, say, throughout my GUI event routines. I should wrap the object inside another one that “speaks” a higher level “language” that maps more directly to what typically goes on in the GUI. This sort of barrier frees the GUI from having to “know” anything about the underlying framework. It also provides a high level organization and commentary to what the framework is actually getting used for.  This situation is isomorphic to the DSL/Framework issue!

Okay, okay… this is a real minor point. But a guy can’t pass up a chance like this to make oblique references to SICP! (I guess MIT isn’t quite the cult phenomenon in Europe that it is here?) Seriously, though. You just can’t have people scoffing at the idea of an abstraction barrier.

7 Responses to “Notes on the 8th OOPSLA Workshop on Domain-Specific Modeling, part II (Sunday Afternoon)”

  1. Mark Miller Says:

    What you say in relation to the SICP quote is interesting. I hadn’t thought of objects from that perspective (the object provides an interface that is semantically compatible with the way the caller does things). The only thing I can think of that relates to this is Alan Kay said that from his conception of OOP every object is a computer in software. Since a computer can emulate any other computer, you can do the same with objects. In other words an object can provide any interface it wants so that to the outside world it looks like it’s acting one way, when internally it’s doing whatever it wants. His main points were implementation should be hidden, and that the abstraction was in the messages/message passing, not the objects themselves.

    I’m working towards delving into SICP (I’m trying to solidify my skills in Lisp first), so in the meantime I can only take a blind stab at this, but in relation to your example of data object(s) and a GUI, are you saying the relationship should be like this (inside GUI code)?:

    | information |
    information := GUIWrapper wrap: dataObject with: displayCell.
    information display withBackground: Color blue andForeground: Color white

    Sometimes in Squeak I see things like the following happen, since in the browser methods are displayed individually in the code editing window, not as one big set of methods that you can cursor through:

    dataObject displayOn: self at: displayCell

    No wrapper involved. This may be bad design at work. It wouldn’t surprise me.

  2. Sergejs Says:

    > The most dynamic presentation (literally!) was by the guys
    > that did “The Transformation-Driven Architecture”.

    I guess this is a mistake. I’m a co-author of this paper, and the paper is not about the things mentioned in the second paragraph.

  3. lispy Says:

    I am so sorry. It was in fact the “Model Talk” guys that gave that talk. Thank you for bringing this to my attention.

  4. atzmon Says:

    Regarding “new classes without new behavior” in ModelTalk runtime: Right, the ability to define totaly new behavior is important and we are working on this. Still, even without this ability, when you have a rich class model (that is, many classes for each type), the variability in bahvior is in the combination of object graphs that can be constructed (as instances of the new class). Equally important is the formation of new refined concepts for the users with the appropriate contraints.
    Note that this applies only to the runtime adapatibity capabilities of ModelTalk – in the IDE you can always write the java-class for the new model-class.

  5. atzmon Says:

    Regarding *why Java and not a dynamic language?* in ModelTalk.
    We chose Java for the following reasons:
    – Availability of mainstream 3rd party components for dependability (high performance, telco-grade non-functionals).
    – Availability of skilled work-force in the market.

  6. Why UML Fails to Add Value to the Design and Development Process « Learning Lisp Says:

    […] problem domain and the generated code has to map directly to the target environment. There are two linguistic abstraction barriers that must be implemented in order to make this work: the modeling language between the models and […]

  7. Lior Schachter Says:

    Changing the system structure by modifying existing classes or adding new classes can influence the runtime functionality of the system. This can be done by:
    1. Having a generic criteria mechanism (i.e. business rule engine), that can work reflectively on the new/modified structures.
    2. By composition (see Atzmon’s comment).
    3. The application code (business logic) itself is generic enough to accommodate new/modifies structures (and to do this the variability points should be identified in advance).

    Readers that wish to explore the topic of adaptive systems can read the following articles:
    1. Language support for adaptive object models using metaclasses. R. Razavi, N. Bouraqadi, J. W. Yoder, J.-F. Perrot, and R. Johnson.
    2. A Constraint-Driven Executable Model of Dynamic System Reconfiguration. D. Walsh, F. Bordeleau, B. Selic

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: