A Love Letter to Object Orientation
Sign in<br>Subscribe
Origins of Object-Oriented Programming<br>I am having a hard time explaining to people what my Abject project is about. I've been taking people's feedback and updating the website to make it clearer. One idea people are having a hard time with is when I say, "The internet is an object-oriented system." Those trained in computer programming often have a hard time grasping this because we have been trained that object-oriented means classes and class hierarchies. Through that lens, it doesn't make sense.<br>The person who coined the term "object-oriented programming" was Alan Kay, when he was in graduate school before he developed Smalltalk. He was influenced by Ivan Sutherland's Sketchpad, one of the earliest systems to contain object-oriented ideas. Sketchpad had no textual programming language in the modern sense; it was visual, and problems were solved through constraints and solvers. Kay was also influenced by his background in biology.<br>The big idea Alan Kay had was messaging. When he developed Smalltalk, the kernel was about sending messages between objects with a good metasystem to do late binding. By late binding I mean deciding what a message means at the moment it is received, not freezing that decision into a class hierarchy ahead of time. By metasystem I mean the layer that lets the system reason about and extend those rules safely. This is why Kay's definition of objects connects so directly to the internet: the internet is not one giant class hierarchy; it is independent systems sending messages across agreed boundaries. Kay made this connection in his message in the Squeak development mailing list in 1998. I'm going to reproduce it here because it's so important.<br>Alan Kay alank at wdi.disney.com<br>Sat Oct 10 04:40:35 UTC 1998
Folks --
Just a gentle reminder that I took some pains at the last OOPSLA to try to<br>remind everyone that Smalltalk is not only NOT its syntax or the class<br>library, it is not even about classes. I'm sorry that I long ago coined the<br>term "objects" for this topic because it gets many people to focus on the<br>lesser idea.
The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak<br>is all about (and it's something that was never quite completed in our<br>Xerox PARC phase). The Japanese have a small word -- ma -- for "that which<br>is in between" -- perhaps the nearest English equivalent is "interstitial".<br>The key in making great and growable systems is much more to design how its<br>modules communicate rather than what their internal properties and<br>behaviors should be. Think of the internet -- to live, it (a) has to allow<br>many different kinds of ideas and realizations that are beyond any single<br>standard and (b) to allow varying degrees of safe interoperability between<br>these ideas.
If you focus on just messaging -- and realize that a good metasystem can<br>late bind the various 2nd level architectures used in objects -- then much<br>of the language-, UI-, and OS based discussions on this thread are really<br>quite moot. This was why I complained at the last OOPSLA that -- whereas at<br>PARC we changed Smalltalk constantly, treating it always as a work in<br>progress -- when ST hit the larger world, it was pretty much taken as<br>"something just to be learned", as though it were Pascal or Algol.<br>Smalltalk-80 never really was mutated into the next better versions of OOP.<br>Given the current low state of programming in general, I think this is a<br>real mistake.
I think I recall also pointing out that it is vitally important not just to<br>have a complete metasystem, but to have fences that help guard the crossing<br>of metaboundaries. One of the simplest of these was one of the motivations<br>for my original excursions in the late sixties: the realization that<br>assignments are a metalevel change from functions, and therefore should not<br>be dealt with at the same level -- this was one of the motivations to<br>encapsulate these kinds of state changes, and not let them be done willy<br>nilly. I would say that a system that allowed other metathings to be done<br>in the ordinary course of programming (like changing what inheritance<br>means, or what is an instance) is a bad design. (I believe that systems<br>should allow these things, but the design should be such that there are<br>clear fences that have to be crossed when serious extensions are made.)
I would suggest that more progress could be made if the smart and talented<br>Squeak list would think more about what the next step in metaprogramming<br>should be – how can we get great power, parsimony, AND security of meaning?
Cheers to all,
Alan<br>Abject-Oriented Programming<br>I call the Abject project an Abject-Oriented system, playing off the phrase Object-Oriented. When I talk about objects, I am talking about them in the sense that Alan Kay had: it is really about messaging, and about having a metasystem to do late binding.<br>The Ask Protocol<br>The key message in the Abject system is the "ask" message, and it is really the heart of...