Messily Veneered C

A recap: we saw that Model-View-Controller started life as Thing-Model-View-Editor, a way of approaching problems to design Smalltalk user interfaces. As Smalltalk-80 drifted off from its ivory tower, many Smalltalkers were using and talking about MVC, although any kind of consensus on its meaning was limited by the lack of important documentation.

Would this telephone game continue to redefine Model-View-Controller as object-oriented programming grew beyond the Smalltalk-80 community?

Part 3: Objective-MVC

Objective-C is now best known as the programming language Apple promotes for developing iOS and Mac applications. It was first available on the Mac during the 1980s pre-Cambrian explosion of OOP languages: on the Mac alone you could send messages using Smalltalk-80, Object Pascal, Objective-C, ExperCommon Lisp, Allegro Common Lisp, Object Assembler, Object Logo, and there were probably more. Most of the list here was derived from Object-Oriented Programming for the Macintosh, written by Kurt J. Schmucker then of Productivity Products International.

Which brings us back to Objective-C, which is probably the best known of the products produced by Productivity Products. Objective-C did not let programmers use a spatial programming interface, it made them use linear text files.

Objective-C also did not follow the Model-View-Controller paradigm of Smalltalk-80. As described by Brad Cox in this figure adapted from Object-Oriented Programming: an Evolutionary Approach, the PPI programmers were thinking about Models and Views, and then about reusing Views in different UIs.

Objective-C Layer Architecture

So, what happened to the Controllers? Here’s Cox:

This architecture is very similar to the one used in Smalltalk-80, with one exception. […] The outgoing leg of Smalltalk’s user interface is handled by a hierarchy of views much like the ones discussed here. But the incoming leg is implemented by a separate hierarchy of classes, Controllers, that provide the control for the application. […] The need for the separate controller hierarchy is unclear and is the topic of spirited debate even within the Smalltalk-80 community.

Unfortunately the citation for “spirited debate” is personal communication with various Smalltalkers, so we may never know the content.

This gives us three Objective-C modifications to the original Smalltalk-80 concept that persist to this day. One is the move from a user interface paradigm concerning the interactions of individual objects to a layered architecture. The Cox book shows the display screen as a projection of the view layer onto glass, and the models all in their own two-dimensional layer suspended from the views, hanging:

suspended from the presentation level by pointers in much the way that circuit boards are connected to test equipment with a bed-of-nails testing jig.

That still persists in Cocoa MVC, though with a somewhat weak assertion:

The collection of objects of a certain MVC type in an application is sometimes referred to as a layer—for example, model layer.

The second thing is the abstraction of the Presentation layer away from the display primitives.

The other thing that we still don’t have in ObjC is the Controller. Wait, what? Surely Objective-C applications have Controllers. Apple and NeXT both talked about it, and they have objects with the name “Controller” in them. Surely that’s MVC.

For whatever reason, NeXT kept the ObjC-style Views with their handling of both input and output, but also had to reintroduce the idea of a Controller. So they took the same approach followed by others, notably including Ivar Jacobson a few years later, of defining the Controller layer to contains whatever’s left once you’ve worked out what goes into the Model and View layers.

Now there’s only the question of placement. The Controller can’t go where Smalltalk’s Controllers went, because then it would get in the way of the input events which now need to get to the View. It could go between the two:

A controller object acts as an intermediary between one or more of an application’s view objects and one or more of its model objects. Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also perform setup and coordinating tasks for an application and manage the life cycles of other objects.

Here’s a reproduction of the diagram from that document:

Cocoa MVC

Notice that for the Controllers to act as a mediator between Models and Views, the Views actually have to forward action messages on to the Controllers (via delegation, target-action or the responder chain). Had the Controller been left where it was it would already be receiving those events.

Compare that with the diagram derived from Smalltalk MVC:

Smalltalk MVC

It’s clear that these are different concepts that unfortunately share a name.

The Objective-C protocol naming trifecta

Objective-C protocol names throughout history seem to fall into three distinct conventions:

  • some are named after what a conforming object provides. Thus we have DBProperties, DBEntities, DBTypes and the like in Database Kit.
  • others are named after what the object is doing. Thus we have NSCoding, NSLocking, IXCursorPositioning etc.
  • still others are named after what the conforming object is. NSTableViewDataSource, NSDraggingInfo etc.

I think I prefer the second one. It emphasises the dynamic message-sending nature of the language: “because you’re sending messages from this protocol, I’ll act like this”.

ClassBrowser’s public face

I made a couple of things:

I should’ve done both of these things at the beginning of the project. I believe that the fact I opened the source really early, when it barely did one thing and then only on my machine™, was a good thing. It let people find out about the project, have a look, and even send changes. But not giving anywhere to discuss ClassBrowser was a mistake. It meant I answered questions in private messages that would’ve been better archived, and it probably turned some people away who couldn’t immediately see what the point was.

Hopefully it’s not too late to fix that.

Laggards don’t buy apps: devil’s advocate edition

Silky-voiced star of podcasts and all-round nice developer person Brent Simmons just published a pair of articles on dropping support for older OS releases. His argument is reasonable, and is based on a number of axioms including this one:

  • People who don’t upgrade their OS are also the kind of people who don’t buy apps.

Sounds sensible. But here’s another take that also sounds sensible, in my opinion.

  • People who don’t upgrade their OS are also the kind of people who don’t like having to computer instead of getting their stuff done.

Let’s explore a world in which that axiom is true. I’m not saying it is true, nor that Brent’s is false: nor am I saying that his is true and that mine is false. I’m saying that there’s an open question, and we can investigate multiple options (or maybe even try to find some data).

Developers are at the extreme end of a range of behaviours, which can be measured in a single dimension that’s glibly called “extent to which individual is willing to mess about with a computer and consider the time spent valuable”. The “only upgraders buy apps” axiom can be seen as an extension of the idea that all changes to a computer fit onto the high end of that dimension: if you’re willing to buy an app, then you’re willing to computer. If you’re willing to computer, then you’re willing to upgrade. Therefore anyone who wants to sell an app is by definition selling to upgraders, so you can reduce costs by targeting the latest upgrade.

Before exploring the other option, allow me to wander off into an anecdote. For a few years between about 2004 and 2011 I was active in my (then) local Mac User Group, which included chairing it for a year. There were plenty of people there who were nearer the middle of the “willingness to mess with a computer” spectrum, who considered messing with upgrades and configuration a waste of time and often a way to introduce unwanted risk of data loss, but nonetheless were keen to learn about new ways to use their computers more efficiently. To stop computering, and start working.

Many of these people were, it is true, on older computers. The most extreme example was a member who to this day uses a Powerbook G3 Pismo and a Newton MessagePad 2100. He could do everything he needed with those two computers. But that didn’t stop him from wanting to do it with less computer, from wanting to optimise his workflow, to find the latest tips and tricks available and decide whether they got him where he was going more efficiently.

As I said, that example was extreme. There were plenty of other people who only bought new computers every five years or more, but were still on the latest versions of apps like Photoshop, Quark Xpress, or iWork where they could be, and whenever new ones got released the meeting topic would be to dig into the new version (some brave soul would have it on day one) to see whether they could do things better, or with less effort.

These people were paying big money for big software. Not because it was the newest, or because they had to be on “latest and [as we like to claim] greatest”, but because it was better suited to their needs. It gave them a better experience. So, bearing in mind that this is a straw-man for exploration purposes, let me introduce the hypothesis that defends the straw-man axiom presented above:

  • A delightful user experience means not making people mess about with computer stuff just to use their computers.
  • There are plenty of people out there who would rather get something that lets them work more effectively than waste time on upgrades.
  • To those people, spending money on software that gets them where they are going is a better investment than any amount of time and anxiety spent on messing with settings including operating system upgrades.
  • These people represent the middle of the spectrum: not the extreme low end where you never change anything once you’ve bought the computer; nor the extreme high end where fiddling with settings and applying upgrades is considered entertainment.
  • Therefore, the low price of “latest and greatest” software reflects at least in part the externalisation of the (time-based) costs and risks associated with upgrading to mid-range tinkerers.
  • Because of this, while the incremental number of users associated with supporting earlier OS versions may not be great, the incremental value per user may be much higher than gaining users with low-price apps on the current operating systems.

