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

Alan Kay on the meaning of "object-oriented programming" (2003)

notes.shixiangxi.com

Post reply on HN
Print view View original

31–40 of 95 posts

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#31

Post by KayEss »

sirwhinesalot wrote: post #20
socketcluster wrote: post #17

IMO, the most important philosophy in all of software engineering is "Separation of responsibilities." The best way to achieve it is through the principle of "High cohesion, loose coupling." OOP is just another layer of philosophy which builds on top of that. It's more specific, imposes additional guardrails. It requires objects with state encapsulation (locality) and message-passing as the mechanism for components t…

I agree "high cohesion, loose coupling" is a good architectural property to strive for, but OOP is terrible at it and there's no reason to use it for this. Trying to achieve "high cohesion, loose coupling" in OOP has led to the creation of (supposedly) best practice recommendations like the SOLID principles, and the development of monstrosities like dependency injection frameworks. If OOP was actually good at "high c…

I think this is looking at what OOP has become (as implemented by systems and programming languages that don't care a wit about what OO was meant to be) rather than what Alan Kay described.

If you think about something like a web server as an object, it has arbitrarily high cohesion and arbitrarily low coupling. You can only communicate to it through messages (HTTP); binding happens at the point in time that the message arrives (notwithstanding that this may be cached in all sorts of interesting ways in the implementation of any given server); and the web server is fully encapsulated (security flaws notwithstanding).

I think it's perfectly reasonable to argue that much of what gets called OOP doesn't deliver on the promise, but then it doesn't deliver on the premise either, and I think these are inextricably linked.

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#32

Post by usrnm »

Mikhail_Edoshin wrote: post #25
usrnm wrote: post #14

Earlier quoted context omitted.

Your example lacks data. An object is the combination of data and code manipulating the data with some syntactic sugar on top

Data will indeed be necessary. But data in OOP are interesting: they are not supposed to be directly visible. They are like the method body: there is one, but it is not important what it is. So if we add data, it will be that: class Aaaa (some data) method bbbb(): (some code) Do you think this is an object now?

Yes, it is an object now, at least in my book. Public/private is less important, there are examples of OOP systems with private data being optional or non-existent at all, for example in Python.

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#33

Post by TZubiri »

jqpabc123 wrote: post #6

I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages It was originablly conceived as a simulation of a distributed system. Distributed systems can be useful but does anyone really believe that they are simpler or easier to develop and maintain? The amazing part to me is that so many were trained and convinced to accept that adopting this sim…

>Distributed systems can be useful but does anyone really believe that they are simpler or easier to develop and maintain?

If you try to maintain a decentralized system, it will be hard yes.

However if you see the nirvana and try to maintain the parts of the system, it will be easier.

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#34

Post by Mikhail_Edoshin »

sdfsdfs34dfsdf wrote: post #22
Mikhail_Edoshin wrote: post #11

There was a Soviet philosopher, Evald Ilyenkov, whose books taught me about a "minimal working model". I'll explain it in my own words. People do not think with words: people think with things. Words serve merely as pointers to things. Some things are easy to point at; Ilyenkov talks about a cow. Some things are much harder to point at; Ilyenkov, being a Marxist, wanted to point to private property, we need to point…

That's super interesting. Thank you for that. I believe what's missing is not just data. That'd only grant it capabilities that upgrade it to a "record" type of entity. I believe an OOP object is more than a record. It's missing behavior triggered by messages. For an object to pass or receive a message we need to have a model of a message and that requires the notion of a sender and receiver, both objects again. Seem…

Behavior is a good clue. The current model, even with data, lacks behavior. It has a method, which is like a message we send to it. But it does not seem to give it enough behavior, even though we don't make any assumptions about its complexity.

Or maybe it could give it behavior if it were like that:

    class Aaaa
      [some data]
      method handle(message, ...)
        [some code]
This construction implies there are multiple messages. "Multiple" is the key difference. The part that was missing in the original sketch is a second method:

    class Aaaa
      [some data]
      method bbbb()
        [some code]
      method cccc()
        [some code]
Now this is an object. For example, it can be a random number generator: we initialize it and then read next numbers. Or it could be a timer: we initialize it and then read the value. We do not need a fully object-oriented environment for that; there is a plenty of such things in C and other non-OOP systems.

Such a thing surely has some behavior and this is exactly what we use. We are not interested in the internal data much. In fact the internal data of an object play exactly the same role as a function stack frame: it is a private slice of memory a computation keeps for itself because this is how it works. As in knitting the size of the manipulator is tiny compared to the final result and to do anything substantial we need a place to keep stuff around until we are done. And we need to be sure data stay were we've put them, hence encapsulation.

So an object is very much like a function, it is a computation that uses some memory to do its job. It is different in that in an object the computation runs step-by-step guided by external events. A function is like an object that gets the whole sequence of events at once, runs from start to finish and in the end discards the working memory so we tend to forget it exists. An object runs from message to message and keeps the working memory, which we see as "object data". This is why objects arise naturally in areas like user interface where events are truly external. But an object is actually a primary form of computation: if you can process a single event, you can use it to process a sequence; but if you can only process the whole sequence, you cannot just switch to processing single events. There are many similarities with closures, coroutines and such; I'd say they are different ways to express the same principle.

(This also means that objects are naturally mutable. Immutable objects are an aberration that arose because we've got here in a very roundabout way.)

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#35

Post by Rochus »

jdw64 wrote: post #28
Rochus wrote: post #26

Earlier quoted context omitted.

Cool; though a few facts on your landing page might need some reconsideration. See e.g. https://news.ycombinator.com/item?id=36879311 . > something like a small computer of its own Which corresponds pretty well with the Simula I concept, published 1966 in the Communications of the ACM. A Simula event notice (time, process) in the sequencing set is just a message step(process, time) in a priority mailbox; the two are…

thanks! I checked the link and there are indeed quite a few inaccuracies in the initial part. I'll go through it and make corrections.

The IEEE milestone about OOP is also worth reading: https://ethw.org/Milestones:Object-Oriented_Programming,_196...

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#36

Post by jdw64 »

Rochus wrote: post #35
jdw64 wrote: post #28

Earlier quoted context omitted.

thanks! I checked the link and there are indeed quite a few inaccuracies in the initial part. I'll go through it and make corrections.

The IEEE milestone about OOP is also worth reading: https://ethw.org/Milestones:Object-Oriented_Programming,_196...

Thank you so much. Sometimes I wish there were more documents out there that organized the historical aspects of programming like this.

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#37

Post by sirwhinesalot »

KayEss wrote: post #31
sirwhinesalot wrote: post #20

Earlier quoted context omitted.

I agree "high cohesion, loose coupling" is a good architectural property to strive for, but OOP is terrible at it and there's no reason to use it for this. Trying to achieve "high cohesion, loose coupling" in OOP has led to the creation of (supposedly) best practice recommendations like the SOLID principles, and the development of monstrosities like dependency injection frameworks. If OOP was actually good at "high c…

I think this is looking at what OOP has become (as implemented by systems and programming languages that don't care a wit about what OO was meant to be) rather than what Alan Kay described. If you think about something like a web server as an object, it has arbitrarily high cohesion and arbitrarily low coupling. You can only communicate to it through messages (HTTP); binding happens at the point in time that the mess…

The Alan Kay variant of OOP is superior in this regard, and I'd argue the Erlang variant even more so (Actors are just asynchronous objects).

But both of them are still suboptimal because they allow objects to instantiate one another and to directly communicate with whomever they come in contact with. That creates strong coupling and you have to "fight the paradigm" to avoid it.

Other engineering domains have this figured out: components can only send and receive data through ports, they are never aware of their siblings. Only a component at a higher level of abstraction can decide how the ports of lower level components connect to one another. That completely eliminates coupling.

(You can of course replicate this type of architecture with OOP, but you can also replicate it with any turing complete paradigm, that's neither here nor there)

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#38

Post by shevy-java »

Alan Kay's definition of OOP is my favourite one, though I actually extended it a bit; for instance, erlang/elixir kind of have "failsafe, reliable objects". Now, barely anyone would call these languages OOP, but IMO it follows just logically similar to Alan Kay's definition. Probably a new language may be required, which is hard to do (make it a succes, that is hard), but along those lines of having a wider definition of OOP. What I definitely hate is the limitation towards C++ and Java. Those two languages really messed up the OOP term, and then we had clown languages such as PHP just copy/pasting that definition and not understanding what OOP is really all about.

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#39

Post by shevy-java »

jdw64 wrote: post #21

I studied the history of OOP a while back because I was curious, and I organized what I learned into my personal wiki[1]. From what I remember, there were quite a few different perspectives on it. One view traces OOP's practical ancestry back to Ole-Johan Dahl's Simula. From Alan Kay's perspective, on the other hand, an object was something like a small computer of its own. The two main lineages of OOP are Simula and…

Depends on the language. I would argue that ruby inherited more from Smalltalk than from Simula, for instance.

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#40

Post by shevy-java »

jqpabc123 wrote: post #6

I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages It was originablly conceived as a simulation of a distributed system. Distributed systems can be useful but does anyone really believe that they are simpler or easier to develop and maintain? The amazing part to me is that so many were trained and convinced to accept that adopting this sim…

> Distributed systems can be useful but does anyone really believe that they are simpler or easier to develop and maintain?

Dinosaur. Whale.

I think these were success stories for a long time. So, it is possible to develop and maintain complex systems.

Post reply on HN