21 Apr 2022
8 min read
This article explores the original idea of OOP, as it has been invented by Alan Kay. OOP was invented as a "systems-oriented approach" to programming, a way to build complex systems. Unfortunately, the name "object-oriented" created confusion and deemphasized this meaning. Perhaps a better name would be something like Complex Systems-Oriented Programming.
Complex systems usually expose “liveness” property, among others – they evolve continuously, without shut downs, since the first moment they emerge, or are started. Complex systems development happens while running, it is undesirable, or even not possible to built them ahead of time and start/stop at random moments in time.
Accordingly, to address these requirements a relevant way of programming is required, to help with developing and then evolving complex software systems on the fly, never fully shutting them down. Complex systems are usually large, consisting of many units and services, interconnected dynamically and embed complex feedback loops, including non-linear ones. This is different to simple systems, which are applications which can be run standalone, do not form complex feedback loops with other applications, can be developed, started, stopped, understood statically.
Complex systems can’t be fully understood or modeled statically, the only true model is the systems itself, which evaluates, simulates own behavior, interaction by interaction. Objects in OOP were meant to be universal simulators, able to simulate whole other systems, applications, computers inside.
Interestingly, the industry did arrive at similar tools. Some interesting examples are the Internet, microservices, FRP, the actor model as in Erlang. They all are addressing the tasks and problems original OOP was designed to address, though do it with different degrees of complication, efficiency, verbosity, by not making these essential requirements a first class properties, or even primitives, to build upon.
Meanwhile, the original OOP, built with objects as universal simulators, has been adopted by the mainstream industry by a way of simulating procedural programming. This is what the mainstream OOP still is today.
A slide from one of Alan's presentations.
The properties usually considered the foundation of OOP – inheritance, polymorphism, encapsulation – exactly express ways to simulate data structures and data types with objects. Inheritance is being used as a subtyping mechanism at best, spaghetti code at worst, polymorphism is an implementation of ad hoc polymorphism on data types. The current state of the art in mainstream OOP languages is support for algebraic data types, which continues the trend of simulation of computations (data types and algorithms) with objects, vs simulations of systems.
Encapsulation is the only property aligned with the original OOP idea, but even it is mostly being used for namespacing and providing static structure to the code, rather than for dynamic abstraction over entities and their internal state.
Let’s see what properties are required to build complex, evolving, live systems. These would be:
See also a list of properties as given by Alan Kay on Quora.
We can see that all these properties have abstraction property. Remember, abstraction is not a vague undefined idea, but a simplification which creates a new level of meaning, new semantic objects (see Dijkstra's definition, and also Wikipedia's one). That that all the essential properties of OOP have the abstraction property is not a coincidence. Abstraction is a way to handle entropy, and managing entropy is the way to build complex systems, both from human comprehension and structural nature of such systems points of view.
Entropy is important, because software systems can be measured with information entropy, which is defined as a logarithm of number of all possible states of all the variables in the system. By encapsulating the state, and by using all the other abstracting properties, OOP makes complex systems manageable.
Now, functional programming, starting with Lambda calculus, also has abstractions as functions, internal state as bound variables, and communication by application. But it lacks mutable internal state, and function application is rigid, static binding, which limits the abilities to evolve the systems built with it. One can only design them ahead of time and link statically, but complex evolving real-life systems are hard to impossible to design in this way.
So to build complex systems in pure FP it must first implement the essential properties needed for building complex systems as described above. This means that complex FP programs also have to rely heavily on microservices of sorts, or techniques like FRP.
The analogy would be that FP is proteins of software, molecules with statically defined properties, while OOP is living cells and up. They are built with proteins and other molecules, but implement a whole new level of interaction, development, evolution properties.“The Molecular Biology of the Cell” by Bruce Alberts, et al. is the book Alan Kay [recommends](https://www.quora.com/What-is-in-your-opinion-the-best-textbook-for-self-studying-computer-architecture-and-programming-from-the-bottom-up-where-the-bottom-is-the-logic-gates-level) for studying software.
OOP intersects with a number of concepts from mathematics and computer science, like the actor model, state machines formalisms, communication and concurrency models, temporal and linear logic etc.
In fact, OOP did influence or inspire some of them, e.g. the actor model and message-based concurrency models. The difference is that the actors model, and languages closely based on it, like Erlang, are concerned with modeling [concurrent] computations with the basic primitives, and do not address universal simulators and systems properties, which results in them being used to implement low-level data and algorithms-based software, vs whole systems.
Also worth mentioning that objects and messages are meant to implement algebras, and could even be used to simulate FP itself. Formal verification would be a nice property to have, but seems that it is only possible for simple systems. Complex systems can only follow strict laws and evolve, and would produce unpredictable results even being fully deterministic (as stated by the chaos theory). On the other hand, formal verification can mean many things, so it depends.
The larger and more complex the system is, the more and more it ends up approximating Complex Systems-Oriented Programming. Objects being universal simulators were meant to emulate whole computers, and the Internet is exactly this - a CSOP/OOP system which exhibits all the essential properties described above, and evolves without downtime since it has been launched almost half a century ago. On the other hand, OOP intends people to build complex applications in a similar way to the Internet - software as Internet principle.
AWS Lambda functions and alike are an interesting case. They do not fully implement all the essential properties of CSOP/OOP, but also seems like they are evolving towards them, with step functions, finops runtime. This also shows where devops is heading – to automation up to irrelevancy.
Another examples of OOP systems are microservices-based backends, microservices for frontend, enterprise event-driven architectures, actor systems like Erlang, Akka, SmallTalk and its derivatives, and so on (though, as mentioned earlier, Erlang and actor libraries in other languages are generally focused on modeling concurrent data access and algorithms on low level, do not address the systems simulation requirement).
Systems built with understanding of the essential properties of OOP and by explicitly implementing them do actually provide the proverbial 10x technological and business advantages.
I can confirm this conclusion from my own experience, from high-load backend systems to complex scalable frontends to building whole complex production-proven applications in single-digit days, vs months it would take with the industry approach.
The future of software development is probably in more [energy efficient](https://traversable.space# essays/guts-d) for humans technologies, but the underlying machinery will have to do the systems and evolution stuff similarly to what is described above.
See other articles by Eugene
Ground Floor, Verse Building, 18 Brunswick Place, London, N1 6DZ
108 E 16th Street, New York, NY 10003
Join over 111,000 others and get access to exclusive content, job opportunities and more!