As I say, interesting food for thought, but not necessarily any more (or less) true than the view presented in Brent’s posts. Please have your pinch of salt ready, and don’t bet your business on the thoughts of this idle blogger.

Missing Vital Content

After reading Moderately Valuable Cliché, reader Nicholas Levin got in touch to recommend that I look at the back of my Smalltalk-80 books. Here’s the blue one.

Books in the Smalltalk-80 series

The first book mentioned in “Other books in the … Series” is the red book, “Smalltalk-80: The Interactive Programming Environment”. The third is the green book, “Smalltalk-80: Bits of History, Words of Advice”. But the middle one? “Smalltalk-80: Creating a User Interface and Graphical Applications”? No-one ever assigned that one a colour. It was never published.

Discussions of the book in comp.lang.smalltalk in 1986 indicate that it was a manifesto for Model-View-Controller, promoting and describing the pattern for building Smalltalk applications. The thread instead recommends looking at Chapter 9 of a book that has been mentioned on this blog before: Object-Oriented Programming: an evolutionary approach by Brad Cox. More on that later.

So the idea behind MVC was well-known in the Smalltalk user community, but the principle was not documented by the Smalltalk team themselves (as far as I know: it’s possible there are documents I haven’t found) until Adele Goldberg left and founded ParcPlace with others at the end of the 1980s.

Levin also pointed me at a couple of other resources. In this interview for the Computer History Museum, Adele Goldberg confirms that the missing book was “to be an applications level book which was basically the model-view-controller metaphor”.

In an interview for the IEEE Global History Network, Goldberg explains how the whole concept of the Dynabook was to allow people to model real-world problems on their portable computers:

That’s what we thought it was, a PDP-10, which is lightweight compared to what we have now. It was going to be there, like a notepad, but it was going to be a computational-based device that allowed you to build models of the world and test your understanding of the world. What students who succeed really do is, they interact with teachers and parents and other people—and it could be other students—who challenge the models they build of their world; and this is true whether it’s science, math, or social studies: that you’re constantly constructing and deconstructing. And when someone really pushes you to think about your models, make the models explicit, talk about those models, and be able to build those models and then challenge those models—I mean, every well educated person I know remembers in their childhood that that was what was going on all the time.

In other words, Smalltalk is the programming equivalent of “[taking] apart engines and [putting] them back together again, to understand how things work”.

The long time over which the books were written and the fact that the system was being designed in reaction to problems found in documenting it (“In order to get the language book done we kind of organized ourselves so that Dan Ingalls and I, we’d have an aspect of the system we’d need to agree on like, what would be the collection classes? How would you provide collections?”) explains why the blue book’s FinancialHistory example can have no MVC, the red book briefly mentions MVC, and the authors of the ParcPlace paper, looking back, can remember it as a key part of the sample. Perhaps that example was eventually fleshed out for the unprinted book, or was developed further for another reason beyond the publication of the blue book.

We also have a possible reason for the subsequent diversity of interpretations of MVC among applications developers. With no primary reference for the original intention behind MVC, as the Addison-Wesley book was unwritten, people guessed at what Model-View-Controller meant from the bits and pieces that were published or discussed in the community.

Moderately Valuable Cliché

In part 1 of the MVC story, I examined “Thing-Model-View-Editor”, a pattern[*] extracted by Trygve Reenskaug’s work in Smalltalk-76. By the time Smalltalk-80’s hot air balloon set sail from the ivory tower, there was already a structure called Model-View-Controller.

Part Two: MVC and Smalltalk

[*] Bear in mind that I’m retroactively applying the word “pattern” here. Design Patterns as a thing, modelled on the book modelled on the other book, do not belong in this story for another 15 years or so.

