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.

17 Responses to “Lisp50 Notes part II: Model-View-Controller Considered Harmful”

  1. Andy Wingo Says:

    Really nice writeups, I appreciate them very much.

  2. Luís Says:

    Could you clarify John’s comment on GC papers? What did he mean?

  3. Davide Says:

    After a few months hacking away a webapps/workflow system using a MVC framework I came to realize the same thing.

    MVC limits you into a constrained view of your domain. You have to reinvent all your domain objects into their Model, Controller and View components spreading simple concepts into 3 distint implementation domains (ok… 2 if you some kind of ORM tool in place :)).

    MVC rocks for building websites/simple webapps. But for fancier things I wouldn’t recommending starting off with a MVC perspective of the problem. Midway through the project you might find yourself looking at the MVC wireframe as pretty shackles. 🙂

  4. charlie Says:

    @Luís : I got the impression that JonL was speaking against researching GC and only reporting the theory or only the _working_ example. Rather, they should both be reported and presented at the same time.

  5. Vidar Hokstad Says:

    If MVC causes those problems, they you are doing MVC wrong.

    If MVC does not lead to a separation of _independent_ concerns into independent units of code, you are doing it wrong.

    Lots of people are doing MVC really badly.

    If MVC is done right, then the model is your domain logic, and will remain the same whether you are doing a HTML interface or a JSON interface or console interface or a GUI app. The view encapsulate the behavior tied to displaying the information.

    The controller directs how it all hangs together – if the controller is more than a handful of lines, something stinks…

    Instead, what we often see in badly structured web apps is views that are full of domain logic, controllers that are full of domain logic, and models that are full of presentation logic. In those cases, doing MVC adds complexity instead of removing it.

    Blaming MVC for peoples lack of discipline in writing loosely coupled / highly cohesive code is putting the blame in the wrong place.

    Sure – if people don’t understand how to do MVC right, perhaps they shouldn’t try… 🙂

  6. Mark Miller Says:

    Just to add a little to the MVC discussion, Alan Kay could talk definitively about this because he was involved in devising MVC back at Xerox PARC. I got a hint a while back that there was something a bit off with MVC. In fact I’ve gotten several hints along the way that Smalltalk is not “perfect”. Alan Kay has pointed to a few things he wished were done differently, and he’s always said he hopes people will come along and “obsolete the darn thing”.

    I listened to a podcast with Dave Thomas (not the Dave Thomas of Pragmatic Programmer/Ruby fame) a while back. He said that MVC was kind of a hack to get around a hardware limitation of the Xerox Altos they were working with, when Smalltalk was being written. He said it was distressing to him to see that hardly anyone was coming up with a better model for displaying objects, but instead repeating the same (I believe he used the term “broken”) MVC model in other technologies simply because it came from Smalltalk. He said Morphic in Squeak was an improvement because it used a model that was more in line with how OO is supposed to work. From what I remember Morphic is an adaptation of the display technology/methodology used in Self.

    Re: the session you talk about here

    The interaction between Constanza and the AspectJ guy is an example of the divide between people who are pursuing real computer science and people in industry. The two definitely think differently.

    Something I’ve heard Alan Kay talk about occasionally is that it’s been shown through research that it’s possible to separate meaning from optimization. You can still get the speed you want without sacrificing the expression of the idea you’re trying to get across. This is something that most people in industry do not understand well if at all, but this is mainly because most don’t dare delve into the VM (I speak for myself at this point).

  7. lispy Says:

    Mark… that “AspectJ guy” we keep talking about…. He’s the co-author of “The Art of the Metaobject Protocol”!

  8. mat Says:

    The solution from Costanza was basically stated in 2 sentences, but unfortunately not being a lisper I didn’t really get it. Some use of a layered object, but I’m not sure to what end. Could you explain this in more generic terms, and how it might be applied to a language like C++, Ruby, etc.?

  9. Jack9 Says:

    The big problem with why MVC is done so badly is mentioned by every person criticizing others’ MVC implementation. Presentation in the Model. MVC is deceivingly named as there should always be an intermediate layer for binding and conditional View controls. Model is pure domain. View is pure presentation (The state of being presented) or “visible view”. Controller is delegation and (model) logic.

    This intermediate layer I call a “presentation layer” (The process of offering for consideration or display). Presentation unfortunately has multiple meanings in English. This does not lessen the need for the abstraction and has done wonders to streamline the mangled MVC frameworks I have had to use.

  10. Mark Miller Says:


    If you know he’s one of the co-authors, I guess you know his name? You seemed unsure. I’ve heard AMOP is an excellent book. I don’t know what to say. All I know is what you described. The “AspectJ guy”, from your description, made the same arguments I’ve heard many times by practitioners against computer scientists: They care about esoteric structures, but care nothing for efficiency. And so they cast aside just about anything the scientist says as “impractical”. Practitioners have a great faith in “premature optimization” which Hoare said is “the root of all evil in programming”. It just struck me that the “AspectJ guy” was so worried about speed. I understand that concern in IT operations. I used to deal with it. What I was saying was “you can keep the elegant expression of the idea, but optimize its execution in the VM.” It seemed like he didn’t consider that. Here’s another dead giveaway for what I’m talking about:

    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 AspectJ guy 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.)

    These kinds of arguments are classic hallmarks of someone who’s worked out in the field building commercial systems rather than working on real CS. As Alan Kay has emphasized, it’s about the culture. If the culture doesn’t understand what computing means then yes, you’re going to have to resort to political arguments and trying to establish installed bases to legitimize a new architecture. This is rather like saying that in order for people to believe in the concept of gravity as curved space you have to make political arguments in favor of it and establish a “base” of support for it. That isn’t science. It puts marketing and PR in the drivers seat, which brings everything into the industry’s current framework which has very little to do with CS. I understand the impulse the “AspectJ guy” had, but Pascal was right. He wasn’t talking like a scientist. He was talking like a vendor.

    Now, ultimately when you build a system that real people are going to use you do need to worry about performance, but again, if you address this from a scientific standpoint, the idea should be to optimize the execution of the existing expression, not compromise the expression so that the system runs faster.

    I think JonL was right as well. CS needs to look at the “why” and not make benchmarks the end-all, be-all of what’s valid.

  11. Andy Wingo Says:

    If I am reading this correctly, the “AspectJ guy” (an amusing term) is Kiczales, whose work is incredibly beautiful and perceptive IMO.

  12. lispy Says:

    Yeah, people kept talking about his “AspectJ” work, but he was never formally introduced.

  13. Diogo Lisboa Says:

    Kiczales is one of the very first researches in Aspect Oriented Programming. And, as said before, he also co-wrote AMOP. “The AspectJ guy” is a bit of an understatement. One of his papers explain AOP using Common Lisp.

  14. lispy Says:

    I’ve edited the post accordingly. However, be aware that when I make references above to someone called “Ruby Guy”, it was in fact *not* Yukihiro Matsumoto. I’m pretty sure of it. 😉

  15. Mark Miller Says:

    I remember the reason why Dave Thomas called the original MVC a “hack”. He said it went outside the OO notion of message passing, by introducing the concept of events. He said it was this concept (in addition to method calls) that got copied everwhere MVC was reimplemented. He said there are platforms now where this “hack” isn’t even necessary yet it still gets replicated.

  16. Dan Weinreb Says:

    It’s not surprising that people talked about history, rather than “how
    to finally win the language wars”. The Lisp50 event was intended to
    be about the history of Lisp.

    There are people who are purely academic, who create and understand big ideas but have little or no idea how things work in the real world. At the other end of the spectrum, there are practitioners who are unaware of big ideas and don’t think in terms of elegance and abstractions.

    Neither Pascal Costanza nor Gregor Kiczales is at either of those ends.

    Gregor is currently a computer science professor, and he has done brilliant work on deep concepts such as CLOS, the CLOS MOP, and Aspect-Oriented Programming. When he worked for me at Symbolics, he was an excellent software developer doing very practical work. After inventing and developing the concepts of Aspect-Oriented Programming, Gregor spent years making it real and practical. AspectJ can really be used with Java. He helped lobby for the introduction of metadata features in Java that would make AOP work more elegantly. He and his team made practical programming tools and IDE extensions for AspectJ, and he went around giving tutorials and workshops to teach people how to use AOP and benefit from it. I went to such a two-day workshop at MIT, and ended up very impressed.

    Pascal has spent his career in academia. In my opinion, he is one of the deepest thinkers about real issue of Common Lisp these days, particularly about CLOS and the CLOS MOP. (The last time I asked Gregor a hard question about those topics, he said that it had been so long since he’d been thinking about those things that he didn’t remember.) However, Pascal’s work tends strongly towards real, usable tools, as opposed to the kind of theoretical work that’s irrelevant to a practitioner.

    I suspect that his remark about not wanting to get into politics reflects his position as an academic: he does not want his field of research to be overly constrained by outside “political” issues (as opposed to outside practical issues).

    Lisp itself has been torn between two analogous polls. On one hand, Lisp has been treated as an environment for language exploration. On the other hand, there are a significant number of people making very real applications written in Lisp. So, for example, having a (pretty) well-defined standard like COmmon Lisp that emphasizes upward-compatibility and stability is good for the latter purpose, but not so good for the former. The way for Lisp to move ahead is not obvious. There will be a lot of discussion of this at the next International Lisp Conference. Full disclosure: I’m general chair of the conference, so I’m trying to encourage people to come. Please come! See

  17. Dan Weinreb Says:

    Sorry, I mean “two analogous paths”. And my comments about Pascal and Gregor, both friends of mine whom I very highly respect, are just my own opinions.

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: