Why UML Fails to Add Value to the Design and Development Process

While attending the Domain Specific Modeling workshop at OOPSLA 2008, I heard many pointed criticisms of UML. No one went into detail, so I bought a book on DSM by Steven Kelly and Juha-Pekka Tolvanen. The book was not cheap– over ninety bucks when tax was added. (Doh!) So far I’ve read the first four chapters, but they cover the problems of UML fairly well in those early sections and also outline the basic tenets of the DSM philosophy as well. I’ve synthesized the gist of their points below. All the good ideas about modeling architecture below are imperfect summaries of Kelly and Tolvanen’s work. The opinionated ideas about programming languages and tools are my own.

UML is applying an abstraction at the wrong end of the problem. It is primarily used to sketch object models for inferior languages. As such, it tends to explode into incomprehensible patterns of accidental complexity in order to accommodate the various “design patterns” that are used work around the lack of essential language features. Because the UML models cannot be compiled, executed, or interpreted, they are reduced to the level of mere documentation. As such, it is generally not even worth keeping in sync– the manual round trip from the code to the model and back is just too expensive for something that adds no more value to a project than an elaborate code comment. (Slides of elaborate UML diagrams, on the other hand, are nevertheless great for impressing the uninitiated in a presentation, of course– that goes without saying!) Efforts to “fix” UML tend to not to gain traction: the specification is itself too broad and coding environments and applications are themselves too diverse.

A modeling language needs to do three things on order to become useful:

First, it should map directly to domain problem concepts. UML is designed to map to coding architectures– and because of this it fails to raise the level of abstraction. The jump from assembler to C gave an order of magnitude increase in productivity because of its corresponding increase in abstraction. OOP languages and UML have not given the increase in productivity gains that they should have– in some cases they may even hurt productivity. Modelers should not even think about implementation details when they develop their language. Instead they need to focus on mapping their ideas directly to the domain concepts. (Note: this is not a new idea. Ableson and Sussman popularized this approach in their SICP lectures at MIT where they demonstrated how Scheme would allow them to define programs that called functions that didn’t even exist yet. They would start with the right solution… and then gradually build up until it would run. Michael Harrison talked about this when he described the ‘wishful thinking’ approach to programming from SICP.)

Second, the modeling language must be formalized. The modeling language must be a first-class citizen of the development process rather than just make-work for architects and project managers. It must be possible to generate useful executable code from the models made within the language. The language needs to add value not just in communicating with domain experts and helping them validate the “business logic”– it needs to add value at all levels of the development process. It needs to raise the level of abstraction for the code maintainers by allowing them to stop thinking about the underlying frameworks and libraries. It needs to contribute to testing efforts by eliminating the need for implementing certain classes of tests and also by providing a basis for generating other classes of tests automatically from the models. It needs to possible to generate documentation automatically from the models. The models should be useful in and of themselves and should be significantly useful to all development tasks downstream from them.

Finally, the modeling language should have first-class tooling support. The tools should not be thought of as IDE extensions for programmers. These tools are not “wizards” to generate ugly code or partial stubs for developers to flesh out. The tooling should stand alone for the domain experts; if they have to think about the code at all then the tools are developing in the wrong direction. Expert developers aware of the intricacies of the domain problem need to organize their frameworks and libraries in such a way that the models can be “compiled” into fully functioning code. The correct analogy for this is, again, to think in terms of compiling C to machine code. The C compilers are created by machine language experts. C programmers do not modify the compiled machine code– they use the results in practically all cases. The C programming environment allows the programmer to work at a higher level– without having to think in terms of the underlying machine code or hardware. C is, in effect, a modeling language for machine code.

So, to get a modeling language that is actually useful, you have to go “Domain Specific” on both sides of the problem: the modeling language has to map directly to the 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: 1) the modeling language between the models and the generated code and 2) the framework between the generated code and the target libraries. You must build up from your core code components to the framework… and you must build down from the models to the generated code. If the code generation process is too complicated, you may need better abstractions at the framework level. If the code generation process is impossible, then the modeling language may not be providing a detailed enough description of the requirements. If there is too much repetition in the models, then the modeling language will need to be extended to cover additional concepts.

As Steven Kelly said in a 2006 article, “To make model-driven development work this way, you cannot use a general-purpose design language like UML and a modeling tool’s built-in code generator. The people that created UML did not design it for describing applications in your domain, or for generating code other than skeletons. Despite the efforts of many to make it suitable for generation, no one has ever, or will ever, make it happen in a way which is still smart and convenient. An application’s behavior and the rules it has to adhere to are domain-specific. To capture that effectively and completely in a graphical design, you need a Domain-Specific Modeling language.”

Update 10/30/08:

I have discovered some interesting ideas from the opposite point of view. Here is some remarks from Franco Civello— someone that has used UML successfully in model driven development:

“… having produced informal use cases to clarify requirements, and a domain model to get an initial understanding of the subject area, the analyst produces a precise specification model, in UML, in which the system to be developed is represented as an object, belonging to a type (note, not a class, as the system is an abstraction used to define visible behaviour, not a software entity to be directly implemented in e.g. Java).”