This story will be told through the lens of a single overview article: A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System by Krasner and Pope is the first. The authors give their affiliation as “ParcPlace Systems, Inc.”, a company that built tools on top of Smalltalk. It was founded by ACM president Adele Goldberg, who originally developed Smalltalk along with Alan Kay and others.


Krasner and pope say that MVC is an application of a particular three-way factoring of a software problem into objects:

separating (1) the parts that represent the model of the underlying application domain from (2) the way the model is presented to the user and from (3) the way the user interacts with it.

They go on to say that it was observed that most Smalltalk-76 applications offer the same interaction—images, buttons, text and menus—and that the goal of the MVC factoring in Smalltalk-80 is to handle those interactions in a common way across all applications.

Smalltalk MVC, adapted from Krasner and Pope 1988

The model and the view hold the same positions that they did in TVME: the models represent the thing in a computerey way, and the views represent the model on the bitmap display. “Controllers are used to send messages to the model, and provide the interface between the model with its associated views and the interactive user interface devices (e.g., keyboard, mouse). Each view may be thought of as being closely associated with a controller, each having exactly one model, but a model may have many view/controller pairs.” The controller is to MVC as the editor was to TVME.

So, the controller is the thing that senses and responds to UI events. Because you probably only intend for one thing to happen when you press a key or click a mouse button, only one controller is active at a time. That controller can interpret your command as a requirement to edit or query the model, or to display or change a particular view.

The views can also edit or query the model. So, there’s a need for the model to let the controller know when it was changed by a view, and the views should know when the model was changed by the controller. Enter dependents!

Dependents represent a realisation of what would later be known as the Observer pattern. The model can keep track of a collection of the objects that care about its changes. When it changes, it sends a changed or changed: message to its dependents.

Smalltalk-80 supplies bundled abstract classes for each of Model, View and Controller. The article goes into each of these classes and some of the subclasses that have already been created, showing how inspectors, editors and debuggers in Smalltalk-80 are all built from this factored collection of objects. It also details complete applications, including the FinancialHistory tutorial from “Smalltalk-80: the Language and its Implementation” by Goldberg and Robson.

Looking in the blue book, as it’s known, none of the terms MVC, model, view, nor controller appear in its index. The classes Model, View and Controller are not in the example class index, and the dependents, changed and changed: methods are not in its implementation index. The FinancialHistory object is described throughout the book, but is a subclass of Object and does not participate in any factoring that’s similar to MVC.

It’s probable that this reference is a mistake, and that Krasner and Pope intended to refer to the red book “Smalltalk-80: the Interactive Programming Environment” by Goldberg. This does indeed describe MVC, but only in relationship to the “MVC Inspector”. However, the description of the inspector shows that the pattern was common enough to motivate the construction of bespoke UI:

Many objects in the Smalltalk-80 system are closely related to one another. In particular, the user interface of the system is implemented using subclasses of two classes, class View and class Controller. A View represents ways of presenting information on the screen; a Controller represents ways in which the user interacts with a screen view. Any View is related to a Controller and to another object, the object whose information is accessed in the View. This other object is referred to as a “model.” Whenever you inspect a View, you typically want to inspect its related model or Controller. There is a special inspector in the system for inspecting the two main objects related to a View, as well as the View, whenever a View is sent the message inspect.

Having mentioned the red and blue books, it seems appropriate to introduce the green book, “Smalltalk-80: Bits of History, Words of Advice” edited by Glenn Krasner (the first author of the paper we started at). There is no MVC in the green book, but the three books[*] together are a fascinating snapshot of this time in our industry.

[*] There is a purple book too, but it’s just half of the blue book repackaged.

So Smalltalk-80 MVC is a formalisation of the abstract collaboration between objects documented as Thing-Model-View-Editor. It is an idiom named after the developer tool that was designed to take advantage of the common relationships between these objects. At some point after its initial documentation, authors (Krasner and Pope along with others) decided that this was not merely a factoring, but a “User Interface Paradigm”.