Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Alan Kay on the misunderstanding of OOP (1998)

lists.squeakfoundation.org

Post reply on HN
Print view View original

111–120 of 212 posts

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

#111

Post by pdkl95 »

mdpopescu wrote: post #86
dang wrote: post #12

Earlier quoted context omitted.

Alan commented on this several times in the AMA he did here a couple days ago: https://news.ycombinator.com/item?id=11957001 https://news.ycombinator.com/item?id=11945986 https://news.ycombinator.com/item?id=11945123

So... it's basically event-driven programming? Objects generate events, and other objects are free to subscribe to them and do something in response (or not)? I thought of something similar a few years ago, I think it would indeed enable much better decoupling than the current OOP model - instead of object A telling object B "do this" (and thus having to know that object B exists and that it can do "this"), have obje…

> subscribe

There isn't any subscription with messages, which are sent to the object directly. There isn't any "event bus" or other complex structure. Messages are just a replacement for function calls (including accessor methods, which may be implied).

> decoupling

That's one of the primary goals. Traditionally function calls required coupling between the call and a single function or multiple functions with vtables or other polymorphism. With messages, the handling of what looks like a function call can be interpreted like an incoming event in event-driven programming.

> let object B, if it's interested, handle that

That's exactly right, but think of it as:

    * Object A sends Object B an event (message)
    * Object B can then handle that event in any way, such as:
        - calling a function
        - interpreting the event directly (i.e. all events handled the same)
        - raising an exception
        - ...whatever...
    * Object B then returns the result which becomes
      the "return value" that Object A. (this part is RPC-like)
> now B has to know about A

Not at all! I suspect you're thinking of this as a subscription model, which isn't correct.

One of the key benefits of messages is that objects never need to know about each other's type (in either direction). Ignoring types and simply sending messages to objects (regardless of their type) is called "duck typing"[1]. As long as an object responds in a useful way to the messages ["year", "month", "day"], it isn't important if the object is actually of type Date.

[1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/...

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

#112

Post by hackits »

cheshire_cat wrote: post #109
mercer wrote: post #103

Earlier quoted context omitted.

Is that actually the case in practice? I haven't used Ruby enough to know, but my experience so far is that most of the time the approach is still mostly just plain method calling in practice. I vaguely recall Rails moving away from some usage of method_missing (which I'd argue is one explicit example of message passing vs method calling). Honest question, btw, I really don't know.

He said "[...] it is encouraged to think of it that way rather than calling functions." This is what Sandi Metz talks about when she speaks about message/responsibility centric design vs data-centric design in OOP. The conceptual difference is said to lead to different designs. You don't start out your design by thinking about what data you hold but you think about which responsibilities/roles you have and create obj…

Another good book if you're interested in actors/behaviour decomposition instead of data decomposition is: Object Design: Roles, Responsibilities, and Collaborations and also https://www.amazon.com/Object-Thinking-Developer-Reference-D...

Also David West Presentation https://www.youtube.com/watch?v=RdE-d_EhzmA

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

#113

Post by optforfon »

kmiroslav wrote: post #81
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…

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

Sorry, I mean "drawbacks". One of the reoccurring complaints about OO is that it leads to huge codebases. Lots of articles about how X rewrote some Java program in Y and it's not 10x smaller and 100x more maintainable. This is a consequence of languages being designed to be minimal in terms of keywords - trying to push off as much as possible on to library writers. Unfortunately this seems to have serious limitations and all the boilerplate can't seem to be hidden in library wrappers

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

#114

Post by [deleted] »

hackits wrote: post #110
aryehof wrote: post #104

Earlier quoted context omitted.

>>> This is not how we program in the 21st century. Actually, for many if not most, programming today means using procedures and subroutines, organized through functional decomposition, just like was done in the 1950s and 60s. We haven't gotten that far have we. OO is a different paradigm from organizing the concepts in a domain through functional decomposition, and understanding how it is different, is key to unders…

Could you elaborate leading by example `how it is different`? Seriously because unless you can define it, and quantify it then it is just rhetoric.

[deleted]

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

#115

Post by Retric »

hackits wrote: post #110
aryehof wrote: post #104

Earlier quoted context omitted.

>>> This is not how we program in the 21st century. Actually, for many if not most, programming today means using procedures and subroutines, organized through functional decomposition, just like was done in the 1950s and 60s. We haven't gotten that far have we. OO is a different paradigm from organizing the concepts in a domain through functional decomposition, and understanding how it is different, is key to unders…

Could you elaborate leading by example `how it is different`? Seriously because unless you can define it, and quantify it then it is just rhetoric.

Functions have no internal state. Early languages used global variables to share state across functions without explicit message passing (everything was a singleton). This created worlds of pain. The alternative was passing state with each function call. This also got painful as people often passed data down through functions.

OOP lets chunks of functions share state and hide that state from the wider application. More importantly you could have multiple instances of that shard state without explicit management, saving a lot of complexity and effort.

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

#116

Post by shrugger »

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.

That is exactly true!

I have experience teaching kids Lua, and with the right metaphors and a little bit of backtracking and foundation-building, even complicated ideas like emulating classes and single inheritance can be understood and even implemented by young students.

