Retracing Original Object-Oriented Programming
In the beginning of Mythryl Programming Language tutorial, the author tells a story about his physics professor:
On the first day of my first undergrad physics class, the prof told us, “Everything we teach you in first year physics is a lie. But sometimes one has to lie to get at the truth; until you understand these lies, you cannot understand the deeper truths behind them.”
It’s basically saying that the first chapters of the tutorial is a collection of deliberate lies. But it needs to be done to help the readers.
The preface continues:
This section is a lot like that.
Most of what we cover will appear to be familiar things done in familiar ways.
Almost none of it is.
But it will simplify things to pretend otherwise long enough to cover the material once; afterward we will go back and look more deeply at what is really going on.
In the same spirit, I expect that you, dear reader, to be familiar with the mainstream Object-Oriented Programming (OOP) concepts (encapsulation, inheritance, and polymorphism). And with that in mind, I’d like to take you to journey to retrace the original OOP.
Why OOP was born
Please allow me start by quoting Mark Twain:
There is no such thing as a new idea. It is impossible. We simply take a lot of old ideas and put them into a sort of mental kaleidoscope. We give them a turn and they make new and curious combinations.
When it was invented, OOP was not a new idea. You can say that it’s combination of old ideas. The OOP inventor himself, Alan Kay, stated that there many “ancestor” ideas that led to the birth of OOP.
So, in order to understand the formulation behind OOP, I have no choice but to you bring you to journey going back 50 years ago, in the 1960s.
Alan Kay claimed that OOP has many “ancestors”, but since I don’t want to make this history longer than needed, I’m going to cherry-pick 2 of those ideas: Sketchpad and GRAIL.
Sketchpad (1962)
Sketchpad can be considered as the first Graphical User Interface (GUI) application and the ancestor of Computer-Aided Design (CAD). It was truly revolutionary during in its time, and — dare I say — it still has plenty of things we can be inspired of.
Here’s a short 3 minutes Sketchpad demo which Alan Kay played during his presentation in 1986:
(Side note: It’s an interesting fact that on that video (around 2:08 mark), Alan Kay said that:
Sketchpad is also the first true Object-Oriented Programming System..
.. while the Object-Oriented term itself is formed 4 years later (in 1966). My guess is that Alan Kay is looking back at those days and he made Sketchpad as aspiration of what will become of OOP)
GRAIL (1968)
GRAIL stands for Graphical Input Language. Although the hardware was limited, I find the idea and implementation of this system truly remarkable, even by today’s standard.
Here’s a short 2-minutes video of Alan Kay playing the demo of GRAIL. Notice how fluid the user interaction is.
One thing that sets GRAIL apart is that it was modeless. As a comparison, today’s programming requires 2/3 modes: edit/[compile]/debug cycle, while GRAIL doesn’t have any.
(Side note: From the video above, it can be seen that GRAIL had following property: The end-user mental model was being displayed and manipulated using a view that acts as the extension of end-user’s brain, and a certain controller is responsible to dispatch the user’s input (via stylus) into the system.
See what I did there? GRAIL had much closer Model-View-Controller (MVC) implementation than today’s MVC, where it means database schema (model), HTML page (view), and glue layer (controller).
Like OOP, the term MVC had also been hijacked (for better or for worse), but that’s story for another time).
The “Personal Computer”
Not just Sketchpad and GRAIL, there are many more interesting systems being developed in the 1960s and 1970s. One of them is personal computer envisioned by — not coincidentally — Alan Kay.
His exact vision was to make computer a learning and thinking amplifier.
Now, it’s really hard to describe what does that vision really mean, let alone describe it in few sentences. But I’ll try by quoting Alan Kay himself:
There has always been confusion between carriers and contents. Pianists know that music is not in the piano. It begins inside human beings as special urges to communicate feelings. But many children are forced to “take piano” before their musical impulses develop; then they turn away from music for life. The piano at its best can only be an amplifier of existing feelings, bringing forth multiple notes in harmony and polyphony that the unaided voice cannot produce.
The computer is the greatest “piano” ever invented, for it is the master carrier of representations of every kind.
I should note Alan Kay’s vision is greatly influenced by children education thinkers, such as Maria Montessori, Jerome Bruner, Seymour Papert, etc. So it’s not surprising that to materialize his vision, he wants the final product to be children-friendly. It was called Dynabook.
Let’s take a look at short 1-minute video of Alan Kay presenting Dynabook:
Of course, to make a Dynabook a complete computing system, it needs software component. That’s where Smalltalk — the first programming language that was built to support OOP paradigm — came in.
Although Smalltalk was developed originally as programming language, it soon grew into a set of software (Think of OS, IDE, and application container rolled into one). Smalltalk objective was to provide answer to “How to make the best possible environment for the children to learning and exploring?”. Now, because at this point Smalltalk is OOP and OOP is Smalltalk, the materialization of OOP idea goes hand-in-hand with Smalltalk.
So, that’s the reason OOP was born. OOP intention was actually a lot closer to help children learn and explore rather than to help programmer creates reusable and easily maintainable code (though, of course, it would be nice if that can accomplished, too).
OOP Key Idea(s)
Most newcomer to OOP will be told that the main principles in OOP are encapsulation, inheritance, and polymorphism. However, these never been the intention of OOP, at least according to its inventor. Alan Kay said (emphasis mine):
The big idea is “messaging” [..]. The Japanese have a small word — ma — for “that which is in between” — perhaps the nearest English equivalent is “interstitial”. The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be.
In computing, “messaging” is a very crowded term and — without context — it’s really hard to understand what does he meant by messaging. Fortunately, he provides context: messaging in “ma”. Unfortunately, I have zero knowledge about Japanese, so that limits me to have proper understanding of “ma”.
So, in order to continue this journey, I have to insist to take a little detour. We’re going into biology.
An Organism Structure
The way a biological organism is structured is almost sounded recursive.
A human is an organism.
This organism consisted of collection of organ systems grouped together.
Each organ system consisted of multiple organs grouped together.
Each organ consisted of multiple tissues grouped together.
Each tissue consisted of multiple cells grouped together.
Each cell consisted of multiple organels.
One wonderful thing about the “design” of organism is its scalability. The simplest unit that can support itself, is a cell. However, the cell itself is not “smart” at all. (Think of POJO).
How, then, does a huge number of them can mimics smartness? Because they communicate (by messaging) with each other.
So, this is the kind of “messaging” Alan Kay is talking about. The smartness of the system comes not from inside of the object, but from how those objects work together. (Note that those cells don’t actually know they’re “working” together. They’re not smart, remember?)
How does this translate to the software world?
Getting More Concrete
Messaging is the big idea. But big idea needs implementation.
In different interview, Alan would specify about this:
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them.
So, there you go, the key ideas of OOP are:
- Messaging
- Local retention, protection, and hiding of state-process
- Extreme late-binding of all things
Let’s examine those idea one-by-one.
Messaging
Now that we know the idea behind messaging, let’s get down to a more detailed level. In order to convey the idea, I’m going to compare it with how we usually design a class.
Suppose that we have two classes: A and B. The mainstream notion is that we should put focus how to design their in-ternal properties and behaviors.
Now, focusing in-side of the classes works well if the system is small. But if we need to built a non-trivial system, focusing on the in-side can’t help us building “great and growable system”. Instead, as Alan Kay argues, we should be focusing out-side.
(Side note: Note that on the picture above, I drew a line to separate compile-time and run-time. But the original OOP idea concerns about the run-time only. More on that on the next section.)
It may look like that the difference between “focusing on the internal” and “focusing on the space between objects” is miniscule. I originally thought the same thing. I couldn’t have been more wrong.
The difference matters so much, but it took me long time to see it because it requires different mindset.
Local retention, protection, and hiding of state-process
This idea can be thought of the higher kind of encapsulation. I personally think that this one idea that most of us can easily grasp. But one should be careful not to equate this with encapsulation in mainstream OOP. To quote Alan Kay (emphasis mine):
However, doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming.
Getter and setter certainly don’t conform with this idea.
Extreme late-binding of all things
Extreme late-binding is needed if we want to have an environment where experimentation (as needed by “thinking and learning”) is a first-class concept.
Basically, this idea can be thought of as late-binding as we found in dynamic programming language, but taken to the extreme. Just as “messaging” idea above, it’s really hard to describe this concept. So I’ll just show a short 2-minutes demo video about Light Table, which implementation close enough for this “extreme late-binding”
However, I recommend you to check out other sources to know more about this intriguing idea:
- Martin Fowler, which calls this Internal Reprogrammability.
- A 20-minutes TED Talk by Alan Kay, in which he talks about One Laptop Per Child (OLPC). Notice that the presentation software he uses can embed all the programs he needed without switching out to another software.
“OO” System: The Internet
My friend once asked me which application/library that has the best abstraction. It’s rather hard for me to answer, because there are many great application/library out there.
But if he’d asked what computing system has the best abstraction, I’d easily answer it. For me, one system stood out and eclipses the rest: The Internet.
Internet is often mentioned by Alan Kay as the only working Object-Oriented system out there. It embodies the 3 keys ideas above really well. Further, he says:
The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs.
I think the comment is rather harsh. But unfortunately, he’s right.
The Internet, as a system, was turned on on January 1st, 1983. Since then, it had 100% uptime. Sure, some of its subnetworks were experiencing downtime here and there. But The Internet, as a system, have had 0% downtime.
Not only that, The Internet is always “interactive” and always at “runtime”. If you made changes on the Internet, you don’t need to restart it. It just works. It’s “extreme late-binding” at its best.
Moreover, The Internet is a really good metasystem — a system where another system is built on top of it. To built a good metasystem, its designer can’t assume what its users will built on top of it. I highly doubt Vint Cerf and Bob Kahn — the main designers of TCP/IP — would predict that The Internet will become the backbone of modern currency.
The Internet is truly an engineering masterpiece. The web, which built on top of The Internet, is nowhere close to that.
Honorable Mention for “OOP” Languages
In today’s mainstream OOP languages, do we really focus on the object? I doubt that we do. If your programming language doesn’t let you write or edit object, then maybe it’s not oriented toward objects. Ironically, programming language that often being heralded as the OOP language, Java, doesn’t have this ability. In Java, object only lives in runtime. What we write or edit in Java is class. Jim Coplien prefers to call this paradigm as Class Oriented Programming. I certainly don’t think that Class Oriented Programming is bad, but Object Oriented Programming requires different mindset.
Of course, this didn’t happen only with Java. As a rule of thumb when you wonder whether a programming language supports OOP or not, ask yourself “Does this language lets me write or edit object”?
So, what’s mainstream programming language that’s closer to OOP? As it turns out: Javascript. Brendan Eich, the Javascript designer, states that Javascript takes inspiration from Scheme and Self. Scheme is a LISP, and Self aims to be more OOP than Smalltalk. LISP and Smalltalk, if you recall, are the languages that can do OOP according to Alan Kay. (And yes, you can write or edit object in Javascript).
(Un)fortunately, the marketing team at Netscape, where Brendan Eich worked, wants Javascript to be more like Java to ease market adoption. Then Javascript becomes the most misunderstood programming language. The rest is history.
Another language worth mentioning (although much less mainstream) is Erlang. Erlang’s design coincidentally conforms with Actor Model. Actor Model itself has interesting relationship with OOP. If Javascript is interesting because it gets object idea better than the others, Erlang is interesting because it gets the messaging idea better than the others.
I should note that I’m not advocating for Javascript and Erlang. But if you understood one of them (or better: all of them), chances are it’s easier for you to get the ideas of original OOP.
(Side note: In order to solve the multiple hard problems that we face in software construction, I get the impression from Alan Kay that he doesn’t think OOP implementation (a la Smalltak) won’t get us there, though the OOP ideas might. Smalltalk might be the best solution for problems in the past, but not for what we have right now, and especially not for what he have in future.
To put in another word using our biology example: Our current abstraction can deal until “organ” scale. But in order to scale up to “organism”, we will need totally different abstraction. You contains 37 billions cell, all is working without your mind thinking about about it. Not only that, you have 100% uptime.
Software abstraction is just not there yet. Even recreating Sketchpad and GRAIL will be hard using today’s programming languages. But this should be story for another time.)
Closing Thoughts
This where I drop you, dear reader, off the journey. I hope by now you get the understanding that original OOP is not about inheritance, encapsulation, and polymorphism. The idea is much bigger than that.
As we’ve seen, things that we take for granted everyday, such as The Internet, contains many great properties that we want from a software (highly concurrent, fault-tolerant, 100% uptime, etc). I don’t even need to mention the system design that makes you you is in totally different league.
That’s why I wonder why we — as software community — doesn’t seem to learn more from them?
