As computing projects go, particularly foundational computing projects, the history of Smalltalk is well-documented, so a potted version will suffice here. Xerox hired someone in Palo Alto to hire a lot of other people, and invent things that would lead to interesting new lines of business for the company. Along the way, this group invented personal computing, the mouse, the graphical user interface, Ethernet networking, the laser printer, object-oriented programming, video conferencing, and provided the creativeness behind trillions of dollars of new products and markets. What Xerox forgot to do was to employ anyone with the responsibility to capture those interesting lines of business for the company, and keep for themselves any of those trillions of dollars. So they carried on marketing their photocopiers, while giving the PARC inventions to others (for example, a local startup they had an investment in, called Apple Computer) or letting their people leave to have a better chance of selling the products on the outside.
Some of the people left to form ParcPlace Systems, marketing the Smalltalk-80 product. This later trajectory is well-documented too. The people at PARC wanted to see whether custom hardware architecture like their Alto or Dorado workstations were necessary for Smalltalk-80 to perform well, or whether it would work on commodity computers. They published information about how Smalltalk-80 worked, and partnered with people in other companies and institutions to bring up Smalltalks on commercially-available computers. Among those who left to start ParcPlace was Adele Goldberg, who used her influence in the Association of Computing Machinery (she was president around this time) to create the OOPSLA conference series, bringing Object-Oriented Programming and Smalltalk to the public sphere.
It was at the 1997 OOPSLA that Alan Kay delivered his keynote address, complaining that the computer revolution had not happened yet. The talk is famous for the shade he threw at other systems and their inventors, indeed at their users too. He “invented the term” OOP, and he wants you to know that he “did not have C++ in mind”. Edsger Dijkstra may think that the European method of teaching computer programming is more precise and avoids more errors, but “arrogance in computer science is measured in nano-Dijkstras” and “most of the software in the world is written on one side of the Atlantic”.
A subtle—mostly, but often less so—tinge of bitterness runs through this talk, and through other talks subsequently delivered by Kay. He alternates between implying that Smalltalk-80 did not live up to the goals of the Smalltalk project and of OOP, and that programmers did not live up to the intellectual standards necessary to get Smalltalk and OOP, and understand how they were superior. So we can understand a lot about what Smalltalk was by asking the opposite question: what was not it?
Kay often presents the idea of two orthogonal places of technological development. The blue plane is where current paradigms and ways of working exist. Incremental innovation moves a field along the blue plane: making it more efficient, easier, or cheaper to do things the way we were doing them anyway. A bread machine is a blue-plane invention in the field of home baking: you still put all the same ingredients in a bowl, and you still get a loaf of bread three hours later, but you no longer do so much work in the middle.
Meanwhile, the pink plane represents a move out of the blue plane, an innovation that opens up whole new ways of thinking about the problem being addressed, or replacing that problem entirely with a whole different (and hopefully easier) problem. A sewing machine is a pink-plane invention in the field of sewing: it reduces the costs of creating garments so much as to enable off-the-peg as a whole new business model. Sewing machines make it easier and cheaper for someone to buy pre-made clothes off a rack in a store than to make their own clothes.
Presumably object-oriented programming with Smalltalk is a pink-plane idea that makes programming unrecognisably different from its procedural beginnings, and we are all to dense to notice that. Well, maybe. The Smalltalk-80 creators noted in their special issue of Byte that OOP requires a new way of thinking about designing computer programs, and that it was easier to teach to children than to existing programmers. This seems like the hallmark of a pink-plane idea: it is so alien to the current way of thinking that current thinkers do not recognise it at all.
But programming is only incidentally about designing computer programs, and is really mostly about designing programs. And program is synonymous with words like agenda, menu, routine…ideas of procedure. If the software you are working on is going to automate some business process, you had better have a good idea of what that process is. And because you are automating a process, you will be thinking about a procedure. We have got millennia of experience, across multiple civilisations, of describing activities procedurally and repeatably performing those procedures. Recipes (“first take half a pint of warm water, then add a pound of strong flour…”), religious rituals (“then he broke the bread, saying: Take. Eat. This is my body…”), natural phenomena (“a body at rest remains at rest until a force is exerted on it”), and so on. A better way of designing a computer program needs to either also be a better way of describing the world than a procedure, or to be so vastly more efficient at expressing the program as to compensate for its shortcomings as a modelling tool.
This is, at its root, a restatement of Fred Brooks’ argument in “No Silver Bullet: Essence and Accident in Software Engineering”. The only way to achieve a stepwise improvement of an order of magnitude in programming productivity is to remove, at a stroke, 90% of the work performed. That can be done only if this work is unrelated to the problem at hand (expressing your solution for the computer to follow, rather than solving the problem). Assuming that pre-OOP programmers were spending more than 10% of their time on solution-related activities, your silver bullet would need to fundamentally redesign not the activity of programming but the activity of understanding the problem you hired a programmer to solve. OOP does not do this.
In most contexts where we apply software, there is a single animus overseeing all of the behaviour. Yes, we say that the customer takes a cart, browses the store, selects items to put in their cart, then takes the cart to the cashier who rings up the items in the cart, takes the money, and bags the items. But they do that sequence of activities in that order (i.e. they follow that procedure) because that is what the management of the store has decreed. There is a single intelligence (which may be an early and inefficient form of artificial intelligence called a bureaucracy) masterminding the interaction, so the OOP conceit of giving distinct willpower and animation to each of the objects in the system, modelling them as entities that make their own decisions in reposes to messages received from the world, is superfluous.
People do, of course, design object-oriented programs, and they do so successfully. But they do so by mapping them onto procedures. A use case document recognisable by Ivar Jacobson lists the steps taken by the user to achieve a goal, and documents the flow of data through the system. This being too wordy and not Agile™ enough, it is replaced by the user story, but what is a story other than a sequential description of events with a beginning, a middle, and an end? We ensure that we have got our stories correct by performing acceptance tests: sequential procedures with a beginning (“Given a logged-in user”), a middle (“when the user clicks the Buy button next to the pound of cheese”), and an end (“then a pound of cheese is added to their cart”).
OOP made it easier to reuse common procedures, and adapt existing procedures, by giving program designers and software architects a mental toolkit for adopting modularity in their software design (classes, polymorphism through message-passing, and inheritance). But it did not fundamentally change the way we do business, and neither has functional programming: it is still procedures in and procedures out, with the computer taking responsibility either for executing or shepherding the procedural flow. It is therefore a blue plane improvement, and we are still working the same way we did before.
Cover photo by NeONBRAND on Unsplash