If I taught them lua reserved keywords, and a couple little math tricks here and there, they usually would all bunch up everything into a couple huge functions, and their game would (sort-of) work but be impossible to reason about, and very painful to extend.

Introducing objects as a way to represent things that they want the game to do (draw things, shoot things, eat things, etc), it becomes clear to them that there is merit in structuring programs with objects beyond "shrugger says to do it like this!"

OOP on its own doesn't make much sense. You can't teach someone to drive stick shift if they don't know what a car is. Maybe you could, but that's probably even worse.

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

#117

Post by mikekchar »

mercer wrote: post #103
sb8244 wrote: post #102

Earlier quoted context omitted.

Is message passing that you're referring to different than the Ruby concept of messages? Objects respond to messages in Ruby, and it is encouraged to think of it that way rather than calling functions.

Is that actually the case in practice? I haven't used Ruby enough to know, but my experience so far is that most of the time the approach is still mostly just plain method calling in practice. I vaguely recall Rails moving away from some usage of method_missing (which I'd argue is one explicit example of message passing vs method calling). Honest question, btw, I really don't know.

I personally don't know how it is implemented under the hood, but it is important to understand as a Ruby programmer that methods are not just functions. In fact functions are not really first class entities in Ruby. Instead you have a mishmash of procs, blocks, instance methods and class methods and they are all different to a certain degree. It's one of the big frustrations of programming in Ruby sometimes.

But when it comes down to it what really is message passing? You have a reference to an object, a method name and a collection of parameters. When you dispatch the message you look for the method on the object and run the function passing in the parameters. Does it matter if you optimise the situation by placing the parameters on a stack and using a dictionary with a reference to the method? Or if you optimise by doing static analysis to look up the method and replace the dispatch with a direct call to the method? Or if you optimise further by inlining the code altogether?

The point is not how it is implemented but how the programmer thinks of it. Object Oriented programming is a thing humans do, not a thing computers do. Object Oriented Programming Languages have features that make it more convenient to do Object Oriented programming. Whether the code is OO or not is only up to the programmer, not the compiler/interpreter.

Having said all that, is Ruby my first choice for (what I understand to be) Alan Kay's model of OOP? No. But then I really don't know what my first choice would be. It is possible that the language hasn't been written yet ;-)

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

#118

Post by jdmichal »

Retric wrote: post #115
hackits wrote: post #110

Earlier quoted context omitted.

Could you elaborate leading by example `how it is different`? Seriously because unless you can define it, and quantify it then it is just rhetoric.

Functions have no internal state. Early languages used global variables to share state across functions without explicit message passing (everything was a singleton). This created worlds of pain. The alternative was passing state with each function call. This also got painful as people often passed data down through functions. OOP lets chunks of functions share state and hide that state from the wider application. Mo…

> Functions have no internal state.

But closures do. And thus, why closures are a poor man's objects, and objects are a poor man's closures. As an example, Java closures are really anonymous objects with the closed state as instance variables.

> More importantly you could have multiple instances of that shard state without explicit management, saving a lot of complexity and effort.

Technically that's what classes gives you, not objects. But agreed on the sentiment.

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

#119

Post by zeveb »

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…

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

Maybe it should be? Languages like Erlang and — to a much lesser extent — Go use message-passing semantics in at least some places.

To paraphrase Chesterton, message-passing has not been tried and found wanting; it's been found unusual and not tried.

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

#120

Post by aryehof »

hackits wrote: post #110
aryehof wrote: post #104

Earlier quoted context omitted.

>>> This is not how we program in the 21st century. Actually, for many if not most, programming today means using procedures and subroutines, organized through functional decomposition, just like was done in the 1950s and 60s. We haven't gotten that far have we. OO is a different paradigm from organizing the concepts in a domain through functional decomposition, and understanding how it is different, is key to unders…

Could you elaborate leading by example `how it is different`? Seriously because unless you can define it, and quantify it then it is just rhetoric.

> "Could you elaborate leading by example `how it is different`?"

I'll try.

By the end of the 1950's, modular programming based on procedures and subroutines had become problematic. It was hard to have large teams of programmers working on parts of the code at the same time, and it was hard to create large well-structured programs.

The answer in the 1960's was to break down a problem into pieces, then sub-components, then subroutines through functional decomposition. This better allowed large problems to be understood, and worked on by different teams at the same time. This approach is known as structured programming.

This approach has resulted in quality software over the years, but suffers from painful limitations. One of the big ones is that as one works on a problem and discovers its requirements, the decomposition used needs to be modified, often from the top down.

Object orientation (much as for the "data" movement) represented a different way to approach a problem. Let's break down a large problem or system into entirely independent concepts that know how to to do things themselves. Let's not orchestrate concepts (objects) centrally, but instead have them do things themselves together to solve a problem. This comes close to the way we think. We recognize and organize things in our minds around us as objects. We differentiate between them by their attributes, and we classify them. When we see a tree we recognize it as such, and differentiate it from other by its attributes and also by its place in the hierarchy of types of trees we know. Behavior on the other hand is only immediately important to us if it is causal - for example if it threatens us. That unknown thing moving fast towards you prompts changes in your body, but once you recognize the object is a beetle and not a spider, you change.

Hopefully that helps.

Post reply on HN