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

41–50 of 95 posts

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

#41

Post by Kinrany »

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 dislike OOP as much as the next HN commenter, but dependency injection tools are good in principle. OOP just uses them much more and for bad reasons.

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

#44

Post by Twey »

_pdp_ wrote: post #27

> OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. This sounds a lot like microservice architecture.

Taken to an extreme. It's not feasible with current microservice architecture to, for example, represent every Boolean in the program as a service.

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

#45

Post by bluGill »

Kinrany wrote: post #41
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 dislike OOP as much as the next HN commenter, but dependency injection tools are good in principle. OOP just uses them much more and for bad reasons.

OOP isn't why they are used. OOP may enable injection more than others, but it is not encouraged. Bad programmers and bad architects is why it is overused not OOP. Keep the blame in the right place.

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

#46

Post by noelwelsh »

jdw64 wrote: post #36
Rochus wrote: post #35

Earlier quoted context omitted.

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.

You'd probably like the work of Tomas Petricek: https://tomasp.net/

He does research in "the history and philosophy of programming", amongst other things.

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

#47

Post by sirwhinesalot »

Kinrany wrote: post #41
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 dislike OOP as much as the next HN commenter, but dependency injection tools are good in principle. OOP just uses them much more and for bad reasons.

Dependency Injection frameworks are a workaround for limitations of the paradigm, much like Design Patterns also are. They're necessary (by a very stretched definition of necessary) because people want to do certain things and the paradigm is fighting them.

Some part of the code wants to do logging. The paradigm-native solution is to just instantiate a logger object directly, but that's not really what you want to happen, because there are application-level concerns as to where those logging messages should go.

So instead of a direct new, you create a Logger interface (extra work), then use the Factory pattern (extra work) to hide the concrete logger objects that get instantiated. Ok, but now you are still creating multiple independent loggers, which will trample on each other.

So you employ the Singleton pattern (extra work), but now you can't use different loggers for different parts of the codebase.

Ok, let's instead have the application instantiate the proper loggers, and then thread them through method arguments as needed (extra work).

But now passing all those loggers around is super annoying and extremely noisy, so you create a framework that can inject them where they are needed.

Great, now you have a whole framework just to pass some logger objects around. The framework is not the problem per se, it exists for a reason, the problem is that someone felt the need for it. And it is a massive pile of complexity that is NOT worth it.

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

#48

Post by Rochus »

shevy-java wrote: post #39
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.

“I wanted a scripting language that was more powerful than Perl, and more object-oriented than Python" and "Ruby's class library is an object-oriented reorganization of Perl functionality--plus some Smalltalk and Lisp stuff" (see "An Interview with the Creator of Ruby", 2001, https://web.archive.org/web/20041220041220/http://www.linuxd...).

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

#49

Post by tskj »

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…

You might like Casey Muratori's "The Big OOPs" talk about this, if you haven't seen it yet: https://www.youtube.com/watch?v=wo84LFzx5nI

It's my favorite deep dive into the subject, it's super thoughtful and well structured.

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

#50

Post by mpweiher »

_pdp_ wrote: post #27

> OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. This sounds a lot like microservice architecture.

Very similar, yes.

Except that Kay did not envision the distinct computers communicating via REST.

https://blog.metaobject.com/2019/11/what-alan-kay-got-wrong-...

Also: microservices currently require at least process and frequently even VM/Container/Machine boundaries.

In-Process REST scales that down:

https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_...

Language support for In-Process REST:

https://dl.acm.org/doi/10.1145/3359591.3359729

https://objective.st/

Post reply on HN