Alan Kay on Moti’s “Objects Ever?” CACM Article

September 15, 2010 at 10:38 am 8 comments

Occasionally I take the blog-owner’s prerogative to re-post a comment as its own blog post.  Alan Kay, inventor of the term “object-oriented programming” responding to Moti Ben-Ari’s article on “Objects Ever?” would be reason enough.  Even better, Alan’s response offers insight into what parts of objects are most critical to use and learn.

Spoiler alert that particularly pleased me: Inheritance ain’t one of them. I have had several debates, often at SIGCSE, about the importance of inheritance. The discussion usually ends with me saying, “Read Alan’s HOPL chapter!” and my antagonist’s reply, “I don’t read history — that has nothing to do with modern languages.” What was that line again about “doomed to repeat”?

Thanks for this, Alan!

Here is the comment I added to the ACM post of the article. And I’ve added a few more things to think about below this.

———————————————————————–
I think this article raises important issues.

A good example of a large system I consider “object-oriented” is the Internet. It has billions of completely encapsulated objects (the computers themselves) and uses a pure messaging system of “requests not commands”, etc.

By contrast, I have never considered that most systems which call themselves “object-oriented” are even close to my meaning when I originally coined the term.

So part of the problem here is a kind of “colonization” of an idea — which got popular because it worked so well in the ARPA/PARC community — by many people who didn’t take the trouble to understand why it worked so well.
And, in a design-oriented field such as ours, fads are all to easy to hatch. It takes considerable will to resist fads and stay focused on the real issues.

Combine this with the desire to also include old forms (like data structures, types, and procedural programming) and you’ve got an enormous confusing mess of conflicting design paradigms.

And, the 70s ideas that worked so well are not strong enough to deal with many of the problems of today. However, the core of what I now have to call “real oop” — namely encapsulated modules all the way down with pure messaging — still hangs in there strongly because it is nothing more than an abstract view of complex systems.

The key to safety lies in the encapsulation. The key to scalability lies in how messaging is actually done (e.g. maybe it is better to only receive messages via “postings of needs”). The key to abstraction and compactness lies in a felicitous combination of design and mathematics.

The key to resolving many of these issues lies in carrying out education in computing in a vastly different way than is done today.
——————————————————————-
A few more comments here.

If you are “setting” values from the outside of an object, you are doing “simulated data structure programming” rather than object oriented programming. One of my original motivations for trying to invent OOP was to eliminate imperative assignment (at least as a global unprotected action). “Real OOP” is much more about “requests”, and the more the requests invoke goals the object knows how to accomplish, the better. “Abstract Data Types” is not OOP!

A larger problem here is that though the invention of OOP and the coining of the term were influenced by several prior systems (including Sketchpad and Simula, and others which can be found in the history I wrote for the ACM — a nice irony it turns out!), it is quite clear that the idea of OOP did not include most of its precursors.

We didn’t even do all of the idea at PARC. Many of Carl Hewitt’s Actors ideas which got sparked by the original Smalltalk were more in the spirit of OOP than the subsequent Smalltalks. Significant parts of Erlang are more like a real OOP language the the current Smalltalk, and certainly the C based languages that have been painted with “OOP paint”.

The largest problem here is that a misapplication of a paradigm is being blamed for what is really bad language and systems designs and implementations. And I agree completely with the author that most of the features cited are really bad. But they have nothing to do with OOP.

For example, Smalltalk initially did not have inheritance because I thought the way it was used in Simula was all to easily the foundation of nightmares (too many different semantics from one mechanism). Instead the original Smalltalk used many LISP ideas to allow dynamic experiments with many kinds of generalizations.

I think the remedy is to consign the current wide-spread meanings of “object-oriented” to the rubbish heap of still taught bad ideas, and to make up a new term for what I and my colleagues did.

A smaller consideration is to notice that what is good about the original idea is still quite good, but it does require more thinking (and different thinking) and design to accomplish (but with great benefits in expressiveness, scalability and safety).

Blaming a good idea for being difficult is like blaming the Golden Rule for not being easily able to be learned by most humans. I think the main points of both lie elsewhere.
Best wishes,
Alan

Entry filed under: Uncategorized.

Discovering Oneself Supporting the “Landed Gentry” A robot drummer as computing student inspiration

8 Comments Add your own

  • 1. Maria and Gary Litvin  |  September 15, 2010 at 11:18 am

    Thank you, Alan. It is especially disheartening that event-driven models are not even mentioned in AP CS curricula and most college courses.

    Reply
    • 2. Stephen Bloch  |  March 6, 2011 at 1:05 pm

      I teach event-driven programming, with clear model/view separation, starting in the third week of my “Computer Programming for Non-Majors” course. Students have not yet seen an arithmetic operator, a conditional, or a loop, but they’re writing GUI programs that respond (in simple ways) to the clock, the mouse, and the keyboard.

      http://www.adelphi.edu/sbloch/class/160/

      Teaching the same concepts to first-semester CS majors would be possible, but more difficult because the CS-major course is hobbled by Java 🙂

      Reply
      • 3. Mark Guzdial  |  March 6, 2011 at 1:41 pm

        Hi Stephen! Sounds really interesting! I saw on your web page that you have an NSF grant on this approach. Do you have any results yet showing what the students are getting from this approach, e.g., what are they able to do later with it? I’m intrigued by the conceptualizations that non-majors take away from different approaches to introductory computing.

        Reply
  • 4. Geoff  |  September 16, 2010 at 5:48 pm

    The programming model being described as Alan’s original vision of “OOP” sounds to me a lot like the Actor model (which he mentions). Is the main difference that actors describe concurrent systems, while OOP is inherently sequential? Are there other differences?

    Reply
  • […] Alan Kay on Moti’s “Objects Ever?” CACM Article (computinged.wordpress.com) […]

    Reply
  • […] Kay had a guest post on Mark Guzdial’s blog: Alan Kay on Moti’s “Objects Ever?” CACM Article where he described “real OOP” as “encapsulated modules all the way down with pure […]

    Reply
  • 8. OO: Then and Now – eatsleepios  |  September 17, 2016 at 6:56 pm

    […] [3] Alan Kay on Moti’s “Object Ever?” CACM Article […]

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trackback this post  |  Subscribe to the comments via RSS Feed


Enter your email address to follow this blog and receive notifications of new posts by email.

Join 4,353 other followers

Feeds

Recent Posts

Blog Stats

  • 1,587,086 hits
September 2010
M T W T F S S
« Aug   Oct »
 12345
6789101112
13141516171819
20212223242526
27282930  

CS Teaching Tips


%d bloggers like this: