Alan Kay on the misunderstanding of OOP (1998) • Hacker News Board

Re: Alan Kay on the misunderstanding of OOP (1998)

#141

Post by zerohp » Fri, Jun 24, 2016, 3:31 PM UTC

stevedonovan wrote: post #18

lacker wrote: post #14

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 hiera…

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.

When the ECE department at my university revised the undergrad Computer Engineering curriculum, they rejected the CS introductory courses partly for this reason. They also want to teach hardware first, but more importantly they teach "systematic decomposition" from the very beginning (before they teach programming) and leave OOP for future course work.

Re: Alan Kay on the misunderstanding of OOP (1998)

#142

Post by dfox » Fri, Jun 24, 2016, 3:34 PM UTC

Dangeranger wrote: post #137

Dangeranger wrote: post #134

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

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.

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.

Re: Alan Kay on the misunderstanding of OOP (1998)

#143

Post by DigitalJack » Fri, Jun 24, 2016, 3:37 PM UTC

jdmichal wrote: post #125

huuu wrote: post #89

Earlier quoted context omitted.

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

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

I wonder where pterodactyls would fall on that scale.

Re: Alan Kay on the misunderstanding of OOP (1998)

#144

Post by DigitalJack » Fri, Jun 24, 2016, 3:38 PM UTC

gliese1337 wrote: post #35

DigitalJack wrote: post #25

Earlier quoted context omitted.

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.

"reifiable" = "able to be reified", where "to reify" means "to make something abstract concrete or real". So, for example, Scheme's call/cc function reifies continuations- it take a continuation, an abstract control-flow concept, and turns it into a concrete object that you can pass around and manipulate in code. Therefore, continuations are reifiable in Scheme.

thank you

Re: Alan Kay on the misunderstanding of OOP (1998)

#145

Post by DigitalJack » Fri, Jun 24, 2016, 3:38 PM UTC

ridiculous_fish wrote: post #46

DigitalJack wrote: post #25

Earlier quoted context omitted.

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.

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…

thanks

Re: Alan Kay on the misunderstanding of OOP (1998)

#146

Post by grandalf » Fri, Jun 24, 2016, 3:45 PM UTC

skybrian wrote: post #140

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 comm…

> But this doesn't seem like a neglected area

It is generally considered a suited for a different class of problems. I think Kay's point is that decoupling the messages from an object's internal state is a smart approach to system design. Many of the other "features" of OOP get in the way of this design principle.

Re: Alan Kay on the misunderstanding of OOP (1998)

#147

Post by markokrajnc » Fri, Jun 24, 2016, 3:52 PM UTC

pjmlp wrote: post #67

markokrajnc wrote: post #50

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

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

You mean VisualWorks Smalltalk...

Re: Alan Kay on the misunderstanding of OOP (1998)

#148

Post by somethingsimple » Fri, Jun 24, 2016, 4:01 PM UTC

kmiroslav wrote: post #80

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…

This is anecdotal, but my 8-year old daughter found it quite intuitive to learn programming based on message passing (on Scratch).

Re: Alan Kay on the misunderstanding of OOP (1998)

#149

Post by jonahx » Fri, Jun 24, 2016, 4:09 PM UTC

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

Re: Alan Kay on the misunderstanding of OOP (1998)

#150

Post by kabdib » Fri, Jun 24, 2016, 4:09 PM UTC

pjmlp wrote: post #66

optforfon wrote: post #48

Earlier quoted context omitted.

"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 failu…

I can think of a good list of OO languages that don't have anything to do with C. Also the pImpl is a consequence of C++ not adopting modules and instead rely on C linkers, nothing to do with OOP.

Yup. We were looking at alternate runtimes in some OS / userland projects at Apple in the late 80s. You don't need vtables, and you can do better than static struct layout. You have to do some work at code load-time.

C++'s initial lack of a real string type and simple collection types pretty much doomed the language. (Instead they did iostreams? I've been using C++ since early CFront days, and have never used that misbegotten API).