Notice the key similarity there with the Kelly/Tolvanen Tolvanen approach. Civello is not using UML to describe the code architecture– he is mapping the UML more toward the problem domain.

“Steps in the use case flows are then formalised as operations on the system type, with a declarative specification of behaviour based on the notion of functional contract, written as pre- and post-conditions expressed on an underlying model (the system type model, derived closely from the domain model).”

Again, this point reflects back to my second point: there must be a formalization of the modeling language at some point. Note also, we have (possibly) an analog to the declarative approaches that I saw in the ModelTalk presentation last week.

“UML static modelling gives you the language to represent the state of the system in abstract and yet precise terms. Just don’t think of your classes as software things with methods and member data, but as specification types that give you the vocabulary to specify the business outcome of a system operation. These types can have attributes, associations, queries, constraints and definitions, all powerful UML concepts, but no state-changing operations. The only state-changing operations are defined at the system level, and are not elaborated into message-based solutions, but just specified declaratively in terms of business logic, steering clear of any design decisions.”

Lisp50 Notes part VI: The Future of Lisp

In a sense, I’ve written all the other posts in this series just so you can understand what happened when Rich Hickey gave his talk. Maybe you’ve already read a post from a Lisp hacker that was there, so you think you already know how this ends. Think again. Let me break this down so you can see the full context in which he was speaking:

* We started with the Steele/Gabriel “meta-talk.” As the guy on LispCast said, this talk inadvertently gave an impression of general stagnation among the Common Lisp community.

* We’d heard much of the history of Lisp and Common Lisp… and the story seemed to indicate that the Lisp community spent too much energy fighting among themselves before they could finally realize that C and C++ were their real enemies.

* Fritza Kunze’s idea of completing a new Lisp within 12 months pretty much tanked.

* Those of us that held out hopes for Scheme being the answer to our dreams were disappointed to hear William Clinger describe in exquisite detail all of the problems with the R6RS process.

I don’t know when it was, but at some point a guy toward the front pleaded for just some basic libraries for GUI’s, database access, and web services. Someone tried to punt on that question, but a consensus emerged that it was way too hard for anyone that just wanted to build a stupid application. Later on we would hear about some of the technical reasons behind that difficulty, but still… there was no good answer on the table.

So into that setting comes Rich Hickey. We wanted a new Lisp. A simpler Lisp. A cleaned up Lisp with decent library support. We wanted to be able to use Lisp on our day jobs and not just on “the back forty.” And Rich Hickey basically says to us, “I’ve already got one.” (!)

And not only that… he gave an really good presentation. I admit, I’m a snob. I never really looked at Clojure myself– one mention of the word “Java” and my mind was closed to whatever it had to offer. But he knew all of my objections and had clear and concise answers for them. He also knew about the kinds of frustrations I’ve had with Common Lisp… and he had answers for those as well. But he also knew what makes Lisp great. The thing that clinched it was that he knew exactly why we were so enamored with Alan Perlis. And he could take Perlis’s ideas and take them one step further.

It was electrifying.

This is the thing that sold me: hash tables in Common Lisp are a pain to work with. As Hickey said, “you can’t write lispy code with Lisp hash tables.” But take a look at how you do hash tables in Clojure:

Clojure Data Structures

In short, Clojure provides better ways to produce homogeneous code that operates on heterogeneous data structures.  Clojure provides more uniformity in data structure access.  Clojure provides something I’ve wanted for months, but never fully imagined on my own.

And unlike some of the talks that were tinged with a little bitterness, a sense of loss, or a sense of nostalgia, Hickey was upbeat and forward looking. “Lisp as an idea is still vibrant, especially among young developers,” he said. “People are excited about Lisp and the idea of Lisp.”

At end of the talk, JonL was the first to speak, as usual. I think even he was temporarily speechless. While he might have had reservations about the hash table trick that I like so much, he still gave his blessing to Hicky: “You love to go to Lisp and you understand why,” he said with clear admiration. The sense of relief that passed over the room at that point was palpable. After JonL was finished responding, a young developer in the back could not contain himself. “This is the best thing I’ve ever heard in any conference,” he said. “Great work.”

And that’s what the Lisp50 conference was about.

Lisp50 Notes part V: Interlisp, PARC, and the Common Lisp Consolidation Wars

Okay, quick… how many people besides Alan Kay can you name that worked at Xerox PARC? Not very many, eh? Yeah, that’s your loss. It wasn’t all about the guys like Kay that get all the glory, you know….

Warren Teitelman was by far my favorite speaker. Unfortunately my notes got worse as the day drug on, so I simply cannot do justice to him. Yeah, Guy Steele is…you know… Guy Steele. (OMG! The guy who wrote the lambda papers is sitting right behind me! Uh… can I have your autograph?) Fritz Kunze seemed like he’d have been a great guy to go out drinking with. And we’d heard from John McCarthy himself, for crying out loud…. But Teitelman came off as being at once knowledgeable and approachable. He didn’t exude any of the “dysfunctional Lisp-programmer” type attitudes at all. (Not that anyone else did….) And his work at PARC and InterLisp seemed to address things that the Lisp community as a whole seems to have overlooked somewhat in the years since. He’d been right in the middle of some pretty significant moments of computer history, but he still seemed like a pretty humble guy in spite of it.

Teitelman’s early work had to do with debugging Lisp programs while they were still running. When he presented it at a conference in 1968, he was completely flamed by Dijkstra! “We shouldn’t make it easier for programmers to recover from bugs,” Dijkstra said angrily. (He’d been visibly shaking his head through out the talk even before this outburst.) “How many bugs are we going to tolerate?” he demanded. “Seven,” Teitelman shot back. The audience laughed, of course, but Dijkstra never forgave him. From that day forward, Dijkstra referred to him as the Internationally Renowned Computer Entomologist!

In 1970 he worked on the DWIM features of InterLisp. He’d been discussing the feature for weeks, but somehow the implications of it were just not evident to the people he worked with. The idea was that the computer should be able to automatically correct doubled and transposed characters and such like. He rolled out the code for it into production and soon one of his colleages burst into the room and explained breathlessly: “I was talking on the phone and typed the wrong thing… and… and the computer corrected it!” Until you have something out there, the user can’t be sure what it can do, Teitelman said.

So yes… we were all sitting there listening to the guy that pretty much impelented the first spell checker, the first undo system (for a Lisp environment), and the first online help system. There were some court cases between Microsoft and Apple back in the eighties over who had these features first, but Teitelman of course has printouts from long before either one were on the scene! I think he was one of the first people to get a personal computer. (It cost $150,000…. It was something called a “Dorado”.) And when windowing systems were first developed at PARC, he rewired the Lisp programming tools to work with it. He was the first person to use the term “programming enviornment” in print. Incredible.

He concluded by quoting Alan Kay as saying that there aren’t enough languages these days that are late binding self-reflexive. Teitelman said that we’ve got to strive to separate the business process from the code. Your average developer, though, just thinks, “hey… I can easily build this rule in Java!” Don’t!!! This is a concept that people don’t get. If the program is rapidly changing or needs to look at itself, then you really need those late binding self-reflexive features, he said.

After hearing about many of the wonderful developments in the various branches of Lisp, Kent Pitman told us about extremely Machiavellian process of consolidating them under Common Lisp. (Earlier in the day, Fritz Kunze had remarked that this was a “deeply flawed” process and that the mailing archive revealed it to be an “unfolding disaster.”) Pitman had a strikingly cynical slide detailing the strategies of the process organizers: “due process is an illusion,” it said. Other bullet points sounded like something out the Art of War: “turn opponents against each other and let them wear each other down.” “Soliciting volunteers gives critics something to do,” another said, “which dilutes their passion, pacifies them, and makes them feel involved.” In order to isolate the Interlisp guys, dark rumors were spread about various computing nightmares caused by Teitelman’s DWIM features!

While at MIT, Pitman recounted how he’d written the MacLisp manual and naively signed the copyright over to them. “Oh, it’s just a formality,” they said. Not really understanding what copyright was about, he didn’t really think anything of it. He also didn’t see a dime of the money that MIT brought in with the book sales. Pitman wrote up the standard for the Common Lisp project and was very careful to avoid a similar deal for that. The committee would vote on the truth of the various propositions, but he would do all of the writing. No matter what, he was not going to give up the copyright for any reason!

When ANSI Common Lisp was finally finished, Pitman described how people simply could not come to grips with the fact that it was portable. “What platform is this implementation for?” people would ask. After failing to get people to try it out, these same people would end up calling two years later and say, “hey, you know… we tried it and it works. Can we use this?” Talk abut not getting the point!

He had another slide detailing an eerie phone conversation between him and someone from ANSI. Each side engaged in subtle forms of intimidation to try to get their way. After being pushed to turn it over, Pitman said flatly: “Our commitee just voted on the truth of things, not the text. Copyright covers the form of the text, not the truth.” He held his ground and somehow ANSI figured something out. The tragedy is that you can’t get a decent copy of the language standard anymore! And due to all of these maneuverings, it was years before Pitman could get his work published on the web… (Steele’s CLtL books actually beat him, much to his chagrin….) Stallman was not happy with the way Pitman handled copyrights: “I don’t care about useful,” he said, “it has to be free!”

Pitman seemed to have a knack for being a day late and a dollar short. He decided to write a Lisp based web server back in the nineties and after six months of working on it Franz (I think) came out with a free one. As a result of this experience, he has reservations about not only giving up his copyrights, but also with the open source development model in general….

(I apologize for the poor quality of this post.  There so much that could be done to get this right, but I have limited time, etc.  Hopefully this will suffice to give people a sense of the sessions until something better is released.)

Lisp50 Notes part IV: Fritz Kunze Enters the Lisp Mine Field

Fritz Kunze (co-founder of Franz Incorporated) gave a talk called “Careening through Lisp mind fields.” He was very informal in his delivery and had lots of humorous anecdotes to go along with his recollections and “armchair” speculations. Combined with the opening “meta talk” by Steel and Gabriel and also JonL’s extremely informal “meaning of life” type talk, one gets the impression that many of the major players in the Lisp world are unable to go along with any sort of standard social convention. Somehow, some way… they all have to find they own way of doing things and their own quirky personal inflections impact everything they do.

Early on in his talk he told a story about the creator of Eliza: Joseph Weizenbaum. (Weizenbaum died earlier this year, by the way.) The story goes that he walked into someones office and the guy in there says, hey– check out my program. You ask it questions and it answers yes or no! So they tried a few, and sure enough, the answers were right every single time. Weizenbaum asked him if it answers questions that are in German. The guy says, sure, but you have to do the typing. So Weizenbaum types in a couple of questions in German and the answers were correct in both cases. “I have to think about this,” he said, and he stomped off to his office. Not too long later he had Eliza up and running. And the program that inspired him? It just gave a “yes” if there were an odd number of characters in the question! (Weizenbaum would later go through a slightly paranoid/Luddite type phase when he was shocked at how ordinary people ascribed ‘real’ intelligence to his Eliza program. He criticized the role of artificial intelligence in society with his book, Computer Power and Human Reason.)

After showing some images created by an extremely unusual Lisp-based drawing program (and talking about some Eliza spinoffs), he then delved into the link between aspergers, autism, emotional immaturity and programming ability. He had a slide outlining some personality traits and a collective hush fell over the room as we all realized that we were part of some sort of incomprehensible evolutionary programmer-genius phenomenon. Okay, okay… I’m exaggerating. But the slide was interesting: it included stuff like “uncomfortable at parties” and “dislikes travelling”. (Are you a misunderstood genius? Take this quiz!) He talked about some of the problems in managing Lisp guys: “There’s a limit to the number of smart people you can put in a room. Things will break down and they won’t talk to each other.” After some more anecdotes and also some unscientific speculations, he concluded that therapy was the only solution… therapy, that is, for the normal people that have to work with the “asperger” guys! After a while, the managers and salesmen begin to emulate the smart people, he explained. If the company culture as whole absorbs too many “aspergerisms”, then the business ceases to be able to talk to its customers!

He concluded his talk with some ideas about the future of lisp. He thought that it would be possible for Lisp to reposition itself as sort of the ultimate DSL for making web pages. The problem, though, is that the Lisp community is made up of people who can neither compromise nor give up control. He proposed that a non-profit Lisp foundation be set up with the goal of producing a new Lisp within 12 months. “If you study history, you repeat yourself over and over again,” he said. “You’ve got to do something brand new!”

JonL stood up immediately following the talk: “As usual, I couldn’t disagree more with everything you said!” JonL was clearly disgusted, and… uh… unwilling to compromise on any of the points what were presented. “Nothing we can do today can change Lisp’s position in the market,” he concluded.

Lisp50 Notes part III: McCarthy Reaffirms the Importance of Having Access to the Abstract Syntax

Due to health reasons, John McCarthy could not attend the conference. Alan Kay was (I hear) heading somewhere else in the evening– it would be a tight fit for his schedule if he was going to be there and also make his other “date”. Seeing as McCarthy couldn’t make it, Kay decided not to come. Instead, Guy Steele conducted the interview by phone.

(What as most striking to me about this was just how careful Steele was and how precise he was with his language. He appeared to already know the answers to all the questions… and if things got sidetracked or drifted off in a random or unclear direction, he always knew just what to say to pull things back together and pin things down. Just observing this interview process, it was clear that Guy was exactly the kind of person that you’d want to have running a massive language standards type project. It’s no accident that Steele is as influential as he is. He was very different from the traditional stereotype of a Lisp hacker. Throughout the day, I’d run into people and say… that’s Guy Steele over there! That’s the guy who wrote the lambda papers!  Unfortunately, this didn’t seem to mean much to the typical conference goer….)

When asked what should have been added to Lisp, McCarthy said he would like to add some direct logic, but he didn’t know how to do that in a good way. Steele mentioned something about the Lisp-Prolog people in an aside. (I think Norvig implemented Prolog in Common Lisp in PAIP….)

When asked what separates a good programming language from a bad one, McCarthy said he had one advocacy: a language should have access to its own abstract syntax. Any program which works with programs involves abstract syntax. If you take Java and you want to write a program that deals with Java programs, then you’ve got to scan it and look up the plus sign and its precedents. (What a mess!)

Steele asked about the variation in the implementation of key-value pairs and association lisps. Was this an accident or a reinvention? McCarthy said he invented both– when he invented the second, he wasn’t thinking about what he’d done the first time.

Steele asked if s-expressions were good or bad. McCarthy said his original idea was to make it like Fortran. (With m-expressions, that is.) Steve Russel took McCarthy’s eval and said you could just program in s-expressions. Being a “conservative guy”, McCarthy thought this was a bad idea. Steele appeared to be slightly taken aback by the idea of such a revolutionary figure describing themselves as “conservative.” McCarthy said, “everybody’s conservative about what they’ve been doing.”

