Hacker News new | past | comments | ask | show | jobs | submit login

OOP is about (subtype) polymorphism

What are we to make of this quote: "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."--Alan Kay

Do we interpret that as suggesting that polymorphism is the thing and that Alan is using different words to describe it? That polymorphism is an implementation technique for achieving the goals Alan is describing? or perhaps that in the thirty years since Smalltalk has been commercialized, we have moved on from its initial vision?




Alan Kay also said: "I made up the term "object-oriented", and I can tell you I did not have C++ in mind."

Going by Kay's original definition, Java, C# and C++ do not qualify as object-orientated languages. I think we may have to accept that the original term has become somewhat diluted over time.

However I don't think OOP is all about polymorphism, because you can have polymorphism without objects (e.g. Clojure's protocols or Haskell's type classes).


the original term has become somewhat diluted over time

It's not the original term. OOP started with Simula 67 and then split into 2 branches: the Alan Kay brach and the Barbara Liskov branch.

Alan Kay coined OOP for his branch, but the name caught on. So now OOP can refer to any descendent of Simula 67. Even ones he didn't have in mind (C++ is on the Liskov branch).

The thing is: the branches aren't really compatible philosophically. That's a big reason for the amount of confusion that exists.

In Alan Kay land objects are sub-computers that receive messages from other sub-computers. In Barbara Liskov world objects are abstract data with operators and a hidden representation.


Alan Kay coined the term, so his definition was the first, and therefore the original.

But aside from your unusual interpretation of the word "original", I agree with everything you said.


I already mentioned other types of polymorphism.


But OOP isn't really a type of polymorphism, any more than a Ford Focus is a type of internal combustion engine. You claim that:

> OOP is about (subtype) polymorphism... Everything else is there to support and make it easier to apply this concept.

But if that were true, why does your typically OOP language handle polymorphism so poorly? If your only goal is subtype polymorphism, why not just have multimethods and type inheritance and be done with it? Why bother with encapsulation? Why only have single-dispatch?


I haven't said that OOP is a type of polymorphism, I only said that OOP has a type of polymorphism, that is its most important property and easy to overlook when talking about OOP.

I'm also not saying that you could throw away the rest - thinking in objects has value, having the ability to inherit implementation has value (in certain cases) and so on; so definitely the whole is bigger than the sum of the parts.

The comment I responded to said OOP is a metaphor ... but now you're saying it's like a Ford Focus with a certain type of combustion engine. That's exactly my point - it's easy to overlook what makes it tick.

And you asks questions to which you (probably) know the answer.

Multimethods are sweat, but a bitch to optimize and only useful in certain use-cases - that's why Clojure is backing away from them. Single-dispatch is what you need in 80% of the cases and it can be optimized aggressively ... notice the JVM where most method-calls end up not doing a vtable-lookup (not that you can have a vtable with multimethods).

C++ / Java handle OOP so poorly because these are languages with a static type system that can't blend in with OOP (where method dispatching is done at runtime). But that's what people asked for.


Clearly I misunderstood what you were saying. It sounds as if we agree on most things :)

> Multimethods are sweat, but a bitch to optimize and only useful in certain use-cases

I'm curious, why do you think multiple-dispatch is more difficult to optimize than single-dispatch?


"messaging" / "extreme late-binding of all things" - this is about polymorphism.

"local retention and protection" - encapsulation is THE goal of every engineer (i.e. black boxes that take some input and reliably give you some output, without you worrying about the details) and is in no way an exclusive property of OOP, although thinking about data-structures as objects that respond to messages gives you powerful tools to do that.

EDIT - and thinking about beginners that can't understand OOP, encapsulation is also hard to explain, but that doesn't make it any less of a useful goal.


"Messaging" also means loose coupled. It enables things like Structural interfaces (you implement what you implement) like in Go, instead of declarative interfaces (you implement what you say you implement) like in Java/C++/C#.

"Messaging" and its loose coupling also means the ability of doing Method Lookup Alteration and Interception [1], such as those provided by Smalltalk’s doesNotUnderstand, Ruby’s missing_method and Python’s __gettattr__ method. This is crucial because it allows you to compose objects, as they are strippable down to the Common Lisp Object System system: an object is a function that takes a message specification (method name and args) and decides what to do with it.

Yeah. Messaging is really important and powerful. It also explains why Alan Kay also said: I coined the term object-oriented, and C++ wasn't what I had in mind.

[1]http://www.google.com/url?sa=t&source=web&cd=2&v...


"Messaging" is polymorphism in action and a way to describe it to people without headaches by concentrating on benefits and use-cases, instead of implementation details.

And to be a little pedantic -- virtual method calls in Java/C#/C++ are also messages.

What Alan Kay meant was that a static type system doesn't blend with the OOP he enabled in Smalltalk. Do you know why?

Because in OOP polymorphism, method-dispatching is late-bound. And being late-bound it makes absolute sense for the developer to be able to override the method-dispatching that's being done (by means of method_missing and other mechanisms). But that's directly at odds with the purpose of a static type system.

And btw, structural typing is not dynamic typing. It has the same problem as the one described above.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: