
Alan Kay on the misunderstanding of OOP (1998) - mmphosis
http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html
======
hackits
I find it interesting that everyone gets so up-beat about the ideology or
philosophical debate about objects sending each object messages, hell even not
relying to a message one object send you until a later date. Without even
thinking about concurrency, state, and hell even the basics such as cyclic
loops within a event based system!

Though I keep hearing from Alan and other prominent language designers that we
still are holding onto this old 1960 mental model of command and control, or
structured design concepts. Even some well spoken people suggest that the
whole notion of object's are worthless to programmers because it takes place
within the notion of classes and constraints of the machine.

This whole philosophical debate about understanding/miss-understanding/correct
usage of OOP is just a complete waste of time.

For what its worth I consider object's simply as a basic level category of
procedures and data tied to a namespace. If the category requires state then
consider it as a object otherwise its considered a module.

I've seen too many project's that have drunken the cool aid and has resulted
in 5-10 level deep inheritance tree's with their own branching logic trying to
fit behavior to a specific taxonomy.

~~~
optforfon
"For what its worth I consider object's simply as a basic level category of
procedures and data tied to a namespace.“

I mean you're just using different words to talk about the same thing. In your
terminology inheritance is just extending a namespace and overloading names.

How does that discredit or put into question the "mental model of command and
control, or structured design concepts"

If anything I feel the failure of OO languages is that they have been afraid
of baking in proven design patterns/principles that reoccur over and over (ie.
Gang of Four and a few more since then). Yesterday i was staring at some
undocumented OpenCV code trying to figure out why there was some pointer that
kept showing up in random places. After a very confusing 30 minutes i figured
out it was actually the pImpl idiom. Now why do we have to have to reimplement
the pImpl idiom each time? why can't this be a keyword?. The amount of code
bloat and confusion that a visitor introduces is the prime reason I never use
them. (There was an interesting proposal at CppCon 2 years ago that addressed
this, but as far as I know it's not gone anywhere)

The problem is that the most OO language trace back to C which IS a half-assed
language from the perspective of "concurrency, state, and hell even the basics
such as cyclic loops within a event based system" and most languages that do
OO have been half baked on top of that foundation.

~~~
kmiroslav
> If anything I feel the failure of OO languages

What failure exactly?

OOP has flaws but it has certainly proven to be extremely versatile and
adaptable over these past decades since even today, it's still the dominant
paradigm to solve modern problems in computing.

~~~
infinite8s
Seriously? Have you watched any of the demos Alan references? They were doing
things with computers in the 1960s/70s that still haven't reached mainstream
use as yet. Computers as used today are still absolutely dumb machines that
are little more than super-fast calculators, and in most cases increases the
mental burden of their users instead of reducing/augmenting them. Nicholas
Negroponte had a great quote in '94 that's still true today - "those infra-red
urinals in public restrooms know more about what we are doing than our
computers today."

~~~
ludamad
Can you summarize what those things might be? (That haven't reached mainstream
use)

~~~
infinite8s
Here are 2 that he often brings up:

Ivan Sutherland's Sketchpad demo - Object oriented graphics using a constraint
based system
([https://www.youtube.com/watch?v=6orsmFndx_o](https://www.youtube.com/watch?v=6orsmFndx_o))

Douglas Englebart's demo - too many innovations to list, but includes real
time collaboration (he demoed in a convention center while the system ran 30
miles away in his lab, connected by a leased line operating at 1200 baud!).
People think he just invented the mouse, but the overarching theme in his work
was augmenting human capabilities...
[http://dougengelbart.org/firsts/dougs-1968-demo.html](http://dougengelbart.org/firsts/dougs-1968-demo.html)

~~~
tamana
Which of those things are not in mainstream use? We have Skype and Google Docs
and AWS for collaboration and client/server computing.

------
kmiroslav
I don't really understand this obsession with messages.

We're moving away from it. This is not how we program in the 21st century. The
last popular language that supported this paradigm (Objective C) is being
replaced and will probably be all but gone in just a few years as Swift (not
message based) takes it place.

Besides, this idea of message passing is really not that useful for modern
programming anyway but a lot of people still have this weird idea that message
passing magically solves the problem of data integrity in parallelism. It
doesn't. It does nothing to solve it. You can still have deadlocks and you can
still have data corruption.

The only approach that has provably improved our problems in this area is
immutability, but even that paradigm comes at a cost that sometimes doesn't
make it worth the trouble

~~~
_asummers
What about e.g. HTTP? The dynamics of server to server communication are all
about message passing (REST is just a message conveying state, if you ignore
the other rules). Look at things like Erlang and Elixir processes. Akka and
the actor model. Map/Reduce to a certain extent. These are all founded on the
idea of giving a task out with enough information that the worker can
reasonably go and work on the task without having to look around for state.
Also look at things like FRP and more event driven architectures. While not
ThingA sends message to ThingB, ThingA still broadcasts a message, possibly
containing the relevant state.

Also almost forgot. Look at the wealth of message queues that exist (RabbitMQ,
ActiveMQ, SQS, Kafka, ... the list goes on).

~~~
pacala
Message passing implies one way broadcast. Think GOTO. HTTP is a request /
reply protocol, i.e. a function call. Map / Reduce is an implementation device
for SQL-like collection-based processing, modern Map / Reduce systems
[Google's Flume / Dataflow] offer directly the collection API, using Map /
Reduce as an implementation detail. FRP is a device for adding a collection
API on top of streams of events. Collection APIs are conceptually function
calls over collections [duh].

Just because your compiler uses GOTO / messaging behind the scenes to
implement function calls, it doesn't follow that GOTO / messaging is the right
API level for designing applications. We know this since 1968.

~~~
protomyth
> Message passing implies one way broadcast.

Can you explain that since its contrary to my experience. PDO and normal
Objective-C methods had a return and are not one way.

~~~
ivan_gammel
In modern enterprise programming message is very different concept (probably
more widespread, if we'll look at popularity of Java and .Net, compared to
Objective-C), which is not related to OOP. It's a pattern of integration, in
which systems exchange with messages through a message broker, that abstracts
them from each other. By their nature such messages are asynchronous and
unidirectional.

~~~
infinite8s
That was also the original model of messaging in Smalltalk (well, without the
necessity of a broker).

~~~
coldtea
Smalltalk receivers returned values to the senders of the message. Plus, they
were synchronous.

So, while indeed still messaging, I'm not sure about the similarity to message
queues/brokers in modern enterprise, where, as the parent said "By their
nature such messages are asynchronous and unidirectional".

------
huuu
I might be wrong, but I think people like Alan Kay and Christopher Alexander
have in common that they:

    
    
       * see that things can be done better (not as in upgrade but best);
       * have a global idea/feeling of how this could be done;
       * take a lot of ideas from nature.
    

And somehow I think they have a lot of trouble expressing the 'how'.

My take: we should take a good look at nature because this is closest to what
we are. For example the communication between objects could be learned from
cells.

~~~
kmiroslav
Nothing wrong with looking at nature and trying to get inspiration from it
(e.g. neural nets) but ever since we realized that flight was easier to
implement with chemical combustion than by flapping wings, we know that just
because something works in nature doesn't mean it will be easy to replicate
for human use.

~~~
huuu
True. But because as today it's easier to implement doesn't mean we won't have
aircraft with flapping wings in the future.

~~~
jdmichal
We probably won't, at least not at human-scale and not on Earth. Flapping
wings don't scale; there's a reason you have to get to #12 of the heaviest
birds list to get one that flies, at ~13% the maximum mass of the heaviest
bird.

[https://en.wikipedia.org/wiki/List_of_largest_birds#Table_of...](https://en.wikipedia.org/wiki/List_of_largest_birds#Table_of_heaviest_living_birds)

~~~
DigitalJack
I wonder where pterodactyls would fall on that scale.

~~~
jdmichal
Looks like Wikipedia has us covered:

[https://en.wikipedia.org/wiki/Pterosaur_size#Speculation_abo...](https://en.wikipedia.org/wiki/Pterosaur_size#Speculation_about_pterosaur_size_and_flight)

From the references, this is a pretty good read:

[http://www.scientificamerican.com/article/how-pterosaurs-
fir...](http://www.scientificamerican.com/article/how-pterosaurs-first-took-
flight/)

------
jonahx
I'd love clarification on a few points, from anyone who understands everything
Alan says here:

 _Think of the internet -- to live, it (a) has to allow many different kinds
of ideas and realizations that are beyond any single standard_

Is he referring here to alternative protocols from http, or to the fact that
behind the single http protocol are servers written in myriad languages and
styles?

 _If you focus on just messaging -- and realize that a good metasystem can
late bind the various 2nd level architectures used in objects_

What is a metasystem? Can you provide an example? Similarly, what are 2nd
level architectures?

 _the realization that assignments are a metalevel change from functions, and
therefore should not be dealt with at the same level_

what does he mean here? what are the two "metalevels" of assignments vs
functions? what are examples of other "metalevels"? i've just never heard
these terminology in this context, so don't know where to start in
understanding it...

~~~
infinite8s
Regarding the internet (and the design of TCP/IP in particular), here's a
comment by Alan from his recent AMA:

[https://news.ycombinator.com/item?id=11960130](https://news.ycombinator.com/item?id=11960130)

One interesting point from a talk of his - the internet has never broken or
been unavailable since they turned it on, even though it has gone through
about 3 successive generations of hardware/software.

~~~
jonahx
So the idea, essentially, is that TCP/IP is like a "free form field" where
people can write whatever they want, and then everyone is free to create their
own structure on top of that, to suit their needs. In contrast to some
protocol that accepted only, say, XML? His point, then, is that _not_ forcing
such structure was a crucial ingredient in the internet's success?

~~~
endlessvoid94
The TCP messaging analogy here is that the design was a protocol, which
focused on how different components in a TCP system communicate with each
other. Rather than a design that focused on how each component worked
internally.

The inter-communication was the central design, not the intra-communication.

Many OOP programmers today spend the bulk of their time thinking about how
their objects should work rather than how they should communicate.

~~~
jstimpfle
> Many OOP programmers today spend the bulk of their time thinking about how
> their objects should work rather than how they should communicate.

Which is the "proof" that OOP was oversold. This is called "structured
programming". It's not evil :-)

[http://www.yegor256.com/2014/05/05/oop-alternative-to-
utilit...](http://www.yegor256.com/2014/05/05/oop-alternative-to-utility-
classes.html)

------
lacker
IMO the problem with object-oriented programming is that it turned into the
standard curriculum for peoples' first semester of computer science, rather
than being yet another interesting concept that advanced programmers would
ponder. And the way we handle "the standard CS curriculum" sucks. (In the USA
at least.)

For example, AP Computer Science requires Java and tries to teach stuff like
designing inheritance hierarchies to people in their first two months of
programming education. And then tests it mostly using multiple-choice quizzes.
It's totally inappropriate - most of these students would fail fizzbuzz.

OOP should be something you only get into after you have written some
practical programs, rather than something where you can't program, but you
memorize the difference between "is-a" and "has-a" inheritance so that you can
pass multiple choice tests.

~~~
stevedonovan
OOP made sense to people who already knew structured programming and
understood functional decomposition (what we now call 'refactoring'). Perhaps
education should start with that and then justify OOP? I remember reading
about the original LOGO experiments; one thing kids do not spontaneously do is
break up their monolithic actions into sensible functions.

~~~
lacker
Yeah "breaking up a complex function into simpler functions" is a great
example of something that isn't taught well today, yet is simpler and more
critical than what we try to teach people in intro courses.

I think of it in analogy to math. OOP is like topology - it's definitely
useful in some cases, it's not too hard for an experienced mathematician to
get the basics, and yet in a lot of situations it's irrelevant and it doesn't
really belong in the first class you take.

Being able to solve fizzbuzz is like doing arithmetic. If you can't solve
fizzbuzz then you aren't going to be able to really get any advanced concepts.
It's like you can't be a good mathematician if you can't figure out whether
351 is an odd number - you need to learn the basics first, even if "real math
isn't about arithmetic".

Sadly, you can tell if you do a lot of phone screens that many people who
graduate with CS degrees still can't code fizzbuzz. Our CS education is busted
right at the beginning. It needs to get the basics right, like, can you write
loops, can you write functions. Today it is failing at that.

~~~
mercer
Perhaps inheritance is easier to teach, which might be completely unrelated to
how useful it is in practice? That would explain a lot.

It reminds me a bit of how I was taught basic economics, where societies go
from barter to currency. Apparently this is not true at all, but it's a story
that is easy to teach.

------
unabst
His distinction reminded me of what I wrote in a comment regarding Dissipative
Adaptation and its relationship with language [1].

If Alan Kay is right, and Wittgenstein is right, and Prof. England is right,
then we should be focusing on the language that emerges from the necessary
transactions between functions, and let those transactions define the objects.
That would make the modern popular understanding of OOP completely backwards
-- as backwards as our understanding of the role of language prior to
Wittgenstein and the role of thermodynamics in biology prior to England.

Meaning, objects should not define (infer or induce or implement) the
communication, nor the expression. Rather, all transactions (interactions,
communications) should define (infer or induce or implement) the objects. And,
given names, the objects will find a way to sort themselves based on rate of
utility (the chosen objects, just as we choose the right words, from which
refined definitions sort themselves).

(Sorry for all the parentheses.)

\--

[1]
[https://news.ycombinator.com/item?id=11341397](https://news.ycombinator.com/item?id=11341397)

Before Wittgenstein philosophers were obsessed with the factual nature of
words and tried mapping everything correctly (logically) with the natural
world. Except, they were failing.

Wittgenstein came in and basically said language was never designed to
represent reality, but rather is what emerges from the use cases between
people. Communication is a transaction ("game" in his words), and not some
mathematical or logical construct. It may have such properties, and the people
and the context are all real, so reality is involved, but language is not a
direct output, nor does it need to directly correlate to resist contradiction
or paradox -- which are abound in philosophy.

Except, for those who speak it, language is their reality. Those who cannot
overcome their own immersion can never see past their own words, which sums up
much of his opposition. They are all correct in their world and in their
words... except Wittgenstein was talking about how words and worlds worked.

In short, words can be arbitrary, and are constrained by the goal to
communicate and transact. This exact phenomenon which Wittgenstein described
as what we are doing is the phenomena England is describing as what biological
systems are doing.

It's all Dissipative Adaptation, with language being the unique construct for
every such system that emerges and sustains it all.

------
mej10
Are there any examples of Kay's ideal other than The Internet? Especially
systems that I could actually inspect and learn about in detail, rather than
read short stories about.

~~~
z1mm32m4n
Hearing the way Alan Kay talks about "messaging" always reminds me of two
technologies: the Flux/Redux architecture and Apache Samza & Kafka.

> 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.

With React and Flux, this is exactly what's going on! You're defining view
components, and when someone interacts with them, there's a very structured,
discrete set of actions that can be fired. These actions are then dispatched
and handled elsewhere, but somewhere at the core, there's a single source of
truth for what happens upon any given message.

And for Apache Samza, I think this video[1] does a nice job of talking about
stream processing as a programming architecture. There's a connection to be
made between processing streams of information and processing messages between
modules, and that video goes a good way towards exposing it.

[1]:
[https://www.youtube.com/watch?v=fU9hR3kiOK0](https://www.youtube.com/watch?v=fU9hR3kiOK0)
"Turning the database inside out with Apache Samza"

~~~
michaelscott
Redux is definitely a step in that direction. Elm, which it's inspired by, is
even further along that road in that its design is better handled (but then it
doesn't require handling in JavaScript so I suppose that is why)

------
damienkatz
"OOP to me means only messaging, local retention and protection and hiding of
state-process, and extreme LateBinding of all things."

What he's describing is the essence of Erlang.

~~~
jacquesm
Yes, there are a lot of parallels there.

------
Dangeranger
Here is another important clarification email from Alan regarding the meaning
of OOP that I found to also be helpful:
[http://www.purl.org/stefan_ram/pub/doc_kay_oop_en](http://www.purl.org/stefan_ram/pub/doc_kay_oop_en)

~~~
Dangeranger
Note this email and conclusion are from 2003-07-23:

> 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.

~~~
dfox
The original article gives some important context to this sentence, as
otherwise it is slightly weird, as both ST-80 (at least in comparison to
earlier Smalltalks) and CLOS does not have that much explicit concept of
messaging and in both cases it's essentially late bound function call.

~~~
gnaritas
What? Smalltalk80 has #doesNotUnderstand: which allows explicit handling of
messages directly so no, it's not a late bound function call.

------
elchief
How is messaging different than calling a method?

~~~
ridiculous_fish
One example is the HTTP GET request. This was originally conceived of as a
file download, where the URL path is mapped directly to filesystem paths. GET
as an RPC: "download the file at this location."

But in modern thinking, HTTP GET is a request with abstract semantics. The
URL's path is abstract, and may be interpreted arbitrarily by the server. The
client has no idea whether the request is serviced by a simple sendfile() or a
fully dynamic program. HTTP GET is no longer an RPC, it is now a message.

A key difference is whether your function call is a request for concrete or
abstract behavior. If you answer "abstract," then the call itself must be
reifiable data, which can be sliced and diced in ways hidden from the caller.

~~~
DigitalJack
Can you define "reifiable" for me? I come across it a fair bit in clojure, but
I still don't really understand what the term means.

~~~
ridiculous_fish
Reifying means to take the abstract and make it concrete. Reflection is an
example: take a language feature, like a class, and make it into real data.
Many languages have some reflection capabilities for types; message sending
takes this even further.

For example, in Java, I can take a class and make data out of it: dynamically
look up fields, etc. I can also do that with a method. But I cannot take a
_method call_ and turn it into data. I can sort of do it with a lambda, but
lambdas make poor data:

1\. A lambda is concrete, not abstract. It's literally "run this code." 2\.
Even if your lambda merely invokes a method on an object, it's still opaque. I
can't pick it apart, get the parameters or method name out, etc.

Here's some practical objects you can't make in Java:

1\. Envelope: wraps an arbitrary remote object Contents. Any method you invoke
on Envelope gets sent over the wire and invoked on Contents.

2\. Delegator: represents the union of one or more objects, the Delegates. Any
method invoked on Delegator gets re-sent to the first Delegate that
understands it.

3\. Tee: Any method you invoke on the Tee gets multicast to its wrapped
objects.

4\. Mapper: wraps a list. Any message you send to Mapper sends it the elements
of its list, and returns the resulting list.

etc. Put directly, Java method invocations are procedure calls, not messaging.
But once you reify method invocations into object, it opens up all sorts of
dynamic possibilities.

~~~
DigitalJack
thanks

------
k__
Why didn't he call it Message Oriented Programming then?

Would have been a much clearer name.

But now we have all these clunky OO-systems, that focus on objects and classes
and still use functions/methods instead of messages...

~~~
DougMerritt
> Why didn't he call it Message Oriented Programming then?

He eventually said much the same thing (many people remember him as using your
exact phrase, but I'm less sure about that):

> [Kay:] I'm sorry that I long ago coined the term "objects" for this topic
> because it gets many people to focus on the lesser idea. The big idea is
> "messaging"...

[ Alan Kay, Usenet, 1998 ]

[http://c2.com/cgi/wiki?AlanKayOnMessaging](http://c2.com/cgi/wiki?AlanKayOnMessaging)

Somewhere I read him saying that a key moment was when he was looking at
(IIRC) Sussman's highly optimized Lisp dispatch of continuations, and realized
that it was essentially the same thing as what Kay had in mind for Smalltalk.
Something roughly like that.

It may have been the first "X is a poor man's Y" observation.

------
matchagaucho
Passing objects as method parameters and returning objects are sadly
underutilized.

The look on Developers faces when I suggest this refactoring pattern seems to
say "but that class doesn't do anything but encapsulate message data."

------
mmczaplinski
Does anyone know what Alan means by "assignments are a metalevel change from
functions, and therefore should not be dealt with at the same level"? In what
way are assignments a metalevel change from functions?

~~~
frankenbagel
I believe he means that variable and their assignments are at a _lower_ level.
Objects interfaces should be defined in terms of the messages they can send
and receive. No exposed variables: Variables should always be
private/protected and are just used by the objects to maintain their internal
state.

------
skybrian
I'm thinking the closest mainstream thing to real messages is probably event
handling. Events are nearly always represented as objects of some sort (rather
than something simpler like a function call) and event routing is the heart of
any UI framework.

So maybe the question is whether we should be using events (and streams of
events) more?

But this doesn't seem like a neglected area - publish/subscribe is pretty
common and there's plenty of recent discussion of reactive systems and event-
handling architectures.

~~~
Joeri
It is much broader than events. Anything where you sit and wait for some piece
of data to happen and trigger code can be viewed as receiving messages. An
object that sits in memory and has its methods called is receiving messages. A
piece of code that calls methods on objects is sending messages. A variable
containing data is a message at rest, and once passed to a method becomes a
message in transit. If you then start thinking about things like generators,
you see that this is just another way of sending messages. You can take any
program and view it entirely as a collection of messages, with the objects and
procedures being the glue between the messages.

The issue that languages have, is that the syntax obscures this fact instead
of highlighting it. There are many different ways of sending a message between
objects, and none of them are labeled as such. But essentially, there are just
two different models that matter: synchronous send + receive (receive the
replied message, the method's return value, before moving on), and
asynchronous send + receive (where the receive remembers the context of what
was sent that is being replied to). A really simple OO language would just
implement those two operations between objects, and would need nothing else.

------
ninjakeyboard
Poor Alan Kay.

"I made up the term 'object-oriented', and I can tell you I didn't have C++ in
mind."

\-- Alan Kay, OOPSLA '97

------
stcredzero
Isn't a lack of direct hardware/ISA support for message passing becoming
apparent in today's world of multicore architectures? The Disruptor library
used by HFT shops and much of Erlang seem to suggest a need for this.

~~~
astrange
Generally speaking anything that's essentially pointer chasing can't be moved
to hardware, because they'd make it with microcode and that's just hard-to-
update software.

[http://yosefk.com/blog/the-high-level-cpu-
challenge.html](http://yosefk.com/blog/the-high-level-cpu-challenge.html)

------
nix0n
This sounds a little bit like microservices, which are at the very least a
heavy-handed way to enforce separation of concerns. (I know they can't
possibly be what Alan Kay was talking about in 1998.)

------
Glench
More from Alan Kay: [http://alan-
kay.wikia.com/wiki/Alan_Kay_Wiki](http://alan-
kay.wikia.com/wiki/Alan_Kay_Wiki)

------
norswap
I've used Smalltalk, I've used Java. They are not __not __different in terms
of the object mechanism. The only difference one could imagine is that you can
treat messages as data through doesNotUnderstand in Smalltalk (the analog to
method_missing in Ruby). That is by far not the predominant use case though.

Otherwise, what makes method calls "messages" in Smalltalk, but not in Java?

This mailing list entry has always sound like bogus philosophistry trying to
defend an imaginary high ground.

------
markokrajnc
This was the time when Java-magnet pulled people, money and momentum from the
Smalltalk community...

~~~
pjmlp
The year before Java was announced I was doing a SmaltalkWorks project at the
university and it was part of our curriculum.

~~~
markokrajnc
You mean VisualWorks Smalltalk...

~~~
pjmlp
I guess, I didn't bother to search for how it used to be exactly called.