(I have several notes on the significance and uses of abstract syntax, but I don’t understand them. If anyone out there knows what he meant about having different versions of it– say, one to write in and one that’s pretty– then please help elucidate this. He also said something about not having really any good examples of Lisp programs that write programs. I think that’s what he said; I’d like to know more about this, too.)

Steele noted that most new languages have a “boss”. (Perl has Larry, Python has Guido, etc.) Steele then asked who was that boss of Lisp. McCarthy cracked back, “if Lisp has any boss, it’s you! You wrote the language manual!” The audience laughed. “There was no boss,” McCarthy said. “I never attempted to be the boss.” (And of course, as we had seen in the historical perspectives on Lisp earlier in the day, there were tons of Lisp implementations in the sixties and seventies. Each “tribe” was going off in their own directions and people couldn’t really consolidate them at the time because of hardware limitations.) “Even in the early days I wasn’t the boss of Lisp,” he said. “People could get things into Lisp without me knowing it.”

Steele asked what’s his one idea that could have had the most practical impact if it had actually gotten implemented. McCarthy said, if IBM had taken his ideas about time sharing… then things would have been quite a bit better in the 1960’s. At this point, JonL stood up and started clapping.

The final parts of the interview covered Perlis’s attachment to Formula-Algol before “apologizing” and agreeing with the Lisp approach. McCarthy said he had looked at Formula-Algol when they first proposed it and thought it was pretty bad: it overloaded the algebraic operations and applied them to formulas, he said. He concluded by saying he didn’t know what the alternatives were to abstract syntax. The most important problem we can be working on, he said, was formalizing common sense.

Lisp50 Notes part II: Model-View-Controller Considered Harmful

Herbert Stoyan was next to talk at the conference. He covered many obscure details of the earliest days of Lisp. My notes are pretty sparse, but I remember him showing several pictures of McCarthy and Minsky– he said, “Marvin Minsky, he hasn’t ever changed. But if I were to show you twenty pictures of McCarthy, he’d be completely different in each one!” Somewhere in there Richard Gabriel (I think) stood up and said that, “John McCarthy is the worst programmer on the planet. He calls me up for the simplest things!” I’m pretty sure it was some sort of strange Lisp-type humor, as everyone laughed.

Stoyan has a Lisp museum in Germany, but he’s in the process of moving everything to the Computer History Museum in Mountain View, California. Everyone with Lisp artifacts needs to contact this guy and find a home for them. (The guy to talk to is Paul McJones.)  As a cautionary tale, he noted that we’ve already lost the first Lisp compiler– the guy who made it was actually a mathematician and didn’t even get a PHD in Computer Science! (Stoyan had a slide of the guy’s photo.) During the questions after the talk, JonL recalled McCarthy talking about one of the newer machines in the early days. When questioned about its memory limitations, McCarthy said, “You can’t possibly cons too much on this new machine!” This story got a good laugh from the crowd.

Pascal Costanza was up next. He spoke on his research about Context Oriented Programming. The basic idea is that the computer should behave differently depending on the situation– for example, if the computer “knew” the user was angry due to heart rate, etc. then it should maybe not do certain things. He noted that you can implement this sort of thing naively by having lots of if-then blocks everywhere. That’s no fun, though. Then he made what I thought was a bombshell of a point: Model-View-Controller spreads code dealing with a single object’s behavior and spreads it all over the system. (He had a slide showning a UML diagram raging out of control.) He said the original idea of OOP was that behavior is defined just in the class where it belongs. With behavior spread all over the object model, objects no longer “know” how to behave!

Here’s how Costanza makes that point in his paper: “Among prominent domains to motivate object-oriented programming, graphics and people are the most widely used examples. A reason for their popularity is the fact that one can easily introduce the idea that objects know how to behave, that is how to react to messages…. However, when programs become more complex, the code for displaying objects is usually not contained in the classes to be displayed because there is a need to have different views on the same objects, often at the same time. Therefore, such code is separated into view objects that need to be notified of changes to model objects (such as instances of Rectangle or Person), leading to variants of the well-known Model-View-Controller (MVC) framework originally introduced with Smalltalk. Unfortunately, this distribution of responsibilities that conceptually belong to a single object complicates the original simplicity of the object-oriented paradigm. For this reason, some more recent object systems like Self and Squeak have even changed their frameworks for presenting objects on the screen back to the original idea that objects maintain their own knowledge about how to display themselves. However, with that they lose the desired property to offer different views of the same objects. ContextL provides an alternative approach that both keeps the conceptual simplicity that all of an object’s behavior is indeed associated with that object and still allows an object to be viewed in different ways depending on the context.”

Costanza then fired up Lispworks Professional Edition and started hammering out code. This was all CLOS code. He wrote some commands to define a class: define-layered-class, define-layered-function, define-layered-method, and deflayer. To call an object in a given context, you call with-active-layers and pass it a list of layers, and method expression against your object: (with-active-layers (employment) (display *pascal*)). He then paused for questions and the crowd went a little crazy. People wanted know how these features interacted with inheritance and how to code it to know that other layers are active given certain conditions. Gregor Kiczales was floored: “We in the CLOS community have failed to explain why multiple inheritance is important. The problem is complicated, but our code is simpler.” He wanted to know what we could do to actually win the “political” argument. Pascal responded, “I don’t care about the political discussions. I think we should be focused on science.” (In an informal discussion out in the hall, someone noted that the Kiczales didn’t think ideas in the lab actually proved anything– in order to really demonstrate the validity of an idea, you have to have a base of users that are actually applying it in a real situation.)

[Note: Gregor Kiczales is one of the co-authors of The Art of the Metaobject Protocol.  Can you imagine presenting a paper about CLOS and having him ask you questions afterward?!  Costanza did not flinch….]

The Ruby coder that had jumped in the DSM fishbowl the night before returned right about then. From the back of the room he asked (somewhat agitatedly, no less) how you could possibly save the contexts in the case of a real web application. (I thing he was coming from a… what is it… a Spring or a Hibernate standpoint or something. Something like that.) Costanza responded that if you knew what you were doing, you could get at everything. Ruby guy also wanted know how you could possibly handle exceptions with this stuff.

Costanza put up a slide showing some benchmarks. Inexplicably, he actually made the code faster in some situations just by adding contexts! Everyone wanted to know how this could be, and Costanza responded that it didn’t mean anything. He said to never optimize on the basis of guesses; efficiency is not important– give us more flexibility, he declared! Kiczales couldn’t handle this– in most of the meetings he’d ever been in, a 1% loss of efficiency would mean he’d get shown the door. “We can not ship something that is less effective than the thing we shipped before,” he said. Costanza said that most of our machines are idle– who cares?! Ruby and Python very popular and they are dog-slow…. One percent? People these days don’t care about a ten percent performance hit!

JonL closed the final remarks with a word of caution about benchmarking. The competitive impulse magnifies trivial differences. Back in the day, a meaningless difference would mean that a Lisp hacker would be dead in the water and have to go back to C. JonL said there should be no more papers on Garbage Collectors unless you had an example. There should be no more benchmarking without theory and no more theory without benchmarking– it’s not the magnitude, it’s the “why” that matters.

Lisp50 Notes part I: JonL Recalls How Sussman Revealed the Nature of Intelligence…

This was a totally different crowd than what I saw at the DSM workshop. There were lots more Americans here. You had a mix of bearded Lisp Hackers, a few not-yet-middle-aged guys who were running significant projects, and then some younger guys that were either still in college or were not out for very long.

To understand the conference, you’ve got to understand the backdrop. I’d just sat through a day of presentations that were mostly focused on Java, Eclipse, and UML diagrams. The “last word” of the day was from a Small Talk programmer who said that the competing tools in his area of work had not improved upon the solutions that he’d had 15 years ago or so. Educators attending the symposium were talking over lunch about how they couldn’t find good examples for applying some of the concepts they were teaching. Anybody I met, I would say to them: “I can’t believe I’m going to see John McCarthy and Alan Kay tomorrow!” This didn’t mean anything really to most people I tried to chat with. Collectively, the net effect of the preceding day was to produce a mild sensation of frustration, disappointment, and alienation.

I was nearly late for the opening session of Lisp50. I rushed in just barely in the nick of time… only to find that Lisp50 was starting ten minutes late or so. There was no posting of the schedule anywhere that I saw while the workshop I was in the previous day had a copy of the schedule at every seat and even a booklet of all the papers to be presented. Add to this the fact that many of the Lisp speakers had some sort of trouble with their Power Point slide and that there was no slot on the schedule for a break for an evening meal… and it just appeared that collectively the Lisp community was doing everything it could to meet its own stereotypical expectations!

So the first “talk” was Guy Steel and Richard Gabriel re-enacting a talk they gave back in 1993. This was amusing in places– the audience laughed in most of the same places as the 1993 audience did– but it was a little frustrating. I mean, we have Steel and Gabriel on stage… and they’re reading. I want to know what they have to say about right now. I want them to preach to the choir. I want them explain how to finally win the “language wars” and why it matters. Something. Anything! Instead we get a play by play of how Lisp communities evolved and coagulated in the seventies and eighties. The net effect of this was to leave the impression that we’re reduced to the significance level of, say, a confederate civil-war reenactor. The battle is over. We lost. There’s nothing left but pin down the final details of the history of our side so we can bury it all. Yes, that’s it… that’s is exactly. I felt like I was at a funeral! This “talk” set a tone that our proceedings were going to be more about nostalgia than anything else. (I’m not saying this wasn’t interesting… I’m just talking about the tone here given the context. Maybe I was the only one the felt this way, but I think the general pulse of the crowd was mildly uncomfortable because of these sorts of unspoken memes floating around in our collective unconsciousness.)

JonL White was the next speaker. I simply cannot do justice to what he said and what he represents. Suffice it to say, if all you know about Lisp is some stuff you read in a Paul Graham essay and a few textbooks here and there… then you really don’t know anything. This man has a tremendous intellect… and has had a hand in nearly everything as far as Lisp is concerned. (Did I see that right on the slide of specific language contributions that he was responsible for defun? I wish I had that slide….) Fifty years from now, I’m going to be telling people, “I saw JonL at the Lisp50 conference.” I cannot do justice to this guy’s presentation, so here’s just a few tidbits:

* He used several Alan Perlis quotes to set the tone. These were all great quotes; the same ones from SICP that inspire me so much. JonL really misses Perlis.

* He mentioned something about dealing with the archetypal “bipolar Lisp programmer” types on the job and exclaimed, “how can you supervise a Lisp guy?! You just take what he does…!”

* JonL was responsible for hiring Stallman at the MIT AI Lab. Stallman has contested this and claimed that some random administrator was responsible. JonL explained that the administrator’s don’t decide anything– the way you get in is by making friends with someone in the lab.

* JonL encouraged us all to go to the International Lisp conference. “Lisp is the back forty for a lot of people,” he said. (That is, you do whatever you need to do when you work for the master, but if the work is for yourself, a lot of people tend to do it in Lisp.)

JonL spoke about growing up in the Ozarks. He talked about how his parents influenced him intellectually and genetically. He talked about how racist everyone was there and how he took the slurs personally somehow…. He talked about how he ended hanging out with Jews and how he sort of became, as it were, an “honorary Jew” because they figured if he was so smart, he must be a Jew, too. (I’m trying not to mangle this too badly.) So Sussman asks him one day, “Why are Jews so smart?” Now, JonL was pained at recounting the answer he gave. He confessed to having picked up on some the racism that was endemic to the Ozarks. “Uh… must be their genes,” he’d said back then. Sussman was very irritated at this answer. “WRONG,” he said, “it’s the LAW!”

I have no idea how many people “got” this. JonL wasn’t too sure either. The default assumption is that we’re all rabid libertarians and atheists, I suppose. JonL explained that Sussman was referring to the Torah… the Jewish scriptures. Sussman argued that because Jewish fathers are required to teach their children how to read and write– so they could understand the Law– that this somehow gave them a fantastic intellectual foundation. JonL referred to a talk that Sussman gave somewhere– it was extemporaneous, but better than most prepared talks. (I want to see this talk if anyone finds a recording!) JonL was totally blown away by this talk… the best thing he’d ever heard. But in it, Sussman argued that intelligence was transmittable and improvable. Somehow, if you can (legitimately) learn more words, you expand your ability to think. This tied into symbolic thinking being about giving names to things. (This reminds me of that strange story in Genesis about Adam naming the animals in the garden of Eden.) Sussman said, “great ideas can be understood by an ordinary person.”

(That’s a very encouraging thought. I suppose there’s hope even for us “average developers.” This is all the more reason to continue learning a new programming language every year or so. It kind of gives one a little more respect for all of those among the USA’s founding fathers that could read and write Latin, Greek, and Hebrew….)

JonL had spoken earlier about how he’d gotten a great prep-school type education even though he grew up out in the middle of nowhere in the Ozarks. Farming and industry were all dead there, but… they still had this heritage of education. JonL pointed out how, for us Americans, this traces back to the Puritans. The fundamental concept of our form of government is that man’s government cannot work. That’s why you have all of those checks and balances– those Puritan-types did not trust man to get things right! (Note to self: compare and contrast this with socialism sometime. Try not to use the word “hubris” gratuitously.) Our education was meant to provide a check on our untrustworthy governmental institutions– but just look at how things are developing in, say, the California public schools.  Things do not look good; we’ve lost something….

That’s the gist of JonL’s talk based just on my hasty and imperfect notes. (That last “tidbit” sort of raged out of control there….)  Please feel free to post corrections and clarifications if you feel they are required.  I didn’t get the feel that he was a raving evangelical or anything, but I was surprised by the philosophical bent to his talk.  But what do you expect from a guy that cuts off his tie with a pair of pruning shears…!

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

In the final segment of the Sunday sessions, we had a “goldfish bowl.” Steven Kelly, Goren Olsen, Laurent Safa, and Arturo Sanchez each said a few words about “Evolution of DSM’s”. Then other participants could filter into the circle of chairs, ask questions and participate in the discussion, and then “fade out” when they were done.

Steve opened up with a point that (just like Tennessee in 1925!), people just don’t talk about Evolution in DSM. Everything assumes that you write this thing and then you’re done! This attitude is sufficient to get a working prototype for a research paper, but in the real world… clients may not tolerate this so much. He had a very interesting illustration of the interrelationships of the Model Language, the Models, the Generator, the Framework, and the Generated Code.  How does a change in the model language cascade through a running system?

As the session topics and crowd response indicated during the day, most people in the room really wanted tools to help cope with evolutionary issues. They wanted to know how to deploy model modifications into an environment where previous iterations are still in operation. They wanted IDE tools to be seamless… they wanted IDE’s to understand the maintenance nightmare that DSM can unleash. They want things to just work– they want “flow through.” If the model changes, they want everything downstream of the model to be patched or rebuilt automatically. They want transformations to be automatically generated to handle all of this housecleaning. There seemed to be a consensus that UML just didn’t work– it’s too general. At the same time, there were hardly any presentations that didn’t have a completely incomprehensible UML diagram in their slides.

Steve would go into detail about what sort of things tend to break among the various competing tool sets. He noted that the XML-based tools are just too new as of yet to have any sort of robust answer to DSM evolution issues. The older tools have features for this because customers insisted on it. If they got put in a situation where their models suddenly stopped working, for some reason they just didn’t tend to respond well to the notion that they were going to have do all of the grunt work of fixing everything by hand….

Arturo disagreed with all of this. He pointed out that DSM’s should emphasize the “specific” part of the acronym. If you can handle all of this evolution stuff, what you’re developing is just another general purpose programming language! Steve didn’t appear to think that an attitude like this could last long in the presence of real paying clients. Also, he pointed out that if you can’t evolve, then you’ve pretty much lost the chance to ever reuse anything.

Steve spoke in specific terms about what sort of changes the current tools can tolerate. Most of them will let you add new properties. Some XML tools would make new properties “required”, though, which would cause the old models to break. Some tools could tolerate a renaming. Luis Pedro wondered why you couldn’t use new models and old models together– he’d used a database tool that could manage to produce the right SQL for querying something regardless of the actual version in operation. Steve didn’t seem to think that such tactics could work with DSM.

At some point, a Ruby coder jumped in and said that in the real world, you just don’t have time to mess with a bunch of pointless UML diagrams and fancy modeling. He urged everyone to work toward creating a system where you could make DSL’s so quickly that it would be easier to start over than it would be to “evolve”.

At the end of the discussion, Arturo reiterated his point that mixing evolution with DSM’s was crazy. (He had a real zinger– something like, DSM’s are revolution… and if you add evolution to them, you’ll get some serious retribution. Argh. I missed the last word, but it was something like that. Devolution? Contribution?) Steve said he was depressed. The current crop of tools are all inferior to the tool he was using 13 years ago! (Hint: Steve’s tools are built on Small Talk.) Luis Pedro reiterated the point that reusability required evolution.

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!

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.

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

Nearly everyone attending this workshop was from Europe. There was a guy from Israel, some folks from East Asia, and a couple of guys from US Air-force Research… but I was embarrassed at how few Americans were there seeing as we were in the US and all. Almost everyone in the room was there to deliver a paper of some kind. Most of the rest were students looking for PHD topics. While a couple of presenters happened to be project leads working on large applications that utilised DMS’s, there did not appear to be any “ordinary” full-time developer types represented. (I guess they were busy with the refactoring tutorials or something.)

Most of the tools demonstrated of discussed were Eclipse based. I saw very little DSL code, if any. Most of the conversation focused on meta-models, rules, grammars, syntax trees, transformations, visitors, ANTLR, and Petri Nets.

Presentations seemed very hit or miss with the crowd. Sometimes there would be almost no questions, other times someone in the crowd would get hung up on semantics or some pedantic correction. These would often end in an impasse with the presenter and questioner not having achieved any sort of consensus or meeting of the minds. Worse than that, it appeared that occasionally a presentation would get shot down as being basically pointless or so limited in scope as to be of no use. Some questions would delve more into practical development and maintenance issues, but there just wasn’t time to do more than scratch the surface of that sort of thing.

Arturo Sanchez gave the most animated talk of the morning sessions. While others appeared to get lost in a world of tools and abstractions, Sanchez emphasized that the point of DSM was “empowering users to solve problems without the assistance of software developers.” He appeared to delight in going against the grain of his peers– he was intentionally adapting his approach to the problem space instead of forcing things to flow the way “theory” dictates.

From the standpoint of a run-of-the-mill IT application developer, his project was to very easy to relate to: English teachers at his college would use his program to highlight text in a paper, right click, and then classify it as being one of a set of Patterns and Anti patterns. A comment would then be added to the section of text… and a grade summary at the end of the Word Document would summarize the final grade.

The hierarchy of patterns and anti-patterns were stored in an XML file that the user could modify via his GUI– he called this data an “Ontology”. The right-click-and drag maneuver the user used to highlight text he referred to as a “gesture”. Put the two together and you have Domain Specific Modeling! I may be in left field here, but by that definition, VB developers are doing DSM all the time– all they need is a GUI and a database! Still, he wanted to do everything he could to eliminate as much context switching on the part of the users as he could. I wish more application developers cared about that….

(Note: I am neither a computer scientist nor a journalist. These are just first-hand impressions of the workshop from someone that has no experience working with DSM. As always, YMMV. Please feel free to add any corrections or clarifications that you might feel these rough notes require.)